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:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:54
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: IANA IDs
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<http://www.ingenieria.udp.cl>
(56 2) 676 8125
--- Begin Message ---
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,
pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>
<pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>>
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
<thomas.watte...@inria.fr<mailto:thomas.watte...@inria.fr>> 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:
pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>
<pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>>
Date: Tue, Dec 1, 2015 at 1:33 AM
Subject: [6tisch] IEEE 802.15 6T Interest Group responses to IETF 6tisch
requests
To: 6tisch@ietf.org<mailto:6tisch@ietf.org>
Cc: "Heile Bob Ph., D" <bhe...@ieee.org<mailto:bhe...@ieee.org>>, Watteyne
Thomas <6tisch@ietf.org<mailto:6tisch@ietf.org>>, Thubert Pascal
<pthub...@cisco.com<mailto:pthub...@cisco.com>>, Brian Haberman
<br...@innovationslab.net<mailto:br...@innovationslab.net>>
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
(stds-802-15-i...@listserv.ieee.org<mailto:stds-802-15-i...@listserv.ieee.org>)
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>
pat.kin...@kinneyconsultingllc.com<mailto:pat.kin...@kinneyconsultingllc.com>
_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
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>
_______________________________________
--- End Message ---
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
