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

["Rob Wilton (rwilton)" <[e-mail]>]

Discuss cleared.  Thanks all for accommodating.

Regards,
Rob


> -----Original Message-----
> From: Ladislav Lhotka <[e-mail]>
> Sent: 17 June 2021 07:24
> To: Warren Kumari <[e-mail]>; Benno Overeinder
> <[e-mail]>
> Cc: Rob Wilton (rwilton) <[e-mail]>; [e-mail]; dnsop-
> [e-mail]; [e-mail]; The IESG
> <[e-mail]>; Paul Wouters <[e-mail]>; [e-mail]
> Subject: 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]> 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