On Apr 3, 2018, at 23:09, Adam Roach <a...@nostrum.com> wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-tls-iana-registry-updates-04: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work everyone put in on this document. I have a handful of > comments, ranging from nits to minor issues. They appear in document order. > > --------------------------------------------------------------------------- > > Title: > > Please expand "TLS" and "DTLS" in the title. See > https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
Sure, but I have also just sent a request off to get TLS and DTLS added as well-known abbreviations so I’m hoping to change it back during AUTH48 ;) > --------------------------------------------------------------------------- > > Abstract: > > Please include the list of updated RFCs in the abstract. See > <https://www.ietf.org/standards/ids/checklist/> §3.1.D. The current > formulation > of "This document updates many (D)TLS RFCs (see updates header)" is > problematic > due to the factors described in the final paragraph of RFC 7322 §4.3. See Ben’s response. > --------------------------------------------------------------------------- > > §2: > >> Instead of listing the changes and their rationale in this, >> the introductory, section each section provides rationale for the >> proposed change(s). > > There's something awkward with the commas here. Perhaps you mean: > >> Instead of listing the changes and their rationale in this, >> the introductory section, each section provides rationale for the >> proposed change(s). Yep that does read better. > --------------------------------------------------------------------------- > > §8: > > This section doesn't indicate anything about the disposition of > "token_binding," which is due to (potentially) expire in 11 months. Given that > the temporary property of this registration is due only to the previous policy > that this document is obsoleting, it seems that this document should instruct > IANA to remove the temporary status from the "token_binding" TLS > ExtensionType. I think that would be terribly unfair especially since the draft defining the token_binding extension is on the 5/10 telechat ;) https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ How about I just get them to add a Recommended = Yes column. > --------------------------------------------------------------------------- > > §8: > > The table that adds a "Recommended" column to the TLS ExtensionType does not > indicate values for "token_binding" or "cached_info." I suggest either adding > them, or adding text to explain their omission. Can’t believe I forgot cached_info. I’ll add a note about token_binding. I also just sent the WG a note about needing to add the Recommended “Yes” value to their IANA considerations. > --------------------------------------------------------------------------- > > §9: > >> assigned via Specification Required {{RFC8126}}. Values with the >> first byte 255 (decimal) are reserved for Private Use {{RFC8126}}. > > Nit: the "{{...}}" citation style is probably not what you intended. Ah it did that because it’s a code snipet :(. Fixed the multiple occurrences. > --------------------------------------------------------------------------- > > §13: > >> o A "Recommended" column to the TLS Exporter Label registry. The >> table that follows has been generated by marking Standards Track >> RFCs as "Yes" and all others as "No". > > No rows are marked "No." Presumably, the text above should instead say "any > values not indicated in the table below [will be/have been] marked 'No’" yeah I think it’s that the others are "to be marked” (same for the cipher suites). > --------------------------------------------------------------------------- > > §14: > >> 120 no_application_protocol Y [RFC7301] > > Every other updated table is amended to also point to this document. I presume > that omitting it from this entry is an oversight, and that it should instead > be: > >> 120 no_application_protocol Y [RFC7301] [RFCthis] Yep. See the following PR to address the above changes: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/71 > --------------------------------------------------------------------------- > > §17: > >> o [SHALL update/has updated] the TLS HashAlgorithm Registry to list >> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry >> to list values 4-223 as "Reserved". > > HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8. > Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223", > respectively. https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65 > --------------------------------------------------------------------------- > > §17: > >> Despite the fact that the HashAlgorithm and SignatureAlgorithm >> registries are orphaned, it is still import to warn implementers of > > nit: "important" > >> pre-TLS1.3 implementations about the dangers of blinding implementing > > nit: “blindly" https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
