RFC Errata
Found 2 records.
Status: Held for Document Update (1)
RFC 8126, "Guidelines for Writing an IANA Considerations Section in RFCs", June 2017
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 5772
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-07-03
Held for Document Update by: Barry Leiba
Date Held: 2019-07-03
Throughout the document, when it says:
Jon Postel and Joyce Reynolds provided a detailed explanation on what IANA needs in order to manage assignments efficiently, and patiently provided comments on multiple versions of this document. Brian Carpenter provided helpful comments on earlier versions of the document. One paragraph in the Security Considerations section was borrowed from RFC 4288.
It should say:
Jon Postel and Joyce Reynolds provided a detailed explanation on what IANA needs in order to manage assignments efficiently, and patiently provided comments on multiple versions of this document. Brian Carpenter provided helpful comments on earlier versions of the document. One paragraph in the Security Considerations section was borrowed from RFC 2048.
Notes:
Incorrect reference in ¨Acknowledgments from the First Edition (1998)¨, p. 46
Status: Rejected (1)
RFC 8126, "Guidelines for Writing an IANA Considerations Section in RFCs", June 2017
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 6522
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2021-04-08
Rejected by: Alvaro Retana
Date Rejected: 2021-04-08
Section 4.6 says:
The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation.
It should say:
The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation. Specific versions of Internet-Drafts, specifically IETF Working Group documents, that serve as "work in progress" reference for RFC path documents also achieve this requirement subject to Designated Expert review. Upon publication as RFC the reference may be updated upon request by Designated Expert.
Notes:
As part of the IESG review of draft-ietf-idr-bgp-ls-registry, the was a debate about whether an Internet-Draft serves the requirement of "permanent and readily available" for allocation under Specification Required policy. While IDs are indeed permanent and readily available these days and referencing a specific version does meet the requirements. However, the boiler plate text on IDs indicate that they many not be cited as reference other than work-in-progress.
For certain WGs (e.g. IDR) which await at least two implementations, the process of RFC publication takes time and it would have been good if the WG could have requested allocation based on a WG ID instead of following the tedious process of early allocation in RFC7120. The reference in IANA registry can then be update to the RFC upon publication and if not can remain with the reference to the ID.
--VERIFIER NOTES--
------
While the concerns are valid, this report doesn't target an error in the document but makes a proposal that will require community discussion and consensus.