Re: [core] draft-bierman-core-yid-00.txt questions
Michel Veillette <Michel.Veillette@trilliantinc.com> Wed, 24 August 2016 23:22 UTC
Return-Path: <Michel.Veillette@trilliantinc.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3C412D1E0 for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 16:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfvIilG9QHw6 for <core@ietfa.amsl.com>; Wed, 24 Aug 2016 16:22:48 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2D712D144 for <core@ietf.org>; Wed, 24 Aug 2016 16:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nuMQzv3lZkyVJadYjIS0snhvVoDs5hVovqc20QBu7UE=; b=PVEFNj6wk9vpMCKS2yPXet4GGYvVLG4iB3l/j/gkznOC6KILgKj47hkn6uYkAweOrAB3I/pH4ftiUGdF0ucylzoDEc0ZBn8oMVHuor22TUfVtenTr0dPYbT98BkPNA8JcUEe2rbdL+vHKgi4M7ePj+d7ljTkHLn1BDqLOiGKtFg=
Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 23:22:45 +0000
Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0557.030; Wed, 24 Aug 2016 23:22:44 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>, David Reid <reid@snmp.com>
Thread-Topic: [core] draft-bierman-core-yid-00.txt questions
Thread-Index: AQHR/kcOnsXgBk9RvEWD4CzBgA9zo6BYnsOAgAAdH0A=
Date: Wed, 24 Aug 2016 23:22:43 +0000
Message-ID: <BN6PR06MB2308A46F6A84378832DBC849FEEA0@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <20160824203526.3B9B45213C4@rh7.snmp.com> <CABCOCHR63yE=QsCdUmNXAUw9cGgAxugFBqpHwFe9E6Pt25Rc5A@mail.gmail.com>
In-Reply-To: <CABCOCHR63yE=QsCdUmNXAUw9cGgAxugFBqpHwFe9E6Pt25Rc5A@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [24.225.215.88]
x-ms-office365-filtering-correlation-id: 7a4dd038-d989-4a48-027a-08d3cc758d36
x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 6:iJlcpsmeejnXzfvzHk3zUIsu9wfYd6z1AVflrbvNoDVXne4Aj9OViG7TAVTPQutTrH9Z2/BnEhtUtHdHzTqAJCixDrzHEWxGE1P9aDJyTUEfksMpeEXZEypdodgt5ttpnii7LAtkkIuuq+GxEiXNsvjuYeHCL7zZHrzfL8xhYuUixjSWEb3fskaDjHZbvYgr6u+yYjPckeD34QaX+QUsOrubD2bFiYyLjsnNqrEh3DLgA+PgJ9gsCN0uZK64x5P8eoELtdLMKQjuMUv/Y9rZt1cDN6hwsK6G1P//v7i6cCk=; 5:r9/PyMc+O2srTNpEESKJ207Jo2jN65W0dHYN42uKK1opGubQb1xk74XLJm5nE73oYtM0CA0sNTP0RYA7jRjGsWPgGhqQtwoiIJSbAvKD2TLD+AI9PedyweTh+VVXHGDoORRam+ZhGJMllMlPBzCs4w==; 24:486U1jeu4N4ndbHK4ZRvy8h8ApP9BMHCgK9GHsW6cQqhj/G+YT3GTfWNjMMIpkmzntYmvuFObeo76P1eUZX9gTR95Q/KDtU/Fyuc0BL7L+k=; 7:DJcmOggdZXQHzV65Zd+/zU+7FwUMqRR5KXxPKzOq2KCe0zAh0NYryHcWYAQ0EiZE1Zv+pVNFk9DmeC6bM8z/ucjr05k6R7u84wBo5Pp4oH2ZV5ZKahnw6ve8JcVc2h2wGlFT7BYQAWJNQqxz7n4PeigylqpHu0U+VVMg2NztQkbI0+wOOWFjI+UxvEmctZHkjxBFN2D6HEZb2SfPI+nmT6orNpHBcMdxkBn3MNrbc0MSjq8CqGbG66R/xNTtwSCF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2307;
x-microsoft-antispam-prvs: <BN6PR06MB23074290F951CA5AB98441DBFEEA0@BN6PR06MB2307.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(51884002)(377454003)(199003)(68736007)(2906002)(77096005)(106116001)(105586002)(5660300001)(122556002)(3660700001)(3280700002)(7846002)(7696003)(6116002)(586003)(19609705001)(5002640100001)(8676002)(7736002)(790700001)(9686002)(81166006)(74316002)(81156014)(106356001)(8936002)(230783001)(10400500002)(66066001)(99286002)(7906003)(3846002)(19300405004)(102836003)(16236675004)(19580405001)(2900100001)(19617315012)(19625215002)(92566002)(2950100001)(189998001)(76176999)(50986999)(15975445007)(19580395003)(97736004)(101416001)(87936001)(5001770100001)(54356999)(76576001)(4326007)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308A46F6A84378832DBC849FEEA0BN6PR06MB2308namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 23:22:43.9817 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ue-E7mlmmlsPzkF3p930zL_RJE4>
Cc: Core <core@ietf.org>
Subject: Re: [core] draft-bierman-core-yid-00.txt questions
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2016 23:22:51 -0000
Hi David, Hi Andy [MV] Inline From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, August 24, 2016 5:23 PM To: David Reid <reid@snmp.com> Cc: Core <core@ietf.org> Subject: Re: [core] draft-bierman-core-yid-00.txt questions On Wed, Aug 24, 2016 at 1:35 PM, David Reid <reid@snmp.com<mailto:reid@snmp.com>> wrote: I read draft-bierman-core-yid-00.txt and have a few questions. Will all IETF standard yang modules be included in the YANG identifier registry or just ones that might be used on constrained devices? I think all modules. We want to support unconstrained devices on constrained networks. [MV] The request we got so far is all YANG modules published in RFCs. In order to assign numbers, is it correct that I need the first revision of the module or else the current revision and the registry assignments for the previous revision? I think in all numbering schemes (as Michel pointed out) you need the current registration entry and the new module revision. What is the benefit of assigning values using hashing over sequentially assigning values? There is overhead ir reading and processing a giant list of mappings. Automatic assignment is risky because both sides need to agree on the object to number mapping. Detecting these issues is very difficult. The YANG Hash algorithm is designed to use the path string, which is permanent and cannot change no matter how the YANG is refactored. The murmur hash is a stable algorithm. There is not a lot that can go wrong for the 2 peers to disagree on the hashes (except for collisions) When there is a hash collision, would it be possible to rehash the value to get a unique number so that we never have to manually assign numbers and thus never need to register the numbers in the registry? yes, this has been suggested. The problem with auto-rehashing before was inter-module clashes. Now those are not possible so automatic rehashing is feasible. [MV] I disagree, see my previous email which explain why all YIDs/SIDs need to be registered even if generated using a hash. Why does module-id need to be added to the YANG module names registry since it is also in the YANG identifier registry? I guess it is not needed since the module name is in both registries already Would it make sense to put the module-id inside the yang module with a yid extension so that I would not have to go lookup that information from a registry? I suppose -- but how to prevent duplicates and cut-and-paste errors? [MV] Just adding the module ID in the yang file is not sufficient to use a .yang file, all YIDs/SIDs need to be added. [MV] Having YIDs/SIDs in yang files will make their maintenance more complex. [MV] BTW, a pyang plugin already exist to automatically generate and update a .sid file from a .yang file [MV] See https://github.com/core-wg/yang-cbor/blob/master/sid.py Would it be possible to assign the module-id based on information in the module, for example a hash of the namespace and maybe the revision date. That way, a module-id would not have to be assigned and maintained in a registry. I think private module-id would be better, using a range reserved for temporary assignments. How do you resolve hash collisions for module-id? If I want to handle private modules, do I have to create my own registry? It seems important that private modules be supported. Could we re-use the SMI enterprise number assignments for creating module-ids for private modules? The ietf-yid module has a schema for the entire registry. How to use the registry is a protocol issue that needs to be decided. If the server advertises its own registry vs. a public registry, then it is using a private registry. If all devices in the system agree on which registry to use, then everything works. Who will assign the local-id numbers? Is that done by the working group that defines the YANG module? I would expect IETF modules to use hashes by default but for some modules that seem useful to constrained devices, then manual numbering could be done instead by the WG. [MV] To obtain a smaller encoding, I personally believe that the sequential numbering will be used. [MV] With sequential numbering, all current YANG modules defined in RFCs can be assigned within the first 6500 SIDs which will be encoded as 3 bytes for the first reference and typically as 1 bytes for the following ones using delta encoding. [MV] With hashes, only one YANG module can be assigned within that range. -David Reid Andy _______________________________________________ core mailing list core@ietf.org<mailto:core@ietf.org> https://www.ietf.org/mailman/listinfo/core
- [core] draft-bierman-core-yid-00.txt questions David Reid
- Re: [core] draft-bierman-core-yid-00.txt questions Andy Bierman
- Re: [core] draft-bierman-core-yid-00.txt questions Michel Veillette
- Re: [core] draft-bierman-core-yid-00.txt questions David Reid
- Re: [core] draft-bierman-core-yid-00.txt questions Andy Bierman
- Re: [core] draft-bierman-core-yid-00.txt questions Michel Veillette
- Re: [core] draft-bierman-core-yid-00.txt questions Andy Bierman
- Re: [core] draft-bierman-core-yid-00.txt questions Michel Veillette
- Re: [core] draft-bierman-core-yid-00.txt questions Alexander Pelov
- Re: [core] draft-bierman-core-yid-00.txt questions Andy Bierman
- Re: [core] draft-bierman-core-yid-00.txt questions Alexander Pelov
- Re: [core] draft-bierman-core-yid-00.txt questions Michel Veillette
- Re: [core] draft-bierman-core-yid-00.txt questions peter van der Stok