Re: [netmod] yang-data-ext issues

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> Ladislav Lhotka <[e-mail]> wrote:
>> Robert Varga <[e-mail]> writes:
>> 
>> > On 23/04/18 18:51, Juergen Schoenwaelder wrote:
>> >> Some people will say that the cost of a new language version is high.
>> >> (Well, when we did 1.1, some people said it will never be deployed.)
>> >> Anyway, not bumping the YANG version number but having instead several
>> >> (optional) language extensions is just hiding the version number
>> >> change under the carpet.
>> >
>> > Not quite, as extensions allow for modular/incremental evolution, as an
>> > implementer I do not have to go through a long development cycle where I
>> > need to rewire language aspects just to get the features my users need
>> > for their models...
>> 
>> But what prevents you from forking YANG, indicating it in the
>> "yang-version" string and implementing your new statements as built-ins?
>> 
>> It is tempting to think about extensions as a magic for adding modular
>> extensions but it breaks down as soon as such extensions interfere with
>> the YANG core (with and each other, or both).
>
> Sure, nothing new here.  This is how the extension mechanism is
> designed.  Do you feel that there are so many standard extensions that

My objections are also not new. Implementations are permitted to ignore
extensions, but if an extension affects the resulting schema, then
implementation A that supports the extension may end up working with
another schema than implementation B that doesn't support the
extension. This situation has to be avoided.

> interfere with each other that we actually have a problem?  I strongly

Perhaps not yet, but we do have extensions (or proposals thereof) that
interfere with core YANG. And my impression is that OpenConfig is going
to use extensions for creating their own YANG silo.

> agree that we need to be careful with standard extensions, and I
> strongly encourage vendors to not define extensions that interfere
> with YANG core (been there, done that, bad idea).
>
> In the case of yang-data, the fact is that it *is* used in standard
> models (in ways not originally anticipated), and vendors have similar
> proprietary extensions (we have a tailf:structure, and I think others
> have reported similar things).

I don't know how much effort those vendors invested into the
specification of such extensions, but the text of the current draft and
module descriptions leave quite a few questions unanswered. Here are
just a few that come to my mind:

- What is the accessible tree for XPath evaluations and leafrefs? In
  particular, error messages might want to refer to state data. Is it
  possible?

- This sentence makes no sense: "The XPath document root is the
  extension statement itself, ..." A YANG statement cannot be an XPath
  node.

- What is the meaning of leaf and leaf-list default values? In RFC 7950
  it is defined in terms of server behaviour but there is no server for
  yang-data.

- What does it mean if an action is defined inside yang-data?

- If a module is imported without revision and its groupings/typedefs
  are used inside yang-data, how is the exact revision of the imported
  module determined?

I suspect that users of such extensions accept the fact that some amount
of hand-waving is necessary. But then, why all this hassle? Why cannot
normal YANG be used for specifying a schema that is not intended for an
NM protocol? It requires just a little bit more hand-waving. The draft
doesn't explain why the extension is needed.

Also, I am quite sure that YANG experts can use it carefully so that it
makes sense. But as a Standard Track document it becomes an official
part of YANG that seems to give unsuspecting users enough rope for
hanging themselves.

Lada

>
>
>
> /martin

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67