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