From: Jürgen Schönwälder <j.schoenwael...@jacobs-university.de> Sent: 05 January 2022 15:04
USM is a part of STD62 and I do not think it is the job of an update of RFC 6353 to make any changes concerning STD62 and the status of USM. SNMP RFCs usually talk about what is mandatory to implement (to guarantee some level of interoperability), they usually are silent about enablement (whatever that means) and about usage policies. I believe the focus of an update should be on the technical aspects necessary to clarify to use SNMP over (D)TLS 1.3 - focus on the mechanisms, staying away from any policies. <tp> I agree. A BCP is a formal document with almost the same status as a Proposed Standard as described in RFC2026 (ignoring the many updates thereto). Separately, an update to a Standard should go through the standards process which did not happen with the deprecation of older versions of (D)TLS. I flagged this when the deprecation was being reviewed but got no response. I suspect that the IESG found it too complicated to contemplate, although it is not without precedent. Possibly this I-D could become part of STD062 in years to come but I am doubtful. Tom Petch /js On Wed, Jan 05, 2022 at 08:39:30AM -0600, Kenneth Vaughn wrote: > 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 > kvau...@trevilon.com > www.trevilon.com > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
