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

From: Ebben Aries <[email-masked]>
Date: Fri, 22 Mar 2019 00:12:46 +0000

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Mar 2019 10:14:06 +0100 (CET)

Hi,

> of a module where other non-schema statements have a cyclic dependency

Is this a separate question from 2 below?  If so, I don't understand
the question.  If it the same, please see below.

> and use of identities only (e.g. module A).

The server would advertise module B as conformance-type = import in
the YANG library.

> schema tree, you cannot deviate the entire tree as this breaks the

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.

/martin

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Ebben Aries <[email-masked]>
Date: Fri, 22 Mar 2019 22:47:13 +0000

Thx Martin - see inline...

> the question.  If it the same, please see below.

Yes, these were 2 separate questions - see below

> The server would advertise module B as conformance-type = import in

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)

> 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

> > (as this is how they are each identified per their schema node

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.

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 23 Mar 2019 09:37:42 +0100 (CET)

Hi,

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

/martin

---

From: Ebben Aries <[email-masked]>
Date: Sat, 23 Mar 2019 16:52:11 +0000

> typedef that you can't support, you have to deviate these leafs as

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Mar 2019 16:27:31 +0100 (CET)

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

/martin

---

From: Ebben Aries <[email-masked]>
Date: Sun, 24 Mar 2019 16:59:43 +0000

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Mar 2019 19:30:25 +0100

> at all due to the deviation (which could fall into the same category I

In the general case, it is desirable that compilers generate warnings
or errors when schema nodes are referenced that have no definition
(regardless of require-instance).  Whether this is a warning of an
error may be context dependent, for example, a typedef with a
reference to something undefined is likely just a warning as long as
the defined type is not used but it becomes an error if the defined
type is used by a leaf or a leaf-list.

In your particular case, the compiler knows that the schema node is
defined and the compiler knows that it got deviated away. Hence, the
compiler can stay silent as long as the typedef is not used.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>