Re: [netmod] yang-data-ext issues

Robert Wilton <rwilton@cisco.com> Wed, 02 May 2018 09:02 UTC

Return-Path: <rwilton@cisco.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 55A1112D877 for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 02:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 z3OuGnUNijsp for <netmod@ietfa.amsl.com>; Wed, 2 May 2018 02:02:46 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8AD12D872 for <netmod@ietf.org>; Wed, 2 May 2018 02:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14044; q=dns/txt; s=iport; t=1525251765; x=1526461365; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=2hP6e5Sls/MMfn1/OEKI9x9H6Q5vxDnjdO/pd/qKOM8=; b=nCUVQRjci/ZwyRqb330zULJ8KIdLdjXYTXeUHEpYSCiagzYoJHq9cCv8 CRZV5Hb2ZAeQQdZ4SI6pz4VLw/rAn2BoB3oACsmlZAGEpZQFV+bTr2ORc jT9Oxhqo8Rp2O5pN0NmtzjumC4AL8ifOlZXuHM2L8F3zTO/otO5Dw9N1P o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQA9fela/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYJNgVcXYyiDbYhgjhGBD44nhHCBeAsYAQqEA0YCgx41FwECAQEBAQEBAmwcDIUpAQEBAwEBIUsLEAsOBAYqAgInIg4GAQwGAgEBF4R0D6gkghwfhDmDa4I9BYltP4EPI4JogxEBAYFKgxaCVAKQd4cdCI5FBodOhQmLGoUjgSUeAjSBUjMaCBsVO4JDixCFPz4wkC8BAQ
X-IronPort-AV: E=Sophos;i="5.49,354,1520899200"; d="scan'208,217";a="3510764"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 09:02:43 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w4292gF5010436; Wed, 2 May 2018 09:02:43 GMT
To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, Ladislav Lhotka <lhotka@nic.cz>
Cc: netmod@ietf.org
References: <CABCOCHSKfDCOpQJ4bX2ueHSj-e90ZyHVC1z3h9WMfPkn2OMMvw@mail.gmail.com> <87d0yglra0.fsf@nic.cz> <CABCOCHSupojOLssLebB-mR_PybRLA_4bcbaNF6-8ZUrx1Pu53w@mail.gmail.com> <20180502.092527.2305319833268262996.mbj@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <9fca04b0-fb29-36b3-67aa-2f2c4fb98748@cisco.com>
Date: Wed, 02 May 2018 10:02:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180502.092527.2305319833268262996.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------0DAA4355C3A45A51E574481A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Owr15-b_vpjh4cyTVimSoam7_kU>
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:02:49 -0000


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?

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

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