[adding 6TiSCH]

Andy,

I believe the issue Michel highlights is that the ha= sh collisions depends on the modules that are implemented in the CoMI endpo= int.

That is, if nodeA implements the [/6t,/foo] m= odules, and nodeB the [/6t,/bar] modules, the hash collisions can be differ= ent, even in the same "6t" module. In the case of 6top, the YANG = model describes the module completely. It would be awfully nice to be able = to just rely on that YANG model to predict the hash collisions within that = module.without having to discover the rehash-map on a server each time.

IIRC, today, a client accessing any resource using Co= MI needs to first retrieve the hash-map? The client needs to do this for ea= ch node is manages, potentially periodically if new modules are added on-th= e-fly? This seems like a lot of uncessary overhead.

One way could be fr the server to return some error code when the client = accesses a resource with a hash that is ambiguous.

Your insight on this is very welcome.

Thomas

On Tue, Ma= r 31, 2015 at 3:46 AM, Andy Bierman <andy@yumaworks.com> wr= ote:

On Mon, Mar 30, 201= 5 at 12:43 PM, Michel Veillette
<Michel.Veillette@t= rilliantinc.com> wrote:
> Currently, CoMI object identifiers (YANG hash) are globally unique wit= hin a CoMI server. Devices implementing different set of modules may have d= ifferent YANG hash conflicts and may have a different set of object identif= iers affected by rehash. In an application like 6TiSH, this means that the = list of rehash values can't be known in advance based on the published = YANG module, rehash values need to be discover and manage by each node invo= lved in the timeslots reservation process.
>
> Reducing the scope of the YANG hash to the context of a single module = (data nodes defined by a module + data nodes added to that module by the au= gment statement) can mitigate this issue. The question is how this can be a= ccomplished and if the overhead required make this change acceptable.
>

I don't think this will work.
The probability of collisions is the same whether 100 objects
are defined in 1 module or 10 objects are defined in each of 10 modules.
The client must implement the rehash algorithm even though there is
a low probability it will be used.

Andy

> Impacts on the URI
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Currently, the CoAP path consist of:
>=C2=A0 "/mg/<hash-value>"
>
> Considering that the YANG hash is unique only within the context of a = module, the CoAP path needs to include the module name:
> "/mg/data" or
>=C2=A0 "/mg/data/<moduleName>: <hash-value>"
>
> Impacts on the CBOR content
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> If the CoAP path target a specific module (e.g. "/mg/data/<mod= uleName>: <hash-value>"), the current CBOR encoding rules sho= uld apply unmodified.
>
> If the CoAP path target multiple modules (e.g. "/mg/data"), = CoMI objects need to be associated to their respective module context. A CB= OR map added to the root of the CBOR object can be used to establish this r= elationship.
>
> For example
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Assuming:
> - hash of "/6top:CellList" =3D=C2=A0 0x3470d0c5, base64 &quo= t;0cNDF"
> - hash of "/6top:CellList/6top:CellID" =3D 0x2a33a8b4
> - hash of "/6top:CellList/6top:SlotframeI" =3D 0xfe4ad55
> - hash of "/6top:CellList/6top:SlotOffset" =3D 0x2515e82f > - hash of "/6top:CellList/6top:ChannelOffset" =3D 0x9c2f821,= base64 "Jwvgh"
> - hash of "/6top:CellList/6top:LinkOption" =3D 0x5057e17
> - hash of "/6top:CellList/6top:LinkType" =3D 0xd2a79e8
> - hash of "/6top:CellList/6top:CellType" =3D 0x26e3537
> - hash of "/6top:CellList/6top:TargetNodeAddress" =3D 0x2efe= a0b3
> - hash of "/6top:CellList/6top:TrackID" =3D 0x1e32edaf
>
> The "/6top:CellList/6top:ChannelOffset" data node can be req= uested as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data/6top:Jwvgh
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A00x9c2f821 : 5
>=C2=A0 =C2=A0}
>
> The content of the "/6top:CellList"=C2=A0 list can be reques= ted as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data/6top:0cNDF
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A00x3470d0c5 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2a33a8b4 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfe4ad55 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2515e82f : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x9c2f821 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x5057e17 : "Transmit,Timekeepin= g",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xd2a79e8 : 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x26e3537 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2efea0b3 : h'0102030000112233&#= 39;,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1e32edaf : 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0}
>
> And the content of the datastore can be requested as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0"6top" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A00x3470d0c5 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2a33a8b4 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfe4ad55 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2515e82f : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x9c2f821 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x5057e17 : "Transmit,Tim= ekeeping",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xd2a79e8 : 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x26e3537 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2efea0b3 : h'01020300001= 12233',
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1e32edaf : 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0"IP-MIB" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A00x30b7bc3f : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1067f289 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00d38564 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2745e222 : "ipv4= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x387804eb : "10.0= .0.51",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1a51514a : "00:0= 0:10:01:23:45",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x03f95578 : "2333= 943",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x24ade115 : "stat= ic",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x09e640ef : "reac= hable",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x3b5c1ab6 : "acti= ve"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00d38564 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2745e222 : "ipv4= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x387804eb : "9.2.= 3.4",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1a51514a : "00:0= 0:10:54:32:10",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x03f95578 : "2329= 836",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x24ade115 : "dyna= mic",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x09e640ef : "unkn= own",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x3b5c1ab6 : "acti= ve"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> Is it a real issue and is it a viable solution?
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veillette@= trilliantinc.com
> www.trillian= tinc.com
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--047d7bd8fecc7b3f420512905ff7-- From nobody Tue Mar 31 04:43:23 2015 Return-Path: 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 B879C1A9023 for ; Tue, 31 Mar 2015 04:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 H6DKZNEbC4JQ for ; Tue, 31 Mar 2015 04:43:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89891A9070 for ; Tue, 31 Mar 2015 04:43:18 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 31 Mar 2015 11:42:58 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0112.000; Tue, 31 Mar 2015 11:42:58 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] COMI hash values globally unique vs. unique within a module Thread-Index: AdBrEhHnZ+lyuo2YQSO6KWYX3e5b0gAQnp2AABRO+JA= Date: Tue, 31 Mar 2015 11:42:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.225.215.88] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB792; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(38414003)(24454002)(2900100001)(46102003)(74316001)(92566002)(76576001)(86362001)(15975445007)(99286002)(66066001)(110136001)(87936001)(77156002)(54356999)(122556002)(50986999)(19580395003)(575784001)(102836002)(15974865002)(77096005)(40100003)(561944003)(2656002)(19580405001)(76176999)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0601MB792; H:CO2PR0601MB792.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR0601MB792; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB792; x-forefront-prvs: 0532BF6DC2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 11:42:58.1428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB792 Archived-At: Cc: "twatteyne@gmail.com" , "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 11:43:21 -0000 SGkgQW5keQ0KDQpUaGUgZ29hbCBvZiB0aGlzIHByb3Bvc2FsIGlzIHRvIGFsbG93IFlBTkcgaGFz aCBkdXBsaWNhdGVzIGJldHdlZW4gbW9kdWxlcy4gVG8gYWNjb21wbGlzaCB0aGlzIGdvYWwsIHRo ZSBtb2R1bGUgbmFtZSBpcyBhZGRlZCB0byB0aGUgVVJJIGFuZCB0byB0aGUgcm9vdCBDQk9SIG9i amVjdCB3aGVuIG11bHRpcGxlIG1vZHVsZSBjb250ZXh0cyBhcmUgYWNjZXNzZWQsIHNlZSBleGFt cGxlcyBiZWxsb3cuDQoNClRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIHdpdGhpbiBhIG1v ZHVsZSBpcyBsb3dlciBhbmQgbW9yZSBpbXBvcnRhbnRseSwgdGhlIHNldCBvZiBjb2xsaXNpb25z IHdpbGwgYmUgdGhlIHNhYW1lIG9uIGFsbCBkZXZpY2VzIGluZGVwZW5kZW50bHkgb2YgdGhlIG51 bWJlciBvZiBtb2R1bGUgaG9zdGVkIGJ5IHRoZXNlIGRldmljZXMuDQoNCkkgYWRkZWQgVGhvbWFz IFdhdHRleW5lIGluIGNjIHdoaWNoIGlzIHBhcnQgb2YgdGhlIDZUaVNDSCBncm91cCBhbmQgYWxz byBjb25jZXJuZWQgYWJvdXQgdGhpcyBpc3N1ZS4gVGhvbWFzLCBkbyB5b3UgaGF2ZSBhbnl0aGlu ZyB0byBhZGQgYWJvdXQgdGhlIHJhdGlvbmFsIG9mIHN1Y2ggbW9kaWZpY2F0aW9uIHRvIENPTUku DQoNCk1pY2hlbCBWZWlsbGV0dGUNClN5c3RlbSBBcmNoaXRlY3R1cmUgRGlyZWN0b3INClRyaWxs aWFudCBJbmMuDQpUZWw6IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KbWljaGVsLnZlaWxsZXR0ZUB0 cmlsbGlhbnRpbmMuY29tDQp3d3cudHJpbGxpYW50aW5jLmNvbSDCoCANCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29y a3MuY29tXSANClNlbnQ6IDMwIG1hcnMgMjAxNSAyMTo0Nw0KVG86IE1pY2hlbCBWZWlsbGV0dGUN CkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIENPTUkgaGFzaCB2YWx1ZXMg Z2xvYmFsbHkgdW5pcXVlIHZzLiB1bmlxdWUgd2l0aGluIGEgbW9kdWxlDQoNCk9uIE1vbiwgTWFy IDMwLCAyMDE1IGF0IDEyOjQzIFBNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRl QHRyaWxsaWFudGluYy5jb20+IHdyb3RlOg0KPiBDdXJyZW50bHksIENvTUkgb2JqZWN0IGlkZW50 aWZpZXJzIChZQU5HIGhhc2gpIGFyZSBnbG9iYWxseSB1bmlxdWUgd2l0aGluIGEgQ29NSSBzZXJ2 ZXIuIERldmljZXMgaW1wbGVtZW50aW5nIGRpZmZlcmVudCBzZXQgb2YgbW9kdWxlcyBtYXkgaGF2 ZSBkaWZmZXJlbnQgWUFORyBoYXNoIGNvbmZsaWN0cyBhbmQgbWF5IGhhdmUgYSBkaWZmZXJlbnQg c2V0IG9mIG9iamVjdCBpZGVudGlmaWVycyBhZmZlY3RlZCBieSByZWhhc2guIEluIGFuIGFwcGxp Y2F0aW9uIGxpa2UgNlRpU0gsIHRoaXMgbWVhbnMgdGhhdCB0aGUgbGlzdCBvZiByZWhhc2ggdmFs dWVzIGNhbid0IGJlIGtub3duIGluIGFkdmFuY2UgYmFzZWQgb24gdGhlIHB1Ymxpc2hlZCBZQU5H IG1vZHVsZSwgcmVoYXNoIHZhbHVlcyBuZWVkIHRvIGJlIGRpc2NvdmVyIGFuZCBtYW5hZ2UgYnkg ZWFjaCBub2RlIGludm9sdmVkIGluIHRoZSB0aW1lc2xvdHMgcmVzZXJ2YXRpb24gcHJvY2Vzcy4N Cj4NCj4gUmVkdWNpbmcgdGhlIHNjb3BlIG9mIHRoZSBZQU5HIGhhc2ggdG8gdGhlIGNvbnRleHQg b2YgYSBzaW5nbGUgbW9kdWxlIChkYXRhIG5vZGVzIGRlZmluZWQgYnkgYSBtb2R1bGUgKyBkYXRh IG5vZGVzIGFkZGVkIHRvIHRoYXQgbW9kdWxlIGJ5IHRoZSBhdWdtZW50IHN0YXRlbWVudCkgY2Fu IG1pdGlnYXRlIHRoaXMgaXNzdWUuIFRoZSBxdWVzdGlvbiBpcyBob3cgdGhpcyBjYW4gYmUgYWNj b21wbGlzaGVkIGFuZCBpZiB0aGUgb3ZlcmhlYWQgcmVxdWlyZWQgbWFrZSB0aGlzIGNoYW5nZSBh Y2NlcHRhYmxlLg0KPg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgd2lsbCB3b3JrLg0KVGhlIHByb2Jh YmlsaXR5IG9mIGNvbGxpc2lvbnMgaXMgdGhlIHNhbWUgd2hldGhlciAxMDAgb2JqZWN0cyBhcmUg ZGVmaW5lZCBpbiAxIG1vZHVsZSBvciAxMCBvYmplY3RzIGFyZSBkZWZpbmVkIGluIGVhY2ggb2Yg MTAgbW9kdWxlcy4NCg0KVGhlIGNsaWVudCBtdXN0IGltcGxlbWVudCB0aGUgcmVoYXNoIGFsZ29y aXRobSBldmVuIHRob3VnaCB0aGVyZSBpcyBhIGxvdyBwcm9iYWJpbGl0eSBpdCB3aWxsIGJlIHVz ZWQuDQoNCg0KQW5keQ0KDQoNCj4gSW1wYWN0cyBvbiB0aGUgVVJJDQo+ID09PT09PT09PT09PT09 PQ0KPiBDdXJyZW50bHksIHRoZSBDb0FQIHBhdGggY29uc2lzdCBvZjoNCj4gICIvbWcvPGhhc2gt dmFsdWU+Ig0KPg0KPiBDb25zaWRlcmluZyB0aGF0IHRoZSBZQU5HIGhhc2ggaXMgdW5pcXVlIG9u bHkgd2l0aGluIHRoZSBjb250ZXh0IG9mIGEgbW9kdWxlLCB0aGUgQ29BUCBwYXRoIG5lZWRzIHRv IGluY2x1ZGUgdGhlIG1vZHVsZSBuYW1lOg0KPiAiL21nL2RhdGEiIG9yDQo+ICAiL21nL2RhdGEv PG1vZHVsZU5hbWU+OiA8aGFzaC12YWx1ZT4iDQo+DQo+IEltcGFjdHMgb24gdGhlIENCT1IgY29u dGVudA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT0NCj4gSWYgdGhlIENvQVAgcGF0aCB0YXJn ZXQgYSBzcGVjaWZpYyBtb2R1bGUgKGUuZy4gIi9tZy9kYXRhLzxtb2R1bGVOYW1lPjogPGhhc2gt dmFsdWU+IiksIHRoZSBjdXJyZW50IENCT1IgZW5jb2RpbmcgcnVsZXMgc2hvdWxkIGFwcGx5IHVu bW9kaWZpZWQuDQo+DQo+IElmIHRoZSBDb0FQIHBhdGggdGFyZ2V0IG11bHRpcGxlIG1vZHVsZXMg KGUuZy4gIi9tZy9kYXRhIiksIENvTUkgb2JqZWN0cyBuZWVkIHRvIGJlIGFzc29jaWF0ZWQgdG8g dGhlaXIgcmVzcGVjdGl2ZSBtb2R1bGUgY29udGV4dC4gQSBDQk9SIG1hcCBhZGRlZCB0byB0aGUg cm9vdCBvZiB0aGUgQ0JPUiBvYmplY3QgY2FuIGJlIHVzZWQgdG8gZXN0YWJsaXNoIHRoaXMgcmVs YXRpb25zaGlwLg0KPg0KPiBGb3IgZXhhbXBsZQ0KPiA9PT09PT09PT09DQo+IEFzc3VtaW5nOg0K PiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0IiA9ICAweDM0NzBkMGM1LCBiYXNlNjQgIjBjTkRG Ig0KPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6Q2VsbElEIiA9IDB4MmEzM2E4YjQN Cj4gLSBoYXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9wOlNsb3RmcmFtZUkiID0gMHhmZTRhZDU1 DQo+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpTbG90T2Zmc2V0IiA9IDB4MjUxNWU4 MmYNCj4gLSBoYXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9wOkNoYW5uZWxPZmZzZXQiID0gMHg5 YzJmODIxLCBiYXNlNjQgIkp3dmdoIg0KPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6 TGlua09wdGlvbiIgPSAweDUwNTdlMTcNCj4gLSBoYXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9w OkxpbmtUeXBlIiA9IDB4ZDJhNzllOA0KPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6 Q2VsbFR5cGUiID0gMHgyNmUzNTM3DQo+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpU YXJnZXROb2RlQWRkcmVzcyIgPSAweDJlZmVhMGIzDQo+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExp c3QvNnRvcDpUcmFja0lEIiA9IDB4MWUzMmVkYWYNCj4NCj4gVGhlICIvNnRvcDpDZWxsTGlzdC82 dG9wOkNoYW5uZWxPZmZzZXQiIGRhdGEgbm9kZSBjYW4gYmUgcmVxdWVzdGVkIGFzIGZvbGxvdzoN Cj4NCj4gICBSRVE6IEdFVCBleGFtcGxlLmNvbS9tZy9kYXRhLzZ0b3A6Snd2Z2gNCj4NCj4gICBS RVM6IDIuMDUgQ29udGVudCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9uL2Nib3IpDQo+ICAg ew0KPiAgICAgMHg5YzJmODIxIDogNQ0KPiAgIH0NCj4NCj4gVGhlIGNvbnRlbnQgb2YgdGhlICIv NnRvcDpDZWxsTGlzdCIgIGxpc3QgY2FuIGJlIHJlcXVlc3RlZCBhcyBmb2xsb3c6DQo+DQo+ICAg UkVROiBHRVQgZXhhbXBsZS5jb20vbWcvZGF0YS82dG9wOjBjTkRGDQo+DQo+ICAgUkVTOiAyLjA1 IENvbnRlbnQgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNhdGlvbi9jYm9yKQ0KPiAgIHsNCj4gICAg IDB4MzQ3MGQwYzUgOiBbDQo+ICAgICAgIHsNCj4gICAgICAgICAweDJhMzNhOGI0IDogMSwNCj4g ICAgICAgICAweGZlNGFkNTUgOiAxLA0KPiAgICAgICAgIDB4MjUxNWU4MmYgOiAxLA0KPiAgICAg ICAgIDB4OWMyZjgyMSA6IDEsDQo+ICAgICAgICAgMHg1MDU3ZTE3IDogIlRyYW5zbWl0LFRpbWVr ZWVwaW5nIiwNCj4gICAgICAgICAweGQyYTc5ZTggOiAwLA0KPiAgICAgICAgIDB4MjZlMzUzNyA6 IDEsDQo+ICAgICAgICAgMHgyZWZlYTBiMyA6IGgnMDEwMjAzMDAwMDExMjIzMycsDQo+ICAgICAg ICAgMHgxZTMyZWRhZiA6IDENCj4gICAgICAgfQ0KPiAgICAgXQ0KPiAgIH0NCj4NCj4gQW5kIHRo ZSBjb250ZW50IG9mIHRoZSBkYXRhc3RvcmUgY2FuIGJlIHJlcXVlc3RlZCBhcyBmb2xsb3c6DQo+ DQo+ICAgUkVROiBHRVQgZXhhbXBsZS5jb20vbWcvZGF0YQ0KPg0KPiAgIFJFUzogMi4wNSBDb250 ZW50IChDb250ZW50LUZvcm1hdDogYXBwbGljYXRpb24vY2JvcikNCj4gICB7DQo+ICAgICAiNnRv cCIgOiB7DQo+ICAgICAgIDB4MzQ3MGQwYzUgOiBbDQo+ICAgICAgICAgew0KPiAgICAgICAgICAg MHgyYTMzYThiNCA6IDEsDQo+ICAgICAgICAgICAweGZlNGFkNTUgOiAxLA0KPiAgICAgICAgICAg MHgyNTE1ZTgyZiA6IDEsDQo+ICAgICAgICAgICAweDljMmY4MjEgOiAxLA0KPiAgICAgICAgICAg MHg1MDU3ZTE3IDogIlRyYW5zbWl0LFRpbWVrZWVwaW5nIiwNCj4gICAgICAgICAgIDB4ZDJhNzll OCA6IDAsDQo+ICAgICAgICAgICAweDI2ZTM1MzcgOiAxLA0KPiAgICAgICAgICAgMHgyZWZlYTBi MyA6IGgnMDEwMjAzMDAwMDExMjIzMycsDQo+ICAgICAgICAgICAweDFlMzJlZGFmIDogMQ0KPiAg ICAgICAgIH0NCj4gICAgICAgXQ0KPiAgICAgfSwNCj4gICAgICJJUC1NSUIiIDogew0KPiAgICAg ICAweDMwYjdiYzNmIDogew0KPiAgICAgICAgIDB4MTA2N2YyODkgOiBbDQo+ICAgICAgICAgICB7 DQo+ICAgICAgICAgICAgIDB4MDBkMzg1NjQgOiAxLA0KPiAgICAgICAgICAgICAweDI3NDVlMjIy IDogImlwdjQiLA0KPiAgICAgICAgICAgICAweDM4NzgwNGViIDogIjEwLjAuMC41MSIsDQo+ICAg ICAgICAgICAgIDB4MWE1MTUxNGEgOiAiMDA6MDA6MTA6MDE6MjM6NDUiLA0KPiAgICAgICAgICAg ICAweDAzZjk1NTc4IDogIjIzMzM5NDMiLA0KPiAgICAgICAgICAgICAweDI0YWRlMTE1IDogInN0 YXRpYyIsDQo+ICAgICAgICAgICAgIDB4MDllNjQwZWYgOiAicmVhY2hhYmxlIiwNCj4gICAgICAg ICAgICAgMHgzYjVjMWFiNiA6ICJhY3RpdmUiDQo+ICAgICAgICAgICB9LA0KPiAgICAgICAgICAg ew0KPiAgICAgICAgICAgICAweDAwZDM4NTY0IDogMSwNCj4gICAgICAgICAgICAgMHgyNzQ1ZTIy MiA6ICJpcHY0IiwNCj4gICAgICAgICAgICAgMHgzODc4MDRlYiA6ICI5LjIuMy40IiwNCj4gICAg ICAgICAgICAgMHgxYTUxNTE0YSA6ICIwMDowMDoxMDo1NDozMjoxMCIsDQo+ICAgICAgICAgICAg IDB4MDNmOTU1NzggOiAiMjMyOTgzNiIsDQo+ICAgICAgICAgICAgIDB4MjRhZGUxMTUgOiAiZHlu YW1pYyIsDQo+ICAgICAgICAgICAgIDB4MDllNjQwZWYgOiAidW5rbm93biIsDQo+ICAgICAgICAg ICAgIDB4M2I1YzFhYjYgOiAiYWN0aXZlIg0KPiAgICAgICAgICAgfQ0KPiAgICAgICAgIF0NCj4g ICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4NCj4gSXMgaXQgYSByZWFsIGlzc3VlIGFuZCBpcyBp dCBhIHZpYWJsZSBzb2x1dGlvbj8NCj4NCj4gTWljaGVsIFZlaWxsZXR0ZQ0KPiBTeXN0ZW0gQXJj aGl0ZWN0dXJlIERpcmVjdG9yDQo+IFRyaWxsaWFudCBJbmMuDQo+IFRlbDogNDUwLTM3NS0wNTU2 IGV4dC4gMjM3DQo+IG1pY2hlbC52ZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbQ0KPiB3d3cudHJp bGxpYW50aW5jLmNvbQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Tue Mar 31 04:51:44 2015 Return-Path: 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 301A71A9111; Tue, 31 Mar 2015 04:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 x6FKWMH1OKSF; Tue, 31 Mar 2015 04:51:34 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2BC1A9114; Tue, 31 Mar 2015 04:51:34 -0700 (PDT) Received: by patj18 with SMTP id j18so17597794pat.2; Tue, 31 Mar 2015 04:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zz82/aCeFE4QXYI4HonAB793pHAFl7cUc226zpacxs0=; b=kxRal7ZGIaV4XmQU3VStf3GGpLJI29YAkvPI1aUgHZIFR3hxF1ciJc6oXfrVVRN6qQ yBLouPNAs2Xm1GUxc1ZeJBvzQITz81ImWoNvSAWV88vqqWRsec4UUPdDO2pOliDaDpCd MkQRcI+yb2snKvwoUPm1k23gqIK1lPt1cUT4wf/ieqCcrKZL1eWozS648Olmp1EQSaWv wT4Bx0xDZMWGScRYlkJ8YEaS1Hihmb+P3nDZIXRNGTZ6IRkD3KagJwNXzxQoXL8b19AY 7hi5EMt1/XGEs63KLSN7DbptQ0Ocxq7YImPnuJUtXCZLCALslQJFSG4PGnqcZxUBm4/r Hehg== X-Received: by 10.70.53.40 with SMTP id y8mr67967954pdo.61.1427802693934; Tue, 31 Mar 2015 04:51:33 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.76.100 with HTTP; Tue, 31 Mar 2015 04:51:13 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 31 Mar 2015 13:51:13 +0200 X-Google-Sender-Auth: lCRW121xbtHiZtrhsvHBB2g_mzM Message-ID: To: Michel Veillette Content-Type: multipart/alternative; boundary=001a11343a7a61a4300512943864 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 11:51:37 -0000 --001a11343a7a61a4300512943864 Content-Type: text/plain; charset=UTF-8 Michel, +1 on all, which echoes the e-mail I sent to the 6TISCH and CoRE MLs this morning. On Tue, Mar 31, 2015 at 1:42 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > The goal of this proposal is to allow YANG hash duplicates between > modules. To accomplish this goal, the module name is added to the URI and > to the root CBOR object when multiple module contexts are accessed, see > examples bellow. > > The probability of collisions within a module is lower and more > importantly, the set of collisions will be the saame on all devices > independently of the number of module hosted by these devices. > > I added Thomas Watteyne in cc which is part of the 6TiSCH group and also > concerned about this issue. Thomas, do you have anything to add about the > rational of such modification to COMI. > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: 30 mars 2015 21:47 > To: Michel Veillette > Cc: core@ietf.org > Subject: Re: [core] COMI hash values globally unique vs. unique within a > module > > On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > Currently, CoMI object identifiers (YANG hash) are globally unique > within a CoMI server. Devices implementing different set of modules may > have different YANG hash conflicts and may have a different set of object > identifiers affected by rehash. In an application like 6TiSH, this means > that the list of rehash values can't be known in advance based on the > published YANG module, rehash values need to be discover and manage by each > node involved in the timeslots reservation process. > > > > Reducing the scope of the YANG hash to the context of a single module > (data nodes defined by a module + data nodes added to that module by the > augment statement) can mitigate this issue. The question is how this can be > accomplished and if the overhead required make this change acceptable. > > > > I don't think this will work. > The probability of collisions is the same whether 100 objects are defined > in 1 module or 10 objects are defined in each of 10 modules. > > The client must implement the rehash algorithm even though there is a low > probability it will be used. > > > Andy > > > > Impacts on the URI > > =============== > > Currently, the CoAP path consist of: > > "/mg/" > > > > Considering that the YANG hash is unique only within the context of a > module, the CoAP path needs to include the module name: > > "/mg/data" or > > "/mg/data/: " > > > > Impacts on the CBOR content > > ======================== > > If the CoAP path target a specific module (e.g. "/mg/data/: > "), the current CBOR encoding rules should apply unmodified. > > > > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI objects > need to be associated to their respective module context. A CBOR map added > to the root of the CBOR object can be used to establish this relationship. > > > > For example > > ========== > > Assuming: > > - hash of "/6top:CellList" = 0x3470d0c5, base64 "0cNDF" > > - hash of "/6top:CellList/6top:CellID" = 0x2a33a8b4 > > - hash of "/6top:CellList/6top:SlotframeI" = 0xfe4ad55 > > - hash of "/6top:CellList/6top:SlotOffset" = 0x2515e82f > > - hash of "/6top:CellList/6top:ChannelOffset" = 0x9c2f821, base64 "Jwvgh" > > - hash of "/6top:CellList/6top:LinkOption" = 0x5057e17 > > - hash of "/6top:CellList/6top:LinkType" = 0xd2a79e8 > > - hash of "/6top:CellList/6top:CellType" = 0x26e3537 > > - hash of "/6top:CellList/6top:TargetNodeAddress" = 0x2efea0b3 > > - hash of "/6top:CellList/6top:TrackID" = 0x1e32edaf > > > > The "/6top:CellList/6top:ChannelOffset" data node can be requested as > follow: > > > > REQ: GET example.com/mg/data/6top:Jwvgh > > > > RES: 2.05 Content (Content-Format: application/cbor) > > { > > 0x9c2f821 : 5 > > } > > > > The content of the "/6top:CellList" list can be requested as follow: > > > > REQ: GET example.com/mg/data/6top:0cNDF > > > > RES: 2.05 Content (Content-Format: application/cbor) > > { > > 0x3470d0c5 : [ > > { > > 0x2a33a8b4 : 1, > > 0xfe4ad55 : 1, > > 0x2515e82f : 1, > > 0x9c2f821 : 1, > > 0x5057e17 : "Transmit,Timekeeping", > > 0xd2a79e8 : 0, > > 0x26e3537 : 1, > > 0x2efea0b3 : h'0102030000112233', > > 0x1e32edaf : 1 > > } > > ] > > } > > > > And the content of the datastore can be requested as follow: > > > > REQ: GET example.com/mg/data > > > > RES: 2.05 Content (Content-Format: application/cbor) > > { > > "6top" : { > > 0x3470d0c5 : [ > > { > > 0x2a33a8b4 : 1, > > 0xfe4ad55 : 1, > > 0x2515e82f : 1, > > 0x9c2f821 : 1, > > 0x5057e17 : "Transmit,Timekeeping", > > 0xd2a79e8 : 0, > > 0x26e3537 : 1, > > 0x2efea0b3 : h'0102030000112233', > > 0x1e32edaf : 1 > > } > > ] > > }, > > "IP-MIB" : { > > 0x30b7bc3f : { > > 0x1067f289 : [ > > { > > 0x00d38564 : 1, > > 0x2745e222 : "ipv4", > > 0x387804eb : "10.0.0.51", > > 0x1a51514a : "00:00:10:01:23:45", > > 0x03f95578 : "2333943", > > 0x24ade115 : "static", > > 0x09e640ef : "reachable", > > 0x3b5c1ab6 : "active" > > }, > > { > > 0x00d38564 : 1, > > 0x2745e222 : "ipv4", > > 0x387804eb : "9.2.3.4", > > 0x1a51514a : "00:00:10:54:32:10", > > 0x03f95578 : "2329836", > > 0x24ade115 : "dynamic", > > 0x09e640ef : "unknown", > > 0x3b5c1ab6 : "active" > > } > > ] > > } > > } > > } > > > > Is it a real issue and is it a viable solution? > > > > Michel Veillette > > System Architecture Director > > Trilliant Inc. > > Tel: 450-375-0556 ext. 237 > > michel.veillette@trilliantinc.com > > www.trilliantinc.com > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > --001a11343a7a61a4300512943864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Michel,

+1 on all, which echoes the e-m= ail I sent to the 6TISCH and CoRE MLs this morning.

On Tue, Mar 31, 2015 at 1:4= 2 PM, Michel Veillette <Michel.Veillette@trilliantinc.com<= /a>> wrote:

Hi Andy

The goal of this proposal is to allow YANG hash duplicates between modules.= To accomplish this goal, the module name is added to the URI and to the ro= ot CBOR object when multiple module contexts are accessed, see examples bel= low.

The probability of collisions within a module is lower and more importantly= , the set of collisions will be the saame on all devices independently of t= he number of module hosted by these devices.

I added Thomas Watteyne in cc which is part of the 6TiSCH group and also co= ncerned about this issue. Thomas, do you have anything to add about the rat= ional of such modification to COMI.

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-3= 75-0556 ext. 237
michel.veillette@trill= iantinc.com
www.trilliantinc.= com =C2=A0

-----Original Message----- From: Andy Bierman [mailto:andy@yumaw= orks.com]
Sent: 30 mars 2015 21:47
To: Michel Veillette
Cc: core@ietf.org
Subject: Re: [core] COMI hash values globally unique vs. unique within a mo= dule

On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette <Michel.Veillette@trilliantinc.com> = wrote:
> Currently, CoMI object identifiers (YANG hash) are globally unique wit= hin a CoMI server. Devices implementing different set of modules may have d= ifferent YANG hash conflicts and may have a different set of object identif= iers affected by rehash. In an application like 6TiSH, this means that the = list of rehash values can't be known in advance based on the published = YANG module, rehash values need to be discover and manage by each node invo= lved in the timeslots reservation process.
>
> Reducing the scope of the YANG hash to the context of a single module = (data nodes defined by a module + data nodes added to that module by the au= gment statement) can mitigate this issue. The question is how this can be a= ccomplished and if the overhead required make this change acceptable.
>

I don't think this will work.
The probability of collisions is the same whether 100 objects are defined i= n 1 module or 10 objects are defined in each of 10 modules.

The client must implement the rehash algorithm even though there is a low p= robability it will be used.

Andy

> Impacts on the URI
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Currently, the CoAP path consist of:
>=C2=A0 "/mg/<hash-value>"
>
> Considering that the YANG hash is unique only within the context of a = module, the CoAP path needs to include the module name:
> "/mg/data" or
>=C2=A0 "/mg/data/<moduleName>: <hash-value>"
>
> Impacts on the CBOR content
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> If the CoAP path target a specific module (e.g. "/mg/data/<mod= uleName>: <hash-value>"), the current CBOR encoding rules sho= uld apply unmodified.
>
> If the CoAP path target multiple modules (e.g. "/mg/data"), = CoMI objects need to be associated to their respective module context. A CB= OR map added to the root of the CBOR object can be used to establish this r= elationship.
>
> For example
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Assuming:
> - hash of "/6top:CellList" =3D=C2=A0 0x3470d0c5, base64 &quo= t;0cNDF"
> - hash of "/6top:CellList/6top:CellID" =3D 0x2a33a8b4
> - hash of "/6top:CellList/6top:SlotframeI" =3D 0xfe4ad55
> - hash of "/6top:CellList/6top:SlotOffset" =3D 0x2515e82f > - hash of "/6top:CellList/6top:ChannelOffset" =3D 0x9c2f821,= base64 "Jwvgh"
> - hash of "/6top:CellList/6top:LinkOption" =3D 0x5057e17
> - hash of "/6top:CellList/6top:LinkType" =3D 0xd2a79e8
> - hash of "/6top:CellList/6top:CellType" =3D 0x26e3537
> - hash of "/6top:CellList/6top:TargetNodeAddress" =3D 0x2efe= a0b3
> - hash of "/6top:CellList/6top:TrackID" =3D 0x1e32edaf
>
> The "/6top:CellList/6top:ChannelOffset" data node can be req= uested as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data/6top:Jwvgh
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A00x9c2f821 : 5
>=C2=A0 =C2=A0}
>
> The content of the "/6top:CellList"=C2=A0 list can be reques= ted as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data/6top:0cNDF
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A00x3470d0c5 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2a33a8b4 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfe4ad55 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2515e82f : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x9c2f821 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x5057e17 : "Transmit,Timekeepin= g",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xd2a79e8 : 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x26e3537 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2efea0b3 : h'0102030000112233&#= 39;,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1e32edaf : 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0}
>
> And the content of the datastore can be requested as follow:
>
>=C2=A0 =C2=A0REQ: GET example.com/mg/data
>
>=C2=A0 =C2=A0RES: 2.05 Content (Content-Format: application/cbor)
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0"6top" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A00x3470d0c5 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2a33a8b4 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xfe4ad55 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2515e82f : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x9c2f821 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x5057e17 : "Transmit,Tim= ekeeping",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xd2a79e8 : 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x26e3537 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2efea0b3 : h'01020300001= 12233',
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1e32edaf : 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0"IP-MIB" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A00x30b7bc3f : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1067f289 : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00d38564 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2745e222 : "ipv4= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x387804eb : "10.0= .0.51",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1a51514a : "00:0= 0:10:01:23:45",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x03f95578 : "2333= 943",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x24ade115 : "stat= ic",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x09e640ef : "reac= hable",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x3b5c1ab6 : "acti= ve"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00d38564 : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x2745e222 : "ipv4= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x387804eb : "9.2.= 3.4",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1a51514a : "00:0= 0:10:54:32:10",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x03f95578 : "2329= 836",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x24ade115 : "dyna= mic",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x09e640ef : "unkn= own",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x3b5c1ab6 : "acti= ve"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> Is it a real issue and is it a viable solution?
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veillette@= trilliantinc.com
> www.trillian= tinc.com
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--001a11343a7a61a4300512943864-- From nobody Tue Mar 31 06:30:13 2015 Return-Path: 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 5E54B1ACD22 for ; Tue, 31 Mar 2015 06:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 HSuN36Gc3et6 for ; Tue, 31 Mar 2015 06:30:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3191ACD33 for ; Tue, 31 Mar 2015 06:30:08 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so12360012lbb.3 for ; Tue, 31 Mar 2015 06:30:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jFriz+Zv4TTD5J0EBOL9iO3HiTEH427lwf6lTus0020=; b=kGnwt7ZGOCemWPZE9JsgzAoxbwLx9wijKl+BCFf4umJkczji18vOZnQ1wUo4PtNoyL Zw5W2y/KxOsvoUbfrlYIJZrcrFLVISdckdwGDWQKJh3GX6tZTcuvKZw0awaEktF7XE7e 92AzUWmkvqHftFdVVJxe/G4fG6XxY9Yc/Q/8QZJ023G6Hhpg11peH+orOeXrS+RTJfrF C4AdePTghc0eZkoyV9qDQWw45s/k8XFRIHUmsCGZnixMPX2zJkVngc4oGAMD7JotZvNO Q1TVZpe04nm2DI84T4jH+OcIYuC0XtTGnrlM5YqsoyLNug8A2dojjt8NfofOoARhG+/G FQ1g== X-Gm-Message-State: ALoCoQmhlc0Lcjr1Y3eAtFw7ZycEfQwDL2B1NOEQ8liO2Xrut4o6z0ySP+rN/OFcjpPF9vg+NRwq MIME-Version: 1.0 X-Received: by 10.152.244.161 with SMTP id xh1mr30506803lac.119.1427808607139; Tue, 31 Mar 2015 06:30:07 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Tue, 31 Mar 2015 06:30:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Mar 2015 06:30:07 -0700 Message-ID: From: Andy Bierman To: Thomas Watteyne Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 13:30:11 -0000 On Tue, Mar 31, 2015 at 12:15 AM, Thomas Watteyne wrote: > [adding 6TiSCH] > > Andy, > > I believe the issue Michel highlights is that the hash collisions depends on > the modules that are implemented in the CoMI endpoint. > But hash collisions can occur within a module or across modules. Allowing collisions across modules does not change the probability of a collision. It does not remove the need to check for a collision. What problem are you trying to solve? If it is to remove the possibility of a collision ever occurring then keep trying. Why is it better to change the scope of the object hash to be per module name? The goal of the YANG hash is to lower the identifier size to a 4 byte number. Adding the 10 - 20 byte module name to every identifier really doesn't help lower the identifier size at all. Andy > That is, if nodeA implements the [/6t,/foo] modules, and nodeB the > [/6t,/bar] modules, the hash collisions can be different, even in the same > "6t" module. In the case of 6top, the YANG model describes the module > completely. It would be awfully nice to be able to just rely on that YANG > model to predict the hash collisions within that module.without having to > discover the rehash-map on a server each time. > > IIRC, today, a client accessing any resource using CoMI needs to first > retrieve the hash-map? The client needs to do this for each node is manages, > potentially periodically if new modules are added on-the-fly? This seems > like a lot of uncessary overhead. > > One way could be fr the server to return some error code when the client > accesses a resource with a hash that is ambiguous. > > Your insight on this is very welcome. > > Thomas > > On Tue, Mar 31, 2015 at 3:46 AM, Andy Bierman wrote: >> >> On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette >> wrote: >> > Currently, CoMI object identifiers (YANG hash) are globally unique >> > within a CoMI server. Devices implementing different set of modules may have >> > different YANG hash conflicts and may have a different set of object >> > identifiers affected by rehash. In an application like 6TiSH, this means >> > that the list of rehash values can't be known in advance based on the >> > published YANG module, rehash values need to be discover and manage by each >> > node involved in the timeslots reservation process. >> > >> > Reducing the scope of the YANG hash to the context of a single module >> > (data nodes defined by a module + data nodes added to that module by the >> > augment statement) can mitigate this issue. The question is how this can be >> > accomplished and if the overhead required make this change acceptable. >> > >> >> I don't think this will work. >> The probability of collisions is the same whether 100 objects >> are defined in 1 module or 10 objects are defined in each of 10 modules. >> >> The client must implement the rehash algorithm even though there is >> a low probability it will be used. >> >> >> Andy >> >> >> > Impacts on the URI >> > =============== >> > Currently, the CoAP path consist of: >> > "/mg/" >> > >> > Considering that the YANG hash is unique only within the context of a >> > module, the CoAP path needs to include the module name: >> > "/mg/data" or >> > "/mg/data/: " >> > >> > Impacts on the CBOR content >> > ======================== >> > If the CoAP path target a specific module (e.g. "/mg/data/: >> > "), the current CBOR encoding rules should apply unmodified. >> > >> > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI objects >> > need to be associated to their respective module context. A CBOR map added >> > to the root of the CBOR object can be used to establish this relationship. >> > >> > For example >> > ========== >> > Assuming: >> > - hash of "/6top:CellList" = 0x3470d0c5, base64 "0cNDF" >> > - hash of "/6top:CellList/6top:CellID" = 0x2a33a8b4 >> > - hash of "/6top:CellList/6top:SlotframeI" = 0xfe4ad55 >> > - hash of "/6top:CellList/6top:SlotOffset" = 0x2515e82f >> > - hash of "/6top:CellList/6top:ChannelOffset" = 0x9c2f821, base64 >> > "Jwvgh" >> > - hash of "/6top:CellList/6top:LinkOption" = 0x5057e17 >> > - hash of "/6top:CellList/6top:LinkType" = 0xd2a79e8 >> > - hash of "/6top:CellList/6top:CellType" = 0x26e3537 >> > - hash of "/6top:CellList/6top:TargetNodeAddress" = 0x2efea0b3 >> > - hash of "/6top:CellList/6top:TrackID" = 0x1e32edaf >> > >> > The "/6top:CellList/6top:ChannelOffset" data node can be requested as >> > follow: >> > >> > REQ: GET example.com/mg/data/6top:Jwvgh >> > >> > RES: 2.05 Content (Content-Format: application/cbor) >> > { >> > 0x9c2f821 : 5 >> > } >> > >> > The content of the "/6top:CellList" list can be requested as follow: >> > >> > REQ: GET example.com/mg/data/6top:0cNDF >> > >> > RES: 2.05 Content (Content-Format: application/cbor) >> > { >> > 0x3470d0c5 : [ >> > { >> > 0x2a33a8b4 : 1, >> > 0xfe4ad55 : 1, >> > 0x2515e82f : 1, >> > 0x9c2f821 : 1, >> > 0x5057e17 : "Transmit,Timekeeping", >> > 0xd2a79e8 : 0, >> > 0x26e3537 : 1, >> > 0x2efea0b3 : h'0102030000112233', >> > 0x1e32edaf : 1 >> > } >> > ] >> > } >> > >> > And the content of the datastore can be requested as follow: >> > >> > REQ: GET example.com/mg/data >> > >> > RES: 2.05 Content (Content-Format: application/cbor) >> > { >> > "6top" : { >> > 0x3470d0c5 : [ >> > { >> > 0x2a33a8b4 : 1, >> > 0xfe4ad55 : 1, >> > 0x2515e82f : 1, >> > 0x9c2f821 : 1, >> > 0x5057e17 : "Transmit,Timekeeping", >> > 0xd2a79e8 : 0, >> > 0x26e3537 : 1, >> > 0x2efea0b3 : h'0102030000112233', >> > 0x1e32edaf : 1 >> > } >> > ] >> > }, >> > "IP-MIB" : { >> > 0x30b7bc3f : { >> > 0x1067f289 : [ >> > { >> > 0x00d38564 : 1, >> > 0x2745e222 : "ipv4", >> > 0x387804eb : "10.0.0.51", >> > 0x1a51514a : "00:00:10:01:23:45", >> > 0x03f95578 : "2333943", >> > 0x24ade115 : "static", >> > 0x09e640ef : "reachable", >> > 0x3b5c1ab6 : "active" >> > }, >> > { >> > 0x00d38564 : 1, >> > 0x2745e222 : "ipv4", >> > 0x387804eb : "9.2.3.4", >> > 0x1a51514a : "00:00:10:54:32:10", >> > 0x03f95578 : "2329836", >> > 0x24ade115 : "dynamic", >> > 0x09e640ef : "unknown", >> > 0x3b5c1ab6 : "active" >> > } >> > ] >> > } >> > } >> > } >> > >> > Is it a real issue and is it a viable solution? >> > >> > Michel Veillette >> > System Architecture Director >> > Trilliant Inc. >> > Tel: 450-375-0556 ext. 237 >> > michel.veillette@trilliantinc.com >> > www.trilliantinc.com >> > >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Mar 31 07:50:51 2015 Return-Path: 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 5F9A11ACDC9; Tue, 31 Mar 2015 07:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b-iMjKPpziVX; Tue, 31 Mar 2015 07:50:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF0C1ACDC7; Tue, 31 Mar 2015 07:50:45 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 31 Mar 2015 14:50:40 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0112.000; Tue, 31 Mar 2015 14:50:40 +0000 From: Michel Veillette To: Andy Bierman , Thomas Watteyne Thread-Topic: [core] COMI hash values globally unique vs. unique within a module Thread-Index: AQHQa7bWrHUbJLeAg02uMwJInuX94502rFeA Date: Tue, 31 Mar 2015 14:50:39 +0000 Message-ID: References:

Message-ID: <21a88170b362636293589de2dd6e240a@xs4all.nl> X-Sender: stokcons@xs4all.nl (3D2doVLqzsOf/oieINGWbpDz7V9d7L1v) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch@ietf.org, core@ietf.org Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 14:50:57 -0000 X-List-Received-Date: Tue, 31 Mar 2015 14:50:57 -0000 Thomas, I agree with Andy, that adding the module name means going back to square one; i.e having long identifiers that we want to remove. The rehash may occur at loading time and does not change as long as modules are not reloaded. Consequently, each client can learn the rehash values at start-up and use them without rechecking all the time. OR, do you expect constant changes to the module configurations in the servers? Is your problem that for the same identifier in two different servers the rehash may be different; and you need to maintain lists per server? Anyway, at a central server one can simulate the loading in a given server and see if there is a collision. Using the same algorithm as on the server, the central server can already provide all the rehash values for all servers to the clients. Peter Andy Bierman schreef op 2015-03-31 15:30: > On Tue, Mar 31, 2015 at 12:15 AM, Thomas Watteyne > wrote: >> [adding 6TiSCH] >> >> Andy, >> >> I believe the issue Michel highlights is that the hash collisions >> depends on >> the modules that are implemented in the CoMI endpoint. >> > > But hash collisions can occur within a module or across modules. > Allowing collisions across modules does not change the probability > of a collision. It does not remove the need to check for a collision. > > What problem are you trying to solve? > If it is to remove the possibility of a collision ever occurring > then keep trying. Why is it better to change the scope > of the object hash to be per module name? > > The goal of the YANG hash is to lower the identifier size to > a 4 byte number. Adding the 10 - 20 byte module name to > every identifier really doesn't help lower the identifier size > at all. > > > Andy > > > >> That is, if nodeA implements the [/6t,/foo] modules, and nodeB the >> [/6t,/bar] modules, the hash collisions can be different, even in the >> same >> "6t" module. In the case of 6top, the YANG model describes the module >> completely. It would be awfully nice to be able to just rely on that >> YANG >> model to predict the hash collisions within that module.without having >> to >> discover the rehash-map on a server each time. >> >> IIRC, today, a client accessing any resource using CoMI needs to first >> retrieve the hash-map? The client needs to do this for each node is >> manages, >> potentially periodically if new modules are added on-the-fly? This >> seems >> like a lot of uncessary overhead. >> >> One way could be fr the server to return some error code when the >> client >> accesses a resource with a hash that is ambiguous. >> >> Your insight on this is very welcome. >> >> Thomas >> >> On Tue, Mar 31, 2015 at 3:46 AM, Andy Bierman >> wrote: >>> >>> On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette >>> wrote: >>> > Currently, CoMI object identifiers (YANG hash) are globally unique >>> > within a CoMI server. Devices implementing different set of modules may have >>> > different YANG hash conflicts and may have a different set of object >>> > identifiers affected by rehash. In an application like 6TiSH, this means >>> > that the list of rehash values can't be known in advance based on the >>> > published YANG module, rehash values need to be discover and manage by each >>> > node involved in the timeslots reservation process. >>> > >>> > Reducing the scope of the YANG hash to the context of a single module >>> > (data nodes defined by a module + data nodes added to that module by the >>> > augment statement) can mitigate this issue. The question is how this can be >>> > accomplished and if the overhead required make this change acceptable. >>> > >>> >>> I don't think this will work. >>> The probability of collisions is the same whether 100 objects >>> are defined in 1 module or 10 objects are defined in each of 10 >>> modules. >>> >>> The client must implement the rehash algorithm even though there is >>> a low probability it will be used. >>> >>> >>> Andy >>> >>> >>> > Impacts on the URI >>> > =============== >>> > Currently, the CoAP path consist of: >>> > "/mg/" >>> > >>> > Considering that the YANG hash is unique only within the context of a >>> > module, the CoAP path needs to include the module name: >>> > "/mg/data" or >>> > "/mg/data/: " >>> > >>> > Impacts on the CBOR content >>> > ======================== >>> > If the CoAP path target a specific module (e.g. "/mg/data/: >>> > "), the current CBOR encoding rules should apply unmodified. >>> > >>> > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI objects >>> > need to be associated to their respective module context. A CBOR map added >>> > to the root of the CBOR object can be used to establish this relationship. >>> > >>> > For example >>> > ========== >>> > Assuming: >>> > - hash of "/6top:CellList" = 0x3470d0c5, base64 "0cNDF" >>> > - hash of "/6top:CellList/6top:CellID" = 0x2a33a8b4 >>> > - hash of "/6top:CellList/6top:SlotframeI" = 0xfe4ad55 >>> > - hash of "/6top:CellList/6top:SlotOffset" = 0x2515e82f >>> > - hash of "/6top:CellList/6top:ChannelOffset" = 0x9c2f821, base64 >>> > "Jwvgh" >>> > - hash of "/6top:CellList/6top:LinkOption" = 0x5057e17 >>> > - hash of "/6top:CellList/6top:LinkType" = 0xd2a79e8 >>> > - hash of "/6top:CellList/6top:CellType" = 0x26e3537 >>> > - hash of "/6top:CellList/6top:TargetNodeAddress" = 0x2efea0b3 >>> > - hash of "/6top:CellList/6top:TrackID" = 0x1e32edaf >>> > >>> > The "/6top:CellList/6top:ChannelOffset" data node can be requested as >>> > follow: >>> > >>> > REQ: GET example.com/mg/data/6top:Jwvgh >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > 0x9c2f821 : 5 >>> > } >>> > >>> > The content of the "/6top:CellList" list can be requested as follow: >>> > >>> > REQ: GET example.com/mg/data/6top:0cNDF >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > 0x3470d0c5 : [ >>> > { >>> > 0x2a33a8b4 : 1, >>> > 0xfe4ad55 : 1, >>> > 0x2515e82f : 1, >>> > 0x9c2f821 : 1, >>> > 0x5057e17 : "Transmit,Timekeeping", >>> > 0xd2a79e8 : 0, >>> > 0x26e3537 : 1, >>> > 0x2efea0b3 : h'0102030000112233', >>> > 0x1e32edaf : 1 >>> > } >>> > ] >>> > } >>> > >>> > And the content of the datastore can be requested as follow: >>> > >>> > REQ: GET example.com/mg/data >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > "6top" : { >>> > 0x3470d0c5 : [ >>> > { >>> > 0x2a33a8b4 : 1, >>> > 0xfe4ad55 : 1, >>> > 0x2515e82f : 1, >>> > 0x9c2f821 : 1, >>> > 0x5057e17 : "Transmit,Timekeeping", >>> > 0xd2a79e8 : 0, >>> > 0x26e3537 : 1, >>> > 0x2efea0b3 : h'0102030000112233', >>> > 0x1e32edaf : 1 >>> > } >>> > ] >>> > }, >>> > "IP-MIB" : { >>> > 0x30b7bc3f : { >>> > 0x1067f289 : [ >>> > { >>> > 0x00d38564 : 1, >>> > 0x2745e222 : "ipv4", >>> > 0x387804eb : "10.0.0.51", >>> > 0x1a51514a : "00:00:10:01:23:45", >>> > 0x03f95578 : "2333943", >>> > 0x24ade115 : "static", >>> > 0x09e640ef : "reachable", >>> > 0x3b5c1ab6 : "active" >>> > }, >>> > { >>> > 0x00d38564 : 1, >>> > 0x2745e222 : "ipv4", >>> > 0x387804eb : "9.2.3.4", >>> > 0x1a51514a : "00:00:10:54:32:10", >>> > 0x03f95578 : "2329836", >>> > 0x24ade115 : "dynamic", >>> > 0x09e640ef : "unknown", >>> > 0x3b5c1ab6 : "active" >>> > } >>> > ] >>> > } >>> > } >>> > } >>> > >>> > Is it a real issue and is it a viable solution? >>> > >>> > Michel Veillette >>> > System Architecture Director >>> > Trilliant Inc. >>> > Tel: 450-375-0556 ext. 237 >>> > michel.veillette@trilliantinc.com >>> > www.trilliantinc.com >>> > >>> > >>> > _______________________________________________ >>> > core mailing list >>> > core@ietf.org >>> > https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 31 08:29:08 2015 Return-Path: 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 2294F1AC3C5 for ; Tue, 31 Mar 2015 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 ypJ-PrmSKV21 for ; Tue, 31 Mar 2015 08:29:04 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3661F1A907B for ; Tue, 31 Mar 2015 08:29:04 -0700 (PDT) Received: by lahf3 with SMTP id f3so15087285lah.2 for ; Tue, 31 Mar 2015 08:29:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=r/vNiMcWlGdREr2Xx5LkrVlKEqeiKEYCWfIQkuhOgek=; b=Et5OslBcufylbdcbB60x0G1WcBzUQESLWlsfVBdtIj+PixkRISlC0sju/UjsDvUqLk A7XeXV+TbqZFiY0NQBK6+mcek4WKagKn/NiojJJX4Co13e1Ox5OdLRQxGwz4Vk4r2Z7C bOQi0RY19j0KOdknwmon5tFqJT+WrBhOvA4pguwMlpx8dNvUVy1Xq+ATKd9poRGt94l+ IUyi20wYMqtX4tFVVoTGbxAfANOEQVQiNA3O7vFj3sFxOG7hftgb+w8gzjZjkTG6n8Y8 +LbrSB8sYGad+L8yCyz/SFOeplr3NzX6iLK64f9YwaqrsDh08ihJUKe+LrNOosli+sYP 4mgQ== X-Gm-Message-State: ALoCoQlUphhGBsULEz5gacDDd6O8kJ5wsuNlBQTHR6s7dfLBhxWhpoRhlZpw4+1i26vp5dAiNkmK MIME-Version: 1.0 X-Received: by 10.112.141.202 with SMTP id rq10mr31491053lbb.88.1427815742448; Tue, 31 Mar 2015 08:29:02 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Tue, 31 Mar 2015 08:29:02 -0700 (PDT) In-Reply-To: References:

Date: Tue, 31 Mar 2015 08:29:02 -0700 Message-ID: From: Andy Bierman To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:29:07 -0000 On Tue, Mar 31, 2015 at 7:50 AM, Michel Veillette wrote: > Hi Andy > > The intent is not to reduce the number of collisions but make these colli= sions predictable and uniform within a population of devices independently = of the number of modules implemented by them. This is especially important = in distributed applications such 6TiSH timeslot management. In such applica= tions, each constrained device need to interact with multiple other constra= ined devices using CoMI. With the current YANG hash approach, each constrai= ned device need to retrieve and maintain the rehash list for each peer. > > If the scope of YANG hash is reduced to the module level (data nodes defi= ned by a module + data nodes added to that module by the augment statement)= , collisions within this module can be determined based of the YAND definit= ion of this module and specific rehash values can be mandated or recommende= d if needed. > Nodes from module X that augment module Y are not known by module Y, when module Y is compiled or deployed. You seem to be suggesting that the 6TISCH WG will control all YANG modules on a device, even modules from vendors or other SDOs. Most deployment scenarios allow for the vendor to select the set of modules that are supported by a device. YANG is designed to be modul= ar and extensible, without requiring a single, centralized naming authority. > Michel Veillette Andy > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: 31 mars 2015 09:30 > To: Thomas Watteyne > Cc: 6tisch@ietf.org; core@ietf.org > Subject: Re: [core] COMI hash values globally unique vs. unique within a = module > > On Tue, Mar 31, 2015 at 12:15 AM, Thomas Watteyne wrote: >> [adding 6TiSCH] >> >> Andy, >> >> I believe the issue Michel highlights is that the hash collisions >> depends on the modules that are implemented in the CoMI endpoint. >> > > But hash collisions can occur within a module or across modules. > Allowing collisions across modules does not change the probability of a c= ollision. It does not remove the need to check for a collision. > > What problem are you trying to solve? > If it is to remove the possibility of a collision ever occurring then kee= p trying. Why is it better to change the scope of the object hash to be pe= r module name? > > The goal of the YANG hash is to lower the identifier size to a 4 byte num= ber. Adding the 10 - 20 byte module name to every identifier really doesn'= t help lower the identifier size at all. > > > Andy > > > >> That is, if nodeA implements the [/6t,/foo] modules, and nodeB the >> [/6t,/bar] modules, the hash collisions can be different, even in the >> same "6t" module. In the case of 6top, the YANG model describes the >> module completely. It would be awfully nice to be able to just rely on >> that YANG model to predict the hash collisions within that >> module.without having to discover the rehash-map on a server each time. >> >> IIRC, today, a client accessing any resource using CoMI needs to first >> retrieve the hash-map? The client needs to do this for each node is >> manages, potentially periodically if new modules are added on-the-fly? >> This seems like a lot of uncessary overhead. >> >> One way could be fr the server to return some error code when the >> client accesses a resource with a hash that is ambiguous. >> >> Your insight on this is very welcome. >> >> Thomas >> >> On Tue, Mar 31, 2015 at 3:46 AM, Andy Bierman wrote= : >>> >>> On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette >>> wrote: >>> > Currently, CoMI object identifiers (YANG hash) are globally unique >>> > within a CoMI server. Devices implementing different set of modules >>> > may have different YANG hash conflicts and may have a different set >>> > of object identifiers affected by rehash. In an application like >>> > 6TiSH, this means that the list of rehash values can't be known in >>> > advance based on the published YANG module, rehash values need to >>> > be discover and manage by each node involved in the timeslots reserva= tion process. >>> > >>> > Reducing the scope of the YANG hash to the context of a single >>> > module (data nodes defined by a module + data nodes added to that >>> > module by the augment statement) can mitigate this issue. The >>> > question is how this can be accomplished and if the overhead required= make this change acceptable. >>> > >>> >>> I don't think this will work. >>> The probability of collisions is the same whether 100 objects are >>> defined in 1 module or 10 objects are defined in each of 10 modules. >>> >>> The client must implement the rehash algorithm even though there is a >>> low probability it will be used. >>> >>> >>> Andy >>> >>> >>> > Impacts on the URI >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > Currently, the CoAP path consist of: >>> > "/mg/" >>> > >>> > Considering that the YANG hash is unique only within the context of >>> > a module, the CoAP path needs to include the module name: >>> > "/mg/data" or >>> > "/mg/data/: " >>> > >>> > Impacts on the CBOR content >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> > If the CoAP path target a specific module (e.g. "/mg/data/: >>> > "), the current CBOR encoding rules should apply unmodifi= ed. >>> > >>> > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI >>> > objects need to be associated to their respective module context. A >>> > CBOR map added to the root of the CBOR object can be used to establis= h this relationship. >>> > >>> > For example >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > Assuming: >>> > - hash of "/6top:CellList" =3D 0x3470d0c5, base64 "0cNDF" >>> > - hash of "/6top:CellList/6top:CellID" =3D 0x2a33a8b4 >>> > - hash of "/6top:CellList/6top:SlotframeI" =3D 0xfe4ad55 >>> > - hash of "/6top:CellList/6top:SlotOffset" =3D 0x2515e82f >>> > - hash of "/6top:CellList/6top:ChannelOffset" =3D 0x9c2f821, base64 >>> > "Jwvgh" >>> > - hash of "/6top:CellList/6top:LinkOption" =3D 0x5057e17 >>> > - hash of "/6top:CellList/6top:LinkType" =3D 0xd2a79e8 >>> > - hash of "/6top:CellList/6top:CellType" =3D 0x26e3537 >>> > - hash of "/6top:CellList/6top:TargetNodeAddress" =3D 0x2efea0b3 >>> > - hash of "/6top:CellList/6top:TrackID" =3D 0x1e32edaf >>> > >>> > The "/6top:CellList/6top:ChannelOffset" data node can be requested >>> > as >>> > follow: >>> > >>> > REQ: GET example.com/mg/data/6top:Jwvgh >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > 0x9c2f821 : 5 >>> > } >>> > >>> > The content of the "/6top:CellList" list can be requested as follow: >>> > >>> > REQ: GET example.com/mg/data/6top:0cNDF >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > 0x3470d0c5 : [ >>> > { >>> > 0x2a33a8b4 : 1, >>> > 0xfe4ad55 : 1, >>> > 0x2515e82f : 1, >>> > 0x9c2f821 : 1, >>> > 0x5057e17 : "Transmit,Timekeeping", >>> > 0xd2a79e8 : 0, >>> > 0x26e3537 : 1, >>> > 0x2efea0b3 : h'0102030000112233', >>> > 0x1e32edaf : 1 >>> > } >>> > ] >>> > } >>> > >>> > And the content of the datastore can be requested as follow: >>> > >>> > REQ: GET example.com/mg/data >>> > >>> > RES: 2.05 Content (Content-Format: application/cbor) >>> > { >>> > "6top" : { >>> > 0x3470d0c5 : [ >>> > { >>> > 0x2a33a8b4 : 1, >>> > 0xfe4ad55 : 1, >>> > 0x2515e82f : 1, >>> > 0x9c2f821 : 1, >>> > 0x5057e17 : "Transmit,Timekeeping", >>> > 0xd2a79e8 : 0, >>> > 0x26e3537 : 1, >>> > 0x2efea0b3 : h'0102030000112233', >>> > 0x1e32edaf : 1 >>> > } >>> > ] >>> > }, >>> > "IP-MIB" : { >>> > 0x30b7bc3f : { >>> > 0x1067f289 : [ >>> > { >>> > 0x00d38564 : 1, >>> > 0x2745e222 : "ipv4", >>> > 0x387804eb : "10.0.0.51", >>> > 0x1a51514a : "00:00:10:01:23:45", >>> > 0x03f95578 : "2333943", >>> > 0x24ade115 : "static", >>> > 0x09e640ef : "reachable", >>> > 0x3b5c1ab6 : "active" >>> > }, >>> > { >>> > 0x00d38564 : 1, >>> > 0x2745e222 : "ipv4", >>> > 0x387804eb : "9.2.3.4", >>> > 0x1a51514a : "00:00:10:54:32:10", >>> > 0x03f95578 : "2329836", >>> > 0x24ade115 : "dynamic", >>> > 0x09e640ef : "unknown", >>> > 0x3b5c1ab6 : "active" >>> > } >>> > ] >>> > } >>> > } >>> > } >>> > >>> > Is it a real issue and is it a viable solution? >>> > >>> > Michel Veillette >>> > System Architecture Director >>> > Trilliant Inc. >>> > Tel: 450-375-0556 ext. 237 >>> > michel.veillette@trilliantinc.com >>> > www.trilliantinc.com >>> > >>> > >>> > _______________________________________________ >>> > core mailing list >>> > core@ietf.org >>> > https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 31 08:53:45 2015 Return-Path: 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 E38EE1AC411; Tue, 31 Mar 2015 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 63QAFmjU74zS; Tue, 31 Mar 2015 08:53:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6044D1AC413; Tue, 31 Mar 2015 08:53:37 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB790.namprd06.prod.outlook.com (10.141.247.142) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 31 Mar 2015 15:53:16 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0112.000; Tue, 31 Mar 2015 15:53:16 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] COMI hash values globally unique vs. unique within a module Thread-Index: AQHQa8dtRg20MVrYfEyNSmCW5DT13502uKlQ Date: Tue, 31 Mar 2015 15:53:15 +0000 Message-ID: References:

In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.96.192.122] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB790; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(377454003)(38414003)(50986999)(40100003)(62966003)(99286002)(92566002)(106116001)(575784001)(86362001)(2656002)(93886004)(110136001)(74316001)(77156002)(15975445007)(54356999)(15974865002)(87936001)(102836002)(19580405001)(77096005)(33656002)(2900100001)(76576001)(122556002)(46102003)(66066001)(19580395003)(76176999)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0601MB790; H:CO2PR0601MB792.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR0601MB790; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB790; x-forefront-prvs: 0532BF6DC2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 15:53:15.3455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB790 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:53:44 -0000 SGkgQW5keQ0KDQotIEFib3V0IHlvdXIgY29tbWVudCAiIE5vZGVzIGZyb20gbW9kdWxlIFggdGhh dCBhdWdtZW50IG1vZHVsZSBZIGFyZSBub3Qga25vd24gYnkgbW9kdWxlIFksIHdoZW4gbW9kdWxl IFkgaXMgY29tcGlsZWQgb3IgZGVwbG95ZWQuIg0KDQpJZiBhIGRhdGEgbm9kZSAneScgYWRkZWQg YnkgbW9kdWxlICdZJyB0byBtb2R1bGUgJ1gnIGNyZWF0ZSBhIFlBTkcgaGFzaCBjb25mbGljdCwg ZGF0YSBub2RlICd5JyB3aWxsIG5lZWQgdG8gYmUgcmVoYXNoLiBUaGlzIGRvbid0IGFmZmVjdCBZ QU5HIGhhc2ggdmFsdWVzIG9mIHRoZSBkYXRhIG5vZGVzIGFscmVhZHkgZGVmaW5lZCBieSBtb2R1 bGUgJ1gnLg0KDQotIEFib3V0IHlvdXIgY29tbWVudCAiIFlvdSBzZWVtIHRvIGJlIHN1Z2dlc3Rp bmcgdGhhdCB0aGUgNlRJU0NIIFdHIHdpbGwgY29udHJvbCBhbGwgWUFORyBtb2R1bGVzIG9uIGEg ZGV2aWNlLCBldmVuIG1vZHVsZXMgZnJvbSB2ZW5kb3JzIG9yIG90aGVyIFNET3MuIg0KDQpUaGlz IGlzIG5vdCB0aGUgY2FzZSwgZGV2aWNlcyBhcmUgZnJlZSB0byBpbXBsZW1lbnQgYW55IG51bWJl ciBvZiBZQU5HIG1vZHVsZXMgbmVlZGVkLiBCeSBjcmVhdGluZyBhIGRpc3RpbmN0IGhhc2ggc3Bh Y2UgZm9yIGVhY2ggbW9kdWxlLCB3ZSBjYW4gbWluaW1pemUgaW1wYWN0cyB3aGVuIGludGVncmF0 aW5nIG11bHRpcGxlIG1vZHVsZXMgd2l0aGluIGEgc2luZ2xlIHNlcnZlci4NCg0KLSBBYm91dCB5 b3VyIGNvbW1lbnQgIiBNb3N0IGRlcGxveW1lbnQgc2NlbmFyaW9zIGFsbG93IGZvciB0aGUgdmVu ZG9yIHRvIHNlbGVjdCB0aGUgc2V0IG9mIG1vZHVsZXMgdGhhdCBhcmUgc3VwcG9ydGVkIGJ5IGEg ZGV2aWNlLiBZQU5HIGlzIGRlc2lnbmVkIHRvIGJlIG1vZHVsYXIgYW5kIGV4dGVuc2libGUsIHdp dGhvdXQgcmVxdWlyaW5nIGEgc2luZ2xlLCBjZW50cmFsaXplZCBuYW1pbmcgYXV0aG9yaXR5LiIN Cg0KVGhlIGludGVudCBpcyB0byByZWluZm9yY2UgdGhpcyBtb2RlbCBhbmQgaW1wcm92ZSBpdHMg c2NhbGFiaWxpdHkuDQoNCk1pY2hlbCBWZWlsbGV0dGUNClN5c3RlbSBBcmNoaXRlY3R1cmUgRGly ZWN0b3INClRyaWxsaWFudCBJbmMuDQpUZWw6IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KbWljaGVs LnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tDQp3d3cudHJpbGxpYW50aW5jLmNvbSDCoCANCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86 YW5keUB5dW1hd29ya3MuY29tXSANClNlbnQ6IDMxIG1hcnMgMjAxNSAxMToyOQ0KVG86IE1pY2hl bCBWZWlsbGV0dGUNCkNjOiBUaG9tYXMgV2F0dGV5bmU7IDZ0aXNjaEBpZXRmLm9yZzsgY29yZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBDT01JIGhhc2ggdmFsdWVzIGdsb2JhbGx5IHVu aXF1ZSB2cy4gdW5pcXVlIHdpdGhpbiBhIG1vZHVsZQ0KDQpPbiBUdWUsIE1hciAzMSwgMjAxNSBh dCA3OjUwIEFNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGlu Yy5jb20+IHdyb3RlOg0KPiBIaSBBbmR5DQo+DQo+IFRoZSBpbnRlbnQgaXMgbm90IHRvIHJlZHVj ZSB0aGUgbnVtYmVyIG9mIGNvbGxpc2lvbnMgYnV0IG1ha2UgdGhlc2UgY29sbGlzaW9ucyBwcmVk aWN0YWJsZSBhbmQgdW5pZm9ybSB3aXRoaW4gYSBwb3B1bGF0aW9uIG9mIGRldmljZXMgaW5kZXBl bmRlbnRseSBvZiB0aGUgbnVtYmVyIG9mIG1vZHVsZXMgaW1wbGVtZW50ZWQgYnkgdGhlbS4gVGhp cyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBpbiBkaXN0cmlidXRlZCBhcHBsaWNhdGlvbnMgc3Vj aCA2VGlTSCB0aW1lc2xvdCBtYW5hZ2VtZW50LiBJbiBzdWNoIGFwcGxpY2F0aW9ucywgZWFjaCBj b25zdHJhaW5lZCBkZXZpY2UgbmVlZCB0byBpbnRlcmFjdCB3aXRoIG11bHRpcGxlIG90aGVyIGNv bnN0cmFpbmVkIGRldmljZXMgdXNpbmcgQ29NSS4gV2l0aCB0aGUgY3VycmVudCBZQU5HIGhhc2gg YXBwcm9hY2gsIGVhY2ggY29uc3RyYWluZWQgZGV2aWNlIG5lZWQgdG8gcmV0cmlldmUgYW5kIG1h aW50YWluIHRoZSByZWhhc2ggbGlzdCBmb3IgZWFjaCBwZWVyLg0KPg0KPiBJZiB0aGUgc2NvcGUg b2YgWUFORyBoYXNoIGlzIHJlZHVjZWQgdG8gdGhlIG1vZHVsZSBsZXZlbCAoZGF0YSBub2RlcyBk ZWZpbmVkIGJ5IGEgbW9kdWxlICsgZGF0YSBub2RlcyBhZGRlZCB0byB0aGF0IG1vZHVsZSBieSB0 aGUgYXVnbWVudCBzdGF0ZW1lbnQpLCBjb2xsaXNpb25zIHdpdGhpbiB0aGlzIG1vZHVsZSBjYW4g YmUgZGV0ZXJtaW5lZCBiYXNlZCBvZiB0aGUgWUFORCBkZWZpbml0aW9uIG9mIHRoaXMgbW9kdWxl IGFuZCBzcGVjaWZpYyByZWhhc2ggdmFsdWVzIGNhbiBiZSBtYW5kYXRlZCBvciByZWNvbW1lbmRl ZCBpZiBuZWVkZWQuDQo+DQoNCg0KTm9kZXMgZnJvbSBtb2R1bGUgWCB0aGF0IGF1Z21lbnQgbW9k dWxlIFkgYXJlIG5vdCBrbm93biBieSBtb2R1bGUgWSwgd2hlbiBtb2R1bGUgWSBpcyBjb21waWxl ZCBvciBkZXBsb3llZC4NCg0KWW91IHNlZW0gdG8gYmUgc3VnZ2VzdGluZyB0aGF0IHRoZSA2VElT Q0ggV0cgd2lsbCBjb250cm9sIGFsbCBZQU5HIG1vZHVsZXMgb24gYSBkZXZpY2UsIGV2ZW4gbW9k dWxlcyBmcm9tIHZlbmRvcnMgb3Igb3RoZXIgU0RPcy4NCg0KTW9zdCBkZXBsb3ltZW50IHNjZW5h cmlvcyBhbGxvdyBmb3IgdGhlIHZlbmRvciB0byBzZWxlY3QgdGhlIHNldCBvZiBtb2R1bGVzIHRo YXQgYXJlIHN1cHBvcnRlZCBieSBhIGRldmljZS4gWUFORyBpcyBkZXNpZ25lZCB0byBiZSBtb2R1 bGFyIGFuZCBleHRlbnNpYmxlLCB3aXRob3V0IHJlcXVpcmluZyBhIHNpbmdsZSwgY2VudHJhbGl6 ZWQgbmFtaW5nIGF1dGhvcml0eS4NCg0KDQo+IE1pY2hlbCBWZWlsbGV0dGUNCg0KQW5keQ0KDQoN Cj4gU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0KPiBUcmlsbGlhbnQgSW5jLg0KPiBUZWw6 IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KPiBtaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudGluYy5j b20NCj4gd3d3LnRyaWxsaWFudGluYy5jb20NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFuZHkgQmllcm1hbg0KPiBTZW50OiAzMSBtYXJzIDIwMTUgMDk6MzANCj4gVG86IFRob21h cyBXYXR0ZXluZQ0KPiBDYzogNnRpc2NoQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbY29yZV0gQ09NSSBoYXNoIHZhbHVlcyBnbG9iYWxseSB1bmlxdWUgdnMuIHVuaXF1 ZSB3aXRoaW4gDQo+IGEgbW9kdWxlDQo+DQo+IE9uIFR1ZSwgTWFyIDMxLCAyMDE1IGF0IDEyOjE1 IEFNLCBUaG9tYXMgV2F0dGV5bmUgPHdhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PiB3cm90ZToN Cj4+IFthZGRpbmcgNlRpU0NIXQ0KPj4NCj4+IEFuZHksDQo+Pg0KPj4gSSBiZWxpZXZlIHRoZSBp c3N1ZSBNaWNoZWwgaGlnaGxpZ2h0cyBpcyB0aGF0IHRoZSBoYXNoIGNvbGxpc2lvbnMgDQo+PiBk ZXBlbmRzIG9uIHRoZSBtb2R1bGVzIHRoYXQgYXJlIGltcGxlbWVudGVkIGluIHRoZSBDb01JIGVu ZHBvaW50Lg0KPj4NCj4NCj4gQnV0IGhhc2ggY29sbGlzaW9ucyBjYW4gb2NjdXIgd2l0aGluIGEg bW9kdWxlIG9yIGFjcm9zcyBtb2R1bGVzLg0KPiBBbGxvd2luZyBjb2xsaXNpb25zIGFjcm9zcyBt b2R1bGVzIGRvZXMgbm90IGNoYW5nZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSBjb2xsaXNpb24uICBJ dCBkb2VzIG5vdCByZW1vdmUgdGhlIG5lZWQgdG8gY2hlY2sgZm9yIGEgY29sbGlzaW9uLg0KPg0K PiBXaGF0IHByb2JsZW0gYXJlIHlvdSB0cnlpbmcgdG8gc29sdmU/DQo+IElmIGl0IGlzIHRvIHJl bW92ZSB0aGUgcG9zc2liaWxpdHkgb2YgYSBjb2xsaXNpb24gZXZlciBvY2N1cnJpbmcgdGhlbiBr ZWVwIHRyeWluZy4gIFdoeSBpcyBpdCBiZXR0ZXIgdG8gY2hhbmdlIHRoZSBzY29wZSBvZiB0aGUg b2JqZWN0IGhhc2ggdG8gYmUgcGVyIG1vZHVsZSBuYW1lPw0KPg0KPiBUaGUgZ29hbCBvZiB0aGUg WUFORyBoYXNoIGlzIHRvIGxvd2VyIHRoZSBpZGVudGlmaWVyIHNpemUgdG8gYSA0IGJ5dGUgbnVt YmVyLiAgQWRkaW5nIHRoZSAxMCAtIDIwIGJ5dGUgbW9kdWxlIG5hbWUgdG8gZXZlcnkgaWRlbnRp ZmllciByZWFsbHkgZG9lc24ndCBoZWxwIGxvd2VyIHRoZSBpZGVudGlmaWVyIHNpemUgYXQgYWxs Lg0KPg0KPg0KPiBBbmR5DQo+DQo+DQo+DQo+PiBUaGF0IGlzLCBpZiBub2RlQSBpbXBsZW1lbnRz IHRoZSBbLzZ0LC9mb29dIG1vZHVsZXMsIGFuZCBub2RlQiB0aGUgDQo+PiBbLzZ0LC9iYXJdIG1v ZHVsZXMsIHRoZSBoYXNoIGNvbGxpc2lvbnMgY2FuIGJlIGRpZmZlcmVudCwgZXZlbiBpbiB0aGUg DQo+PiBzYW1lICI2dCIgbW9kdWxlLiBJbiB0aGUgY2FzZSBvZiA2dG9wLCB0aGUgWUFORyBtb2Rl bCBkZXNjcmliZXMgdGhlIA0KPj4gbW9kdWxlIGNvbXBsZXRlbHkuIEl0IHdvdWxkIGJlIGF3ZnVs bHkgbmljZSB0byBiZSBhYmxlIHRvIGp1c3QgcmVseSANCj4+IG9uIHRoYXQgWUFORyBtb2RlbCB0 byBwcmVkaWN0IHRoZSBoYXNoIGNvbGxpc2lvbnMgd2l0aGluIHRoYXQgDQo+PiBtb2R1bGUud2l0 aG91dCBoYXZpbmcgdG8gZGlzY292ZXIgdGhlIHJlaGFzaC1tYXAgb24gYSBzZXJ2ZXIgZWFjaCB0 aW1lLg0KPj4NCj4+IElJUkMsIHRvZGF5LCBhIGNsaWVudCBhY2Nlc3NpbmcgYW55IHJlc291cmNl IHVzaW5nIENvTUkgbmVlZHMgdG8gDQo+PiBmaXJzdCByZXRyaWV2ZSB0aGUgaGFzaC1tYXA/IFRo ZSBjbGllbnQgbmVlZHMgdG8gZG8gdGhpcyBmb3IgZWFjaCANCj4+IG5vZGUgaXMgbWFuYWdlcywg cG90ZW50aWFsbHkgcGVyaW9kaWNhbGx5IGlmIG5ldyBtb2R1bGVzIGFyZSBhZGRlZCBvbi10aGUt Zmx5Pw0KPj4gVGhpcyBzZWVtcyBsaWtlIGEgbG90IG9mIHVuY2Vzc2FyeSBvdmVyaGVhZC4NCj4+ DQo+PiBPbmUgd2F5IGNvdWxkIGJlIGZyIHRoZSBzZXJ2ZXIgdG8gcmV0dXJuIHNvbWUgZXJyb3Ig Y29kZSB3aGVuIHRoZSANCj4+IGNsaWVudCBhY2Nlc3NlcyBhIHJlc291cmNlIHdpdGggYSBoYXNo IHRoYXQgaXMgYW1iaWd1b3VzLg0KPj4NCj4+IFlvdXIgaW5zaWdodCBvbiB0aGlzIGlzIHZlcnkg d2VsY29tZS4NCj4+DQo+PiBUaG9tYXMNCj4+DQo+PiBPbiBUdWUsIE1hciAzMSwgMjAxNSBhdCAz OjQ2IEFNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+Pj4NCj4+ PiBPbiBNb24sIE1hciAzMCwgMjAxNSBhdCAxMjo0MyBQTSwgTWljaGVsIFZlaWxsZXR0ZSANCj4+ PiA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPiB3cm90ZToNCj4+PiA+IEN1cnJl bnRseSwgQ29NSSBvYmplY3QgaWRlbnRpZmllcnMgKFlBTkcgaGFzaCkgYXJlIGdsb2JhbGx5IHVu aXF1ZSANCj4+PiA+IHdpdGhpbiBhIENvTUkgc2VydmVyLiBEZXZpY2VzIGltcGxlbWVudGluZyBk aWZmZXJlbnQgc2V0IG9mIA0KPj4+ID4gbW9kdWxlcyBtYXkgaGF2ZSBkaWZmZXJlbnQgWUFORyBo YXNoIGNvbmZsaWN0cyBhbmQgbWF5IGhhdmUgYSANCj4+PiA+IGRpZmZlcmVudCBzZXQgb2Ygb2Jq ZWN0IGlkZW50aWZpZXJzIGFmZmVjdGVkIGJ5IHJlaGFzaC4gSW4gYW4gDQo+Pj4gPiBhcHBsaWNh dGlvbiBsaWtlIDZUaVNILCB0aGlzIG1lYW5zIHRoYXQgdGhlIGxpc3Qgb2YgcmVoYXNoIHZhbHVl cyANCj4+PiA+IGNhbid0IGJlIGtub3duIGluIGFkdmFuY2UgYmFzZWQgb24gdGhlIHB1Ymxpc2hl ZCBZQU5HIG1vZHVsZSwgDQo+Pj4gPiByZWhhc2ggdmFsdWVzIG5lZWQgdG8gYmUgZGlzY292ZXIg YW5kIG1hbmFnZSBieSBlYWNoIG5vZGUgaW52b2x2ZWQgaW4gdGhlIHRpbWVzbG90cyByZXNlcnZh dGlvbiBwcm9jZXNzLg0KPj4+ID4NCj4+PiA+IFJlZHVjaW5nIHRoZSBzY29wZSBvZiB0aGUgWUFO RyBoYXNoIHRvIHRoZSBjb250ZXh0IG9mIGEgc2luZ2xlIA0KPj4+ID4gbW9kdWxlIChkYXRhIG5v ZGVzIGRlZmluZWQgYnkgYSBtb2R1bGUgKyBkYXRhIG5vZGVzIGFkZGVkIHRvIHRoYXQgDQo+Pj4g PiBtb2R1bGUgYnkgdGhlIGF1Z21lbnQgc3RhdGVtZW50KSBjYW4gbWl0aWdhdGUgdGhpcyBpc3N1 ZS4gVGhlIA0KPj4+ID4gcXVlc3Rpb24gaXMgaG93IHRoaXMgY2FuIGJlIGFjY29tcGxpc2hlZCBh bmQgaWYgdGhlIG92ZXJoZWFkIHJlcXVpcmVkIG1ha2UgdGhpcyBjaGFuZ2UgYWNjZXB0YWJsZS4N Cj4+PiA+DQo+Pj4NCj4+PiBJIGRvbid0IHRoaW5rIHRoaXMgd2lsbCB3b3JrLg0KPj4+IFRoZSBw cm9iYWJpbGl0eSBvZiBjb2xsaXNpb25zIGlzIHRoZSBzYW1lIHdoZXRoZXIgMTAwIG9iamVjdHMg YXJlIA0KPj4+IGRlZmluZWQgaW4gMSBtb2R1bGUgb3IgMTAgb2JqZWN0cyBhcmUgZGVmaW5lZCBp biBlYWNoIG9mIDEwIG1vZHVsZXMuDQo+Pj4NCj4+PiBUaGUgY2xpZW50IG11c3QgaW1wbGVtZW50 IHRoZSByZWhhc2ggYWxnb3JpdGhtIGV2ZW4gdGhvdWdoIHRoZXJlIGlzIA0KPj4+IGEgbG93IHBy b2JhYmlsaXR5IGl0IHdpbGwgYmUgdXNlZC4NCj4+Pg0KPj4+DQo+Pj4gQW5keQ0KPj4+DQo+Pj4N Cj4+PiA+IEltcGFjdHMgb24gdGhlIFVSSQ0KPj4+ID4gPT09PT09PT09PT09PT09DQo+Pj4gPiBD dXJyZW50bHksIHRoZSBDb0FQIHBhdGggY29uc2lzdCBvZjoNCj4+PiA+ICAiL21nLzxoYXNoLXZh bHVlPiINCj4+PiA+DQo+Pj4gPiBDb25zaWRlcmluZyB0aGF0IHRoZSBZQU5HIGhhc2ggaXMgdW5p cXVlIG9ubHkgd2l0aGluIHRoZSBjb250ZXh0IA0KPj4+ID4gb2YgYSBtb2R1bGUsIHRoZSBDb0FQ IHBhdGggbmVlZHMgdG8gaW5jbHVkZSB0aGUgbW9kdWxlIG5hbWU6DQo+Pj4gPiAiL21nL2RhdGEi IG9yDQo+Pj4gPiAgIi9tZy9kYXRhLzxtb2R1bGVOYW1lPjogPGhhc2gtdmFsdWU+Ig0KPj4+ID4N Cj4+PiA+IEltcGFjdHMgb24gdGhlIENCT1IgY29udGVudA0KPj4+ID4gPT09PT09PT09PT09PT09 PT09PT09PT09DQo+Pj4gPiBJZiB0aGUgQ29BUCBwYXRoIHRhcmdldCBhIHNwZWNpZmljIG1vZHVs ZSAoZS5nLiAiL21nL2RhdGEvPG1vZHVsZU5hbWU+Og0KPj4+ID4gPGhhc2gtdmFsdWU+IiksIHRo ZSBjdXJyZW50IENCT1IgZW5jb2RpbmcgcnVsZXMgc2hvdWxkIGFwcGx5IHVubW9kaWZpZWQuDQo+ Pj4gPg0KPj4+ID4gSWYgdGhlIENvQVAgcGF0aCB0YXJnZXQgbXVsdGlwbGUgbW9kdWxlcyAoZS5n LiAiL21nL2RhdGEiKSwgQ29NSSANCj4+PiA+IG9iamVjdHMgbmVlZCB0byBiZSBhc3NvY2lhdGVk IHRvIHRoZWlyIHJlc3BlY3RpdmUgbW9kdWxlIGNvbnRleHQuIA0KPj4+ID4gQSBDQk9SIG1hcCBh ZGRlZCB0byB0aGUgcm9vdCBvZiB0aGUgQ0JPUiBvYmplY3QgY2FuIGJlIHVzZWQgdG8gZXN0YWJs aXNoIHRoaXMgcmVsYXRpb25zaGlwLg0KPj4+ID4NCj4+PiA+IEZvciBleGFtcGxlDQo+Pj4gPiA9 PT09PT09PT09DQo+Pj4gPiBBc3N1bWluZzoNCj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExp c3QiID0gIDB4MzQ3MGQwYzUsIGJhc2U2NCAiMGNOREYiDQo+Pj4gPiAtIGhhc2ggb2YgIi82dG9w OkNlbGxMaXN0LzZ0b3A6Q2VsbElEIiA9IDB4MmEzM2E4YjQNCj4+PiA+IC0gaGFzaCBvZiAiLzZ0 b3A6Q2VsbExpc3QvNnRvcDpTbG90ZnJhbWVJIiA9IDB4ZmU0YWQ1NQ0KPj4+ID4gLSBoYXNoIG9m ICIvNnRvcDpDZWxsTGlzdC82dG9wOlNsb3RPZmZzZXQiID0gMHgyNTE1ZTgyZg0KPj4+ID4gLSBo YXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9wOkNoYW5uZWxPZmZzZXQiID0gMHg5YzJmODIxLCBi YXNlNjQgDQo+Pj4gPiAiSnd2Z2giDQo+Pj4gPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0 b3A6TGlua09wdGlvbiIgPSAweDUwNTdlMTcNCj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExp c3QvNnRvcDpMaW5rVHlwZSIgPSAweGQyYTc5ZTgNCj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2Vs bExpc3QvNnRvcDpDZWxsVHlwZSIgPSAweDI2ZTM1MzcNCj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6 Q2VsbExpc3QvNnRvcDpUYXJnZXROb2RlQWRkcmVzcyIgPSAweDJlZmVhMGIzDQo+Pj4gPiAtIGhh c2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6VHJhY2tJRCIgPSAweDFlMzJlZGFmDQo+Pj4gPg0K Pj4+ID4gVGhlICIvNnRvcDpDZWxsTGlzdC82dG9wOkNoYW5uZWxPZmZzZXQiIGRhdGEgbm9kZSBj YW4gYmUgcmVxdWVzdGVkIA0KPj4+ID4gYXMNCj4+PiA+IGZvbGxvdzoNCj4+PiA+DQo+Pj4gPiAg IFJFUTogR0VUIGV4YW1wbGUuY29tL21nL2RhdGEvNnRvcDpKd3ZnaA0KPj4+ID4NCj4+PiA+ICAg UkVTOiAyLjA1IENvbnRlbnQgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNhdGlvbi9jYm9yKQ0KPj4+ ID4gICB7DQo+Pj4gPiAgICAgMHg5YzJmODIxIDogNQ0KPj4+ID4gICB9DQo+Pj4gPg0KPj4+ID4g VGhlIGNvbnRlbnQgb2YgdGhlICIvNnRvcDpDZWxsTGlzdCIgIGxpc3QgY2FuIGJlIHJlcXVlc3Rl ZCBhcyBmb2xsb3c6DQo+Pj4gPg0KPj4+ID4gICBSRVE6IEdFVCBleGFtcGxlLmNvbS9tZy9kYXRh LzZ0b3A6MGNOREYNCj4+PiA+DQo+Pj4gPiAgIFJFUzogMi4wNSBDb250ZW50IChDb250ZW50LUZv cm1hdDogYXBwbGljYXRpb24vY2JvcikNCj4+PiA+ICAgew0KPj4+ID4gICAgIDB4MzQ3MGQwYzUg OiBbDQo+Pj4gPiAgICAgICB7DQo+Pj4gPiAgICAgICAgIDB4MmEzM2E4YjQgOiAxLA0KPj4+ID4g ICAgICAgICAweGZlNGFkNTUgOiAxLA0KPj4+ID4gICAgICAgICAweDI1MTVlODJmIDogMSwNCj4+ PiA+ICAgICAgICAgMHg5YzJmODIxIDogMSwNCj4+PiA+ICAgICAgICAgMHg1MDU3ZTE3IDogIlRy YW5zbWl0LFRpbWVrZWVwaW5nIiwNCj4+PiA+ICAgICAgICAgMHhkMmE3OWU4IDogMCwNCj4+PiA+ ICAgICAgICAgMHgyNmUzNTM3IDogMSwNCj4+PiA+ICAgICAgICAgMHgyZWZlYTBiMyA6IGgnMDEw MjAzMDAwMDExMjIzMycsDQo+Pj4gPiAgICAgICAgIDB4MWUzMmVkYWYgOiAxDQo+Pj4gPiAgICAg ICB9DQo+Pj4gPiAgICAgXQ0KPj4+ID4gICB9DQo+Pj4gPg0KPj4+ID4gQW5kIHRoZSBjb250ZW50 IG9mIHRoZSBkYXRhc3RvcmUgY2FuIGJlIHJlcXVlc3RlZCBhcyBmb2xsb3c6DQo+Pj4gPg0KPj4+ ID4gICBSRVE6IEdFVCBleGFtcGxlLmNvbS9tZy9kYXRhDQo+Pj4gPg0KPj4+ID4gICBSRVM6IDIu MDUgQ29udGVudCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9uL2Nib3IpDQo+Pj4gPiAgIHsN Cj4+PiA+ICAgICAiNnRvcCIgOiB7DQo+Pj4gPiAgICAgICAweDM0NzBkMGM1IDogWw0KPj4+ID4g ICAgICAgICB7DQo+Pj4gPiAgICAgICAgICAgMHgyYTMzYThiNCA6IDEsDQo+Pj4gPiAgICAgICAg ICAgMHhmZTRhZDU1IDogMSwNCj4+PiA+ICAgICAgICAgICAweDI1MTVlODJmIDogMSwNCj4+PiA+ ICAgICAgICAgICAweDljMmY4MjEgOiAxLA0KPj4+ID4gICAgICAgICAgIDB4NTA1N2UxNyA6ICJU cmFuc21pdCxUaW1la2VlcGluZyIsDQo+Pj4gPiAgICAgICAgICAgMHhkMmE3OWU4IDogMCwNCj4+ PiA+ICAgICAgICAgICAweDI2ZTM1MzcgOiAxLA0KPj4+ID4gICAgICAgICAgIDB4MmVmZWEwYjMg OiBoJzAxMDIwMzAwMDAxMTIyMzMnLA0KPj4+ID4gICAgICAgICAgIDB4MWUzMmVkYWYgOiAxDQo+ Pj4gPiAgICAgICAgIH0NCj4+PiA+ICAgICAgIF0NCj4+PiA+ICAgICB9LA0KPj4+ID4gICAgICJJ UC1NSUIiIDogew0KPj4+ID4gICAgICAgMHgzMGI3YmMzZiA6IHsNCj4+PiA+ICAgICAgICAgMHgx MDY3ZjI4OSA6IFsNCj4+PiA+ICAgICAgICAgICB7DQo+Pj4gPiAgICAgICAgICAgICAweDAwZDM4 NTY0IDogMSwNCj4+PiA+ICAgICAgICAgICAgIDB4Mjc0NWUyMjIgOiAiaXB2NCIsDQo+Pj4gPiAg ICAgICAgICAgICAweDM4NzgwNGViIDogIjEwLjAuMC41MSIsDQo+Pj4gPiAgICAgICAgICAgICAw eDFhNTE1MTRhIDogIjAwOjAwOjEwOjAxOjIzOjQ1IiwNCj4+PiA+ICAgICAgICAgICAgIDB4MDNm OTU1NzggOiAiMjMzMzk0MyIsDQo+Pj4gPiAgICAgICAgICAgICAweDI0YWRlMTE1IDogInN0YXRp YyIsDQo+Pj4gPiAgICAgICAgICAgICAweDA5ZTY0MGVmIDogInJlYWNoYWJsZSIsDQo+Pj4gPiAg ICAgICAgICAgICAweDNiNWMxYWI2IDogImFjdGl2ZSINCj4+PiA+ICAgICAgICAgICB9LA0KPj4+ ID4gICAgICAgICAgIHsNCj4+PiA+ICAgICAgICAgICAgIDB4MDBkMzg1NjQgOiAxLA0KPj4+ID4g ICAgICAgICAgICAgMHgyNzQ1ZTIyMiA6ICJpcHY0IiwNCj4+PiA+ICAgICAgICAgICAgIDB4Mzg3 ODA0ZWIgOiAiOS4yLjMuNCIsDQo+Pj4gPiAgICAgICAgICAgICAweDFhNTE1MTRhIDogIjAwOjAw OjEwOjU0OjMyOjEwIiwNCj4+PiA+ICAgICAgICAgICAgIDB4MDNmOTU1NzggOiAiMjMyOTgzNiIs DQo+Pj4gPiAgICAgICAgICAgICAweDI0YWRlMTE1IDogImR5bmFtaWMiLA0KPj4+ID4gICAgICAg ICAgICAgMHgwOWU2NDBlZiA6ICJ1bmtub3duIiwNCj4+PiA+ICAgICAgICAgICAgIDB4M2I1YzFh YjYgOiAiYWN0aXZlIg0KPj4+ID4gICAgICAgICAgIH0NCj4+PiA+ICAgICAgICAgXQ0KPj4+ID4g ICAgICAgfQ0KPj4+ID4gICAgIH0NCj4+PiA+ICAgfQ0KPj4+ID4NCj4+PiA+IElzIGl0IGEgcmVh bCBpc3N1ZSBhbmQgaXMgaXQgYSB2aWFibGUgc29sdXRpb24/DQo+Pj4gPg0KPj4+ID4gTWljaGVs IFZlaWxsZXR0ZQ0KPj4+ID4gU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0KPj4+ID4gVHJp bGxpYW50IEluYy4NCj4+PiA+IFRlbDogNDUwLTM3NS0wNTU2IGV4dC4gMjM3DQo+Pj4gPiBtaWNo ZWwudmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20NCj4+PiA+IHd3dy50cmlsbGlhbnRpbmMuY29t DQo+Pj4gPg0KPj4+ID4NCj4+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4gPiBjb3JlIG1haWxpbmcgbGlzdA0KPj4+ID4gY29yZUBpZXRmLm9y Zw0KPj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+Pj4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4gY29yZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGNvcmUgbWFpbGluZyBsaXN0 DQo+PiBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Tue Mar 31 09:30:20 2015 Return-Path: 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 5FAF91A013B for ; Tue, 31 Mar 2015 09:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 6ZmAbmtY_gBr for ; Tue, 31 Mar 2015 09:30:17 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1000C1A0145 for ; Tue, 31 Mar 2015 09:30:13 -0700 (PDT) Received: by lboc7 with SMTP id c7so16628974lbo.1 for ; Tue, 31 Mar 2015 09:30:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JvH4V7eSPaTXArAIBDsZ76rteIdOfl5Nj6ADoflkj8w=; b=OvEpAnaHN1agGIF1WdnV3oXAkBeuDj45P7nBYoN8LOlQDn5P+cLEKnOf/cWR2M4CwR 9/KU3fk6X/BUYa69DrYqmHcjkU8AyyAdCZw1s1nGECTsKDw6XUtsRjUbQYB2m0+atX6U 9o+qYxOUsJkR+BFZuR9g+Lvu5vyPHGAvXuBGiK/Hxp2rZ+Gkn/ubotX3bqjQGWabLQJE BTdC9SgRAfiOCpNM0I3FnCd+Wj6AqTMwrvB24dvXlhZExAwOxPB+yB46rVP/ypHiay+B dgCfLrnvDTnBD8H170IboD7nKuz+fKZ8wWDxs0Qp6hCSrWMinSdSR2xRV6pcsmwfgw9H DO1Q== X-Gm-Message-State: ALoCoQlLq9Sj8RYA3NumBy+b6adClIa+xCCBGEuYThDsssDbvtbrj1YjLrGgnqgLIQDQd7SfxHsm MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr31401745laz.82.1427819411403; Tue, 31 Mar 2015 09:30:11 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Tue, 31 Mar 2015 09:30:11 -0700 (PDT) In-Reply-To: References:

Date: Tue, 31 Mar 2015 09:30:11 -0700 Message-ID: From: Andy Bierman To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:30:19 -0000 On Tue, Mar 31, 2015 at 8:53 AM, Michel Veillette wrote: > Hi Andy > > - About your comment " Nodes from module X that augment module Y are not = known by module Y, when module Y is compiled or deployed." > > If a data node 'y' added by module 'Y' to module 'X' create a YANG hash c= onflict, data node 'y' will need to be rehash. This don't affect YANG hash = values of the data nodes already defined by module 'X'. Sorry I responded to the comment about augment. It doesn't matter if the conflict is from an augment or a disjoint object. > > - About your comment " You seem to be suggesting that the 6TISCH WG will = control all YANG modules on a device, even modules from vendors or other SD= Os." > > This is not the case, devices are free to implement any number of YANG mo= dules needed. By creating a distinct hash space for each module, we can min= imize impacts when integrating multiple modules within a single server. > I guess if the YANG designers ran the hashes when they were written then they could make gratuitous name changes to undo hash collisions. But YANG module names tend to be 15 to 30 bytes long, which really defeats the purpose of using short identifiers. If the solution makes the names longer than they would have been without any hash, then perhaps it is not the right solution. > - About your comment " Most deployment scenarios allow for the vendor to = select the set of modules that are supported by a device. YANG is designed = to be modular and extensible, without requiring a single, centralized namin= g authority." > > The intent is to reinforce this model and improve its scalability. > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > Andy > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: 31 mars 2015 11:29 > To: Michel Veillette > Cc: Thomas Watteyne; 6tisch@ietf.org; core@ietf.org > Subject: Re: [core] COMI hash values globally unique vs. unique within a = module > > On Tue, Mar 31, 2015 at 7:50 AM, Michel Veillette wrote: >> Hi Andy >> >> The intent is not to reduce the number of collisions but make these coll= isions predictable and uniform within a population of devices independently= of the number of modules implemented by them. This is especially important= in distributed applications such 6TiSH timeslot management. In such applic= ations, each constrained device need to interact with multiple other constr= ained devices using CoMI. With the current YANG hash approach, each constra= ined device need to retrieve and maintain the rehash list for each peer. >> >> If the scope of YANG hash is reduced to the module level (data nodes def= ined by a module + data nodes added to that module by the augment statement= ), collisions within this module can be determined based of the YAND defini= tion of this module and specific rehash values can be mandated or recommend= ed if needed. >> > > > Nodes from module X that augment module Y are not known by module Y, when= module Y is compiled or deployed. > > You seem to be suggesting that the 6TISCH WG will control all YANG module= s on a device, even modules from vendors or other SDOs. > > Most deployment scenarios allow for the vendor to select the set of modul= es that are supported by a device. YANG is designed to be modular and exten= sible, without requiring a single, centralized naming authority. > > >> Michel Veillette > > Andy > > >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> michel.veillette@trilliantinc.com >> www.trilliantinc.com >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: 31 mars 2015 09:30 >> To: Thomas Watteyne >> Cc: 6tisch@ietf.org; core@ietf.org >> Subject: Re: [core] COMI hash values globally unique vs. unique within >> a module >> >> On Tue, Mar 31, 2015 at 12:15 AM, Thomas Watteyne wrote: >>> [adding 6TiSCH] >>> >>> Andy, >>> >>> I believe the issue Michel highlights is that the hash collisions >>> depends on the modules that are implemented in the CoMI endpoint. >>> >> >> But hash collisions can occur within a module or across modules. >> Allowing collisions across modules does not change the probability of a = collision. It does not remove the need to check for a collision. >> >> What problem are you trying to solve? >> If it is to remove the possibility of a collision ever occurring then ke= ep trying. Why is it better to change the scope of the object hash to be p= er module name? >> >> The goal of the YANG hash is to lower the identifier size to a 4 byte nu= mber. Adding the 10 - 20 byte module name to every identifier really doesn= 't help lower the identifier size at all. >> >> >> Andy >> >> >> >>> That is, if nodeA implements the [/6t,/foo] modules, and nodeB the >>> [/6t,/bar] modules, the hash collisions can be different, even in the >>> same "6t" module. In the case of 6top, the YANG model describes the >>> module completely. It would be awfully nice to be able to just rely >>> on that YANG model to predict the hash collisions within that >>> module.without having to discover the rehash-map on a server each time. >>> >>> IIRC, today, a client accessing any resource using CoMI needs to >>> first retrieve the hash-map? The client needs to do this for each >>> node is manages, potentially periodically if new modules are added on-t= he-fly? >>> This seems like a lot of uncessary overhead. >>> >>> One way could be fr the server to return some error code when the >>> client accesses a resource with a hash that is ambiguous. >>> >>> Your insight on this is very welcome. >>> >>> Thomas >>> >>> On Tue, Mar 31, 2015 at 3:46 AM, Andy Bierman wrot= e: >>>> >>>> On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette >>>> wrote: >>>> > Currently, CoMI object identifiers (YANG hash) are globally unique >>>> > within a CoMI server. Devices implementing different set of >>>> > modules may have different YANG hash conflicts and may have a >>>> > different set of object identifiers affected by rehash. In an >>>> > application like 6TiSH, this means that the list of rehash values >>>> > can't be known in advance based on the published YANG module, >>>> > rehash values need to be discover and manage by each node involved i= n the timeslots reservation process. >>>> > >>>> > Reducing the scope of the YANG hash to the context of a single >>>> > module (data nodes defined by a module + data nodes added to that >>>> > module by the augment statement) can mitigate this issue. The >>>> > question is how this can be accomplished and if the overhead require= d make this change acceptable. >>>> > >>>> >>>> I don't think this will work. >>>> The probability of collisions is the same whether 100 objects are >>>> defined in 1 module or 10 objects are defined in each of 10 modules. >>>> >>>> The client must implement the rehash algorithm even though there is >>>> a low probability it will be used. >>>> >>>> >>>> Andy >>>> >>>> >>>> > Impacts on the URI >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > Currently, the CoAP path consist of: >>>> > "/mg/" >>>> > >>>> > Considering that the YANG hash is unique only within the context >>>> > of a module, the CoAP path needs to include the module name: >>>> > "/mg/data" or >>>> > "/mg/data/: " >>>> > >>>> > Impacts on the CBOR content >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>>> > If the CoAP path target a specific module (e.g. "/mg/data/: >>>> > "), the current CBOR encoding rules should apply unmodif= ied. >>>> > >>>> > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI >>>> > objects need to be associated to their respective module context. >>>> > A CBOR map added to the root of the CBOR object can be used to estab= lish this relationship. >>>> > >>>> > For example >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > Assuming: >>>> > - hash of "/6top:CellList" =3D 0x3470d0c5, base64 "0cNDF" >>>> > - hash of "/6top:CellList/6top:CellID" =3D 0x2a33a8b4 >>>> > - hash of "/6top:CellList/6top:SlotframeI" =3D 0xfe4ad55 >>>> > - hash of "/6top:CellList/6top:SlotOffset" =3D 0x2515e82f >>>> > - hash of "/6top:CellList/6top:ChannelOffset" =3D 0x9c2f821, base64 >>>> > "Jwvgh" >>>> > - hash of "/6top:CellList/6top:LinkOption" =3D 0x5057e17 >>>> > - hash of "/6top:CellList/6top:LinkType" =3D 0xd2a79e8 >>>> > - hash of "/6top:CellList/6top:CellType" =3D 0x26e3537 >>>> > - hash of "/6top:CellList/6top:TargetNodeAddress" =3D 0x2efea0b3 >>>> > - hash of "/6top:CellList/6top:TrackID" =3D 0x1e32edaf >>>> > >>>> > The "/6top:CellList/6top:ChannelOffset" data node can be requested >>>> > as >>>> > follow: >>>> > >>>> > REQ: GET example.com/mg/data/6top:Jwvgh >>>> > >>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>> > { >>>> > 0x9c2f821 : 5 >>>> > } >>>> > >>>> > The content of the "/6top:CellList" list can be requested as follow= : >>>> > >>>> > REQ: GET example.com/mg/data/6top:0cNDF >>>> > >>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>> > { >>>> > 0x3470d0c5 : [ >>>> > { >>>> > 0x2a33a8b4 : 1, >>>> > 0xfe4ad55 : 1, >>>> > 0x2515e82f : 1, >>>> > 0x9c2f821 : 1, >>>> > 0x5057e17 : "Transmit,Timekeeping", >>>> > 0xd2a79e8 : 0, >>>> > 0x26e3537 : 1, >>>> > 0x2efea0b3 : h'0102030000112233', >>>> > 0x1e32edaf : 1 >>>> > } >>>> > ] >>>> > } >>>> > >>>> > And the content of the datastore can be requested as follow: >>>> > >>>> > REQ: GET example.com/mg/data >>>> > >>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>> > { >>>> > "6top" : { >>>> > 0x3470d0c5 : [ >>>> > { >>>> > 0x2a33a8b4 : 1, >>>> > 0xfe4ad55 : 1, >>>> > 0x2515e82f : 1, >>>> > 0x9c2f821 : 1, >>>> > 0x5057e17 : "Transmit,Timekeeping", >>>> > 0xd2a79e8 : 0, >>>> > 0x26e3537 : 1, >>>> > 0x2efea0b3 : h'0102030000112233', >>>> > 0x1e32edaf : 1 >>>> > } >>>> > ] >>>> > }, >>>> > "IP-MIB" : { >>>> > 0x30b7bc3f : { >>>> > 0x1067f289 : [ >>>> > { >>>> > 0x00d38564 : 1, >>>> > 0x2745e222 : "ipv4", >>>> > 0x387804eb : "10.0.0.51", >>>> > 0x1a51514a : "00:00:10:01:23:45", >>>> > 0x03f95578 : "2333943", >>>> > 0x24ade115 : "static", >>>> > 0x09e640ef : "reachable", >>>> > 0x3b5c1ab6 : "active" >>>> > }, >>>> > { >>>> > 0x00d38564 : 1, >>>> > 0x2745e222 : "ipv4", >>>> > 0x387804eb : "9.2.3.4", >>>> > 0x1a51514a : "00:00:10:54:32:10", >>>> > 0x03f95578 : "2329836", >>>> > 0x24ade115 : "dynamic", >>>> > 0x09e640ef : "unknown", >>>> > 0x3b5c1ab6 : "active" >>>> > } >>>> > ] >>>> > } >>>> > } >>>> > } >>>> > >>>> > Is it a real issue and is it a viable solution? >>>> > >>>> > Michel Veillette >>>> > System Architecture Director >>>> > Trilliant Inc. >>>> > Tel: 450-375-0556 ext. 237 >>>> > michel.veillette@trilliantinc.com >>>> > www.trilliantinc.com >>>> > >>>> > >>>> > _______________________________________________ >>>> > core mailing list >>>> > core@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/core >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 31 09:43:07 2015 Return-Path: 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 BBB891A0318; Tue, 31 Mar 2015 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ndtVpc0dfTBk; Tue, 31 Mar 2015 09:43:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3291A0262; Tue, 31 Mar 2015 09:43:02 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB791.namprd06.prod.outlook.com (10.141.247.143) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 31 Mar 2015 16:42:43 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0112.000; Tue, 31 Mar 2015 16:42:43 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] COMI hash values globally unique vs. unique within a module Thread-Index: AQHQa8dtRg20MVrYfEyNSmCW5DT13502uKlQgAAPsoCAAADjoA== Date: Tue, 31 Mar 2015 16:42:42 +0000 Message-ID: References:

