On 31/05/2023 09.50, Jürgen Schönwälder wrote:
On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga 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.I have YANG modules that were extracted years ago using some version of smistrip of the past. Do you believe my files extracted back then are byte-by-byte equivalent to what some cron job produces on some github repo somewhere today?
smistrip tries to be smart with whitespace and the version I looked up does not actually refer to any specification. Also arriving at YANG files would then imply RFC6643 processing, right? If that is the case, I would say the chances of the files being byte-exact equivalents are close to, but not equal, to zero.
I do not quite understand how the problem of IETF still not publishing files should be solved, or whether in fact it is being solved. Do you have any references I could use to read up on the current state of affairs, please?
Do you guarantee that the software behind
the cron job will never ever be updated causing it to produce something where white space may differ?
No, obviously not. But there is a public ledger of all changes made to those files. So:
a) the cron job's results can feasibly be guarded against accidental overwrite
b) if that ever happens, there is a clear indication that it happened, when it happened and who has done it.
On the other hand those guarantees do not hold for RFCs either -- we have errata and the associated process.
Regards, Robert
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
