Subject: [6tisch] 6P and Sf0 issue: IANA IDs

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 3 Mar 2016 13:54:00 -0300

Dear 6tisch chairs,
                            I would like to know which are the steps
to request IDs to IANA, since we need at least the following
ones:

IANA_IETF_IE_GROUP_ID
IANA_6TOP_SUBIE_ID
IANA_6TOP_6P_VERSION
6P command identifiers
6P Return Codes
IANA_SFID_SF0

Are they independent of the draft/RFC status? Do we have
to wait until the drafts get into the standardization track?

Regards,

                           Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Mar 2016 11:06:15 +0000

Hello Diego:

You need a IANA section where you detail which registries you create and which you add to.
Then you need to enumerate the entries that you need, as you do below.

You may suggest values to help interop till you make RFC, but the IANA will have the final word and implementations may need to be updated.

In this particular case, we have discussed where the IE space comes from but I have not seen a final conclusion on that. In particular (quoting Thomas in the attached mail) we have on the table “Choice 2, the ID is allocated to IETF via IANA. There is a defined process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html), it basically starts with a formal request from an IANA officer.  There are only 8 addresses left before going onto extended addresses, so we really need to make sure that each of the 8 addresses will be properly used.”

If we are sure we’ll need the ID regardless of this particular draft, then we may issue a short draft to request it from IANA. As Thomas indicated, we need a very solid justification. It would be good to discuss this at the interim next Friday to prepare for any request / question to the 6TiSHC SG or WG15 who are meeting in Macao the week after.

CC’ing Brian in case I missed something?

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:54
To: [email-masked]
Subject: [6tisch] 6P and Sf0 issue: IANA IDs

Dear 6tisch chairs,

IANA_IETF_IE_GROUP_ID
IANA_6TOP_SUBIE_ID
IANA_6TOP_6P_VERSION
6P command identifiers
6P Return Codes
IANA_SFID_SF0

Regards,
                           Diego Dujovne

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

Subject: Re: [6tisch] IEEE 802.15 6T Interest Group responses to IETF 6tisch requests
From: Thomas Watteyne <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Feb 2016 15:05:42 +0000

Pat,
I suggest we discuss this at the meeting this Friday. I will start a thread on the ML. OK for me to copy-paste the following:

The best way to determine which of these alternatives to use is to define what is required of the IE and how is it used:

Choice 1, the vendor specific ID is already defined in the standard and needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2 followed by 3 octets of the Vendor’s OUI.  Two options here are to request an OUI from the IEEE RAC, or request a company ID from the IEEE RAC.  Regardless, the vendor specific ID adds 3 octets to the IE, which is not a problem if the IE is seldom used, such as configuring the network.

Choice 2, the ID is allocated to IETF via IANA. There is a defined process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html), it basically starts with a formal request from an IANA officer.  There are only 8 addresses left before going onto extended addresses, so we really need to make sure that each of the 8 addresses will be properly used.

Choice 3, the ESDU IE is meant to send a message to another node, it has no inherent formatting, the other node must already understand how to use the information.

If the 6tisch group chooses choice 2, we’ll need a request from IANA.

Thomas

