A YANG Data Model for SNMP Configuration
RFC 7407
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Benoît Claise; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
-- 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?
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
Though a YANG model for SNMP feels a little self-referential. Do we have a NETCONF MIB, just for completeness? ;)
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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.
(Ted Lemon; former steering group member) No Objection