In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.96.192.122] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB791; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(38414003)(13464003)(51704005)(377454003)(77156002)(50986999)(19580395003)(15975445007)(46102003)(86362001)(77096005)(575784001)(74316001)(33656002)(87936001)(76176999)(110136001)(66066001)(102836002)(19580405001)(99286002)(106116001)(92566002)(2950100001)(15974865002)(40100003)(62966003)(93886004)(122556002)(54356999)(2656002)(76576001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0601MB791; H:CO2PR0601MB792.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR0601MB791; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB791; x-forefront-prvs: 0532BF6DC2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 16:42:42.7438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB791 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:43:06 -0000 SGkgQW5keQ0KDQo+IEJ1dCBZQU5HIG1vZHVsZSBuYW1lcyB0ZW5kIHRvIGJlIDE1IHRvIDMwIGJ5 dGVzIGxvbmcsIHdoaWNoIHJlYWxseSBkZWZlYXRzIHRoZSBwdXJwb3NlDQo+ICBvZiB1c2luZyBz aG9ydCBpZGVudGlmaWVycy4gIElmIHRoZSBzb2x1dGlvbiBtYWtlcyB0aGUgbmFtZXMgbG9uZ2Vy IHRoYW4gdGhleSB3b3VsZCBoYXZlIGJlZW4NCj4gd2l0aG91dCBhbnkgaGFzaCwgdGhlbiBwZXJo YXBzIGl0IGlzIG5vdCB0aGUgcmlnaHQgc29sdXRpb24uDQoNCkkgYWdyZWUgdGhlcmUgaXMgYW4g aW1wYWN0IGJ1dCB0aGlzIGltcGFjdCBzZWVtIGxpbWl0ZWQuDQoNCkZvciBhIHNpbmdsZSBkYXRh IG5vZGUgYWNjZXNzLCB0aGUgb3ZlcmhlYWQgY29uc2lzdCBvZiBhZGRpbmcgdGhlIG1vZHVsZSBu YW1lIG9uY2UgaW4gdGhlIFVSSS4NCg0KUkVROiBHRVQgZXhhbXBsZS5jb20vbWcvZGF0YS82dG9w OjBjTkRGDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANClJFUzogMi4w NSBDb250ZW50IChDb250ZW50LUZvcm1hdDogYXBwbGljYXRpb24vY2JvcikNCnsNCiAgMHgzNDcw ZDBjNSA6IFsNCiAgICB7DQogICAgICAweDJhMzNhOGI0IDogMSwNCiAgICAgIDB4ZmU0YWQ1NSA6 IDEsDQogICAgICAweDI1MTVlODJmIDogMSwNCiAgICAgIDB4OWMyZjgyMSA6IDEsDQogICAgICAw eDUwNTdlMTcgOiAiVHJhbnNtaXQsVGltZWtlZXBpbmciLA0KICAgICAgMHhkMmE3OWU4IDogMCwN CiAgICAgIDB4MjZlMzUzNyA6IDEsDQogICAgICAweDJlZmVhMGIzIDogaCcwMTAyMDMwMDAwMTEy MjMzJywNCiAgICAgIDB4MWUzMmVkYWYgOiAxDQogICAgfQ0KICBdDQp9DQoNCkZvciBhIGNvbXBs ZXRlIGRhdGFzdG9yZSBhY2Nlc3MsIHRoZSBvdmVyaGVhZCBjb25zaXN0IG9mIGFkZGluZyBlYWNo IG1vZHVsZSBuYW1lIG9uY2UgaW4gYSBDQk9SIG1hcC4NCg0KUkVROiBHRVQgZXhhbXBsZS5jb20v bWcvZGF0YQ0KDQpSRVM6IDIuMDUgQ29udGVudCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9u L2Nib3IpDQp7DQogICI2dG9wIiA6IHsNCiAgICAweDM0NzBkMGM1IDogWw0KICAgICAgew0KICAg ICAgICAweDJhMzNhOGI0IDogMSwNCiAgICAgICAgMHhmZTRhZDU1IDogMSwNCiAgICAgICAgMHgy NTE1ZTgyZiA6IDEsDQogICAgICAgIDB4OWMyZjgyMSA6IDEsDQogICAgICAgIDB4NTA1N2UxNyA6 ICJUcmFuc21pdCxUaW1la2VlcGluZyIsDQogICAgICAgIDB4ZDJhNzllOCA6IDAsDQogICAgICAg IDB4MjZlMzUzNyA6IDEsDQogICAgICAgIDB4MmVmZWEwYjMgOiBoJzAxMDIwMzAwMDAxMTIyMzMn LA0KICAgICAgICAweDFlMzJlZGFmIDogMQ0KICAgICAgfQ0KICAgIF0NCiAgfSwNCiAgIklQLU1J QiIgOiB7DQogICAgMHgzMGI3YmMzZiA6IHsNCiAgICAgIDB4MTA2N2YyODkgOiBbDQogICAgICAg IHsNCiAgICAgICAgICAweDAwZDM4NTY0IDogMSwNCiAgICAgICAgICAweDI3NDVlMjIyIDogImlw djQiLA0KICAgICAgICAgIDB4Mzg3ODA0ZWIgOiAiMTAuMC4wLjUxIiwNCiAgICAgICAgICAweDFh NTE1MTRhIDogIjAwOjAwOjEwOjAxOjIzOjQ1IiwNCiAgICAgICAgICAweDAzZjk1NTc4IDogIjIz MzM5NDMiLA0KICAgICAgICAgIDB4MjRhZGUxMTUgOiAic3RhdGljIiwNCiAgICAgICAgICAweDA5 ZTY0MGVmIDogInJlYWNoYWJsZSIsDQogICAgICAgICAgMHgzYjVjMWFiNiA6ICJhY3RpdmUiDQog ICAgICAgIH0sDQogICAgICAgIHsNCiAgICAgICAgICAweDAwZDM4NTY0IDogMSwNCiAgICAgICAg ICAweDI3NDVlMjIyIDogImlwdjQiLA0KICAgICAgICAgIDB4Mzg3ODA0ZWIgOiAiOS4yLjMuNCIs DQogICAgICAgICAgMHgxYTUxNTE0YSA6ICIwMDowMDoxMDo1NDozMjoxMCIsDQogICAgICAgICAg MHgwM2Y5NTU3OCA6ICIyMzI5ODM2IiwNCiAgICAgICAgICAweDI0YWRlMTE1IDogImR5bmFtaWMi LA0KICAgICAgICAgIDB4MDllNjQwZWYgOiAidW5rbm93biIsDQogICAgICAgICAgMHgzYjVjMWFi NiA6ICJhY3RpdmUiDQogICAgICAgIH0NCiAgICAgIF0NCiAgICB9DQogIH0NCn0NCg0KTWljaGVs IFZlaWxsZXR0ZQ0KU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0KVHJpbGxpYW50IEluYy4N ClRlbDogNDUwLTM3NS0wNTU2IGV4dC4gMjM3DQptaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudGlu Yy5jb20NCnd3dy50cmlsbGlhbnRpbmMuY29tIMKgIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dIA0K U2VudDogMzEgbWFycyAyMDE1IDEyOjMwDQpUbzogTWljaGVsIFZlaWxsZXR0ZQ0KQ2M6IFRob21h cyBXYXR0ZXluZTsgNnRpc2NoQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W2NvcmVdIENPTUkgaGFzaCB2YWx1ZXMgZ2xvYmFsbHkgdW5pcXVlIHZzLiB1bmlxdWUgd2l0aGlu IGEgbW9kdWxlDQoNCk9uIFR1ZSwgTWFyIDMxLCAyMDE1IGF0IDg6NTMgQU0sIE1pY2hlbCBWZWls bGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4gd3JvdGU6DQo+IEhpIEFu ZHkNCj4NCj4gLSBBYm91dCB5b3VyIGNvbW1lbnQgIiBOb2RlcyBmcm9tIG1vZHVsZSBYIHRoYXQg YXVnbWVudCBtb2R1bGUgWSBhcmUgbm90IGtub3duIGJ5IG1vZHVsZSBZLCB3aGVuIG1vZHVsZSBZ IGlzIGNvbXBpbGVkIG9yIGRlcGxveWVkLiINCj4NCj4gSWYgYSBkYXRhIG5vZGUgJ3knIGFkZGVk IGJ5IG1vZHVsZSAnWScgdG8gbW9kdWxlICdYJyBjcmVhdGUgYSBZQU5HIGhhc2ggY29uZmxpY3Qs IGRhdGEgbm9kZSAneScgd2lsbCBuZWVkIHRvIGJlIHJlaGFzaC4gVGhpcyBkb24ndCBhZmZlY3Qg WUFORyBoYXNoIHZhbHVlcyBvZiB0aGUgZGF0YSBub2RlcyBhbHJlYWR5IGRlZmluZWQgYnkgbW9k dWxlICdYJy4NCg0KU29ycnkgSSByZXNwb25kZWQgdG8gdGhlIGNvbW1lbnQgYWJvdXQgYXVnbWVu dC4NCkl0IGRvZXNuJ3QgbWF0dGVyIGlmIHRoZSBjb25mbGljdCBpcyBmcm9tIGFuIGF1Z21lbnQg b3IgYSBkaXNqb2ludCBvYmplY3QuDQoNCj4NCj4gLSBBYm91dCB5b3VyIGNvbW1lbnQgIiBZb3Ug c2VlbSB0byBiZSBzdWdnZXN0aW5nIHRoYXQgdGhlIDZUSVNDSCBXRyB3aWxsIGNvbnRyb2wgYWxs IFlBTkcgbW9kdWxlcyBvbiBhIGRldmljZSwgZXZlbiBtb2R1bGVzIGZyb20gdmVuZG9ycyBvciBv dGhlciBTRE9zLiINCj4NCj4gVGhpcyBpcyBub3QgdGhlIGNhc2UsIGRldmljZXMgYXJlIGZyZWUg dG8gaW1wbGVtZW50IGFueSBudW1iZXIgb2YgWUFORyBtb2R1bGVzIG5lZWRlZC4gQnkgY3JlYXRp bmcgYSBkaXN0aW5jdCBoYXNoIHNwYWNlIGZvciBlYWNoIG1vZHVsZSwgd2UgY2FuIG1pbmltaXpl IGltcGFjdHMgd2hlbiBpbnRlZ3JhdGluZyBtdWx0aXBsZSBtb2R1bGVzIHdpdGhpbiBhIHNpbmds ZSBzZXJ2ZXIuDQo+DQoNCkkgZ3Vlc3MgaWYgdGhlIFlBTkcgZGVzaWduZXJzIHJhbiB0aGUgaGFz aGVzIHdoZW4gdGhleSB3ZXJlIHdyaXR0ZW4gdGhlbiB0aGV5IGNvdWxkIG1ha2UgZ3JhdHVpdG91 cyBuYW1lIGNoYW5nZXMgdG8gdW5kbyBoYXNoIGNvbGxpc2lvbnMuDQoNCkJ1dCBZQU5HIG1vZHVs ZSBuYW1lcyB0ZW5kIHRvIGJlIDE1IHRvIDMwIGJ5dGVzIGxvbmcsIHdoaWNoIHJlYWxseSBkZWZl YXRzIHRoZSBwdXJwb3NlIG9mIHVzaW5nIHNob3J0IGlkZW50aWZpZXJzLiAgSWYgdGhlIHNvbHV0 aW9uIG1ha2VzIHRoZSBuYW1lcyBsb25nZXIgdGhhbiB0aGV5IHdvdWxkIGhhdmUgYmVlbiB3aXRo b3V0IGFueSBoYXNoLCB0aGVuIHBlcmhhcHMgaXQgaXMgbm90IHRoZSByaWdodCBzb2x1dGlvbi4N Cg0KDQoNCj4gLSBBYm91dCB5b3VyIGNvbW1lbnQgIiBNb3N0IGRlcGxveW1lbnQgc2NlbmFyaW9z IGFsbG93IGZvciB0aGUgdmVuZG9yIHRvIHNlbGVjdCB0aGUgc2V0IG9mIG1vZHVsZXMgdGhhdCBh cmUgc3VwcG9ydGVkIGJ5IGEgZGV2aWNlLiBZQU5HIGlzIGRlc2lnbmVkIHRvIGJlIG1vZHVsYXIg YW5kIGV4dGVuc2libGUsIHdpdGhvdXQgcmVxdWlyaW5nIGEgc2luZ2xlLCBjZW50cmFsaXplZCBu YW1pbmcgYXV0aG9yaXR5LiINCj4NCj4gVGhlIGludGVudCBpcyB0byByZWluZm9yY2UgdGhpcyBt b2RlbCBhbmQgaW1wcm92ZSBpdHMgc2NhbGFiaWxpdHkuDQo+DQo+IE1pY2hlbCBWZWlsbGV0dGUN Cj4gU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0KPiBUcmlsbGlhbnQgSW5jLg0KPiBUZWw6 IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KPiBtaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudGluYy5j b20NCj4gd3d3LnRyaWxsaWFudGluYy5jb20NCj4NCj4NCg0KQW5keQ0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbV0NCj4gU2VudDogMzEgbWFycyAyMDE1IDExOjI5DQo+IFRvOiBNaWNoZWwgVmVpbGxl dHRlDQo+IENjOiBUaG9tYXMgV2F0dGV5bmU7IDZ0aXNjaEBpZXRmLm9yZzsgY29yZUBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIENPTUkgaGFzaCB2YWx1ZXMgZ2xvYmFsbHkgdW5pcXVl IHZzLiB1bmlxdWUgd2l0aGluIA0KPiBhIG1vZHVsZQ0KPg0KPiBPbiBUdWUsIE1hciAzMSwgMjAx NSBhdCA3OjUwIEFNLCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dGluYy5jb20+IHdyb3RlOg0KPj4gSGkgQW5keQ0KPj4NCj4+IFRoZSBpbnRlbnQgaXMgbm90IHRv IHJlZHVjZSB0aGUgbnVtYmVyIG9mIGNvbGxpc2lvbnMgYnV0IG1ha2UgdGhlc2UgY29sbGlzaW9u cyBwcmVkaWN0YWJsZSBhbmQgdW5pZm9ybSB3aXRoaW4gYSBwb3B1bGF0aW9uIG9mIGRldmljZXMg aW5kZXBlbmRlbnRseSBvZiB0aGUgbnVtYmVyIG9mIG1vZHVsZXMgaW1wbGVtZW50ZWQgYnkgdGhl bS4gVGhpcyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBpbiBkaXN0cmlidXRlZCBhcHBsaWNhdGlv bnMgc3VjaCA2VGlTSCB0aW1lc2xvdCBtYW5hZ2VtZW50LiBJbiBzdWNoIGFwcGxpY2F0aW9ucywg ZWFjaCBjb25zdHJhaW5lZCBkZXZpY2UgbmVlZCB0byBpbnRlcmFjdCB3aXRoIG11bHRpcGxlIG90 aGVyIGNvbnN0cmFpbmVkIGRldmljZXMgdXNpbmcgQ29NSS4gV2l0aCB0aGUgY3VycmVudCBZQU5H IGhhc2ggYXBwcm9hY2gsIGVhY2ggY29uc3RyYWluZWQgZGV2aWNlIG5lZWQgdG8gcmV0cmlldmUg YW5kIG1haW50YWluIHRoZSByZWhhc2ggbGlzdCBmb3IgZWFjaCBwZWVyLg0KPj4NCj4+IElmIHRo ZSBzY29wZSBvZiBZQU5HIGhhc2ggaXMgcmVkdWNlZCB0byB0aGUgbW9kdWxlIGxldmVsIChkYXRh IG5vZGVzIGRlZmluZWQgYnkgYSBtb2R1bGUgKyBkYXRhIG5vZGVzIGFkZGVkIHRvIHRoYXQgbW9k dWxlIGJ5IHRoZSBhdWdtZW50IHN0YXRlbWVudCksIGNvbGxpc2lvbnMgd2l0aGluIHRoaXMgbW9k dWxlIGNhbiBiZSBkZXRlcm1pbmVkIGJhc2VkIG9mIHRoZSBZQU5EIGRlZmluaXRpb24gb2YgdGhp cyBtb2R1bGUgYW5kIHNwZWNpZmljIHJlaGFzaCB2YWx1ZXMgY2FuIGJlIG1hbmRhdGVkIG9yIHJl Y29tbWVuZGVkIGlmIG5lZWRlZC4NCj4+DQo+DQo+DQo+IE5vZGVzIGZyb20gbW9kdWxlIFggdGhh dCBhdWdtZW50IG1vZHVsZSBZIGFyZSBub3Qga25vd24gYnkgbW9kdWxlIFksIHdoZW4gbW9kdWxl IFkgaXMgY29tcGlsZWQgb3IgZGVwbG95ZWQuDQo+DQo+IFlvdSBzZWVtIHRvIGJlIHN1Z2dlc3Rp bmcgdGhhdCB0aGUgNlRJU0NIIFdHIHdpbGwgY29udHJvbCBhbGwgWUFORyBtb2R1bGVzIG9uIGEg ZGV2aWNlLCBldmVuIG1vZHVsZXMgZnJvbSB2ZW5kb3JzIG9yIG90aGVyIFNET3MuDQo+DQo+IE1v c3QgZGVwbG95bWVudCBzY2VuYXJpb3MgYWxsb3cgZm9yIHRoZSB2ZW5kb3IgdG8gc2VsZWN0IHRo ZSBzZXQgb2YgbW9kdWxlcyB0aGF0IGFyZSBzdXBwb3J0ZWQgYnkgYSBkZXZpY2UuIFlBTkcgaXMg ZGVzaWduZWQgdG8gYmUgbW9kdWxhciBhbmQgZXh0ZW5zaWJsZSwgd2l0aG91dCByZXF1aXJpbmcg YSBzaW5nbGUsIGNlbnRyYWxpemVkIG5hbWluZyBhdXRob3JpdHkuDQo+DQo+DQo+PiBNaWNoZWwg VmVpbGxldHRlDQo+DQo+IEFuZHkNCj4NCj4NCj4+IFN5c3RlbSBBcmNoaXRlY3R1cmUgRGlyZWN0 b3INCj4+IFRyaWxsaWFudCBJbmMuDQo+PiBUZWw6IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KPj4g bWljaGVsLnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tDQo+PiB3d3cudHJpbGxpYW50aW5jLmNv bQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjb3JlIFttYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQo+PiBT ZW50OiAzMSBtYXJzIDIwMTUgMDk6MzANCj4+IFRvOiBUaG9tYXMgV2F0dGV5bmUNCj4+IENjOiA2 dGlzY2hAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ09N SSBoYXNoIHZhbHVlcyBnbG9iYWxseSB1bmlxdWUgdnMuIHVuaXF1ZSANCj4+IHdpdGhpbiBhIG1v ZHVsZQ0KPj4NCj4+IE9uIFR1ZSwgTWFyIDMxLCAyMDE1IGF0IDEyOjE1IEFNLCBUaG9tYXMgV2F0 dGV5bmUgPHdhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PiB3cm90ZToNCj4+PiBbYWRkaW5nIDZU aVNDSF0NCj4+Pg0KPj4+IEFuZHksDQo+Pj4NCj4+PiBJIGJlbGlldmUgdGhlIGlzc3VlIE1pY2hl bCBoaWdobGlnaHRzIGlzIHRoYXQgdGhlIGhhc2ggY29sbGlzaW9ucyANCj4+PiBkZXBlbmRzIG9u IHRoZSBtb2R1bGVzIHRoYXQgYXJlIGltcGxlbWVudGVkIGluIHRoZSBDb01JIGVuZHBvaW50Lg0K Pj4+DQo+Pg0KPj4gQnV0IGhhc2ggY29sbGlzaW9ucyBjYW4gb2NjdXIgd2l0aGluIGEgbW9kdWxl IG9yIGFjcm9zcyBtb2R1bGVzLg0KPj4gQWxsb3dpbmcgY29sbGlzaW9ucyBhY3Jvc3MgbW9kdWxl cyBkb2VzIG5vdCBjaGFuZ2UgdGhlIHByb2JhYmlsaXR5IG9mIGEgY29sbGlzaW9uLiAgSXQgZG9l cyBub3QgcmVtb3ZlIHRoZSBuZWVkIHRvIGNoZWNrIGZvciBhIGNvbGxpc2lvbi4NCj4+DQo+PiBX aGF0IHByb2JsZW0gYXJlIHlvdSB0cnlpbmcgdG8gc29sdmU/DQo+PiBJZiBpdCBpcyB0byByZW1v dmUgdGhlIHBvc3NpYmlsaXR5IG9mIGEgY29sbGlzaW9uIGV2ZXIgb2NjdXJyaW5nIHRoZW4ga2Vl cCB0cnlpbmcuICBXaHkgaXMgaXQgYmV0dGVyIHRvIGNoYW5nZSB0aGUgc2NvcGUgb2YgdGhlIG9i amVjdCBoYXNoIHRvIGJlIHBlciBtb2R1bGUgbmFtZT8NCj4+DQo+PiBUaGUgZ29hbCBvZiB0aGUg WUFORyBoYXNoIGlzIHRvIGxvd2VyIHRoZSBpZGVudGlmaWVyIHNpemUgdG8gYSA0IGJ5dGUgbnVt YmVyLiAgQWRkaW5nIHRoZSAxMCAtIDIwIGJ5dGUgbW9kdWxlIG5hbWUgdG8gZXZlcnkgaWRlbnRp ZmllciByZWFsbHkgZG9lc24ndCBoZWxwIGxvd2VyIHRoZSBpZGVudGlmaWVyIHNpemUgYXQgYWxs Lg0KPj4NCj4+DQo+PiBBbmR5DQo+Pg0KPj4NCj4+DQo+Pj4gVGhhdCBpcywgaWYgbm9kZUEgaW1w bGVtZW50cyB0aGUgWy82dCwvZm9vXSBtb2R1bGVzLCBhbmQgbm9kZUIgdGhlIA0KPj4+IFsvNnQs L2Jhcl0gbW9kdWxlcywgdGhlIGhhc2ggY29sbGlzaW9ucyBjYW4gYmUgZGlmZmVyZW50LCBldmVu IGluIA0KPj4+IHRoZSBzYW1lICI2dCIgbW9kdWxlLiBJbiB0aGUgY2FzZSBvZiA2dG9wLCB0aGUg WUFORyBtb2RlbCBkZXNjcmliZXMgDQo+Pj4gdGhlIG1vZHVsZSBjb21wbGV0ZWx5LiBJdCB3b3Vs ZCBiZSBhd2Z1bGx5IG5pY2UgdG8gYmUgYWJsZSB0byBqdXN0IA0KPj4+IHJlbHkgb24gdGhhdCBZ QU5HIG1vZGVsIHRvIHByZWRpY3QgdGhlIGhhc2ggY29sbGlzaW9ucyB3aXRoaW4gdGhhdCANCj4+ PiBtb2R1bGUud2l0aG91dCBoYXZpbmcgdG8gZGlzY292ZXIgdGhlIHJlaGFzaC1tYXAgb24gYSBz ZXJ2ZXIgZWFjaCB0aW1lLg0KPj4+DQo+Pj4gSUlSQywgdG9kYXksIGEgY2xpZW50IGFjY2Vzc2lu ZyBhbnkgcmVzb3VyY2UgdXNpbmcgQ29NSSBuZWVkcyB0byANCj4+PiBmaXJzdCByZXRyaWV2ZSB0 aGUgaGFzaC1tYXA/IFRoZSBjbGllbnQgbmVlZHMgdG8gZG8gdGhpcyBmb3IgZWFjaCANCj4+PiBu b2RlIGlzIG1hbmFnZXMsIHBvdGVudGlhbGx5IHBlcmlvZGljYWxseSBpZiBuZXcgbW9kdWxlcyBh cmUgYWRkZWQgb24tdGhlLWZseT8NCj4+PiBUaGlzIHNlZW1zIGxpa2UgYSBsb3Qgb2YgdW5jZXNz YXJ5IG92ZXJoZWFkLg0KPj4+DQo+Pj4gT25lIHdheSBjb3VsZCBiZSBmciB0aGUgc2VydmVyIHRv IHJldHVybiBzb21lIGVycm9yIGNvZGUgd2hlbiB0aGUgDQo+Pj4gY2xpZW50IGFjY2Vzc2VzIGEg cmVzb3VyY2Ugd2l0aCBhIGhhc2ggdGhhdCBpcyBhbWJpZ3VvdXMuDQo+Pj4NCj4+PiBZb3VyIGlu c2lnaHQgb24gdGhpcyBpcyB2ZXJ5IHdlbGNvbWUuDQo+Pj4NCj4+PiBUaG9tYXMNCj4+Pg0KPj4+ IE9uIFR1ZSwgTWFyIDMxLCAyMDE1IGF0IDM6NDYgQU0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1h d29ya3MuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4gT24gTW9uLCBNYXIgMzAsIDIwMTUgYXQgMTI6 NDMgUE0sIE1pY2hlbCBWZWlsbGV0dGUgDQo+Pj4+IDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFu dGluYy5jb20+IHdyb3RlOg0KPj4+PiA+IEN1cnJlbnRseSwgQ29NSSBvYmplY3QgaWRlbnRpZmll cnMgKFlBTkcgaGFzaCkgYXJlIGdsb2JhbGx5IA0KPj4+PiA+IHVuaXF1ZSB3aXRoaW4gYSBDb01J IHNlcnZlci4gRGV2aWNlcyBpbXBsZW1lbnRpbmcgZGlmZmVyZW50IHNldCANCj4+Pj4gPiBvZiBt b2R1bGVzIG1heSBoYXZlIGRpZmZlcmVudCBZQU5HIGhhc2ggY29uZmxpY3RzIGFuZCBtYXkgaGF2 ZSBhIA0KPj4+PiA+IGRpZmZlcmVudCBzZXQgb2Ygb2JqZWN0IGlkZW50aWZpZXJzIGFmZmVjdGVk IGJ5IHJlaGFzaC4gSW4gYW4gDQo+Pj4+ID4gYXBwbGljYXRpb24gbGlrZSA2VGlTSCwgdGhpcyBt ZWFucyB0aGF0IHRoZSBsaXN0IG9mIHJlaGFzaCB2YWx1ZXMgDQo+Pj4+ID4gY2FuJ3QgYmUga25v d24gaW4gYWR2YW5jZSBiYXNlZCBvbiB0aGUgcHVibGlzaGVkIFlBTkcgbW9kdWxlLCANCj4+Pj4g PiByZWhhc2ggdmFsdWVzIG5lZWQgdG8gYmUgZGlzY292ZXIgYW5kIG1hbmFnZSBieSBlYWNoIG5v ZGUgaW52b2x2ZWQgaW4gdGhlIHRpbWVzbG90cyByZXNlcnZhdGlvbiBwcm9jZXNzLg0KPj4+PiA+ DQo+Pj4+ID4gUmVkdWNpbmcgdGhlIHNjb3BlIG9mIHRoZSBZQU5HIGhhc2ggdG8gdGhlIGNvbnRl eHQgb2YgYSBzaW5nbGUgDQo+Pj4+ID4gbW9kdWxlIChkYXRhIG5vZGVzIGRlZmluZWQgYnkgYSBt b2R1bGUgKyBkYXRhIG5vZGVzIGFkZGVkIHRvIHRoYXQgDQo+Pj4+ID4gbW9kdWxlIGJ5IHRoZSBh dWdtZW50IHN0YXRlbWVudCkgY2FuIG1pdGlnYXRlIHRoaXMgaXNzdWUuIFRoZSANCj4+Pj4gPiBx dWVzdGlvbiBpcyBob3cgdGhpcyBjYW4gYmUgYWNjb21wbGlzaGVkIGFuZCBpZiB0aGUgb3Zlcmhl YWQgcmVxdWlyZWQgbWFrZSB0aGlzIGNoYW5nZSBhY2NlcHRhYmxlLg0KPj4+PiA+DQo+Pj4+DQo+ Pj4+IEkgZG9uJ3QgdGhpbmsgdGhpcyB3aWxsIHdvcmsuDQo+Pj4+IFRoZSBwcm9iYWJpbGl0eSBv ZiBjb2xsaXNpb25zIGlzIHRoZSBzYW1lIHdoZXRoZXIgMTAwIG9iamVjdHMgYXJlIA0KPj4+PiBk ZWZpbmVkIGluIDEgbW9kdWxlIG9yIDEwIG9iamVjdHMgYXJlIGRlZmluZWQgaW4gZWFjaCBvZiAx MCBtb2R1bGVzLg0KPj4+Pg0KPj4+PiBUaGUgY2xpZW50IG11c3QgaW1wbGVtZW50IHRoZSByZWhh c2ggYWxnb3JpdGhtIGV2ZW4gdGhvdWdoIHRoZXJlIGlzIA0KPj4+PiBhIGxvdyBwcm9iYWJpbGl0 eSBpdCB3aWxsIGJlIHVzZWQuDQo+Pj4+DQo+Pj4+DQo+Pj4+IEFuZHkNCj4+Pj4NCj4+Pj4NCj4+ Pj4gPiBJbXBhY3RzIG9uIHRoZSBVUkkNCj4+Pj4gPiA9PT09PT09PT09PT09PT0NCj4+Pj4gPiBD dXJyZW50bHksIHRoZSBDb0FQIHBhdGggY29uc2lzdCBvZjoNCj4+Pj4gPiAgIi9tZy88aGFzaC12 YWx1ZT4iDQo+Pj4+ID4NCj4+Pj4gPiBDb25zaWRlcmluZyB0aGF0IHRoZSBZQU5HIGhhc2ggaXMg dW5pcXVlIG9ubHkgd2l0aGluIHRoZSBjb250ZXh0IA0KPj4+PiA+IG9mIGEgbW9kdWxlLCB0aGUg Q29BUCBwYXRoIG5lZWRzIHRvIGluY2x1ZGUgdGhlIG1vZHVsZSBuYW1lOg0KPj4+PiA+ICIvbWcv ZGF0YSIgb3INCj4+Pj4gPiAgIi9tZy9kYXRhLzxtb2R1bGVOYW1lPjogPGhhc2gtdmFsdWU+Ig0K Pj4+PiA+DQo+Pj4+ID4gSW1wYWN0cyBvbiB0aGUgQ0JPUiBjb250ZW50DQo+Pj4+ID4gPT09PT09 PT09PT09PT09PT09PT09PT09DQo+Pj4+ID4gSWYgdGhlIENvQVAgcGF0aCB0YXJnZXQgYSBzcGVj aWZpYyBtb2R1bGUgKGUuZy4gIi9tZy9kYXRhLzxtb2R1bGVOYW1lPjoNCj4+Pj4gPiA8aGFzaC12 YWx1ZT4iKSwgdGhlIGN1cnJlbnQgQ0JPUiBlbmNvZGluZyBydWxlcyBzaG91bGQgYXBwbHkgdW5t b2RpZmllZC4NCj4+Pj4gPg0KPj4+PiA+IElmIHRoZSBDb0FQIHBhdGggdGFyZ2V0IG11bHRpcGxl IG1vZHVsZXMgKGUuZy4gIi9tZy9kYXRhIiksIENvTUkgDQo+Pj4+ID4gb2JqZWN0cyBuZWVkIHRv IGJlIGFzc29jaWF0ZWQgdG8gdGhlaXIgcmVzcGVjdGl2ZSBtb2R1bGUgY29udGV4dC4NCj4+Pj4g PiBBIENCT1IgbWFwIGFkZGVkIHRvIHRoZSByb290IG9mIHRoZSBDQk9SIG9iamVjdCBjYW4gYmUg dXNlZCB0byBlc3RhYmxpc2ggdGhpcyByZWxhdGlvbnNoaXAuDQo+Pj4+ID4NCj4+Pj4gPiBGb3Ig ZXhhbXBsZQ0KPj4+PiA+ID09PT09PT09PT0NCj4+Pj4gPiBBc3N1bWluZzoNCj4+Pj4gPiAtIGhh c2ggb2YgIi82dG9wOkNlbGxMaXN0IiA9ICAweDM0NzBkMGM1LCBiYXNlNjQgIjBjTkRGIg0KPj4+ PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpDZWxsSUQiID0gMHgyYTMzYThiNA0K Pj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpTbG90ZnJhbWVJIiA9IDB4ZmU0 YWQ1NQ0KPj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpTbG90T2Zmc2V0IiA9 IDB4MjUxNWU4MmYNCj4+Pj4gPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6Q2hhbm5l bE9mZnNldCIgPSAweDljMmY4MjEsIGJhc2U2NCANCj4+Pj4gPiAiSnd2Z2giDQo+Pj4+ID4gLSBo YXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9wOkxpbmtPcHRpb24iID0gMHg1MDU3ZTE3DQo+Pj4+ ID4gLSBoYXNoIG9mICIvNnRvcDpDZWxsTGlzdC82dG9wOkxpbmtUeXBlIiA9IDB4ZDJhNzllOA0K Pj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpDZWxsVHlwZSIgPSAweDI2ZTM1 MzcNCj4+Pj4gPiAtIGhhc2ggb2YgIi82dG9wOkNlbGxMaXN0LzZ0b3A6VGFyZ2V0Tm9kZUFkZHJl c3MiID0gMHgyZWZlYTBiMw0KPj4+PiA+IC0gaGFzaCBvZiAiLzZ0b3A6Q2VsbExpc3QvNnRvcDpU cmFja0lEIiA9IDB4MWUzMmVkYWYNCj4+Pj4gPg0KPj4+PiA+IFRoZSAiLzZ0b3A6Q2VsbExpc3Qv NnRvcDpDaGFubmVsT2Zmc2V0IiBkYXRhIG5vZGUgY2FuIGJlIA0KPj4+PiA+IHJlcXVlc3RlZCBh cw0KPj4+PiA+IGZvbGxvdzoNCj4+Pj4gPg0KPj4+PiA+ICAgUkVROiBHRVQgZXhhbXBsZS5jb20v bWcvZGF0YS82dG9wOkp3dmdoDQo+Pj4+ID4NCj4+Pj4gPiAgIFJFUzogMi4wNSBDb250ZW50IChD b250ZW50LUZvcm1hdDogYXBwbGljYXRpb24vY2JvcikNCj4+Pj4gPiAgIHsNCj4+Pj4gPiAgICAg MHg5YzJmODIxIDogNQ0KPj4+PiA+ICAgfQ0KPj4+PiA+DQo+Pj4+ID4gVGhlIGNvbnRlbnQgb2Yg dGhlICIvNnRvcDpDZWxsTGlzdCIgIGxpc3QgY2FuIGJlIHJlcXVlc3RlZCBhcyBmb2xsb3c6DQo+ Pj4+ID4NCj4+Pj4gPiAgIFJFUTogR0VUIGV4YW1wbGUuY29tL21nL2RhdGEvNnRvcDowY05ERg0K Pj4+PiA+DQo+Pj4+ID4gICBSRVM6IDIuMDUgQ29udGVudCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxp Y2F0aW9uL2Nib3IpDQo+Pj4+ID4gICB7DQo+Pj4+ID4gICAgIDB4MzQ3MGQwYzUgOiBbDQo+Pj4+ ID4gICAgICAgew0KPj4+PiA+ICAgICAgICAgMHgyYTMzYThiNCA6IDEsDQo+Pj4+ID4gICAgICAg ICAweGZlNGFkNTUgOiAxLA0KPj4+PiA+ICAgICAgICAgMHgyNTE1ZTgyZiA6IDEsDQo+Pj4+ID4g ICAgICAgICAweDljMmY4MjEgOiAxLA0KPj4+PiA+ICAgICAgICAgMHg1MDU3ZTE3IDogIlRyYW5z bWl0LFRpbWVrZWVwaW5nIiwNCj4+Pj4gPiAgICAgICAgIDB4ZDJhNzllOCA6IDAsDQo+Pj4+ID4g ICAgICAgICAweDI2ZTM1MzcgOiAxLA0KPj4+PiA+ICAgICAgICAgMHgyZWZlYTBiMyA6IGgnMDEw MjAzMDAwMDExMjIzMycsDQo+Pj4+ID4gICAgICAgICAweDFlMzJlZGFmIDogMQ0KPj4+PiA+ICAg ICAgIH0NCj4+Pj4gPiAgICAgXQ0KPj4+PiA+ICAgfQ0KPj4+PiA+DQo+Pj4+ID4gQW5kIHRoZSBj b250ZW50IG9mIHRoZSBkYXRhc3RvcmUgY2FuIGJlIHJlcXVlc3RlZCBhcyBmb2xsb3c6DQo+Pj4+ ID4NCj4+Pj4gPiAgIFJFUTogR0VUIGV4YW1wbGUuY29tL21nL2RhdGENCj4+Pj4gPg0KPj4+PiA+ ICAgUkVTOiAyLjA1IENvbnRlbnQgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNhdGlvbi9jYm9yKQ0K Pj4+PiA+ICAgew0KPj4+PiA+ICAgICAiNnRvcCIgOiB7DQo+Pj4+ID4gICAgICAgMHgzNDcwZDBj NSA6IFsNCj4+Pj4gPiAgICAgICAgIHsNCj4+Pj4gPiAgICAgICAgICAgMHgyYTMzYThiNCA6IDEs DQo+Pj4+ID4gICAgICAgICAgIDB4ZmU0YWQ1NSA6IDEsDQo+Pj4+ID4gICAgICAgICAgIDB4MjUx NWU4MmYgOiAxLA0KPj4+PiA+ICAgICAgICAgICAweDljMmY4MjEgOiAxLA0KPj4+PiA+ICAgICAg ICAgICAweDUwNTdlMTcgOiAiVHJhbnNtaXQsVGltZWtlZXBpbmciLA0KPj4+PiA+ICAgICAgICAg ICAweGQyYTc5ZTggOiAwLA0KPj4+PiA+ICAgICAgICAgICAweDI2ZTM1MzcgOiAxLA0KPj4+PiA+ ICAgICAgICAgICAweDJlZmVhMGIzIDogaCcwMTAyMDMwMDAwMTEyMjMzJywNCj4+Pj4gPiAgICAg ICAgICAgMHgxZTMyZWRhZiA6IDENCj4+Pj4gPiAgICAgICAgIH0NCj4+Pj4gPiAgICAgICBdDQo+ Pj4+ID4gICAgIH0sDQo+Pj4+ID4gICAgICJJUC1NSUIiIDogew0KPj4+PiA+ICAgICAgIDB4MzBi N2JjM2YgOiB7DQo+Pj4+ID4gICAgICAgICAweDEwNjdmMjg5IDogWw0KPj4+PiA+ICAgICAgICAg ICB7DQo+Pj4+ID4gICAgICAgICAgICAgMHgwMGQzODU2NCA6IDEsDQo+Pj4+ID4gICAgICAgICAg ICAgMHgyNzQ1ZTIyMiA6ICJpcHY0IiwNCj4+Pj4gPiAgICAgICAgICAgICAweDM4NzgwNGViIDog IjEwLjAuMC41MSIsDQo+Pj4+ID4gICAgICAgICAgICAgMHgxYTUxNTE0YSA6ICIwMDowMDoxMDow MToyMzo0NSIsDQo+Pj4+ID4gICAgICAgICAgICAgMHgwM2Y5NTU3OCA6ICIyMzMzOTQzIiwNCj4+ Pj4gPiAgICAgICAgICAgICAweDI0YWRlMTE1IDogInN0YXRpYyIsDQo+Pj4+ID4gICAgICAgICAg ICAgMHgwOWU2NDBlZiA6ICJyZWFjaGFibGUiLA0KPj4+PiA+ICAgICAgICAgICAgIDB4M2I1YzFh YjYgOiAiYWN0aXZlIg0KPj4+PiA+ICAgICAgICAgICB9LA0KPj4+PiA+ICAgICAgICAgICB7DQo+ Pj4+ID4gICAgICAgICAgICAgMHgwMGQzODU2NCA6IDEsDQo+Pj4+ID4gICAgICAgICAgICAgMHgy NzQ1ZTIyMiA6ICJpcHY0IiwNCj4+Pj4gPiAgICAgICAgICAgICAweDM4NzgwNGViIDogIjkuMi4z LjQiLA0KPj4+PiA+ICAgICAgICAgICAgIDB4MWE1MTUxNGEgOiAiMDA6MDA6MTA6NTQ6MzI6MTAi LA0KPj4+PiA+ICAgICAgICAgICAgIDB4MDNmOTU1NzggOiAiMjMyOTgzNiIsDQo+Pj4+ID4gICAg ICAgICAgICAgMHgyNGFkZTExNSA6ICJkeW5hbWljIiwNCj4+Pj4gPiAgICAgICAgICAgICAweDA5 ZTY0MGVmIDogInVua25vd24iLA0KPj4+PiA+ICAgICAgICAgICAgIDB4M2I1YzFhYjYgOiAiYWN0 aXZlIg0KPj4+PiA+ICAgICAgICAgICB9DQo+Pj4+ID4gICAgICAgICBdDQo+Pj4+ID4gICAgICAg fQ0KPj4+PiA+ICAgICB9DQo+Pj4+ID4gICB9DQo+Pj4+ID4NCj4+Pj4gPiBJcyBpdCBhIHJlYWwg aXNzdWUgYW5kIGlzIGl0IGEgdmlhYmxlIHNvbHV0aW9uPw0KPj4+PiA+DQo+Pj4+ID4gTWljaGVs IFZlaWxsZXR0ZQ0KPj4+PiA+IFN5c3RlbSBBcmNoaXRlY3R1cmUgRGlyZWN0b3INCj4+Pj4gPiBU cmlsbGlhbnQgSW5jLg0KPj4+PiA+IFRlbDogNDUwLTM3NS0wNTU2IGV4dC4gMjM3DQo+Pj4+ID4g bWljaGVsLnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tIHd3dy50cmlsbGlhbnRpbmMuY29tDQo+ Pj4+ID4NCj4+Pj4gPg0KPj4+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+ID4gY29yZSBtYWlsaW5nIGxpc3QNCj4+Pj4gPiBjb3JlQGlldGYu b3JnDQo+Pj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+IGNvcmVAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBjb3Jl IG1haWxpbmcgbGlzdA0KPj4+IGNvcmVAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1haWxpbmcgbGlzdA0KPj4gY29y ZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQo= From nobody Tue Mar 31 10:07:08 2015 Return-Path: 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 755241A1AA1 for ; Tue, 31 Mar 2015 10:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 ZQusGvhxctoB for ; Tue, 31 Mar 2015 10:07:04 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999EE1A1A94 for ; Tue, 31 Mar 2015 10:07:03 -0700 (PDT) Received: by lahf3 with SMTP id f3so17303535lah.2 for ; Tue, 31 Mar 2015 10:07:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+4/NaxfQjhztOjErxfFE8ZndAh061t3yvFy9MraeY4=; b=PYjwcmYZRkBH+WAP5oAxW6S9qadEiiLVdvHdbLBR6fm8En4HmySgk6HrxSegrygQiH IepjgDSnxELDozQ0CqKYpATMaz0RRn0KxsIRTklo6IQvrsHgcyXU7a2jctVamUF8+GeF jY+nZBrAFFNfUnEuM4QkdgT+tN/ERTvc8otO2dZNNyzdVt5WgWElpvVt08vdG7XSa5p7 yTaV5yjta1OLxnZpiuWSam4L/3F4C9eS4Cn+xlCgVCUJTQpMw5kUZtvyLg0VBTG0C23O fkyXMk5cfcwfRYCu+UqM4otJ+o5zyS544No2lhkOvbCKvv1N/lR3SyjyRTlsjWryunwB RO2w== X-Gm-Message-State: ALoCoQn2hBrEpPYBHhFWfdOSWuzhbQMXh4fCSyAZwxPyZdfn+7BBB/+r2ao5MqI1zwaxdt6W0dhp MIME-Version: 1.0 X-Received: by 10.152.87.135 with SMTP id ay7mr16634963lab.88.1427821621815; Tue, 31 Mar 2015 10:07:01 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Tue, 31 Mar 2015 10:07:01 -0700 (PDT) In-Reply-To: References:

Date: Tue, 31 Mar 2015 10:07:01 -0700 Message-ID: From: Andy Bierman To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:07:07 -0000 Hi, YANG module names are a bit longer than your example (like ietf-6top). Data is not required to be organized or retrieved by module. I don't think it is very practical for YANG module writers to manually manage the names in the module so there are no hash collisions. For SMIv2 modules already published and converted to YANG, this is not an option. Unless the collision probability is zero for all possible combinations of vendor and standard modules, then the need for rehashing has not been removed. The probability is already low enough that a constrained device will not ever encounter a collision, but it is still greater than zero. Andy On Tue, Mar 31, 2015 at 9:42 AM, Michel Veillette wrote: > Hi Andy > >> But YANG module names tend to be 15 to 30 bytes long, which really defea= ts the purpose >> of using short identifiers. If the solution makes the names longer tha= n they would have been >> without any hash, then perhaps it is not the right solution. > > I agree there is an impact but this impact seem limited. > > For a single data node access, the overhead consist of adding the module = name once in the URI. > > REQ: GET example.com/mg/data/6top:0cNDF > > RES: 2.05 Content (Content-Format: application/cbor) > { > 0x3470d0c5 : [ > { > 0x2a33a8b4 : 1, > 0xfe4ad55 : 1, > 0x2515e82f : 1, > 0x9c2f821 : 1, > 0x5057e17 : "Transmit,Timekeeping", > 0xd2a79e8 : 0, > 0x26e3537 : 1, > 0x2efea0b3 : h'0102030000112233', > 0x1e32edaf : 1 > } > ] > } > > For a complete datastore access, the overhead consist of adding each modu= le name once in a CBOR map. > > REQ: GET example.com/mg/data > > RES: 2.05 Content (Content-Format: application/cbor) > { > "6top" : { > 0x3470d0c5 : [ > { > 0x2a33a8b4 : 1, > 0xfe4ad55 : 1, > 0x2515e82f : 1, > 0x9c2f821 : 1, > 0x5057e17 : "Transmit,Timekeeping", > 0xd2a79e8 : 0, > 0x26e3537 : 1, > 0x2efea0b3 : h'0102030000112233', > 0x1e32edaf : 1 > } > ] > }, > "IP-MIB" : { > 0x30b7bc3f : { > 0x1067f289 : [ > { > 0x00d38564 : 1, > 0x2745e222 : "ipv4", > 0x387804eb : "10.0.0.51", > 0x1a51514a : "00:00:10:01:23:45", > 0x03f95578 : "2333943", > 0x24ade115 : "static", > 0x09e640ef : "reachable", > 0x3b5c1ab6 : "active" > }, > { > 0x00d38564 : 1, > 0x2745e222 : "ipv4", > 0x387804eb : "9.2.3.4", > 0x1a51514a : "00:00:10:54:32:10", > 0x03f95578 : "2329836", > 0x24ade115 : "dynamic", > 0x09e640ef : "unknown", > 0x3b5c1ab6 : "active" > } > ] > } > } > } > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: 31 mars 2015 12:30 > To: Michel Veillette > Cc: Thomas Watteyne; 6tisch@ietf.org; core@ietf.org > Subject: Re: [core] COMI hash values globally unique vs. unique within a = module > > On Tue, Mar 31, 2015 at 8:53 AM, Michel Veillette wrote: >> Hi Andy >> >> - About your comment " Nodes from module X that augment module Y are not= known by module Y, when module Y is compiled or deployed." >> >> If a data node 'y' added by module 'Y' to module 'X' create a YANG hash = conflict, data node 'y' will need to be rehash. This don't affect YANG hash= values of the data nodes already defined by module 'X'. > > Sorry I responded to the comment about augment. > It doesn't matter if the conflict is from an augment or a disjoint object= . > >> >> - About your comment " You seem to be suggesting that the 6TISCH WG will= control all YANG modules on a device, even modules from vendors or other S= DOs." >> >> This is not the case, devices are free to implement any number of YANG m= odules needed. By creating a distinct hash space for each module, we can mi= nimize impacts when integrating multiple modules within a single server. >> > > I guess if the YANG designers ran the hashes when they were written then = they could make gratuitous name changes to undo hash collisions. > > But YANG module names tend to be 15 to 30 bytes long, which really defeat= s the purpose of using short identifiers. If the solution makes the names = longer than they would have been without any hash, then perhaps it is not t= he right solution. > > > >> - About your comment " Most deployment scenarios allow for the vendor to= select the set of modules that are supported by a device. YANG is designed= to be modular and extensible, without requiring a single, centralized nami= ng authority." >> >> The intent is to reinforce this model and improve its scalability. >> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> michel.veillette@trilliantinc.com >> www.trilliantinc.com >> >> > > Andy > >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: 31 mars 2015 11:29 >> To: Michel Veillette >> Cc: Thomas Watteyne; 6tisch@ietf.org; core@ietf.org >> Subject: Re: [core] COMI hash values globally unique vs. unique within >> a module >> >> On Tue, Mar 31, 2015 at 7:50 AM, Michel Veillette wrote: >>> Hi Andy >>> >>> The intent is not to reduce the number of collisions but make these col= lisions predictable and uniform within a population of devices independentl= y of the number of modules implemented by them. This is especially importan= t in distributed applications such 6TiSH timeslot management. In such appli= cations, each constrained device need to interact with multiple other const= rained devices using CoMI. With the current YANG hash approach, each constr= ained device need to retrieve and maintain the rehash list for each peer. >>> >>> If the scope of YANG hash is reduced to the module level (data nodes de= fined by a module + data nodes added to that module by the augment statemen= t), collisions within this module can be determined based of the YAND defin= ition of this module and specific rehash values can be mandated or recommen= ded if needed. >>> >> >> >> Nodes from module X that augment module Y are not known by module Y, whe= n module Y is compiled or deployed. >> >> You seem to be suggesting that the 6TISCH WG will control all YANG modul= es on a device, even modules from vendors or other SDOs. >> >> Most deployment scenarios allow for the vendor to select the set of modu= les that are supported by a device. YANG is designed to be modular and exte= nsible, without requiring a single, centralized naming authority. >> >> >>> Michel Veillette >> >> Andy >> >> >>> System Architecture Director >>> Trilliant Inc. >>> Tel: 450-375-0556 ext. 237 >>> michel.veillette@trilliantinc.com >>> www.trilliantinc.com >>> >>> -----Original Message----- >>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman >>> Sent: 31 mars 2015 09:30 >>> To: Thomas Watteyne >>> Cc: 6tisch@ietf.org; core@ietf.org >>> Subject: Re: [core] COMI hash values globally unique vs. unique >>> within a module >>> >>> On Tue, Mar 31, 2015 at 12:15 AM, Thomas Watteyne wrote: >>>> [adding 6TiSCH] >>>> >>>> Andy, >>>> >>>> I believe the issue Michel highlights is that the hash collisions >>>> depends on the modules that are implemented in the CoMI endpoint. >>>> >>> >>> But hash collisions can occur within a module or across modules. >>> Allowing collisions across modules does not change the probability of a= collision. It does not remove the need to check for a collision. >>> >>> What problem are you trying to solve? >>> If it is to remove the possibility of a collision ever occurring then k= eep trying. Why is it better to change the scope of the object hash to be = per module name? >>> >>> The goal of the YANG hash is to lower the identifier size to a 4 byte n= umber. Adding the 10 - 20 byte module name to every identifier really does= n't help lower the identifier size at all. >>> >>> >>> Andy >>> >>> >>> >>>> That is, if nodeA implements the [/6t,/foo] modules, and nodeB the >>>> [/6t,/bar] modules, the hash collisions can be different, even in >>>> the same "6t" module. In the case of 6top, the YANG model describes >>>> the module completely. It would be awfully nice to be able to just >>>> rely on that YANG model to predict the hash collisions within that >>>> module.without having to discover the rehash-map on a server each time= . >>>> >>>> IIRC, today, a client accessing any resource using CoMI needs to >>>> first retrieve the hash-map? The client needs to do this for each >>>> node is manages, potentially periodically if new modules are added on-= the-fly? >>>> This seems like a lot of uncessary overhead. >>>> >>>> One way could be fr the server to return some error code when the >>>> client accesses a resource with a hash that is ambiguous. >>>> >>>> Your insight on this is very welcome. >>>> >>>> Thomas >>>> >>>> On Tue, Mar 31, 2015 at 3:46 AM, Andy Bierman wro= te: >>>>> >>>>> On Mon, Mar 30, 2015 at 12:43 PM, Michel Veillette >>>>> wrote: >>>>> > Currently, CoMI object identifiers (YANG hash) are globally >>>>> > unique within a CoMI server. Devices implementing different set >>>>> > of modules may have different YANG hash conflicts and may have a >>>>> > different set of object identifiers affected by rehash. In an >>>>> > application like 6TiSH, this means that the list of rehash values >>>>> > can't be known in advance based on the published YANG module, >>>>> > rehash values need to be discover and manage by each node involved = in the timeslots reservation process. >>>>> > >>>>> > Reducing the scope of the YANG hash to the context of a single >>>>> > module (data nodes defined by a module + data nodes added to that >>>>> > module by the augment statement) can mitigate this issue. The >>>>> > question is how this can be accomplished and if the overhead requir= ed make this change acceptable. >>>>> > >>>>> >>>>> I don't think this will work. >>>>> The probability of collisions is the same whether 100 objects are >>>>> defined in 1 module or 10 objects are defined in each of 10 modules. >>>>> >>>>> The client must implement the rehash algorithm even though there is >>>>> a low probability it will be used. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> > Impacts on the URI >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > Currently, the CoAP path consist of: >>>>> > "/mg/" >>>>> > >>>>> > Considering that the YANG hash is unique only within the context >>>>> > of a module, the CoAP path needs to include the module name: >>>>> > "/mg/data" or >>>>> > "/mg/data/: " >>>>> > >>>>> > Impacts on the CBOR content >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>>>> > If the CoAP path target a specific module (e.g. "/mg/data/: >>>>> > "), the current CBOR encoding rules should apply unmodi= fied. >>>>> > >>>>> > If the CoAP path target multiple modules (e.g. "/mg/data"), CoMI >>>>> > objects need to be associated to their respective module context. >>>>> > A CBOR map added to the root of the CBOR object can be used to esta= blish this relationship. >>>>> > >>>>> > For example >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > Assuming: >>>>> > - hash of "/6top:CellList" =3D 0x3470d0c5, base64 "0cNDF" >>>>> > - hash of "/6top:CellList/6top:CellID" =3D 0x2a33a8b4 >>>>> > - hash of "/6top:CellList/6top:SlotframeI" =3D 0xfe4ad55 >>>>> > - hash of "/6top:CellList/6top:SlotOffset" =3D 0x2515e82f >>>>> > - hash of "/6top:CellList/6top:ChannelOffset" =3D 0x9c2f821, base64 >>>>> > "Jwvgh" >>>>> > - hash of "/6top:CellList/6top:LinkOption" =3D 0x5057e17 >>>>> > - hash of "/6top:CellList/6top:LinkType" =3D 0xd2a79e8 >>>>> > - hash of "/6top:CellList/6top:CellType" =3D 0x26e3537 >>>>> > - hash of "/6top:CellList/6top:TargetNodeAddress" =3D 0x2efea0b3 >>>>> > - hash of "/6top:CellList/6top:TrackID" =3D 0x1e32edaf >>>>> > >>>>> > The "/6top:CellList/6top:ChannelOffset" data node can be >>>>> > requested as >>>>> > follow: >>>>> > >>>>> > REQ: GET example.com/mg/data/6top:Jwvgh >>>>> > >>>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>>> > { >>>>> > 0x9c2f821 : 5 >>>>> > } >>>>> > >>>>> > The content of the "/6top:CellList" list can be requested as follo= w: >>>>> > >>>>> > REQ: GET example.com/mg/data/6top:0cNDF >>>>> > >>>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>>> > { >>>>> > 0x3470d0c5 : [ >>>>> > { >>>>> > 0x2a33a8b4 : 1, >>>>> > 0xfe4ad55 : 1, >>>>> > 0x2515e82f : 1, >>>>> > 0x9c2f821 : 1, >>>>> > 0x5057e17 : "Transmit,Timekeeping", >>>>> > 0xd2a79e8 : 0, >>>>> > 0x26e3537 : 1, >>>>> > 0x2efea0b3 : h'0102030000112233', >>>>> > 0x1e32edaf : 1 >>>>> > } >>>>> > ] >>>>> > } >>>>> > >>>>> > And the content of the datastore can be requested as follow: >>>>> > >>>>> > REQ: GET example.com/mg/data >>>>> > >>>>> > RES: 2.05 Content (Content-Format: application/cbor) >>>>> > { >>>>> > "6top" : { >>>>> > 0x3470d0c5 : [ >>>>> > { >>>>> > 0x2a33a8b4 : 1, >>>>> > 0xfe4ad55 : 1, >>>>> > 0x2515e82f : 1, >>>>> > 0x9c2f821 : 1, >>>>> > 0x5057e17 : "Transmit,Timekeeping", >>>>> > 0xd2a79e8 : 0, >>>>> > 0x26e3537 : 1, >>>>> > 0x2efea0b3 : h'0102030000112233', >>>>> > 0x1e32edaf : 1 >>>>> > } >>>>> > ] >>>>> > }, >>>>> > "IP-MIB" : { >>>>> > 0x30b7bc3f : { >>>>> > 0x1067f289 : [ >>>>> > { >>>>> > 0x00d38564 : 1, >>>>> > 0x2745e222 : "ipv4", >>>>> > 0x387804eb : "10.0.0.51", >>>>> > 0x1a51514a : "00:00:10:01:23:45", >>>>> > 0x03f95578 : "2333943", >>>>> > 0x24ade115 : "static", >>>>> > 0x09e640ef : "reachable", >>>>> > 0x3b5c1ab6 : "active" >>>>> > }, >>>>> > { >>>>> > 0x00d38564 : 1, >>>>> > 0x2745e222 : "ipv4", >>>>> > 0x387804eb : "9.2.3.4", >>>>> > 0x1a51514a : "00:00:10:54:32:10", >>>>> > 0x03f95578 : "2329836", >>>>> > 0x24ade115 : "dynamic", >>>>> > 0x09e640ef : "unknown", >>>>> > 0x3b5c1ab6 : "active" >>>>> > } >>>>> > ] >>>>> > } >>>>> > } >>>>> > } >>>>> > >>>>> > Is it a real issue and is it a viable solution? >>>>> > >>>>> > Michel Veillette >>>>> > System Architecture Director >>>>> > Trilliant Inc. >>>>> > Tel: 450-375-0556 ext. 237 >>>>> > michel.veillette@trilliantinc.com www.trilliantinc.com >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > core mailing list >>>>> > core@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 31 11:09:03 2015 Return-Path: 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 42A631A885E; Tue, 31 Mar 2015 11:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 64cpk97hBJ42; Tue, 31 Mar 2015 11:08:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0555B1A8857; Tue, 31 Mar 2015 11:08:55 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 31 Mar 2015 18:08:38 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0112.000; Tue, 31 Mar 2015 18:08:38 +0000 From: Michel Veillette To: Andy Bierman Thread-Topic: [core] COMI hash values globally unique vs. unique within a module Thread-Index: AQHQa8dtRg20MVrYfEyNSmCW5DT13502uKlQgAAPsoCAAADjoIAACWiAgAAQxAA= Date: Tue, 31 Mar 2015 18:08:37 +0000 Message-ID: References:

Date: Tue, 31 Mar 2015 19:28:54 -0700 Message-ID: From: Andy Bierman To: Michel Veillette Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" Subject: Re: [core] COMI hash values globally unique vs. unique within a module X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 02:28:58 -0000 Hi, inline also On Tue, Mar 31, 2015 at 11:08 AM, Michel Veillette wrote: > Hi Andy > > See [MV] inline > > Michel Veillette > System Architecture Director > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: 31 mars 2015 13:07 > To: Michel Veillette > Cc: Thomas Watteyne; 6tisch@ietf.org; core@ietf.org > Subject: Re: [core] COMI hash values globally unique vs. unique within a = module > >> Hi, >> >> YANG module names are a bit longer than your example (like ietf-6top). >> Data is not required to be organized or retrieved by module. > > [MV] > The solution don=E2=80=99t require to organized data nodes by module but = an > implementation that do so will minimize payload overhead. OK -- I will accept that we can come up with optimizations so each module-name needs to appear only 1 time. > >> I don't think it is very practical for YANG module writers to manually m= anage >> the names in the module so there are no hash collisions. For SMIv2 modu= les >> already published and converted to YANG, this is not an option. >> >> Unless the collision probability is zero for all possible combinations o= f vendor >> and standard modules, then the need for rehashing has not been removed. >> The probability is already low enough that a constrained device will not= ever >> encounter a collision, but it is still greater than zero. > > [MV] > The intent is not to "manually manage the names in the module so there ar= e no hash collisions". > The intent is not to remove the "need for rehashing". > > The intent is to reduce the scope of YANG hash to make collisions predict= able and uniform within > a population of devices independently of the number of modules implemente= d by them. > Actually, I wanted to use your design from the start, but not with strings. Temporary numeric mappings do not help, so I gave up. When I started working on YANG Hash and the ietf-yang-library module, I wanted to put a uint32 "module-id" in the module entry, but this needs to be a globally assigned number so all servers return the same mappings. The numbers are arbitrary so they can be assigned by IANA or by algorithm. Since there are so few YANG modules in RFCs, I wonder if an IANA registry for module-id mappings would work. Could a 2-number module-id work: . ORG =3D=3D reserved space: 1 for IETF, 2 for IEEE, etc. enterprise space: SMI enterprise ID + (reserverd range offset) MODULE-ID =3D=3D permanent module number assigned to the module Maybe an algorithm to convert arbitrary SMI MIB root OIDs to module-ids could be found so SMIv2 converted to YANG will work automatically. >> Andy

Transport Lay= er Binding and Encodings=

8.1 = Req= uired Features

= 5 = ; Overview

= 5.1 &n= bsp; Required Features