search

netmod-wg / yang-next

Feature requests for future versions of YANG
6 stars 0 forks source link

YANG Packages (multi-module conformance/guidance) #50

Closed abierman closed 5 years ago

abierman commented 6 years ago

YANG modules are designed to be used together but there is no way to specify in a machine-readable way the contents of a logical package of YANG modules that are intended to be implemented together.

The module-name, SEMVER info, and YANG features needs to be documented for each module in the package.

It is often not possible to place all relevant package metadata inside each individual module, such as extending the import-stmt. It is possible (and quite common for the foundation modules) to have a module appear in multiple packages. The module requirements (versions, features) may be different in each package.

abierman commented 6 years ago

It would be useful for constrained devices to advertise package capabilities instead of module capabilities. This could reduce session startup info exchange by 10X or more.

rgwilton commented 6 years ago

I wonder whether this could reuse any of the structures in YANG library bis, and/or the YANG instance data draft. Some of the comments that Balazs made about device capabilities seems related to YANG packages.

I agree that YANG needs something like this. Although I'm not sure whether this should go directly into the next version of YANG. It would be good to see what the solution looks like in an independent ID first.

mbj4668 commented 5 years ago

I agree this is an important problem to solve. Not sure it should be solved in the language though. Maybe time for the WG to pick up the old packages draft?

rgwilton commented 5 years ago

I posted an ID to describe the approach of defining YANG packages via YANG instance data documents.

YANG Packages ID

abierman commented 5 years ago

My original idea for YANG packages was based on experience with RPM and debian packaging. The goals were really based on operational issues, not conformance issues. Consider a virtual package like build-essential or jre-default. It is for convenience to load many modules at once. Experts can still use individual debian packages instead.

The standards work already being done to define module-tags for routing modules can and should be leveraged to define conceptual packages.

Not convinced there is any need to defined additional YANG conformance but packages for convenience are probably useful

kwatsen commented 5 years ago

Andy: Module tags may be another way to solve this. The idea is a package may be obsoleted by instance-documents.

Rob: packages might be useful for quite a few things, but this may not be a YANG-next issue.

Kent: not a data modeling language issue, so much as a data model issue - could be solved by an instance document.