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)]

[Warren Kumari <[e-mail]>]

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...

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