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

[tom petch <[e-mail]>]

From: tirumal reddy <[e-mail]>
Sent: 14 October 2022 09:22

On Thu, 13 Oct 2022 at 16:55, tom petch <[e-mail]<mailto:[e-mail]>> wrote:
From: tirumal reddy <[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.

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

does profile-supported have a default?

s.8
There is a template for YANG security as referenced by RFC8407 which I note is not used here

s.9
I note that this is TLS and not (D)TLS. Is that intended?  s.4 uses the latter

s.10
When specifying Expert Review, guidance is often given as to what the experts should look for and where.

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