SMIng Meeting Minutes from IETF55: TUESDAY, November 19, 2002 Time: 1930-2200 Minute takers: Ravi Sahita Minutes reported by David Durham WG Chair: David Durham Issue: Updated documents have not been produced. We need volunteers to progress the SMI-DS related document set. Need more participation on the mailing list. Chair: Revisited Charter and Milestones. Updated charter was put on the mailing list. No issues raised on the list, no issues raised at the meeting either. According to the charter milestones we are a year behind. The original milestones assumed the nmrg documents which were complete, but the wg chose to investigate the smi-ds route. We will still need a few iterations on the smi-ds/v3 documents before they will be complete. The current proposed list of documents in priority order is: - 1. SMIv3 Language Definition ANDY BIERMAN - 2. Capabilities MIB DONE - 3. SMIv3 Guidelines - 4. Transition from SMIv2 - 5. SMIv3 MIB Modules (core types) - 6. INET Modules (textual conventions) - 7. RFC 2580 Conformance Updates We need volunteers for the documents or the wg will shut down, and the smi will not progress. Previous volunteers for the guidelines and transition documents are waiting for the language definition. In principle, people support the smi-ds work, but we will need people to sign up to get the work done. Likewise from the discussion at the wg meeting it seems that there is a lot of waffling on how we proceed item by item through the open issues listed below. Wes Hardaker presented SMIng enhancements that would be useful to his OOPS proposal: Nested data structures such as Subarrays in arrays (eg. where you can have multiple interfaces and multiple addresses assigned to each interface) make indexing subelements difficult. Wes proposes that internal indices are given a local number. Advantage is that we have a local index to it including external indexes. This enbables all elements to be mapped to an OID. Something like: INDEXS otherIndex FROM otherTable ::= {base 1} What does this have to do with the SMI: If you pick an augmentation table. Not a problem for previous SMI structures, but problematic to have nested structures because need to go down to the index. There was a lot of discussion whether or not this is useful. It provides a way to separate the data instance index part of the oid from the data type part of the oid. There was concern that this mechanism would affect transpartent forward translations from SMIv2 MIBs, but this will apprarently only affect new SMIv3 definitions where there is nesting and not SMIv2 stuff. Andy made it clear we should only have one version of the SMI and not create the need to continually support two versions. There was no consensus in the room that Wes's proposal was a necessary or appropriate language mechanism. Wes was to post to the list some cases where this is valuable, removing oids where possible, to better support compression because his new PDUs have a base root oid. Next it was pointed out that external augmentations are a pain from the protocol's perspective with multiple random OID assignments. Any chance we can fix this in SMIv3 via a forced local extension node?: Currently, if the agent doesn't have the MIB definition locally, the agent needs to interpret the oids without the MIB. One thing that makes augmentation tables difficult is that if you don't know an agent supports the table you wouldn't know to get it. It helps understanding for those who are trying to query agents. Andy pointed out his original proposal fixed this by having a 0.enterprise ID where you could augment right inline the oid hierarchy, but this went away when the indices were all grouped back on the right of the oid to preserve forward mapping of existing tables. Wes proposes that this is only for new structures in SMIv3, but Andy believe we really need to go back to understand the importance with the forward translation because we don't want to have two versions of the smi going forward. The purpose is to make the new oops protocol mappings work better with SMIv3 structures. Again, there was no consensus in the room around this proposal. More thought is needed to fully understand what the problem is before we add more syntax to the smi, and Wes volunteered to elaborate on the problem on the mailing list. Next, Wes suggests that smiv3 notifications should be able to contain structs and possibly even arrays. Currently only support for single objects. Example: would like to be able to send all addresses associated with linkup. It would be nice to support new notifications with more complex/complete data (like syslog). The limited data that snmpv3 notifications support is a reason why operators use prefer to use syslog instead of snmp. Wes is trying to define new PDUs to make access to new more complete structures easier. This affects smiv3 because notifications would now be able to support aggregate types instead of just base types, but this would not be backwards with snmpv3. There was more support in the room for this proposal over the rest, however, enabling backward compatibility w/ snmpv3 requires more thought. Others concluded that a similar result could be achieved if strings are used and a standard syslog-like string format were defined... No changes would be required to the language or snmpv3 to accomplish this. Andy Bierman presents the SMIv3 Open issues: * NULL choice for union types: Like and SQL NULL value. Want to be able to create a template for a generic table (eg. RMON control entry)... can create an instance of that table and leave out stuff that you didn't need in your usage scenario. In sming it was implements X and implements Y but not Z, which is like partial inheritance. Instead, he proposes the parent gets to tell you what it can pick and choose, so it's not equivalent to partial inheritance. Still, Andy is not convinced that this is worth the trouble it might cause. * Oid naming for aggresgates and sub-aggregates: How to tell you want to access row three down in the second nested array. It was previously suggested having a zero to apply on the left to distinguish the constant part from the instance identifier part. If have a nested array want to get internal array now. Want more granularity to get one object or get everything. This may be a moot point if the protocol changes, and you don't get the support in SNMPv3 for it, so you only support the fancy new aggregate new stuff with new protocol. Also weren't sure if adding .0's everywhere is backward compatible. Other organizations have oids with 0's in them. For example, the IEEE sometimes defines their own mibs, such as for the 802.1X protocol. The OID of the IEEE 802.1 branch for mibs is { iso(1) std(0) iso8802(8802) ieee802dot1(1) ieee802dot1mibs(1)}, so every mib put out by the IEEE 802.1 group will have a zero in the OID. The only rule currently is that the last subidentifier per object can't be 0. Andy would advocate doing new things with the new protocol and not trying to retrofit into the existing SNMPv3 protocol. They should still work with snmpv3, but they will be suboptimal there. The issue was raised that when you have multiple levels of nesting in your oid, then your encoding rules either result in ambiguities or undesirable behaviors in get next and get bulk. Andy believes that if you are trying to get a leaf, and all the indices are on the right, there are no ambiguities. The suboptimal behavior of get next is the same bad behavior that we already have today. The orders that we got were always suboptimal. Getting rows would be correct, but we instead get the columns. Still, the worst case and the specific issue was poor behavior with unions, because the order is questionable. The question was raised: Why not having a separate branch for all new SMIv3 structures. Having naming that is helpful to us instead of being in the way. If you have only one layer of nesting then it falls out that the indices are on the right, because they are in the right place anyway. Bring this to the list, too complex to deal with now. Juergen previously had objections to putting the new definitions under a new branch, he thought it would break things. Others point out that changing the root oid will make things much more complicated, eg. dealing with all the enterprise-specific branches, users may get confused about the differences between the branches, related information appears under completely different branches, etc. * NOTIFICATION definitions in TYPEs: Proposal to move notifications into the types to be more OO-like. It is not always true a notification can be tied to a specific set of data, however. Also not sure what problem this issue solves. Juergen previously also wanted master NOTIFICATION (link up), and derived NOTIFICATIONs. Suggestion was to take this to the list until we can understand what Juergen wanted to do originally. Moving on... * Inline vs. by-reference TYPEs and VARs: Extend types by inline or by reference and only allow named types. Interim decided that we only do it by reference, never inline. By reference allows all constructs to be reusable. Adds some complexity in terms of versioning. We would never allow a type to be silently extended, you would have to clone it. Another issue is it makes MIBs harder to read because you have to search for type definitions. Some have suggested that this makes things unreadable. Turns out that people think referencing things by type is an annoyance. Some things are simply not meant to be reused. The MIB writer has to have some responsibility with the freedom. Inline definitions should be allowed to aid readability. *** The consensus in the room was to kill the proposal to force all types to be reusable. *** * Descriptor naming issues for TYPEs. BCP document would define what the limit is for different protocol mappings, and the current limit that names are to be restricted to <=32/64 will be eliminated. Hums agree. Require uniqueness only within the scope of the parent node. Can you have descriptors that define the same data types. It needs to be fully qualified. It is important to distinguish between the name of the type (eg. TC) and the name of an object (the oid). This discussion is specifically around type descriptors. You can use the module name descriptor to find import name clashes. Finally, it was suggested we move to XML style names; mixed case with hypens. Hums agreed this would be good to do. * Conformance section changes to support SMIv3. Existing MODULE-COMPLIANCE macro won't work for SMIv3 objects. Descriptors are not unique within the module. Existing problems with SMIv2 need to be fixed such as OBJECT clauses for INDEX objects. Need to create a construct for each complex VAR declaration... Could fully specify attribute names; but it would be better to have a shorthand notation. Andy suggests he will work on this offline, it's not an open issue, he just needs to finish it. * Change control issues for variables Need to be able to add new attributes to existing VARs, just as we add new columns to an existing table now. We should be able to create a new type which is a superset of an old type and allow VAR SYNTAX to change. Use conformance section for version identification. Allow the writer to replace FooType with BarType which is a superset of FooType. This could be done with a Cut & paste operation, and can only add new definitions to the end. If it is defining a subclass, need to increase the naming depth. It would be useful to have an include clause since we want to be able to compose new object definitions from the old definitions. This is specifically for change control. Only semantics of fooType need to stay the same, just need to add columns to a table in a radically new way. * SMI syntax changes Many syntax changes proposed by at the last interim. Need to decide case by case on the mailing list. Examples: Imports; LEAF, NODE or ATTRIBUTE; OBJECT-GROUP ->GROUP; NOTIFICATION-GROUP -> GROUP; Base type names; Remove MODULE - this module should be implied. There were no comments. There was little support for syntax changes in the room. * Migration of SMIv2 CLRs to SMIv3 Suggestion was to take them out of the SMI and put them into a separate document particular to a protocol mapping. But we don't want to put the sign that says no left on main and collect it with all other crappy little road signs and put them in the same place. But, at the same time, we need to make the language document somewhat future proof so when protocols are upgraded, we don't have to update the full standard document... Concensus in the room was to put these rules in a separate informational document & thus easier to change. * Support for Configuration: Need to distinguish between different types of objects: Configuraton (acl list, bgp peer, users/passwords) vs. Control (per-session debug commands, reset card) vs. State (ifOperStatus) vs. Statistics (eg. ifInOctets). Need mechanism to describe high-level configuration methods:Could be purely documentation, but they need to be clearly specified in the MIB document... These could be more, such as the minimum procedural requirements for a particular task. Don't call these methods! Call them use cases or scenarios. Specifically what is needed: Mechanism to describe what has to be created in initial PDU, what can be edited after creation, what is the cascading deletion order, etc. * Support for XML naming , XSD translation. It would make the IETF more consistent if the SMI were to be the base definition for everything, XML, COPS-PR etc. Would like to make sure there is only one data definition, regardless of the number of protocols. Some hints to make language definitions easier: Need to identify XML Namespace for MIB; Add optional XML-NAMESPACE "" clause in MODULE-IDENTITIY, or use XML namespace MODULE name; Need to identify XML element names: Optional XML-NAME "string" clause in TYPE or VAR constructs used to override descriptor as element name. Need to map ARRAY population characteristics to minOccurs, maxOccurs attributes. The question was raised, why so much emphasis on XML. Some question if it was appropriate to put XML name mappings inline vs. in a separate XML mapping document as there could be a separate sppi mappings document. Given Andy's suggestions for support of XML naming, some expressed that perhaps a better outcome of this wg effort would be to declare that XMLSchema should replace the SMI.