Last Call Review of draft-ietf-tls-iana-registry-updates-04

Request Review of draft-ietf-tls-iana-registry-updates
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-03-01
Requested 2018-02-15
Authors Joseph Salowey, Sean Turner
Draft last updated 2018-02-20
Completed reviews Secdir Last Call review of -04 by Stefan Santesson (diff)
Opsdir Last Call review of -04 by Dan Romascanu (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-tls-iana-registry-updates-04-opsdir-lc-romascanu-2018-02-20
Reviewed rev. 04 (document currently at 05)
Review result Has Issues
Review completed: 2018-02-20


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/