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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 March 2016 11:06 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3F41B3694 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.601
X-Spam-Level:
X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS1L1VTWuXaf for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:06:47 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330431B368D for <6tisch@ietf.org>; Fri, 4 Mar 2016 03:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45298; q=dns/txt; s=iport; t=1457089587; x=1458299187; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TjyLJlyZqzueXJn1wA3/euVeCcPo1sfkmONOzm7tQj8=; b=g1FwM0vngMDDNvvNYwlwwtgbE7YMGtZYb2Wu96kp75veJQ4onIo2wU0m zsFaOJ+f/YTGAmuLRnq6W3aAkmS+YtpEzvKznJC7iiFiSBRaDGS+MM0c2 iBczY4x98qolaovmraXfrkC9pITO03Lwpmwpe4E74xW0HKw90QFEzHEXI U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AgDnatlW/5NdJa1aA4JuTFJtBroxD?= =?us-ascii?q?oFpFwEJhSRKAhyBFTgUAQEBAQEBAWQnhEEBAQEEAQEBICYlBQYQAgEIBwoDAQE?= =?us-ascii?q?BKAMCAgIlCxQJCAIEAQ0FCAaIFA6uAI58AQEBAQEBAQEBAQEBAQEBAQEBAQEBD?= =?us-ascii?q?QiGF4M/fYQJEAIBMwoBCwEJCAmCOYE6BYVSggiPRwGDDIM8hGiCMIFphESIU45?= =?us-ascii?q?RAR4BQ4NkagGII34BAQE?=
X-IronPort-AV: E=Sophos; i="5.22,535,1449532800"; d="scan'208,217"; a="83002982"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 11:06:25 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u24B6PoL026357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 11:06:25 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 05:06:24 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 05:06:24 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] 6P and Sf0 issue: IANA IDs
Thread-Index: AQHRdW1SijePZM8se0WhPBK8Z3H65J9JHWoQ
Date: Fri, 4 Mar 2016 11:06:15 +0000
Deferred-Delivery: Fri, 4 Mar 2016 11:06:09 +0000
Message-ID: <0ab9f3bddbab478d8b0d917563577e02@XCH-RCD-001.cisco.com>
References: <CAH7SZV8UpGENL6aEiTXt1txmaLfZ8XhtzB3wJPopL-U6Onqxfg@mail.gmail.com>
In-Reply-To: <CAH7SZV8UpGENL6aEiTXt1txmaLfZ8XhtzB3wJPopL-U6Onqxfg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: multipart/mixed; boundary="_004_0ab9f3bddbab478d8b0d917563577e02XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/46Iszi-CscUFpZDE_TBKCTv5OjQ>
Cc: "'Brian Haberman' \(brian@innovationslab.net\)" <brian@innovationslab.net>
Subject: Re: [6tisch] 6P and Sf0 issue: IANA IDs
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2016 11:06:54 -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:6tisch-bounces@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.kinney@kinneyconsultingllc.com<mailto:pat.kinney@kinneyconsultingllc.com> <pat.kinney@kinneyconsultingllc.com<mailto:pat.kinney@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.watteyne@inria.fr<mailto:thomas.watteyne@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.kinney@kinneyconsultingllc.com<mailto:pat.kinney@kinneyconsultingllc.com> <pat.kinney@kinneyconsultingllc.com<mailto:pat.kinney@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" <bheile@ieee.org<mailto:bheile@ieee.org>>, Watteyne Thomas <6tisch@ietf.org<mailto:6tisch@ietf.org>>, Thubert Pascal <pthubert@cisco.com<mailto:pthubert@cisco.com>>, Brian Haberman <brian@innovationslab.net<mailto:brian@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-IG6T@LISTSERV.IEEE.ORG<mailto:STDS-802-15-IG6T@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.kinney@kinneyconsultingllc.com<mailto:pat.kinney@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 ---