inline <tp3> one minor editorial comment plus a technical one which I do not know the answer to.
From: tirumal reddy <[email protected]> Sent: 14 October 2022 14:01 On Fri, 14 Oct 2022 at 16:46, tom petch <[email protected]<mailto:[email protected]>> wrote: From: tirumal reddy <[email protected]<mailto:[email protected]>> Sent: 14 October 2022 09:22 On Thu, 13 Oct 2022 at 16:55, tom petch <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: From: tirumal reddy <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> Sent: 13 October 2022 07:57 Thanks Tom for the review. Yes, we will fix the references identified by Tom. <tp> -09 looks better. I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a rationale for that. I prefer the former but that mix of characters may confuse others. Good point, fixed in my copy https://github.com/tireddy2/mud-tls/blob/master/draft-ietf-opsawg-mud-tls-10.txt. I see a number of editorial issues - I do not know if you want to look at those now or leave them to Last Call. Please feel free to raise the editorial issues, we will fix them. One slightly technical one is that it is very rare to start a YANG prefix with ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT IMHO. Thus acl has a prefix of acl so I would see the augment as acl-tls and not ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment is perhaps better as ietf-mud-tls. We followed the format similar to ietf-access-control-list (YANG data model of network ACL) and ietf-mud to be consistent. <tp2> Um, that is not what I see. It is the prefix I have in mind where RFC8519 specifies a prefix of acl and that is what you use in the import. An extension to that module could then have a prefix of acl-xxx or some such where you have specified ietf-acl-tls. It is that 'ietf' that I see as unusual. Got it, changed the prefix to "acl-tls". Editorially, not all of which you may want to fix at this time 'The YANG module specified in Section 5...' suggest adding the subsection since there is more than one 'specific terms are used' suggest using the terms here e.g. TLS and DTLS are used s.4 incapable to decipher perhaps 'unable to decipher' or 'incapable of deciphering' s.5.1 Add an Infornative Reference to RFC8340 for the meaning of tree diagrams s.5.2 /Simplified BSD/Revised BSD/ revision date is out of date SPKI probably needs expanding both in the body and in the YANG modules The description of certificate-authorities looks like it is too long for an RFC s.5.3 BSD license again revision date again s.5.4 ditto author e-mail address is not the same as elsewhere YANG import MUST have a reference clause which MUST be a Normative reference Thanks, I fixed all the above editorial issues. <tp3> Almost. I am still seeing a YANG import in s.5.4 which has no reference clause. Also, there is a technical YANG issue to which I do not know the answer and have posted that to the netmod list. AFAICT there has been no YANG Doctor review and it is an issue that at least some YANG Doctors would comment on Tom Petch does profile-supported have a default ? No. s.8 There is a template for YANG security as referenced by RFC8407 which I note is not used here Thanks, added note that it is not applicable to draft as it is not meant to be accessed via NETCONF/RESTCONF.. s.9 I note that this is TLS and not (D)TLS. Is that intended? s.4 uses the latter Fixed, it is supposed to be (D)TLS. s.10 When specifying Expert Review, guidance is often given as to what the experts should look for and where. Yes, I added details for Expert Review.. Cheers, -Tiru Tom Petch Cheers, -Tiru Tom Petch Cheers, -Tiru On Wed, 12 Oct 2022 at 18:37, Henk Birkholz <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> wrote: Hi Tom, would it be possible for you to augment your first comment with change proposals, if possible? @authors: it seems to me that the references issues Tom now provided in specific detail could be resolved in this thread in a timely manner. Is that correct? Viele GrΓΌΓe, Henk On 12.10.22 13:39, tom petch wrote: > From: OPSAWG > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> > on behalf of Henk Birkholz > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> > Sent: 06 October 2022 13:26 > > Dear authors and contributors, > > thank you for your hard work. As it seems that all existing issues have > been resolve, we'll move the I-D to write-up in the datatracker. > > Also, thanks Thomas Fossati for stepping up as shepherd! > > <tp> > My main comment on this remains the mix of two different YANG modules with > different life cycles; I expect that l will comment again on the Last Call > list to give this issue more exposure. > > Of lesser import, I cannot make sense of the references. > I see [RFC5246] which normally means that a reference has been created. Not > here, so there would seem to have been some chicanery involved, that this I-D > has not been produced by the usual IETF tools. > > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D > References. > > dtls13 is now an RFC. > > What is the difference between > draft-ietf-tls-dtls13: > and > "RFC DDDD: Datagram Transport Layer Security 1.3"; > ? > How do I find > "RFC CCCC: Common YANG Data Types for Cryptography"; > or > "RFC IIII: Common YANG Data Types for Hash algorithms"; ? > > Does tls-1-2 mean the same as tls-1.2? And is this the same as that which > the Netconf WG refers to as tls12? > > Tom Petch > > > For the OPSAWG co-chairs, > > Henk > > > On 29.09.22 10:27, Henk Birkholz wrote: >> Dear OPSAWG members, >> >> this email concludes the first WGLC call for >> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html. >> >> A few comments where raised. Authors/editors, please go ahead and >> address these as discussed on the list. >> >> >> For the OPSAWG co-chairs, >> >> Henk >> >> On 14.09.22 16:07, Henk Birkholz wrote: >>> Dear OPSAWG members, >>> >>> this email starts a two week period for a Working Group Last Call of >>> >>>> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html >>> >>> ending on Thursday, September 28th. >>> >>> The authors believe the Internet-Draft is ready for a WGLC and the >>> chairs agree. The draft has been discussed visibly at IETF 114 and >>> review feedback has been incorporated in -07. >>> >>> Please send your comments to the list and your assessment of whether >>> or not it is ready to proceed to publication before September 28th. >>> >>> >>> For the OPSAWG co-chairs, >>> >>> Henk >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
