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?