Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many module lists #69

Closed
janlindblad opened this issue Oct 6, 2020 · 1 comment
Closed

Too many module lists #69

janlindblad opened this issue Oct 6, 2020 · 1 comment
Assignees
Labels
packages YANG packages related issue

Comments

@janlindblad
Copy link
Collaborator

janlindblad commented Oct 6, 2020

With the proposed YANG packages solution, there would be one more place where a server would list the set of modules it implements. At this point, there are already four mechanisms standardized by IETF.

  1. The hello message (mandatory in YANG 1.0, RFC 6020)
  2. ietf-netconf-monitoring (required for downloading YANG schemas, RFC 6022)
  3. ietf-yang-library (mandatory in YANG 1.1, RFC 7950)
  4. ietf-yang-library (as modified by NMDA, RFC 8342)

With this history, to add a fifth mechanism does not necessarily sound like an improvement. To resolve, we could either overlay the proposal with one of these mechanisms (probably (3)) and remove the duplication. Or we could try to get rid of some of the prior modules.

Getting rid of (1) is not possible for YANG 1.0, since it's mandatory. Getting rid of (2) is possible, but would require some new way of downloading YANG schemas (since that operation is defined there). Some solutions (e.g. ODL) would break, since they (incorrectly imo) require this module to be implemented to work. Getting rid of (3) is not possible for YANG 1.1, since it's mandatory. In conclusion, removing any of (1), (2), or (3) would be rather disruptive.

@rgwilton rgwilton added the packages YANG packages related issue label Oct 20, 2020
@rgwilton rgwilton assigned rgwilton and janlindblad and unassigned rgwilton Sep 28, 2021
@janlindblad
Copy link
Collaborator Author

We looked at an alternative approach to grafting the packages data model on top of YL. The alternative approach did work, but was deemed to not give any major advantages. We'll have to live with five mechanisms after all. At least we looked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages YANG packages related issue
Projects
None yet
Development

No branches or pull requests

2 participants