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 [email protected] www.trevilon.com > On Oct 5, 2022, at 4:53 AM, tom petch <[email protected]> wrote: > > From: OPSAWG <[email protected]> on behalf of Joe Clarke (jclarke) > <[email protected]> > 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 <[email protected]> > Date: Tuesday, October 4, 2022 at 10:37 > To: Joe Clarke (jclarke) <[email protected]> > Cc: [email protected] <[email protected]> > 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) > 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]<mailto:[email protected]> > www.trevilon.com<http://www.trevilon.com> > > > On Oct 3, 2022, at 12:20 PM, Joe Clarke (jclarke) > <[email protected]<mailto:[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. > Please work through and address these. Thanks. > > Joe > > From: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> > Date: Tuesday, September 27, 2022 at 13:00 > To: Kenneth Vaughn <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[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]<mailto:[email protected]>> > Date: Tuesday, September 27, 2022 at 12:51 > To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[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
