Subject: [Int-dir] draft-kivinen-802-15-ie-02.txt

From: Charlie Perkins <[email-masked]>
Date: Thu, 20 Oct 2016 21:21:52 -0700

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.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 21 Oct 2016 07:47:58 -0500

To address your bulleted comments:
Why is Section 5 included: Section 5 is informative on using the Vendor Specific IE.  Although it isn’t strictly needed, it doesn’t hurt and could help a reader to better understand
Rewording Section 6: You’re correct, the sentence should be reworded to state "IETF requests that the 802.15.4 Working Group to allocate an ID for a Payload IE for IETF use.
different security model requires another IE: as per the 802.15 operations manual - " Only one number shall be assigned to an external organization (e.g an SDO or an open alliance/consortium) from an ID category.  
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
ISA100 co-chair, ISA100.20 chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 20, Oct2016, at 23:21, Charlie Perkins <[email-masked]> wrote:

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, seehttp://www.ietf.org/iesg/directorate.html <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.
<Diff  draft-kivinen-802-15-ie-02.txt - draft-kivinen-802-15-ie-02cep.txt.htm><draft-kivinen-802-15-ie-02cep.txt>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2016 17:31:48 +0300

Charlie Perkins writes:
> <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.

I have tried to make all your changes to my draft, but as your review
was for 02, and there was already 03 out there, I could not make
direct apply for your changes. Please, check them from the attached
version (both final text and diff from your version to the 04
version).

I will submit the 04 version when I get feedback from you, whether the
changes done were ok. 

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

The reason why section 5 is needed, is to explain that there is no
need to do vendor specific range in the IETF IE, as there is so many
other ways to do vendor specific IEs already.

I.e., section 8 do not have range reserved for Private Use. In normal
case we always have such range, now we do not.

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

Pat Kinney already commented this, and I took his text for this.

>   * 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

We cannot get another IE, as Operations manual does not permit
802.15.4 to give us another...

On the other hand, higher layer processing those IETF IEs will make
their own security processing checks, and we do not really want to
use MAC level checks. The MAC level checks are needed for those things
which are acted on the MAC level. IETF IE should not have anything
like that, so we do not need to rely on the MAC level checks. 

>     document still will need a close proofreading.

That seems to be always an issue with my drafts :-)

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

For the:

    /* 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.
       */

The Length field is part of the IEEE 802.15.4 Payload IE format, and
is not shown in the Figure 1, as it is not part of the IETF IE subtype
format.

I changed the text to say :

	The length of the subtype content can be calculated from the
	IEEE 802.15.4 Payload IE Length field of the IETF IE.

I.e., added "IEEE 802.15.4 Payload IE" before the Length field to
indicate it is not part of the IETF IE.

< draft-kivinen-802-15-ie-02cep.txt

draft-kivinen-802-15-4-ie-04.txt >

Network Working Group T. Kivinen

Network Working Group T. Kivinen

Internet-Draft INSIDE Secure

Internet-Draft INSIDE Secure

Intended status: Standards Track P. Kinney

Intended status: Standards Track P. Kinney

Expires: October 24, 2016 Kinney Consulting LLC

Expires: April 27, 2017 Kinney Consulting LLC

April 22, 2016

October 24, 2016

IEEE 802.15.4 Information Element for IETF

IEEE 802.15.4 Information Element for IETF

draft-kivinen-802-15-ie-02.txt

draft-kivinen-802-15-ie-04.txt

Abstract

Abstract

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used

extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned

to extend 802.15.4 in an interoperable manner. The IEEE 802.15

Numbers Authority (ANA) manages the registry of the Information

Assigned Numbers Authority (ANA) manages the registry of the

Elements. This document formulates a request for ANA to allocate a number

Information Elements. This document formulates a request for ANA to

from that registry for

allocate a number from that registry for IETF, and describes how the

IETF, and describes how the IE is formatted to provide

IE is formatted to provide subtypes.

subtypes.

Status of This Memo

Status of This Memo

This Internet-Draft is submitted in full conformance with the

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF). Note that other groups may also distribute

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet-

working documents as Internet-Drafts. The list of current Internet-

Drafts is at http://datatracker.ietf.org/drafts/current/.

Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

material or to cite them other than as "work in progress."

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

This Internet-Draft will expire on April 27, 2017.

Copyright Notice

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the

Copyright (c) 2016 IETF Trust and the persons identified as the

document authors. All rights reserved.

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

described in the Simplified BSD License.

Table of Contents

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Users of the IETF IE . . . . . . . . . . . . . . . . . . . . 3

3. Working Groups Benefitting from the IETF 802.15.4 IE . . . . 3

4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3

4. IETF IE Subtype Format . . . . . . . . . . . . . . . . . . . 3

5. Vendor Specific IE . . . . . . . . . . . . . . . . . . . . . 4

5. Vendor Specific IE . . . . . . . . . . . . . . . . . . . . . 4

6. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4

6. Request to allocate IETF IE . . . . . . . . . . . . . . . . . 4

7. Security Considerations . . . . . . . . . . . . . . . . . . . 4

7. Security Considerations . . . . . . . . . . . . . . . . . . . 4

8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4

8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4

9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5

9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5

9.1. Normative References . . . . . . . . . . . . . . . . . . 5

9.1. Normative References . . . . . . . . . . . . . . . . . . 5

9.2. Informative References . . . . . . . . . . . . . . . . . 5

9.2. Informative References . . . . . . . . . . . . . . . . . 5

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction

1. Introduction

The IEEE Std. 802.15.4 [IEEE-802-15-4] defines Information Elements (IE)

IEEE Std. 802.15.4 [IEEE-802-15-4] defines Information Elements (IEs)

that can be used to extended the 802.15.4 in an interoperable manner.

that can be used to extend 802.15.4 in an interoperable manner.

There are two different IE types, Header IE and Payload IE. A

There are two different IE types, Header IE and Payload IE. A Header

Header IEs is part of the Medium Access Control (MAC) header;

IE is part of the Medium Access Control (MAC) header; it is never

it is never encrypted, but they may be authenticated. Most of the

encrypted, but they may be authenticated. Most of the Header IE

Header IE processing is done by the MAC, and IETF protocols should not have

processing is done by the MAC, and IETF protocols should not have any

any direct effect on that processing. A Payload IE is part of the MAC

direct effect on that processing. A Payload IE is part of the MAC

payload, and may be encrypted and authenticated.

payload, and may be encrypted and authenticated.

IETF protocols will need to insert information in the 802.15.4

IETF protocols will need to insert information in the 802.15.4

frames, and 802.15.4 enables that by including payload

frames; the 802.15.4 enables that by including one or more payload

IE in the frame that will contain the information. For this purpose

IEs in the frame that will contain the information. For this purpose

the IETF requests a dedicated Payload IE from IEEE 802.15

the IETF requests a dedicated Payload IE from the IEEE 802.15

Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The current

Assigned Numbers Authority (ANA) [IEEE-802-15-ANA]. The current

802.15 ANA database can be found in [IEEE-802-15-ANA-DB].

802.15 ANA database can be found at [IEEE-802-15-ANA-DB].

The 802.15.4 operations manual [IEEE-802-15-OPS] describes

The 802.15.4 operations manual [IEEE-802-15-OPS] describes how a

how a standardization organization (SDO) may request an allocation of

standardization organization (SDO) may request an allocation of one

one IE. To make this request the SDO

IE. To make this request the SDO has to provide (i) the reason for

has to provide (i) the reason for the request, (ii) a

the request, (ii) a description of the protocol format that shows an

description of the protocol format that shows an appropriate

appropriate subtype capability, and (iii) an agreement that only one

subtype capability, and (iii) an agreement

IE number will be allocated for use by the SDO.

that only one IE number will be allocated for use by the SDO.

This document provides the information needed for the request.

This document provides the information needed for the request.

2. Terminology

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [RFC2119].

document are to be interpreted as described in [RFC2119].

3. Working Groups Benefitting from the IETF 802.15.4 IE

3. Working Groups Benefitting from the IETF 802.15.4 IE

There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc,

There are several IETF working groups such as 6TiSCH, 6lo, CoRE etc,

which could benefit from the IETF IE. The 6TiSCH working group has

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

already expressed the need for the IE, and this allocation is

satisfy that need.

expected to satisfy that need.

4. IETF IE Subtype Format

4. IETF IE Subtype Format

The maximum length of the Payload IE content is 2047 octets, and

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

802.15.4 frame contains a list of payload IEs. A single frame can

can have multiple payload IEs, terminated with the payload IE

have multiple payload IEs, terminated with the payload IE terminator,

terminator, which may then be followed by the payload.

which may then be followed by the payload.

Because the frame contains a list of the payload IEs, there is no need

Because the frame contains a list of payload IEs, there is no need

for this document to specify the internal structure inside the IETF IE. The Payload IE

for this document to specify the internal structure inside the IETF

format of IEEE 802.15.4 contains the Length field. The length of

IE. The Payload IE format of IEEE 802.15.4 contains the Length

the subtype content can be calculated from the Length field of the

field. The length of the subtype content can be calculated from the

IETF IE.

IEEE 802.15.4 Payload IE Length field of the IETF IE.

The format of the IETF IE is as follows:

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

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

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 ID | |

+-+-+-+-+-+-+-+-+ |

+-+-+-+-+-+-+-+-+ |

~ subtype content ~

~ subtype content ~

| |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: IETF IE Subtype Format

Figure 1: IETF IE Subtype Format

o Subtype ID is the IANA allocated number specifying the subtype

o Subtype ID is the IANA allocated number specifying the subtype of

of the IETF IE. Value 0 is reserved for future extensibility,

the IETF IE. Value 0 is reserved for future extensibility, i.e.,

i.e., in case a longer SubType ID field is needed.

in case a longer subtype ID field is needed.

o Subtype content is the actual content of the information element,

o Subtype content is the actual content of the information element,

and its length can be calculated from the Length field of the IETF

and its length can be calculated from the Length field of the IETF

IE.

IE.

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

One IEEE 802.15.4 frame MAY contain multiple IETF IEs with the same

different subtypes.

or different subtypes.

5. Vendor Specific IE

5. Vendor Specific IE

IEEE 802.15.4 has already several numbers for different Vendor

IEEE 802.15.4 has already several numbers for different Vendor

Specific IE types. There is one for the Vendor Specifc Header IE for

Specific IE types. There is one for the Vendor Specific Header IE

Header IEs. There is one incorrectly named Vendor Specific Nested IE

for Header IEs. There is one incorrectly named Vendor Specific

for Payload IEs, and there is also another one with exactly same

Nested IE for Payload IEs, and there is another one with exactly the

name, but under the MLME Nested IE long format. All of the Vendor

same name, but under the MLME Nested IE long format. All of the

Specific IEs have 3 octet vendor OUI in beginning to identify the

Vendor Specific IEs start with a 3-octet vendor OUI to identify the

organization.

organization.

Because of this there is no need to reserve any subtype IDs

Because of this, there is no need to reserve any subtype IDs for the

for the vendor specific uses, as the above-mentioned Vendor Specific IE

vendor-specific uses, as above-mentioned Vendor Specific IE types can

types can be used for that.

be used for that.

/* CEP: I am not clear why this section is needed. */

6. Request to allocate IETF IE

6. Request to allocate IETF IE

IETF requests the 802.15.4 Working Group to allocate an ID for a Payload

IETF would requests that the 802.15 Working Group allocate an ID for

IE for IETF use. It is agreed that only one ID will

a Payload IE for IETF use. Furthermore IETF understands that only

be issued for use by IETF protocols.

one ID will be issued to it.

/* CEP: isn't this supposed to be a request to ANA? */

7. Security Considerations

7. Security Considerations

This document creates an IANA registry for IETF IE subtype IDs (see section

This document creates an IANA registry for IETF IE subtype ID (see

8).

Section 8). The security of the protocols using the IEs MUST be

The security of the protocols using the IEs MUST be described in

described in the documents requesting allocations from this registry.

the documents requesting allocations from this registry.

The IEEE Std 802.15.4-2015 [IEEE-802-15-4] contains methods where

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

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

is only per IE type. Therefore, all IETF IEs will have same security

requirements regardless of the subtype ID used. This can cause

level requirements regardless of the subtype ID used. This can cause

issues if different security processing would be needed and any of

issues if different security processing would be needed and any of

those IEs would need to be processed in the MAC level. Since all

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,

IETF protocols should operate at a higher level than the MAC level,

the higher layer processing for these IEs SHOULD perform

the higher layer processing for these IEs SHOULD perform separate

separate security policy checking based on the IETF IE subtype ID in

security policy checking based on the IETF IE subtype ID in addition

addition to the checks done by the MAC.

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

8. IANA Considerations

/* CEP: bad pagination */

This document creates a new registry for IETF IE subtype IDs

This document creates a new registry for IETF IE subtype IDs

registry:

registry:

Value Subtype ID

Value Subtype ID

0 Reserved

0 Reserved

1-200 Unassigned

1-200 Unassigned

201-255 Experimental Use

201-255 Experimental Use

Any change or addition to this registry requires expert review.

Any change or addition to this registry requires expert review.

End of changes. 24 change blocks.

75 lines changed or deleted

64 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

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

               IEEE 802.15.4 Information Element for IETF
                     draft-kivinen-802-15-ie-04.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 April 27, 2017.

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 April 27, 2017                 [Page 1]

Internet-Draft IEEE 802.15.4 Information Element for IETF   October 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.  Working Groups Benefitting from the IETF 802.15.4 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

   IEEE Std. 802.15.4 [IEEE-802-15-4] defines Information Elements (IEs)
   that can be used to extend 802.15.4 in an interoperable manner.
   There are two different IE types, Header IE and Payload IE.  A Header
   IE 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; the 802.15.4 enables that by including one or more payload
   IEs in the frame that will contain the information.  For this purpose
   the IETF requests a dedicated Payload IE from the IEEE 802.15
   Assigned Numbers Authority (ANA) [IEEE-802-15-ANA].  The current
   802.15 ANA database can be found at [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 April 27, 2017                 [Page 2]

Internet-Draft IEEE 802.15.4 Information Element for IETF   October 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 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
   IEEE 802.15.4 Payload IE Length field of the IETF IE.

   The format of the IETF IE is as follows:

                        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 April 27, 2017                 [Page 3]

Internet-Draft IEEE 802.15.4 Information Element for IETF   October 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 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.

   Because of this, there is no need to reserve any subtype IDs for the
   vendor-specific uses, as above-mentioned Vendor Specific IE types can
   be used for that.

6.  Request to allocate IETF IE

   IETF would requests that the 802.15 Working Group allocate an ID for
   a Payload IE for IETF use.  Furthermore IETF understands that only
   one ID will be issued to it.

7.  Security Considerations

   This document creates an IANA registry for IETF IE subtype ID (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.

8.  IANA Considerations

   This document creates a new registry for IETF IE subtype IDs
   registry:

Kivinen & Kinney         Expires April 27, 2017                 [Page 4]

Internet-Draft IEEE 802.15.4 Information Element for IETF   October 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: [email-masked]

Kivinen & Kinney         Expires April 27, 2017                 [Page 5]

Internet-Draft IEEE 802.15.4 Information Element for IETF   October 2016

   Pat Kinney
   Kinney Consulting LLC

   Email: [email-masked]

Kivinen & Kinney         Expires April 27, 2017                 [Page 6]
-- 
[email-masked]

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 24 Oct 2016 20:31:12 -0700

Hello Tero and all,

I reviewed the document revision ...-04.txt that you sent.  It looks 
good.  I have a couple of miniscule editorial comments down below.

Regarding the need for the Vendor IE section:  it still seems to me that 
the section would work well as an appendix.  But, especially if it is to 
be maintained in the normative text, perhaps the title could be changed 
to "Vendor Specific IE not needed" to make the purpose of the section 
even more clear.

On further reflection, I think you are indeed right that any additional 
security policy should anyway be checked at protocol layers higher than 
the MAC layer, and your wording in the Security Considerations section 
does express that thought.

Miniscule editorial suggestions follow:

  * "                                              it is never
    encrypted, but they may be authenticated"
      o the clauses are mismatched.  I think the simplest fix is to
        delete the word "they".

  * "IETF would requests" --> "IETF would request" --> "The IETF would
    request" --> "The IETF requests"
      o The first one is wrong, the second one uses the subjunctive but
        I don't know why, the third one sounds a little better to me,
        but the fourth one is declarative and I think that is actually
        best for what is intended.  In the next sentence I think that
        "Furthermore IETF" should be "Furthermore the IETF".  This could
        simply be a regional preference on my part.

I'd also like to echo Pascal's appreciation for your production of this 
badly needed Internet Draft.

Regards,
Charlie P.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2016 15:47:43 +0300

Charlie Perkins writes:
> Regarding the need for the Vendor IE section:  it still seems to me that the
> section would work well as an appendix.  But, especially if it is to be
> maintained in the normative text, perhaps the title could be changed to
> "Vendor Specific IE not needed" to make the purpose of the section even more
> clear.

I moved it to the appendix and changed the title to "Vendor Specific
IE in IEEE 802.15.4".

> security policy should anyway be checked at protocol layers higher than the
> MAC layer, and your wording in the Security Considerations section does
> express that thought.
> 
>       + the clauses are mismatched.  I think the simplest fix is to delete the
>         word "they".

Fixed.

>       + The first one is wrong, the second one uses the subjunctive but I
>         don't know why, the third one sounds a little better to me, but the
>         fourth one is declarative and I think that is actually best for what
>         is intended.  In the next sentence I think that "Furthermore IETF"
>         should be "Furthermore the IETF".  This could simply be a regional
>         preference on my part.

Fixed, here is whole paragraph:

5.  Request to allocate IETF IE

   The IETF requests that the 802.15 Working Group allocate an ID for a
   Payload IE for IETF use.  Furthermore the IETF understands that only
   one ID will be issued to it.

> I'd also like to echo Pascal's appreciation for your production of this badly
> needed Internet Draft.

I will submit the modified draft now.
-- 
[email-masked]