Re: [yang-doctors] Unsupported schema tree w/ cyclic dependencies + schema node identifier clarification

[Ebben Aries <[e-mail]>]

On Mar 24 16:27 PM, Martin Bjorklund wrote:
> Ebben Aries <[e-mail]> wrote:
> > On Mar 23 09:37 AM, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Ebben Aries <[e-mail]> wrote:
> > > > Thx Martin - see inline...
> > > > 
> > > > On Mar 22 10:14 AM, Martin Bjorklund wrote:
> > > > > Hi,
> > > > > 
> > > > > Ebben Aries <[e-mail]> 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
> 
> I view this as a bug in the compiler!
>

I agree.  It seems section 9.9 covers some of this to come to the
conclusion that strict checks as such should not be in order if a
require-instance statement is not in use however the problem here is a
bit different in attempting to resolve a schema node that does not exist
at all due to the deviation (which could fall into the same category I
suppose)

The issue is more so resolving rather than if a schema node exists or
not so it's probably worth some additional wording in this section or
5.4 don't you think?


> > 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
> > 
> 
> 
> 
> /martin