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

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jan 2019 15:50:31 +0100

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.

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

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

- As Jason pointed out, there seems to be no use for the package
  namespace, as packages don't define any names on their own.

- 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": {
      ...
    }
  }

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Jan 2019 18:12:02 +0000

Hi Lada,

Thanks for the review and comments ...

I've added some thoughts inline ...

> - I like the fact that this work doesn't require any changes to YANG,

RW: OK.

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

>    combination of module revisions would require a separate package

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.

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

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

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jan 2019 15:00:53 +0100

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

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.

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

> easily machine parse-able.

I don't see how the two extra levels make the JSON more easy to parse.

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.

Lada

>
> Thanks,
> Rob
>
>
>>
>> Thanks, Lada
>>
>>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod