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

[[e-mail]]

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?

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

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.

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

Will do.

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

OK, will remove Expert Review for FCFS.

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

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?

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

OK, will mark them as reserved instead.
>>
>>
>>
>
>


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