DNSSEC Cryptographic Algorithm Recommendation Update Process
draft-ietf-dnsop-rfc8624-bis-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-02-12
|
05 | Tim Wicinski | Tag Doc Shepherd Follow-up Underway cleared. |
2025-02-07
|
05 | Warren Kumari | New version available: draft-ietf-dnsop-rfc8624-bis-05.txt |
2025-02-07
|
05 | Warren Kumari | New version accepted (logged-in submitter: Warren Kumari) |
2025-02-07
|
05 | Warren Kumari | Uploaded new revision |
2025-01-29
|
04 | Tim Wicinski | Pulling this back from Eric for now. The issues are mostly minor. |
2025-01-29
|
04 | Tim Wicinski | Tag Doc Shepherd Follow-up Underway set. |
2025-01-29
|
04 | Tim Wicinski | IETF WG state changed to Waiting for WG Chair Go-Ahead from Submitted to IESG for Publication |
2025-01-25
|
04 | Wes Hardaker | New version available: draft-ietf-dnsop-rfc8624-bis-04.txt |
2025-01-25
|
04 | Wes Hardaker | New version accepted (logged-in submitter: Wes Hardaker) |
2025-01-25
|
04 | Wes Hardaker | Uploaded new revision |
2025-01-23
|
03 | Tim Wicinski | (1) RFC is Informational, and this is the correct RFC type. (2) Technical Summary: The DNSSEC protocol makes use of various cryptographic algorithms to provide … (1) RFC is Informational, and this is the correct RFC type. (2) Technical Summary: The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs. Working Group Summary: WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict. Document Quality: Document quality is very good. As this document is updating IANA tables, it is more about documenting existing usage and not about implemenetations. Document Shepherd: Tim Wicinski Responsible Area Director: Eric Vyncke (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) All nits found have been addressed by the authors. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This RFC will update RFC8624, and is listed in all correct places. (17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries. The details for updating the registries are clearly laid out. (18) No new IANA registries (19) No Automated checks needed (20) No Yang |
2025-01-23
|
03 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2025-01-23
|
03 | Tim Wicinski | IESG state changed to Publication Requested from I-D Exists |
2025-01-23
|
03 | (System) | Changed action holders to Éric Vyncke (IESG state changed) |
2025-01-23
|
03 | Tim Wicinski | Document is now in IESG state Publication Requested |
2025-01-23
|
03 | Tim Wicinski | (1) RFC is Informational, and this is the correct RFC type. (2) Technical Summary: The DNSSEC protocol makes use of various cryptographic algorithms to provide … (1) RFC is Informational, and this is the correct RFC type. (2) Technical Summary: The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs. Working Group Summary: WG consensus was solid. There was discussions around Section 2 "Adding usage and implementation recommendations to the IANA DNSSEC tables", but nothing in conflict. Document Quality: Document quality is very good. As this document is updating IANA tables, it is more about documenting existing usage and not about implemenetations. Document Shepherd: Tim Wicinski Responsible Area Director: Eric Vyncke (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) There are no concerns from the document shepherd. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is strong. (10) There has been no appeals. (11) All nits found have been addressed by the authors. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This RFC will update RFC8624, and is listed in all correct places. (17) The IANA considerations section and the changes are the basis for this document. The shepherd has done a through review of this section and the focus of the WGLC was around updating and expanding these IANA registries. The details for updating the registries are clearly laid out. (18) No new IANA registries (19) No Automated checks needed (20) No Yang |
2025-01-21
|
03 | Tim Wicinski | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2025-01-21
|
03 | Tim Wicinski | Notification list changed to tjw.ietf@gmail.com because the document shepherd was set |
2025-01-21
|
03 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2025-01-07
|
03 | Warren Kumari | Updated the Responsible AD to be Eric V, as I'm an author... |
2025-01-07
|
03 | Warren Kumari | Updated the Responsible AD to be Eric V, as I'm an author... |
2025-01-07
|
03 | Warren Kumari | Shepherding AD changed to Éric Vyncke |
2025-01-06
|
03 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2025-01-06
|
03 | Warren Kumari | New version available: draft-ietf-dnsop-rfc8624-bis-03.txt |
2025-01-06
|
03 | Warren Kumari | New version accepted (logged-in submitter: Warren Kumari) |
2025-01-06
|
03 | Warren Kumari | Uploaded new revision |
2024-11-20
|
02 | Tim Wicinski | Intended Status changed to Informational from None |
2024-10-23
|
02 | Tim Wicinski | Added to session: IETF-121: dnsop Mon-1730 |
2024-10-18
|
02 | Wes Hardaker | New version available: draft-ietf-dnsop-rfc8624-bis-02.txt |
2024-10-18
|
02 | Wes Hardaker | New version accepted (logged-in submitter: Wes Hardaker) |
2024-10-18
|
02 | Wes Hardaker | Uploaded new revision |
2024-10-09
|
01 | Wes Hardaker | New version available: draft-ietf-dnsop-rfc8624-bis-01.txt |
2024-10-09
|
01 | Wes Hardaker | New version accepted (logged-in submitter: Wes Hardaker) |
2024-10-09
|
01 | Wes Hardaker | Uploaded new revision |
2024-10-03
|
00 | Tim Wicinski | Changed document external resources from: None to: github_repo https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-algorithm-update |
2024-07-07
|
00 | Tim Wicinski | This document now replaces draft-hardaker-dnsop-rfc8624-bis instead of None |
2024-07-07
|
00 | Wes Hardaker | New version available: draft-ietf-dnsop-rfc8624-bis-00.txt |
2024-07-07
|
00 | Tim Wicinski | WG -00 approved |
2024-07-07
|
00 | Wes Hardaker | Set submitter to "Wes Hardaker ", replaces to draft-hardaker-dnsop-rfc8624-bis and sent approval email to group chairs: dnsop-chairs@ietf.org |
2024-07-07
|
00 | Wes Hardaker | Uploaded new revision |