All of the edits related to idnits have been addressed in draft-ietf-opsawg-tlstm-update-10. As discussed below, I tweaked the wording for SnmpTLSAddress to require conformance to 1123 and 5890 when it is intended to represent a hostname and I made those normative references. The only issues that the indits tool shows now are two "comments" about obsolete informational references, but these references are needed because: 1. The definition of the proposed hash table needs to reference RFC 5246 2. The revision history of the MIB contains a revision clause that indicates it originated in RFC 5953
Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com > On Oct 7, 2022, at 8:25 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: > > I’ve always been told (and it makes sense) that one must understand normative > references so to implement the given spec. > > This is a weird case. The TLS address doesn’t need to be a hostname and, if > it is, it doesn’t need to be an i18n hostname. So, one wouldn’t need to > understand RFCs 1123 and 5890 to implement this spec if they only used IP > addresses. > > But for completeness, I would recommend doing option #4 below (as you added > normative language to v4 and v6 addresses already). > > Joe > > From: Kenneth Vaughn <kvau...@trevilon.com <mailto:kvau...@trevilon.com>> > Date: Thursday, October 6, 2022 at 4:27 AM > To: Joe Clarke (jclarke) <jcla...@cisco.com <mailto:jcla...@cisco.com>> > Cc: opsawg@ietf.org <mailto:opsawg@ietf.org> <opsawg@ietf.org > <mailto:opsawg@ietf.org>>, tom petch <ie...@btconnect.com > <mailto:ie...@btconnect.com>> > Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07 > > Joe, et al. > > I am working in a draft that includes the text suggested by Tom (e..g, "This > module makes reference to"). I have also ensured that the list of references > is accurate and properly classified between normative and informative. While > doing this, I noticed that RFC 6353 seems to treat two RFCs differently, > despite the text referring to them in a similar fashion. Specifically, the > MIB contains the following text, which is repeated in the updated MIB: > > A hostname is always in US-ASCII (as per RFC 1123); internationalized > hostnames are encoded as A-labels as specified in > RFC 5890. > > Neither of these RFCs are referenced in any other way in RFC 6353, but RFC > 1123 is listed as a normative reference while RFC 5890 as an informative > reference. It seems to me that the two documents should be referenced in the > same fashion, but I am not sure which type is most correct. A basic reading > of the text implies that this is just an informative fact; but I believe the > intent is that the "is always" and "are" expressions are intended to be "MUST > be" expressions - and parallel the prior paragraphs that describe IPv4 and > IPv6 addresses. So I see the following options; I know what ISO would like, > but I am interested in hearing which option is the best to conform with IETF > rules... > 1) leave as is (i.e., no change to MIB module, keep RFC 1123 as normative and > EFC 5890 as informative) > 2) no change to MIB module, make both RFC 1123 and RFC 5890 normative > 3) no change to MIB module, make both RFC 1123 and RFC 5890 informative > 4) Replace the "is always" and "are" in the text above with "MUST be" and > make both RFC 1123 and RFC 5890 normative > > Thanks for your advice > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-571-331-5670 cell > kvau...@trevilon.com <mailto:kvau...@trevilon.com> > www.trevilon.com <http://www.trevilon.com/> > > > On Oct 5, 2022, at 4:53 AM, tom petch <ie...@btconnect.com > <mailto:ie...@btconnect.com>> wrote: > > From: OPSAWG <opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org>> on > behalf of Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org > <mailto:jclarke=40cisco....@dmarc.ietf.org>> > Sent: 04 October 2022 17:45 > > Thanks, Ken. I saw your updates, and I agree with you on 5246. > > But now that I am done with my shepherd write-up, I notice that there are a > slew of references in the MIB that are not reflected in the document > references (e.g., 1123, 5890, etc.). Given that the full MIB is included in > this new document, you should include the same references in the Norm/Inform. > > <tp> > This has been a problem with YANG for years and the accepted solution is to > include a section 4.1 'This module makes references to [RFC1123], [RFC5890] > etc ' > > Consistency with YANG would be good:-) > > Tom Petch > > Joe > > From: Kenneth Vaughn <kvau...@trevilon.com <mailto:kvau...@trevilon.com>> > Date: Tuesday, October 4, 2022 at 10:37 > To: Joe Clarke (jclarke) <jcla...@cisco.com <mailto:jcla...@cisco.com>> > Cc: opsawg@ietf.org <mailto:opsawg@ietf.org> <opsawg@ietf.org > <mailto:opsawg@ietf.org>> > Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07 > 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 > kvau...@trevilon.com > <mailto:kvau...@trevilon.com><mailto:kvau...@trevilon.com > <mailto:kvau...@trevilon.com>> > www.trevilon.com <http://www.trevilon.com/><http://www.trevilon.com > <http://www.trevilon.com/>> > > > On Oct 3, 2022, at 12:20 PM, Joe Clarke (jclarke) <jcla...@cisco.com > <mailto:jcla...@cisco.com><mailto:jcla...@cisco.com > <mailto:jcla...@cisco.com>>> 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) <jcla...@cisco.com > <mailto:jcla...@cisco.com><mailto:jcla...@cisco.com > <mailto:jcla...@cisco.com>>> > Date: Tuesday, September 27, 2022 at 13:00 > To: Kenneth Vaughn <kvau...@trevilon.com > <mailto:kvau...@trevilon.com><mailto:kvau...@trevilon.com > <mailto:kvau...@trevilon.com>>> > Cc: opsawg@ietf.org <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org > <mailto:opsawg@ietf.org>> <opsawg@ietf.org > <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org <mailto:opsawg@ietf.org>>> > 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 <kvau...@trevilon.com > <mailto:kvau...@trevilon.com><mailto:kvau...@trevilon.com > <mailto:kvau...@trevilon.com>>> > Date: Tuesday, September 27, 2022 at 12:51 > To: Joe Clarke (jclarke) <jcla...@cisco.com > <mailto:jcla...@cisco.com><mailto:jcla...@cisco.com > <mailto:jcla...@cisco.com>>> > Cc: opsawg@ietf.org <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org > <mailto:opsawg@ietf.org>> <opsawg@ietf.org > <mailto:opsawg@ietf.org><mailto:opsawg@ietf.org <mailto:opsawg@ietf.org>>> > 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 > kvau...@trevilon.com > <mailto:kvau...@trevilon.com><mailto:kvau...@trevilon.com > <mailto:kvau...@trevilon.com>> > www.trevilon.com <http://www.trevilon.com/><http://www.trevilon.com/ > <http://www.trevilon.com/>> > > > > > On Sep 27, 2022, at 10:36 AM, Joe Clarke (jclarke) <jcla...@cisco.com > <mailto:jcla...@cisco.com><mailto:jcla...@cisco.com > <mailto:jcla...@cisco.com>>> 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
