Re: [core] draft-ietf-core-sid-02 Issues
Andy Bierman <andy@yumaworks.com> Mon, 27 November 2017 21:30 UTC
Return-Path: <andy@yumaworks.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 E1B4812940B for <core@ietfa.amsl.com>; Mon, 27 Nov 2017 13:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 v7ys46-mCDIF for <core@ietfa.amsl.com>; Mon, 27 Nov 2017 13:30:13 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 6D83D126C26 for <core@ietf.org>; Mon, 27 Nov 2017 13:30:12 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id 73so34470831lfu.10 for <core@ietf.org>; Mon, 27 Nov 2017 13:30:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MqpgQjj9ukeWR8zUSRWSeGQV72i0HNWM45aONa907hQ=; b=VYgCTIUYA0YmTzm2xcouOXifMpqm1ABnV0unJG0Zz6nY5FWTzCN6E2f9kuUFy5YsY6 lBSCZZpKVQbnipsTGB2VyIXBdSJhZPYIWa3pJ5D7abZ5dkLKIEfZcRJKxGgCImB7DcHC /dAU9jk6+aQTNmDkgVXBRKNDZwl9d6LCLl9KqIkwOnZoNdtrSG3/NWW9XUZvFq/F1n31 a2jtSrb9wbZpXeqOw3qkYjqz2ByzFwuJ2t7V5MxBMIVlqw5YxcfvVDKdsyZHJY2tcpxT oVupMcHK3BZQmcYPXC8xZL4atyKbzKSD/KsS6aU29XMQknOFlGs0BahHttRALxLNRnYt tVag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MqpgQjj9ukeWR8zUSRWSeGQV72i0HNWM45aONa907hQ=; b=iscEuLyZse7NnqxcBW/QKaL5IsuS2YDK+nsQ7oq8aHPPOZ5tWmyxhQfKVJdUHO2yGZ MO5RmH8FygSF+a64RcAPtlGIldI4AqPKiNNTA4EnqnIgGKtP72U9sOw2d8VBTDKuy1+a /qUt+XCG3Gb7E1zX/h/aqADky9KhDjgLaGx4gEXv9FWxaSeQuIlGFC9eJNbM83faUy2r 2JPGlj0iykDY+ts0M/HAsjpemKa1qun5p6Qtnn15n2E0qYpPrrKokFSYw8dfc+kXna0n 3F2OG30pD9rrbUHeNrJ8oLRTUGRQUw/TjDo54oI/UQs2dKB1Ge3w5RWHQQIXSdnUmqUY umiA==
X-Gm-Message-State: AJaThX4s75shKJb6OX2Rsjk1KaEhV7ngaXtc9wDMmWM/R9QDBwvr2yRw LoS6rQRYJ+eafViqJPTx0gASG7CyWK+9heHyH0fWIocJ
X-Google-Smtp-Source: AGs4zMZVFr14Ymswwsizgj0OqNiJj1pzhBqWpWVAZVNr/jbcO4pDP3tjOkxNK3Q1QxqhjB65EeJp8d0OCzlAv71UQLg=
X-Received: by 10.25.32.145 with SMTP id g139mr12778301lfg.2.1511818210436; Mon, 27 Nov 2017 13:30:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 13:30:09 -0800 (PST)
In-Reply-To: <BN6PR06MB2308B3E800D8554EFAC8331EFE250@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <CABCOCHT9D-4ko4Du_HEv62Etf2aPTbSqBJb1rOOEoMzpXVRXxA@mail.gmail.com> <BN6PR06MB2308B3E800D8554EFAC8331EFE250@BN6PR06MB2308.namprd06.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 27 Nov 2017 13:30:09 -0800
Message-ID: <CABCOCHR3KoXwuzhdtvrmd5YXeCeVpfKLS8WCUpKhOt8rZAuccw@mail.gmail.com>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Core <core@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401ca865ffee055efd9b3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/O24w09RD88eJswxMn7rZDzan6Pw>
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:30:16 -0000
On Mon, Nov 27, 2017 at 1:03 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > 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? > > > I think that identity SID entries are currently broken. Only the identity name is included in the label, not the base. YANG 1.1 allows multiple bases, so listing 1 base is broken. Identity and feature names are unique within the module that defines them. The SIDs for them will be globally unique. The SID entry for a given module does not need to identify the module itself. That is implied. typdef foo { type identityref { base foo; } } identity foo; feature foo; leaf foo { if-feature foo; type foo; } All legal YANG -- the SID labels call contain "foo", and each one has a different type. I see your issue -- a tool cannot compare an entry from 2 different modules for feature and identity definitions. However it is not relevant in YANG to compare these names across modules. Feature A:foo and B:foo have no relation to each other, just a name collision resolved by the module namespace scope. I do not anticipate any other changes to SID. Sorry I did not do this review months ago when the draft came out. I want to implement CoMI w/CBOR/SID soon, and I think the CBOR/SID part is almost ready. Andy > 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