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

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 14:49:18 -0400

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 <[email-masked]> 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 [email-masked] 
> https://www.ietf.org/mailman/listinfo/netmod 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Jul 2019 21:08:34 +0200

Lada,

it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
section 9.6 both map to YANG's 'obsolete'.

/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
> 
> > 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
> > [email-masked] https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> _______________________________________________
> netmod mailing list
> [email-masked]

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 15:28:18 -0400

> 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  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67