RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata