> On Aug 12, 2020, at 04:04, Ladislav Lhotka <[email protected]> wrote: > > "Joe Clarke \(jclarke\)" <[email protected]> writes: > >>> On Aug 11, 2020, at 10:45, Martin Björklund <[email protected]> wrote: >>> >>> Hi, >>> >>> "Joe Clarke \(jclarke\)" <[email protected]> wrote: >>>> At the IETF 108 virtual meeting, Lada asked about what would happen if >>>> he converted a YANG module to YIN syntax (or vice versa, or to some >>>> other format). This was during the discussion of the issue of what >>>> should happen if a module changes and the only changes are >>>> insignificant whitespaces (e.g., strip trailing spaces, change line >>>> length of descriptions, etc.). >>>> >>>> The authors/contributors discussed on this on our weekly calls, and we >>>> propose: >>>> >>>> If a module changes and those changes are only insignificant >>>> whitespace changes and the syntax of the module remains the same >>>> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module >>>> MUST be created. If you are using YANG semver as your revision >>>> scheme, you MUST apply a PATCH version bump to that new module >>>> revision to indicate an editorial change. >>>> >>>> The reasoning behind this decision is that it makes it very clear and >>>> unambiguous to consumers that this module has been consciously >>>> changed, and those changes are only editorial. This way one won’t be >>>> concerned if they note that a module of a given syntax with the same >>>> version but different checksums and diffs wasn’t otherwise >>>> manipulated. >>> >>> I think this is the wrong way to go. I clean up formatting issues all >>> the time, including IETF modules. I am pretty sure that if you >>> retrieve modules like "ietf-interfaces" or "ietf-yang-types" from >>> different vendors' products, you will get modules with differences in >>> whitespace - and this is not a problem AFAIK. >>> >>> I think it is ok that a simple "diff" show whitespace changes in this >>> case. I don't think it leads to any real problems. >> >> We discussed this on the call. The thinking was that a long diff output >> would essentially be unwieldy for some modules and important changes might >> be lost. If the versions were the same, it would be ambiguous to the >> consume as to whether or not the module was only changed in trivial (i.e., >> less-than-editorial) or if more substantive changes happened. If you trust >> the producer, maybe you assume they regenerated the module without trailing >> whitespace (or the like). We felt there should be a more explicit signal. >> >>> >>>> That said, if a module changes format from one syntax to another but >>>> maintains semantic equivalency, then the revision and YANG semver MUST >>>> be the same. In that case, one will use the extension to realize that >>>> this module file cannot be directly compared to one of another syntax >>>> without looking at compiled or semantic representation. >>> >>> This seems a bit inconsistent. Suppose I round-trip from YANG to YIN >>> to YANG, and the result is different whitespace in the two YANG >>> modules. The revision is the same, as explained above. How is this >>> different from changing the whitespace in YANG directly? >> >> We didn’t discuss this directly, but we did discuss auto-generators that >> could do this type of round-tripping. The general consensus was that you >> would use the same post-processing tool (e.g., pyang -f yang) on the result >> to ensure consistency. And a consumer would look to a canonical source >> (like IANA, the IETF document, or the vendor) to ensure a consistent module. >> >> In terms of alternate sources, I would think that if one wanted to trust an >> IETF module downloaded from some other site, they could. If that site did >> some additional formatting, that would be up to the consumer to resolve >> compared to what might be required by a package. But if the publisher (IETF >> in this case) were to republish a module with these stripped whitespace line >> endings, then that would be a different revision. > > I think it would be better to define "canonical YANG". One relatively > straightforward way might be to convert to YIN first and then apply XML > canonicalization: > > https://www.w3.org/TR/2001/REC-xml-c14n-20010315 > > As an additional benefit, this would also enable digital signatures of YANG > modules.
This came up on our last call as well, but the consensus there was that defining canonical YANG would be a large undertaking and out of scope for this work. That said, I think codifying such things would be useful. Joe _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
