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

Alexander Pelov <a@ackl.io> Wed, 24 August 2016 07:57 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 7C3A4128E18 for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 00:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 E8qOwapUWIKO for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 00:57:14 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825A112B015 for <core@ietf.org>; Wed, 24 Aug 2016 00:57:14 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:18fb:9ee9:cee6:495e] (unknown [IPv6:2001:660:7301:3728:18fb:9ee9:cee6:495e]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EA886A80D7; Wed, 24 Aug 2016 09:57:10 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alexander Pelov <a@ackl.io>
In-Reply-To: <086a18a750b073efaf5fc42c47273d37@xs4all.nl>
Date: Wed, 24 Aug 2016 09:57:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <966138C9-ED80-4876-9A60-5C58B0CAFE17@ackl.io>
References: <8D2B6B77-9FA4-4171-959C-D9080F6AF507@ericsson.com> <B46CF3BB-BF16-4E15-967D-07B1BCD1E4D3@ackl.io> <BN6PR06MB23089B3621DD9CC77AD944A5FEEB0@BN6PR06MB2308.namprd06.prod.outlook.com> <086a18a750b073efaf5fc42c47273d37@xs4all.nl>
To: consultancy@vanderstok.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/NDa6Qz_Bn5ZGfg7FkxaoeLPJxvY>
Cc: "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: Wed, 24 Aug 2016 07:57:18 -0000

Dear Peter,

> Le 24 août 2016 à 08:39, peter van der Stok <stokcons@xs4all.nl> a écrit :
> 
> Some comments based on the arguments below:
> 
>> This draft is a prerequisite for the following works:
>> - CBOR encoding of YANG data model
>> (https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/)
> I have argued already for some time that the text about SIDs does not belong in the yang to cbor draft.
> It reduces its independence from the CoMI work.
> Given that CBOR is not to be changed, Putting the SID text in a content format draft seems more appropriate.

There are two types of identifiers supported by draft-ietf-core-yang-cbor - textual (for full compatibility with RESTConf/NETCONF names) and delta-encoded integers (a.k.a. SIDs). The former could be used when network constraints are not so stringent, while the latter is the preferred way of using this encoding in constrained networks.

We should keep it simple. Having several content formats to express the same thing - especially when this is not necessary - is adding complexity for no reason. 

The SID draft allows for having ranges of SIDs be managed by independent registries and have different rules of assignment. No need to use different Content Formats necessary to solve overlapping of the integer values. Moreover, as of the time of this writing, we have 3 different Content-Formats for the CoOL/CoMI draft. Adding an alternative Content-Format for the interpretation of the integers would multiply this by 2, e.g. 6 content formats, where half are doing the same thing.

If you have a server with mixed modules (e.g. ones using SID and ones using a different interpretation of the IDs), the Content-Format will force you to chose ONE or ANOTHER. There is no possibility in one request to read or write values from different modules. This effectively removes all interoperability between the two, making one of the two redundant. 

Best,
Alexander



>> The alternate assignment algorithm of IDs based on murmur3 and
>> improved description texts  proposed by Andy in
>> (https://datatracker.ietf.org/doc/draft-bierman-core-yid/) don't
>> fundamentally change the registration process defined by the SID draft.
> 
> I should like to wait till this agreement is visible on this mailing list.
> 
> Peter
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core