Addressing OPSDIR IETF LC comments

draft-ietf-tls-iana-registry-updates.md

@@ -123,7 +123,7 @@ standards action.  Not all parameters defined in standards track
 documents need to be marked as recommended.
 
 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
+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.
 
@@ -159,21 +159,6 @@ updated] the TLS ExtensionType Values registry to:
 
 - Update the "Reference" to also refer to this document.
 
-- Add the following notes:
-
-Note:
-: Experts are to verify that there is in fact a publicly available
-standard.  An Internet Draft that is posted and never published or a
-standard in another standards body, industry consortium, university
-site, etc. suffices.
-
-Note:
-: As specified in {{RFC8126}}, assignments made in the Private Use
-space are not generally useful for broad interoperability.  It is
-the responsibility of those making use of the Private Use range to
-ensure that no conflicts occur (within the intended scope of use).
-For widespread experiments, temporary reservations are available.
-
 See {{expert-pool}} for additional information about the designated
 expert pool.
 
@@ -218,6 +203,32 @@ update/has updated] the TLS ExtensionType Values registry to:
 | session_ticket                  |         Yes |
 | renegotiation_info              |         Yes |
 
+IANA [SHALL update/has added] the following notes:
+
+Note:
+: Experts are to verify that there is in fact a publicly available
+specification.  An Internet Draft that is posted and never published or a
+specification in another standards body, industry consortium, university
+site, etc. suffices.
+
+Note:
+: As specified in {{RFC8126}}, assignments made in the Private Use
+space are not generally useful for broad interoperability.  It is
+the responsibility of those making use of the Private Use range to
+ensure that no conflicts occur (within the intended scope of use).
+For widespread experiments, temporary reservations are available.
+
+Note:
+: Extensions marked as "Yes" are those allocated via Standards Track
+RFCs.  Extensions marked as "No" are not.
+
+Note:
+: 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.
+
+
 NOTE:
 : The following is from {{I-D.ietf-tls-tls13}} and is included here to
 ensure aligment between these specifications.
@@ -353,14 +364,20 @@ suites have a significantly truncated authentication tag that represents
 a security trade-off that may not be appropriate for general
 environments.
 
+Note:
+: 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.
+
 IANA [SHALL add/has added] the following notes for additional
 information:
 
 Note:
 : The designated expert {{RFC8126}} only ensures that the specification
 is publicly available.  An Internet Draft that is posted and never
-published or a standard in another standards body, industry consortium,
-university site, etc. suffices.
+published or a standard in another standards body, industry
+consortium, university site, etc. suffices.
 
 Note:
 : As specified in {{RFC8126}}, assignments made in the Private Use
@@ -394,6 +411,12 @@ Note:
 Track RFCs.  Supported Groups marked as "No" are not; supported groups
 marked "No" range from "good" to "bad" from a cryptographic standpoint.
 
+Note:
+: 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.
+
 Note:
 : The designated expert {{RFC8126}} only ensures that the specification
 is publicly available.  An Internet Draft that is posted and never
@@ -454,6 +477,12 @@ Note:
 via Standards Track RFCs.  ClientCertificateTypes marked as "No" are
 not.
 
+Note:
+: 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.
+
 New Session Ticket TLS Handshake Message Type
 =============================================
 
@@ -519,6 +548,12 @@ Note:
 : Exporters Labels marked as "Yes" are those allocated via Standards
 Track RFCs.  Exporter Labels marked as "No" are not.
 
+Note:
+: 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.
+
 IANA [SHALL update/has updated] the reference for this registry to also
 refer to this document.
 
@@ -529,7 +564,7 @@ IANA [SHALL add/has added] the following entry to the TLS Alert
 Registry; the entry was omitted from the IANA instructions in
 {{!RFC7301}}:
 
-    120   no_application_protocol  Y  [RFC7301]
+    120   no_application_protocol  Y  [RFC7301][this-RFC]
 
 TLS Certificate Types
 =====================
@@ -556,6 +591,12 @@ Note:
 : Certificate Types marked as "Yes" are those allocated via Standards
 Track RFCs.  Certificate Types marked as "No" are not.
 
+Note:
+: 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.
+
 IANA [SHALL update/has updated] the reference for this registry to also
 refer this document.