"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. Lada > > Joe > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
