RFC 5665, "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", January 2010Source of RFC: nfsv4 (tsv)
Errata ID: 2016
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-26
Section 220.127.116.11 says:
18.104.22.168. Uaddr Format for ICMP over IPv4 and IPv6 As ICMP is not a true transport, there is no uaddr format for ICMP. The netid assignments "icmp" and "icmp6" and their shared uaddr "format" are listed to prevent any registrant from allocating the netids "icmp" and "icmp6" for a purpose that would likely cause confusion.
It should say:
22.214.171.124. Uaddr Format for ICMP over IPv4 and IPv6 As ICMP is not a true transport, there are no netid assignments "icmp" and "icmp6" and there is no need for a dummy uaddr format for ICMP.
The RFC text in Section 126.96.36.199. is outdated and does not correspond
to the revised design decision documented in Section 5.1 to _not_
register "icmp" and "icmp6" netids.
Section 5.1 says:
o To prevent confusion with the control protocol by the same name
, netids with the prefix "ICMP" are Reserved.
Constant names with the prefix "NC_STDS",
"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved.
Since there are no such registry entries (see Table 2 in Section 5.1.1),
there also is no dummy shared Uaddr Format for ICMP in the Uaddr Format
registry (see Table 3 in Section 5.2.1), and hence the Original text is
An alternative to the above Corrected Text would be to delete the
entire subsection 188.8.131.52. in the RFC.
Notes regarding the current IANA registries originated in RFC 5665
[[ This part of the Errata Note should be deleted by the verifier
after verification and corrective action by IANA. ]]
a) IANA has misrepresented the registration policy in the netid registry.
Both namespaces are split into two parts, governed respectively
by "Standards Action" and "First Come First Served" policy.
IANA has split the 'netid' registry into two sub-registries
(BTW: not sure this makes sense, since the namespace is shared),
but the first registry, "ONC RPC Netids (First Come First Served)"
b) "RESERVED" values and patterns
IANA did not make note of the various "reserved" values specified
in the RFC. All these reservations should preferably be stated in
"Note"s attached to the registries to remind readers and prospective
registrant of the reservations.
Maybe, a short hint to the RFC suffices in both cases:
"Note: RFC 5665 specifies various reserved values and name prefixes
for this registry."
c) Columnar alignment
In the "ONC RPC Netids (First Come First Served)" registry,
apparently the content of the "Point of Contact" column is missing,
and the entries for the "cross reference" column are misaligned.
In the "ONC RPC Netids (Standards Action)" registry and the
"NC RPC Uaddr Format Registry", the left alignment of the
cross reference table cell entries below the (centered) column
heading (and thus visually almost under the "Point of Contact"
column heading) also is rather confusing.
In general, using the _same_ (often: left) horizontal alignment
of column headings and table cells would be preferable.