Suresh,
I strongly support the publication of this document. Since it defines a
mechanism which can be used by several working groups, AD sponsoring seems
perfect.
I'm attaching the XML of the the -02 version of that draft in which I have
corrected some typos. I'll let Tero and Pat decide what he wants to merge,
if anything. These changes are for the authors' information only, they do
NOT affect my support to publish this document.
Thomas
On Mon, Jul 18, 2016 at 2:39 PM, Suresh Krishnan <
[email protected]> wrote:
> Hi all,
> I am considering AD sponsoring the following draft
>
> https://tools.ietf.org/html/draft-kivinen-802-15-ie-02
>
> to request the allocation of an 802.15.4 information element from the IEEE
> for use in the IETF protocols that may need it. If you have any concerns
> either with the content of the draft or about requesting the IE at all
> please
> let me know before 2016/07/29.
>
> Thanks
> Suresh
>
> NOTE: I have CCed: all the groups that I thought could be potentially
> interested in this work. If you think I have missed out some WG(s) please
> let
> me know.
>
> _______________________________________________
> IoT-DIR mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/iot-dir
>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category='std' ipr='trust200902'
docName='draft-kivinen-802-15-ie-02.txt'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>
<front>
<title>IEEE 802.15.4 Information Element for IETF</title>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>INSIDE Secure</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>FI</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Pat Kinney" initials="P." surname="Kinney">
<organization>Kinney Consulting LLC</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year='2016' />
<area>Internet</area>
<abstract>
<t>IEEE Std 802.15.4 has Information Elements (IE) 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, and this document requests ANA to allocate a
number for the IETF, and provides information on how the IE is
formatted to provide sub types.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>IEEE Std. 802.15.4 <xref target="IEEE-802-15-4" /> has
Information Elements (IE) that can be used to extend 802.15.4 in an interoperable manner.
There are two different IE
types, Header IE and Payload IE. The Header IEs are part of the
Medium Access Control (MAC) header, and are never encrypted,
but they may be authenticated. Most of the Header IE processing is
done by the MAC, and IETF protocols should not need to extend
them. The Payload IEs are part of the MAC payload and they
may be encrypted and authenticated.</t>
<t>IETF protocols will need to include information in the 802.15.4
frames; the standard 802.15.4 way of doing this is to include
one of more payload IEs in the frame that will contain the information. Because
of this, the IETF needs to obtain a dedicated Payload IE from the IEEE
802.15 Assigned Numbers Authority (ANA) <xref
target='IEEE-802-15-ANA' />. The up-to-date 802.15 ANA database
can be found at <xref target='IEEE-802-15-ANA-DB' />.</t>
<t>The 802.15.4 operations manual <xref target='IEEE-802-15-OPS'
/> provides information on how a standardization organization may
request an allocation of an IE. To make this request,
the standardization organization needs to: provide the reason for
the request; a description of the protocol format that shows there
is sufficient subtype capability; a statement that the external
organization understands that only one ID number will be
issued.</t>
<t>This document provides the information needed for the
request.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref
target='RFC2119'/>.</t>
</section>
<section title="Users of the IETF IE" anchor="users">
<t>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 should provide them a way forward.</t>
</section>
<section title='IETF IE Subtype Format' anchor='ietf-ie'>
<t>The maximum length of the Payload IE content is 2047 octets,
and 802.15.4 frame contains a list of payload IEs, i.e. a single
frame can have multiple payload IEs, terminated with the payload
IE terminator, and may be followed by the payload.</t>
<t>Because the frame contains a list of payloads, there is no
need to provide internal structure inside the IETF IE. The Payload
IE format of the 802.15.4 contains the Length field, so the
length of the Sub-Type Content can be calculated from the Length
field of the IETF IE.</t>
<t>The format of the IETF IE is as follows:</t>
<figure anchor="ietf-ie-figure" title="IETF IE Subtype Format" ><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type ID | |
+-+-+-+-+-+-+-+-+ |
~ Sub-Type Content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="symbols">
<t>Sub-Type ID is the IANA allocated number specifying the
sub-type of the IETF IE. Value 0 is reserved for future
extensibility, i.e., in case a longer Sub-Type ID field is
needed.</t>
<t>Sub-Type Content is the actual content of the information
element, and its length can be calculated from the Length field
of the IETF IE. </t>
</list></t>
<t>One IEEE 802.15.4 frame can contain multiple IETF IEs with the same
or different sub types.</t>
</section>
<section title="Vendor Specific IE">
<t>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.</t>
<t>Because of this, there is no need to reserve the specific
Sub-Type IDs for the vendor-specific uses, as those other IE types
can be used for that.</t>
</section>
<section title="Request to allocate IETF IE">
<t>IETF would request the 802.15.4 Working Group to allocate a
Payload IE for IETF use. Furthermore IETF understands that only
one ID will be issued to it.</t>
</section>
<section title='Security Considerations'>
<t>This document creates an IANA registry for IETF IE Sub-type
IDs, and the security of the protocols using the IEs needs to be
described in the actual documents allocating values from this
registry.</t>
<t>The IEEE Std 802.15.4-2015 <xref target="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, thus all IETF IEs
will have same security level requirements regardless of the
Sub-Type 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. Fortunately, everything IETF does
should be in a higher level than the MAC level, thus the higher
layer processing for these IEs needs to perform separate security
policy checking based on the IETF IE Sub-Type ID in addition to
the checks done by the MAC.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document creates a new registry for IETF IE Sub-type IDs
registry:</t>
<figure><artwork><![CDATA[
Value Sub-type ID
0 Reserved
1-200 Unassigned
201-255 Experimental Use
]]></artwork></figure>
<t>Changes and additions to this registry is by expert review.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title='Informative References'>
<reference anchor='IEEE-802-15-4'>
<front>
<title>IEEE Standard for Low-Rate Wireless Personal Area
Networks (WPANs)</title>
<author></author>
<date year='2015'/>
</front>
<seriesInfo name="IEEE" value="Standard 802.15.4" />
</reference>
<reference anchor='IEEE-802-15-ANA'
target="http://www.ieee802.org/15/ANA.html";>
<front>
<title>IEEE 802.15 Assigned Numbers Authority</title>
<author></author>
<date />
</front>
</reference>
<reference anchor='IEEE-802-15-ANA-DB'
target='https://mentor.ieee.org/802.15/documents?is_dcn=257&is_group=0000'>
<front>
<title>IEEE 802.15 ANA database</title>
<author></author>
<date />
</front>
</reference>
<reference anchor='IEEE-802-15-OPS'
target='https://mentor.ieee.org/802.15/documents?is_dcn=235&is_group=0000'>
<front>
<title>IEEE 802.15 Operations Manual</title>
<author></author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
