Editor's Note: Minutes received 12/9/92 INTERIM_MEETING_REPORT_ Reported by James Davin/Bellcore Minutes of the SNMP Version 2 Working Group (SNMPV2) The SNMPV2 Working Group met October 5-6, 1992 in Knoxville, TN. The Chair, Bob Stewart, called the meeting to order at 9:05 AM and circulated the attendance roster. Agenda o Introductions and Housekeeping o Goals and Process - Credo - Organization - Stepwise Refinement to SNMP o Easy Questions o Proposals o Summary Introductions and Housekeeping All present introduced themselves. The schedule for lunch and breaks was established. Changes to the Agenda were entertained. Local arrangements for reading email were explained. Goals and Process Bob presented some slides outlining his vision of where the Group was going and how it would get there. Under the rubric ``Goals and Process,'' Bob introduced three topics: 1. Credo: As a ``credo'' for our collective work, Bob quoted a recent email statement by Dave Perkins as an illustration of the spirit he hoped everyone would bring to the discussion: ``to assist with creating a positive and long lasting solution for the community. This goal comes before any personal or company goals which I set aside when I communicate via EMAIL and attend IETF functions.'' 2. Organization: Bob noted that the Working Group was a chartered IETF Working Group. James ``Chuck'' Davin was appointed to take Minutes for this meeting. Bob stated that the Working Group would make decisions by discussion and consensus, both in meetings and 1 via email. Marshall Rose was appointed editor of the Working Group documents. Bob noted that the Group would rely on Marshall to make appropriate changes without detailed instructions, except in those cases where ``le mot juste'' was required to capture the consensus properly. It was agreed that Marshall would clearly indicate all changes to the Working Group documents by change bars. A question was raised about whether the change bars should indicate differences from the originally posted documents or the most recent document versions. This question was deferred, because, at the moment, the latest version is the original posting. It was noted that the Working Group Minutes would be available on-line in the usual IETF repositories. 3. Stepwise Refinement to SNMP: Bob explained what he meant by ``Stepwise Refinement of SNMP'' by presenting a slide with the following points: o Assume that SNMP is basically sound. o Widespread implementation. o Current level of technology, cooperation, understanding. o Choose improvements. o Maintain first principles. o High benefit-to-cost ratio. Bob identified the SMP proposal as the baseline documents from which the Working Group would proceed. He noted that there were 8 documents, and 4 implementations; these latter are to be regarded as supporting the Working Group and building confidence in its baseline; the implementations will not in any way constrain the decisions or directions of the Group. At this point, Marshall said that all four of the SMP proponents look forward to making implementation changes based on the work of the Group. Bob next noted the need to coordinate with the SNMP Security Working Group. He noted the pledge of timely cooperation by the relevant Area Directors at the Cambridge IETF meeting. He noted that the liaison function is neatly realized insofar as Keith McCloghrie is both one of the SMP proponents and the co-Chair of the SNMP Security Working Group. Bob concluded by saying that, although the Group would not delve deeply into security issues, it could not and would not ignore them completely. Bob identified the ``deliverables'' of the Group as a set of Internet-Drafts, revised according to the judgement of the Group, together with a recommendation to the IESG that these documents (possibly together with revised documents produced by the SNMP Security Working Group) define the next generation SNMP framework. Bob said that, assuming our ultimate agreement, the recommendation of the Group would be for Proposed Standard status for these 2 documents. Bob said that the schedule goal of the Group would be to finish up and, consistent with its Charter, to ``drop dead'' in the Spring of 1993 (shortly following the IETF plenary meeting, March 28 - April 2, 1993, in Columbus). A discussion of the schedule goal ensued: Marshall and Jeff Case emphasized the need for quick progress; Dave emphasized that haste should in no way compromise the openness of the process; Chuck emphasized that haste should not compromise the quality or thoroughness of the solution, because it is unlikely that revision of the standard framework will be undertaken again soon. The Group agreed that its schedule and pace must be governed by all of these considerations. Recognizing considerable consensus, currentt and from the Cambridge BOF, that the work should be completed in December, the Group deferred accepting that as possible for the end of the secong day. Easy Questions The focus of the Group turned to what Bob had identified as ``Easy Questions.'' In this part of the meeting, Bob encouraged people to raise what they regarded as ``easy issues'' about the proposed framework. Those that could be quickly resolved, would be dispatched in real time. Those that proved more complicated would be noted for later consideration by the Group. Tracy Cox raised the question of whether or not the row-set-and-create mechanisms currently specified would be mandatory. Jeff suggested that it should be mandatory for new MIBs. Tracy sketched some scenarios in which the specified mechanism was undesirable owing to time delays between the processing of a SET request and the actual effecting of the requested alteration. The Group agreed that this point was not simple and warranted further discussion. Tracy accepted an action item to present more detail and analysis of the relevant scenarios and propose a solution. Satish Joshi asked whether or not the SMUX should be part of the standard framework. Marshall said that the SMUX is not part of the framework, but elements in the current proposal (the ``or'' table in the SMP MIB) permit the use of SMUX or SMUX-like mechanisms. Chuck expressed a general concern about uncertain conformance requirements and raised the particular question of whether or not use of the AGENT-CAPABILITIES macro would be required of conformant implementations. Chuck proposed that the specification language be clarified to either make the macro a requirement or to omit it from the standard framework (as is now the case). Keith says that use of the CAPABILITIES macro would be required because of its relationship to the ``or'' table in the proposed MIB. Marshall argued that use of the macro should not be required because it was not relevant to all of the constituencies of the proposal: it includes vendor tools, user tools, and Working Group tools. Chuck said that the different requirements in each of these three contexts should be written down unequivocally. Jon 3 Saperia said that he favored requiring the AGENT-CAPABILITIES macro mandatory. After some discussion, it was proposed that the word ``should'' be applied to this issue. Chuck said that he found the use of ``should'' acceptable only if no other parts of the framework depended for their function or their unambiguous definition on the presence or use of this macro. The Working Group agreed to using ``should'' provided that this condition was met. Dave suggested that a list of ``required reading'' be prepared to help give everyone a common context for discussion. The Group agreed, and Dave accepted an action item to produce this list for inclusion in these Minutes (see attached). Dave also proposed that the new standards documents include a glossary of key terms. It was suggested that Marshall undertake this task and include the glossary in the introductory document. The Group agreed that Marshall would consider the effort involved and report back after lunch. Dave suggested that the Group prepare a detailed analysis of how well the baseline proposals addressed the concerns raised at the Atlanta IETF session on perceived deficiencies in SNMP. Jeff said that the basis of the current proposals was a list of problems he had maintained since 1988 that included the IETF session, a previous INTEROP BOF, and some additional items as well. Marshall said that preparing such an analysis would be too much effort. Jeff elaborated, saying that each item on the list was evaluated according to several criteria (e.g., compatibility with installed base, performance, impact in existing MIB object access methods). Peter Wilson raised the question of party proliferation. After brief discussion, this was identified as an issue for the SNMP Security Working Group, and further discussion of this topic was deferred for later in this meeting. Dave suggested that the Group consider a revision of the MIB-2 interfaces table. The consensus of the Group was that this was not in the scope of its Charter as it could be handled in the normal course of IETF business. The Group agreed to a recommendation that this work be pursued soon after the SNMP evolution work is completed. Dave raised a question about the definition of sysObjectId. It is ambiguous, but is also used by SNMP 2. Steve Waldbusser said that sysObjectId should identify the combination of software and hardware that makes up the managed system. Jeff agreed with Steve, and described various strategies used by OEM software vendors to address this question. Marshall said that the actual definition of sysObjectId is not ambiguous, but that the example text that follows it is bad. SMP assumes that sysObjectId names a protocol/MIB implementation but (not necessarily) the type of box (e.g., a bridge, router, etc.). Are we comfortable with this assumption? Do we want to legislate rules for assigning sysObjectId? 4 Proposal: either fix the ``or'' table so that it doesn't refer to the (arguably ambiguous) sysObjectId or else define a new MIB table that tells what MIB objects are supported. Action (Dave): prepare a proposal if needed. If the Group agrees that the interpretation of sysObjectId that is implicit in the baseline proposals is correct, then this consensus must be documented in the standard. After lunch, Bob suggested that the Group change its discussion mode to focus on brief discussions that would either result in quick resolution of topics or place those topics on a ``deferred issues list'' (see attached) for later discussion. There was a discussion of how Working Group consensus should be achieved, whether email or face-to-face meetings would dominate. Bob explained that neither would dominate. He would attempt to assure progress by posing straw conclusions and calls for consensus by requesting strong objections, but ultimately the Group would be governed by the soft principles that have been traditional in the IETF. Proposals The remainder of the day was spent in considering various proposals for amendment of the baseline documents. Bob presented the list of pending proposals collected from the mailing list: o Reliable Traps - Chuck Wegrzyn o Party Proliferation - Pete Wilson o Remove Counter64 Time Limit - Pete Wilson o NAME Clause - Pete Wilson o OID Optimization - Ilan Raab o Redefinition of ``Manager'' - Bob Stewart o Date and Time Textual Convention - Jon Saperia He asked the Group for others and added: o Miscellaneous changes from Jeff Case. o Miscellaneous changes from Chuck Davin. o Miscellaneous SMI changes from Dave Perkins. o Ideas on Get Bulk OID compression from Satish Joshi. o Two ideas from Robert Snyder. - Identifying MIB objects with constant values. - Contents of Set Responses. o Get Bulk OID Compression: Satish spoke about his ideas on Bulk Retrieval. He suggested compressing the OIDs in the varbind list of responses to Bulk Retrieval requests. He observed that the OIDs 5 in the 2nd and subsequent repetitions in a response could be abbreviated. Compression could occur in the context of the original request or in the context of the preceding varbind. Satish noted that this scheme presents no compatibility problem because existing agents don't implement the new Get Bulk operation. General question: is it worth it? Marshall said that there are easier ways to save OID bytes. Jeff observed that we hate the byte-skimping of the ASN BER, and asked why we would want to repeat that mistake. He also noted that a growing number of MIB tables are indexed by OID values, and so the savings in those cases would be minimal. Satish said that retrieval of very large tables (e.g., an RMON traffic table with 10000 entries, a bridge table with 8000 entries, or a Token Ring table with 4000 entries) would benefit significantly from this strategy, even if the savings for smaller tables were somewhat less. The Group agreed that Satish and others should perform some real measurements that include the CPU costs (as well as the bandwidth savings) of this approach. It was noted that compressed OIDs could not really be encoded with ASN.1 OID Tags and would have to be transmitted using an additional ASN.1 type. o NAME Clause: Peter Wilson led a discussion for about 30 minutes on the addition of a NAME clause to the OBJECT TYPE macro. Cheryl agreed with the proposal, but thought that the length of any such field should be less than 15 bytes. Bob suggested that it be called a LABEL clause, not NAME clause, to better reflect its true nature. Ken Key raised the issue of what language the LABEL information should be in. Dave P. suggested that information that is primarily an aid for management stations should be in separate documents. Chuck echoed Dave's suggestion, recalling his earlier suggestions to cleave the framework in this way. The Group concluded that the NAME clause should not be introduced because one could get the same effect by well-chosen object descriptors. However, it was also agreed that this sort of information might be included in macros exclusively for management stations. Dave Perkins accepted an action item to explore the feasibility of such a notation. Peter Wilson then offered a proposal that the time limit associated with the use of the 64-bit counter type be excised from the baseline documents. A router implementor argued against the proposal, arguing that critical code paths can't afford lots of double precision math. Cheryl found the time limit desirable, given MS polling requirements. Jeff spoke of hardware barriers (e.g., need to lock the bus) that 6 make broad implementation of 64-bit counters difficult. Peter argued a broad need for big counters in hierarchical management systems (bigger numbers at higher levels in the hierarchy). Marshall noted that aggregation counts at the higher levels are semantically different from the raw ``leaf'' counts on which they are based. Keith followed this by saying that we need appropriate MIBs to do effective hierarchical management and limit the proliferation of 64-bit counters. Steve Waldbusser noted that effective MS support for 64-bit counters may be a long time coming. Wilson noted that constraining the use of big counters might limit the effective lifetime of the new framework. Dave noted the role of big counters in the work of IEEE. The consensus of the Group was to leave the restriction as it is. o New Textual Convention: the Group took up Jon Saperia's proposal for a new Textual Convention for expressing dates. The Group spent some time tweaking the details of this proposal. Bob asked whether display hints imply leading zeros. Keith said no, but there might be an ambiguity in the definition of display hints that needs to be fixed. Issue: where is byte ordering on the network defined? (i.e., are Textual Conventions that imply a byte ordering part of the mgr-agent contract or just a mgr aid?) In part to avoid the question of leading zeros, the Group agreed that tenths of seconds was adequate resolution for this proposal and abandoned microsecond resolution. Mike Davison suggested augmenting the display hint notation to provide for real field precision. Jon accepted an action item to post the agreed, amended proposal to the mailing list. o New MIB Object Clause: Robert Snyder proposed a new MIB object clause that identifies an object as having a constant value: a manager need only retrieve it once. Marshall asked what macro it should go in. Chuck suggested that this information was really more of a manager aid than an essential property of a MIB object. Robert Snyder accepted an action item to go examine some MIBs and report back on these questions and on the number of cases in which this idea would yield actual benefits. The remainder of the day was spent reviewing a list of proposed changes introduced by Jeff Case (see attached). Unless otherwise noted, the 7 Group accepted all of the changes on that list. Item 1 on the list proposed that the term ``SMP'' be purged from the documents. The Group agreed, stipulating that the terms ``SNMP-1'' and ``SNMP-2'' be used as appropriate, instead. Items 4 and 5 could not be quickly resolved and were deferred. Item 11 was tentatively approved. Davin took an action to investigate the use of readOnly in deployed implementations. Item 14 was agreed, but the Group stipulated that the additional information would somehow be part of the appropriate macro(s). Item 21 was not quickly resolved and was deferred. Item 22 was agreed but the curly braces removed from the replacement text. Item 24 was tentatively agreed, but there was some reluctance to accept so significant a change without more deliberation. Item 26 was agreed. Davin took an action to investigate the use of readOnly in deployed implementations. The first day of the meeting concluded at 17:26. DAY 2 The Group continued its discussion beginning at 9:00 AM. Robert Snyder raised the question of the meaning of a negative value with type TimeInterval. The Group agreed that a range should be added to the definition of that type. Bob Stewart offered a proposal that would clarify the definition of ``manager'' and ``agent'' in the framework: A ``manager'' is any active network management component that observes or controls one or more network devices, whether locally through implementation-specific interfaces or remotely via SNMP, with or without a human interface. Such a manager may use any subset of the SNMP manager functions. Definition of ``agent'' is unchanged. Jon Saperia objected to this text, arguing that we don't want to have a ``roll-your-own'' definition of a manager. E.g., does a compliant ``manager'' need to support Sets? Discussion of conformance issues and the question of whether a manager requires a user interface ensued. Two possible problems were identified with definitions of a manager: 1) Too restrictive, excludes useful products 2) Doesn't contribute much 8 to collective understanding so that we have a common basis for addressing issues (like confirmed traps in ``agents''). E.g.: Manager Agent master slave responsible not responsible Bob accepted an action item to propose appropriate text, but the current text will stand until new text is produced and agreed. Chuck accepted an action item to attempt a glossary. Robert Snyder withdrew his proposal about different values in the response to a Set request. Bob Stewart proposed to remove varbinds from responses to Sets altogether, citing the bandwidth savings. Chuck seconded this idea, citing the improved security that would result: configuration errors would be less likely to expose private data. Peter Wilson and Robert Snyder opposed this change because they preferred the option of using the varbinds in a response to a Set to carry other information. Marshall said (incorrectly) that the security benefits of this change would require configuration of an additional party. The Group agreed that responses to Set requests should remain as currently specified in the baseline documents. At this point (10:22 AM), the Group took a brief break. When the Group resumed at 10:40, Dave Perkins led a discussion on a list of proposed changes to the SMI that he prepared. Dave actually submitted two separate lists of issues/suggested changes. One list covered the textual conventions SMP document. It had 10 numbered points. The other list covered the SMI SMP document. It had 50 numbered points. In the 2 days at Knoxville, Dave was allocated approximately 2-3 hrs to go over the lists. Only 8 items from the SMI list were covered. Those items are included in the minutes. The meeting attendees were given a paper copy of the lists. An electronic copy is available from the archive at thumper.bellcore.com. Dave plans to update the lists and submit them for consideration at a future meeting of the WG. 9) All items should include a required DESCRIPTION clause, an optional REFERENCE clause, and a required STATUS clause. In response to this item, Jeff asked how a COMPLIANCE or CAPABILITIES macro could have a ``STATUS.'' Dave responded that the function of this clause was to mark OIDs as eternally assigned but no longer ``important.'' It is a way of signaling management stations that it is OK to forget a particular OID assignment. The Group agreed to this change. 9 11) The SMI needs to specify conventions on things like uniqueness of names, max length of names, allowed characters in names. There was an extended discussion of the uniqueness and form of object descriptors. Dave modified his proposal to be that all the rules governing the form of object descriptors be gathered into one place in the document. Dave proposed that the SMI explicitly require counter names to be plural (not simply to end in ``s''). The Group agreed. Dave proposed that object descriptors have a maximum length. The Group agreed to the value 64. Bob Stewart took an action to poll the mailing list to determine if any object descriptor in any extant MIB is longer. Dave proposed the object descriptors in standard MIBs should be unique across all standard MIBs; that vendor MIBs should be encouraged to preserve uniqueness of object descriptors. Bob Stewart objects to the exception for vendors, arguing that, since a management station must cope with all MIBs including vendor MIBs, it cannot take advantage of the uniqueness property. So, why make the restriction at all? Robert Snyder said that vendors could not in practice avoid name collisions with all standard MIBs, past or future, or all MIBs from other vendors. Mark Kepke echoed this sentiment and pointed out that, in large companies, vendors may not even be able to avoid collisions across the MIBs of a single enterprise. The Group agreed that the baseline text should require that object descriptors be unique across all standard MIBs and that vendor MIBs should not be addressed. The Group agreed that the editor will propose text that encourages vendor MIBs to conform to the same rules that constrain standard MIBs. As a result of this discussion, the Group seemed to agree that object descriptors are not an essential part of a MIB object definition and may be altered from time to time for convenience without deprecating the associated MIB object. Bob Stewart took an action item to poll the mailing list for opinions on this, changing names in enumerations, and adding to enumerations. At this point, it was noon, and the Group broke for lunch. When the Group resumed at 13:30, Dave Perkins continued his presentation of proposed changes to the baseline SMI document. 1) The OBJECT-TYPE macro needs to be replaced by two macros. The first is to be used only for ``leaf objects'' or ``management information objects''. The second is to be used to define the two grouping objects which have been called ``tables'' and ``rows''. 10 2) The following is the suggested replacement for the ``OBJECT-TYPE'' macro to define management information objects: actual MACRO was here 3) The following is the suggested replacement for the ``OBJECT-TYPE'' macro to define table and row objects: actual MACRO was here Dave presented Items (1)-(3) in the Specific Comments section of his list. The thrust of these changes was to use a new macro for the definition of conceptual rows in the MIB and to remove some of the more ``tabular'' aspects of the current OBJECT macro as they would be replace by this new notation. Peter Wilson objected to these changes because the cost of rewriting parsers is not acceptable when the benefits of the new notation are not clear. Dave said that the benefit of this approach is that it precludes mistakes in MIB writing that he has observed in his compiler work (e.g., mismatches between the types in a SEQUENCE grouping and the the types in the corresponding object definition). Peter and Marshall argued that the Group should reject this change: because of our need for widespread MIB objects, we should want to minimize (a) the cost of upgrading MIB compilers from V1 to V2 and (b) the cost of upgrading V1 MIBs to V2 (although it had been stated earlier in the day that upgrading of MIBs was neither necessary nor desirable if done independently of other factors in the MIB lifecycle). The Group agreed that the proposed changes were not necessary. Dave Perkin proposed a change to the handling of DEFVALs described at the end of Item (2) in the Specific Comments section of his list of proposals. This change would permit a more readable way of expressing DEFVAL values whose type is defined by a Textual Convention. Bob Stewart asked if the Group considered itself restricted to the expressiveness of ASN.1 to satisfy its needs? The Group provisionally agreed to this proposal, provided that Dave can find a legal ASN.1 notation for accomplishing it. 28) The replacement for the OBJECT-TYPE macro has a replacement for the allowed values in the DEFVAL clause. The change is to accomplish the following: * OIDs should be restricted to a name. The curly bracket syntax (ie ```` ... ''') should not be allowed. This would restrict the values to the names of defined OIDs. * The replacement (if valid ASN.1) solves the problem of constant values like IP addresses that can't be expressed in ASN.1. The Group agreed to Item 28 on Dave's list. Dave proposed that the MaxPart and AvailPart of the macro defined in Item 3 on his list be added to the OBJECT macro in the baseline 11 documents. The intended usage of these clauses is to identify related MIB objects whose value indicates the location of available ``slots'' in a MIB table whose implementation may be a memory array. After some discussion, it was suggested that, instead of using multiple objects to indicate the ``available entry,'' a single object with OID syntax should be used. Steve Waldbusser commented that the ``RMON polka'' is not an expensive '' strategy and solves a superset of the problem solved by this mechanism. He elaborated on the relevance of the available entry problem to small tables that must be packed (owing to implementation as memory arrays). Bob proposed that the max entry, available entry, and num entry clauses are essentially aids for management stations and should be dealt with in that context (i.e., not in this Working Group). The G roup agreed with this suggestion and the aforementioned clauses will not be included in the documents. At this point, the chair began the identification of residual issues and discussion of future schedule and meetings. Bob said that, in order to encourage people to air proposals early, he would promise on the mailing list that proposals posted by Monday, 9 November would be assured time for discussion at the November meeting, while others might only be considered schedule permitting. The Group generally approved of this plan. Bob emphasized the need for doing ``homework'' before the next meeting. An interim meeting date was set for 14 December in Atlanta. This date will only be used if the Group needs it. Marshall said that new Internet Draft documents reflecting the discussions at this meeting would be posted by Thursday. The Group agreed that its work should be completed in December. If work can not be completed at the Washington IETF, the Group will hold a meeting at Georgia Tech in Atlanta. The suggested date for this meeting was 14 December. Bob proposed that the deferred discussion on party proliferation be referred entirely to the SNMP Security Working Group. Keith accepted and the Group did not object. The meeting closed with a brief review of the DISPLAY-HINT discussion in particular and the more general question of whether the Group should focus on technology that is primarily an aid to managers or leave that for future work. Chuck raised the question of whether display hint should be broken into two parts: (1) representation on the wire and (2) display format hint for a user interface. The consensus was that the current text would stand for now pending any future proposals on this question. 12 The meeting adjourned at 4:00 PM. ##### Deferred Issues List 1) Should Textual Conventions be part of the SMI? 2) Is the Textual Conventions macro consistent with ASN.1 subtyping? 3) Further work on the DISPLAY-HINT clause is needed. 4) Conformance issues need further definition, esp. with respect to interactions between SNMP V1 and SNMP V2. 5) Restart Domain and Entity Domain require further discussion. 6) Ommision of readOnly(4). Action item (Chuck): post an email query to the relevant mailing lists asking for information about the use of readOnly in deployed implementations. 7) Can MIB objects be in zero compliance groups? I.e., can there be ``dangling objects''? Action (Bob): report on this issue. 8) Are the row manipulation mechanisms adequate to address scenarios in which there may be significant time delay between an SNMP row manipulation and the alteration of the underlying management state? Is operation in such scenarios a requirement? Action (Tracy): propose an answer to these questions. ##### Proposed Changes to SNMP Version 2 Documents: October 5-6, 1992 A Contribution to the IETF SNMP2 Working Group Jeff Case, Keith McCloghrie, Marshall Rose, Steve Waldbusser 1. All documents: throughout Lose the term SMP 2. Transport Mappings: throughout Document should use consistent naming of domains, e.g., smpUDPdomain, smpOSIclnsDomain, smpDDPDomain all should be changed to Domain 3. Transport Mappings: page 5 In comment prior to SmpOSIAddress, change ``string or (up to'' to ``string of (up to''. 4. Transport Mappings: page 12 Add new sentence at end of Section 8.1: 13 Because the address associated with this transport mapping is internal to the agent, an SMP entity acting in a manager role cannot directly communicate with a party using this transport mapping. As such, communications are accomplished using the partyProxyFor object of a party which uses a transport mapping with an externally accessible address. 5. Transport Mappings: page 13 Add new sentence at end of Section 9.1: Because the address associated with this transport mapping is internal to the agent, an SMP entity acting in a manager role cannot directly communicate with a party using this transport mapping. As such, communications are accomplished using the partyProxyFor object of a party which uses a transport mapping with an externally accessible address. 6. Transport Mappings: page 15 < These restrictions apply to all aspects of ASN.1 encoding, < both for the protocol data units and the data objects they < contain. > These restrictions apply to all aspects of ASN.1 encoding, > including the message wrappers, protocol data units, and the > data objects they contain. 7. Transport Mappings: page 15 < (2) When encoding the value field, the primitive form is used < whenever possible. > (2) When encoding the value field, the primitive form shall be > used for all simple types, i.e., INTEGER, BIT STRING, OCTET > STRING, and OBJECT IDENTIFIER (either IMPLICIT or explicit). > The constructed form of encoding shall be used only for > structured types, i.e., a SEQUENCE or an implicit SEQUENCE. 8. Transport Mappings: page 16 Example needs to include a length field which is not expressed in the minimum number of bytes. 9. Transport Mappings: page 16 Remove extraneous comma in mapping example: ``NULL } },`` to ``NULL } }'' 10. PROTO: page 6 Start a new paragraph after the first sentence in (2). (The paragraph starts with ``The former is...'' 11. PROTO: page 10 Remove readOnly(4). 12. PROTO: page 21 Delete the clarifying ``implementation strategies'' paragraph from the description of the awesome getBulk operator ... it only caused confusion. 13. PROTO: page 24 Add at the end of third paragraph in Section 5.2.4: A compliant SMP entity acting in the manager role must be able to 14 properly receive and handle a Response-PDU with an error-status field equal to noSuchName(2) or badValue(3). (See Section 4.1.2 of [coex].) 14. SMI: (distributed) Every MIB document (including trap documents), every compliance document, and every capabilities document must have a required preamble title block which describes the version number, last revision date, originating organization, and contact information. 15. SMI: pages 6 and 23 Clarify the meaning of mandatory in the STATUS clause, perhaps by changing it to a word which parallels ``obsolete'' and ``deprecated'' and which ref* *lects the role shift of the STATUS clause. Candidates include ``current'', and ``effacious''. 16. SMI: page 23 Add the following parenthetical clarification: If any columnar object in a conceptual row has ``read-create'' as its maximal level of access, then no other columnar object of the same conceptual row may have a maximal access of ``read-write''. (Note that ``read-create'' is a superset of ``read-write''). 17. SMI: page 25 accessible''. However, a conceptual row must contain at least one columnar object which is not an auxiliary object (i.e., the value of the MAX-ACCESS clause for such an object is something other than ``not-accessible''). The last line should be ``read-only'' or ``read-create'', i.e., it can't be ``read-write''. 18. SMI: page 27 Add new paragraph before last paragraph at end of Section 4.8: For example, a MIB designer might wish to define additional columns in an enterprise MIB which logically extend a conceptual row defined in a standard MIB. The standard MIB definition of the conceptual row would include the INDEX clause and the enterprise MIB would contain the definition of a conceptual row using the AUGMENTS clause. 19. SMI: page 27 < The value of an instance of the named object is the (exact or < approximate) number of conceptual rows. > The value of the one and only instance of the named object is the > (exact or approximate) number of conceptual rows. 20. SMI: page 27 < The DEFVAL clause, which need not be present, defines an < acceptable default value which may be used when an object < instance is created at the discretion of the SMP entity acting < in an agent role. 15 > The DEFVAL clause, which need not be present, defines an > acceptable default value which may be used at the discretion > of an SMP entity acting in an agent role when an object instance > is created. 21. SMI: page 32 Add new sentence end of Section 5.1 An object may be named in zero, one, or many groups. 22. SMI: page 49 < SYNTAX INTEGER { maxttl(255) } > SYNTAX INTEGER { (255..255) } 23. MIB document page 20 DESCRIPTION ``The number of traps which have been sent to a particular SMP party, since the last initialization of the SMP protocol entity, or the creation of the SMP party, which ever occurred most recently.'' ::= { smpTrapEntry 1 } which ever --> whichever 24. MIB 2 and MIB. Deprecate the SNMP subtree. Delete the entire smpInOut group. Replace them with the following new variables in two groups as follows (all are similar to other variables previously defined): Group 1: (mandatory for all entities) snmpInASNParseErrors snmpEnableAuthenTraps snmpInUnknownSrcParties snmpInUnknownDstParties snmpInBadAuths snmpInNotInLifetimes snmpInWrongDigestValues snmpInBadOperations snmpInSilentDrops Group 2: (optional, only for entities which support SNMP Version 1) snmpInBadVersions snmpInBadCommunityNames snmpInBadCommunityUses 25. M2M: Page 7: Remove ObjectName from IMPORTS clause Page 7: Add InstancePointer to IMPORTS clause for SMP-TC Page 10: (2x) Change ObjectName --> InstancePointer 26. Coex: page 9 < `badValue', or `readOnly', the proxy agent must not 16 > or `badValue', the proxy agent must not 27. Textual Conventions: page 8 in enumerations and associated text < underCreation(1) < underDestruction(2) < underModification(3) < active(4) > active(1) > underConstruction(2) > underModification(3) > underDestruction(4) ##### Attendees Steve Alexander stevea@i88.isc.com Uri Blumenthal uri@watson.ibm.com Jeff Case case@cs.utk.edu Tracy Cox tacox@sabre.bellcore.com James Davin davin@bellcore.com Michael Davison davison@fibercom.com Taso Devetzis devetzis@bellcore.com Gary Haney hny@ornl.gov Matthew Hecht mhecht@cs.utk.edu Susan Hicks hny@ornl.gov Satish Joshi sjoshi@synoptics.com Mark Kepke mak@cnd.hp.com Kenneth Key key@cs.utk.edu Michael Kornegay mlk@bir.com Deirdre Kostick dck2@sabre.bellcore.com Cheryl Krupczak cheryl@cc.gatech.edu Robert Lushbaugh lus@ornl.gov Keith McCloghrie kzm@hls.com David Minnich dwm@fibercom.com David Perkins dperkins@synoptics.com Shawn Routhier sar@epilogue.com Marshall Rose mrose@dbc.mtview.ca.us Jon Saperia saperia@tcpjon.ogo.dec.com Robert Snyder snyder@cisco.com Bob Stewart rlstewart@eng.xyplex.com Maurice Turcotte dnmrt@interlan.com Steven Waldbusser waldbusser@andrew.cmu.edu Bert Wijnen wijnen@vnet.ibm.com Peter Will will@isi.edu Steven Wong wong@took.enet.dec.com Chris Young cyoung@ctron.com Kiho Yum kxy@nsd.3com.com 17