Re: [yang-doctors] Unsupported schema tree w/ cyclic dependencies + schema node identifier clarification
Martin Bjorklund <mbj@tail-f.com> Sat, 23 March 2019 08:37 UTC
Return-Path: <mbj@tail-f.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 354FA127985 for <yang-doctors@ietfa.amsl.com>; Sat, 23 Mar 2019 01:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0EtwvBHqfY5O for <yang-doctors@ietfa.amsl.com>; Sat, 23 Mar 2019 01:37:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91167127990 for <yang-doctors@ietf.org>; Sat, 23 Mar 2019 01:37:45 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id B281F1AE039A; Sat, 23 Mar 2019 09:37:42 +0100 (CET)
Date: Sat, 23 Mar 2019 09:37:42 +0100
Message-Id: <20190323.093742.1114866601397885600.mbj@tail-f.com>
To: exa@arrcus.com
Cc: yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20190322224711.sglgrvgfrqu7bosw@localhost>
References: <20190322001243.qek4neyeee4ezspl@localhost> <20190322.101406.1388195451706941171.mbj@tail-f.com> <20190322224711.sglgrvgfrqu7bosw@localhost>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/JpkdNkuQ5Cx7T6cyDrqCcTPCuxg>
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 08:37:47 -0000
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. > > > 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