Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga <[e-mail]>]

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