Re: [netmod] yang-data-ext issues

Andy Bierman <andy@yumaworks.com> Wed, 25 April 2018 10:10 UTC

Return-Path: <andy@yumaworks.com>
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 1909712DA13 for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 03:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 QmwFSHU0FxlJ for <netmod@ietfa.amsl.com>; Wed, 25 Apr 2018 03:09:48 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D34212DA1D for <netmod@ietf.org>; Wed, 25 Apr 2018 03:09:47 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id r125-v6so24621186lfe.2 for <netmod@ietf.org>; Wed, 25 Apr 2018 03:09:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=By8rIUcyvFGeIVr8FvIhqbsvOB4ygxxHgSdR3q8VUGw=; b=kEPy4myswUCha06M6sUh1dUmYoBFpGdmXMqkCMIVwgw7ySggzzHmd5z7cqZ0NqcHE9 hCkfk3RLvdQn8T4p8PV9aZPFbUiYSlZ6BUjkpq1a8aJP+sQhDgMKYai0JU5SSHyHq0Zd 2C7Ob3idHVnFafr9hCYXL6ui/xzn8HUR446oEUUcC0kvHctbVjE4RWxEID8S3toGqKUB 9wcUr5QmUbdF1ux00uykvgLCc1pMNgB8VjXrB1NN3AusQw4WqkSnuVzuo0Gbuqapg8Q4 w1f81akE9+HfRJY80z8PUZXeWZEO31R7/jszpLubOA8DsJ4F8ncslNKeMEmS97F0hRNR TJiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=By8rIUcyvFGeIVr8FvIhqbsvOB4ygxxHgSdR3q8VUGw=; b=GtxYCtdO8oPg8pxR5rN8BE3ABP1A47QeXHXBdgySSE0p+HgiPTLSGhjat56E8xKsk0 7LLGJIWM43GaL1MazzvlglLAAmLY1F474cylIgQdWb2o0KzwcdClEVT8P+P6NwrEoWpp ll9/PfJokL/M5XxCwGtnrtKQDNAtPHsVp+G39srP6Arw/2p3CL7Gq8FC503zY2zDSbhj qqWC4yd3Zn8ukVccLvJeiKCVZEWcxK3qc/44Je7DAwh55iIF8h0tYRbLqvHaR9OvTjji 6m6c2hFhGfB/Za2ofz8KSXbyAdYjWyKs3Hu7fNmWIcxr3WKlDTc4+N2geSGT2jcARdN6 e5SQ==
X-Gm-Message-State: ALQs6tBARUWNrWV61XfIv9ROFKd5oeI768uUmaLWi6fbiaxvdcMOhgPN uXwiTwzHbrxeFTsZu1LcI51qXbJa76jmY9eIJ3GgK2Ny
X-Google-Smtp-Source: AB8JxZpkwo0Pe1Qnf5YrcQYN0/KMIqr93US4WbT7lp8uPii5k6HvQNo9N8iGz6zyWxMvB775x27+3hjBCYjpXEsGd8U=
X-Received: by 2002:a19:93ce:: with SMTP id w75-v6mr14209624lfk.38.1524650985312; Wed, 25 Apr 2018 03:09:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 03:09:44 -0700 (PDT)
In-Reply-To: <20180425.085751.1552281751468645335.mbj@tail-f.com>
References: <20180423.220815.526647366558506966.mbj@tail-f.com> <CABCOCHTt3noQ5PcX57yGi5Cm7BxQA=GCB9KajrWS2WLnYM9THA@mail.gmail.com> <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> <20180425.085751.1552281751468645335.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Apr 2018 03:09:44 -0700
Message-ID: <CABCOCHSKuc5sSehZRkUi8vyZwr0zL9k+ET+a4e4hyuw1Z++bjg@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Kent Watsen <kwatsen@juniper.net>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062eab6056aa97871"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/R_Zn0t4BIsHZkS_r2BxzS7SKIis>
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: Wed, 25 Apr 2018 10:10:02 -0000

On Tue, Apr 24, 2018 at 11:57 PM, Martin Bjorklund <mbj@tail-f.com>; wrote:

> Kent Watsen <kwatsen@juniper.net>; wrote:
> >
> > > People want to use YANG to define the schema for an XML or JSON
> > > representation of a stand-alone document.
> >
> > Agreed
> >
> >
> > > The only data needed must be module + local-name.
> >
> > Or maybe: module + local-name + context, where context is one of:
> >
> >   - data nodes
> >   - RPC/actions
> >   - notifications
> >   - standalone artifacts (files)
>
> I don't think we should use yang-data to model notifications.
> Presumably you meant error-info from rpc or action.
>
> And my point it is that I think that we should make yang-data
> flexible enoough in itself, and not constrain it to the one or two use
> cases we know now.
>
> > At least, it seems that these are different things.
> >
> > [Note: RESTCONF places some of the context into the URL; two different
> > data node resources can have identical module + local-name.]
> >
> > It would be bad if two stand-alone artifacts had the same
> > module+local-name (foo:bar).  However, it's okay to have a matching
> > top-level data node called "foo:bar", since it is used in a different
> > context.  Just like yang-data cannot be accessed as data via a
> > protocol like NC or RC, so it is that traditionally-defined data nodes
> > cannot be accessed as a stand-alone artifact (unless you’re a
> > draft-author and need an instance document for an example).
> >
> >
> > > Defining an extension that maps error-info data for a specific RPC
> > > might be
> > > something worth standardizing.  It should not be done with yang-data,
> > > but rather a different extension just for this purpose.
> >
> > Martin wrote before:
> >
> >             (maybe in the future we could even have a YANG extension
> statement
> >             to
> >             formalize the description:
> >
> >                rpc my-first-rpc {
> >                  ...
> >                  opx:error-info-structure my-first-rpc-error-info;
> >                }
> >
> >             but this is not point now.)
> >
> > I imagined that he was hoping to limit what's needed to get
> > draft-ietf-netconf-notification-messages out the door now, but I think
> > another I-D should be proposed to augment the 'rpc' and 'action'
> > statements with an anydata called "error-info-structure" so the YANG
> > would be more like this:
> >
> >                rpc my-first-rpc {
> >                  ...
> >                  opx:error-info-structure my-first-rpc-error-info {
> >                      …
> >                    }
> >                }
>
> No I was thinking along the lines of:
>
>   ydx:yang-data my-first-rpc-error-info {
>     ...
>   }
>
>   rpc my-first-rpc {
>     ...
>     opx:error-info-structure my-first-rpc-error-info;
>   }
>
> I.e., use yang-data to define a structure, and use another statement
> to tie them together.
>
> If we define special statements with inline structures, we probably
> also need special augment statements; with your example:
>
>
>   rpc my-first-rpc {
>     ...
>     opx:error-info-structure my-first-rpc-error-info {
>       ...
>     }
>   }
>
>
>   opx:augment-error-info-structure '/m:my-first-rpc'
>                                  + '/m:my-first-rpc-error-info {
>     ...
>   }
>
>


This could easily be defined to use groupings instead:



  grouping my-first-rpc-error-info {
    ...
  }

  rpc my-first-rpc {
    ...
    opx:error-info-structure my-first-rpc-error-info;
  }


 There is no need to reinvent the grouping.



> /martin
>
>

Andy



>
>
>
> > That is, to your point, with no reference to a yang-data data
> > structure.
> >
> >
> > > Andy
> >
> > Kent // contributor
> >
>