Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy <[e-mail]>]

On Mon, 17 Oct 2022 at 16:28, tom petch <[e-mail]> wrote:

> inline <tp3> one minor editorial comment plus a technical one which I do
> not know the answer to.
>
> From: tirumal reddy <[e-mail]>
> Sent: 14 October 2022 14:01
>
> On Fri, 14 Oct 2022 at 16:46, tom petch <[e-mail]<mailto:
> [e-mail]>> wrote:
> From: tirumal reddy <[e-mail]<mailto:[e-mail]>>
> Sent: 14 October 2022 09:22
>
> On Thu, 13 Oct 2022 at 16:55, tom petch <[e-mail]<mailto:
> [e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
> wrote:
> From: tirumal reddy <[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> 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.
>

Thanks, fixed in git repo.


>
> 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
>

We will publish the revised version after the review from YANG Doctor and
the response to your question in netmod list.

Cheers,
-Tiru


>
> 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 <
> [e-mail]<mailto:[e-mail]
> ><mailto:[e-mail]<mailto:
> [e-mail]>><mailto:[e-mail]
> <mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>>
> 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 <[e-mail]<mailto:[e-mail]
> ><mailto:[e-mail]<mailto:[e-mail]>><mailto:
> [e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>> on behalf of
> Henk Birkholz <[e-mail]<mailto:
> [e-mail]><mailto:[e-mail]
> <mailto:[e-mail]>><mailto:
> [e-mail]<mailto:[e-mail]
> ><mailto:[e-mail]<mailto:
> [e-mail]>>>>
> > 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
> >> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:
> [e-mail]>><mailto:[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:
> [e-mail]>><mailto:[e-mail]<mailto:[e-mail]><mailto:
> [e-mail]<mailto:[e-mail]>>>
> > https://www.ietf.org/mailman/listinfo/opsawg
>