Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04

[Dan Romascanu <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> > On Feb 20, 2018, at 05:44, Dan Romascanu <[e-mail]> wrote:
> >
> > 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.’
>
> 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?
>

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


> > 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.
>
> 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
> > this document.
>
> 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]
>

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


>
> PR submitted:
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62
>
> > 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/
>
> I stole this wording from another RFC so I’m leaning towards leaving it as
> is.
>

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


>
> spt
>