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

On Thu, Jun 17, 2021 at 4:38 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Discuss cleared.  Thanks all for accommodating.
>
>
... and I just approved publication.

Thanks all.
W



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


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra