Re: [core] draft-bierman-core-yid-00 open questions

Michel Veillette <Michel.Veillette@trilliantinc.com> Wed, 24 August 2016 21:09 UTC

Return-Path: <Michel.Veillette@trilliantinc.com>
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 AE17F12D774 for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 14:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
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 KxJIJ0Y_fxif for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 14:09:24 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0107.outbound.protection.outlook.com [104.47.42.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F61812D76E for <core@ietf.org>; Wed, 24 Aug 2016 14:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iBY09A3sfh/OmEkoPuGmR2vRnZLjBsoya8UuX2qFgzQ=; b=skNN3nO6OFCWCJnHFLbSCMhkPNxIX8m3HisuBv0nOGFR6nbDGHEMynlw+IkdCBgby0Lx3IyYINoU9CYBEKJKHlHbbe/DZJOoo+lnpozI9v6iWX2oYj+3o1kBlwU3dNFXymecZh9AwBwaBY3QTHG62i9Gu2d2MyLFG+C8x+tQDx0=
Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 21:09:22 +0000
Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 21:09:21 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: draft-bierman-core-yid-00 open questions
Thread-Index: AdH+KA3Hq1Q3oFkDSaO2q9py8NuksQAIMi0AAAA158A=
Date: Wed, 24 Aug 2016 21:09:21 +0000
Message-ID: <BN6PR06MB23087BFAB03E7B392DD25825FEEA0@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <BN6PR06MB23088AB49805EAA74057FCB8FEEA0@BN6PR06MB2308.namprd06.prod.outlook.com> <CABCOCHTUdywbbCSxxkFObtrXFScwifBXJLZ2arxy=Ux1UYRhNQ@mail.gmail.com>
In-Reply-To: <CABCOCHTUdywbbCSxxkFObtrXFScwifBXJLZ2arxy=Ux1UYRhNQ@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-ms-office365-filtering-correlation-id: e79d7002-9124-4464-e5b7-08d3cc62eb5c
x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:u7PEe5/xC4jWnXUJ2hu+JTEfCZiOS1zBMaSjDol3Za5BD0ZL0gBLY7FV8g7wMKTiHaVuwd1bR2mWPjKyImVFzDwFxHdWKhUfjaAosmtuD2flYXhLfhjuQrmIEqiOKFH0RntHjmE60Pc5XxGDOXD1aYJHmM/oWk+nl+yfY+5iTFfbza0Cd2Dps+RMWwU+wiogr/WmuhM90DIBHciQKfcpFGxg3LF//Q6V8Ju+730RWCJv+scRsAzd94Bl1ftfkopLjx+i4i0mnQWkbSaqWUdvb2gdoZJJKhpmKjnD60/sOvs=; 5:SGHdk6Yql/Edx4tLREYQhWpPGnnd3SAeH3SiFJG5PUEPPuhuPA3NCvuJOfhC0MLvD7F7ibzQCnaxqIpa1Sy7lmxa6yybHr9h00Tq2zG2574lA+QMvkxuUMlp+PqbS42K9hRucWOgxZxPs0qj4IEUSA==; 24:DSQcqGU5ebWZudwU3zxx4S/uLtlm8bRoD/Xp3jiXmTz2d5JJOrjhbEGf1qqUUBxzLTr+3VMQjbHA/PFaoaow8f7m0itDu4xaGbw/0H7kfAA=; 7:G6yvwlyYw+NWu5Y0VKCngSxAh2H/hfn+jKpl68BjNPqJRCtMP026Ukbjwm9kuyFB5MFEoUfxng5Q90O2aEHHNNNjqMvKadTXjmvbziVoRiIukJBK5bXk3gLkqkAZ19ER0le9vyf433w4AgHE7wkuEQAhzz6+pjeqw3uAwHx+ipVJcohU2yu12aWl+ozGXCyAroEUluRb7k6XjPSQUG2w7z+OUNAgPmi/Fk1EbM3ZsuR9cad63VVyXA4uqCWdTdBn
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307;
x-microsoft-antispam-prvs: <BN6PR06MB230722A24832F7E9BD19FBC5FEEA0@BN6PR06MB2307.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(24454002)(189002)(50986999)(76176999)(110136002)(189998001)(87936001)(97736004)(19580395003)(101416001)(2900100001)(19617315012)(19580405001)(19625215002)(92566002)(2950100001)(33656002)(86362001)(76576001)(68736007)(54356999)(4326007)(105586002)(5660300001)(3660700001)(122556002)(2906002)(77096005)(66066001)(99286002)(10400500002)(8936002)(15975445007)(230783001)(102836003)(19300405004)(7906003)(3846002)(5002640100001)(7736002)(6116002)(8676002)(3280700002)(7846002)(19609705001)(7696003)(586003)(16236675004)(74316002)(9686002)(81166006)(106356001)(81156014)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23087BFAB03E7B392DD25825FEEA0BN6PR06MB2308namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 21:09:21.3404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/fs_JCEE8spOJVOLKSGNsEG8c-Rc>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: Re: [core] draft-bierman-core-yid-00 open questions
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 21:09:27 -0000

Hi Andy

My comments inline [MV]

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Wednesday, August 24, 2016 4:48 PM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: Re: draft-bierman-core-yid-00 open questions



On Wed, Aug 24, 2016 at 9:53 AM, Michel Veillette <Michel.Veillette@trilliantinc.com<mailto:Michel.Veillette@trilliantinc.com>> wrote:
Hi Andy

Following if my answers to the questions listed in draft-bierman-core-yid-00

1) When to assign a module-id

Developers should be in control of when this activity is performed based on the estimated amount of work required to reassign IDs (from temporary assigned IDs within the experimental range to the final IDs) and the impacts on the encoding efficiency of assigning a non stable list of YANG items which generate non sequential IDs. If the developer already own a range of YID/SID, the activity can be perform at any time.

It is important to note that the registration of the resulting .sid file(s) is done independently of the registration of the SID range. When registering a SID range, the module or list of modules targeted is not provided. This give the full freedom to developers to assign IDs when needed.

I think the registration process issues are the same whether a module-id or a range is allocated.

[MV] Not exactly, registering a module-id imply that you need to know the module information in advance.
[MV] If you register a range, you can assign this range as needed to one or multiple modules.
[MV] You don’t need to go back to the registrar each time you create a new module.

2) How to support private numbering

A range called "Experimental" spanning both the 16 and 32 bits unsigned integer have been assigned to this purpose.
https://tools.ietf.org/html/draft-somaraju-core-sid-01#section-7.1


Yes, it seems trivial to assign a range for temporary numbers.




3) How to combine registries

Not needed, all registrars, SDO shall receive a specific range from IANA.


OK, so there is a tiered registration process?
And there will not be a land-grab for all the numbers?
Not clear to me how IANA approves allocation requests.



4) Should more YANG statements be numbered

Yes
rpc, action, notification, module, submodule, feature

Numbering submodule and feature?
These are conceptual statements within the schema language and
do not affect anything on the wire.

[MV] SID assigned to submodules and features are required to support discovery
[MV] See https://tools.ietf.org/html/draft-veillette-core-cool-library-00#section-3.1

5a) How to support anyxml

anyxml represents a single data node with an arbitrary content.
This data node have a single ID assigned to it the same way as any other data node, nothing special is required.


    anyxml foo;


    { "foo" : {
         "bar": 42;
         "baz" "fred",
         "a-list" : [
            ....
         ]
       }
     }


So what numbers do you give to bar,, baz, a-list, etc.?
They are all numbered the same as foo?
That will be decoded with all nodes named foo, all anyxml.
The name, type, value info contained in anyxml and anydata
instances have no schema.  These nodes cannot be numbered.
This is a YANG-to-CBOR issue, not a SID issue.

But in real YANG these child nodes sometimes represent real objects
from some other module.  In this case the server may know the "hidden SID".

http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554

[MV] If the inner members of this CBOR map need to associated to SID, the developer will need to assign these SIDs as described in 5b.
[MV] If this is the case, the author should have used an anydata.
[MV] Normally, an anyxml contain an arbitrary CBOR content which have nothing to do with YANG and SIDs.
[MV] This is the approach proposed by "draft-ietf-netmod-yang-json" and reused by "draft-ietf-core-yang-cbor"


5b) How to support anydata

The anydata define an instance of an unspecified schema node (leaf, leaf-list, container, list).
All possible schema node supported by an anydata need to be register to one of the .sid files.
It is the responsibility of the developer(s) to add these SIDs to one or multiple .sid files manually if not already present.
A section need to be added to the draft to clearly describe this approach.

Regards,
Michel Veillette


Andy