Skip to main content

Early Review of draft-kivinen-802-15-ie-02

Request Review of draft-kivinen-802-15-ie
Requested revision No specific revision (document currently at 06)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-10-20
Requested 2016-10-11
Authors Tero Kivinen , Pat Kinney
I-D last updated 2016-10-24
Completed reviews Intdir Early review of -02 by Charles E. Perkins (diff)
Intdir Early review of -02 by Pascal Thubert (diff)
Opsdir Telechat review of -04 by Scott O. Bradner (diff)
Genart Telechat review of -04 by Francis Dupont (diff)
Secdir Telechat review of -04 by Magnus Nyström (diff)
Genart Last Call review of -04 by Francis Dupont (diff)
Genart Last Call review of -04 by Francis Dupont (diff)
Opsdir Early review of -06 by Scott O. Bradner
Assignment Reviewer Pascal Thubert
State Completed
Request Early review on draft-kivinen-802-15-ie by Internet Area Directorate Assigned
Reviewed revision 02 (document currently at 06)
Completed 2016-10-24

Dear all :

I am an assigned INT directorate reviewer for

. 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


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


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


   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

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

Many thanks, Tero, for this much needed work!