Is disabling features using deviations sufficient? There are some cases where this cannot work, e.g. a deviation cannot remove an identity.

List deviations and version down revs when a package is imported to make it explicit that it is not a complete implementation of the package.

Do we suggest what format package instances should be in?

Do we state what format IETF packages SHOULD/MUST be in (e.g. JSON)?

Lada:

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

I think that either one or both need to be provided. But putting a checksum into a file that is being checksum'ed itself does not make sense. So, opting to leave them out at the moment.

Should it be revision-label, or revision-label-or-date?

Should the schema for packages in an instance-data document hold just a single package, or multiple packages?

There are potentially several advantages to a single file holding multiple package definitions:

• This may allow the schema for the instance data package definition and the YANG library definition to be more closely aligned.
• This may be better for vendor devices that support different schema for different datastores.

But there are some downsides too:

• The instance data file cannot have a well defined name that identifies the package that it contains. Although that could still be done with slight different names (e.g. pkg vs pkgs).

Lada has raised the concern that this introduces too many levels to the hierarchy.

At the moment, the text is too suggestive.

YANG says that we can have modules without a revision date, hence that is what the model currently supports, but I question whether we are at the stage were we should require that all modules have at least a revision date to be included in a package.

Do we also need to have protocol support for writing/updating package tags? What about guidance, adding a package tags registry, default package tags, etc. The raw type could be included in the package definition, but everything else could be done in a separate draft?

Section 5.3:

Hmmm, while I agree with the semver rule text, one COULD use a version string that is not semver at all. Then how do these rules apply? I think we either need to make semver mandatory to implement with a separate revision-label for vendors, or we generalize this text.

Should we add contact/organization to a package definition (if so this would duplicate what is already in a YANG instance data document), so perhaps it should only be in the YANG library definition?

For example, a client coded to support 'foo' package at version 1.0.0
should interoperate with a server implementing 'foo' package at
version 1.3.5, because the YANG semantic versioning rules require
that package version 1.3.5 is backwards compatible to version 1.0.0.

Indicate that this is predicated on using semantic versioning

What happens if a package imports packages that implement two different revisions of a module. The package has to choose one, and indicate which one it chooses.

Split the behaviour of packages for conformance vs packages are a building block.
E.g. useful to include a package as a building block for another package, but without indicating conformance to that package.

The only way to modify a package in an nbc way should be through the use of deviations.

Once draft-verdt-netmod-yang-semver is published, add appropriate references to this draft for module level semantic versioning.

There should be an IANA registry for IETF defined YANG packages. Is there just a single registry instance for each package, or are there registry instances for each version of each package?

Does a package definition allow for an arbitrary list of modules that can be selected (e.g. as a flat list) or is it hard coded.

5.2.1.1)
Is there a difference between a package importing or including something.
[RW]
No, I should choose one term and stick to it. Probably include is better to avoid confusion.

Proposal is to "implement".

This would probably provide enough security and make the files easier to read/manage.

Is it OK for the YANG definition used for package instance data vs YANG library to differ? The reason for the difference is to allow "Module Sets" to be reused, potentially minimizing duplicate data in YANG library.

Defining globally unique names for packages, similar to how YANG module names SHOULD be globally unique, should be sufficient without requiring the additional complexity/management of explicit namespace annotations.

Should a package definition be able to remove modules from another package definition?

When a package is imported, it must be marked whether that package has been modified in an nbc way. A package can be modified via any of the following mechanisms:

• Changing the version of a imported package.
• Changing the version of an imported module.
• Add modules with explicit deviations.

My thinking is that it should not, because it then makes it harder for a client to determine whether a package has been faithfully implemented. Using explicit deviations seems like a better choice.

E.g. the package associated with a device may need to be a private package rather than having a globally unique name. Or perhaps the solution here is for the device to generate a random name for the top level device package, e.g. "xr-sw-62162dac-2615-11e9-ab14-d663bd873d93", or perhaps something much shorter!

Commented on by both Jason and Lada:

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new : format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps. My thinking here was to have the list of features high up and very easy to find/parse.

Should the YANG package definitions be part of YANG library, or should they be contained in their own top level "packages" container?

The advantages of them being part of YANG library is that fetching the YANG library information retrieves all of the packages at the same time. However, given that one of the aims of packages is that they are available off the box, then this doesn't seem to be so useful, and perhaps would end up being a hindrance.

The package definition contains a leaf to indicate the previous version. Should there also be a leaf to indicate that the package revision is not backwards compatible to the previous revision?

Should a package (or implementation) be able to remove modules from a package?

Considering version selection, should the YANG library package definition have a flag to indicate whether a particular package can be selected by a client?

Probably the answer here is to defer this issue to a separate version selection draft that can add a flag via augmentation; or provide a separate list of packages that are selectable.

5.2.1.3)It is not defined which data is considered “meta” data.
[RW]
OK, this should be clarified.

Ch 5.1 para 3) I am not sure what is a package instance? What identifies a package and what identifies a package instance? Do we need it in terminology?
[RW]
Yes, it sounds like we need additional terminology.

By “package instance” I mean a particular version of a package. Whereas a package more generally might be used to refer to all possible versions of a package with the same name.

So, a package is defined by having a name that acts as a unique identifier.
A package instance is defined by a instance data file containing a package definition, and is uniquely identified by the (name, version) tuple, and can be verified by its checksum.

Raised as an issue by Jason.

Jason suggested:

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules. Not sure which is better here. Packages could get a lot of updates, and a long revision history would not be helpful at all.

Closely related to #10.

The issue here is whether it is better to augment YANG library or define a new version of YANG library. The conclusion of this issue would seemingly depend on what the nature and scope of the changes to YANG library is. If the majority of the changes can be defined in a separate YANG packages top level object, that augmentations to YANG library would seem to be the most suitable approach.

Should a package include RFC 8199 related metadata? E.g., does a package contain device or service level YANG models?

The current proposal is to gain this flexibility by allowing module tags to be added to package definitions, unless that is regarded as a misuse of module tags.

Also, would it be better if the YANG import statement could indicate whether the dependency is only for typedefs or other dependencies (e.g. paths, identities)?

It should be possible to use YANG packages as the schema for instance data documents.

Presumably the root definition of the package should use an inline YANG library schema definition to define the modules used for the root package definition?

From Jason:

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful. Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

The packages draft currently defines bc and nbc changes, but these should be pulled in from elsewhere.

Do the supported features lists in a package need to also repeat the contents of each included package?