Okay PRs are ready to merge: https://github.com/tlswg/rfc8447bis/pull/61 https://github.com/tlswg/rfc8447bis/pull/62
And I found some typos: https://github.com/tlswg/rfc8447bis/pull/63 Will merge Sunday (when submission window re-opens) and spin a new version, unless you say otherwise. spt > On Mar 10, 2025, at 8:10 PM, Paul Wouters <paul.wout...@aiven.io> wrote: > > > On Fri, Mar 7, 2025 at 12:52 PM Sean Turner <s...@sn3rd.com > <mailto:s...@sn3rd.com>> wrote: >> >> >>> On Mar 6, 2025, at 9:33 PM, Paul Wouters >>> <paul.wouters=40aiven...@dmarc.ietf.org <mailto:40aiven...@dmarc.ietf.org>> >>> wrote: >>> >>> 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. >> >> Will do. BTW - one choice for you below. >> >>> 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. >> >> This sentence structure appears in 10 places. The same types of sentences >> appear in 5 places in RFC 8447, but there is it "Y" and "N" not “Y" an "D". >> This I-D updates all of those 5 in RFC 8447, so sure we can make this change. > > Great. >>> 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. >> >> I don’t think that has actually been much of a problem because it has been >> specified this way since RFC 4346. So, we got two options: >> >> 1) leave it alone >> 2) drop the offending text because we are not changing anything WRT to the >> ranges in those 3 sections. If we do that I would suggest: >> >> OLD: >> >> * Change the registration procedure to: >> >> 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]. Setting a >> "Recommended" column value to "Y" or "D" requires Standards Action >> [RFC8126]. >> Any state transition to or from a "Y" or "D" value requires >> IESG Approval. >> >> NEW: >> >> * Adjust the registration procedure related to setting the “Recommended” >> column as follows: >> >> Setting a value to "Y" or "D" in the "Recommended" column requires >> IETF Standards Action [RFC8126] or IESG Approval. >> >> Which do you prefer? > > I prefer 2) >>> 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" ? >> >> I can get behind that. > > Okay >>> Section 11 TLS ClientCertificateTypes registry >>> >>> The registry name is not "TLS ClientCertificateTypes" registry, but >>> "TLS ClientCertificateTypes Identifiers" registry. >> >> You are correct! > > Good :) > > Paul
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
