Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Ladislav Lhotka <[e-mail]>]

On 11. 08. 20 15:41, Joe Clarke (jclarke) 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.
> 
> 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.

The last paragraph means that after a round trip YANG -> YIN -> YANG the
initial and final YANG modules MUST have the same revision. However,
depending on the conversion tools used, they may easily differ in
whitespace, so their byte-oriented checksums won't be equal.

I think there are in fact three cases:

1. Whitespace outside statement arguments - I believe this should never
be significant.

2. Whitespace in the argument of "contact", "description",
"error-message" and "organization" - this is tricky because tools may
format such arguments differently. I am leaning towards making
whitespace insignificant in this case as well.

3. Whitespace in other arguments has to be significant and lead to a
revision bump.

And one more corner case for both 2 a 3: what if "\t" is replaced with
the tab character in a double-quoted string? For YANG, these two strings
are absolutely equivalent.

Lada

> 
> Thoughts?
> 
> Joe
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67