Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-dtls-tm-14
Yes
(David Harrington)
(Sean Turner)
No Objection
(Gonzalo Camarillo)
(Pete Resnick)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stephen Farrell)
(Stewart Bryant)
(Wesley Eddy)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Dan Romascanu Former IESG member
Yes
Yes
(2010-04-29)
Unknown
1. For consistency purposes (as TLS is expanded) expand SNMP in the title.
2. In a couple of places (section 1, section 9.1) I encountered the term 'notification responder' while in all other places 'notification receiver' is used. The terms are not exactly synonims, is the inconsistency intentional?
3. In Section 3.3
When configuring a (D)TLS target, the snmpTargetAddrTDomain and
snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an
appropriate snmpTLSAddress value. When used with the SNMPv3 message
processing model, the snmpTargetParamsMPModel column of the
snmpTargetParamsTable should be set to a value of 3. The
snmpTargetParamsSecurityName should be set to an appropriate
securityName value and the snmpTlstmParamsClientFingerprint parameter
of the snmpTlstmParamsTable should be set a value that refers to a
locally held certificate (and the corresponding private key) to be
used.
All 'should' seem to need to be capitalized.
4. In Section 4.1
Enterprise configurations are encouraged to map a "subjectAltName"
component of the X.509 certificate to the TLSTM specific
tmSecurityName.
I do not think that we have a clear notion of what an 'enterprise configuration' is and why it would be more appropriate for such a mapping. It looks like a (non-capitalized) may is more appropriate here.
5. In Section 5.2 5b) s/If there is not a corresponding LCD entry/If there is no corresponding LCD entry/
6. In Section 5.4.4
4) Have (D)TLS close the specified connection. This SHOULD include
sending a close_notify TLS Alert to inform the other side that
session cleanup may be performed.
Unless I miss something sending the close_notify TLS Alert is always part of the closing sequence, so s/SHOULD/MUST/
7. Some of the references in the MIB module are not included as Informative References - for example RFC 1033, RFC 3490
David Harrington Former IESG member
Yes
Yes
(2011-05-16)
Unknown
Sean Turner Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-05-06)
Unknown
A few thoughts about the MIB module. Nothing of any great importance. It would be helpful if the Imports clause indicated (through comments) the source documents for the MIB modules from which things are being imported. --- SnmpTLSAddress Since I-D.ietf-6man-text-addr-representation is ahead of this document in the process-chain, it would be good if you could include an RFC Editor note requesting the reference to be changed where it appears in the Description and Reference clause in the MIB module in this document. So the comment -- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get -- published ahead of this draft, RFC3513 has been agreed to be a -- sufficient replacement instead. could also be clarified as a specific instruction. Note that since the I-D is a normative reference, you don't have to worry about the order of publication. --- SnmpTLSFingerprint Some problem with line feeds? --- Do you need to worry about discontinuities with your counters?
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
(2011-05-25)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
(was No Record, No Objection)
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown