Re: [netmod] status terms in YANG and IANA registries

Ladislav Lhotka <lhotka@nic.cz> Mon, 22 July 2019 19:28 UTC

Return-Path: <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 D99F112008F for <netmod@ietfa.amsl.com>; Mon, 22 Jul 2019 12:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAjCfSSWhIyG for <netmod@ietfa.amsl.com>; Mon, 22 Jul 2019 12:28:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC3E12004E for <netmod@ietf.org>; Mon, 22 Jul 2019 12:28:22 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id 60100140B77; Mon, 22 Jul 2019 21:28:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1563823700; bh=GGoDnmXK2KwFTqrZuV4nxCaAD24mRHKHtlPePf8pllw=; h=From:To:Date; b=YTvDJUFrtOUSVJqH4ErNH47ivieKBTRCBjKbz+78hEVf06SZPcX7GjmrU7nNQO297 qvWoguszXSDbfECbtXpkGk/S7kP19Y1WRZqxpHIeO2zi4HjVWALEAFFDOefaEgvRlW bzhT2teEbiYVG+cFm/EIcAXghwMYaK+tREwqAgTg=
Message-ID: <a49e9fcd37670cf716aaabdc3f413aca1f385bea.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, netmod@ietf.org
Date: Mon, 22 Jul 2019 15:28:18 -0400
In-Reply-To: <20190722190834.shen3ajylbxlr5e7@anna.jacobs.jacobs-university.de>
References: <871s6wt1qw.fsf@nic.cz> <87pnm13nwx.fsf@nic.cz> <20190722190834.shen3ajylbxlr5e7@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.4
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8way5XSzDNDsDWYrULERUepeSYw>
Subject: Re: [netmod] status terms in YANG and IANA registries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jul 2019 19:28:26 -0000

On Mon, 2019-07-22 at 21:08 +0200, Juergen Schoenwaelder wrote:
> Lada,
> 
> it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
> section 9.6 both map to YANG's 'obsolete'.

Yes, a short-term fix (e.g. for iana-dns-class-rr-type that is now in DNSOP WG)
could indeed be to map IANA's "deprecated" to "obsolete". But of course it is
seriously confusing.

BTW, it is already weird that YANG defines "deprecated" in terms of "obsolete",
which is another status term being defined.

Lada  
> 
> /js
> 
> On Mon, Jul 22, 2019 at 02:49:18PM -0400, Ladislav Lhotka wrote:
> > Hi,
> > 
> > I haven't received any responses to my message below but, given the recent
> > discussion in DNSOP and IETF mailing list, I believe it is important to
> > address this discrepancy in order not to give ammunition to those who oppose
> > mirroring IANA registries in YANG modules.
> > 
> > Lada
> > 
> > Ladislav Lhotka <lhotka@nic.cz> writes:
> > 
> > > Hi,
> > > 
> > > sec. 7.21.2 of RFC 7950 defines the "deprecated" and "obsolete" statuses
> > > as follows:
> > > 
> > >    o  "deprecated" indicates an obsolete definition, but it    permits
> > > new/continued implementation in order to foster       interoperability
> > > with older/existing implementations.
> > > 
> > >    o  "obsolete" means that the definition is obsolete and    SHOULD NOT
> > > be       implemented and/or can be removed from implementations.
> > > 
> > > Then, RFC 7224 contains these instructions in the IANA Considerations
> > > section:
> > > 
> > >       "status": Include only if a registration has been       deprecated
> > > (use                 the value "deprecated") or obsoleted (use the
> > > value "obsolete").
> > > 
> > > However, RFC 8126 defines the meaning of the status terms in IANA
> > > registries (sec. 9.6) in the following way:
> > > 
> > >    Specific entries in a registry can be marked as "obsolete"    (no
> > > longer in use) or "deprecated" (use is not recommended).
> > > 
> > > I would say that "deprecated" means something else here than in YANG.
> > > For example, the RSA/MD5 algorithm in [1] is marked as "deprecated"
> > > because it was found weak, and implementing it to "foster
> > > interoperability" can hardly be recommended. Instead, "SHOULD NOT
> > > implement" applies here, too.
> > > 
> > > I think it would be good to either align the semantics of "deprecated"
> > > in YANG with IANA registries, or at least map both IANA terms to
> > > "obsolete" in YANG.
> > > 
> > > Lada
> > > 
> > > [1] 
> > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
> > > 
> > > --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________ netmod mailing list
> > > netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67