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

Robert Varga <nite@hq.sk> Wed, 31 May 2023 00:13 UTC

Return-Path: <nite@hq.sk>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A81C151992 for <netmod@ietfa.amsl.com>; Tue, 30 May 2023 17:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvslrNb8BQIy for <netmod@ietfa.amsl.com>; Tue, 30 May 2023 17:13:16 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433AFC15106C for <netmod@ietf.org>; Tue, 30 May 2023 17:13:15 -0700 (PDT)
Received: from [192.168.1.107] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 27931248A32 for <netmod@ietf.org>; Wed, 31 May 2023 02:13:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1685491992; bh=O4/AbaXYBu8sdP54R5AJzTjSH5pY54PuWUoL8jtRD7E=; h=Date:Subject:To:References:From:In-Reply-To; b=txfET7umWsyinEyF8MVfpai6AAL31P4ivSMxn1q7uTt1HoRqwJjsSbQpM4QUUdxMf M6ctp19tcFNBiKMHT3XMXXMtWwOsS3MaHwvdr043plBTKnVWbVxB33hWzPTRn/B5eq wHKlO5VjoqbKxOuxYFO5vA3RhBGnd003IyG5ObUk=
Message-ID: <12cd6ad9-e384-7cbc-d14d-fdf58cdbb0df@hq.sk>
Date: Wed, 31 May 2023 02:13:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: "netmod@ietf.org" <netmod@ietf.org>
References: <01000187fd8e0407-84bd7e7b-ede3-43d8-a9b3-5d4d0a915509-000000@email.amazonses.com> <jr5nepvspm3kpoxbv6dpxwi234ggjuthvckeerj2hb3g3qdc6x@4o42ngfbw72f>
From: Robert Varga <nite@hq.sk>
In-Reply-To: <jr5nepvspm3kpoxbv6dpxwi234ggjuthvckeerj2hb3g3qdc6x@4o42ngfbw72f>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------m0ukngV8W4mg70gRqxMw51El"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Q12QnAOvp67lBgRU9NyGVjFJR0k>
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2023 00:13:21 -0000

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 :(

Regards,
Robert