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: A0C0AgDnatlW/5NdJa1aA4JuTFJtBroxDoFpFwEJhSRKAhyBFTgUAQEBAQEBAWQnhEEBAQEEAQEBICYlBQYQAgEIBwoDAQEBKAMCAgIlCxQJCAIEAQ0FCAaIFA6uAI58AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGF4M/fYQJEAIBMwoBCwEJCAmCOYE6BYVSggiPRwGDDIM8hGiCMIFphESIU45RAR4BQ4NkagGII34BAQE
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, 04 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 ---
- [6tisch] 6P and Sf0 issue: IANA IDs Prof. Diego Dujovne
- Re: [6tisch] 6P and Sf0 issue: IANA IDs Pascal Thubert (pthubert)
- Re: [6tisch] 6P and Sf0 issue: IANA IDs Prof. Diego Dujovne