SMIng minutes from the 53rd IETF WEDNESDAY, March 20, 2002 1530-1730: Minutes reported by David Durham. Special thanks to Ravi Sahita for taking minutes during the meeting. David Durham chair. - The chair presented agenda and a list of doc status. - The status was that the wg was behind in its schedule. There are 2 proposals still in progress: SMI-DS and the NRMG SMIng proposal. - The chair wants to see more people involved in discussions on the mailing list. * Andy Bierman presented v02 (third rev) of SMI-DS. SMI-DS provides improved data modeling capabilities to express nested data structures using a hierarchical oid namespace. This allows set operations to be made easier; also one can avoid race conditions in get operations. This update improves on the naming scheme to retain compatibility with SMIv2, but also allows more containment layers. We can take advantage of these data definitions with SNMP today but more protocol operations are needed to move aggregate data around in one transaction. To accomplish backwards compatibility, the instance ids are now over to the right, so the SMIv2 index is still in the same place. Andy has added some new clauses like OID POINTER, UNIQUE-SCOPE, SPARSE-AUGMENTS. Also added the notion of runtime retrievable conformance information which implicitly maps to the mib instance data. Andy mentioned Juergen was arguing that this same functionality could be better achieved by just adding more mib objects or separate capabilities data as in the Framework PIB. AUGMENTS has changed significantly. One can't augment types anymore, which is basically retained for backward compatibility with SMIv2. Hierarchical instance naming has been changed to preserve SMIv2 objects, so one can go from SMIv2->SMI-DS->SMIv2 and nothing is lost. However, to use new features in SMIv3 and to go to SMIv2 can be done but it's not going to be transparent. Still, the instance level supports nesting in order to move aggregates around. Now SMI-DS OIDs can coexist with SMIv2 since the static portions are identical. Nesting level 0,1 are identical, where levels >1 are concatenated to the RHS of the OID name. The static portion is registered so that SMIv2 still works. Andy presented an array in array example with types W, X and Y1 and Y2, with Y1 and Y2 nested in type Y. All instance ids are moved to the right hand side. Each time a nested node is added a static node is added to the oid. When getting such a type, you get all instances of W first then all for X then all for Y1 and then Y2. Chair asked what this means for getnext? Andy replied that you get column first order, and fornest level upto and including 1, you don't change from the SMIv2 (achieving backward compatibility). One can reuse the nested containment as the entire struct can become another member within another structure including its statically defined sub-oids (starting from the root static oid of the containing structure). A Conformance Level was added. This is a scalar number implicitly associated with the corresponding instance data. Its purpose is to describe at runtime the conformance level a particular device supports corresponding to a particular mib structure. The challenge here is dealing with variance across boxes... agent caps aren't available on the boxes previous to row creation... so one wouldn't know what's available on the box initially. Also, sometimes mib objects have no conformance levels, so this scalar will be unused. The objects could also have min/full conformance associated with a mib object. Sharon asked how do to use this? Andy said these are psuedo mib objects for real mib objects. Sharon - isn't a better approach to backoff if there is an error? If the node subid is 0, that could be the anchor point of the compliance section. Sharon- And that provides a mapping to the compliance stmt in the mib? Andy-the conformance info struct has 4 objects, confModuleCompliance - this tells what version the agent complies with, confLevel - has confVariation - has syntax clause of object, confVarDesc - description where variation of an agent caps/desc of object clause of a module compliance macro. comment-Is this for runtime agent capabilities? Andy gives an inet address example. You can add enums with syntax clause and you can document if you need more. Dave Perkins noted that this was examined with snmpconf, which found this approach doesn't work. The fundamental thing was module compliance is better known than agent caps. There's no requirement that you have module compliance in a mib module. Besides you can have multiple mod comps. Though compliance could give a range, you don't know where in that range of behavior the person has implemented. You can only assume the min of the specific value. Andy responded that's what 'other' is used for, to specify exactly what you implemented. DaveP had two issues with this - Issue1: Whether your behavior matches the defn of the object or the defn of the application. Issue2: Does it comply with conformance or not? You don't have to have a modcompliance in a MIB. Bert noted that you can leave it out but another doc must be submitted which does compliance. Andy thinks this is the 80/20 kind of thing, there may always be other corner cases. DaveP - I agree this is needed - but need to work out the details. Others firmly support having this capability and Andy noted that a lot of work is done by app developers to understand different versions. The issue then came up how would one use read-create, how would one say he wants create and go and won't accept create and wait? Basically what if one wants to see if rowstatus has been lowered to accept only create and go. Andy replied that we would need to use Sharon's style where we do conformance by a new subtree. Randy suggested that, like the app mib, it would force the different vendors to implement same level of conformance. Andy replied that if you have an oid with more than those subids, it can use lowest prefix match. OID pointers discussion followed. Basically Andy provides the concept of typed pointers. He gave an example from RMON with a syntax pointer to . DaveP wanted to know how would one do 'data source null' with this concept of pointers? Andy - Are you asking how do I put a 0.0 in there? DaveP - No, reporting that information. Andy hasn't I thought that thru. Uniqueness: Andy believes it is a non feature of the SMI to force uniqueness in the index. It makes things complicated, things have to be unique within internet/admin domain/device - or not unique. SPARSE AUGMENTS: Array variables can be augmented. Sparse augments has a sparse condition which is a textual clause that is machine readable via SPARSE-EXPRESSION keyword. As for mapping SMI-DS to SMIv2: One can go back but the process won't be transparent. Randy wanted to know how this oid naming is different from SMIv2? When you flatten out the indices, it comes out the same on the wire. Andy said it's not the same... You have different root oid in the SMI-DS case... Same semantics but not the same oid numbers. Open issues discussion: * Merge SPPI? MIB readers read MIBs, tool developers need to read SMI, we can define rules for mapping these; not protocol mappings like in SMIng. * Syntax? SMIv2-like? Java-like? XML? * Terminology? SMIv2-like? OO-like? * Module COmpliance? - Needs to be variably declared, not per accessible object descriptor. - max access should not be in typedefs. Example-counter32 cannot be more than readonly access. * Implied runtime Conformance info or just add more MIB objects? Andy and room seem to be leaning toward the just add more mib objects approach, not the implicit mapping Andy added to SMI-DS. * INDEX clause issue. Issue was should it be defined inline per attributed within the data definition (implied) or should it be outside akin to SMIv2. After some discussion, people seem to prefer keeping the SMIv2-like INDEX clause because this allows more flexibility in how one defines the index. * SPARSE-EXPRESSION condition syntax. Suggestion to make this a simple boolean expression. Bob asked as this evolves for compatibility etc, do you have an assessment on your effort to make mib modules easier to read? Andy replied that he is assuming the writer is familiar with struct, union, typedefs, arrays etc. You can refine a base type and that's it. This gives us more building blocks and achieves a higher level of reuse. It will certainly eliminate a lot of cut and paste. Randy noted that reuse doesn't necessarily make it easier to use. That presupposes an ability to find out what to reuse. Reuse is great but not making a connection between this and a newcomer using this is bad. Steve thinks we are focusing too much on a newcomer. He might go read InetAddr in a doc and if it's named correctly - he can deal with it properly. Randy replied that you have to know to look for it. If I'm dealing with x.25, someone would have to find x.121 for me. How do I know x.121 exists? Jeff believes this is an age old discussion. When you repeat text by value it's easier for newcomers, text by reference is easier for people who know. Andy said that regardless, code/semantic organization is required in some way. Wes- agreed that reuse makes it easier to write, and 9 out of 10 questions about the SMI are how do I put a table in a table. SMI-DS makes it much easier for new authors to be able to do what they want to. Steve also agrees that reuse promotes not re-inventing which is a good thing. SMI-DS Syntax Discussion: Randy believes that syntax is just a user interface issue. Andy thinks it is naive to think anyone going to use this is immune to knowing SMIv2, You will always have to know the syntax of those MIBs that exist today. Andy pointed out that when going from v1 to v2 things were transparently compatible, without changing anything on the wire. It was asked that given in the mib objects there is a syntax current clause - can that be made default? Andy responded that he thought that is a 2nd order issue. He is trying to reduce pages of text... To avoid repeating descriptions via constructs like unions and structs. Bob wanted to know if we're making any progress - are there any benchmarks to measure our success? Randy though that this could this be a good project for a focus group of college freshmen? Andy thinks it's all subjective, Steve makes a good point, once one looks at a definition once, having containment and C like data structures, he doesn't care what the structure of some sub-aggregate is. This search to find out if this MIB is appropriate, shifts them away from the real problem. Once can see this problem in code with seven different versions of strcpy. Steve mentioned that when we talk about metrics we should consider code size of agent implementations, but Randy believes that depends on how optimized your code generation process is, how much redundant code is generated. Dave went on to recap the NMRG proposal looking at some of the differences between it and SMI-DS. For one, sming allows hierarchical data structures without first assigning oids to them. So you can map to tables and protocols like COPS etc or even to XML. On the negative side, people felt they have to do twice as much work because assigning oids was another separate step. Andy's proposal added relative oids to the reusable data structure definitions. Andy pointed out that theoretically we have protocol independent MIBs and MIB independent protocols, and SMI solves this so that the writers don't have to do this every time. It was also pointed out that mapping of pointers to data structures were causing problems when mapping pointers to oids and the corresponding instance space in the sming proposal. The syntax of the NMRG proposal was made to look more like C to make new comers feel readily familiar with it. Also, the NMRG proposal has provided an abnf grammar for the language. Andy said he would get to an abnf for SMI-DS later. What followed was a formulation of questions for consensus on four issues, 1. hierarchical oids for N levels of nesting 2. level of reuse/independence of oid naming from the data structure definitions. 3. Support of multiple protocols. 4. Syntax. The consensus of the room was determined, and these same questions will be asked on the mailing list. Starting with hierarchical oids, Dave asked if we want to do hierarchical oid format as in SMI-DS? Sharon pointed out that we need to be aware that we'll break a lot of apps. The manager side needs to be aware if this is done in existing mibs for example if she is querying ifTable. Andy believes this will be a new mib then. Steve asked Randy that if you take ifTable, if he augments anything in the table with hierarchical naming, would he agree that if.12 can do whatever it wants? Randy agrees as long as the oid for the augments does not end up being a subtree of the tree being augmented the manager can do a getnext and not see this new tree. Andy mentioned that we had the same problem with Unsigned Int64's. The code that understands the foo mib is the only one that knows what the instance id is. Randy pointed out that if you have an existing mib and doing a mib walk this is not going to affect that. Sharon thinks this is good but it needs to be spelled out clearly in the doc. Jeff agrees SMI-DS is good and for this particular issue, if we generalize this from 2 to N dimensions, there are benefits. So, Jeff's strongly in favor of Andy's proposal for hierarchical oid support and would go to the Nth degree (levels of nesting). *** The consensus of the room was unanimous that n-levels of nested data structures via hierarchical oids should be supported by the SMIng. Next the chair revisited the issue concerning flexibility of reuse: Andy pointed out that the issue is code design in general... a container which represents one instance in general or you typedef the array and reuse by reference. Randy pointed out that in the SMI-DS definition when Andy defines an array and the index is a foreign key, you could get into a scoping situation. But he thinks that issue has pretty much gone away now. Andy said what Randy really wants to do is contain the structs and n would go to 3 instead of 2 and it would no longer be transparent. Dave pointed out that what Juergen was saying was that for backward compatibility you may want to map new structured data to existing flattened tables. Randy raised the issue of having elements in index clauses which were not an element of that struct. Jeff pointed out that if you change the index, then you should deprecate the table and start over again. *** The conclusion was that 100% coverage for all cases of reuse is probably not achievable. Juergen should clarify the advantages of mapping abstract hierarchical data structures back to existing flatten mibs. No consensus can be determined until we clearly formulate what this concept is here. Next addressed was the issue of dealing with multiple protocols: The chair asked if the wg wants to consider things like mapping to a standard CLI? Andy would like to keep the charter focused to map to COPS-PR and SNMP. He thinks the objections are for having MIBs and PIBs, so we instead have one underlying schema that gets accessed in different ways. But we need someone from SPPI side to solve the COPS-PR mapping. dbh noted that one of the things that came up previously in this wg were methods- looking at CLI, it does work like methods. Steve however wonders if CLI ops are row adds to tables so if you think along those lines it gets simpler. *** The conclusion was that we should focus on SNMP as a wg, and someone should do a COPS-PR mapping. CLI and other such mechanism should not be our focus at least initially, particularly given the lack of a standardized CLI. The next issue was around what to do concerning syntax: Should we keep SMIv2 Look & Feel? or switch to XML or a more Clike syntax? - Newer people might be familiar with something more mainstream such as these. There was general agreement to defer this discussion till later. Still the question remains as to what the proposals are going to use for the time being? Jeff believes we need a direction, Randy is right in that syntax is boring but he thinks we should follow Andy's proposal. It was also pointed out that we have to think in terms of what tools are currently available... - by keeping the SMI consistent - we have several available tools. By using XML there are also tools out there. By switching to something else, someone will have to develop a compiler and toolkit for it. Randy wants to keep the discussion focused on modeling issues and protocol mappings etc. Notations that diverge too much from what is in the SMI is not good. We should focus in the semantics of things, then, we can decide on the syntax. But he would like to keep things focused on functional issues. Bob agrees with what Randy said. - Believes that long-term we would be better off getting away on our own private set of notations and tools. It would be nice if we all use the same set of tools. There was a comment that SNMP and SMIv2 are being extended for use in telco, and this looks like its getting too complex, meaning the problems are complex in telco and SMIv2 seems to be getting complex also to deal with it. Randy pointed out that GDMO is hard to understand since there are templates, that have behaviors, that have external objects- this promotes reuse and modular code but you need a very powerful browser, unless you wrote it you won't understand it. Bert wondered if this is an issue of the design or the complexity of the data? Randy thinks it's due to excessive modularity. Andy doesn't want to make SMI-DS any more complex that it is right now. He has seen some easy to understand code and some hard, so complexity is in the hands of the designers. He thinks another syntax that would be workable would be XML. Wes pointed out as Andy has repeated many times - make it easy for the majority. There are 3 groups of people that would comprise this majority. Those that write mibs, those that implement them - these guys understand c,C++,java, and then the group that read the mibs. The latter has two subgroups, the manager app side and the n/w admin, who wrap their head around them to use them. He doesn't think C is perfect for both ends. He doesn't think English is perfect for both ends either. We should not do what CIM did in reusing everything. We shouldn't go overboard with OO and reuse. Jeff noted that he'd like to support the growing consensus that we continue with SMIDS/SMIv2-like syntax, focus on features, and near the end decide for XML schema or SMI or something else. Changing other things will not make a difference, what makes MIBs difficult to write are the rules we added. C programmers can map { to BEGIN and } to END - so Jeff suggests we keep the syntax as close to SMIv2 as possible. *** The consensus of the room was to continue using a SMIv2-like syntax for the time being. The chair asked if there was support for holding an Interim meeting. Roughly 10 people responded they would attend an interim meeting for SMIng to progress. -End of session-