Re: [netmod] yang-data-ext issues

Andy Bierman <andy@yumaworks.com> Mon, 30 April 2018 17:48 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 E316F124239 for <netmod@ietfa.amsl.com>; Mon, 30 Apr 2018 10:48:37 -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 HDp88uoYCEgQ for <netmod@ietfa.amsl.com>; Mon, 30 Apr 2018 10:48:35 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 CFA121201F2 for <netmod@ietf.org>; Mon, 30 Apr 2018 10:48:34 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id g12-v6so13256955lfb.10 for <netmod@ietf.org>; Mon, 30 Apr 2018 10:48:34 -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; bh=Tjj2ykyBMWTTE8WJDEc3XDMbmxZFtvrAt3lDMK5R56w=; b=VvoLqP+ILHtskkZ7wi4HqZh8vCu163RuGKs73lShwTfri/gXlXxV9ElgXUuGrfZfp9 S7iw2YDWyXCzY8CpemLqgdjWDeqo7NJIKGmvX7thCIQwHh7Rp9d59R1sen80XuR65a7X 2Sbjs5FLSAFqyybkg/YppM4STasos1J75l86Gg0ZenpeDWPTHb6wJ/SihCU/s7lS+mVo 5kp+Z8O2sfAi0eNNu9kMdYRMHkETzLagHMbd0A+GdoAE51Hdd8L1m2TBqxCZ1cL/Ds4Q reUXCq+vKogvpfQf0Yar5629Uxe/ichbqRur4w2PQYInie7EhjHzAdhQEtIPaO3tzMKy Su/Q==
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; bh=Tjj2ykyBMWTTE8WJDEc3XDMbmxZFtvrAt3lDMK5R56w=; b=F5Cf+FzJk6CDgs/DhTllCqMCypcQ7eT/uEhSmauCFDhxQl1PuPxvDPhS/bpU/MpH0U JwsAsQLh0ZXcU+HY2Q/6O7YJ0dQCRaSDRGJXhy2/YZYi8ptHXxuibNxWeL0Kv0pzOP69 s1h8k0MWkrTrPSY7ZfpEmYzOzCe0o6cGYGPPK8F61z4rURDgkUwtGlqvONawv+T/EyMC O+KvfZp+6A71KuMkHob/4keu173yEFB7myQt1br+zuXe46M6xbo+emuYJbBjCZSFJKlU hHzzHR000NWUBZOlXYpUr6wu568mVh3XZd8ppolnA8NsJRBNED47CcxM3XK7kZZHOFT2 8llg==
X-Gm-Message-State: ALQs6tB8wMy7ctdPswtW/BP6N3xC4vUnfr7Oy89bde+7f33SVr5Lplj+ HE6CFr+83el5L1rvZf2BBMmhAgYWPbZzVtcDvrTkLA==
X-Google-Smtp-Source: AB8JxZq7qhsK+EKSduBA6a5tioxT9O4Hs8lcohLGeqsooOPp7VzlKoGRqGboOk4h0BrjQDGwu0vnSGW5LsGIpw8sEFs=
X-Received: by 2002:a19:2092:: with SMTP id g140-v6mr8146505lfg.38.1525110512982; Mon, 30 Apr 2018 10:48:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 10:48:31 -0700 (PDT)
In-Reply-To: <87d0yglra0.fsf@nic.cz>
References: <87muxq1pk9.fsf@nic.cz> <CABCOCHSwB8m6Uk82MZHnjnVi=0ofRohqEPT0Q06NM=+3n5gtFA@mail.gmail.com> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <b9211ebacd24ffdd558ecf4da5bfa1ad71cfdabb.camel@nic.cz> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com> <87d0yglra0.fsf@nic.cz>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 30 Apr 2018 10:48:31 -0700
Message-ID: <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005eb011056b1476d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/uJ0X81JKjom65xI3Ly0wiu09-Tw>
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: Mon, 30 Apr 2018 17:48:38 -0000

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.



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