On Fri, Jun 02, 2023 at 06:13:08PM +0200, Robert Varga wrote: > 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?
I am not aware of an official authoritative source of YANG files. The IETF sends documents to the RFC editor for publishing and the RFC editor meanwhile publishes multiple formats. The discussion that we should have an official archival repository of data model definitions is likely more than 20 years old, it surely predates YANG. I have given up on this but perhaps fresh blood can resolve roadblocks. > 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. It would be more useful to explain why byte-level equivalence is now necessary. So far, we did fine without requiring this. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
