Re: [core] ietf-cool YANG module

Michel Veillette <Michel.Veillette@trilliantinc.com> Thu, 17 December 2015 15:34 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D131B2EC7 for <core@ietfa.amsl.com>; Thu, 17 Dec 2015 07:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 TqrjAuw6XqMU for <core@ietfa.amsl.com>; Thu, 17 Dec 2015 07:34:33 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD2B1B2EC3 for <core@ietf.org>; Thu, 17 Dec 2015 07:34:33 -0800 (PST)
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 17 Dec 2015 15:34:31 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0361.006; Thu, 17 Dec 2015 15:34:31 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>, Core <core@ietf.org>
Thread-Topic: [core] ietf-cool YANG module
Thread-Index: AQHROHPrVbCFaEUjFEe53zJemfgelJ7PSV8A
Date: Thu, 17 Dec 2015 15:34:31 +0000
Message-ID: <BLUPR06MB1763EED13B126A1144D93B79FEE00@BLUPR06MB1763.namprd06.prod.outlook.com>
References: <CABCOCHQN2s7RbNon4kyTfXG8QCFyT+GJZ3CLtm60WCJCCsL2dQ@mail.gmail.com>
In-Reply-To: <CABCOCHQN2s7RbNon4kyTfXG8QCFyT+GJZ3CLtm60WCJCCsL2dQ@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:6qjx3jTmM72H9hUJXxJVBKtVuZmA0Lb5CGwdzBR2f1Bjan+Octuzp15cSyHgkQUmP2UnfSVBhpctAXQNR6Apxm+qFyyMwVdvEDqG+RGb0lQrojLzA2S6DNQkl30/3zbExoooYE1J3e2Y8xMX9545ug==; 24:UPn9d1ak5Y3ddaGCYMWh1DnOwXH76WM5huKbJdLZSyI439+A8XAQoESgJR0jDQe4NywYBN070UlBbptvTPsbPhnFmK/KUW62aeqJF+ioNDg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762;
x-microsoft-antispam-prvs: <BLUPR06MB17626B39161842D4D6A42420FEE00@BLUPR06MB1762.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762;
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(189002)(377454003)(199003)(66066001)(5002640100001)(19580405001)(15975445007)(122556002)(40100003)(87936001)(5008740100001)(81156007)(5003600100002)(5001770100001)(97736004)(86362001)(5001960100002)(19617315012)(107886002)(92566002)(11100500001)(189998001)(76176999)(33656002)(6116002)(99286002)(3846002)(74316001)(790700001)(1220700001)(1096002)(19300405004)(54356999)(101416001)(77096005)(102836003)(16236675004)(50986999)(10400500002)(76576001)(2900100001)(19625215002)(5004730100002)(106356001)(105586002)(586003)(106116001)(19580395003)(2950100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763EED13B126A1144D93B79FEE00BLUPR06MB1763namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 15:34:31.0801 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/op8pSTS0v2h9h1SCquv9Uhr5mGw>
Subject: Re: [core] ietf-cool YANG module
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 17 Dec 2015 15:34:35 -0000

Hi Andy

We are currently evaluating a solution to address two of your previous comments:
- The number of objects per YANG module should not be limited to 1024
- IDs assigned to an object shall never change between versions.

To address the first one, we are proposing the use of variable size allocation blocs and the ability to assign more that one bloc to the same module. In practice, this means that we move away of the concept of Module ID and this 20 bits / 10 bits structure within the data node identifier. To maintain and even improve message compactness, we are adopting delta encoding, a solution proposed by Laurent in Prague.

To address your second comment, we propose to introduce the .sid file. This file will contain the list of objects allocated. This file can be automatically generated by a YANG validator. This file can be publish by registrars and is used as input when a new revision is released, to extend the list of objects while preserving those already allocated.

You will find more details about these concepts and the .sid file format at the following link:
https://www.dropbox.com/s/2akirh2l8k4648i/ietf%2095%20structured%20identifiers.pptx?dl=0

Now back to your current questions:
About "what is to prevent 2 different modules from assigning the same module-id"

With the introduction of the .sid file, all proposed extensions will be removed.
The question remain, how two objects don't get the same ID.
Allocation ranges need to be managed by the different tiers involved (IANA, registrars and developers).
This is not novel, ZigBee and LWM2M do the same.
What is novel is the use of the YANG modeling language and the automatic assignment of IDs.

About "Neither of these drafts are mentioned anywhere, such as the reference section"
Effectively, references and justifications need to be added.
The current development effort is on the mapping and problem statement but I'll keep this
in mind when it will be time to address the function set.

Thanks for your comments
Michel

From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: December-16-15 9:38 PM
To: Core <core@ietf.org>
Subject: [core] ietf-cool YANG module

Hi,

I noticed in this YANG module in draft-veillette-core-cool-00,
there are YANG extensions to put the module-id and object IDs in the
YANG module.  If the numbering comes from these extensions,
what is to prevent 2 different modules from assigning the same module-id?

I see there is a patch-request and patch-response that look rather similar
to the ietf-yang-patch module being developed by the NETCONF WG.
There is also an ietf-cool-library module that looks rather similar to the
ietf-yang-library module being developed by the NETCONF WG.
Neither of these drafts are mentioned anywhere, such as the reference section.


Andy