RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5665, "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", January 2010

Source of RFC: nfsv4 (wit)

Errata ID: 2016
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2010-01-26

Section 5.2.3.5 says:

5.2.3.5.  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:

5.2.3.5.  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.

Notes:

Rationale:
The RFC text in Section 5.2.3.5. 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
[9], netids with the prefix "ICMP" are Reserved.

and

2. [...]
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
moot.

An alternative to the above Corrected Text would be to delete the
entire subsection 5.2.3.5. in the RFC.

_____
Closely related:

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)"
confusingly says:
Registration Procedures
Standards Action
as well.

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.

Report New Errata



Advanced Search