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. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
