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

[Tero Kivinen <[e-mail]>]

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]