-----Original Message-----
From: Ladislav Lhotka <ladislav.lho...@nic.cz>
Sent: 10 June 2021 12:37
To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>;
Warren Kumari <war...@kumari.net>; michelle.cot...@iana.org
Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org;
dnsop@ietf.org; be...@nlnetlabs.nl
Subject: RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-
03: (with DISCUSS and COMMENT)
"Rob Wilton (rwilton)" <rwil...@cisco.com> writes:
Hi Lada,
I've also copied Michelle on - since I think that it would be helpful for IANA
to at least be aware of this discussion.
Sorry for being slow to get back to you. I've expanded on my discuss
comment below, but it may be helpful for you, Warren, I, possibly Michelle,
to have a quick chat to see if we can resolve it.
-----Original Message-----
From: Ladislav Lhotka <ladislav.lho...@nic.cz>
Sent: 03 June 2021 14:17
To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>
Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org;
dnsop@ietf.org; be...@nlnetlabs.nl
Subject: Re: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-
yang-
03: (with DISCUSS and COMMENT)
Hi Rob,
On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote:
...
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
One issue that I think we should should discuss and resolve (sorry for
the
late
discuss ballot):
In section 4, it states:
"status": Include only if a class or type registration has been
deprecated or obsoleted. In both cases, use the value "obsolete"
as the argument of the "status" statement.
I know that we have had some previous discussion on this on Netmod,
but,
if
draft-ietf-netmod-yang-module-versioning-02 gets standardized then it
will
effectively evolve YANG's "status deprecated" into "must implement or
explicitly deviate" and YANG's "status obsolete" into "must not
implement".
It
wasn't clear to me that marking one of these fields as being deprecated
in
an
IANA registry would mean that existing implementations must stop
using it
if
they migrate to a new version of the generated YANG module. Hence, I
think
that at this stage, it may be safer to map IANA "deprecated" into YANG's
"status deprecated"?
Yes, this was discussed repeatedly in NETMOD and DNSOP WGs. I think
we
currently have to use RFC 7950 for the status definitions, and so in YANG
o "deprecated" indicates an obsolete definition, but it permits
new/continued implementation in order to foster interoperability
with older/existing implementations.
This is incompatible with the meaning of "deprecated" in IANA
registries, which is per RFC 8126: "use is not recommended".
I don't think that there is a perfect answer here, and I think that for the
moment we are looking for the least bad option.
The YANG and IANA definitions of deprecated are obviously different,
but it isn't clear to me how different they actual are from those definitions.
E.g., in neither case do they indicate why they are going away (e.g.,
because they are no longer used, or there is a better way, or there is a
security issue).
I would also argue that "use is not recommended" applies to the YANG
"deprecated" as well, and generally matches what I understand what
deprecated means.
One strong case that was mentioned in DNSOP discussions was a
compromised crypto algorithm. It will be marked as deprecated in IANA
registries, and it is highly undesirable to "foster interoperability" by using
it.
In fact, this I-D started with mapping IANA deprecated/obsolete to the same
term in YANG (which is what RFC 7224 does), but we were forced to change it
due to the above objection.
But ultimately there are two choices here:
(1) Map both IANA deprecated and obsolete to YANG obsolete as your
draft
proposes. If the text in draft-ietf-netmod-yang-module-versioning-02 gets
standardized then this means that there will be no way to indicate a DNS
class type that shouldn't be used anymore and is going away. Either it is
"current" and can/should be implemented, or it is "obsolete" and it cannot
be
used once the server pulls in the new revision of the types YANG file. I.e.,
there isn't even a mechanism to deviate it to indicate that it is still
supported,
there is no possible transition window.
Maybe the RFC can then be updated to reflect this evolution? In our view,
mapping both terms to "obsolete" in YANG is currently the safest option.
(2) Map IANA deprecated -> YANG deprecated. IANA obsolete -> YANG
obsolete. With vanilla RFC 7950, the server may or may not
implement the deprecated value, and it can use a deviation to be
explicit. If draft-ietf-netmod-yang-module-versioning-02 gets
standardized: The server is expected to implement it or use a
You probably mean "The server is expected NOT to implement it or ...",
right?
deviation. I.e., there is still a mechanism to allow a server to
implement if they need to, but equally they can also choose not to
implement it.
I'm still of the opinion that (2) is the least bad option out of the two above.
Our YANG module probably doesn't have anything as critical as crypto
algorithms, so it might work. I am a bit worried about the reaction of DNSOP
WG though: it will open another round of discussion, and some people might
fiercely oppose this change. This seemingly simple I-D was started already
almost 3 years ago. :-/
A third possibility, a variant of (2), would be to map IANA deprecated to
YANG
deprecated, but also update the type description to indicate that "Per the
IANA [XXX] definition of 'deprecated', use is not recommended. New
implementation should not use it; existing implementations should phase
out support for it."
This would be possible, too, but my concern about further delays still
applies, so I would prefer to avoid any changes.
Pragmatically, I don't think that a DNS CLASS or RR TYPE will ever become
deprecated (obsolete is OK), so it might be a non-issue anyway.
Cheers, Lada
I agree that this discrepancy should be solved in a new version of YANG,
possibly along the lines of draft-ietf-netmod-yang-module-versioning-02,
but we can't wait for that with this draft.
Agreed. I'm not suggesting that we wait.
Regards,
Rob
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Hi,
Thanks for this document. I think that documenting this fields in YANG
is a
good thing.
One minor nit:
In an couple of places you have used 'analogically' but perhaps meant
'analogously' instead?
Yes, I will change all occurrences.
Thanks, Lada
Thanks,
Rob
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
