IANA Registry Updates for TLS and DTLS
draft-ietf-tls-iana-registry-updates-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-08-10
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-08-01
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-08-01
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-07-03
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-07-02
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-07-02
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-06-29
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-29
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-06-29
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-29
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-06-11
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-11
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-06-07
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-06-06
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-05-30
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-05-25
|
05 | (System) | RFC Editor state changed to EDIT |
2018-05-25
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-05-25
|
05 | (System) | Announcement was received by RFC Editor |
2018-05-25
|
05 | (System) | IANA Action state changed to In Progress |
2018-05-25
|
05 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-05-25
|
05 | Cindy Morgan | IESG has approved the document |
2018-05-25
|
05 | Cindy Morgan | Closed "Approve" ballot |
2018-05-25
|
05 | Cindy Morgan | Ballot approval text was generated |
2018-05-25
|
05 | Benjamin Kaduk | Revised I-D present, and RFC Editor Note in place. |
2018-05-25
|
05 | Benjamin Kaduk | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-05-25
|
05 | Benjamin Kaduk | RFC Editor Note was changed |
2018-05-25
|
05 | Benjamin Kaduk | RFC Editor Note for ballot was generated |
2018-05-25
|
05 | Benjamin Kaduk | RFC Editor Note for ballot was generated |
2018-05-24
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-24
|
05 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-05.txt |
2018-05-24
|
05 | (System) | New version approved |
2018-05-24
|
05 | (System) | Request for posting confirmation emailed to previous authors: Sean Turner , Joseph Salowey |
2018-05-24
|
05 | Sean Turner | Uploaded new revision |
2018-04-05
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-04-05
|
04 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-04
|
04 | Benjamin Kaduk | Ballot approval text was generated |
2018-04-04
|
04 | Ignas Bagdonas | [Ballot comment] s/aligment/alignment s/prviate/private |
2018-04-04
|
04 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-04-04
|
04 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-04-03
|
04 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-04-03
|
04 | Adam Roach | [Ballot comment] Thanks for the work everyone put in on this document. I have a handful of comments, ranging from nits to minor issues. They … [Ballot 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. --------------------------------------------------------------------------- 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. --------------------------------------------------------------------------- §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). --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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'" --------------------------------------------------------------------------- §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] --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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" |
2018-04-03
|
04 | Adam Roach | Ballot comment text updated for Adam Roach |
2018-04-03
|
04 | Adam Roach | [Ballot comment] Thanks for the work everyone put in on this document. I have a handful of comments, ranging from nits to minor issues. They … [Ballot 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. --------------------------------------------------------------------------- Abstract: Please include the list of updated RFCs in the abstract. See §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. --------------------------------------------------------------------------- §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). --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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'" --------------------------------------------------------------------------- §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] --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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" |
2018-04-03
|
04 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-04-03
|
04 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-04-03
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-03
|
04 | Alexey Melnikov | [Ballot comment] I support the idea behind this document. I have a few minor issues which I would like to discuss before recommending its approval: … [Ballot comment] I support the idea behind this document. I have a few minor issues which I would like to discuss before recommending its approval: 1) In several places: "IESG action is REQUIRED for a Yes->No transition." Firstly, this should be "IESG Approval", not "IESG action" (according to RFC 8126). Secondly, are you saying that this is the ONLY way to transition from Yes to No? Surely, Standards Action should also be allowed in case there is no rush? Besides IESG is likely to prefer a document explaining the transition anyway. 2) In Section 15: 15. TLS Certificate Types Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict. Based on WG consensus, the decision was taken to change registration policy to Specification Required [RFC8126] while reserving a small part of the code space for experimental and private use. Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry. X.509 and Raw Public Key are "Yes". All others are "No". In order to register an extension with the value "Yes", a Standards Track document [RFC8126] is REQUIRED. The above sentence. Future Certificate Types MUST define the value of this column. A Standards Track document [RFC8126] is REQUIRED to register an entry with the value "Yes". And this is just repeating the above sentence in a different way. IESG action is REQUIRED for a Yes->No transition. 3) In Section 17: Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still import to warn implementers of import --> important pre-TLS1.3 implementations about the dangers of blinding implementing blinding --> blindly cryptographic algorithms. And later in the same section: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed cipher suites --> hash functions/signatures? here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. |
2018-04-03
|
04 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-04-03
|
04 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-04-03
|
04 | Benjamin Kaduk | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-04-02
|
04 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-04-02
|
04 | Warren Kumari | [Ballot comment] I'd suggest that the authors review the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-tls-iana-registry-updates-04-opsdir-lc-romascanu-2018-02-20/ I especially agree with #1 ("It would be useful from an operator perspective … [Ballot comment] I'd suggest that the authors review the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-tls-iana-registry-updates-04-opsdir-lc-romascanu-2018-02-20/ I especially agree with #1 ("It would be useful from an operator perspective to add to the registries where the Recommended column is added a text similar to the one in Section 6,...") I'm guessing it is not needed, but should there be a note to the RFC editor to fix the "IANA [SHALL prepend/has prepended]..." bit to "IANA has prepended..." throughout? 'tis probably obvious enough, but I figured worth asking. The Nits Checker grumps about missing Updates in the Abstract -- I was getting ready to fuss about this, and then found "This document updates many (D)TLS RFCs (see updates header)." - this seems like a fine hack to me. |
2018-04-02
|
04 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-03-31
|
04 | Eric Rescorla | [Ballot comment] requires standards action. Not all parameters defined in standards track documents need to be marked as recommended. It might be useful to … [Ballot comment] requires standards action. Not all parameters defined in standards track documents need to be marked as recommended. It might be useful to capitalize Recommended here. been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. I think technically it has "Recommended = No" Note: Supported Groups marked as "Yes" are those allocated via Standards Track RFCs. Supported Groups marked as "No" are not; supported groups marked "No" range from "good" to "bad" from a This may need a revision because some have not been allocated that way. thus requiring a new construction. The exporter interface remains the same, however the value is computed different. differently. |
2018-03-31
|
04 | Eric Rescorla | [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla |
2018-03-29
|
04 | Mirja Kühlewind | [Ballot comment] 1) Section 18: "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they … [Ballot comment] 1) Section 18: "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published." This sounds like it's simply the early allocation process (rfc7120). Maybe it's useful to name it like this to avoid confusion. 2) Also section 18: "IANA [...] SHOULD direct all requests for registration to the review mailing list." Why is this not a MUST? |
2018-03-29
|
04 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-03-29
|
04 | Mirja Kühlewind | [Ballot comment] Section 18: "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are … [Ballot comment] Section 18: "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published." This sounds like it's simply the early allocation process (rfc7120). Maybe it's useful to name it like this to avoid confusion. |
2018-03-29
|
04 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-28
|
04 | Benjamin Kaduk | [Ballot comment] Section 15, TLS Certificate Types, needs to list the values that are now spec required (3-223) and those that remain for private use … [Ballot comment] Section 15, TLS Certificate Types, needs to list the values that are now spec required (3-223) and those that remain for private use (224-255), I think. The Orphaned Registries section has a note added to the HashAlgorithm and SignatureAlgorithm registries about crypto potentially being bad, that mentions cipher suites instead of hash and signature algorithms. |
2018-03-28
|
04 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-03-28
|
04 | Benjamin Kaduk | Ballot has been issued |
2018-03-28
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-03-28
|
04 | Benjamin Kaduk | Created "Approve" ballot |
2018-03-28
|
04 | Benjamin Kaduk | Ballot writeup was changed |
2018-03-21
|
04 | Cindy Morgan | Shepherding AD changed to Benjamin Kaduk |
2018-03-16
|
04 | Stefan Santesson | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Stefan Santesson. Sent review to list. |
2018-03-01
|
04 | Kathleen Moriarty | Ballot writeup was changed |
2018-03-01
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-27
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-02-27
|
04 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tls-iana-registry-updates-04. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tls-iana-registry-updates-04. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are several actions which we must complete. We have examined the IANA Actions contained in this document and, on approval of the document, will work with the authors to ensure that the IANA Actions throughout the document are completed. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-02-21
|
04 | Kathleen Moriarty | Telechat date has been changed to 2018-04-05 from 2018-03-08 |
2018-02-20
|
04 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list. |
2018-02-20
|
04 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. Sent review to list. |
2018-02-19
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2018-02-19
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2018-02-16
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-02-16
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-02-16
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-02-16
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-02-15
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-15
|
04 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-03-01): From: The IESG To: IETF-Announce CC: tls@ietf.org, Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, draft-ietf-tls-iana-registry-updates@ietf.org, Stephen … The following Last Call announcement was sent out (ends 2018-03-01): From: The IESG To: IETF-Announce CC: tls@ietf.org, Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , stephen.farrell@cs.tcd.ie Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'IANA Registry Updates for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5878: Transport Layer Security (TLS) Authorization Extensions (Experimental - IETF stream) |
2018-02-15
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-15
|
04 | Kathleen Moriarty | Last call was requested |
2018-02-15
|
04 | Kathleen Moriarty | Ballot approval text was generated |
2018-02-15
|
04 | Kathleen Moriarty | Ballot writeup was generated |
2018-02-15
|
04 | Kathleen Moriarty | IESG state changed to Last Call Requested from Publication Requested |
2018-02-15
|
04 | Kathleen Moriarty | Last call announcement was generated |
2018-02-15
|
04 | Kathleen Moriarty | Placed on agenda for telechat - 2018-03-08 |
2018-02-15
|
04 | Sean Turner | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. This version is dated 20180103 (1) What type of … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. This version is dated 20180103 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? PS is being requested. This draft amends many TLS registries so that is the appropriate type. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document is not very technical, it's about IANA registries: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Working Group Summary This draft has been discussed at multiple IETFs most recently at IETF100: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-iana-registry-updates/ There's not been a lot of review because most people consider this administrivia that others should do; most just want the rules relaxed. A couple of notable reviews have been provided as noted below. The most important change - to loosen registrations while at the same time adding a "recommended" column to key registries requiring standards action for a "yes" value, had clear WG consensus. Various other WG documents depend on these changes being made and more will in the near future. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Responsible AD: Kathleen Moriarty Shepherd Extraordinaire: Stephen Farrell Martin Thomson, Eric Rescorla, and Benjamin Kaduk have at one time or anther reviewed this draft. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd re-read the document and raised some nits that got fixed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This document is ripe. GENART might be interested, maybe. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes - all relevant provisions of BCP 78 and BCP 79 have been filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. No IPR has been disclosed. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? The WG definitely wants the registration rules relaxed in conjunction with the use of the "recommended" column. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There has been no threat of appeal. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits check was on -03, the authors might fix some of these before this write-up is updated: - I think other nits described by the tool are erroneous. Cluttering the abstract with all those RFC numbers wouldn't help any real reader of this document, nor user of the IANA registries. (But if we insist on such clutter it'll cease being harmful once done;-) - There's a downref to RFC 5878. I'd say best would be to move that to an informative reference as nobody cares about that encumbered and pretty useless RFC (no offence to the authors, it was well intended but a fail, as some are). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes the references are identified as either normative or informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary. No other RFCs' status will change. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The entire draft is about IANA registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The entire draft is about IANA registries. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2018-02-15
|
04 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-02-15
|
04 | Sean Turner | IESG state changed to Publication Requested |
2018-02-15
|
04 | Sean Turner | IESG process started in state Publication Requested |
2018-02-15
|
04 | Sean Turner | Intended Status changed to Proposed Standard from None |
2018-02-15
|
04 | Sean Turner | Based on Stephen's email: https://mailarchive.ietf.org/arch/msg/tls/zOAmGQP7-fceZciF5D-mIfzRHQw |
2018-02-15
|
04 | Sean Turner | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-02-15
|
04 | Sean Turner | Changed consensus to Yes from Unknown |
2018-02-15
|
04 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-04.txt |
2018-02-15
|
04 | (System) | New version approved |
2018-02-15
|
04 | (System) | Request for posting confirmation emailed to previous authors: Sean Turner , Joseph Salowey |
2018-02-15
|
04 | Sean Turner | Uploaded new revision |
2018-01-30
|
03 | Kathleen Moriarty | Shepherding AD changed to Kathleen Moriarty |
2018-01-15
|
03 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
2018-01-03
|
03 | Stephen Farrell | Changed document writeup |
2018-01-03
|
03 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-03.txt |
2018-01-03
|
03 | (System) | New version approved |
2018-01-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Sean Turner , Joseph Salowey |
2018-01-03
|
03 | Sean Turner | Uploaded new revision |
2017-11-21
|
02 | Stephen Farrell | Changed document writeup |
2017-11-21
|
02 | Sean Turner | Notification list changed to Stephen Farrell <stephen.farrell@cs.tcd.ie> |
2017-11-21
|
02 | Sean Turner | Document shepherd changed to Stephen Farrell |
2017-11-07
|
02 | Sean Turner | Added to session: IETF-100: tls Thu-0930 |
2017-10-30
|
02 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-02.txt |
2017-10-30
|
02 | (System) | New version approved |
2017-10-30
|
02 | (System) | Request for posting confirmation emailed to previous authors: Sean Turner , Joseph Salowey |
2017-10-30
|
02 | Sean Turner | Uploaded new revision |
2017-10-30
|
01 | (System) | Document has expired |
2017-04-28
|
01 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-01.txt |
2017-04-28
|
01 | (System) | New version approved |
2017-04-28
|
01 | (System) | Request for posting confirmation emailed to previous authors: Sean Turner , Joseph Salowey , tls-chairs@ietf.org |
2017-04-28
|
01 | Sean Turner | Uploaded new revision |
2017-04-12
|
00 | Sean Turner | Stephen Farrell ran the WG call for adoption because the two authors are the WG's chairs. |
2017-04-12
|
00 | Sean Turner | This document now replaces draft-sandj-tls-iana-registry-updates instead of None |
2017-01-02
|
00 | Sean Turner | As Joe and I are the chairs, Stephen (our AD) judged whether there was WG consensus to adopt the draft (see https://mailarchive.ietf.org/arch/msg/tls/v2dlB-CWZUl8OSmqSWpwGSl3SOs). Prior to … As Joe and I are the chairs, Stephen (our AD) judged whether there was WG consensus to adopt the draft (see https://mailarchive.ietf.org/arch/msg/tls/v2dlB-CWZUl8OSmqSWpwGSl3SOs). Prior to adopting/accepting this draft with the datatracker, I got approval from Stephen on 20170102. |
2017-01-02
|
00 | Sean Turner | New version available: draft-ietf-tls-iana-registry-updates-00.txt |
2017-01-02
|
00 | (System) | WG -00 approved |
2017-01-02
|
00 | Sean Turner | Set submitter to "Sean Turner ", replaces to (none) and sent approval email to group chairs: tls-chairs@ietf.org |
2017-01-02
|
00 | Sean Turner | Uploaded new revision |