AD review of draft-ietf-tls-rfc8447bis-10
I have some comments and small change requests. Do let me know if I got it
wrong.
Section 3
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
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
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
* 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
The registry name is not "TLS ClientCertificateTypes" registry, but
"TLS ClientCertificateTypes Identifiers" registry.
Paul
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
