Re: [yang-doctors] [IANA #1289473] Revision statements in IANA-maintained YANG modules

Ladislav Lhotka <ladislav.lhotka@nic.cz> Wed, 22 November 2023 07:57 UTC

Return-Path: <ladislav.lhotka@nic.cz>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D680C14CF17 for <yang-doctors@ietfa.amsl.com>; Tue, 21 Nov 2023 23:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 HIoxGxi5O1qh for <yang-doctors@ietfa.amsl.com>; Tue, 21 Nov 2023 23:57:16 -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 9AB9EC14CEFE for <yang-doctors@ietf.org>; Tue, 21 Nov 2023 23:57:15 -0800 (PST)
Received: from wedge.nic.cz (88-100-20-130.rcf.o2.cz [88.100.20.130]) by mail.nic.cz (Postfix) with ESMTPSA id 797C11C17FC; Wed, 22 Nov 2023 08:57:12 +0100 (CET)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=ladislav.lhotka@nic.cz smtp.mailfrom=ladislav.lhotka@nic.cz
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: iana-issues@iana.org
Cc: yang-doctors@ietf.org
In-Reply-To: <rt-5.0.3-1442929-1700610968-1782.1289473-37-0@icann.org>
References: <RT-Ticket-1289473@icann.org> <rt-5.0.3-1442929-1700610506-1513.1289473-37-0@icann.org> <rt-5.0.3-1442929-1700610968-1782.1289473-37-0@icann.org>
Date: Wed, 22 Nov 2023 08:57:11 +0100
Message-ID: <87v89ufcfc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.103.7 at mail
X-Virus-Status: Clean
X-Spamd-Bar: -----
X-Spamd-Result: default: False [-5.10 / 20.00]; BAYES_HAM(-5.00)[100.00%]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5610, ipnet:88.100.0.0/15, country:CZ]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; TO_DN_NONE(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]
X-Rspamd-Action: no action
X-Rspamd-Server: mail
X-Rspamd-Queue-Id: 797C11C17FC
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/vg4Hoqmn4Ne6yq1bdi8ICqvk5P0>
Subject: Re: [yang-doctors] [IANA #1289473] Revision statements in IANA-maintained YANG modules
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2023 07:57:18 -0000

Hi Amanda,

"Amanda Baber via RT" <iana-issues@iana.org> writes:

> Hi,
>
> We came across an issue when attempting to validate RFC 9403's ietf-rib-extension@2023-11-20.yang module before posting.
>
> That module refers to iana-routing-types@2022-08-19.yang, and pyang is refusing to validate it on the grounds that iana-routing-types@2022-08-19.yang doesn't have references for its revision statements. (Which it indeed does not.)
>
> However, if we try to validate iana-routing-types@2022-08-19.yang directly, we don't get any errors.
>
> Which pyang reaction is correct?

RFC 8407 states in sec. 4.8:

  The "revision" statement MUST have a "reference" substatement.

The module description refers to RFC 8294 though, and I am not sure how this particular module is updated and whether there is always a relevant reference available for a given revision.

>
> One larger issue is that we weren't aware that we needed to add references for revision statements in the IANA-maintained modules. We have no expertise in YANG and have been relying entirely on validation tools (and on IANA Considerations sections for registry maintenance instructions in general).
>
> Should we go back and add references to revision statements for all the IANA-maintained modules?

This could lead to problems with versioning of modules. 

>
> Do we need to do so only going forward?

I'd suggest to add reference statements to future (substantial) revisions of modules, perhaps even retroactively, but only where it makes sense. 

>
> Either way, we have two questions:
>
> 1) Many of the registries mirrored by the IANA-maintained modules have First Come First Served or Expert Review ranges that don't require that the applicant provide a specification. For those registrations, we list the name of a contact person in the registry's "Reference" field. In the module, would we continue to omit the reference field?

If there is no suitable document to refer to, it makes no sense to me to add any stub references. RFC 8407 is IMO unnecesarily strict here, and a SHOULD might suffice. 

>
> 2) When we need to correct an IANA-maintained module, in the absence of a document to refer to, what can we do to make the revision statement valid?

I'd say yes.

Best regards, Lada

>
> Best regards,
>
> Amanda Baber
> IANA Operations Manager
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors

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