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

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