List of things where Openconfig deliberately breaks the standard

[dbarrosop]

Hello, sorry to bring this up but is there a place to go to see which parts of the IETF standards are broken deliberately? For instance, the choice of regex style (PCRE I reckon) is not compatible with what's defined in the standard (XSD flavour). The reason why this would be useful is because lots of tooling try to adhere to the standards and loading openconfig models often breaks such tooling, sometimes is hard to tell if it's the tooling's fault or something else so it'd be helpful for everybody to have an easy to access list for reference.

Thanks! David

[aashaikh]

tl;dr : we don't have a single doc describing differences from standards at this point (agree it would be useful)

Slightly longer discussion (maybe this could seed a doc): There are few types of differences that users/contributors/tools authors would notice:

• many of the differences have to do with restricting to use a subset of the full YANG language (and XPATH) to retain some sanity, and adopting some structural conventions (to provide consistency across all of OC) that are not in IETF modules -- representing opstate is perhaps the most significant of these. These differences are both largely covered in our style guide and enforced/checked by our linter (openconfig.py plugin)

• some "breakages" that people see in their tools are due to an incorrect, or different, interpretation of the standard -- there is enough ambiguity in the RFCs (6020 and also 7950), that this happens more frequently than one might expect. The most common example is tooling that requires module A importing another module B to reference data in B using the same namespace prefix as defined in B itself. Some tools make assumptions about subtle requirements on namespaces for things like imported identities that are not fully clear in the specification.

• the third class of differences are those where OpenConfig models assign different behavior to language constructs or data definitions as defined in some standards -- this class is what the original issue probably had in mind. The rationale for these differences varies -- in some cases the choices made in the standard are not well suited to software development practice, or the standard is unnecessarily broad as compared with operational practice (for which OpenConfig models are biased). Examples in this category:

  • OpenConfig modules use a regular expression format that is natively supported in most modern programming languages, while the YANG standard is based on a W3C-defined format which has a few significant differences. This means that pattern statements in OpenConfig modules need to be interpreted differently than modules that use W3C.
  • OpenConfig uses a semantic version number to track the evolution of modules, and explicitly signal whether changes are backward compatible or not. We do not consider the YANG revision statement as the authoritative version of a module, and remove the requirement in the standard that module changes must never be backward incompatible. (note that recently the IETF has started to define support for semantic versions).
  • OpenConfig defines base IP address types (in openconfig-inet-types) to be non-zoned to reflect the most common operational scenario -- zoned IP addresses are supported using a different type definition if needed. The corresponding types in ietf-inet-types overload zoned and non-zoned addresses in the same type. This isn't strictly speaking a "breaking" difference, but I'm mentioning it because there might be expectation that IP address types are exactly the same. We've generally defined our own set of type definition modules (inet-types, yang-types, etc.) to allow for such differences.

[dbarrosop]

Thanks for the detailed explanation, I think compiling these notes under NOTES.md or something like that would be super helpful.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.