Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Mon, 30 April 2018 14:09 UTC

Return-Path: <lhotka@nic.cz>
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 9D42D12DA54 for <netmod@ietfa.amsl.com>; Mon, 30 Apr 2018 07:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZgkHPtO4-dMV for <netmod@ietfa.amsl.com>; Mon, 30 Apr 2018 07:09:41 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12E1E12DA53 for <netmod@ietf.org>; Mon, 30 Apr 2018 07:09:40 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 0FC36182015B; Mon, 30 Apr 2018 16:14:44 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 08C5E1820157; Mon, 30 Apr 2018 16:14:41 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NetMod WG <netmod@ietf.org>
In-Reply-To: <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com>
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>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NetMod WG <netmod@ietf.org>
Date: Mon, 30 Apr 2018 16:09:43 +0200
Message-ID: <87d0yglra0.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FB430AfiEIdMVieb3vwDvkrrnlE>
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 14:09:44 -0000

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.

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

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

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