[netmod] status terms in YANG and IANA registries

Ladislav Lhotka <lhotka@nic.cz> Wed, 05 December 2018 15:46 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BAC09130E1B for <netmod@ietfa.amsl.com>; Wed, 5 Dec 2018 07:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bHiiJ9XwynY3 for <netmod@ietfa.amsl.com>; Wed, 5 Dec 2018 07:46:51 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name []) by ietfa.amsl.com (Postfix) with ESMTP id 32780126CB6 for <netmod@ietf.org>; Wed, 5 Dec 2018 07:46:51 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 3975B1821356; Wed, 5 Dec 2018 16:55:05 +0100 (CET)
Received: from localhost (unknown []) by trail.lhotka.name (Postfix) with ESMTPSA id 3A9041820056 for <netmod@ietf.org>; Wed, 5 Dec 2018 16:55:03 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Wed, 05 Dec 2018 16:46:47 +0100
Message-ID: <871s6wt1qw.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Y35OqnaGXEaI4HSIFxsiZsw2vPQ>
Subject: [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: Wed, 05 Dec 2018 15:46:54 -0000


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

      "status": Include only if a registration has been deprecated (use
                the value "deprecated") or obsoleted (use the value

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,

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.


[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