Re: [netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Wed, 02 May 2018 07: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 B5FA812D947 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:25:30 -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 fWTlsuhsEf1u for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 00:25:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5C126CB6 for <netmod@ietf.org>; Wed, 2 May 2018 00:25:28 -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 2B5FC1AE012C; Wed, 2 May 2018 09:25:27 +0200 (CEST)
Date: Wed, 02 May 2018 09:25:27 +0200 (CEST)
Message-Id: <20180502.092527.2305319833268262996.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com>
References: <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com> <87d0yglra0.fsf@nic.cz> <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DscSJVzqrqlAkP2gGe0h4TMvWX8>
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 07:25:31 -0000

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