Re: [netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Wed, 02 May 2018 09:25 UTC

Return-Path: <mbj@tail-f.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 B799A12D965 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 02:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 YDfuGmlz3_7O for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 02:25:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E7DFC12D95F for <netmod@ietf.org>; Wed, 2 May 2018 02:25:07 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id BF3531AE012C; Wed, 2 May 2018 11:25:06 +0200 (CEST)
Date: Wed, 02 May 2018 11:25:06 +0200
Message-Id: <20180502.112506.845305331945500257.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com>
References: <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com> <20180502.092527.2305319833268262996.mbj@tail-f.com> <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MrN9-6kV4fIcNlb5bbSpjBDYnKc>
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, 02 May 2018 09:25:29 -0000

Robert Wilton <rwilton@cisco.com> wrote:
> 
> 
> On 02/05/2018 08:25, Martin Bjorklund wrote:
> > Andy Bierman <andy@yumaworks.com> wrote:
> >> On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka <lhotka@nic.cz>
> >> wrote:
> >>
> >>> Andy Bierman <andy@yumaworks.com> writes:
> >>>
> >>>> On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka <lhotka@nic.cz>
> >>>> wrote:
> >>>>
> >>>>> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
> >>>>>> On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
> >>>>>>
> >>>>>>> [...] define a special datastore for it, such as "error-messages".
> >>>>>> This seems worse than using, well, RFC 8040 yang-data. The proper
> >>>>> Why it seems worse?
> >>>>>
> >>>>>
> >>>> Because this is not part of the NMDA.
> >>> NMDA is extensible.
> >>>
> >>
> >> If your only tool is a hammer, then all your problems look like nails.
> >> I fail to see how an "error-messages" datastore fits in with NMDA
> >>
> >>
> >>
> >>>> IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> >>>> is sufficient for that purpose, which is a YANG representation of
> >>>> an instance document (such as a protocol message or file).
> >>> The same is basically true even without the extension. For example, I
> >>> fail to see any benefit from using yang-data in a module like
> >>> ietf-zerotouch-information.
> >>>
> >>
> >> I don't see the benefit of pretending all data-def-stmts represent
> >> configuration or operational data.
> >>
> >> Wrapping the data-def-stmts in an extension says "this is not
> >> configuration
> >> or operational data".  This is useful for tools that can process YANG
> >> in
> >> other contexts.
> > I fully agree
> 
> YANG already models RPCs, and 7950 makes it clear that the
> input/output parameters of those RPC statements are not configuration
> or state and are not modeled in datastores.  I.e.:
> 
>    Since the input tree is not part of any datastore, all "config"
>    statements for nodes in the input tree are ignored.
> 
> 
>    Since the output tree is not part of any datastore, all "config"
>    statements for nodes in the output tree are ignored.
> 
> 
> Isn't the YANG data extension just modelling fragments of YANG to be
> used in generic RPC messages?

The primary use case is not "generic RPC messages", but standalone
instance documents, error-info structures, etc.

> This doesn't seem to be a fundamental change in YANG's scope, or
> architecture.

I agree.


/martin


> 
> Thanks,
> Rob
> 
> 
> >
> >>>> YANG is useful for defining data structures that can be represented in
> >>>> different formats, yet it is independent of any 1 format.
> >>> Of course I see this potential. Unfortunately, YANG spec was
> >>> explicitly
> >>> written for a very specific context. Using an extension for removing
> >>> this specificity is IMO an ugly hack that undermines the architecture.
> >>>
> >>>
> >> I don't see the architecture as fragile or damaged if yang-data is
> >> used.
> >>
> >> People are going to continue to push the boundaries of YANG
> >> capabilities.
> >> This will happen with or without the IETF.
> > Yes, and it already happens.
> >
> >
> > /martin
> >
> >
> >
> >> Maybe this work should remain
> >> proprietary or get moved to an opensource project.
> >>
> >>
> >>
> >>
> >>>> I am in favor if keeping the yang-data in RFC 8040 and not
> >>>> creating a new version of it that is unconstrained.
> >>>> There does not seem to be consensus on how to do this,
> >>>> or even consensus that it is a good idea.
> >>>>
> >>> If the extension is deemed necessary, I would also prefer this
> >>> approach
> >>> to making the extension a Proposed Standard.
> >>>
> >>> Lada
> >>>
> >>
> >> Andy
> >>
> >>
> >>>>
> >>>>>> clear solution for RPCs and actions would be to enable the definition
> >>>>>> of error details right in the rpc/action definition (input, output,
> >>>>>> error).
> >>>>> Agreed.
> >>>>>
> >>>>>> But something like yang-data seems to have uses in other contexts.
> >>>>> So other datastores may be defined. I assume that YANG library data
> >>>>> can
> >>> be
> >>>>> used
> >>>>> independently, not just on a NC/RC server, pretty much along the lines
> >>> of
> >>>>> draft-
> >>>>> lengyel-netmod-yang-instance-data.
> >>>>>
> >>>>> Lada
> >>>>>
> >>>> Andy
> >>>>
> >>>>
> >>>>
> >>>>>> /js
> >>>>>>
> >>>>> --
> >>>>> Ladislav Lhotka
> >>>>> Head, CZ.NIC Labs
> >>>>> PGP Key ID: 0xB8F92B08A9F76C67
> >>>>>
> >>>>> _______________________________________________
> >>>>> netmod mailing list
> >>>>> netmod@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>>>
> >>> --
> >>> Ladislav Lhotka
> >>> Head, CZ.NIC Labs
> >>> PGP Key ID: 0xB8F92B08A9F76C67
> >>>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
>