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

[Ebben Aries <[e-mail]>]

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

> > 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.