RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

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

Note: This RFC has been updated by RFC 8375

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

Status: Held for Document Update (1)

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

Note: This RFC has been updated by RFC 8375

Source of RFC: homenet (int)

Errata ID: 4718
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Ralph Droms
Date Reported: 2016-06-23
Held for Document Update by: Terry Manderson
Date Held: 2017-01-31

Throughout the document, when it says:

7.4.  Multicast DNS Proxy

   The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link
   is elected based on the capabilities described in Section 4.

[...]

   The elected router MUST provide an mDNS proxy on the given link and
   announce it as described in Section 8.

[...]

8.  Naming and Service Discovery

   [...]

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
   proxy, or for which it provides forward or reverse DNS services on
   behalf of connected devices.

[...]

10.1.  HNCP-Version TLV

   [...]

   M-capability:  Priority value used for electing the on-link mDNS
      [RFC6762] proxy.  It MUST be set to 0 if the router is not capable
      of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set
      to any value from 1 to 7 to indicate a non-default priority



It should say:

7.4.  Multicast DNS Hybrid Proxy

   The designated Multicast DNS (mDNS) [RFC6762] Hybrid Proxy
   [draft-ietf-dnssd-hybrid-03] on a Common Link is elected based
   on the capabilities described in Section 4.

[...]

   The elected router MUST provide an mDNS Hybrid Proxy on the
   given link and announce it as described in Section 8.

[...]

8.  Naming and Service Discovery

   [...]

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
   Hybrid Proxy, or for which it provides forward or reverse DNS
   services on behalf of connected devices.

[...]

10.1.  HNCP-Version TLV

   [...]

   M-capability:  Priority value used for electing the on-link mDNS
      Hybrid Proxy.  It MUST be set to 0 if the router is not capable
      of providing an mDNS Hybrid Proxy service, otherwise it SHOULD
      be set to 4 but MAY be set to any value from 1 to 7 to indicate
      a non-default priority


Notes:

RFC 7788 refers to "Multicast DNS (mDNS) proxy" and gives a citation for RFC 6762.

RFC 6762, "Multicast DNS," defines multicast DNS and mentions (without an explicit definition) a "Multicast DNS Proxy" service. This proxy service is also known as "Bonjour Sleep Proxy" [https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy]

However, the intent of RFC 7788 is to specify the operation and advertisement of the multicast DNS Hybrid Proxy Service, as defined in draft-ietf-dnssd-hybrid-03, "Hybrid Unicast/Multicast DNS-Based Service Discovery." This errata corrects the mentions of "mDNS proxy" in RFC 7788 to "Hybrid Proxy."

draft-ietf-dnssd-hybrid-03 should also be added to the Normative References.

Report New Errata



Advanced Search