Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)

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

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.

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.

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

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



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