[homenet] [Errata Verified] RFC9526 (7792)
The following errata report has been verified for RFC9526, "Simple Provisioning of Public Names for Residential Networks". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7792 -- Status: Verified Type: Editorial Reported by: Samuel K. Lam Date Reported: 2024-01-30 Verified by: RFC Editor The Abstract says: Original Text - Home Naming Authority (NHA) Corrected Text -- Homenet Naming Authority (HNA) Notes - In the second paragraph of this RFC's Abstract: "Home" should be corrected to "Homenet", and "(NHA)" should be corrected to "(HNA)". The rest of this RFC uses "Homenet Naming Authority (HNA)" as opposed to "Home Naming Authority (NHA)". -- RFC9526 (draft-ietf-homenet-front-end-naming-delegation-27) -- Title : Simple Provisioning of Public Names for Residential Networks Publication Date: January 2024 Author(s) : D. Migault, R. Weber, M. Richardson, R. Hunter Category: EXPERIMENTAL Source : Home Networking Area: Internet Stream : IETF ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Editorial Errata Reported] RFC9526 (7792)
The following errata report has been submitted for RFC9526, "Simple Provisioning of Public Names for Residential Networks". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7792 -- Type: Editorial Reported by: Samuel K. Lam Section: Abstract Original Text - Home Naming Authority (NHA) Corrected Text -- Homenet Naming Authority (HNA) Notes - In the second paragraph of this RFC's Abstract section: "Home" should be corrected to "Homenet", and "(NHA)" should be corrected to "(HNA)". The rest of this RFC uses "Homenet Naming Authority (HNA)" as oppose to "Home Naming Authority (NHA)". Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC9526 (draft-ietf-homenet-front-end-naming-delegation-27) -- Title : Simple Provisioning of Public Names for Residential Networks Publication Date: January 2024 Author(s) : D. Migault, R. Weber, M. Richardson, R. Hunter Category: EXPERIMENTAL Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Errata Verified] RFC7788 (5113)
The following errata report has been verified for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5113 -- Status: Verified Type: Technical Reported by: Denis Ovsienko Date Reported: 2017-09-13 Verified by: Eric Vyncke (IESG) Section: 10 Original Text - 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -- 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 -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Errata Verified] RFC7788 (5021)
The following errata report has been verified for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5021 -- Status: Verified Type: Technical Reported by: Dirk Feytons Date Reported: 2017-05-19 Verified by: Eric Vyncke (IESG) Original Text - HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32). Corrected Text -- HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 4). Notes - 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)." -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Errata Rejected] RFC8375 (6378)
The following errata report has been rejected for RFC8375, "Special-Use Domain 'home.arpa.'". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6378 -- Status: Rejected Type: Editorial Reported by: Kulvinder Matharu Date Reported: 2021-01-02 Rejected by: Eric Vyncke (IESG) Section: GLOBAL Original Text - "home.arpa." Corrected Text -- "home.arpa" Notes - The domain "home.arpa." is used throughout the document. The domain should, instead, be "home.arpa". --VERIFIER NOTES-- As discussed over email, RFC 1034 specifies that FQDN should terminate with a dot else it is not a FQDN. -- RFC8375 (draft-ietf-homenet-dot-14) -- Title : Special-Use Domain 'home.arpa.' Publication Date: May 2018 Author(s) : P. Pfister, T. Lemon Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Editorial Errata Reported] RFC8375 (6378)
The following errata report has been submitted for RFC8375, "Special-Use Domain 'home.arpa.'". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6378 -- Type: Editorial Reported by: Kulvinder Matharu Section: GLOBAL Original Text - "home.arpa." Corrected Text -- "home.arpa" Notes - The domain "home.arpa." is used throughout the document. The domain should, instead, be "home.arpa". Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8375 (draft-ietf-homenet-dot-14) -- Title : Special-Use Domain 'home.arpa.' Publication Date: May 2018 Author(s) : P. Pfister, T. Lemon Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Technical Errata Reported] RFC7788 (5494)
The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5494 -- Type: Technical Reported by: Uros Section: 1 Original Text - 1 Corrected Text -- 1 Notes - 1 Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Technical Errata Reported] RFC7788 (5113)
The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5113 -- Type: Technical Reported by: Denis Ovsienko Section: 10 Original Text - 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -- 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. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Technical Errata Reported] RFC7788 (5021)
The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5021 -- Type: Technical Reported by: Dirk Feytons Section: 3 Original Text - HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32). Corrected Text -- HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 4). Notes - RFC 7787 (DNCP) in section 9 defines DNCP_NODE_IDENTIFIER_LENGTH as being bytes, not bits. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Errata Held for Document Update] RFC7788 (4718)
The following errata report has been held for document update for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4718 -- Status: Held for Document Update Type: Technical Reported by: Ralph Droms Date Reported: 2016-06-23 Held by: Terry Manderson (IESG) Section: GLOBAL Original Text - 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 Corrected Text -- 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. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Technical Errata Reported] RFC7788 (4718)
The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4718 -- Type: Technical Reported by: Ralph Droms Section: GLOBAL Original Text - 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 Corrected Text -- 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. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Errata Verified] RFC7788 (4677)
The following errata report has been verified for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4677 -- Status: Verified Type: Technical Reported by: Tim Wicinski Date Reported: 2016-04-26 Verified by: Terry Manderson (IESG) Section: 8 Original Text - 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. Corrected Text -- 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. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] [Technical Errata Reported] RFC7788 (4677)
The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4677 -- Type: Technical Reported by: Tim Wicinski Section: 8 Original Text - 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. Corrected Text -- A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. Sn administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) 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. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
