AD review comments

[seanturner]

• Section 3 - See Addressing AD comments #61

    Setting a value to "Y" or "D" in the "Recommended" column requires
    IETF Standards Action [RFC8126]. Any state transition to or from a
    "Y" or "D" value requires IESG Approval.
  

Isn't this easier written as:

    Setting a value to "Y" or "D" in the "Recommended" column requires
    IETF Standards Action [RFC8126] or IESG Approval.

This appears in a number of sections in the document.

• Section 4 TLS ExtensionType Values - See Addressing decimal #62 - Awaiting response from PW

    Values with the first byte in the range 0-254 (decimal) are
    assigned via Specification Required [RFC8126].  Values with the
    first byte 255 (decimal) are reserved for Private Use [RFC8126].
  

I'd rather not let IANA figure out decimal network order byte math. Or
require everyone to do that math when checking the registry. Why not:

    Values in the range 0-65279 are assigned via Specification Required
    [RFC8126]. Values in the range 65280-65535 are reserved for Private
    Use [RFC8126].

Also, this is not true for:

    65281   renegotiation_info

which is clearly not usable for Private Use. Maybe it makes sense to say:

    Values in the range 0-65279 are assigned via Specification Required
    [RFC8126]. Values in the range 65280-65295 are Reserved. Values in
    the range 65296-65535 are reserved for Private Use [RFC8126].

This then leaves 0xff00-0xff0f for whatever the reason for 65281 was to be
able to happen a few more times, and keep the private range valid without
strange exceptions.

• Section 5 TLS Cipher Suites Registry - see email

This section contains some reasoning why it is Discouraging things. The current
IANA registry also contains such reasoning on the form of notes, but this section
does not add to the notes. So now this inforation is splintered between RFC and
Registry. I think the easiest fix is to add these few reasons specified here
as Note: to the IANA registry.

Note that this registry states:

    When this registry is modified, the YANG module
    "iana-tls-cipher-suite-algs" [iana-tls-cipher-suite-algs] must
    be updated as defined in [RFC9645].

Has this happened or is it scheduled? If so who is the contact I can follow up with?

• Section 6 TLS Supported Groups - see Addressing AD comments #61

    * Replace the registry range table note column for the 0-255,
      512-65535 range with "Unallocated".
  

This makes no sense. That current line with its note reads:

    0-255, 512-65535        Specification Required  Elliptic curve groups

I understand that the note should remove the text "Elliptic curve groups",
but it makes no sense to add "Unallocated" because the range does have
allocations in it. Maybe just instruct IANA to remove the note "Elliptic
curve groups" ?

• Section 11 TLS ClientCertificateTypes registry - see Addressing AD comments #61

The registry name is not "TLS ClientCertificateTypes" registry, but
"TLS ClientCertificateTypes Identifiers" registry.