Tom, Joe, Wes, et al: I propose that we address the overarching questions first as they potentially affect the entire scope of the draft. Namely:
Can we can continue to use <> <>https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18> for the TLSHashAlgorithm identifier? Doing so would greatly simplify the update and would eliminate any revision to the SNMP-TLS-TM-MIB. I believe Joe Clarke is taking the lead to check with the registry experts to see if this can continue to be used. If so, I propose that the next I-D be changed to offer an update to RFC 6353 (rather than a new or replacement RFC). As such, the MIB would be removed, which would shorten the I-D to just a few pages. RFC 8996 (BCP 195) updated RFC 6353 with a prohibition on using (D)TLS versions prior to 1.2. What is the status of an IETF BCP? In other words, can we reference a Best Current Practice or do we restate the requirements (i.e, is a BCP considered normative text – or is it considered to be a lower precedence since it was approved through a shortened process?). I would think that a BCP is relatively informal and that we would want to formalize the rules in our document. RFC 6353 indicated that it was "NOT RECOMMENDED" to use a non-transport-aware security model, including USM and previous versions of SNMP. However, support for USM remained a requirement (inherited from STD 62) and other comments were included regarding implementations that supported previous versions of SNMP. Given that a system is only as secure as its weakest link, what should our position be on the use and support of USM and previous versions of SNMP? a. Support and enablement mandatory b. Support mandatory; enablement silent; use not recommended (RFC 6353 for USM) c. Support mandatory; ability to disable mandatory d. Support optional/silent; use not recommended (RFC 6353 for old SNMP versions) e. Support optional/silent; ability to disable, if supported, mandatory f. Support prohibited Answers to the above should provide a good amount of direction to the effort; if we are successful in having IANA maintain the one-octet identifier, most of the other comments suggested by Tom will be rendered moot by removing the MIB. The others are largely editorial and can be addressed once we have the other questions answered. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell [email protected] www.trevilon.com >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
