Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)

[Ladislav Lhotka <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> 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 <[e-mail]>
>> Sent: 03 June 2021 14:17
>> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> 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