On Tue, May 30, 2023 at 5:13 PM Robert Varga <n...@hq.sk> wrote: > On 30/05/2023 20.28, Jürgen Schönwälder wrote: > > It is unclear what "identical" means here. If two people extract a > > module from an RFC, they may not end up with identical byte > > sequences. So does white space matter when we talk about MUST be > > identical? What about comments? The problem is that the IETF still > > publishes YANG modules in RFCs instead of files. > > As for RFC vs. files, the mechanics of extracting of files from RFCs > seems to be well established, plus it is an IETF-owned cron job which > updates https://github.com/YangModels/yang/tree/main/standard/ietf/RFC > -- so I would (and I actually do) assume that is the normative source of > byte-exact files. > > In my opinion "identical" leaves little room for interpretation: it is > byte-exact, i.e. md5sum (and everything else of that kind) returning the > same value. > > If we were to say "equivalent", now that would be a whole another kettle > of fish. > > I stand to be corrected, but I do not believe there is a single > normative statement about handling equivalent Unicode encodings. As a > tool author, I believe having that is a hard prerequisite to be solved > before we ever embark on pulling in YANG semantics into the conversation. > > I do have opinions around that, in particular the equivalence of > - description "foo" > - description 'foo' > - description foo > and the order of preference of those (which may contradict best current > practice), but I certainly do not have the cycles to engage in that > discussion to a reasonable depth :( > >
There are many ways to maintain semantic equivalence with vastly different language syntax. That is a separate issue I think. As per [RFC7950 <https://www.rfc-editor.org/info/rfc7950>] and [RFC6020 <https://www.rfc-editor.org/info/rfc6020>], all published revisions of a module are given a new unique revision date. This applies even for module revisions containing (in the module or included submodules) only changes to any whitespace, formatting, comments or line endings (e.g., DOS vs UNIX).¶ <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#section-3.1-4> I disagree with this proposed module update rule. This includes insignificant whitespace that is ignored in the YANG language. Your example description-stmt should count as a change since each string form has different rules. Changing any characters, even changing the newline (dos2unix) or trimming trailing whitespace on a line, requires a new module revision. IMO this is a bad idea since it is too fragile. E.g., tools might change the end-of-line chars so they are correct for the operating system used to store the file. Module authors should not need to track insignificant whitespace changes that are ignored in YANG. > Regards, > Robert > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
