Re: coex draft last call
"C. M. Heard" <[email protected]> Tue, 7 Jan 2003 01:18:40 -0800 (PST)
| Newsgroups | gmane.ietf.snmpv3 |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 4 Jan 2003, Harrington, David wrote: > In my view as co-chair, the coex draft has not had enough thorough > review for it to be submitted to the IESG. We need at least two more > thorough reviews of the content. The Last Call ends next Friday, > January 10. [ ... ] I do not want to be one of the chairs that submits > documents without adequate review. We need more technical review of this > document. If we do not get it, I will not submit the document to the > IESG or the RFC-editor. We can just close the WG and let the I-D expire > after six months. I feel fully empowered to make such a decision because > it will be apparent that the consensus of the WG is "I don't care about > this document". While I understand what you are saying (and largely agree with it), I can also sympathize to some degree with someone who would say "but this is a deployed spec, and we reviewed it when it was first published ... do we really need to do it all over again?" I say that because that was my first reaction. Anyway, to try to contribute what I can I've done two things: 1.) I have carefully read through the only part of spec about which I have sufficient technical expertise to make a meaningful review of the content ... namely Section 2. With two exceptions, I think that section is fine; the exceptions will be the subject of a subsequent message. 2.) I went through _all_ the changes that I found between RFC 2576 and this draft (other than spelling, grammar, and formatting). I found one that I think was wrong, and I will complain about it in a subsequent message. All the rest looked reasonable to me, and I constructed some proposed text for a "changes since RFC 2576" section. That, too, will be the subject of a subsequent message. I would now like to suggest a way to move this document forward. Surely there are people on this list who have _implemented_ the stuff in Sections 3, 4, and 5 of RFC 2576 in multilingual agents and/or proxies. Surely at least some those people had to read RFC 2576 in detail in order to do so and would be in a position to say what, if any, shortcomings they found in RFC 2576. For such a person, a review of just the changes in the latest coex draft relative to 2576 should suffice to determine if the new document is technically sound. The substantive changes are actually fairly small: they can be boiled down to two context diffs of less than 300 lines apiece, one for the text of the spec from Section 1 through Section 5.3 up to but not including the MIB module, and another for the MIB module itself. These are attached. The formatting and line numbers in the diff for the prose part of the specification match those in RFC 2576 (rather than the draft), and it omits items trivial items such as spelling and formatting. The diff for the MIB module includes the changes to the DESCRIPTION and REVISION clauses of the MODULE-IDENTITY invocation that I recommended in a previous message to the list, i.e., those corrections were applied to the MIB module from the draft before the diff was generated. I've now done what I can to review the parts of this document that I'm competent to review and to assist other people in reviewing the remainder. I hope someone who's read and implemented RFC 2576 will now step up to the plate. If no one does, then I will have to agree with our co-chair that the clear message is that the WG does not care ehough about this spec to merit sending it to the IESG. //cmh
rfc2576-coex-v2-diffs.txt
(text/plain, 11.6 KB)
*** rfc2576.txt Tue Mar 14 18:42:07 2000
--- coex-v2.txt Mon Dec 16 14:51:58 2002
***************
*** 387,390 ****
(13) One or more OBJECT-GROUPS MUST be defined, and related objects
! SHOULD be collected into appropriate groups. Note that SMIv2
requires all OBJECT-TYPEs to be a member of at least one
OBJECT-GROUP.
--- 387,390 ----
(13) One or more OBJECT-GROUPS MUST be defined, and related objects
! MUST be collected into appropriate groups. Note that SMIv2
requires all OBJECT-TYPEs to be a member of at least one
OBJECT-GROUP.
***************
*** 522,525 ****
! (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of
MODULE-CONFORMANCE.
! (2) The STATUS clause SHOULD be added, with a value of 'current'.
--- 522,525 ----
! (1) The macro name AGENT-CAPABILITIES MUST be used instead of
MODULE-CONFORMANCE.
! (2) The STATUS clause MUST be added, with a value of 'current'.
***************
*** 608,610 ****
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in
the second variable-binding in an SNMPv2-Trap-PDU or
! InformRequest-PDU.
--- 608,612 ----
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in
the second variable-binding in an SNMPv2-Trap-PDU or
! InformRequest-PDU, and is equal to the value portion of that
! variable-binding (not the name portion, as both the name and
! value are OBJECT IDENTIFIERs).
***************
*** 695,707 ****
- If the SNMPv2 snmpTrapOID parameter is not one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be determined from the SNMPv2 snmpTrapOID
parameter as follows:
! - If the next-to-last sub-identifier of the snmpTrapOID is
! zero, then the SNMPv1 enterprise SHALL be the SNMPv2
! snmpTrapOID with the last 2 sub-identifiers removed,
otherwise
! - If the next-to-last sub-identifier of the snmpTrapOID is
! non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
! snmpTrapOID with the last sub-identifier removed.
--- 697,709 ----
- If the SNMPv2 snmpTrapOID parameter is not one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be determined from the SNMPv2 snmpTrapOID
parameter as follows:
! - If the next-to-last sub-identifier of the snmpTrapOID value
! is zero, then the SNMPv1 enterprise SHALL be the SNMPv2
! snmpTrapOID value with the last 2 sub-identifiers removed,
otherwise
! - If the next-to-last sub-identifier of the snmpTrapOID value
! is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
! snmpTrapOID value with the last sub-identifier removed.
***************
*** 759,765 ****
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
! bindings. Note, however, that if the SNMPv2 variable-bindings
! contain any objects whose type is Counter64, the translation to
! SNMPv1 notification parameters cannot be performed. In this
! case, the notification cannot be encoded in an SNMPv1 packet
! (and so the notification cannot be sent using SNMPv1, see
! section 4.1.3 and section 4.2).
--- 761,768 ----
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
! bindings, with the variable-bindings containing sysUpTime.0,
! snmpTrapOID.0, and snmpTrapAddress.0 removed. Note, however,
! that if the SNMPv2 variable-bindings contain any objects whose
! type is Counter64, the translation to SNMPv1 notification
! parameters cannot be performed. In this case, the notification
! cannot be encoded in an SNMPv1 packet (and so the notification
! cannot be sent using SNMPv1, see section 4.1.3 and section 4.2).
***************
*** 1151,1166 ****
4.2. Proxy Implementations
A proxy implementation may be used to enable communication between
entities which support different SNMP message versions. This is
accomplished in a proxy forwarder application by performing
translations on PDUs. These translations depend on the PDU type, the
SNMP version of the packet containing a received PDU, and the SNMP
version to be used to forward a received PDU. The following sections
describe these translations. In all cases other than those described
below, the proxy SHALL forward a received PDU without change, subject
to size constraints as defined in section 5.3 (Community MIB) of this
document. Note that in the following sections, the 'Upstream
! Version' refers to the version used between the command generator and
! the proxy, and the 'Downstream Version' refers to the version used
! between the proxy and the command responder, regardless of the PDU
! type or direction.
--- 1154,1170 ----
4.2. Proxy Implementations
A proxy implementation may be used to enable communication between
entities which support different SNMP message versions. This is
accomplished in a proxy forwarder application by performing
translations on PDUs. These translations depend on the PDU type, the
SNMP version of the packet containing a received PDU, and the SNMP
version to be used to forward a received PDU. The following sections
describe these translations. In all cases other than those described
below, the proxy SHALL forward a received PDU without change, subject
to size constraints as defined in section 5.3 (Community MIB) of this
document. Note that in the following sections, the 'Upstream
! Version' refers to the version used between the command generator or
! notification receiver and the proxy, and the 'Downstream Version'
! refers to the version used between the proxy and the command
! responder or notification originator, regardless of the PDU type or
! direction.
***************
*** 1183,1188 ****
- If a GetResponse-PDU is received whose error-status field has a
! value of 'tooBig', the message will be forwarded using the SNMPv2c
! or SNMPv3 message version, and the original request received by
! the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL
! remove the contents of the variable-bindings field before
forwarding the response.
--- 1187,1193 ----
- If a GetResponse-PDU is received whose error-status field has a
! value of 'tooBig', and the message will be forwarded using the
! SNMPv2c or SNMPv3 message version, and the original request
! received by the proxy was not a GetBulkRequest-PDU, the proxy
! forwarder SHALL remove the contents of the variable-bindings field
! and ensure that the error-index field is set to 0 before
forwarding the response.
***************
*** 1190,1204 ****
- If a GetResponse-PDU is received whose error-status field has a
value of 'tooBig,' and the message will be forwarded using the
SNMPv2c or SNMPv3 message version, and the original request
received by the proxy was a GetBulkRequest-PDU, the proxy
forwarder SHALL re-send the forwarded request (which would have
been altered to be a GetNextRequest-PDU) with all but the first
variable-binding removed. The proxy forwarder SHALL only re-send
such a request a single time. If the resulting GetResponse-PDU
also contains an error-status field with a value of 'tooBig,' then
the proxy forwarder SHALL remove the contents of the variable-
! bindings field, and change the error-status field to 'noError'
! before forwarding the response. Note that if the original request
! only contained a single variable-binding, the proxy may skip re-
! sending the request and simply remove the variable-bindings and
! change the error-status to 'noError.'
--- 1195,1210 ----
- If a GetResponse-PDU is received whose error-status field has a
value of 'tooBig,' and the message will be forwarded using the
SNMPv2c or SNMPv3 message version, and the original request
received by the proxy was a GetBulkRequest-PDU, the proxy
forwarder SHALL re-send the forwarded request (which would have
been altered to be a GetNextRequest-PDU) with all but the first
variable-binding removed. The proxy forwarder SHALL only re-send
such a request a single time. If the resulting GetResponse-PDU
also contains an error-status field with a value of 'tooBig,' then
the proxy forwarder SHALL remove the contents of the variable-
! bindings field, and change the error-status field to 'noError',
! and ensure that the error-index field is set to 0 before
! forwarding the response. Note that if the original request only
! contained a single variable-binding, the proxy may skip re-sending
! the request and simply remove the variable-bindings and change the
! error-status to 'noError.'
***************
*** 1478,1481 ****
- The scopedPDU. Note that this parameter will actually consist
! of three values, the contextSnmpEngineID, the contextName, and
! the PDU. These must be separate values, since the first two do
! not actually appear in the message.
--- 1484,1491 ----
- The scopedPDU. Note that this parameter will actually consist
! of three values, the contextSnmpEngineID (which will be the
! value of snmpCommunityContextEngineID from the selected entry
! in the snmpCommunityTable), the contextName (which will be the
! value of snmpCommunityContextName from the selected entry in
! the snmpCommunityTable), and the PDU. These must be separate
! values, since the first two do not actually appear in the
! message.
***************
*** 1583 ****
--- 1594,1623 ----
+ 5.2.4. Proxy Forwarding Of Requests
+
+ In a proxy forwarding application, when a received request is to be
+ forwarded using the SNMPv1 Message Processing Model, the parameters
+ used for forwarding will be obtained by examining the SNMP-PROXY-MIB
+ and the SNMP-TARGET-MIB. These parameters will be passed to the
+ SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1
+ Message Processing Model will attempt to locate an appropriate
+ community string in the snmpCommunityTable based on the parameters
+ passed to the sendPdu ASI. This is done by performing a search
+ through the snmpCommunityTable in lexicographic order. The first
+ entry for which the following matching criteria are satisfied will be
+ selected:
+
+ - The securityName must be equal to the
+ snmpCommunitySecurityName value.
+
+ - The contextEngineID must be equal to the
+ snmpCommunityContextEngineID value.
+
+ - The contextName must be equal to the snmpCommunityContextName
+ value.
+
+ If no such entry can be found, the proxy forwarding application
+ should follow the procedure described in RFC 2573 [18], section
+ 3.5.1.1, item (2). This procedure states that the snmpProxyDrops
+ counter [12] is incremented, and that a Response-PDU is generated by
+ calling the Dispatcher using the returnResponsePdu abstract service
+ interface.
+
SNMP-COMMUNITY-MIB-diffs.txt
(text/plain, 10.6 KB)
*** SNMP-COMMUNITY-MIB-200003060000Z Mon Mar 6 00:00:00 2000
--- SNMP-COMMUNITY-MIB-200212130000Z Fri Dec 13 00:00:00 2002
***************
*** 1,76 ****
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
IpAddress,
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
snmpModules
FROM SNMPv2-SMI
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpAdminString,
SnmpEngineID
FROM SNMP-FRAMEWORK-MIB
SnmpTagValue,
snmpTargetAddrEntry
FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY
! LAST-UPDATED "200003060000Z" -- 6 Mar 2000, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: [email protected]
Subscribe: [email protected]
In msg body: subscribe snmpv3
! Chair: Russ Mundy
! TIS Labs at Network Associates
Postal: 3060 Washington Rd
! Glenwood MD 21738
USA
! Email: [email protected]
Phone: +1-301-854-6889
Co-editor: Rob Frye
! CoSine Communications
! Postal: 1200 Bridge Parkway
! Redwood City, CA 94065
USA
! E-mail: [email protected]
! Phone: +1 703 725 1130
Co-editor: David B. Levi
Nortel Networks
Postal: 3505 Kesterwood Drive
! Knoxville, TN 37918
E-mail: [email protected]
Phone: +1 423 686 0432
Co-editor: Shawn A. Routhier
Integrated Systems Inc.
Postal: 333 North Ave 4th Floor
! Wakefield, MA 01880
E-mail: [email protected]
Phone: +1 781 245 0804
Co-editor: Bert Wijnen
Lucent Technologies
Postal: Schagen 33
3461 GL Linschoten
Netherlands
Email: [email protected]
! Phone: +31-348-407-775
"
DESCRIPTION
! "This MIB module defines objects to help support coexistence
! between SNMPv1, SNMPv2c, and SNMPv3."
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
! REVISION "199905130000Z" -- 13 May 1999
! DESCRIPTION "The Initial Revision"
::= { snmpModules 18 }
--- 1,94 ----
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
IpAddress,
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
snmpModules
FROM SNMPv2-SMI
RowStatus,
StorageType
FROM SNMPv2-TC
SnmpAdminString,
SnmpEngineID
FROM SNMP-FRAMEWORK-MIB
SnmpTagValue,
snmpTargetAddrEntry
FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY
! LAST-UPDATED "200212130000Z" -- 13 Dec 2002, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: [email protected]
Subscribe: [email protected]
In msg body: subscribe snmpv3
! Co-Chair: Russ Mundy
! Trusted Information Systems
Postal: 3060 Washington Rd
! Glenwood, Maryland 21738
USA
! EMail: [email protected]
Phone: +1-301-854-6889
+ Co-Chair: David Harrington
+ Enterasys Networks
+ Postal: 35 Industrial Way
+ P. O. Box 5004
+ Rochester, New Hampshire 03866-5005
+ USA
+ EMail: [email protected]
+ Phone: +1 603-337-2614
+
Co-editor: Rob Frye
! Vibrant Solutions
! Postal: 2711 Prosperity Ave
! Fairfax, Virginia 22031
USA
! E-mail: [email protected]
! Phone: +1-703-270-2000
Co-editor: David B. Levi
Nortel Networks
Postal: 3505 Kesterwood Drive
! Knoxville, Tennessee 37918
E-mail: [email protected]
Phone: +1 423 686 0432
Co-editor: Shawn A. Routhier
Integrated Systems Inc.
Postal: 333 North Ave 4th Floor
! Wakefield, Massachusetts 01880
E-mail: [email protected]
Phone: +1 781 245 0804
Co-editor: Bert Wijnen
Lucent Technologies
Postal: Schagen 33
3461 GL Linschoten
Netherlands
Email: [email protected]
! Phone: +31-348-680-485
"
DESCRIPTION
! "This MIB module defines objects to help support
! coexistence between SNMPv1, SNMPv2c, and SNMPv3.
!
! Copyright (C) The Internet Society (2002). This
! version of this MIB module is part of RFC xxxx;
! see the RFC itself for full legal notices."
! -- RFC-editor: replace xxxx with actual RFC number & remove this notice
! REVISION "200212130000Z" -- 13 Dec 2002 (same as LAST-UPDATED)
! DESCRIPTION "Updated description of snmpCommunityTag to make
! it consistent with the rest of the document.
! This version published as RFC xxxx."
! -- RFC-editor: replace xxxx with actual RFC number & remove this notice
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
!
::= { snmpModules 18 }
***************
*** 170,191 ****
snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
! from which a command responder application will accept
! management requests. If a management request containing
! this community is received on a transport endpoint other
! than the transport endpoints identified by this object,
! the request is deemed unauthentic.
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
! If the value of this object has zero-length, transport
! endpoints are not checked when authenticating messages
! containing this community string."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
--- 188,223 ----
snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
! which are used in two ways:
! - to specify the transport endpoints from which an
! SNMP entity will accept management requests, and
! - to specify the transport endpoints to which a
! notification may be sent using the community
! string matching the corresponding instance of
! snmpCommunityName.
! 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.
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
! If a management request containing a community string
! that matches the corresponding instance of
! snmpCommunityName is received on a transport endpoint
! other than the transport endpoints identified by this
! object the request is deemed unauthentic.
!
! When a notification is to be sent using an entry in
! this table, if the destination transport endpoint of
! the notification does not match one of the transport
! endpoints selected by this object, the notification
! is not sent."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
***************
*** 293,301 ****
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
! in the snmpTargetAddrTable."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
--- 325,334 ----
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
! in the snmpTargetAddrTable. Note that a value of 0 means
! that the maximum message size is unknown."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
***************
*** 352 ****
! MANDATORY-GROUPS { snmpCommunityGroup }
--- 385 ----
! MANDATORY-GROUPS { snmpCommunityTableGroup }
***************
*** 395 ****
! snmpCommunityGroup OBJECT-GROUP
--- 428 ----
! snmpCommunityTableGroup OBJECT-GROUP