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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 03 Jun 2021 04:16:27 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-iana-class-type-yang-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/

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

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

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 3 Jun 2021 15:17:14 +0200

Hi Rob,

On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote:

...

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

Yes, I will change all occurrences.

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 10 Jun 2021 09:20:08 +0000

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 <[email-masked]>
> Sent: 03 June 2021 14:17
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-
> 03: (with DISCUSS and COMMENT)
> 
> Hi Rob,
> 

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

> but we can't wait for that with this draft.

Agreed.  I'm not suggesting that we wait.

Regards,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Jun 2021 13:36:56 +0200

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

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

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

> implementation should not use it; existing implementations should phase

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