On Fri, 14 Oct 2022 at 16:46, tom petch <ie...@btconnect.com> wrote: > From: tirumal reddy <kond...@gmail.com> > Sent: 14 October 2022 09:22 > > On Thu, 13 Oct 2022 at 16:55, tom petch <ie...@btconnect.com<mailto: > ie...@btconnect.com>> wrote: > From: tirumal reddy <kond...@gmail.com<mailto:kond...@gmail.com>> > 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. > > 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 < > henk.birkh...@sit.fraunhofer.de<mailto:henk.birkh...@sit.fraunhofer.de > ><mailto:henk.birkh...@sit.fraunhofer.de<mailto: > henk.birkh...@sit.fraunhofer.de>>> 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 <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org > ><mailto:opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>>> on > behalf of Henk Birkholz <henk.birkh...@sit.fraunhofer.de<mailto: > henk.birkh...@sit.fraunhofer.de><mailto:henk.birkh...@sit.fraunhofer.de > <mailto:henk.birkh...@sit.fraunhofer.de>>> > > 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 > >> OPSAWG@ietf.org<mailto:OPSAWG@ietf.org><mailto:OPSAWG@ietf.org<mailto: > OPSAWG@ietf.org>> > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org<mailto:OPSAWG@ietf.org><mailto:OPSAWG@ietf.org<mailto: > OPSAWG@ietf.org>> > > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
