Re: [netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis

Ladislav Lhotka <ladislav.lhotka@nic.cz> Fri, 08 December 2023 12:49 UTC

Return-Path: <ladislav.lhotka@nic.cz>
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 0F914C15152E for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2023 04:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=nic.cz
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 mNuo5eFJ4dc2 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2023 04:49:01 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9E859C151061 for <netmod@ietf.org>; Fri, 8 Dec 2023 04:49:00 -0800 (PST)
Received: from wedge.nic.cz (unknown [IPv6:2001:1488:fffe:255:b563:4ddb:6db3:3f95]) by mail.nic.cz (Postfix) with ESMTPSA id 070BC1C1948; Fri, 8 Dec 2023 13:48:56 +0100 (CET)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=ladislav.lhotka@nic.cz smtp.mailfrom=ladislav.lhotka@nic.cz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1702039737; bh=VSDrf+bXm/V6u0yUfjY6YiyPh55QnItB2YElO9CWHjY=; h=From:To:Subject:In-Reply-To:References:Date:From:Reply-To:Subject: To:Cc; b=OjzyHkpgf+iKl7jpA6mSvrZm6I+r7+BE1YqTGRkhCR+gO1TErZ7Q7lt18iwLZrfYf Fy0r7HEGT5lr2YYo0VoDgtxSO3k5jeOXdJfMqE743iNm4uyyxvsyTTGzj47sRFe7NX jc1zRDE+S8kO2+MiBBcWr+hSyyE/xH3Yp69ZV1T4=
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: Martin Björklund <mbj+ietf@4668.se>, netmod@ietf.org
In-Reply-To: <20231207.170451.2186357392151798883.id@4668.se>
References: <20231207.170451.2186357392151798883.id@4668.se>
Mail-Followup-To: Martin Björklund <mbj+ietf@4668.se>, netmod@ietf.org
Date: Fri, 08 Dec 2023 13:48:55 +0100
Message-ID: <87jzpox3k8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.103.7 at mail
X-Virus-Status: Clean
X-Rspamd-Queue-Id: 070BC1C1948
X-Spamd-Bar: /
X-Spamd-Result: default: False [-0.10 / 20.00]; MIME_GOOD(-0.10)[text/plain]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[ietf]; WHITELISTED_IP(0.00)[2001:1488:fffe:255:b563:4ddb:6db3:3f95]; ASN(0.00)[asn:25192, ipnet:2001:1488::/32, country:CZ]
X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: WHITELISTED_IP
X-Rspamd-Action: no action
X-Rspamd-Server: mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-fh1wgGa97n8ZVZWnC_URYoZ8WE>
Subject: Re: [netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis
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: Fri, 08 Dec 2023 12:49:06 -0000

Martin Björklund <mbj+ietf@4668.se> writes:

> Hi,
>
> There has been some discussion with IANA on the YANG doctors list
> regarding this text in section 4.8 in RFC 8407:
>
>    A "revision" statement MUST be present for each published version of
>    the module.  The "revision" statement MUST have a "reference"
>    substatement.  It MUST identify the published document that contains
>    the module.
>
> (the same text is present in rfc8407bis)

I think it would be sufficient to have SHOULD instead of MUST here. Other cases apart from IANA modules may arise where it makes no sense to attach reference to every single revision. And adding dummy references just to satisfy tools is actually harmful.

On the other hand, I assume YANG doctors would object if a reference isn't provided where it is appropriate and no sound reason is given.

Lada

>
> It continues with the motivation behind the rule:
>
>    Modules are often extracted from their original
>    documents, and it is useful for developers and operators to know how
>    to find the original source document in a consistent manner.
>
> As can be seen in e.g.,
> https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-type@2023-11-08.yang,
> this rule has not been followed.
>
> The discussion ended with the recommendation to IANA to always add a
> "reference" statement that refers to the published module (e.g.,
> https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-type@2023-11-08.yang).
>
> If people agree that this is the correct solution, I think we should
> update 8407bis with this.
>
> Specifically, I suggest to change 4.30.3.1 and 4.30.3.2:
>
> OLD:
>
> When the "iana-foo" YANG module is updated, a new "revision"
> statement with a unique revision date must be added in front of the
> existing revision statements.
>
> NEW:
>
> When the "iana-foo" YANG module is updated, a new "revision"
> statement with a unique revision date must be added in front of the
> existing revision statements.  The "revision" statement must have a
> "reference" substatement that to the published module (e.g.,
> https://www.iana.org/assignments/yang-parameters/iana-foo@2023-11-08.yang)
>
>
>
>
> Further, some IANA modules use the IETF template for the module's
> "description", see e.g.,
> https://www.iana.org/assignments/yang-parameters/iana-routing-types@2022-08-19.yang.
> That module has in its "description":
>
>      This version of this YANG module is part of RFC 8294; see
>      the RFC itself for full legal notices.";
>
> But that is not correct.  Other module use this instead:
>
>      The initial version of this YANG module is part of RFC 7224;
>      see the RFC itself for full legal notices.";
>
> I think 8407bis should recommend that IANA-maintained modules use this
> wording instead.
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67