Early Review of draft-kivinen-802-15-ie-02
review-kivinen-802-15-ie-02-intdir-early-perkins-2016-10-24-00

Request Review of draft-kivinen-802-15-ie
Requested rev. no specific revision (document currently at 06)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-10-20
Requested 2016-10-08
Draft last updated 2016-10-24
Completed reviews Intdir Early review of -02 by Charles Perkins (diff)
Intdir Early review of -02 by Pascal Thubert (diff)
Opsdir Telechat review of -04 by Scott Bradner (diff)
Genart Telechat review of -04 by Francis Dupont (diff)
Secdir Telechat review of -04 by Magnus Nystrom (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 Bradner
Assignment Reviewer Charles Perkins
State Completed
Review review-kivinen-802-15-ie-02-intdir-early-perkins-2016-10-24
Reviewed rev. 02 (document currently at 06)
Review completed: 2016-10-24

Review
review-kivinen-802-15-ie-02-intdir-early-perkins-2016-10-24



Hello folks,







I am an assigned INT directorate reviewer for
      <draft-kivinen-802-15-ie-02.txt>.  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

.




I made a lot of minor editorial changes to the draft, because I
      think that the draft needs improvements for readability and
      clarity.  For this purpose, please see the attached files. 
      draft-kivinen-802-15-ie-02cep.txt contains all of my comments
      (marked with "CEP") and revisions.







A few more general comments:







I do not understand why Section 5 is included.  It doesn't
        seem to have any effect on the request for allocation.




Section 6 should be reworded so that the request is made to
        ANA, not 802.15.4




Since all uses of the newly allocated IE will share the same
        security model, perhaps it should be mentioned that if a
        different security model is needed, another IE might be
        requested




Although I have made a number of editorial suggestions, I
        think the document still will need a close proofreading.










For other comments, please refer to the attached rfcdiff file.







Regards,


      Charlie P.







<<< text/html; charset=UTF-8; name="Diff draft-kivinen-802-15-ie-02.txt - draft-kivinen-802-15-ie-02cep.txt.htm": Unrecognized >>>








Network Working Group                                         T. Kivinen
Internet-Draft                                             INSIDE Secure
Intended status: Standards Track                               P. Kinney
Expires: October 24, 2016                          Kinney Consulting LLC
                                                          April 22, 2016


               IEEE 802.15.4 Information Element for IETF
                     draft-kivinen-802-15-ie-02.txt

Abstract

   IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to
   extend 802.15.4 in an interoperable manner.  The IEEE 802.15 Assigned
   Numbers Authority (ANA) manages the registry of the Information
   Elements.  This document formulates a request for ANA to allocate a number
   from that registry for
   IETF, and describes how the IE is formatted to provide
   subtypes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at 

http://datatracker.ietf.org/drafts/current/

.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 24, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (

http://trustee.ietf.org/license-info

) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Kivinen & Kinney        Expires October 24, 2016                [Page 1]

Internet-Draft IEEE 802.15.4 Information Element for IETF     April 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Users of the IETF IE  . . . . . . . . . . . . . . . . . . . .   3
   4.  IETF IE Subtype Format  . . . . . . . . . . . . . . . . . . .   3
   5.  Vendor Specific IE  . . . . . . . . . . . . . . . . . . . . .   4
   6.  Request to allocate IETF IE . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The IEEE Std. 802.15.4 [IEEE-802-15-4] defines Information Elements (IE)
   that can be used to extended the 802.15.4 in an interoperable manner.
   There are two different IE types, Header IE and Payload IE.  A
   Header IEs is part of the Medium Access Control (MAC) header;
   it is never encrypted, but they may be authenticated.  Most of the
   Header IE processing is done by the MAC, and IETF protocols should not have
   any direct effect on that processing.  A Payload IE is part of the MAC
   payload, and may be encrypted and authenticated.

   IETF protocols will need to insert information in the 802.15.4
   frames, and 802.15.4 enables that by including payload
   IE in the frame that will contain the information.  For this purpose
   the IETF requests a dedicated Payload IE from IEEE 802.15
   Assigned Numbers Authority (ANA) [IEEE-802-15-ANA].  The current
   802.15 ANA database can be found in [IEEE-802-15-ANA-DB].

   The 802.15.4 operations manual [IEEE-802-15-OPS] describes
   how a standardization organization (SDO) may request an allocation of
   one IE.  To make this request the SDO
   has to provide (i) the reason for the request, (ii) a
   description of the protocol format that shows an appropriate
   subtype capability, and (iii) an agreement
   that only one IE number will be allocated for use by the SDO.

   This document provides the information needed for the request.






Kivinen & Kinney        Expires October 24, 2016                [Page 2]

Internet-Draft IEEE 802.15.4 Information Element for IETF     April 2016


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Working Groups Benefitting from the IETF 802.15.4 IE

   There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc,
   which could benefit from the IETF IE.  The 6TiSCH working group has
   already expressed the need for the IE, and this allocation is expected to
   satisfy that need.

4.  IETF IE Subtype Format

   The maximum length of the Payload IE content is 2047 octets, and
   802.15.4 frame contains a list of payload IEs.  A single frame
   can have multiple payload IEs, terminated with the payload IE
   terminator, which may then be followed by the payload.

   Because the frame contains a list of the payload IEs, there is no need
   for this document to specify the internal structure inside the IETF IE.  The Payload IE
   format of IEEE 802.15.4 contains the Length field.  The length of
   the subtype content can be calculated from the Length field of the
   IETF IE.

   The format of the IETF IE is as follows:
	/* CEP: The above paragraph states that the Length field is
                part of the IETF IE, but the Length field is not
                shown in Figure 1. */

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Subtype ID   |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                        subtype content                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: IETF IE Subtype Format

   o  Subtype ID is the IANA allocated number specifying the subtype
      of the IETF IE.  Value 0 is reserved for future extensibility,
      i.e., in case a longer SubType ID field is needed.

   o  Subtype content is the actual content of the information element,
      and its length can be calculated from the Length field of the IETF
      IE.





Kivinen & Kinney        Expires October 24, 2016                [Page 3]

Internet-Draft IEEE 802.15.4 Information Element for IETF     April 2016


   One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same or
   different subtypes.

5.  Vendor Specific IE

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

   Because of this there is no need to reserve any subtype IDs
   for the vendor specific uses, as the above-mentioned Vendor Specific IE
   types can be used for that.
   /* CEP: I am not clear why this section is needed. */

6.  Request to allocate IETF IE

   IETF requests the 802.15.4 Working Group to allocate an ID for a Payload
   IE for IETF use.  It is agreed that only one ID will
   be issued for use by IETF protocols.
	/* CEP: isn't this supposed to be a request to ANA? */

7.  Security Considerations

   This document creates an IANA registry for IETF IE subtype IDs (see section
8).
   The security of the protocols using the IEs MUST be described in
   the documents requesting allocations from this registry.

   The IEEE Std 802.15.4-2015 [IEEE-802-15-4] contains methods where
   security of the IE can be enforced when a frame is received, but this
   is only per IE type.  Therefore, all IETF IEs will have same security level
   requirements regardless of the subtype ID used.  This can cause
   issues if different security processing would be needed and any of
   those IEs would need to be processed in the MAC level.  Since all
   IETF protocols should operate at a higher level than the MAC level,
   the higher layer processing for these IEs SHOULD perform
   separate security policy checking based on the IETF IE subtype ID in
   addition to the checks done by the MAC.
   /* CEP: If a different security model is needed for a future IETF IE,
	   could a request be made for another IETF IE allocation? */

8.  IANA Considerations

   /* CEP: bad pagination */
   This document creates a new registry for IETF IE subtype IDs
   registry:







Kivinen & Kinney        Expires October 24, 2016                [Page 4]

Internet-Draft IEEE 802.15.4 Information Element for IETF     April 2016


   Value     Subtype ID
   0         Reserved
   1-200     Unassigned
   201-255   Experimental Use

   Any change or addition to this registry requires expert review.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <

http://www.rfc-editor.org/info/rfc2119

>.

9.2.  Informative References

   [IEEE-802-15-4]
              "IEEE Standard for Low-Rate Wireless Personal Area
              Networks (WPANs)", IEEE Standard 802.15.4, 2015.

   [IEEE-802-15-ANA]
              "IEEE 802.15 Assigned Numbers Authority",
              <

http://www.ieee802.org/15/ANA.html

>.

   [IEEE-802-15-ANA-DB]
              "IEEE 802.15 ANA database",
              <

https://mentor.ieee.org/802.15/


              documents?is_dcn=257&is_group=0000>.

   [IEEE-802-15-OPS]
              "IEEE 802.15 Operations Manual",
              <

https://mentor.ieee.org/802.15/


              documents?is_dcn=235&is_group=0000>.

Authors' Addresses

   Tero Kivinen
   INSIDE Secure
   Eerikinkatu 28
   HELSINKI  FI-00180
   FI

   Email: kivinen at iki.fi






Kivinen & Kinney        Expires October 24, 2016                [Page 5]

Internet-Draft IEEE 802.15.4 Information Element for IETF     April 2016


   Pat Kinney
   Kinney Consulting LLC

   Email: pat.kinney at kinneyconsultingllc.com















































Kivinen & Kinney        Expires October 24, 2016                [Page 6]