Re: [core] draft-ietf-core-sid-02 Issues
Michel Veillette <Michel.Veillette@trilliantinc.com> Mon, 27 November 2017 21:03 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 196651293EB for <core@ietfa.amsl.com>; Mon, 27 Nov 2017 13:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MAcXPWxSMnVP for <core@ietfa.amsl.com>; Mon, 27 Nov 2017 13:03:17 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0139.outbound.protection.outlook.com [104.47.37.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8070D124D6C for <core@ietf.org>; Mon, 27 Nov 2017 13:03:17 -0800 (PST)
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=AS/YeGTVHUVv6z1iO7jA1pfuHbN2DLm+zzGCcK4+JKw=; b=j2utyInBF/I9bM8Et3DvyF4EN8yGxgwRR8mB1JWnlevgkte7a6BecBVKdjWqT2TkogWz97zphgsPTf6oqfSJwrivjG7vlma1myAaetxP21I7cIGP0TgPEtWucHcLqb+c54HVgIepSKbPhEn0ndPQ6nbLjeQLZ46oIA/VqGQ36Ds=
Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Mon, 27 Nov 2017 21:03:15 +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.20.0260.006; Mon, 27 Nov 2017 21:03:15 +0000
From: Michel Veillette <Michel.Veillette@trilliantinc.com>
To: Andy Bierman <andy@yumaworks.com>, Core <core@ietf.org>
Thread-Topic: [core] draft-ietf-core-sid-02 Issues
Thread-Index: AQHTXMgvoatPIUb3x0SkGinFP4uMu6MowQ+Q
Date: Mon, 27 Nov 2017 21:03:15 +0000
Message-ID: <BN6PR06MB2308B3E800D8554EFAC8331EFE250@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <CABCOCHT9D-4ko4Du_HEv62Etf2aPTbSqBJb1rOOEoMzpXVRXxA@mail.gmail.com>
In-Reply-To: <CABCOCHT9D-4ko4Du_HEv62Etf2aPTbSqBJb1rOOEoMzpXVRXxA@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 6:/frfRzOEfw46FFldiV3EaYMv6uFZo0UevcJBznfuBr+AnVkWFJdXQoLzkBLr+wU9HqcE+iwUeWWNtPI2SfETzBvNLtSPegSA+j3GEA1JwYSYbpPCYmY3dWtWzJNr2Ym7imOc4o1Y4r6XkumMT+LigxoA5ceTRsiE8OpvSLrQC8RuEKNAQsTQguzK2oNjUfkCDfr8kTFft61hhu9ydZpcVlb/7XqDhyPCygbDH9iVYpCTyDItYfzkMT8JkDhAHeWD4ehBqHX2LIVqyh592zBhp5f1tkUOZ7ovuh4DcEmZo3GWPZudw6DsNhLQcDYFtpN5bKee2fOQ5IicydiCfNJWly//MEc76NnJPcQrZc8kes4=; 5:ZvgA4n3L8TkNYCwATcTRqodGzIuRU+GZHZcz7xv5+S+fMgkF2zC+gqb6tvprMacDt9X3rfmS+YKrnp7+pC6s12RMLBcPUCkr8sx6cAyoJCmQ0t+wqahY/SWsIkW8JFF6qCWrbeDvXZg0k2U0ziYV7Mxxut1JSgDoc75GMeQhHhM=; 24:KH3mt2hobYu2ChPvtSVr+9PiKH3E/TDYEkj7WxWxLRezug7UanL2OwL02G21u62akn0ak9sBOid9Zr/kVgBIDzE7BXGbcHqyE/lzV2hY6IU=; 7:Z4Cl9/XAkbamegjavZdUt52gmwi2av2boOd07pBX8XLys0sh9yrxqfwZNHT1atrFteJ9/78C0Vc8zo7V7nGVvcTKRgh0WsCGyIOIeIysfsM/L7GYGKX+wkHA9XLOtOPeKzkaYEFpyqPaSGFn71gpdbqLb9nM4VnHNbe3V1lu7j643ABkE2c1NN3fBtlz/gmLojvJIvroBIXj9QkhcviKyeBF5dxWZCv1nzY0b2PfHD869OW55+JaVycR9debexaO
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d70ad5d6-22f5-4fb9-4ca5-08d535da475b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:BN6PR06MB2308;
x-ms-traffictypediagnostic: BN6PR06MB2308:
x-microsoft-antispam-prvs: <BN6PR06MB2308E398D6C0E216B870FD9EFE250@BN6PR06MB2308.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR06MB2308;
x-forefront-prvs: 0504F29D72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(199003)(189002)(3280700002)(53546010)(101416001)(230783001)(316002)(606006)(8936002)(68736007)(8676002)(7736002)(74316002)(2950100002)(478600001)(72206003)(81166006)(3660700001)(77096006)(7696005)(86362001)(5660300001)(2906002)(25786009)(81156014)(66066001)(54356999)(966005)(50986999)(9686003)(76176999)(189998001)(6436002)(790700001)(54896002)(6506006)(105586002)(55016002)(99286004)(229853002)(6306002)(3846002)(14454004)(33656002)(53936002)(2900100001)(6246003)(102836003)(106356001)(4001150100001)(6116002)(97736004)(110136005)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308B3E800D8554EFAC8331EFE250BN6PR06MB2308namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d70ad5d6-22f5-4fb9-4ca5-08d535da475b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 21:03:15.7539 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wHBNi8cpx0zToeMdF2t06Seb9rs>
Subject: Re: [core] draft-ietf-core-sid-02 Issues
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 27 Nov 2017 21:03:22 -0000
Hi Andy I first want to confirm the list of changes you are proposing. 1. Paths within 'label' represented using a canonical representation (YANG 1.1 ABNF for a schema node identifier, except module names are used instead of prefixes) 2. 'type' implemented using an enumeration 3. 'module' and 'submodule' combined within the same 'type' (module) 4. 'node', 'notification', 'rpc' and 'action' combined within the same 'type' (data) It's still time to make such changes, but I will like to limit the number of iterations to avoid too much instabilities in the registry. If we move ahead, let try to get a large consensus. My only question about these changes are relative to 'identity' and 'feature'. 'module' and 'submodule' are part of a global namespace. 'data' are represented using a canonical representation which make them globally unique. Should we also adopt some kind of canonical representation for 'feature' and 'identity'? Should we make the 'label' field globally unique to simplify the aggregation of .sid files? Notes: * See https://comi.space/file/ietf/public/ietf-ip@2014-06-16.sid for examples using the current .sid format of data nodes defined using the augment statement. * See https://comi.space/file/ietf/public/iana-if-type@2014-05-08.sid for examples using the current .sid format of identity. Regards, Michel From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Monday, November 13, 2017 4:41 PM To: Core <core@ietf.org> Subject: [core] draft-ietf-core-sid-02 Issues Hi, Here are some comments on SID draft: - The SID design does not support augment correctly. It is not mentioned at all in the draft. The "label" leaf design does not allow for YANG identifier names from other modules. There is also no need to overload the label field with extra semantics about the data type. This actually breaks the SID mapping since "label" is part of the key. (It needs a simple and canonical representation.) Example of SID broken for augment: module A { ... container top { leaf leaf1 { type string; } } } module B { import A { prefix A; } ... augment /A:top { leaf leaf1 { type int32; } } container top; } - the module revision date is always 2015-12-16. The revision date is supposed to match the I-D revision date so YANG compilers can tell the different versions apart - typedef yang-identifier do not clone this type. Use the real yang-identifier in ietf-yang-types (RFC 6991( - The 'mandatory true' statements are redundant for key leafs and should be removed (for key leafs only) - leaf 'type' needs to be an enumeration, not a string with patterns to do the same thing as an enumeration. This field needs to be a simple identifier, not a union of complex patterns. This type is not defined correctly. It needs to identify the YANG identifier namespace type, as defined in RFC 7950, sec. 6.2.1 Modules and submodules are in the same namespace. They are not separate things as defined in the SID draft. The following "yang-ns-id" typedef definition shows the full namespace, and "sid-ns-id" shows the subset relevant to CoMI. The leafs "type" and "label" fix the problems with the current design and allow the "label" field to support augment-stmt. The only allowed form is also the canonical form, allowing the { type, label } tuples to be easily and correctly compared. typedef yang-ns-id { type enumeration { enum module { description "All module and submodule names share the same global module identifier namespace."; } enum extension { description "All extension names defined in a module and its submodules share the same extension identifier namespace."; } enum feature { description "All feature names defined in a module and its submodules share the same feature identifier namespace."; } enum identity { description "All identity names defined in a module and its submodules share the same identity identifier namespace."; } enum type { description "The namespace for all derived type names, as defined in YANG."; } enum grouping { description "The namespace for all grouping names, as defined in YANG."; } enum data { description "The namespace for all data nodes, as defined in YANG."; } enum case { description "All cases within a choice share the same case identifier namespace. This namespace is scoped to the parent choice node."; } } description "A YANG namespace identifier specifies the identifier namespace within a YANG module and its submodules. An identifier is only required to be unique within a specific namespace."; reference "RFC 7950, The YANG 1.1 Data Modeling Language; Section 6.2.1: Identifiers and Their Namespaces."; } typedef sid-ns-id { type yang-ns-id { enum module { description "All module and submodule names share the same global module identifier namespace."; } enum feature { description "All feature names defined in a module and its submodules share the same feature identifier namespace."; } enum identity { description "All identity names defined in a module and its submodules share the same identity identifier namespace."; } enum data { description "The namespace for all data nodes, as defined in YANG."; } } description "A SID namespace identifier specifies the identifier namespace within a YANG module and its submodules, as used within the a SID registry mapping."; } typedef sid-path { type string; description "Identifies a schema-node path string for use in the SID registry. This string format follows the rules for an instance-identifier, as defined in RFC 7959, except that no predicates are allowed. This format is intended to support the YANG 1.1 ABNF for a schema node identifier, except module names are used instead of prefixes, as specified in RFC 7951."; reference "RFC 7950, The YANG 1.1 Data Modeling Language; Section 6.5: Schema Node Identifier; RFC 7951, JSON Encoding of YANG Data; Section 6.11: The instance-identifier type"; } leaf type { type sid-ns-id; description "The SID namespace Identifier type for this entry"; } leaf label { type union { type sid-path; type yang:yang-identifier; } description "The label identifying this mapping entry. If the corresponding 'type' field is 'module', 'feature', or 'identity', then this field MUST contain a valid yang-identifier string. If the corresponding 'type' field is 'data', then this field MUST contain a valid sid-path string."; } Example for module A and B: module A: module, "A", 1700 data, "/A:top", 1701 data, "/A:top/leaf1", 1702 module B: module, "B", 2700 data, "/A:top/B:leaf1", 2701 data, "/B:top", 2702 Andy
- [core] draft-ietf-core-sid-02 Issues Andy Bierman
- Re: [core] draft-ietf-core-sid-02 Issues Michel Veillette
- Re: [core] draft-ietf-core-sid-02 Issues Andy Bierman