RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Verified (1)

RFC 2673, "Binary Labels in the Domain Name System", August 1999

Note: This RFC has been obsoleted by RFC 6891

Note: This RFC has been updated by RFC 3363, RFC 3364

Source of RFC: dnsind (int)

Errata ID: 1679
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2009-02-09
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section headers says:

(none)

It should say:

Updates: 1035

Notes:

This document introduces a type of label not explicitly anticipated in the core DNS documents. Not having an "updating" entry that threads it back to 1035 (or 1034) makes this specification hard to find and likely to be omitted from any compendium or overview of DNS specifications.

The situation is obviously a little complicated by our usual difficulties in updating full standards from documents that are earlier on the standards track or not on the standards track at all. 2673 was published (in 1999) as a Proposed Standard, making an intention to update 1035 well within the rules. A suggestion then appears to in 3363 (published in 2002) to change it to Experimental, but, since 3363 is itself Informational, it clearly did make that change. I can find no record of an explicit IESG action making it, but such records are hard to find. For completeness (of the confusion), RFC 3364 is also listed as updating 2673, but not only is it also Informational, it doesn't even reference 2673 -- one has to deduce the relationship to 2673 by making an inference from the discussion of 2874.

Obviously, while the erratum, and probably one for 1034 with a forward pointer to 2673, should be recorded, the key problem can be fixed by updating the rfc-index and its various clones.

An alternative, which clearly requires IESG and DNSEXT involvement (the above suggestion may or may not do so) is to decide that, after nearly a decade of presumed experience with 2673, either it is useful for something (even if not IPv6 reverse mapping) or that ten years is enough and it isn't worth the trouble. If it is useful, it should be put it back on the standards track, presumably with an applicability statement about what it is useful for. If it is not, it is time to make it Historic. Either decision would clear up the questions of its status vis-a-vis introduction of new label types and updating 1035.

Report New Errata



Advanced Search