RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (3)

RFC 7788, "Home Networking Control Protocol", April 2016

Source of RFC: homenet (int)

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

Reported By: Tim Wicinski
Date Reported: 2016-04-26
Verifier Name: Terry Manderson
Date Verified: 2016-05-12

Section 8 says:

   A network-wide
   zone is appended to all single labels or unqualified zones in order
   to qualify them. ".home" is the default; however, an administrator
   MAY configure the announcement of a Domain-Name TLV (Section 10.6)
   for the network to use a different one.

It should say:

   A network-wide
   zone is appended to all single labels or unqualified zones in order 
   to qualify them.  A default value for this TLV MUST be set, although 
   the default value of the Domain-Name TLV (Section 10.6) is out of 
   scope of this document, and an administrator MAY configure the 
   announcement of a Domain-Name TLV for the network.

Notes:

It may appear that the use of the label ".home" is unofficially assigning this to be added to the Special Use Domain Registry. That registry can only be updated using the process outlined in RFC6761, therefore the text identifying ".home" as the default network-wide zone is in error.

It is unclear of the IESG and the IETF in publishing this proposed standard if the intent was to use ".home" as an example or placeholder until a name can be reserved.

AD Note: A default label is a requirement for HNCP and its interoperability. As such the Homenet chosen label, ".home", is a strong candidate for the RFC6761 process. The WG will be directed to follow this process and seek (again) the consensus on the ".home" label and work with other IETF WGs as appropriate.

Errata ID: 5021

Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Dirk Feytons
Date Reported: 2017-05-19
Verifier Name: Eric Vyncke
Date Verified: 2021-01-03
Report Text:

RFC 7787 (DNCP) in section 9 defines DNCP_NODE_IDENTIFIER_LENGTH as being bytes, not bits.

-- Verifier note --
Indeed, section 9 of RFC 7787 clearly specifies "DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier (in bytes)."

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

Reported By: Denis Ovsienko
Date Reported: 2017-09-13
Verifier Name: Eric Vyncke
Date Verified: 2021-01-03

Section 10 says:

10.2.2.  DHCPv6-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[...]

10.2.3.  DHCPv4-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

10.2.2.  DHCPv6-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (38)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[...]

10.2.3.  DHCPv4-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (37)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Section 13 (IANA Considerations) of the document says:

37: DHCPv4-Data

38: DHCPv6-Data

Those code points from Section 13 are in the "HNCP TLV Types" IANA registry as well as in the current source code of shncpd and tcpdump. The code points shown in Sections 10.2.2 and 10.2.3 were likely swapped by mistake.

-- Verifier note --
The IANA registry for HNCP TLV types (https://www.iana.org/assignments/dncp-registry/dncp-registry.xhtml#hncp-tlv-types) has indeed 37 for DHCPv4 and the open source SHNCPD has the same https://github.com/jech/shncpd/blob/master/receive.c

Report New Errata