Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server

From: Dhruv Dhody <[email-masked]>
Date: Tue, 13 Apr 2021 14:12:51 +0530

Hi Mahesh, WG,

I have reviewed the draft. The PCE YANG uses these groupings and I am happy
to see the WG make progress on this I-D.

Few comments -
- Both abstract and introduction say that the first module is the TLS
client whereas the first module defined in this I-D is the TLS common.
- I am wondering if anything needs to be done for the older versions of TLS
which are made historic. The use of features helps, is there any other
guidance that needs to be given?
- Why is there no identity for TLS 1.3?
- For the feature tls-1_3, the description says 1.2
- Copyright year in the YANG modules is still 2020
- Authors in the YANG module is inconsistent with the I-D
- Reference used in YANG (FIPS PUB 180-4) needs to be added in the I-D as
well.

Thanks!
Dhruv

On Sat, Mar 27, 2021 at 4:01 AM Mahesh Jethanandani <[email-masked]>
wrote:

>
> We are starting a 2 week WGLC for draft-ietf-netconf-tls-client-server
> version 23.
>
> https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/>
>
> Please respond on this thread indicating your support or concerns about
> why this document should/should not be adopted.
>
> We are particularly interested in statement of the form:
>
> - I have reviewed the draft and found no issues.
> - I have reviewed the draft and found the following issues …
>
> This WGLC will conclude on Friday, April 9. An IPR call will be issued
> separately.
>
> Thank you.
>
> Mahesh & Kent (as co-chairs)
>
>
>
>
>
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Apr 2021 23:19:53 +0000

Hi Dhruv,

Thank you for your review!

Below are responses to your comments.

K.

> On Apr 13, 2021, at 4:42 AM, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi Mahesh, WG,
> 
> I have reviewed the draft. The PCE YANG uses these groupings and I am happy to see the WG make progress on this I-D.

:)

> Few comments -
> - Both abstract and introduction say that the first module is the TLS client whereas the first module defined in this I-D is the TLS common.

Fixed (also fixed in other drafts where the issue arose)

> - I am wondering if anything needs to be done for the older versions of TLS which are made historic. The use of features helps, is there any other guidance that needs to be given?

We could set the “status” to “deprecated”.  That said, it's one thing to say that a protocol is deprecated and another to say that the configuration for a still somewhat widely-used deprecated-protocol is deprecated…thoughts?

> - Why is there no identity for TLS 1.3?

Because the draft has been a work in progress for longer then TLS 1.3  ;)

Just added an identity for 1.3.

> - For the feature tls-1_3, the description says 1.2

Fixed!

> - Copyright year in the YANG modules is still 2020

Fixed (in all drafts)

> - Authors in the YANG module is inconsistent with the I-D

Correct, Gary Wu helped with the YANG module only (in the “ssh” draft also).  For both drafts, I’ve created a new “Contributors” section to better call out his contribution.

> - Reference used in YANG (FIPS PUB 180-4) needs to be added in the I-D as well. 

Reference added.

Thanks!

K.

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 20 Apr 2021 12:09:42 +0530

Hi Kent,

> - I am wondering if anything needs to be done for the older versions of
> TLS which are made historic. The use of features helps, is there any other
> We could set the “status” to “deprecated”.  That said, it's one thing to
> say that a protocol is deprecated and another to say that the configuration
> for a still somewhat widely-used deprecated-protocol is
> deprecated…thoughts?
>
>
>
I agree that we need to allow the configuration of older TLS versions in
the YANG module.

I found this comment from Ben to be useful -
https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA/
. I ended up putting MD5 and SHA-1 support under a feature 'deprecated'. In
this case, I think just adding some text in the description around the
existing features for older TLS could also do the job.

Thanks for taking my comments into consideration!
Dhruv

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Apr 2021 01:11:31 +0000

Hi Dhruv,

> I agree that we need to allow the configuration of older TLS versions in the YANG module. 
> 
> I found this comment from Ben to be useful - https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA/ <https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA/>  . I ended up putting MD5 and SHA-1 support under a feature 'deprecated’.

Wait, you put the support under a feature called “deprecated” or under a deprecated feature (called something else?

> In this case, I think just adding some text in the description around the existing features for older TLS could also do the job.  

That’s easy enough.  For each feature except 1.3, I added to the “description” statement:

    "Please note that TLS 1.? is obsoleted and thus it is NOT
     RECOMMENDED to enable ths feature.”

Is it what you had in mind?

K.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 21 Apr 2021 09:50:19 +0530

Hi Kent,

On Wed, Apr 21, 2021 at 6:41 AM Kent Watsen <[email-masked]> wrote:

> . I ended up putting MD5 and SHA-1 support under a feature 'deprecated’.
>
>
> Wait, you put the support under a feature called “deprecated” or under a
> deprecated feature (called something else?
>
>
The former. Maybe I can use a different name to avoid confusion.

>
>
> In this case, I think just adding some text in the description around the
Yes!

Thanks!
Dhruv