Re: [yang-doctors] Unsupported schema tree w/ cyclic dependencies + schema node identifier clarification
Ebben Aries <exa@arrcus.com> Sat, 23 March 2019 16:52 UTC
Return-Path: <exa@arrcus.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59551277CE for <yang-doctors@ietfa.amsl.com>; Sat, 23 Mar 2019 09:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 SOaG8zy3Hquu for <yang-doctors@ietfa.amsl.com>; Sat, 23 Mar 2019 09:52:16 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690081.outbound.protection.outlook.com [40.107.69.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC6F1279E6 for <yang-doctors@ietf.org>; Sat, 23 Mar 2019 09:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c7qio6YevHTh+aM0zuPLcQFSB3RKxBV5vK36Ph106EU=; b=mQzeR1Q0JfGtVDomM/CbXOT735G/Y9JPxR3BmvYKk3gsKncqcV44DAIIASnuXJNDirVnBIhdCPMbVnX36Z6cee80XDckjafjgl/HNy154g/gN0/9EJHgwbvst6ywPbOH3y4v/Gx5MX8nUs1J+MWpHkTD/9dga3QcbOqg0MUX71o=
Received: from BYAPR18MB2375.namprd18.prod.outlook.com (20.179.90.216) by BYAPR18MB2696.namprd18.prod.outlook.com (20.178.207.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Sat, 23 Mar 2019 16:52:11 +0000
Received: from BYAPR18MB2375.namprd18.prod.outlook.com ([fe80::718b:7ac3:17ca:c664]) by BYAPR18MB2375.namprd18.prod.outlook.com ([fe80::718b:7ac3:17ca:c664%3]) with mapi id 15.20.1730.017; Sat, 23 Mar 2019 16:52:11 +0000
From: Ebben Aries <exa@arrcus.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: [yang-doctors] Unsupported schema tree w/ cyclic dependencies + schema node identifier clarification
Thread-Index: AQHU4EP5YYanB23cdUGtd1BYnLXijaYXXqoAgADjLYCAAKT9AIAAiiaA
Date: Sat, 23 Mar 2019 16:52:11 +0000
Message-ID: <20190323165209.a2mo3c4mxxxs5ghg@localhost>
References: <20190322001243.qek4neyeee4ezspl@localhost> <20190322.101406.1388195451706941171.mbj@tail-f.com> <20190322224711.sglgrvgfrqu7bosw@localhost> <20190323.093742.1114866601397885600.mbj@tail-f.com>
In-Reply-To: <20190323.093742.1114866601397885600.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR07CA0021.namprd07.prod.outlook.com (2603:10b6:a02:bc::34) To BYAPR18MB2375.namprd18.prod.outlook.com (2603:10b6:a03:12d::24)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=exa@arrcus.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2601:283:4600:80a0:bb8b:26e2:d8d4:bc07]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 656c986b-6aff-4687-f384-08d6afafe483
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600127)(711020)(4605104)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR18MB2696;
x-ms-traffictypediagnostic: BYAPR18MB2696:
x-microsoft-antispam-prvs: <BYAPR18MB26961866695884E3CED6BFC8CD5C0@BYAPR18MB2696.namprd18.prod.outlook.com>
x-forefront-prvs: 0985DA2459
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916004)(396003)(376002)(366004)(39840400004)(136003)(346002)(199004)(189003)(6486002)(508600001)(14444005)(256004)(2906002)(6436002)(14454004)(76176011)(52116002)(316002)(305945005)(6116002)(99286004)(7736002)(229853002)(68736007)(97736004)(102836004)(93886005)(6916009)(386003)(6506007)(86362001)(6246003)(5660300002)(53936002)(446003)(8936002)(8676002)(11346002)(33716001)(71200400001)(71190400001)(25786009)(4326008)(46003)(106356001)(486006)(9686003)(1076003)(105586002)(186003)(476003)(81166006)(81156014)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2696; H:BYAPR18MB2375.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 1W0fL/kUElVQMA5vkd8RN4kB6HS8K2cTFjmxhv3xUCgVDJIvyQN1KObNc8Sw4GLJ8QnlTeX0lyaH7vK/J3yQfXbTDORLmMZqFqZiERzk3EgJTj8umUOHFC+ApbylytVmNKmwvJTy27xCKrm2Mu7sDi6BoP4Xod9ZX4tTUn3tAjtkiRH66ru88nsoLLvBOX5dwzHIVq6TEJjYoKKyuyf5h1mc6shzs+/WrgT0WLLpa1ny7FlTMK8IKuUtNHYKGUHFlJQTDSHSpylckF3zF/GfF1VQWzHVuU/wscPGr2jfDyRcNM7l1ZY/GdkBiKWc89jzBnzB2wJEE+A4yqk3PIttUhGjPgNLmYgcg47RO5tpX3yziyeg9KnS4k21PPrhS+AqkIVQW43fPBHciyO2UhJ7CnY8hQ+ajZVm876pqCY0BjM=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5371CEDFEFFBA1469A89CFF96E7BF9C4@namprd18.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 656c986b-6aff-4687-f384-08d6afafe483
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2019 16:52:11.0546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2696
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/g0lJ2jXCbRpkzTUes8ZAKBYUg6s>
Subject: Re: [yang-doctors] Unsupported schema tree w/ cyclic dependencies + schema node identifier clarification
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2019 16:52:19 -0000
On Mar 23 09:37 AM, Martin Bjorklund wrote: > Hi, > > Ebben Aries <exa@arrcus.com> wrote: > > Thx Martin - see inline... > > > > On Mar 22 10:14 AM, Martin Bjorklund wrote: > > > Hi, > > > > > > Ebben Aries <exa@arrcus.com> wrote: > > > > I have a few questions for the group that have surely come up before... > > > > but maybe I'm missing something... > > > > > > > > 1. How to handle cases where you only support a non-schema tree portion > > > > of a module where other non-schema statements have a cyclic dependency > > > > back to the schema tree > > > > > > Is this a separate question from 2 below? If so, I don't understand > > > the question. If it the same, please see below. > > > > > > > Yes, these were 2 separate questions - see below > > > > > > 2. Schema Node Identifier wording in RFC7950 > > > > > > > > > > > > For #1, Let's say you have module A that imports module B for use of an > > > > identity. Let's call the use of this an identityref to 'base b:foo' > > > > > > > > Module B contains typedefs, identities and schema tree and the > > > > implementation prefers to deviate the schema tree completely as > > > > 'not-supported' but needs to support this model for resolving imports > > > > and use of identities only (e.g. module A). > > > > > > The server would advertise module B as conformance-type = import in > > > the YANG library. > > > > > > > Yep - ok. So a 1.1 minimum to support this method of conveying and a > > client that must honor conformance-types when building schemas > > > > For any clients not using yang-library, we have a problem (e.g. > > OpenConfig gNMI or a static module cache) > > > > > > However if any of the typedefs in module B have leafrefs to it's own > > > > schema tree, you cannot deviate the entire tree as this breaks the > > > > contained leafref. > > > > > > I don't think there's an issue here. If a server doesn't implement > > > the target of a leafref in a typedef, it also cannot implement any > > > leaf that uses this typedef. The typedef itself is not a problem. > > > > > > > That is correct. My point was rather than you have a schema tree, a > > typedef and an identity in a module. You only import and use the > > identity and want to deviate the schema tree. You cannot deviate the > > typedef that has a leafref to the schema tree and thus the typedef > > cannot resolve (unless one were to relax checks on resolving). > > Essentially you only support the identity within this module. > > conformance-type==import would solve this from a library perspective but > > appears we cannot solve this solely w/ deviations today > > I still don't understand the problem. You write that "You cannot > deviate the typedef" - correct, but why would you want to do that? > > If you don't use the YANG library, you can deviate the whole schema > tree as "not-supported". If some other module has leafs that use the > typedef that you can't support, you have to deviate these leafs as > well. > Depending on the compiler implementation, an assumption would be that the leafref that sits in a top level typedef would then not resolve e.g. from ietf-interfaces typedef interface-ref { type leafref { path "/if:interfaces/if:interface/if:name"; } } And that is my point, if you deviate /if:interfaces and /if:interfaces-state as not-supported, the typedefs interface-ref and interface-state-ref then cannot resolve their respective paths (should strict checks be in place) Also keep in mind, I might only care about supporting an unrelated identity in this same module (e.g. interface-type) so no need to worry about schema-tree support whatsoever e.g. confdc/yanger will attempt strict resolving ietf-interfaces.yang:57: error: the node 'interfaces' from module 'ietf-interfaces' is not found ietf-interfaces.yang:658: error: the node 'interfaces-state' from module 'ietf-interfaces' is not found while pyang does not for instance in the same scenario... So this is either solved on the compiler side by relaxing checks for top-level non-schema tree nodes that have such refs that may be unresolveable or have the ability to deviate non-schema tree nodes > > > > Since you cannot deviate on anything other than schema tree nodes [See > > > > #2] (e.g. the typedef) and module A is using an unrelated identity, this > > > > poses a bit of an issue (Assume you must not alter/deviate module A > > > > directly) > > > > > > > > Now, this makes me think that for this to not happen, a best practice > > > > would be to always separate out identities, typedefs, etc.. from where > > > > schema trees are defined for such very cases (e.g. types modules) .... > > > > or introduce a method to be able to deviate non-schema tree nodes as > > > > such > > > > > > > > ** ietf-interfaces is one such module where you can see the > > > > interface-ref/interface-state-ref dependencies back to it's own schema > > > > tree > > > > > > > > For #2 - The wording around the deviation statement's target node in > > > > 7.20.3 specifies that this be a node in the schema tree as referenced by > > > > Section 6.5. Maybe I'm missing something but I'm not seeing any > > > > wording around RPCs and Notifications as being part of the schema tree > > > > whereas other statements such as 'typedefs' are not. As a side effect, > > > > this means that an RPC, Notification or top-level node in the schema > > > > tree cannot have the same name and must remain unique in nomenclature > > > > (as this is how they are each identified per their schema node > > > > identifier) > > > > > > > > This was a separate yet related question on what consists of a 'schema > > node' that can be referenced in the schema node identifier. The > > reference back to the 'schema node' definition answers this but I find > > the wording is fragmented among what consists of a schema tree and what > > does not. > > > > /martin
- [yang-doctors] Unsupported schema tree w/ cyclic … Ebben Aries
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Martin Bjorklund
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Ebben Aries
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Martin Bjorklund
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Ebben Aries
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Martin Bjorklund
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Ebben Aries
- Re: [yang-doctors] Unsupported schema tree w/ cyc… Juergen Schoenwaelder