Re: [netmod] instance file parsing

Robert Wilton <rwilton@cisco.com> Mon, 03 December 2018 10:21 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 1B6E9130E19 for <netmod@ietfa.amsl.com>; Mon, 3 Dec 2018 02:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Level:
X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 o6qDnPsIY_mm for <netmod@ietfa.amsl.com>; Mon, 3 Dec 2018 02:21:23 -0800 (PST)
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 AADAD12875B for <netmod@ietf.org>; Mon, 3 Dec 2018 02:21:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3703; q=dns/txt; s=iport; t=1543832482; x=1545042082; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CXMKJ76/CoujFQLdwI7lRe1HWcl+x8QtkWozBOwqMKk=; b=Ek4RpsLwfWUvvYy4OA4yeJkb4krDyfCc+hA1bBFDw8E6Pf5sSrLLRlVC Vmj7kEJqpOo1e16qeKgTWZo2D+2hGP1+riMvYEz28aWySU42UzwTJ35eO +CMVRzVPzRpqkhYqeNtva7yqY82TaAdqzFOR9dTv5aXQDCgWsDpZ6kJgl w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAABoAgVc/xbLJq1iGQEBAQEBAQEBAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmlwEieDeYh3jQoIJZdIgXoNGAuEA0YCg2M2Bw0BAwEBAgEBAm0cDIU8AQEBAwEBASEPAQU2EAsLGAICJgICJzAGAQwGAgEBgx0BgXkID6RggS+FQIRZBYELiyiBQD+BOAyCX4MeAQGBS4MagjUiAolehVCREgmRNgYYiWuHO4kEiQGGaIFNByqBVTMaCBsVO4JsixyFPz8DMItzAQE
X-IronPort-AV: E=Sophos;i="5.56,310,1539648000"; d="scan'208";a="8487774"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2018 10:21:20 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wB3ALKdT015466; Mon, 3 Dec 2018 10:21:20 GMT
To: Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
References: <CABCOCHQYR_iY7Lp=0m8D-GQ8+Rzuijaa8_41bJw6ZvWPc+Cw_w@mail.gmail.com> <b2ee0537-465a-fbc0-1b94-000da5993b05@cisco.com> <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com>
Date: Mon, 03 Dec 2018 10:21:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PIy5CcVWDpWBweyqBu9JXa-06YU>
Subject: Re: [netmod] instance file parsing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 03 Dec 2018 10:21:25 -0000

On 30/11/2018 19:28, Juergen Schoenwaelder wrote:
> I doubt it makes sense to carry an entire yang library schema with the
> instance data. The modules are actually known via the namespaces.

Knowing the module name or namespace isn't sufficient to be able to 
parse the data:
  - E.g. if the contents are in the format of RFC7895bis, but the client 
tries to parse it using the schema from RFC7895, then it will fail.
  - Once NBC changes are allowed via YANG versioning it will become more 
necessary to know the revision or version of the modules to be able to 
parse the data.  E.g. not even just the latest module revision will 
necessarily work.   It is entirely plausible that different server 
revisions may be generating instance data using slightly different schema.

If the server has deviations then the client may also need to know those 
deviations to correctly parse the file.

So, I think that it is pretty clear that knowing the right schema is 
required to be able to correctly parse and interpret the instance data.

I think that there are 4 ways that this can be achieved:
  1) embedded the necessary schema information into the YANG instance data.
  2) put the necessary schema information online somewhere and have a 
URI reference to it.
  3) some combination of (1) and (2), e.g. packages defined centrally, 
with deviations listed in the file.
  4) the schema is determined using some out of bound mechanism, or 
possibly it is hard coded.

I don't think that there is a one size fits all answer here.  I think 
that that it depends on the use case.  Certainly, I think that 
facilitating 1 -3 is useful, but they should be optional rather than 
mandatory.  I.e. defining nodes for these doesn't seem to cost much if a 
server isn't obliged to populate them.

I do think that YANG packages (themselves defined in instance data 
documents) could be very helpful here.  I.e. rather than listing all the 
modules, instead list the packages + any deviations from that.  I'm 
presuming here that the definitions of the packages are available via a URI.


>   If
> you want to capture the schema, dump the relevant yang library into
> another instance file.

That just means another file to carry around and manage.

Thanks,
Rob


>
> /js
>
> On Fri, Nov 30, 2018 at 07:07:03PM +0000, Robert Wilton wrote:
>> I also think that the instance data header needs to have a way of indicating
>> which modules (and versions/revisions) the instance data applies to.
>>
>> It can be optional, so producers that know it is not required can leave it
>> out.  But I think that it is required, at least for situations where being
>> able to programmatically consume the instance data in a robust way is
>> important.
>>
>> Thanks,
>> Rob
>>
>>
>> On 30/11/2018 17:48, Andy Bierman wrote:
>>> Hi,
>>>
>>> I don't see much standards value in this draft so far.
>>> It seems the parser of the file needs to know the YANG library information
>>> for the instance file data in some out-of-scope non-standard manner.
>>> This is what we already have today just by naming the file in a specific
>>> way.
>>>
>>> Is the intent that the instance-data-set leafs will be used to determine
>>> the module revisions, features, and deviations used in the children
>>> or the 'data' node?
>>>
>>> Andy
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>