[Gen-art] genart LC review of draft-ietf-nfsv4-rpc-netid-03.txt (and -04)

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-nfsv4-rpc-netid-03.txt (modified to take -04 into  
account)
Reviewer: Robert Sparks
Review Date: 4 Dec 2008
IETF LC End Date: 5 Dec 2008
IESG Telechat date: not known

Summary: This draft is basically ready for publication, but has nits  
that should be fixed before publication.

Comments:

I reviewed -03, but see -04 was submitted yesterday. I've modified my  
comments below based on -04, but any references to section numbers  
still point into the values the section had in -03.

1) There is an inconsistency between the text in 3.1 claiming "Netids  
can be up to 2^32 -1 octets in length" and the instructions in the  
rest of the document which restrict them to 128 octets.

2) The constraints placed on the "constant name" put a constraint  
around case-sensitivity on netid that you are probably assuming, but  
have not explicitly stated. Do you want to allow someone to register a  
netid of "foo" and someone else to register "Foo"? (btw - in the  
protocols that use these, is it clear whether they are case-sensitive?).

3) In a couple of places, the document says things like "For  
assignments made on a Standards Action basis, the point of contact is  
always the IESG". I suggest this should be something like "the point  
of contact is determined by the IESG" to make it easier to allow the  
IESG to delegate when appropriate.

4) Section 3.2 (IANA considerations for Uaddr Formats) is conflicted  
on what review is required for non-Standards Action registrations. It  
says First Come First Served at the top of the section, and Expert  
Review at the end. This same conflict appears in the first sentence of  
3.2.2.

5) Why are you putting length restrictions on what can go into the  
descriptive parts of the registry? (The description and point of  
contact)? Where did the limit values you selected come from?

6) If the explanation in 3.2.3.5 (Uaddr format for icmp) is complete  
the point is just to prevent someone else registering "icmp" or  
"icmp6". Why not just reserve those instead of registering them in  
this document? That would avoid leading someone into thinking  
something might send those values to them in a protocol message. Or is  
there more to why they're registered than what's explained in this  
section?