Subject: Opsdir last call review of draft-ietf-tls-iana-registry-updates-04

From: Dan Romascanu <[email-masked]>
Date: Tue, 20 Feb 2018 02:44:37 -0800

Reviewer: Dan Romascanu
Review result: Has Issues

I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews
a great part of the IETF documents being processed by the IESG for the OPS ADs.
Please treat with these comments as with all other IETF LC comments. Please
wait for direction from your document shepherd or AD before posting a new
version of the draft.

This document which updates several TLS and DTLS RFCs describes a number of
changes to TLS IANA registries that range from adding notes to the registry all
the way to changing the registration policy. This is not a protocol or a
protocol update document, thus a full OPS-DIR review conforming to RFC 5706 is
not needed. From an operational point of view this document is important, as
operators may need to refer to IANA registries in their daily work of ensuring
functionality and maintaining networks where TLS and DTLS are used.

The document is Ready from an OPS-DIR perspective, with a few minor issues. The
issues listed below are useful for all categories of users of this document:
implementers, operators, end users. None is them is major, but it would be good
to be addressed before the document approval.

1. The document adds a Recommended column to many of the TLS registries. The
rationale and meaning of a parameter being or not being Recommended are
detailed in Section 6. It would be useful from an operator perspective to add
to the registries where the Recommended column is added a text similar to the
one in Section 6, that explains the rationale and the meaning. Something on the
lines of:

* 'If a parameter is marked as Recommended, implementations
   should support it. Adding a recommended parameter
   to a registry or updating a parameter to recommended status
   requires standards action. Not all parameters defined in standards
   track documents need to be marked as recommended.

   If an item is not marked as Recommended it does not necessarily mean
   that it is flawed, rather, it indicates that either the item has not
   been through the IETF consensus process, has limited applicability,
   or is intended only for specific use cases.'

2. Also Section 6. All sections that add Recommended columns need to also
modify the References column in order to add a reference to this document.

3. Section 14. IANA shall update the reference for this registry to also refer
this document.

4. Section 18. s/ Criteria that SHOULD be applied by the Designated Experts
includes determining whether the proposed registration duplicates existing
functionality/Criteria that SHOULD be applied by the Designated Experts
includes determining whether the proposed registration does not duplicate
existing functionality/

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Feb 2018 09:11:46 -0500

> On Feb 20, 2018, at 05:44, Dan Romascanu <[email-masked]> wrote:
> 
> Reviewer: Dan Romascanu
>   or is intended only for specific use cases.’

I’m sure that adding this note wouldn't hurt, but we’re updating all of the registries that are getting a Recommended column to point to this document. 

So I could could go either way here - what do other folks think?

> modify the References column in order to add a reference to this document.

So, I think we’ve done that (double checking):

- s8 adds a recommended column and updates references
- s9 adds a recommended column and updates references
- s10 adds a recommended column and updates references
- s13 adds a recommended column and updates references
- s15 adds a recommended column and updates references

> 3. Section 14. IANA shall update the reference for this registry to also refer

s4 also updates the references to this document so at first I was confused, but I think you’re looking for:

OLD:

  120   no_application_protocol  Y  [RFC7301]

NEW: 

  120   no_application_protocol  Y  [RFC7301][this-RFC]

PR submitted:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62

> includes determining whether the proposed registration does not duplicate

I stole this wording from another RFC so I’m leaning towards leaving it as is.

spt

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Feb 2018 18:02:26 +0200

Hi Sean,

Thanks for the answer and for addressing my comments.

Short observations are inserted.

Regards,

Dan

On Tue, Feb 27, 2018 at 4:11 PM, Sean Turner <[email-masked]> wrote:

> I’m sure that adding this note wouldn't hurt, but we’re updating all of
> the registries that are getting a Recommended column to point to this
> document.
>

I *think* that the note would help - clarifying what 'not marked as
Recommended' means vs. (possibly) writing 'no' in the Recommended column.

> s4 also updates the references to this document so at first I was
> confused, but I think you’re looking for:
>
> OLD:
>

Yes, indeed, this is what I was looking for.

> I stole this wording from another RFC so I’m leaning towards leaving it as

You are the native English speaker, but my acquired English skills tell me
that 'criteria' means what should happen (avoid duplication).

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Feb 2018 11:25:29 -0500

>  or is intended only for specific use cases.’

Wouldn't it be sufficient to add a note a the bottom of the registry that says:

   If an item is marked as not recommended it does not necessarily mean
   that it is flawed, rather, it indicates that either the item has not
   been through the IETF consensus process, has limited applicability,
   or is intended only for specific use cases.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Feb 2018 10:53:09 -0600

>    or is intended only for specific use cases.

Basically.  But, "not marked as recommended", please.

-Ben

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Feb 2018 16:01:34 -0500

> On Feb 27, 2018, at 11:53, Benjamin Kaduk <[email-masked]> wrote:
> 

Check out the PR: