Re: [netmod] yang-data-ext issues

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 29 May 2018 17:09 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7944C12EB45 for <netmod@ietfa.amsl.com>; Tue, 29 May 2018 10:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obYjuUPIxHtt for <netmod@ietfa.amsl.com>; Tue, 29 May 2018 10:09:04 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id A97ED12EB20 for <netmod@ietf.org>; Tue, 29 May 2018 10:09:03 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 7A415219D7EC; Tue, 29 May 2018 19:09:00 +0200 (CEST)
Date: Tue, 29 May 2018 19:09:00 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20180529170900.qboedr2rmefsmblc@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com> <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com> <20180502.112506.845305331945500257.mbj@tail-f.com> <20180502093626.ugsg6nq24a6vjtdn@elstar.local> <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <64990DFB-CF50-401A-A4EF-B6161C8D227B@juniper.net>
User-Agent: NeoMutt/20180512
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ks10scWUVxVFgjfZY58TK8J5NSo>
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 17:09:07 -0000

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?

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

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

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