Randy, If I properly understand your suggestion, you are requesting that we make the new document a stand-alone document and the group could separately consider the retirement of RFC 6353 - perhaps on a separate timeline. If this is an accurate summary of your request, it is largely captured by our original draft (https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/00/ <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/00/>). The only caveat is that version 00 did not include support for DTLS 1.3 because it had not been finalized when we wrote that draft. Once DTLS 1.3 was finalized, the number of changes became much smaller and the concept of doing an update seemed to make more sense, but it was still debated among our team members. We largely picked the update format just to show that either could be done. We are happy to follow the consensus of the group on this point. I think this is probably one of the two most important questions to answer (i.e., should we produce a stand-alone document or an update?)
The other key question (which might impact the answer to the first) is whether the change to the MIB is necessary or if we can convince IANA to maintain the one-octet hash algorithm identifier such that we can have confidence that there will always be a unique number that we can use. That would solve most of our problems (but perhaps add to the workload of IANA) as I think any changes to the MIB would become trivial. As a result, the update document would become very short. I would be very encouraged if we are able to gain consensus on those two topics by the end if IETF 112. 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 > On Oct 21, 2021, at 1:38 AM, Randy Presuhn > <[email protected]> wrote: > > Hi - > > On 2021-10-20 8:38 PM, Kenneth Vaughn wrote: >> I would like to present >> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ >> <https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/>. This >> document is a proposal to update to RFC 6353 (TLS Transport Model for SNMP) >> to reflect the needs of TLS 1.3. > > It seems to me that the document combines two distinct proposals: > (1) deprecating most of the MIB Module from RFC 6353 > (2) defining a new transport model and putting its management > interface into the gutted shell left behind from 6353. > > I think the document would be easier to digest if it were simply > crafted to be solely what its title says it is: a Transport Layer Security > Verion 1.3 (TLS 1.3) Transport Model for SNMPv3. Any > question of casting support for (D)TLS 1.2 into the outer darkness > of "historical" classification or deprecating 6353's MIB module's > definitions could then be handled separately. > > Randy > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
