Sming interim meeting in Washington DC June 6-8 2002 Minutes reported by David Durham. Special thanks to those who recorded the minutes: Juergen Schoenwaelder & Steve Waldbusser. Attendees: Joel Halpern Andy Bierman Bert Wijnen Randy Presuhn David Harrington Steve Waldbusser Juergen Schoenwaelder Chris Elliott Glenn Waters David Durham Wes Hardaker Rob Fry June 6, 2002: * Status and Update: o Where are the sming documents? They had expired (this is fixed). o Jeff withdrew smiv3 proposal, supports smi-ds. o Andreas is not pursing asn1 proposal. o Latest smi-ds version 00 on web page (actually third revision from Andy) o Consensus recap from last IETF meeting: * N-levels of nesting: Yes * Hierarchical instance naming: Yes * Continue using SMI syntax as much as possible: Yes (for the time being) Juergen presented for discussion questions related to high-level goals in an attempt to better understand consensus. Clearly we desire a more powerful language so that 1. Human readers can understand data models more easily and 2. Human writers can express their models in a better way. But do we want to support more than the current SNMP technology? The consensus was that more is fine, but the primary target is SNMP technology, for both monitoring and configuration. So retaining compatibility with current SNMP technology is desired. Attendees wanted the ability to convert from SMIv2 to SMIng (a requirement), and converting SMIng to SMIv2 only where possible (not a requirement). The other question concerned the SPPI. As this topic has been addressed in the past, the chair repeated that this working group will not be constrained or concerned with backward compatibility with SPPI. COPS-PR supporters are responsible for writing a translation if they desire it. Juergen went on to explain why Frank and himself had reservations to the SMI-DS approach. People want to improve the SNMP technology for both monitoring too. SNMP technology is even worse for configuration management. Frank/Juergen believe that we should not change the things that are working well enough. Specifically, they believe changing instance naming will break many applications. The other attendees did not agree. No one who had applications thought that they would be adversely affected by the SMI-DS naming scheme. MIB walks will still work, and the advice was not to use old tools to view new structures anyway. Ideally there shouldn't be any changes that result the wire protocol, but adding new base types is clearly an exception. Juergen ended by suggesting that it was the lack of high-level operations that was the main problem, and using an RPC mechanism would be a good thing. Andy agrees that having clear elements of procedure/use cases for those things people typically do would be beneficial. Overall, people wanted to improve readability and clarify the syntax of the language. Two clear non-requirements was the idea of making it easier on the tool writers (who are a minority) as well as providing annotations to the language. It was felt the latter would be best handled by separate documents, not inline with the standards (overall, making it hard to add new a syntax clause was considered a feature and not a bug). Finally, Juergen strongly believes that the language should be familiar to the majority of people out there. There is no language out there that has the concept of a leaf. Randy agrees that what we do in the smi is different than what most cs students are familiar with since we use different terminology. Andy doesn't believe that SYNTAX or MAX-ACCESS is the problem, it is the lack of data modeling and data structure. Clearly, however, OBJECT in the smi is not what people think it is. * Terminology: o Continue to use SMI terminology? Don't change what isn't broken, if it is, at least take pains to explain why when changing terminology. o Define delta's from existing SMI terminology for use this week: * SMIv3 will be the output of this working group. * Base Types = {Integer, OctetString...} * Derived Types = Refined Types: TCs. Smi-ds does not have a mechanism to extend existing structs in the OO sense. Sming has a mechanism to derive complex types from other complex types. * Scalar Types = Leaf nodes. Anything that is not an aggregate. Can even be a pointer. * Attribute=property=subelement(in XML)=node(smi-ds): The namable elements. Lot's of discussion, consensus toward the word attribute (aggregates can also be attributes). * Structure: Defines a set of attributes. * Class: Essentially a structure with methods. Neither smi-ds or sming have classes containing methods. * Object: ? Will not use this term moving forward, too much baggage. * N-levels of nesting (tables in tables, arrays in arrays...)=Aggregate types: Complex data types can be comprised of other complex data types, including arrays. * Hierarchical Instance Naming: using oids to name hierarchical instance data. * Unions: Choice. * Index: Instance identifier. * Row pointer: * Instance pointer * Typed Pointers=Constrained Pointers: * Intermediate Type Definitions * Name Spaces: Constrained/Scoped universe of identifier names. * Constraints: Clause that constrains the values an attribute may take. * Reusable (abstract) Definitions = type definitions * Leaf Nodes : node which does not contain other nodes. Attribute which does not contain any other aggregate type. Consensus was to change term to something more understandable. * Aggregated Data Object: This term refers to any data object which provides some sort of containment for other data objects, which is any variable construct other than LEAF (e.g., ARRAY, UNION, or STRUCT). * Data Object: This term refers to any SMI Data Structure variable declaration, at any level of containment. * MIB Object: This term generically refers to a SMIv2 OBJECT-TYPE macro definition. It may also refer to an SMI Data Structure definition. * OID: This is a shorthand term for 'OBJECT IDENTIFIER'. * LEAF: This term refers to any accessible data object with a syntax that resolves to a SMI base type. * Method is basically Elements of Procedure as can be determined from a Use case. Next was a discussion about the merits of having a hierarchical oid namespace. Hierarchical oids provide aggregates and aggregate information even at a protocol level. They also enable the individual items of the aggregate to be addressable. The difference between SMI-DS and SMIng documents is at what stage during the definition process are the oids associated with the datastructure. Consensus is that we want to explicitly assign oids within the data structures and not have map them or define arbitrarily later. Smi-ds provides for reuse of the suboid number as well as reuse of the data structures themselves, removing at least one level of indirection. Consensus was to preserve the hierarchical aggregations on the wire was a valuable thing to do (and not to strictly depend on the syntax definition). What followed was a discussion about indexing. SMI-DS keeps the index portion of the sub-oid on the right. The reason for this is that oid pointers (eg. Row pointers) expect indices on the right. If they are not, then old mib definitions will not be able to effectively reference new smiv3 mib definitions. Keeping the index on the right does have the side affect of making the getnext behavior look even stranger. It was noted that the protocol will not allow aggregates to be hidden, so you can only skip over hidden data. Given these issues, there was a suggestion for having two oid spaces, one with indexing on the right, another with indexing inline, adjacent to the current level of aggregation. Randy brought up the issue of unions and getnext. There is a problem with getting next lexical ordered element with a union because get next may skip over the union because the index is on the right. It wasn't clear how bad this problem would actually be, it simply would require the manager to try and get the possible union values directly. A possible solution would be to put the union discriminator on the end of the oid, but this will then mess up the lexical ordering. June 7, 2002 Indexing was further discussed with Andy's (corrected) slides showing conceptual mib walk with smi-ds mibs. The main issue was how to determine where the prefix oid stopped and when the index portion began w/o requiring the smi-ds mib (some intermediate layers of the snmp stack may need to know this information, but won't have access to the definitions). It was suggested to use a .0 between the prefix and index portions to understand where the break point is. Since .0 is not allowed in mibs today, it could be used for this purpose. Another suggestion was to simply use meta data that specified where the prefix and index were for any given oid. Conclusion was there needs to be sufficient meta data available to figure out where each of the indicies are. But we should keep the naming the same as it is today. It was also suggested to use the meta data to encode the oid textual name, and other mib information so that mibs can be more self-describing (like XML documents). Other more radical suggestions were to move away from oids altogther, being that they seem to be the root of all evil. Needless to say, such a radical step would break backward compatibility. In which case, it would probably be better just to adopt XML or something else, and not invent yet another mechanism for network management. Next Steve presented the TRANSACTION clause concept to let implementations know what attributes are expected to be part of a transaction. CREATE-TRANSACTION {ipAddressData, ipAddressFlow, ...}. Needs to create transaction for an entire row, in the specified order. CREATE-OPTIONAL ... provides a list of optional transactional parameters. Most had an issue with forcing ordering. They believed that create and go is sufficient to perform this functionality w/o ordering constraint. The consensus was that it wasn't the ordering that matters, its dribbling out the objects over multiple atomic sets that is the problem currently. Some also had an issue with forcing some implementations to deal a "must not use" object in the transaction. The transaction clause appears to be useful vs. defval because there may be the need to combine variables across tables as part of the same transaction. Andy would like per high level object, elements of procedure. He just wants it clearly specified, it doesn't have to be in machine readable clause, could be in a description clause. Elements of procedure simply need to deal with the 90% cases, clearly describing the steps required to achieve a desired result. Next was a discussion on conformance. Much of the discussion related to enforcing conformance. DavidH suggested that we write a conformance test script at the end of every MIB (coincidently, scripts can be related to, or used to define, a use case as well). When applied to different levels of nesting there is an issue with status. What if deprecated objects exist in a type def? If its use as a variable is deprecated. What if it is deprecated as a type definition but its use is still current by some variable? ... The consensus was that this should simply cause a compiler to issue a warning. With respect to ACCESS, group consensus was that the equivalent of a MAX-ACCESS goes in a type definition that can be further constrained in the variable definition. Where as the C semantic only goes from the first level down, we want it to apply through all levels of nesting. There was some discussion on the scope of reuse/amount of reuse. The old smiv2 pointers don't allow you to point at a particular instance of an aggregate. How to distinguish between high-level object pointer vs. low-level instance pointer. Oid based id's currently point at first accessible column. In an aggregate composition, it is difficult to define what the first "column is", so we should define smiv3 pointers in a new TC. Terminating the object tree with a "0" will help describe where the base oid ends and the index portion starts. Bert mentioned he has seen zero's in the prefix before, but this is not allowed, so we shouldn't be overly concerned. This would help to define aggregate pointers. There is value keeping the oid structure because we can remain backward compatible with the SMI, and old mibs can point to leafs of new data structures. Though when getting to aggregate data types, vacm becomes a problem. Long discussion that the constraints imposed by the current protocol and charter dilute the possible solutions. David Harrington presented removing UDP limitation, port 161 restriction, 484 byte limitation, ASN.1, Security restrictions, Get/Set/oids, no meta objects, no rpcs, no create/edit/delete. There is the belief that OIDs are a big problem. For now we can move forward with data aggregation and aggregated instance naming. Preserve SMI compatible naming and we would like to get an SMI out the door that will still work with SNMPv3 & v1. Finally, we can add features into the language that would be useful for future protocol extensions. We just need to write guidelines that specify when these features will actually be used. Some things people would like: * Getting away from global descriptors that have to be less than 64 bytes long. * Indices can be longer than they are today * Allow multiple sets of indices * Introduce methods and/or elements of procedure * Support for transactions * A uniqueness clause that is different from indices * Remove those annoying little rules: what you are allowed to create, what you are allowed to change (revisit these). Eg. New conformance mib, once you identify the version at run time, no need to deprecate a mib. Not allowed to extend the range of an integer but you can extend enumerations. June 8, 2002 There was a discussion about allowing anonymous types for adding columns. People were comfortable with removing anonymous types IF one can add columns to the named types. Then you have a short binding after the type declarations. Randy cautioned that it can lead to readability problems, but the group consensus was that using a type means you will have to know what the type is. Next, Juergen lead a detailed discussion about how to merge the documents and key issues still to be addressed: General Issues: =============== - Should we change name of the converged version to SMIv3? The Group consensus was yes. - The agreed set of documents & authors: 1. SMIv3 Language Definition: Andy, Juergen, Frank 2. SMIv3 MIB Modules(core types): Juergen by July 1st. 3. SMIv3 Guidelines : Andy 4. Transition from SMIv2 : Andy, Chris 5. Capabilities MIB : Andy, by June 24th. 6. INET Modules (textual conventions) ? IETF deadline: July 1st for revised documents, June 24th for new documents. The list of specific items below were addressed during the meeting and the group consensus is reflected therein. Any specific objections to the group consensus items listed below must be sent to the sming mailing list. Keep objections specific. draft-ietf-sming-0x.txt: ======================== - Changed the data format from ASN.1 ExtUTCTime to the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD'. The group consensus was this is fine, but should clarify that this is UTC time. Reason for changing: The current smiv2 format is unreadable to most people. - The set of SMIng base types is not identical to the set of tagged types used in the SNMP protocol. SMIng base types: Integer32, Unsigned32, Integer64, Unsigned64, OctetString, ObjectIdentifier, Bits, Enumeration, Float* Consensus was this is OK and base types should not be imported. While derived types must be imported. The reason for the change: Make the type system consistent with up-to-date languages, also there should be no spaces in keywords because they make parsing a pain, and finally this gives us a consistent syntax for types. - [1] OctetString vs OCTET STRING and [2] (SIZE (1..20)) vs (1..20) and [3] '0a0f'h vs 0x0a0f. Group consensus was: 1. Use OctetString? OK 2. Use SIZE and RANGE? NO 2a. Use no SIZE and no RANGE? NO 2b. Use what we have now? OK (not consistent, but not worth fixing) 3. Stay with '0a0f'h : OK (because it is meaningful to BER encodings to have module 8, where as with c the encoding is fixed/same size. - Pointer as a base type rather than OBJECT IDENTIFIER. Syntax of Pointer restrictions. The room consensus was that Pointer should be a derived type so one has the flexibility to change it later. Distinction between Pointer and Identifier? (Examples are RowPointer and TDomain.) Group consensus was YES. Call Pointer Reference? No agreement. Pointer aligns with RowPointer, InstancePointer and does not clash with REFERENCE. Consensus was to go with the word "Pointer" - [1] ObjectIdentifier vs OBJECT IDENTIFIER and [2] dotted notation for OID values (including/excluding hexadecimal values) and module namespace separator. The group consensus was: 1. Use ObjectIdentifier keeping with reasoning discussed for types above. 2. Should we add even more stringified versions of these oid numbers? Rationale: Cut & paste between MIBs and SNMP implementations. Keep in addition the { ifIndex 1 }? Some confusion between { iso foo(2) 3 } and { iso 2 3 } and { iso foo 3 } ... No conclusions on point 2. - Hexadecimal Integer32/Integer64/Unsigned32/Unsigned64 constants ('0a0f'h vs 0x0a0f). The group was to keep using the quoted ''[hH] format. - Float32/Float64/Float128. People wanted to know why so many versions, why not just Float64? Objectives document says some kind of floating type support is required. - Enumeration vs INTEGER and syntax of enumerated values. What about things that have been coming up such as status for enumerated values or descriptions for enumerated values? Group consensus that using Enumeration is OK but do not add more stuff for named numbers. - Bits vs BITS and format of Bits named numbers. The group consensus was to use the smiv2 { ... } format. This is not broken. - Display formats are similar to SMIv2. There were however some comments some months ago to change them. The group consensus was to keep them as they are - though the usefulness of display hints is questionable - so keep it as is unless someone comes up with good proposals on the mailing list. - Comments. Allow // or keep the current -- with the arcane ASN.1 rules? Group consensus was mixed, rough consensus was to change to // because the reasoning was that more people are familiar with it (DavidH says -- comments often confuse readers). Others suggested using # for comments though this would confuse preprocessors. Given the varied differences of opinion, it is probably best to leave comments unchanged from the smiv2 style, possibly with the exception of just making them continue to the end of the line. - CAPITALIZE all KEYWORDS for improved SMIv2 look & feel? The group consensus was yes, keeps things similar to smiv2 look & feel. - Use a consistent syntactic structure " ..."? Juergen thinks SMI-DS also has changed into this direction. The group consensus was yes. - Where to anchor module meta information? Removed the LAST-UPDATED clause - use data of last REVISION instead. The group consensus was yes, remove the clause. - Multiple import statements? IMPORT IANAifType FROM IANAifType-MIB IMPORT mib-2 FROM SMIv3 IMPORT AutonomousType, Counter32, Counter64, DisplayString255, Gauge32, PhysAddress, RowStatus, TestAndIncr, TimeStamp, TimeTicks, TruthValue FROM SMIv3-TYPES IMPORT snmpTraps FROM SNMPv2-MIB With or without semicolons? The group consensus was to get rid of the semicolon. The group was also comfortable with having an IMPORT for every module. This makes cut-copy-paste operations easier. - Remove the extension statement? The group consensus was YES. - Change typedef to TYPE? SMIng allows DEFAULT clauses in TYPE definitions (which can be overwritten in ATTRIBUTE definitions). Do people feel comfortable with that? The group consensus was YES. - Change 'type' back to SYNTAX for improved SMIv2 compatibility? Group consensus was YES. - OBJECT-IDENTITY vs IDENTITY and late OID assignment. Change: foo OBJECT-IDENTITY ... => IDENTITY foo ... The group consensus was this change is OK, it is less verbose. - CLASS vs. STRUCT? The group consensus was to use STRUCT. - Should notifications be bound to aggregate types? There was much discussion, and other worlds have generic notifications such as a status change which can be applied to various objects (interfaces, physical entities, ...). People wanted to see the syntax to understand the usefulness of reuse here: STRUCT Status { ATTRIBUTE adminStatus ATTRIBUTE operStatus EVENT statusChange } STRUCT Interface { ATTRIBUTE status { SYNTAX Status } ... } NOTIFICATION Status.statusChange {} = base.32 Reuse might be useful, but details need to be worked out. - Discriminated Unions need to be added. The group consensus was strongly YES, as seen in the smi-ds proposal. - Arrays need to be added. The group consensus was YES, again as in the smi-ds proposal. - Remove inheritance? The group consensus was YES. Reason, adding aggregate/structured data is sufficient. Inheritance adds unwelcome complexity. - Implicit export of everything vs. "static" definitions? No agreement, this needs to go to the list because it is unclear what the benefit is outside of code modules. draft-ietf-sming-modules-0x.txt: ================================ - Modules need to be adapted to reflect the syntactic changes. The group consensus was yes. - 'nil' vs. 'zeroDotZero'. The group consensus was to go with what we have. - Merge contents of IETF-SMING-SNMP from draft-ietf-sming-snmp-0x.txt back into SMIV3-TYPES. The group consensus was yes. draft-ietf-sming-snmp-0x.txt: ============================= - TABLE vs. VAR ARRAY and SCALAR vs. VAR STRUCT? VAR would be enough in both cases since the presence of an INDEX in an aggregate allows to distinguish both cases. 1. TABLE vs. ARRAY - The group consensus was to use the word ARRAY because table already has a different meaning in DB land. 2. INDEX clauses might not always be bound to the aggregate type to allow index swapping. - the group consensus was yes. 3. VAR ARRAY vs. VAR UNION vs. VAR ... even though the second keyword is not really needed? The group consensus was that it may help the reader to see the second keyword. Side step: What is a VAR UNION? UNION Foo { ATTRIBUTE a { ... INDEX {} ... } ATTRIBUTE b } VAR UNION c { SYNTAX Foo INDEX {b} } This probably needs more thought. The group consensus was to syntactically go with the VAR notation for now. Also INDEX clauses (and similar beasts) are only allowed in ARRAYs. - Allow anonymous aggregated types? The group consensus was No. - Move revised version of introduction text from this document back into the main SMIng document. The group consensus was YES. - Other text needs also to be merged. Everything needs to be merged. YES - Define the rules for legal OID values? There has been ongoing confusion what the restrictions on the first two subidentifier are. The group consensus was YES, people wanted to cut & place into applications, define what is a legal subid. Should also clarify we are not using ASN.1 notation here. - Move mapping to today's SNMPv3 back to the main SMIng document. The group consensus was YES. - The notification statement probably needs some work (see above). Yes, see above. - SMIng does not distinguish anymore between OBJECT-GROUPs and NOTIFICATION-GROUPs. They are just GROUPs. Is this useful? The group consensus was that the distinction is not useful. - SMIng removes the common MODULE -- this module construction as the same effect can be achieved in other ways. Seems to be an odd construction, the group consensus was to either require the module name or get rid of it, making it optional helps nothing. - Would be nice to be able to define GROUPs for foreign definitions imported from other modules. - Would be nice to have simpler compliance statements. The group consensus was yes, this would be nice, but someone has to provide proposals. - The keywords EXTENDS and EXPANDS sound too similar and are thus a bit confusing. Use SPARSE-AUGMENTS since CISCO uses it in comments. SMI-DS does not provide EXTENDS anymore. Need to think about it. draft-ietf-sming-inet-modules-0x.txt: ===================================== - Definitions need to be adapted to new syntax. Yes. - Definitions must be aligned with recent changes in other MIBs. Perhaps the INET-ADDRESS stuff should not be done here but rather in a revision of the INET-ADDRESS-MIB since this is now actually being used? Yes.