Subject: Re: [netmod] yang-data-ext issues

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 01 Jun 2018 15:14:14 +0200

Juergen Schoenwaelder <[email-masked]> writes:

> On Tue, May 29, 2018 at 03:58:33PM +0000, Kent Watsen wrote:
>> [resurrecting this thread]
>> 
>> Currently the zerotouch draft has a normative reference to this draft.
>> I will this week post an update to the zerotouch draft to resolve the
>> netconf list thread "a couple zerotouch-21 issues".   It would be easy
>> for me to also switch back to using rc:yang-data, but I won't do so if
>> this draft remains an active work-in-progress.
>> 
>> Please see below for more.
>> 
>> 
>> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
>> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
>> >> 
>> >> The primary use case is not "generic RPC messages", but standalone
>> >> instance documents, error-info structures, etc.
>> >
>> > The proper solution for rpcs and actions is to define error
>> > information as part of the rpc/action. YANG 1.1 does not support
>> > this but this is where it should be fixed.
>> 
>> Agreed, but note that the subscribed-notifications draft (both the
>> published -12 and unpublished -13) are relying on being able to do
>> just this, and YANG-next is years away...
>
> There is a description statement.
>
>> > Standalone instance documents (not tied to datastores) may have their
>> > use cases as well but it feels odd to create support for standalone
>> > instance documents as extensions and then to create even more
>> > extensions to support augmentation of these instance documents and
>> > whoever knows what comes next.
>> 
>> What feels "odd" about this?  Is it not using the extension statement
>> as it was intended?

It is odd because RFC 7950 uses a lot of text to specify the special
context and then the extension attempts to remove parts of this context
(IMO incompletely). It would be much more logical to have a simple
context-agnostic YANG spec and then use extensions for adding
context-specific stuff.

Somebody who is only interested in this "yang-data" usage of YANG
still has to read all the nice CLRs in 7950 that only make sense for
NETCONF. 

>
> For me, extensions that define new data definition statements are
> borderline. RFC 7950 has this nice statement:

It is no borderline. The exception explicitly redefines YANG semantics
in its description.

>
>    o  extension: An extension attaches non-YANG semantics to statements.
>       The "extension" statement defines new statements to express these
>       semantics.
>
> This does not help since we lack a definition for 'non-YANG semantics'
> and yes I know that yang-data is today defined as an extension. But
> for me, this is a hack and instead of creating a slightly more
> generalized version of this hack, I prefer to stick to yang-data in
> favor of a proper solution as part of YANG.
>  
>> > For short-term needs, there is yang-data defined in RFC 8040.
>> 
>> To be clear, the "short-term needs" are:
>> 
>>   a) zerotouch: to define a standalone instance document
>>   b) notification-messages: to define a new notification message
>>   c) subscribed-notifications: to define error-info structures
>> 
>> As I recall, this draft (not RFC 8040) is needed:
>> 
>>   - for (a), because rc:yang-data doesn't support a top-level
>>     "choice" statement spanning "container" statements.
>
> So create a container.
>  
>>   - for (b), in order to augment a base yang-data "message" 
>>     structure with additional nodes.
>
> So you are creating another augmentation mechanism. I am concerned
> about ending up with a zoo of different mechanisms if we go down this
> path, we may end up with every project or vendor creating their own
> variants.
>
> With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
> operations and notifications. It is not a protocol message description
> language or a standalone file format description language. If this is
> needed, I prefer to create YANG X.Y - and if we manage the complexity
> we have something that is ideally integrated and consistent.
>
>>   - AFAIAA, RFC 8040 is sufficient for (c)
>> 
>> Has anything changed?   I don't think that we can un-adopt this
>> draft with said dependencies, right?
>
> I am just voicing my opinion. It may very well be that the WG prefers
> to go the route of not touching YANG 1.1 and instead patching around
> its limitations with extensions.
>
> My concern is simply driven that some want to patch in via extensions
> support for describing protocol messages and standalone documents,
> others want to patch via extensions and updates a different versioning
> system, and who knows what comes next. In the long run, I am afraid
> this will become a mess. And yes, it is always difficult to predict
> the future - we need crystal balls. Perhaps as an extension. ;-)

And, luckily, vendors probably haven't yet realized the potential of
extensions for creating proprietary YANG silos. This document should be
very instructive for them.

Lada

>
> /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/>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Jun 2018 18:56:59 +0000

The authors of yang-data-ext met today to discuss how to move this draft forward.  After about an hour, we decided that the best course of action is to:

  * clarify RFC 8040 rc:yang-data for the zerotouch use case
      - and update the zerotouch draft to use rc:yang-data

  * request this WG for the unadoption of this draft
      - the notification-messages draft solution is TBD

Can the working group, especially the chairs and the affected document authors (all CC-ed) please review this proposal?

Kent (and Andy and Martin) // as co-authors

---

From: Joe Clarke <[email-masked]>
Date: Mon, 25 Jun 2018 15:45:42 -0400

> Can the working group, especially the chairs and the affected document authors (all CC-ed) please review this proposal?

What about the ability to augment yang-data?  The proposed instance data
draft also makes use of yang-data-ext, and I have a use case to augment
some of its MD.  I realize this draft is not a WG item [yet], but I
wonder what the co-authors thought around the fate of the augments work.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Jun 2018 22:46:10 +0000

>> The authors of yang-data-ext met today to discuss how to move this
>> draft forward.  After about an hour, we decided that the best course
>> of action is to:
>> 
>> Can the working group, especially the chairs and the affected document
>> authors (all CC-ed) please review this proposal?
>

This is what I meant by "TBD" above.  Undoubtedly, the notification-messages
draft will need to see if there is another way to achieve its end and, if
not, we (NETMOD) will be asked to define an "augment-yang-data" draft, which
just defines the "augment" part of this draft on top of RFC 8040 rc:yang-data.

To those who say that we need a new version of YANG to do this properly, it
seems that we're making an argument for starting YANG-next now.

> Joe

Kent // as co-author