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.
rgwilton
commented
4 years ago
OK, I missed this purpose. Perhaps one of the examples can be expanded to illustrate this situation.