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

Amanda Baber via RT <iana-issues@iana.org> Tue, 21 November 2023 23:56 UTC

Return-Path: <iana-shared@icann.org>
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 3FE31C151553 for <yang-doctors@ietfa.amsl.com>; Tue, 21 Nov 2023 15:56:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.639
X-Spam-Level:
X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MISSING_HEADERS=1.021, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 2BHOaAjND0aa for <yang-doctors@ietfa.amsl.com>; Tue, 21 Nov 2023 15:56:08 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 D92D2C14CE55 for <yang-doctors@ietf.org>; Tue, 21 Nov 2023 15:56:08 -0800 (PST)
Received: from request6.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id AB51DE0C7B for <yang-doctors@ietf.org>; Tue, 21 Nov 2023 23:56:08 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id A91C47C35D; Tue, 21 Nov 2023 23:56:08 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-issues@iana.org>
Reply-To: iana-issues@iana.org
In-Reply-To: <rt-5.0.3-1442929-1700610506-1513.1289473-37-0@icann.org>
References: <RT-Ticket-1289473@icann.org> <rt-5.0.3-1442929-1700610506-1513.1289473-37-0@icann.org>
Message-ID: <rt-5.0.3-1442929-1700610968-1782.1289473-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1289473
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
CC: yang-doctors@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Tue, 21 Nov 2023 23:56:08 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/UhYHpXrAkrA3AgTMwT_4omS2IX8>
Subject: [yang-doctors] [IANA #1289473] Revision statements in IANA-maintained YANG modules
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 21 Nov 2023 23:56:09 -0000

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?

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?

Do we need to do so only going forward?

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?

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?

Best regards,

Amanda Baber
IANA Operations Manager