Simple Network Management Protocol (SNMP) over IEEE 802 Networks
draft-schoenw-snmp-ether-02

Received changes through RFC Editor sync (changed abstract to 'This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.

This document obsoletes RFC 1089. [STANDARDS-TRACK]')

[Ballot comment]
I'd like to ask in what situations someone would want to run SNMP directly over ethernet, and discuss whether or not to at least include one example to describe such motivations.

[Ballot discuss]
I'd like to ask in what situations someone would want to run SNMP directly over ethernet, and discuss whether or not to at least include one example to describe such motivations.

[Ballot comment]
Section 3., paragraph 1:
>    This is an optional transport mapping.

  s/optional/OPTIONAL/


Section 3.2., paragraph 3:
>    It is recommended that implementations be capable of accepting
>    messages of up to 1472 octets in size.  Implementation of larger
>    values is encouraged whenever possible.

  s/recommended/RECOMMENDED/


Section 3415, paragraph 0:
>    Specifically, the use of the User-based Security Model STD 62, RFC
>    3414 [RFC3414] and the View-based Access Control Model STD 62, RFC
>    3415 [RFC3415] is recommended.

  Nit: Missing Reference: 'RFC3414' is mentioned on line 220, but not
  defined. Missing Reference: 'RFC3415' is mentioned on line 221, but
  not defined.

Gen-Art Review provided by David Black:

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-schoenw-snmp-ether-01.txt
Reviewer: David L. Black
Review Date: 25 Sept 2006
IESG Telechat date: 28 Sept 2006

Summary:
This draft is basically ready for publication, but has nits that should be fixed before publication.

Comments:
This is a short update to (even shorter) RFC 1089 to define a TC and provide somewhat better explanation of a few things, written by a couple of experts.  The -02 version is in the queue to be posted, but I reviewed the -01 version due to time constraints.

The -01 version would be ok to publish as-is, but I concur with Cullen Jennings's comment that use of RFC 2119 language is appropriate, and I specifically suggest a couple of "MUST"s in the second paragraph of Section 3.2 to require the use of EtherType hex 814C and use of SNAP with LLC.  I happen to know from history that IEEE is somewhat sensitive about proper EtherType usage.

IANA needs clarification of what to do about SNMP domain registration - see the IANA comment in the I-D tracker.

Thanks,
--David

Juergen answered:

Does the following rephrased text address your comment:

  When serialized SNMP messages are sent in IEEE 802.3 frames (and in
  other IEEE 802 MAC frame types that can natively represent Ethernet
  type values), the Ethernet type field value of 33100 (hexadecimal
  814C) MUST be used as the link layer protocol identifier.  In IEEE
  802 LANs that use LLC as the means of link layer protocol
  identification, such as IEEE 802.11 Wireless LANs, the SNAP
  encapsulation method described in subclause 10.5 "Encapsulation of
  Ethernet frames over LLC" in [IEEE802] MUST be used.

> IANA needs clarification of what to do about SNMP domain registration
> - see the IANA comment in the I-D tracker.

This is taken care of in the -02 version (which still sits in the queue).

Thanks,

/js

This issue will be addressed in a RFC Editor Note.

Gen-Art Review provided by David Black:

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-schoenw-snmp-ether-01.txt
Reviewer: David L. Black
Review Date: 25 Sept 2006
IESG Telechat date: 28 Sept 2006

Summary:
This draft is basically ready for publication, but has nits that should be fixed before publication.

Comments:
This is a short update to (even shorter) RFC 1089 to define a TC and provide somewhat better explanation of a few things, written by a couple of experts.  The -02 version is in the queue to be posted, but I reviewed the -01 version due to time constraints.

The -01 version would be ok to publish as-is, but I concur with Cullen Jennings's comment that use of RFC 2119 language is appropriate, and I specifically suggest a couple of "MUST"s in the second paragraph of Section 3.2 to require the use of EtherType hex 814C and use of SNAP with LLC.  I happen to know from history that IEEE is somewhat sensitive about proper EtherType usage.

IANA needs clarification of what to do about SNMP domain registration - see the IANA comment in the I-D tracker.

Thanks,
--David

Juergen answered:

Does the following rephrased text address your comment:

  When serialized SNMP messages are sent in IEEE 802.3 frames (and in
  other IEEE 802 MAC frame types that can natively represent Ethernet
  type values), the Ethernet type field value of 33100 (hexadecimal
  814C) MUST be used as the link layer protocol identifier.  In IEEE
  802 LANs that use LLC as the means of link layer protocol
  identification, such as IEEE 802.11 Wireless LANs, the SNAP
  encapsulation method described in subclause 10.5 "Encapsulation of
  Ethernet frames over LLC" in [IEEE802] MUST be used.

> IANA needs clarification of what to do about SNMP domain registration
> - see the IANA comment in the I-D tracker.

This is taken care of in the -02 version (which still sits in the queue).

Thanks,

/js

As version 02 is now published, we believe that the issue raised by David and Cullen should be closed.

IANA Last Call Comment:

IANA has questions about this document.

Upon approval of this document, IANA understands that it has two IANA Actions to complete.

A new entry in the SMI SNMPv2 snmpModules Codes registry in the registry located at: http://www.iana.org/assignments/smi-numbers will be created.

Decimal Name Description References
------- ---- ----------- ----------
tbd SNMP-IEEE802-TM-MIB IEEE 802 Transport Mapping tbd

The second IANA Action is referred to in the IANA Considerations section of the document. The document says, "IANA has to assign an OID value below snmpDomains for the transport domain." In the registry located at
http://www.iana.org/assignments/smi-numbers, there is not yet a registry for SMI SNMPv2 snmpDomains Codes (1.3.6.1.6.1). Upon approval of this document should the SMI SNMPv2 snmpDomains Codes (1.3.6.1.6.1) be established in

http://www.iana.org/assignments/smi-numbers and should an initial value
for transport be created?

Expert review completed on the MIB Doctors list. There were no objections or substantial comments, two participants expressed support for the document in its present form (draft-01)