I've updated the document; the only items that remain in the id-nits check (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-09.txt&submissioncheck=True <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-09.txt&submissioncheck=True>) are:
> == Unused Reference: 'STD58' is defined on line 1472, but no explicit > reference was found in the text STD 58 is referenced in the MIB but I am guessing that the checking tool does not check that content? (I don't think I am supposed to use the formal cross-referencing in the MIB section) > > -- Obsolete informational reference (is this intentional?): RFC 5246 > (Obsoleted by RFC 8446) This reference is intentional as we are identifying the initial entries for the SNMP-TLSTM HashAlgorithm Registry, which needs to point to the older RFC. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-571-331-5670 cell [email protected] www.trevilon.com > On Oct 3, 2022, at 12:20 PM, Joe Clarke (jclarke) <[email protected]> wrote: > > I’m working through the shepherd write-up now. As part of that, I am > reviewing the IDNITS checks, and there are a number of warnings. > > See > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-08.txt > > <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-08.txt>. > Please work through and address these. Thanks. > > Joe > > From: Joe Clarke (jclarke) <[email protected]> > Date: Tuesday, September 27, 2022 at 13:00 > To: Kenneth Vaughn <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07 > > Thanks for refreshing my memory. The clutter argument is sound. I do wish > we would have gotten a SEC DIR review, but it will certainly get some eyes > from the IESG. > > I’ll mention this point in the shepherd write-up, and we’ll leave things the > way they are text-wise for now. > > Joe > > From: Kenneth Vaughn <[email protected]> > Date: Tuesday, September 27, 2022 at 12:51 > To: Joe Clarke (jclarke) <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07 > > The concept of automatically registering new hash algorithms was discussed > during a May e-mail thread. Jürgen objected to the automatic recording of > values and Tom Petch argued for the automatic registration. > > While I don't think we ever achieved "agreement" on the position, we > concluded with consensus (i.e., no sustained objections) on the wording in > the current draft due to the fact that there was agreement that there was no > requirement for our fingerprint to use the same hash as used by the TLS layer > (and thus no technical requirement to link the two registries). From that > point, we concluded that if anyone wanted a value, they "would find the > energy to register it" and we would not clutter the registry with unnecessary > values. > > Personally, I see the argument on both sides and am fine with the consensus. > However, I could perhaps see softening the expert review statement to > automatically approve the request to add any hash algorithm that is already > approved for any version of TLS or DTLS rather than fording a consultation > with the TLS WG. > > I've made the other changes, but will hold off on implementing them until we > resolve this issue.. > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-571-331-5670 cell > [email protected] <mailto:[email protected]> > www.trevilon.com <http://www.trevilon.com/> > > > > On Sep 27, 2022, at 10:36 AM, Joe Clarke (jclarke) <[email protected] > <mailto:[email protected]>> wrote: > > I am reviewing -07 of this draft ahead of the shepherd review. I have found > a few nits, but at a larger level, I think more text might be needed for IANA > around how to handle the new TLS hash registry. Currently, the draft talks > about a sync to “IANA TLS HashAlgorithm Registry”, which is good. But what > if new values get added to the cipher suites registry? For example, what > about GOST variants? I would think if the TLS 1.3 spec (and their experts) > allow for these algorithms would this registry not just take them? What > would the expert review consider when adding new algorithms here? > > In terms of nits: > > Search for “ciphersuites” and change to “cipher suites” as that is more > consistent with other documents (and I think you use both in this document). > > > Section 2.1: > > s/Values zero through 2/Values 0 through 2/ > > > Section 2.3: > > s/stated that TLSTM/states that TLSTM/ > > > Section 3.1: > > s/request, offer or use/request, offer, or use/ > > > Section 7 > > Add a period to the end of the section. > > Joe
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
