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

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.

-- 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?

Though a YANG model for SNMP feels a little self-referential.  Do we have a NETCONF MIB, just for completeness? ;)

- 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.