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
> [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

Reply via email to