coex draft
"David Levi" <[email protected]> Fri, 28 Feb 2003 14:29:49 -0800
| Newsgroups | gmane.ietf.snmpv3 |
|---|---|
| Message-ID | <[email protected]> |
Hi All, Here is a change-bar version of the new coex draft (this is not the official version). This will be submitted tomorrow to the ID editor. Also, I've attached a list of responses to the lists of proposed changes. -Dave ------------------------------------------------------------------------ David B. Levi Nortel Networks [email protected] Voice: +1 865 686 0432 ESN: 455-6004 ------------------------------------------------------------------------
coex.cb
(application/octet-stream, 128.7 KB) - not displayed
changes.txt
(text/plain, 39.9 KB)
------------------------ The following edits have been made to the Coex draft, to be circulated soon for WG Last Call. ------------------------ ------------------------ Changes based on "Re: WG last call: Coex draft spelling check" from Tom Petch [mailto:[email protected] <mailto:[email protected]> ] sent Sunday, December 29, 2002 8:08 AM > > s1) There should not be a comma before the words "and", > "or" in a list > > of items (I was taught). ... No. The "serial comma" (comma after SNMPv2 in "SNMPv1, SNMPv2, or SNMPv3") is a) legal and b) preferred according to the Chicago Manual of Style. Removal doesn't clarify anything, no change. > > s2) There are three "e-mail" (which I regard as correct) and seven > > "email" (which I do not) in 5.4 and 10. I suggest the latter be > > brought in line with the former. I have not flagged these > separately. Nit. No change. > > s3) J Case's organisation is given four times in Section 9 as > > " SNMP Research,Inc." > > which I suggest should be > > " SNMP Research, Inc." Nit. No change. > > S4) Copyright Notice > > **/(2001)/(2002)/ Changed to 2003. > > S5) In the running title, I suggest **/versions/Versions/ No. "versions" not intended to be proper noun. > > s6) Table Of Contents > > I assume the errors here will be corrected automatically when the > > titles of the sections are themselves corrected (corrections below) Correct; no specific edits made to TOC. > > s7) 1. Overview > > "The purpose of this document ... > > termed the SNMP version 2 framework (SNMPv2), **(comma ok here) > > and ..." Non-change. > > > > s8) "- Approaches to coexistence ... > > as well as **//the/ behaviour of proxy implementations. Nit. No change. > > s9) "- The SNMPv1 Message Processing Model and Community-Based > > Security Model, which **/provides/provide/ mechanisms ..." > > for adapting SNMPv1 > > into the View-Based Access Control Model (VACM) [20], > > **/is/are/ > > documented in section 5 ... " > > (models plural) No. Wrong reading of what is plural. > > s10) 1.1. SNMPv1 > > "- STD 16, RFC 1212 [3] which defines a more concise > > description > > mechanism, which is **/wholly/wholy/ consistent with..." No. Correct spelling is "wholly" according to US English. > > s11) " .. 'SMIv1' is used. This term **/generally refers/refers > > generically/ to the ..." Nit. No change. > > s12) 1.2. SNMPv2 > > " ...(RFCs 2578, 2579, and 2580)" > > (I would prefer /RFC 2578, RFC 2579 and RFC 2580/; the > reference is > > more to a document which has the title RFC 2580 as opposed to the > > 2580th item in a list called RFC). Nit. No change. > > s13) 1.3. SNMPv3 > > (Not checked, section needs replacing) No change from Tom. RFC numbers updated to 341x series. > > s14) 2.1.1. Object Definitions > > This contains three numbered lists (of MUSTS, SHOULDs/MAYs then > > MUSTs again) all enumerated from one. This makes any references to > > items in the lists (eg from a working group debating the > changes they > > need to make) clumsy. >> I suggest that either the three lists have a > > single enumeration or, which I would prefer, the section is > split into > > two with the MUSTs in one, the rest in the other, each with an > > enumeration starting from one. Done. > > s15) (2) "The MODULE-IDENTITY macro ... any **/IMPORTs/IMPORTS/ > > statement" > > > > s16) (12) "For any object containing a DEFVAL ... (OBJECT > > IDENTIFIER**/S/s/) ..." > > > > s17) (13) "One or more **/OBJECT-GROUPS/OBJECT-GROUPs/ MUST be > > defined" No change. > > s18) 2.1.2. Trap and Notification Definitions > > (5) "The value of an invocation ... not an INTEGER, > **(comma ok > > here) and MUST ..." OK. Non-change. > > s19) 2.3. Capabilities Statements > > "all leaf objects which are subordinate to the subtree > and have a > > STATUS clause value of mandatory are deemed to be INCLUDEd." > > What is the past tense of INCLUDES? INCLUDESed? ugly. > > Perhaps change to /are implicitly deemed to be the subject of an > > INCLUDES clause/ (but I do not know the INCLUDES clause > well enough to > > be sure 'subject' is the right noun). No. Makes less clear. Readers understand "INCLUDEd". > > s20) 3. "Translating **/Notifications Parameters/Notification > > Parameters/" > > (since that is the phrase defined in the next paragraph) No change. > > s21) "This section describes how parameters ... > > **/refered/referred/ to in this document ... > > is **/refered/referred/ to in this document ...." Done. > > s22) 3.1. Should the OIDs listed under 'snmpTrapOID.0' > start .1.3.6 as > > opposed to 1.3.6? No. Wrong. > > s23) 5) "The SNMPv2 variable-bindings ... bindings will be appended > > ..." > > (Given that appended means add at the end, whereas > prepended means > > add at the beginning and added means add somewhere, is appended the > > right term? I think I see prepends not appends). No, the additional variable binding must be at the end of the list, in order to conform to RFC 3416, section 4.2.6. > > s24) 3.2. "(1) The SNMPv1 enterprise parameter SHALL be > determined as > > follows: > > the SNMPv2 snmpTrapOID value with the last **/2/two/ > > sub-identifiers..." > > (usual to spell out small numbers) No. Nit. > > s25) (2) "... and the notification is to be sent over IP .." > > (Should this specify IPv4 or is IPv6 too remote to consider > > here?) No. Specifically should NOT state IPv4. > > s26) (3) Same comment as s22) Same answer: No. Wrong. > > s27) 4. "There are two basic approaches ... > > with any **/mono-lingual/monolingual/ implementation, > regardless > > of the SNMP version > > supported by the **/mono-lingual/monolingual/ implementation" > > (multi-lingual but monolingual) No. Nit. > > s28) "Proxy implementations provide a mechanism ... > > This allows network elements which support only a single, but > > **/different/not the same/, > > SNMP version to communicate with each other" > > (different needs 'SNMP versions' plural whereas 'not the > same' takes > > the singular) No. Nit. > > s29) 4.1.2.3. Processing An SNMPv1 GetRequest > > "...or an **/SNMP/SMI/v2 syntax that is unknown to > **/SNMP/SMI/v1 > > ..." > > (From the earlier sections eg section 2, syntax is part of the > > SMI not SNMP) Wrong; different levels of processing. > > s30) 4.1.2.4. Processing An SNMPv1 GetNextRequest > > (Two number lists again; I suggest splitting this into > 4.1.2.4.1 > > for errors and 4.1.2.4.2 for noError) No. Clear enough to readers/discussion by reference. > > s31) 4.1.2.4. Processing An SNMPv1 GetNextRequest > > "When processing an SNMPv1 GetNextRequest ... the following > > procedures MUST be followed when **/an// SNMPv2 access to > MIB data is > > called as part of processing the request. ... > > Or, perhaps better > still, **/an > > SNMPv2 access to MIB data is called/an SNMPv2 access routine is > > called/ access routine is the phrase used in the next section) Done. > > s32) 4.1.2.4 1) **/not in view/not-in-view/ > > (for consistency with 4.2.2) Nit. No change. > > s33) "Otherwise, if the access to MIB data ... > > (2) "... (**/there may be more than one,/ if there is > more than > > one,/ it is an implementation decision ..." Done. > > s34) (3) "- The variable binding list of the response SHALL be > > **/composed/generated/ > > from the data as it is returned by the access to MIB data" > > (composed of, generated from) No. Nit. > > s35) 4.1.4. Notification Receiver > > "There are no special requirements **/of/for/ a notification > > receiver" Nit. No change. > > s36) 4.1.4. Notification Receiver > > "However, an implementation may find it useful ... to > > **/request/establish/ whether ..." > > (I do not 'request whether'). No. Terminology correct for protocol layers & requests to lower layers. > > s37) 4.2. Proxy Implementations > > "A proxy implementation ... subject to size > > **/contraints/constraints/ as defined" Done. > > s38) 4.2.1. Upstream Version Greater Than Downstream Version > > "- If a GetBulkRequest-PDU is received and must be forwarded > > using the SNMPv1 message version, the proxy > forwarder SHALL > > set the non-repeaters and max-repetitions fields to 0" > > (the proxy forwarder is setting fields in an SNMPv1 > PDU where the > > non-repeaters and max-repetitions fields do not exist - I suggest > > error-index and error-status instead) Reworded as: If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU. > > s39) "- If a GetResponse-PDU is received whose > error-status field has > > a value of **/'tooBig,'/'tooBig',/ .... contains an > > error-status field > > with a value of **/'tooBig,'/'tooBig',/ > > and change the error-status to /'noError.'/'noError'./ > > (move punctuation outside the quotes) Nit. No change. > > s40) 4.2.2. Upstream Version Less Than Downstream Version > > "- If a GetResponse-PDU is received ... the proxy > MUST generate > > an alternate response > > PDU.." > > (I am not clear if alternate means a replacement PDU or an > > additional PDU; alternate is famously a word whose American sense is > > not its English sense but I find neither sense clear here) No change made. "alternate" meant in replacement sense. I think readers understand it. > > s41) "- If a GetResponse-PDU is received in response to a > > GetNextRequest-PDU ..." > > "- If a GetResponse-PDU is received which contains an SNMPv2 > > (in both cases you should add > > /and the message would be forwarded using the SNMPv1 message > > version/ > > as in other paragraphs ... Done. > > s42) 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security > > Model > > (this is the first use of the acronym MP and so it should be > > expanded) Changed text in section 5 to say "Message Processing (MP)". > > s43) 5.2.1. Processing An Incoming Request > > "In RFC1157 [2], section 4.1, item (3) for an entity which > > receives a > > message, states ..." > > (RCFC1157 section 4.1 has two numbered lists both containing an > > item 3) which is why this reference is a little clumsy! I suggest > > /In section 4.1 of RFC1157 [2], item (3) of the list of > actions (for > > an entity which receives a message) states / No. Clear from context. > > s44) "... parameters are passed to the 'desired authentication > > **/scheme.'/scheme'./ > > s45) "The desired authentication scheme .. using the > > processIncomingMsg ASI) > > (First use of ASI - needs expanding) > > > > s46) "- If the snmpCommunityTransportTag is an empty > string ... when > > checking whether > > **//or not/ the transportDomain ..." > > ('whether' needs an alternative) Above 3 changes: No. Nit. > > s47) "- The pduVersion, which should indicate an SNMPv1 version PDU > > (if the message version was SNMPv2c, this would be an SNMPv2 > > version PDU)" > > (seems clumsy - either it should or it should not be an SNMPv1 > > version PDU; how about > > /which will indicate an SNMPv1 version PDU (or an > SNMPv2c version > > PDU where appropriate)/ No change. > > s48) 5.3. The SNMP Community MIB Module > > "When checking whether **//or not/ a transport address matches No. Nit. > > s49) snmpCommunityTransportTag OBJECT-TYPE > > "This object specifies a set of transport endpoints which > > **/are/is/ used" > > (a set is singular) Does not clarify. No change. > > s50) "In either case, if the value of this object has zero-length, > > transport endpoints are not checked when authenticating messages > > containing this community string, nor when generating > notifications." > > (does the qualification 'containing this community > string' apply > > to generating notifications? I think it does in which case I would > > reword to > > /transport endpoints are not checked either when > authenticating > > messages or when generating notifications, each of which > contain this > > community string./ No. Specifically not checked when generating Notifications. > > s51) "If a management request containing a community string ... > > the request is deemed **/unauthentic/inauthentic/" Don't care. > > s52) snmpTargetAddrExtTable OBJECT-TYPE > > "The table of mask and mms values ... > > (the first use of 'mms' - should be expanded) Done. > > s53) snmpTrapAddress > > "The value of the agent-addr field of a Trap PDU which > > is forwarded by a proxy forwarder application using ... No change. > > s54) snmpCommunityTableGroup OBJECT-GROUP > > "A collection of objects providing for configuration ..." > > (suggest /objects which allow configuration/; 'provide for' > > sounds like a parent with impecunious children) No change . > > s55) 7. **/Acknowledgments/Acknowledgements/ No. Both spellings legal, "Acknowledgments" is US preferred spelling. > > s56) A. Full Copyright Statement > > (I think the copyright notice line should appear here as well as on > > the first page). No. Follows standards. > > s57) B. Changes From RFC1908 > > "- Added snmpCommunityMIB ... **/paramaters/parameters/ which > > can then be used..." Done. Additional changes per WG email threads: - 9. References split into 9. Normative References and 10. Informative References. Changes align with Mike Heard's suggestions. - References done according to 2223bis. - Reviewed 2223bis, policy.html, 1id-guidelines.txt, ID-nits.html -- This I-D now adheres to all appropriately. - No change made regarding handling of Counter64 in 2089 vs 2576. The move in 2576 to not send a notification with Counter64 was purposeful. - Extra closing quote removed that Mike Heard pointed out in the snmpCommunityTransportTag DESCRIPTION clause: << string, nor when generating notifications." >> - Copyrights updated to 2003. - Fixed section 5.1 text indentation - Added change log from 2576. - Revisions of MIB as per Mike Heard's suggestions: removed all I-D revisions, now have: DESCRIPTION "This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2c, and SNMPv3. Copyright (C) The Internet Society (2003) This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- RFC-editor: replace xxxx with the actual RFC number & remove this notice REVISION "200301130000Z" -- 13 Jan 2003 (same as LAST-UPDATED) DESCRIPTION "Updated description of snmpCommunityTag to make it consistent with the rest of the document, and additional edits per WG Last Call comments. This version published as draft-ietf-snmpv3-coex-v2-03.txt and RFC xxxx." -- RFC-editor: replace xxxx with the actual RFC number & remove this notice REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576." ------------------------ ------------------------ Changes based on "review draft-ietf-snmpv3-coex-v2-02.txt" from Harrie Hazewinkel [mailto:[email protected]] sent Wednesday, January 08, 2003 5:21 AM > -----Original Message----- > From: Harrie Hazewinkel [mailto:[email protected]] > Sent: Wednesday, January 08, 2003 5:21 AM > To: WG IETF snmpv3 > Cc: David Harrington > Subject: review draft-ietf-snmpv3-coex-v2-02.txt > > > Hi, > > I have reviewed the draft and here are my comments. > I believe there is nothing broken, but some clarifications > could be usefull. > > See below between pieces of the draft. > > > > Coexistence between Version 1, Version 2, and Version 3 > > of the Internet-standard Network Management Framework > > <draft-ietf-snmpv3-coex-v2-02.txt> > > > Abstract > > > > The purpose of this document is to describe coexistence between > > version 3 of the Internet-standard Network Management Framework, > > (SNMPv3), version 2 of the Internet-standard Network Management > > Framework (SNMPv2), and the original Internet-standard Network > > Management Framework (SNMPv1). This document obsoletes RFC 2576 > > [21]. > > Just to be clear. It basically speaks about coexistance between > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions > against the other versions. right? > > I am asking, since > - for instance, section 1.4 looks like v1 and v2 only (See > there also). > - the document also describes coexistance between SMIv1 and SMIv2 > where SMIv2 is a seperate standard. > Is that therefore needed in this document? > Is SMIv1 and SMIv2 not usefull if that will be added in the > abstract? Added text to abstract: This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. > > > Table Of Contents > [snip] > > B. Changes From RFC1908 > ........................................ 55 > > What about the changes since RFC2576? > Mentioned already by, "C. M. Heard" <[email protected]> There will be an updated change log in the upcoming I-D. > > 1.4. SNMPv1 and SNMPv2 Access to MIB Data > > Correct me if I am wrong, but this is related to the SNMP-PDU > and the SNMP-PDU is not different between SNMPv3 and SNMPv2. > For MIB access the difference between SNMPv3 and SNMPv2 is nihil, > but that is maybe worthwhile mentioning. Also since a big part of > the document uses this. Added text to clarify this at the end of section 1.4 (now section 4.1). > > > SNMPv1 access to MIB data may generate SNMPv1 > error-status values, > > will never generate exception codes nor use the > Counter64 data type, > > and will provide SNMPv1 format parameters for generating > > notifications. Note also that SNMPv1 access to MIB data will > > actually never generate a readOnly error (a noSuchName > error would > > always occur in the situation where one would expect a readOnly > > error). > > > > SNMPv2 access to MIB data may generate SNMPv2 > error-status values, > > may generate exception codes, may use the Counter64 data > type, and > > will provide SNMPv2 format parameters for generating > notifications. > > Note that SNMPv2 access to MIB data will never generate readOnly, > > noSuchName, or badValue errors. > > The above two paragraphs make it look like the 'readOnly' > error exists, > but may never be used. Maybe it maybe used for SNMPv3. That's right, it exists, but is never used. Nothing to change. > This section 1.4 seems also the be hanging between section 2 and 3. Moved section 1.4 into section 4, the terms defined in section 1.4 were only used in section 4. > Also later section 4.3 discusses the mapping between SNMPv1 > and SNMPv2, > but there is also SNMPv3 equal to SNMPv2. Somehow, I get the feeling > this is more SMIv1 and SMIv2 access to the MIB. Added text at end of section 1.3 to clarify this. > > 2. SMI and Management Information Mappings > > > > 2.1. MIB Modules > > > > MIB modules defined using the SMIv1 may continue to be used with > > protocol versions which use SNMPv2 PDUs. However, for the MIB > ^^^^^^^ > suggested change into 'the SMIv1 MIB', since this section is > SMIv1 to SMIv2 translation. (This could be used in more > places later on.) Changed 'for the MIB' to 'for SMIv1 MIB' > > > modules to conform to the SMIv2, the following changes > SHALL be made: > > > > 2.1.1. Object Definitions > > > > In general, conversion of a MIB module does not require the > > deprecation of the objects contained therein. If the > definition of > > an object is truly inadequate for its intended purpose, > the object > > SHALL be deprecated or obsoleted, otherwise deprecation is not > > required. > > I am just curious about the text "If the definition of > an object is truly inadequate for its intended purpose". > which does not make it look like a conversion from SMIv1 to SMIv2 > or vice versa. That is more a design/experience issue. This text is just to clarify that converting a MIB from SMIv1 to SMIv2 does not mean you must deprecate objects, unless there there is some other good reason to deprecate them. No change. > > 3. Translating Notifications Parameters > > > > This section describes how parameters used for generating > > notifications are translated between the format used for SNMPv1 > > notification protocol operations and the format used for SNMPv2 > > notification protocol operations. The parameters used > to generate a > > notification are called 'notification parameters.' The format of > > parameters used for SNMPv1 notification protocol operations is > > refered to in this document as 'SNMPv1 notification > parameters.' The > > format of parameters used for SNMPv2 notification > protocol operations > > is refered to in this document as 'SNMPv2 notification > parameters.' > > What about SNMPv3 'notification parameters'?? > I guess, this is similar to my comment earlier in section 1.4. Since 'notification parameters' are determined by the version of protocol operations, there are only SNMPv1 and SNMPv2 'notification parameters.' I don't think there's anything we need to change here. > > 4.1.1. Command Generator > > > > A command generator must select an appropriate message > version when > > sending requests to another entity. One way to achieve > this is to > > consult a local database to select the appropriate > message version. > > > > In addition, a command generator MUST 'downgrade' > GetBulk requests to > > GetNext requests when selecting SNMPv1 as the message > version for an > > outgoing request. This is done by simply changing the > operation type > > to GetNext, ignoring any non-repeaters and > max-repetitions values, > > and setting error-status and error-index to zero. > > Correct me if I am wrong, but this does not provide the same > functionality > from the command generators point of view. Should that be noted?? This is true, but I think we would be adding too much detail about how to implement code if we said anything more here. No change. > > 4.1.3. Notification Originator > > > > A notification originator must be able to translate > between SNMPv1 > > notification parameters and SNMPv2 notification > parameters in order > > to send a notification using a particular SNMP message > version. If a > > notification is generated using SNMPv1 notification > parameters, and > > configuration information specifies that notifications > be sent using > > SNMPv2c or SNMPv3, the notification parameters must be > translated to > > SNMPv2 notification parameters. > > here I see the first time that SNMPv2c and SNMPv3 are treated > more equal > and then maps upon SNMPV2 notification parameters. Added text at end of section 1.3 to clarify this. > > 5. Message Processing Models and Security Models > > > > In order to adapt SNMPv1 (and SNMPv2c) into the SNMP > architecture, > > the following models are defined in this document: > > > > - The SNMPv1 Message Processing Model > > > > - The SNMPv1 Community-Based Security Model > > > > The following models are also described in this document: > > The above sentence seems redundant if the '(' and ')' earlier > are deleted. Why not listing them just four bullets?? This parentheses are there because we wanted to try to de-emphasize the stuff about SNMPv2c. This was discussed long ago (I can't remember whether it was at an IETF meeting or an interim meeting). We've removed the sentence between the two bullets, though. > > - The SNMPv2c Message Processing Model > > > > - The SNMPv2c Community-Based Security Model > > > > In most respects, the SNMPv1 Message Processing > Model and the > > SNMPv2c Message Processing Model are identical, > and so these > > are not discussed independently in this document. > Differences > > between the two models are described as required. > > > > Similarly, the SNMPv1 Community-Based Security > Model and the > > SNMPv2c Community-Based Security Model are nearly > identical, > > and so are not discussed independently. > Differences between > > these two models are also described as required. > > The indent of the last 2 paragraphs make it look like it is only part > of SNMPv2C. Not needed in my opinion. The indentation was a typo, it has been fixed. > > 5.3. The SNMP Community MIB Module > > > > snmpCommunityMIBCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP engines which > > implement the SNMP-COMMUNITY-MIB." > > > > MODULE -- this module > > MANDATORY-GROUPS { snmpCommunityTableGroup } > > > > OBJECT snmpCommunityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunitySecurityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextEngineID > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityTransportTag > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStorageType > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStatus > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > ::= { snmpCommunityMIBCompliances 1 } > > I remember a discussion of having full compliance and read-only > compliance in some other MIB modules, like DIFFSERV-MIB. (Bert maybe > as well, he can as AD provide IESG guidelines, I hope. It was laid > down on other working groups after all too and I do not see a reason > why telling other WG to do it, while we ourselves don't do it.) > That could be usefull, in order to have people implementing > it also as read-write in order to be fully compliant. > This would mean just adding a full-compliance statement where it > is all implemented and with read/write. Added new compliance statement. > > > > 9. References > > Should these not be split into normative and informational > references. Done. ------------------------ ------------------------ Changes based on "Re: coex draft last call" from Dave Shield [mailto:[email protected]] sent Thursday, January 09, 2003 8:08 AM > -----Original Message----- > From: Dave Shield [mailto:[email protected]] > Sent: Thursday, January 09, 2003 8:08 AM > To: [email protected] (E-mail) > Subject: Re: coex draft last call > > > Sorry for the last-minute nature of this report, but I've now > had a chance to work through the latest coex draft, and identify > a number of points where I found the text unclear. > > Most of what follows are effectively requests for clarification. > In most cases I can probably work out what I *think* is intended > from other comments in the document, but such detective-work > seems unhelpful, and a potential source of problems. I'd suggest > that it's worth saying the same thing in two places, rather than > risk an implementor going astray because they've omitted to make > a connection between two comments at opposite ends of the document! > > > I also noted a number of stylistic points - such as inconsistencies > in phrasing and/or layout (e.g. compare 4.1.2.3 with 4.1.2.4), or > areas where the description felt a little unclear, but I've tried to > concentrate on more substantive issues here. Particularly where > the required behaviour seemed uncertain (or unexpected). > > I trust these comments are of some use. > > Dave > ------------------------------------------------------- > > p10: 2.1.1 bullet (10). > The final sentance is somewhat misleading. > Surely it's the combination of the effects of bullets (10) *and* (11) > that provides the SMIv1->SMIv2 transparency for SNMPv1 agents? Added text to clarify this. > > p17: 3.2 bullet (2) second section. > Why is the original source of the notification to be extracted > *only* from the variable bindings? If the proxy is receiving > the notification from the notification originator via SNMPv2c > or SNMPv3, then this notification would not naturally include > an snmpTrapAddress varbind, but the proxy would (potentially) > know the originating IP address from the incoming PDU transport > information. Could it not use this information when forwarding > the SNMPv1 notification? > > Though there is a potential problem in the case of a "proxy > chain" - where the proxy forwards it to a second proxy, also using > SNMPv2c or SNMPv3. This second proxy would need to recognise that > the transport address that it saw was *not* that of the original > notification originator. > The purpose of including the snmpTrapAddress.0 varbind is to preserve the original value of the agent-addr field from a trap that was originally generated using SNMPv1, and was subsequently forwarded using SNMPv2c or SNMPv3. At each hop along the path through potentially many proxies, the trap will be forwarded using either: - SNMPv1, in which case, the original value is carried in the agent-addr field of the trap, or - SNMPv2c or SNMPv3, in which case the value is carried in the snmpTrapAddress.0 varbind. Incidentally, if you read the DESCRIPTION of snmpTrapAddress, this is stated explicitly. Assuming that all proxies in the path follow these rules, whenever a trap is originally generated using SNMPv1, the agent-addr will be carried properly through the entire path. The only cases where the agent-addr at some hop might be 0.0.0.0 are: - If the trap was originally generated using SNMPv1, but was originally sent on a transport other than IPv4, in which case the value *should* be 0.0.0.0 - If the trap was originally generated using SNMPv2c or SNMPv3, and was translated to SNMPv1 by a proxy somewhere along the path. In this case, the value should also be 0.0.0.0, as we don't carry the source IP address of traps in SNMPv2 traps or informs. Trying to pick up an IP address from a hop somewhere along the way would mean that when you receive a trap, you never know whether the agent-addr value is that of the original agent, or of some hop in-between. So, I think the text is correct as is, no change. > > p18: 3.2 bullet (6) > This description says to strip out snmpTrapAddress.0, but says > nothing about the other two varbind that may potentially have > been added - snmpTrapCommunity.0 and snmpTrapEnterprise.0. > > In particular, the snmpTrapEnterprise.0 varbind has already > been used to set the SNMPv1 enterprise notification parameter > (see 3.2 bullet(1) ). Retaining it here would seem unnecessary, > so it would be sensible to remove this as well. > > How to handle snmpTrapCommunity.0 seems less obvious - in > particular, should the outgoing SNMPv1 notification use this > community name, or that determined from the proxy's own configuration > (e.g. the SNMP-COMMUNITY-MIB)? > > Should the snmpTrapCommunity.0 varbind be retained or not? Does > it make a difference whether this value is the same as the SNMPv1 > community notification parameter on the outgoing notification? > The community name in an SNMPv1 trap being forwarded by a proxy will be determined by the proxy's configuration, as you mentioned, and so the snmpTrapCommunity.0 varbind needs to be left in the varbind list. Preserving this value may be important to some people, which is why snmpTrapCommunity.0 was defined in the first place. So, that varbind should not be removed. In any case, as discussed in subsequent e-mails, it makes sense to just leave all 3 varbinds (snmpTrapAddress, snmpTrapCommunity, snmpTrapEnterprise), so, changed the text to preserve all 3. Also changed the text about removing sysUpTime.0 and snmpTrapOID.0 from the SNMPv2 variable bindings to just note that they are not included (to make the use of the term more consistent). > > p20: 4.1.2 last paragraph > This talks in general terms about "some combination of SNMPv1 and > SNMPv2 access to MIB data". But in practise, everything that > follows is talking specifically about SNMPv2 access to MIB data, > in response to an SNMPv1 request. There is nothing about the > other possible combinations. > > Presumably, "homogeneous" access is not regarded as a problem > (i.e. SNMPv1 access to MIB data in response to an SNMPv1 request, > or SNMPv2 access to MIB data in response to an SNMPv2c or SNMPv3 > request)? In such a situation, the multi-lingual nature of the > agent is effectively irrelevant - yes? Right. > > What about SNMPv1 access to MIB data in response to an SNMPv2c > or SNMPv3 request? If such an approach should not be used (and > I can see no good reason to do so), then perhaps this should > be stated explicitly. > It should not be used, added text stating this. > I believe it would be easier to follow if the introduction to > section 4.1.2 stated up front, that the rest of the section > referred purely to SNMPv2 access to MIB data in response to > an SNMPv1 request. Changed the text at the end of the section to state this. > > > p24: 4.1.2.4 second list, bullet (1) > Presumably an endOfMibView exception counts as an "error" in this > situation (or at least triggers the bullet (2) processing)? > This is not entirely clear, but would seem the obvious behaviour. Added text 'or an endOfMibView exception' > > p27: 4.2.1 bullet (3) > The processing of a 'tooBig' response to a GetBulkRequest feels > surprising. In particular, it's inconsistent with the processing > of a 'toobig' response to the equivalent GetNextRequest. Why should > we try so hard to provide a ("sub-minimal") answer to a GetBulk? > If this behaviour is intentional, it would merit a word of > explanation. This behaviour is intentional, it was deemed to expensive to try to re-send the request multiple times, with a single varbind stripped out each time. This behaviour is intended to preserve the behaviour of a GetBulkRequest as closely as possible. For a GetBulkRequest, you only need to return as many varbinds as will fit in the outgoing packet, and you only return a tooBig error if you cannot fit even a single varbind. So re-sending with just a single varbind ensures that you'll return at least that one varbind if possible, without re-sending multiple times. This is different from how a GetNextRequest works, where you must return all requested varbinds if they will fit in the available packet size, otherwise you must return a tooBig error. So, just added text to state that the described behaviour preserves the behaviour of GetBulk as closely as possible. > > > p28: 4.2.2 bullet (3) > The processing of Counter64 results in a proxy environment is > inconsistent with the of processing Counter64 results in a > multi-lingual environment (section 4.1.2.4, second bullet (1) ) > In particular, a proxy should retry the whole request, not just > the Counter64 varbinds. > Is this difference intentional? If so, then it may be worth > pointing it out explicitly. I think you're comparing apples and oranges here, section 4.1.2.4 is about MIB access internally within a command responder application, whereas section 4.2.2 is talking about forwarding requests and responses through a proxy. I think we would make things more confusing by adding text about this. No change. > > p28: 4.2.2 Deployment Hint > I'm not convinced that the not-in-view suggestion here is sensible, > unless the proxy uses different principals for forwarding SNMPv1 > requests and SNMPv2/v3c requests. If a proxy uses a single principal > for communicating with a particular agent, then any Counter64 type > objects *should* be in-view for incoming SNMPv2c or SNMPv3 requests. > Adding the suggested access restriction would affect such requests, > as well as forwarded SNMPv1 requests. > If this suggestion is retained, then it should make mention of > this problem. > Added text to clarify this. > > p33: 5.2.1 CBSM returned parameters > Where is the value for 'securityName' obtained from? Is it the > value of 'snmpCommunitySecurityName' in the selected row of the > snmpCommunityTable? If so, then it's worth stating this. > > Similarly, where is the value for 'maxSizeResponseScopedPDU' found? > snmpTargetAddrMMS ? Added text to clarify these. > > It would also be worth mentioning any requirements on the > securityStateReference at this point, rather than waiting until > section 5.2.2. Added text to the securityStateReference bullet that it must include the community string. Also, in section 5.2.2, change 'stateReference' to 'securityStateReference,' it is really the securityStateReference that must contain the community string. > > > p35: 5.2.4 > If the proxy is forwarding from one example of a community-based > Message Processing Model to another (e.g. v1->v2c or vice versa) > where do the securityName, contextEngineID and contextName values > come from? Are these the values returned by the processing > described in section 5.2.1? If so, is it worth stating this > in 5.2.4? These parameters are the values passed into the sendPdu ASI, this is already mentioned here. How they are passed in to the sendPdu ASI is beyond the scope of this document, it is described in RFC3413. I don't think we need to add any new text here. Incidentally, while the contextName and contextEngineID are the values obtained in section 5.2.1, the securityName will be the value obtained by the proxy application from the SNMP-PROXY-MIB and SNMP-TARGET-MIB. This is also already stated in section 5.2.4. > > p36: 5.3 third/fourth paragraphs > The third paragraph states that the snmpTargetAddrTMask is only > to be used where explicitly stated - presumably when matching on > incoming transport addresses, rather than identifying individual > destination addresses. > In a situation where the snmpTargetAddrTMask is *not* to be used, > how should transport address matching be done? In particular, if > the snmpTargetAddrTMask is a non-zero length string (i.e. this is > a "wildcard" row), should a check be done on the (exact) value of > snmpTargetAddrTAddress anyway, or should the whole row be skipped? As the text says, the value is only used where explicitly stated. If it is not explicitly state elsewhere in this document, or in another document, that the value is used to match multiple addresses, then it is not used, and matching must be exact. I added text stating that the value must be ignored when it's use is not explicitly stated. > > One final issue: > Is it worth saying something about AgentX in all this? The AgentX > protocol operations are essentially SNMPv2 in a different guise, > so an AgentX master agent could be viewed as a sort of proxy. > Is it worthing saying something along these lines? > Or is it really too late to consider this properly? This has already been addressed on the mailing list, no change.