Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00

Robert Wilton <rwilton@cisco.com> Fri, 01 February 2019 11:25 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 6A27412DF72 for <netmod@ietfa.amsl.com>; Fri, 1 Feb 2019 03:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.053
X-Spam-Level:
X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 STTnos9NQ1J8 for <netmod@ietfa.amsl.com>; Fri, 1 Feb 2019 03:25:44 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753A513121D for <netmod@ietf.org>; Fri, 1 Feb 2019 03:25:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8365; q=dns/txt; s=iport; t=1549020343; x=1550229943; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ABAN3w4Xd+KkVjVorlGjLRFGKUn70AXu7a/8u0o1VLU=; b=dBWe0j6hQQWr+ujtTWYCvQrjjfrawMwYsLpX9UREJLc2MrfMryMGRyk9 3YolSwQkpKdu591vFa+Nfdng1A+4za5YNgNkOivq6JERLuS0QtdDugHrJ +lSfZEH1PqvT4ncE0XfA7YrCN7EebJ67S8dQJV/4KS7MK0UFol/JGx5Rv I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAAAULFRc/xbLJq1kGgEBAQEBAgEBAQEHAgEBAQGBUwMBAQEBCwGCalABMieEA4h5jSCYDoF7DRgLhANGAoMyNgcNAQMBAQIBAQJtHAyFSgEBAQMBAQEhDwEFNhsLGAICJgICJzATBgIBAReDBwGBeQgPqgaBL4VDhG4FgQuLTIFAP4ERJ4Jrgx4BAYFLgx+CVwKKJoxki1kJkjAGGYpBh36UW4cegU0BMIFWMxoIGxU7gmyCJxeIX4U/PwMwjHYBAQ
X-IronPort-AV: E=Sophos;i="5.56,548,1539648000"; d="scan'208";a="9745865"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2019 11:25:41 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x11BPenX011459 for <netmod@ietf.org>; Fri, 1 Feb 2019 11:25:41 GMT
To: netmod@ietf.org
References: <877eemjj2g.fsf@nic.cz> <b6b679bb-9f79-7f47-1bce-91ea54f790de@cisco.com> <87zhrhncyy.fsf@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <1ce25f88-671a-de6f-826e-645b70b753f2@cisco.com>
Date: Fri, 01 Feb 2019 11:25:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <87zhrhncyy.fsf@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/g5dVtZROXq5K53R5Q18BquuITmQ>
Subject: Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00
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: Fri, 01 Feb 2019 11:25:47 -0000

Hi Lada,

On 31/01/2019 14:00, Ladislav Lhotka wrote:
> Robert Wilton <rwilton@cisco.com> writes:
>
>> Hi Lada,
>>
>> Thanks for the review and comments ...
>>
>> I've added some thoughts inline ...
>>
>> On 30/01/2019 14:50, Ladislav Lhotka wrote:
>>> Hi,
>>>
>>> I think it is a good start, here are my comments (some of them were
>>> already raised by Jason):
>>>
>>> - I like the fact that this work doesn't require any changes to YANG,
>>>     except perhaps semver.
>> RW: OK.
>>
>>
>>> - I think the augments to YANG library is a separate problem that should
>>>     perhaps be addressed in a different document. Servers supporting
>>>     multiple package revisions may not be that common.
>> RW:
>>
>> I completely agree that servers supporting multiple package revisions
>> may not be that common, and I agree that any specification on how a
>> server could support multiple packages, and perform package selection
>> should be in a separate draft.
>>
>> But the YANG library augmentations aren't there only to support this use
>> case.  My intention is to make it easier for devices to advertise a
>> package representing what each datastore schema is rather than having to
>> fetch the full contents of YANG library.
>>
>> E.g. a server might implement 900+ modules/sub-modules for a given
>> release.  Different hardware will mostly implement the same modules, but
>> there might be some differences.  If bugs have been patched then there
>> might be some differences.  I'm aiming for a solution where a client
>> doesn't have to fetch the full list of YANG modules for each server to
>> figure out the schema for the device, which is probably the same as
>> another 1000 devices in the network.
>>
>> Instead, I would like the vendor to publish a package for that
>> particular release, with variants depending on the hardware.  The device
>> can then advertise that it uses that base package, along with the small
>> set of differences (e.g. due to bug fixes).
>>
> OK, I missed this purpose. Perhaps one of the examples can be expanded
> to illustrate this situation.

RW: Yes, that is a good suggestion.  I will try and make this more clear 
in the draft.


>
> But doesn't it defeat the purpose of packages? Even if I know that my client
> works with package X, it needn't be the case with the vendor's changes.

RW:

So packages cannot themselves magically help vendor devices more 
faithfully implement the standard YANG models.  I think that over time 
this will likely improve, but probably is somewhat hampered by having 
two competing sets of industry standard YANG models. But there are a 
couple of ways that I feel that packages that they can help:

