Hi, I strongly prefer option 3. The future-proofing and avoidance of a proliferation of new columns in the IANA registries is paramount. The points about QUIC highlight the near-term need to clean up this this issue.
Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmu...@gmail.com PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jun 26, 2019 at 1:32 PM Sean Turner <s...@sn3rd.com> wrote: > While these IANA points are minor, what is being considered here affects > all TLS registries so please let us know what you think about the proposal > for the following issue: > > > Issue: > > The IANA DEs (Designated Experts) think that the registry should indicate > that the connection_id is DTLS-Only. This is the first extension defined > that would need this marking. Currently, there is no “DTLS-Only” column in > the TLS ExtensionType Values registry nor is there a "DTLS-OK" column like > there are in the TLS Parameter registries [0]. Note none of the TLS > extension registries [1] have a "DTLS-OK” column. > > > Proposals (there might be more): > > 0. Do nothing > > 1. Add a note to the top of the registry that says connection_id is > DTLS-Only > > 2. Add a DTLS-Only column to the TLS ExtensionType Values registry and > mark this one Y and all others N > > 3. Think about the future (inspired by Achiem in the GH repo): > > - Change the “DTLS-OK” column to "TLS/DTLS”. Allow values of TLS, DTLS, > or TLS/DTLS. > > - Mark all DTLS-OK=Y rows to “TLS/DTLS” and all DTLS-OK=N to “TLS”. [2] > > - Add “TLS/DTLS” column to the TLS ExtensionType Values registry and mark > the connection_id extension as “DTLS" and all others as “TLS/DTLS". > > > Selection: > > While option 3 is the most work it does kind of future proof the > registries and would make the columns the same in the parameter and > extensions registry groupings. > > > spt > > [0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > [1] > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > [2] Most of the DTLS-OK=N are deprecated cipher suites, but a couple of > Exporter Labels are also marked as DTLS-OK=N. > > > On Jun 20, 2019, at 21:46, Sean Turner <s...@sn3rd.com> wrote: > > > > All, > > > > During the DE’s review of the assignments for > draft-ietf-tls-dtls-connection-id, they requested a new “DTLS Only” column > be added to the TLS ExtensionType Values registry. This connection_id would > be the only “Y” and all others there now would be “N”. > > > > The chairs also noted that the IANA considerations in > draft-ietf-tls-dtls-connection-id needs to specify values for all the > columns for connection_id in the TLS ExtensionType Values registry and > tls12_cid in the TLS ContentType registry. Here are the proposed values: > > > > connection_id > > TLS 1.3 column: “-“ it is not applicable to TLS 1..3 > > Recommended: “Y" > > > > tls12_cid > > DTLS-OK: “Y” > > > > This has been captured in the following PR: > > https://github.com/tlswg/dtls-conn-id/pull/67 > > > > Obviously, please comment. > > > > spt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
