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

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Dec 2008 13:52:01 -0600

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?

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: [email-masked]
Date: Thu, 4 Dec 2008 13:19:47 -0800 (PST)

Robert,

Thanks for your comments.

> typod your email address - sory.

My Mother-In-Law does it all the time (mark vs mike)

in line ...

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

The XDR encoding for netids allows them to be 2^32-1 bytes long.

That's obviously not feasible for an IANA registry, which is where the
restriction comes in.

>From the I-D:

   Netids can be up to 2^32 - 1 octets in length.  However, to ensure
   that practical values for Standards Track protocols are not
   exhausted, the values of netids one to eight octets long should be
   used for netids assigned on the Standards Action basis.

   [...]

   Assignments
   made on a First Come First Served basis should be assigned netids of
   length 9 to 128 octets long.  All netids, regardless of length, that
   start with the prefixes "STDS" 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 "EXPE" are Reserved.  The zero
   length netid is Reserved.  Some exceptions are listed in Table 2.  A
   recommended convention for netids corresponding to transports that
   work over the IPv6 protocol is to have "6" as the last character in
   the netid's name.

   [...]

   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 1 to
       128 octets long.

Tell me how I can make it clearer?

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

Good point. I will add text that says IANA can allow any case for
the netid, but two netids, if mapped to a common case cannot
both be in the registry.

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

Will do.

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

OK, will remove Expert Review for FCFS.

>> contact)? Where did the limit values you selected come from?

Regarding the latter question I looked at some registries, and these
seemed to be acceptable limits. Regarding the former question, one
has to have limits. What happens if someone submits a 1MB, 1GB, 1TB, etc.
entry?

>> 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?

OK, will mark them as reserved instead.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Dec 2008 17:12:56 -0600

inline:

On Dec 4, 2008, at 3:19 PM, [email-masked] wrote:
<trim>
> That's obviously not feasible for an IANA registry, which is where the
<trim>
> Tell me how I can make it clearer?

Perhaps in the sentence that says "2^32-1" you can explicitly say the  
XDR encoding allows
this long length, but this registry will only allow a much shorter  
length.

<trim>

> has to have limits. What happens if someone submits a 1MB, 1GB, 1TB,  

IANA says "You've got to be kidding".

This hasn't been a problem, and IANA's not going to need this document  
as a shield
to protect against someone trying to do something like that in the  
future.

I think what you're really after here is guidance to the person making  
a registration request rather
than setting rules IANA has to enforce.

Thanks for your fast response!

RjS

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Dec 2008 08:54:23 +0200

> to protect against someone trying to do something like that in the

Is there any other registry that potentially names that are this long?  
And with the first-com-first-served section of the registry, IANA  
isn't supposed to do any reviewing.

I think the limitation is reasonable and practical.

Lars

---

From: Robert Sparks <[email-masked]>
Date: Fri, 5 Dec 2008 12:45:13 -0600

To be clear, I'm asking about the limits on the description and  
contact fields (text for people and email addresses) in this message,  
not the restriction on the netid length.

Do we have, in the creation of other registries, explicit restrictions  
on how long the "who do you contact about this" field can be?

I'm not objecting strongly to the limits on these fields, but I do  
find them odd, and they add work for IANA (who will have to check  
things against those limits), which seems in conflict with your  
comment about not doing any reviewing below?

RjS

On Dec 5, 2008, at 12:54 AM, Lars Eggert wrote:

> Is there any other registry that potentially names that are this  
> long? And with the first-com-first-served section of the registry,  
> IANA isn't supposed to do any reviewing.
>

---

From: [email-masked]
Date: Wed, 10 Dec 2008 00:15:50 -0800 (PST)

Robert,

Thanks for your comments. -05 of this I-D has been posted.

Lars,

I fixed the references to obsolete standards. As an FYI, I have been relying
on rfc-editor.org check if RFC numbers were obsolete or not. It did not
classify  several  RFCs as obsolete.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Dec 2008 14:12:15 +0200

Hi,

> on how long the "who do you contact about this" field can be?

I don't know. I'd be OK with removing the limits on the "non- 
technical" fields, such as contact information, because IANA can use  
common sense to check those.

I would like to keep it for the netid itself, because IANA can't know  
whether a 1MB netid is appropriate or not (they don't understand the  
technology, but they do understand that postal addresses have a  
natural length limit.)

> comment about not doing any reviewing below?

IANA evaluated the document and is OK with it.

Lars

>>>> has to have limits. What happens if someone submits a 1MB, 1GB,  
>>>> 1TB,
>>>> etc.
>>>> entry?
>>>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Dec 2008 14:21:22 +0200

On 2008-12-10, at 10:15, [email-masked] wrote:
> I fixed the references to obsolete standards.

You fixed some, but not all. I'll leave the following (edited) RFC  
Editor Note in place: "Please make the following replacements to the  
document references: RFC2960 -> RFC4960, RFC1831 -> draft-ietf-nfsv4- 
rfc1831bis"

> As an FYI, I have been relying

The missing case was RFC793 obsoleting RFC675; the other ones were  
there. I asked the RFC Editor to add that.

Lars

PS: Robert, we can continue the discussion of your gen-art review  
while this document enters IESG Evaluation.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Dec 2008 09:26:32 -0600

> common sense to check those.
That's my recommendation, but its really a minor point.
>
>
> I would like to keep it for the netid itself, because IANA can't  
> know whether a 1MB netid is appropriate or not (they don't  
> understand the technology, but they do understand that postal  
> addresses have a natural length limit.)

I agree.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Dec 2008 09:29:35 -0600

-05 (and whatever gets decided on the registry non-technical field  
length limits) addresses all my comments.

RjS

On Dec 10, 2008, at 6:21 AM, Lars Eggert wrote:

> while this document enters IESG  
> Evaluation._______________________________________________
> Gen-art mailing list
> [email-masked]