Re: [Int-dir] A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Tero:

CC ing Amanda for clarification on "RFC Required". 
For all I know,  with "RFC required", the IANA must also request that the IESG designate an expert to review the new registration.
The difference if I am correct is that "RFC required" adds limit the use of the IETF IE only to address requests from IETF specifications.
Amanda: is this correct?

Tero: Do you think you need assignments for use outside the IETF?  Or that a value could be assigned without an RFC?

Take care,

Pascal

-----Original Message-----
From: Tero Kivinen [mailto:[e-mail]] 
Sent: mardi 25 octobre 2016 14:43
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: A review of https://tools.ietf.org/html/draft-kivinen-802-15-ie-02 for INT-DIR

Pascal Thubert (pthubert) writes:
> Major issues:
> 
> I am not sure that “expert review” is the right policy for section 8 
> on IANA considerations. This registry is for IETF use only. Suggestion 
> is to use “RFC
> required”:
> 
> “
> 
>    Future assignments in this registry are to be coordinated via IANA 
> under the policy of "RFC Required" (see RFC 5226).
> 
> “

I disagree on that. RFC required has caused issues earlier, and I think expert review is better. We have used expert review in all IKEv2 related registries (and I am the expert there), and I think expert review is good option here too.

Why do you think that RFC required is better than expert review?

As this is cross wg registry RFC required might even be lower bar than expert review, as one WG might put forward and RFC taking for example
28 subtypes (draft-bormann-6lo-coap-802-15-ie-00.txt) and other users of this registry might not notice that... The expert can make sure that all relevant WGs are kept in loop for the allocations.

> Intended Status for this document: Seems to me that  informational 
> should be the right level; see for instance
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-01

Yes, that is correct. I fixed it to be informational. 

> Related: In the -04 that Charlie attached, I saw that uppercase 
> imperatives were added. I do not think that’s a good idea:
> 
> -         Imperative “MUST” in section 7 refers to the writing of other
> documents and is probably not appropriate.

We have had such texts earlier, and I agree that there is no real difference whether it is "MUST be described" or "needs to be described".

I am happy to go with either way.

> -         Imperative “SHOULD” in section 7 does not refer to the behavior of
> the implementation of this document and is probably not appropriate either.

Same here.

> -         If those go away, ref to RFC 2119 is not needed and the
> specification can take the informational path, much easier
> 
> Minor issues:
> 
>  The need for section 5 does not appear until the IANA section. The 
> way it is done works, but leaves the reader puzzled. Swapping 5 and 6 
> and then one last sentence saying that there is no need to block 
> subtype IDs in the IETF IE for Vendor Specific work would have made the reading a bit smoother.

I now moved the vendor specific IE in IEEE 820.15.4 to appendix, and added text to IANA considerations saying that we do not need vendor specific IEs:

7.  IANA Considerations
...
   Note, that there is Vendor specific IEs already defined in the IEEE
   802.15.4 (see Appendix A), and because of this, there is no need to
   reserve any subtype IDs for the vendor-specific uses.
...
Appendix A.  Vendor Specific IE in IEEE 802.15.4

   IEEE 802.15.4 has already several numbers for different Vendor
   Specific IE types.  There is one for the Vendor Specific Header IE
   for Header IEs.  There is one incorrectly named Vendor Specific
   Nested IE for Payload IEs, and there is another one with exactly the
   same name, but under the MLME Nested IE long format.  All of the
   Vendor Specific IEs start with a 3-octet vendor OUI to identify the
   organization.
...

> Do we need 20% of the subtypes for experimentations? 240 to 255 seems 
> enough to me…

Most likely not, but if we have bit larger space allocated for them, then people might not always take the first one...

On the other hand, we do have 200 numbers for allocations, I think that is also enough. If we ever get close to that number, I think we want to write the new RFC and specify the extension format of for the subtypes, and while doing that we can make the experimental use space smaller too.
--
[e-mail]