[nfsv4] [Technical Errata Reported] RFC5665 (2016)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 26 January 2010 13:08 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE3A3A63EC for <nfsv4@core3.amsl.com>; Tue, 26 Jan 2010 05:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nGEFeVixBHt for <nfsv4@core3.amsl.com>; Tue, 26 Jan 2010 05:08:27 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C35A53A67B6 for <nfsv4@ietf.org>; Tue, 26 Jan 2010 05:08:26 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 31434E06A4; Tue, 26 Jan 2010 05:08:37 -0800 (PST)
To: mike@eisler.com, magnus.westerlund@ericsson.com, lars.eggert@nokia.com, beepy@netapp.com, shepler@storspeed.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100126130837.31434E06A4@rfc-editor.org>
Date: Tue, 26 Jan 2010 05:08:37 -0800
Cc: ah@TR-Sys.de, nfsv4@ietf.org, rfc-editor@rfc-editor.org
Subject: [nfsv4] [Technical Errata Reported] RFC5665 (2016)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 13:08:28 -0000
The following errata report has been submitted for RFC5665, "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5665&eid=2016 -------------------------------------- Type: Technical Reported by: Alfred Hoenes <ah@TR-Sys.de> Section: 5.2.3.5 Original Text ------------- 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. Corrected Text -------------- 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. Instructions: ------------- This errata 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. -------------------------------------- RFC5665 (draft-ietf-nfsv4-rpc-netid-06) -------------------------------------- Title : IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats Publication Date : January 2010 Author(s) : M. Eisler Category : PROPOSED STANDARD Source : Network File System Version 4 Area : Transport Stream : IETF Verifying Party : IESG
- [nfsv4] [Technical Errata Reported] RFC5665 (2016) RFC Errata System