Re: [core] 🔔 Working Group Adoption call for draft-somaraju-core-sid

Alexander Pelov <a@ackl.io> Tue, 23 August 2016 08:37 UTC

Return-Path: <a@ackl.io>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9145812D8A0; Tue, 23 Aug 2016 01:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 DoCpjWYv23LQ; Tue, 23 Aug 2016 01:37:21 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E5812D89F; Tue, 23 Aug 2016 01:37:21 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:dced:8e63:3ef2:ee4f] (unknown [IPv6:2001:660:7301:3728:dced:8e63:3ef2:ee4f]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 166971720B3; Tue, 23 Aug 2016 10:37:18 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D7312D5B-EDF7-477E-85DC-1456F66A28BA"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alexander Pelov <a@ackl.io>
In-Reply-To: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com>
Date: Tue, 23 Aug 2016 10:37:12 +0200
Message-Id: <B46CF3BB-BF16-4E15-967D-07B1BCD1E4D3@ackl.io>
References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com>
To: Jaime Jiménez <jaime.jimenez@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/QJm_4OYNM_WJaYfH-5KXcSNkl3w>
Cc: "draft-somaraju-core-sid@ietf.org" <draft-somaraju-core-sid@ietf.org>, "core@ietf.org WG" <core@ietf.org>
Subject: Re: [core] 🔔 Working Group Adoption call for draft-somaraju-core-sid
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2016 08:37:25 -0000

Dear all,

I want to confirm my support for the adoption of the document draft-somaraju-core-sid (a.k.a. the SID draft).

I do so for the following main reasons:
- We need a way to represent YANG identifiers for the draft-ietf-core-yang-cbor. The SID draft provides just this. We must adopt the document if we want to move forward with the work on this WG item.
- The SID draft is the result of more than a year and a half of discussions with people from CoRE, NETMOD, IANA and other SDOs.
- It is a straightforward and simple document, which provides the minimal structure on top of which IDs can be allocated.
- It provides for a way of having multiple independent registries, keeping all interoperable, and relieving IANA from the need to do overcomplicated, per-device allocations.
- Running code. There is a tool and a registry which are already used for prototyping. 


The SID draft is aimed at:
- Interoperability (having devices with modules from different registries on a single network). 

- Future-proof. The authors understand that today there are less than 2000 YANG modules. Yet, the ranges which will be allocated are FOREVER. This means, that in 2046, we’ll still be allocating IDs from the ranges we provide today. Independently of the size of identifiers, delta-encoding provides for ultra-efficient data transfer. However, once we move over the 32-bit identifiers, we’ll be taking a 8-byte penalty hit per request. The SID draft provides for a very straightforward and simple way of allocating blocks of IDs as necessary for a module.

- Constrained-device and constrained-network oriented (if needed) - after months of discussions we have confirmed that the most efficient way of representing the data items is with delta-encoding. When retrieving more than one item, the IDs take one byte on the wire in most cases. The allocation of IDs can be manual, automatic, or other - this is not enforced. What the draft enables is the users to make use of this ultra-efficient identifier representation - if they need it. 
  - If not needed - an alternative mapping scheme can be used, e.g. trading interoperability and ultra-efficiency for compatibility with existing implementations.


In conclusion, we need the SID draft to be able to move forward with our WG item - the YANG-CBOR draft. 

Best,
Alexander

Disclaimer: I am one of the authors of the draft. I believe we could make adjustments after the adoption OR decide to have specific drafts for specific use-cases, but we should not spend too much time getting back-and-fourth in changing the WG draft. 


> Le 15 août 2016 à 17:06, Jaime Jiménez <jaime.jimenez@ericsson.com> a écrit :
> 
> Dear CoRE-WG,
> 
> As we discussed at last IETF96, working group adoption has been requested for draft-somaraju-core-sid. At the IETF meeting the room consensus was for adoption (3 people), since not too many people had read the draft we have to take it to the list. Please reply with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.
> 
> Since there are several concurrent WGA calls, we will end the call on August 26, 2016.
> 
> Thanks,
> Jaime and Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core