RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2245
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Glen Zorn
Date Reported: 2010-05-06
Verifier Name: Russ Housley
Date Verified: 2011-12-06

Section 4.1 says:

The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path.


It should say:

The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason not to use that path.

Status: Held for Document Update (1)

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2701
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-01
Held for Document Update by: RFC Editor
Date Held: 2011-12-08

Section 12.2 says:

 [RFC4395]             Hansen, T., Hardie, T., and L. Masinter,
                       "Guidelines and Registration Procedures for New
                       URI Schemes", BCP 115, RFC 4395, February 2006.

It should say:

 [RFC4395]             Hansen, T., Hardie, T., and L. Masinter,
                       "Guidelines and Registration Procedures for New
                       URI Schemes", BCP 35, RFC 4395, February 2006.

Notes:

RFC 4395 is not BCP 115. It is BCP 35.

--VERIFIER NOTES--
Correct - RFC 4395 is BCP 35, not BCP 115. However, at the time RFC 5226 was published (May 2008), this error had not yet been reported (it was reported in Jan. 2009, and the relevant data was updated accordingly at that time).

Status: Rejected (2)

RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008

Note: This RFC has been obsoleted by RFC 8126

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2684
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2011-01-13
Rejected by: Russ Housley
Date Rejected: 2011-12-08

Section 4.2 says:

      5) Initial assignments and reservations.  Clear instructions
         should be provided to identify any initial assignments or
         registrations.  In addition, any ranges that are to be reserved
         for "Private Use", "Reserved", "Unassigned", etc. should be
         clearly indicated.

It should say:

      5) Initial assignments and reservations.  Clear instructions
         should be provided to identify any initial assignments or
         registrations.  In addition, any ranges that are to be reserved
         for "Private Use", "Reserved", etc. should be
         clearly indicated.

Notes:

Unassigned values are not "reserved". For bounded registries, they can be computed from the assigned/reserved values. For unbounded registries (think media types), mentioning them doesn't make any sense at all.
--VERIFIER NOTES--
No change is needed. The use of "should" provides any necessary flexibility. In the IANA Considerations section of a document that sets up a registry, authors tend to indicate which values are initially "Unassigned".

Errata ID: 2715
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-02-12
Rejected by: Russ Housley
Date Rejected: 2011-12-08

Section 4.2 says:

     5) Initial assignments and reservations.  Clear instructions
        should be provided to identify any initial assignments or
        registrations.  In addition, any ranges that are to be reserved
        for "Private Use", "Reserved", "Unassigned", etc. should be
        clearly indicated.


It should say:

     5) Initial assignments and reservations.  Clear instructions
        SHALL be provided to identify any initial assignments or
        registrations.  In addition, any ranges that are "Unassigned" 
        (only for those registries that have a bounded size), to be  
        "Reserved", used for "Private Use", "Experimentation", etc. 
        SHALL be clearly indicated.


Notes:

Julian Reschke included the following notes to his errata report #2684:

--Citation starts--
Unassigned values are not "reserved". For bounded registries, they can be computed from the assigned/reserved values. For unbounded registries (think media types), mentioning them doesn't make any sense at all.
--Citation ends--

Anyway, I propose to consider mentioning the norm about mandatory mentioning the Unassigned values in the registry description appropriate and useful. This would improve the work of IANA staff that will create the registries.
--VERIFIER NOTES--
Changing a "should" to a "SHALL" in a BCP cannot happen through the errata. IETF consensus is needed for such a change.

Report New Errata



Advanced Search