Dear all :




 




I am an assigned INT directorate reviewer for 


https://tools.ietf.org/html/draft-kivinen-802-15-ie-02

. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other
 IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see


http://www.ietf.org/iesg/directorate.html

.




 




Document: draft-kivinen-802-15-ie




IEEE 802.15.4 Information Element for IETF




Reviewer: Pascal Thubert




Review Date: October 13, 2016 




IETF Last Call Date: TBD




 




Summary:  




 




Tero’s draft was developed outside of the working group but is an enabler for solutions developed at 6lo and 6TiSCH. This review comes after the ones by Pat and then Charlie, who provided the adequate comments regarding IEEE802.15.4 and
 ANA. This review abstains to comment on that. Also, this review is made in the light of the Charlie’s proposed update.




 




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




“




 




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




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.




-

        


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




-

        


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.




 




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




 




 




Many thanks, Tero, for this much needed work!




 




Pascal