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

[Ebben Aries <[e-mail]>]

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

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

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.

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)

/ebben