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

Martin Björklund <mbj+ietf@4668.se> Thu, 07 December 2023 16:05 UTC

Return-Path: <mbj+ietf@4668.se>
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 54637C14CF1B for <netmod@ietfa.amsl.com>; Thu, 7 Dec 2023 08:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (2048-bit key) header.d=4668.se header.b="fuRbMJ0O"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="LKe7dBsm"
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 ciL3yFRXh1TE for <netmod@ietfa.amsl.com>; Thu, 7 Dec 2023 08:04:55 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 9A611C14CE2E for <netmod@ietf.org>; Thu, 7 Dec 2023 08:04:55 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3F8BD5C00DA for <netmod@ietf.org>; Thu, 7 Dec 2023 11:04:54 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 07 Dec 2023 11:04:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to; s=fm3; t=1701965094; x=1702051494; bh=dP UJ9qNcoewh9GHjN4Cx8MqAZg9rc2jTR7QzlCFU7WE=; b=fuRbMJ0Ow7Bgb094T0 jXRrTJICgZsdzKzN+IluOb/wZDm9ysGUeDr9Cl3PK3RLvBJFHhWJKrqvMn1yzwzv Q+Fiw/T9bV/EIKVrkQnQ+WK/2dauX0feQ35NAk3KO/ZqeyohOPA6OcdBaZPwAmse 4ZYUhHrVsSojUPe1e5ep/ojiLTyQjG/OIk3bh61N6E22W15pnrYpP7W4fptydQWv PXSbT8xpWASGdgNyP7i3lP9ZsK405ttN30ZOUWeipSyo+uklr/I0Nb7sofHi2zqp fooAGhVKJCIK0CECOsZCvMeRSTtsGMZtV17fR/yJ6fZKvV6sZBIHYzisLvEPJwuR bRLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1701965094; x=1702051494; bh=dPUJ9qNcoewh9 GHjN4Cx8MqAZg9rc2jTR7QzlCFU7WE=; b=LKe7dBsmPo3CsHi/2W+GHviIN6drQ rDlaK+yXRBuqzLqlG44rkLgICyTXNmOMKiGfACuCWhXZ3QRzmlblmiNAL9ZwB1F5 6vrgOFa9aSzGJYH8AeEjTYpzLb/nqtgHC6ql72aeTgueT4WjUDPxL7D5rK+7KUID 9TrU7Jt9Ymsh8/svgqzEvDtR/xlT/vHKc8dg7C2zXLA6iGr+uLYpbqXyxEwUt9tT hUV5Th6OcmwodpDuTwEti3cpy9vwsbc5vxI014kRg5c+lnURqzaPMOo32Wc9zDbi g9b5Q1tELgtG0wQoRSpWtvkZZE0H0ik9EDxIQaEIOBdp+qe0OqT2XKTxw==
X-ME-Sender: <xms:Je1xZbW7907qNTURTQ8BdTnR-Pu_38LPxTRJ59E9dzu_y5aGmt4x4g> <xme:Je1xZTmm8XrBxZASNdEjgNKRSFk2amxVj6xgvdnw9nXgOPYiwSzhRdHYKHlXFbAjK MvQXiv-wkvvIz2UG00>
X-ME-Received: <xmr:Je1xZXZUJxZgEByzslalqtfJcIXZWWtz1YpJZjEJzsMtqYnM35jBC1-K_LBV6EP3Zx16wBKlM_UusMhq-z4Gg-cGbJiJDh6_pQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudekfedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhofggtgfgsehtjeertd ertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhivght fhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepvdevgfefveehgedttdehleeuud duvdefheduhffgteeuleevfeeihfdvleelleffnecuffhomhgrihhnpehirghnrgdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsg hjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:Ju1xZWVmTDqBjC4SMzp1J1LjELrDQg6ofTLvQvT73AeYR-jPA6retA> <xmx:Ju1xZVkb5q08nnYT9FlpLzjTHwVYxANWcrEc-HrTh1hhL1B-tqFQaA> <xmx:Ju1xZTc3fqyyKREtwTfNRVUMKsfs0lGTeOfXQ7-sZGAL-3SiomdcNw> <xmx:Ju1xZTQHZcxNpXJ-KsfzQWZ0dw2s3O2Ypzz1eqpHze3pDupszXqSdw>
Feedback-ID: icc614784:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <netmod@ietf.org>; Thu, 7 Dec 2023 11:04:53 -0500 (EST)
Date: Thu, 07 Dec 2023 17:04:51 +0100
Message-Id: <20231207.170451.2186357392151798883.id@4668.se>
To: netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
X-Mailer: Mew version 6.8 on Emacs 27.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3_tg5oPbHhNQPbo3mMWy0m0cIzg>
Subject: [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: Thu, 07 Dec 2023 16:05:00 -0000

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)

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