1) They can help indicate what functionality a server is trying to 
conform to, better than just a flat list of modules.  E.g. through the 
package inclusion, the client could see that a vendor is attempting to 
implement ietf-l2vpn-pkg@v1.0.0.

2) The package definition should aim to make it more clear where the 
server deviates from the package.

On that second point, Jason was querying whether the package definition 
should list deviations for each module, but thinking about this a bit 
more, I wonder whether it would be helpful if when a package was 
imported, any deviations, or module version down revs, are explicitly 
listed at the point where the package import is defined.  I.e. to make 
the package deviations really explicit.


>>> - I was expecting that a package could specify a range of revisions for
>>>     some modules that may be used together with teh others. This doesn't
>>>     seem to be the case. If so, it would be somewhat unwieldy because every
>>>     combination of module revisions would require a separate package
>>>     revision.
>> RW:
>>
>> Yes, this is an interesting point.
>>
>> My intention is that there is a roughly linear history of package
>> versions.  E.g. if there was a package of all IETF modules, then every
>> time a new version of an IETF module is published, the package
>> definition would be updated to a new version that includes the new
>> published module revision. I think that we need to try and somewhat
>> constraint the versions of modules that can sensibly be used together.
>>
> With semver, would it make sense to be able to specify only a major
> version number of a module? The "yang-sem-ver" type requires the
> complete version number.

So, I don't think that this would quite work, but the effective behavior 
might be what you desire anyway.

Consider the following:
   (i) module A, at version 1.0.0, defines some functionality.
   (ii )module A, at version 2.0.0, fixes some issues in version 1.0.0
   (ii) module A, at version 2.1.0, defines some new (backwards 
compatible) functionality.

If a package only listed module A's major version number (e.g. 2) then a 
client cannot know whether or not it can use the new functionality added 
in version 2.1.0 of the module, because it won't know whether the server 
implements it until is queries the module set in YANG library.

But, I think that listing exact versions is probably OK.
  - pkg-P, at version 1.0.0, uses module A@V2.0.0
  - pkg-P, at version 1.1.0, uses module A@V2.1.0

If the client requires pkg-P@V1.0.0 then it will work with a server that 
supports pkg-p@V2.0.0 or pkg-p@V2.1.0.

Further, if there is a third version of module A defined, e.g. 1.2.0, 
but that hasn't yet been included in an updated pkg-p revision, then the 
server can still indicate that it implements pkg-p@V1.1.0, but also 
indicate that is has updated module A to version 1.2.0.  The semver 
rules indicate that this is all OK and backwards compatible, and clients 
expecting to work with Pkg-P@1.0.0 or 1.1.0 would still work fine.

Finally, I also want to be able to build an exact schema from a package 
definition, and that is only possible if the exact module 
versions/revisions are known.

So, in summary, I think that package definitions should indicate precise 
version numbers of the modules defined by those packages, but the semver 
rules allow for newer backwards compatible implementations of the 
package, or newer backwards compatible implementations of some of the 
modules in the package.


>
>>> - As Jason pointed out, there seems to be no use for the package
>>>     namespace, as packages don't define any names on their own.
>> Yes, I will remove the text about namespaces.  Globally unique package
>> names should be sufficient.
>>
>>
>>> - I would also prefer mandatory-features to be bundled with each
>>> module.
>>>
>>> - This draft nicely shows that there is really no need for any
>>>     "yang-data" extensions. But I also don't see any benefit from using
>>>     ietf-yang-instance-data in this case. It would IMO be perfectly fine
>>>     to get rid of two levels of data hierarchy:
>>>
>>>     { "ietf-yang-package:yang-package": {
>>>         ...
>>>       }
>>>     }
>> That's an interesting point.  My thought is that all at rest YANG data
>> would be encoded in YANG instance data documents to make them more
>> easily machine parse-able.
> I don't see how the two extra levels make the JSON more easy to parse.

So, my interpretation is that 
draft-ietf-netmod-yang-instance-file-format-01 is intended to be the 
standard way of representing YANG data at rest (which is what this YANG 
package definition is meant to be).  If we shouldn't use 
draft-ietf-netmod-yang-instance-file-format-01 for YANG packages, then 
when should it be used?


>
> If we want to have some standard metadata for inclusion in standalone
> instance document, it would be probably better to define the metadata as
> a grouping that can be used right under
> "ietf-yang-package:yang-package". In the DSDL schemas (RFC 6110) we used
> Dublin Core metadata for a similar purpose.

OK, perhaps this issue should be discussed in the context of the YANG 
instance data draft.

But I will add this as an open issue.

Thanks,
Rob


>
> Lada
>
>> Thanks,
>> Rob
>>
>>
>>> Thanks, Lada
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod