Re: [DNSOP] Mapping IANA deprecated to YANG status deprecated [was RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)]

[Ladislav Lhotka <[e-mail]>]

Warren Kumari <[e-mail]> writes:

> Thank you all.
>
> Having heard no objections, we will go with Rob's proposed text.
>
> Lada / Petr, please fold in this change, and then poke me LOUDLY and I'll
> hit the "Go!" button...

Done in -05.

Thanks, Lada

>
> Thanks all,
> W
>
> On Wed, Jun 16, 2021 at 7:00 AM Benno Overeinder <[e-mail]> wrote:
>
>> Thank you Rob.
>>
>> I am the document shepherd, but reply with no hats.
>>
>> I understand the concern, and I am fine with the proposed change.
>
>
>> Best,
>>
>> -- Benno
>>
>>
>> On 10/06/2021 18:05, Rob Wilton (rwilton) wrote:
>> > Hi DNS Ops,
>> >
>> > Warren, Lada and I discussed this further today.  Warren and I think
>> that mapping IANA deprecated to YANG deprecated is the right behaviour
>> here, and Lada is fine with either outcome.
>> >
>> > The main concern of mapping from IANA 'deprecated' to YANG 'status
>> obsolete' is that it would force a hard transition if any DNS classes or
>> RR's ever needed to be deprecated.  I.e., when a server picks up a new
>> version of the generated YANG types file it would be obliged to immediately
>> remove support for the 'status obsolete' definition with no grace period
>> and no option to continue using it (RFC 7950 describes this is a SHOULD
>> NOT, but this constraint is effectively stronger in the versioning related
>> drafts currently progressing in the NETMOD WG).
>> >
>> > So, the following change is proposed:
>> >
>> > OLD:
>> >       "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.
>> >
>> > NEW:
>> >                "status":  Include only if a class or type registration
>> has been
>> >       deprecated or obsoleted.   IANA "deprecated" maps to YANG
>> >       status "deprecated", and IANA "obsolete" maps to YANG status
>> >       "obsolete".
>> >
>> > Does anyone in the WG strongly object to this change?  If so, please let
>> us know by Wed's 16th.
>> >
>> > Regards,
>> > Rob
>> >
>> >
>> >> -----Original Message-----
>> >> From: Ladislav Lhotka <[e-mail]>
>> >> Sent: 10 June 2021 12:37
>> >> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>;
>> >> Warren Kumari <[e-mail]>; [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)
>> >>
>> >> "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
>> >
>> > _______________________________________________
>> > DNSOP mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dnsop
>> >
>>
>>
>
> -- 
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra

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