A YANG Data Model for SNMP Configuration
draft-ietf-netmod-snmp-cfg-08

[Ballot comment]
-- Section 4.1 --

    identity san-rfc822-name {
      base cert-to-name;
      description
        "Maps a subjectAltName's rfc822Name to a name.  The local part
          of the rfc822Name is passed unaltered but the host-part of the
          name must be passed in lowercase.  This mapping results in a
          1:1 correspondence between equivalent subjectAltName
          rfc822Name values and name values except that the host-part
          of the name MUST be passed in lowercase. For example, the
          rfc822Name field FooBar@Example.COM is mapped to name
          FooBar@example.com.";
      reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANRFC822Name";
    }

The repetition in here, and the two different "must/MUST be passed in lowercase" seems odd.  Can this be reworded to say the same thing but remove the odd repetition?

[Ballot comment]
Section 4.10:

I know the term "privacy" is used here to match how it's used in RFC 3414, but given that we now know that privacy can be about many things beyond confidentiality, I'm wondering if it's possible to have the language here match that current understanding a bit better, e.g.:

s/"when privacy is used, authentication must also be used";/"when privacy (confidentiality) is used, authentication must also be used";

If the container could be called "confidentiality" rather than "priv" that would be good too.

[Ballot comment]

- 2.7: I wondered if this gatewaying would change the
security considerations for SNMP proxies? (Not that I really
know what those are, but combining g/ws and proxies is often
a way to create new vulnerabilities.)

- 2.10: "However, the localized key can be changed.  This
implies that if the engine id is changed, all users keys need
to be changed as well." Can you explain that a bit more?  It
doesn't sound so good, but I'm not sure if its avoidable or
not. And I don't think that paragraph is clear as-is to be
honest.

- 2.12 (and more generally): I had a look at this and how it
maps to RFC6353 and it wasn't entirely clear to me how the
client|server-fingerprint here mapped to a 6353
implementation. For example, is the fingerprint a fingerprint
of the SubjectPublicKeyInfo (as used in DANE and elsewhere),
or of the full cert? Similarly can it be a fingerprint for an
end-entity cert or of any or a particular CA in a (or any?)
chain that certifies the client cert?  I think most of this
is somewhere here or in the refs but just wanted to check.

- 2.12: (and more generally) Did the WG consider the kinds of
issue that the websec WG considered for HTTP pinngin? For
example, HTTP pins allow for a backup pin in case you brick
your site and the same might (or might not) be useful here.

- Should (or are) some or all of the 2.x things mandatory
to implement? That wasn't clear to me.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-netmod-snmp-cfg-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First,in the IETF XML namespaces registry located at:

http://www.iana.org/assignments/xml-registry/

a new namespace is to be registered as follows:

ID: yang:ietf-snmp
URI: urn:ietf:params:xml:ns:yang:ietf-snmp
Filename:
Reference: [ RFC-to-be ]

Second, in the YANG Module Names subregistry of the YANG Parameters registry located at:

http://www.iana.org/assignments/yang-parameters/

two, new module names will be added to the registry as follows:

Name: ietf-snmp
Namespace: urn:ietf:params:xml:ns:yang:ietf-snmp
Prefix: snmp
Module:
Reference: [ RFC-to-be ]

Name: ietf-x509-cert-to-name
Namespace: urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name
Prefix: x509c2n
Module:
Reference: [ RFC-to-be ]

Third, also in the YANG Module Names subregistry of the YANG Parameters registry located at:

http://www.iana.org/assignments/yang-parameters/

ten, new submodule names for module 'ietf-snmp' will be added to the registry as follows:

Name: ietf-snmp-common
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-engine
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-community
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-notification
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-target
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-vacm
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-usm
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-tsm
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-tls
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

Name: ietf-snmp-ssh
Namespace:
Prefix:
Module: ietf-snmp
Reference: [ RFC-to-be ]

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for SNMP Configuration) to Proposed Standard


The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for SNMP Configuration'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a collection of YANG definitions for
  configuring SNMP engines.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.