Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-rpc-netid-00.txt

From: [email-masked]
Date: Thu, 14 Aug 2008 22:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : IANA Considerations for RPC Net Identifiers
	Author(s)       : M. Eisler
	Filename        : draft-ietf-nfsv4-rpc-netid-00.txt
	Pages           : 9
	Date            : 2008-08-14

This Internet-Draft lists IANA Considerations for RPC Network
Identifiers (netids).  This Internet-Draft updates, but does not
replace, RFC1833.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpc-netid-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Aug 2008 14:31:39 -0700

>    Identifiers (netids).  This Internet-Draft updates, but does not

   The first-page boilerplate also needs a corresponding: "Updates: 1833
   (if approved)" line.

Section 3., paragraph 4:
 >    o  First Come First Served basis per section 4.1 of [6].

   Based on what you describe below (involvement of a Designated  
Expert),
   I think you want the "Expert Review" policy here. If you want a very
   light-weight expert review, you can give guidance as to what kind of
   review the expert should perform later in this document.

Section 3., paragraph 5:
 >    o  RFC Required basis per section 4.1 of [6].  This RFC MUST be a
 >       Standards Track RFC, and so it is more precisely called the
 >       Standards Track RFC Required basis.

   In that case, the policy is "Standards Action". ("Values are assigned
   only for Standards Track RFCs approved by the IESG.")

Section 3., paragraph 6:
 >    Netids can be up to 2^31 - 1 octets in length.

   Can netids really be up to 4GB long? That seems completely
   impractical, both for IANA to handle and in terms of actually being
   used for ONC RPC (netids > allowable packet size).

Section 3., paragraph 7:
 >    All netids,
 >    regardless of length, that start with the prefixes "IETF" or  
"FCFS"
 >    are Reserved, in order to extend the name space of either  
basis.  In
 >    addition, to give IESG the flexibility in the future to permit
 >    Private and Experimental Uses, all netids with the prefixes  
"PRIV" or
 >    "EXP" are Reserved.  Exceptions to this policy can be authorized  
by a
 >    Designated Expert.

   Remove the last sentence - a Designated Expert cannot make
   authorizations that conflict with the IESG.

Section 1., paragraph 0:
 >    1.  A US-ASCII string name that is the actual netid.  This name  
MUST
 >        NOT conflict with any other netid.  This string name can be  
zero
 >        to 128 octets long.

   Why allow a zero-length netid?

Section 3., paragraph 0:
 >    3.  For assignments made on a First Come First Served basis a
 >        description, which can be up to 1024 US-ASCII characters (or  
more
 >        if IANA permits) how the netid will be used.  The description
 >        field is not included in assignments made on a Standards Track
 >        RFC Required basis.

   I think this is information to be provided to the Designated Expert  
so
   he can perform his review, but it doesn't need to actually go into  
the
   IANA registry. 1024 bytes is very long for a registry field. (Same
   comment applies to 4. and 5. below.)

Section 6., paragraph 0:
 >        The point
 >        of contact field is not included in assignments made on a
 >        Standards Track RFC Required basis; however IESG, on the  
adviced
 >        of a Designated Expert, must approve all assignments made on a
 >        Standards Track RFC Required basis, and thus is the implied  
point
 >        of contact for all such assignments.

   For other registries, the explicit point of contact for
   standards-track registrations is the IETF (or the IESG), which
   implicitly has the right meaning (that the IESG can make changes).
   (Also, nit: s/adviced/advice/)

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 18 Aug 2008 16:27:12 -0700 (PDT)

>    review the expert should perform later in this document.

I'm not sure I follow. For FCFS, the Expert Reivew/Designated Export
is only used when there is no point of contact (given the age of RPC,
and how long it existed before ISOC assumed change control, this
allows the Designated  Expert to authorize netids that are in common
use but no one knows who the point of contact is.

>From RFC 1883:

struct rpcb {
 unsigned long r_prog;    /* program number */
 unsigned long r_vers;    /* version number */
 string r_netid<>;        /* network id */
 string r_addr<>;         /* universal address */
 string r_owner<>;        /* owner of this service */
};

r_netid<> does not have a limiter, e.g. it is not r_netid<MAX_NETID_LEN>.
So per RFC4506, it is 2^32-1 maximum octets.

And yes it is impractical, hence the text the follows:

   However, to ensure
   that practical values for Standards Track protocols are not
   exhausted, the values of netids zero to 8 octets long should be used
   for netids assigned on the Standards Track RFC Required basis.
   Assignments made on a First Come First Served basis should be
   assigned netids of length 9 to 128 octets more.

leaving aside the typos, the intent is to only allow practical values
to be registered.

(I don't mind doing an RFC1833bis,, later, but I'd prefer to not
do one and hold up RPC RDMA and nfsv4.1).

>    Why allow a zero-length netid?

RFC1833 doesn't disallow it. Since IESG ultimately decides whether to
allow it or not, I saw no harm. Since we can ban zero length, and IESG can
override it later, I'm perfectly happy to change it to 1 to 128.

>    he can perform his review, but it doesn't need to actually go into

Not sure if you mean FCFS or/and Standards Action registrations.

I would hope that FCFS registrations always have a description.

Not sure why Standards Action registrations need a description ... there
is an accompanying RFC that should suffice. But if there is a very long
RFC, perhaps what you mean is the the description allows the Expert to
get to the core of the netid issue. OK, I will make such a change.

>    comment applies to 4. and 5. below.)

Actually, I looked at some descriptions for existing registries, and 1024
didn't seem too long at all (I believe I found a description of about
600 characters). Regardless, what length do you suggest
instead of 1024?

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 18 Aug 2008 19:30:19 -0700 (PDT)

I pushed -01 just now.

Comments inline ...

> use but no one knows who the point of contact is.

I think I understand. In the updates section I specified the conditions
when the Expert might update an FCFS.

> override it later, I'm perfectly happy to change it to 1 to 128.

Zero length netids are now Reserved.

> 600 characters). Regardless, what length do you suggest

Left descriptions at 1024 bytes, and reduced references to 256.