On Fri, Jan 29, 2016 at 1:48 AM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:

   Thanks for your reply Thomas;

   Firstly, as far as the formatting goes, it would be good for the group to entertain any other format.  If there are no other formats proposed, then the recommended one is the de facto format.  If another format is proposed then the WG should agree on a method to decide.

   Secondly, for a unique Payload IE Group ID to be used by 6tisch, there are at least three alternatives: 1) use the vendor specific ID stated in the 802.15.4 standard, 2) request a Payload IE to be assigned to IETF via IANA, and 3) use the Encapsulated Service Data Unit (ESDU) IE ID stated in the 802.15.4 standard.

   The best way to determine which of these alternatives to use is to define what is required of the IE and how is it used:

   Choice 1, the vendor specific ID is already defined in the standard and needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2 followed by 3 octets of the Vendor’s OUI.  Two options here are to request an OUI from the IEEE RAC, or request a company ID from the IEEE RAC.  Regardless, the vendor specific ID adds 3 octets to the IE, which is not a problem if the IE is seldom used, such as configuring the network.

   Choice 2, the ID is allocated to IETF via IANA. There is a defined process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html), it basically starts with a formal request from an IANA officer.  The issue I have with this choice is that we have only 8 addresses left before going onto extended addresses, so we really need to make sure that each of the 8 addresses will be properly used.

   Choice 3, the ESDU IE is meant to send a message to another node, it has no inherent formatting, the other node must already understand how to use the information.

   If the 6tisch group chooses choice 2, we’ll need a request from IANA.

   Thanks, Pat

   On 28, Jan2016, at 14:19, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:

   Pat,

   I realize we never really discussed this, and we haven't given it the attention is deserves in the WG. I don't know how this happened, as this is obviously very important, and a great example of IEEE/IETF liaison. Thank you BTW for the super detailed documents. Again, for some reason, I never thanked you for that.

   I understand the recommendation you make in 6TiSCH_IE_information doc, and agree in principle for the recommendations about the formatting.
   So what's the next step? If I understand the document well, you are asking me to send you another e-mail asking for a IETF Payliad IE ID?
   I agree that a single IETF Payload IE is the right way to go, and we can write up an IETF RFC which details how the sub-id space is managed by the IETF, closely following you recommendations.
   I also agree with the statement that it should be called something different than IANA_6TOP_IE_GROUP_ID, obviously. This naming is mostly an editorial nit, nothing more.

   So what's the next step?
   - I send you another e-mail
   - I start an I-D which detailed how the subID space is managed (you're welcome to author/edit it)
   - IEEE gives us a number
   - we go have a beer together in Buenos Aires?

   Thomas

   ---------- Forwarded message ----------
   From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
   Date: Tue, Dec 1, 2015 at 1:33 AM
   Subject: [6tisch] IEEE 802.15 6T Interest Group responses to IETF 6tisch requests
   To: [email-masked]<mailto:[email-masked]>
   Cc: "Heile Bob Ph., D" <[email-masked]<mailto:[email-masked]>>, Watteyne Thomas <[email-masked]<mailto:[email-masked]>>, Thubert Pascal <[email-masked]<mailto:[email-masked]>>, Brian Haberman <[email-masked]<mailto:[email-masked]>>

   This email is in response to Thomas Watteyne’s email dated 23 October requesting the IEEE 802.15 6T interest group to make a recommendation on IE format.  It also addresses correct settings for the PAN ID compression bit in response to the 6tisch minimal document.

   These documents have been reviewed for accuracy and the IE format recommendation was approved by the 6T interest group.

   Please respond to me or the 6T reflector ([email-masked]<mailto:[email-masked]>) with any concerns or issues you may have with these documents.

   Sincerely, Pat Kinney

   Pat Kinney
   Kinney Consulting LLC
   IEEE 802.15 WG vice chair, SC chair
   ISA100 co-chair, ISA100.20 chair
   O: +1.847.960.3715<tel:%2B1.847.960.3715>
   [email-masked]<mailto:[email-masked]>

   _______________________________________________
   6tisch mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/6tisch

   --

   _______________________________________

   Thomas Watteyne, PhD
   Research Scientist & Innovator, Inria
   Sr Networking Design Eng, Linear Tech
   Founder & co-lead, UC Berkeley OpenWSN
   Co-chair, IETF 6TiSCH

   www.thomaswatteyne.com<http://www.thomaswatteyne.com/>
   _______________________________________
   <15-15-0939-02-0000-IETF_6tisch_IE_Information.docx><15-15-0911-01-0mag-Proper_PAN_ID_Field_Settings_for_802.15.4-2015.docx>

   --

   _______________________________________

   Thomas Watteyne, PhD
   Research Scientist & Innovator, Inria
   Sr Networking Design Eng, Linear Tech
   Founder & co-lead, UC Berkeley OpenWSN
   Co-chair, IETF 6TiSCH

   www.thomaswatteyne.com<http://www.thomaswatteyne.com>
   _______________________________________

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 10 Mar 2016 20:08:39 -0300

Pascal,
          Acknowledge. Let's discuss tomorrow
on choice 2, as you mentioned.
Thank you.
Regards,

                   Diego

2016-03-04 8:06 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> You may suggest values to help interop till you make RFC, but the IANA
> will have the final word and implementations may need to be updated.
>
>
>
> In this particular case, we have discussed where the IE space comes from
> but I have not seen a final conclusion on that. In particular (quoting
> Thomas in the attached mail) we have on the table “*Choice 2, the ID is
> allocated to IETF via IANA. There is a defined process to obtain a Payload
> Group ID (http://www.ieee802.org/15/ANA.html
> <http://www.ieee802.org/15/ANA.html>), it basically starts with a formal
> request from an IANA officer.  There are only 8 addresses left before going
> onto extended addresses, so we really need to make sure that each of the 8
> addresses will be properly used.*”
>
>
>
> If we are sure we’ll need the ID regardless of this particular draft, then
> we may issue a short draft to request it from IANA. As Thomas indicated, we
> need a very solid justification. It would be good to discuss this at the
> interim next Friday to prepare for any request / question to the 6TiSHC SG
> or WG15 who are meeting in Macao the week after.
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* jeudi 3 mars 2016 17:54
> *To:* [email-masked]
> *Subject:* [6tisch] 6P and Sf0 issue: IANA IDs
>
>
>
> Dear 6tisch chairs,
>
> ---------- Message transféré ----------
> I suggest we discuss this at the meeting this Friday. I will start a
> thread on the ML. OK for me to copy-paste the following:
>
> *The best way to determine which of these alternatives to use is to define
> what is required of the IE and how is it used:*
>
> *Choice 1, the vendor specific ID is already defined in the standard and
> needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2
> followed by 3 octets of the Vendor’s OUI.  Two options here are to request
> an OUI from the IEEE RAC, or request a company ID from the IEEE RAC.
> Regardless, the vendor specific ID adds 3 octets to the IE, which is not a
> problem if the IE is seldom used, such as configuring the network.*
>
> *Choice 2, the ID is allocated to IETF via IANA. There is a defined
> process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html
> <http://www.ieee802.org/15/ANA.html>), it basically starts with a formal
> request from an IANA officer.  There are only 8 addresses left before going
> onto extended addresses, so we really need to make sure that each of the 8
> addresses will be properly used.*
>
> *Choice 3, the ESDU IE is meant to send a message to another node, it has
> no inherent formatting, the other node must already understand how to use
> the information.*
>
> *If the 6tisch group chooses choice 2, we’ll need a request from IANA.*
>
> Thomas
>
> On Fri, Jan 29, 2016 at 1:48 AM, [email-masked] <
> [email-masked]> wrote:
>
>> Firstly, as far as the formatting goes, it would be good for the group to
>> entertain any other format.  If there are no other formats proposed, then
>> the recommended one is the de facto format.  If another format is proposed
>> then the WG should agree on a method to decide.
>>
>> Secondly, for a unique Payload IE Group ID to be used by 6tisch, there
>> are at least three alternatives: 1) use the vendor specific ID stated in
>> the 802.15.4 standard, 2) request a Payload IE to be assigned to IETF via
>> IANA, and 3) use the Encapsulated Service Data Unit (ESDU) IE ID stated in
>> the 802.15.4 standard.
>>
>> The best way to determine which of these alternatives to use is to define
>> what is required of the IE and how is it used:
>>
>> Choice 1, the vendor specific ID is already defined in the standard and
>> needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2
>> followed by 3 octets of the Vendor’s OUI.  Two options here are to request
>> an OUI from the IEEE RAC, or request a company ID from the IEEE RAC.
>> Regardless, the vendor specific ID adds 3 octets to the IE, which is not a
>> problem if the IE is seldom used, such as configuring the network.
>>
>> Choice 2, the ID is allocated to IETF via IANA. There is a defined
>> process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html),
>> it basically starts with a formal request from an IANA officer.  The issue
>> I have with this choice is that we have only 8 addresses left before going
>> onto extended addresses, so we really need to make sure that each of the 8
>> addresses will be properly used.
>>
>> Choice 3, the ESDU IE is meant to send a message to another node, it has
>> no inherent formatting, the other node must already understand how to use
>> the information.
>>
>> On 28, Jan2016, at 14:19, Thomas Watteyne <[email-masked]>
>> wrote:
>>
>> Pat,
>>
>> I realize we never really discussed this, and we haven't given it the
>> attention is deserves in the WG. I don't know how this happened, as this is
>> obviously very important, and a great example of IEEE/IETF liaison. Thank
>> you BTW for the super detailed documents. Again, for some reason, I never
>> thanked you for that.
>>
>> I understand the recommendation you make in 6TiSCH_IE_information doc,
>> and agree in principle for the recommendations about the formatting.
>> So what's the next step? If I understand the document well, you are
>> asking me to send you another e-mail asking for a IETF Payliad IE ID?
>> I agree that a single IETF Payload IE is the right way to go, and we can
>> write up an IETF RFC which details how the sub-id space is managed by the
>> IETF, closely following you recommendations.
>> I also agree with the statement that it should be called something
>> different than IANA_6TOP_IE_GROUP_ID, obviously. This naming is mostly an
>> editorial nit, nothing more.
>>
>> So what's the next step?
>> From: [email-masked] <
>> [email-masked]>
>> Cc: "Heile Bob Ph., D" <[email-masked]>, Watteyne Thomas <
>> [email-masked]>, Thubert Pascal <[email-masked]>, Brian Haberman <
>> [email-masked]>
>>
>>
>> This email is in response to Thomas Watteyne’s email dated 23 October
>> requesting the IEEE 802.15 6T interest group to make a recommendation on IE
>> format.  It also addresses correct settings for the PAN ID compression bit
>> in response to the 6tisch minimal document.
>>
>> These documents have been reviewed for accuracy and the IE format
>> recommendation was approved by the 6T interest group.
>>
>> Please respond to me or the 6T reflector (
>> [email-masked]) with any concerns or issues you may
>> have with these documents.
>>
>> Sincerely, Pat Kinney
>>
>>
>>
>>
>>
>>
>>
>> Pat Kinney
>> Kinney Consulting LLC
>> O: +1.847.960.3715
>> [email-masked]
>>
>>
>>
>>
>>
>>
>>
>>
>> [email-masked]
>> www.thomaswatteyne.com
>> <15-15-0939-02-0000-IETF_6tisch_IE_Information.docx>
>> <15-15-0911-01-0mag-Proper_PAN_ID_Field_Settings_for_802.15.4-2015.docx>
>>
>>
>
>
> --
> www.thomaswatteyne.com