You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The hello message (mandatory in YANG 1.0, RFC 6020)
ietf-netconf-monitoring (required for downloading YANG schemas, RFC 6022)
ietf-yang-library (mandatory in YANG 1.1, RFC 7950)
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: