Subject: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

From: Ondřej Surý <[email-masked]>
Date: Mon, 13 May 2019 11:06:08 +0700

Hi,

I still would like to continue with this and I still think it’s a no brainer and I know this is super uninteresting
to anyone but the DNS software vendors.

But I do have a question for the WG - should we add a text that would allow the “Expert Review” to formally
DEPRECATE (as defined in this I-D) other RRTYPEs?  This would make things much simpler in the
future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...).

Ondrej
--
Ondřej Surý
[email-masked]

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
> Date: 13 May 2019 at 10:58:27 GMT+7
> To: "Evan Hunt" <[email-masked]>, "Ondrej Sury" <[email-masked]>
> 
> 
> A new version of I-D, draft-sury-deprecate-obsolete-resource-records-01.txt
> has been successfully submitted by Ondrej Sury and posted to the
> IETF repository.
> 
> Name:		draft-sury-deprecate-obsolete-resource-records
> Revision:	01
> Title:		Deprecating obsolete DNS Resource Records Types
> Document date:	2019-05-13
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
> Htmlized:       https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sury-deprecate-obsolete-resource-records-01
> 
> Abstract:
>   This document deprecates Resource Records (RR) Types that are either
>   not being used for anything meaningful or were been already made
>   obsolete by other RFCs.  This document updates [RFC1035], [RFC1035],
>   [RFC4034].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Jim Reid <[email-masked]>
Date: Mon, 13 May 2019 05:51:20 +0100

On 13 May 2019, at 05:06, Ondřej Surý <[email-masked]> wrote:
> 
> But I do have a question for the WG - should we add a text that would allow the “Expert Review” to formally DEPRECATE (as defined in this I-D) other RRTYPEs?

I'm not sure an expert reviewer could or should be in a position to make that determination Ondřej. They could probably put dead/dying RRtypes on a list that says something like "These RRtypes will be deprecated in N months time. Scream now if you disagree.". If nobody screams after a reasonable notice period, the RRtype(s) can then be killed. If there are complaints, we'd know if the RRtype(s) are still in use and/or if that use remains valid.

> This would make things much simpler in the future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...).

NINFO and RKEY were specifically created for use in .tel. If they are used there -- I don't know or care -- they should mainly be seen by the Telnic-controlled name servers and apps that use .tel domain names. [Unless Telnic's T&Cs have changed, registrants can't delegate these names to arbitrary name servers.] Someone would need to contact Telnic to find out how often these RRypes are found or looked up. They're the only ones who could say for sure if the RRtypes are obsolete or not. An expert reviewer probably wouldn't know that unless they asked.

---

From: Joe Abley <[email-masked]>
Date: Mon, 13 May 2019 12:03:20 +0700

> future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...).

I don't know what experts could be expected to know enough about the entire ecosystem to make that call. I also don't know that there's any measurement that could be used in all cases to indicate that an RRTYPE is dead. These both seem like shortcuts that could have unintended consequences.

I think it's better to rely upon a consensus process. Following the example you're setting here might mean that this is an exercise we repeat in the IETF every year or two. I think that's ok.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 May 2019 07:47:35 +0000

On May 13, 2019, at 11:06 AM, Ondřej Surý <[email-masked]> wrote:
> I still would like to continue with this and I still think it’s a no brainer

It is far from a no-brainer. The implementation of this document will leave RFC-compliant systems in an unknown state. 

A far easier approach is for any developer to feel free to treat these RRtypes as unknown RRtypes.

> future when we want to formally cleanup more obsoleted records (like NINFO and RKEY, etc...).

No; see above.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Mon, 13 May 2019 08:00:19 +0000

> RRtypes as unknown RRtypes.

I'm not sure I understand the distinction you're making here?
What you said sounds similar to what the document proposes, so
perhaps the document is unclear, or perhaps I've misunderstood you.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 May 2019 08:08:03 +0000

> perhaps the document is unclear, or perhaps I've misunderstood you.

I am proposing that we don't need a document, nor changes to the IANA registry: just treat whatever RRtypes you as a developer feel are no longer used as unknown types and move on.

--Paul Hoffman

---

From: Miek Gieben <[email-masked]>
Date: Mon, 13 May 2019 09:14:34 +0100

I agree with Paul here. Also sidesteps questions like why HINFO is not in
this list.

On Mon, 13 May 2019, 09:08 Paul Hoffman, <[email-masked]> wrote:

> I am proposing that we don't need a document, nor changes to the IANA
> registry: just treat whatever RRtypes you as a developer feel are no longer
> used as unknown types and move on.
>
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 13 May 2019 15:22:39 +0700

> I am proposing that we don't need a document, nor changes to the IANA registry: just treat whatever RRtypes you as a developer feel are no longer used as unknown types and move on.

The canonical representation of zones and RRSets can't really exist if there are no common rules about which RRTYPEs should be represented in type-specific format and which should be shown in generic/RFC3597 form. If individual implementations differed in their opinions about what is used and what is obsolete it would surely cause headaches.

I would prefer documented agreement about what is obsolete and what is not.

Joe

---

From: Jim Reid <[email-masked]>
Date: Mon, 13 May 2019 09:33:24 +0100

> On 13 May 2019, at 09:22, Joe Abley <[email-masked]> wrote:
> 

+1

Though a definition of what is meant by obsolete might be needed too: "no longer seen in the wild but could still be alive in closed environments", "deader than Elvis", "implementers MUST completely ignore this", "implementers SHOULD now treat this as an unknown RRype", etc.

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 13 May 2019 10:52:59 +0200

Paul Hoffman wrote:
> It is far from a no-brainer. The implementation of this document will
> leave RFC-compliant systems in an unknown state. 
> 

That will work for all record types except those defined in RFC 1035
since name compression in record data is allowed for them.

Kind regards,
Martin

---

From: Shane Kerr <[email-masked]>
Date: Mon, 13 May 2019 10:57:30 +0200

Paul,

> I am proposing that we don't need a document, nor changes to the IANA registry: just treat whatever RRtypes you as a developer feel are no longer used as unknown types and move on.

The problem with this approach is that it requires a developer to go 
through all of these RRtypes and read the specifications and figure out 
what each is, then try to figure out if it is something that is commonly 
in use. Probably that means going through various on-line manuals from 
proprietary implementations, as well as scanning through documentation 
and source of popular open source libraries and servers.

It seems like a lot of time could be saved by being able to look at the 
IANA list and discover that a given RRtype is deprecated.

We have a lot tribal knowledge about how to implement DNS. Reducing that 
amount seems like a good thing.

Cheers,

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 May 2019 10:51:17 -0400 (EDT)

> I am proposing that we don't need a document, nor changes to the IANA registry: just treat whatever RRtypes you as a developer feel are no longer used as unknown types and move on.

It would be helpful for new developers to know which ones to treat this
way, and the best place for that would be an IANA indication that they
shouldn't bother implementing those RRtypes specifically.

I also think it should be a dnsop decision when to make an RRtype
deprecated, not a decision by the IANA Expert.

As a quick review of draft-sury-deprecate-obsolete-resource-records-01

- Include mentioning in the abstract what deprecating means here (eg
   treat as unknown RR rather than exploding)

- The "dns paramaters" IANA reference is not good enough. It should
   specifically link to the "Resource Record (RR) TYPEs" IANA Registry.

- It should not change the Meaning field, but request IANA to add a
   deprecated field and populate that.

- Stating that Recursive DNS Servers "SHOULD warn" is bad. That is a
   denial of service in the waiting, so implementers will rate limit or
   ignore this advise anyway.

- [REcursive DNS servers ...] and they MUST NOT be re-transmitted;
   That sounds like a protocol change that should not be done by
   this document.

- "DNS Clients which receive DEPRECATED RR Types MAY interpret them
   as unknown RR types ([RFC3597]), and MUST NOT interfere with
   their transmission;"
   If they MAY treat these as unknown RRs, what else MAY they do with
   this that it is not a MUST? How do such other MAYs affect the MUST
   NOT interfere ?

- "DEPRECATED RR Types MUST never be treated as a known-type with
    respect to the wire protocol."
    Wouldn't this make all existing implementations immediately violate
    the DNS standards?

- Security Considerations - You must do better here. What happens when
   old and new implementations talk to each other, when something is no
   longer "processed" like before. Convince me there are really no
   security things to worry about. It seems the next section talks about
   "problems" so how are those not security problems?

- Operational Section - You mention problems without describing the
   actual problems. Tell us what the problems are and how to
   operationally avoid those problems when implementing this document.
   "should not cause significant operational problems" is WAAAAAY to
   weak. You are basically admitting implementing things might blow up
   in your face. Do more testing, meassuring, etc and write an actual
   Implementation Considerations section showing there are no problems
   implementing this.

NITS:

 	This document updates [RFC1035], [RFC1035],

did you forget to update the 2nd to another number?

 	are no longer in common use

Remove the word "common".

Paul

---

From: Evan Hunt <[email-masked]>
Date: Mon, 13 May 2019 16:45:04 +0000

> since name compression in record data is allowed for them.

Yes, that's exactly the problem that needs addressing. Those specific
types, defined in 1035 and containing names in the rdata, cannot now be
treated as opaque by a compliant server. We *have to* implement them so we
can handle name compression and canonicalization correctly, even though
nobody's used them for donkey's years (some of them were already labeled
"obsolete" when 1035 specified them).

There are other types that are also unused, but can be treated as opaque;
so IETF action isn't necessary for implementers to do that. Having a note
in the registry about whether they're still in use might be a kindness for
implementers. It doesn't impact interoperability, though.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 May 2019 19:30:44 +0000

> I agree with Paul here. Also sidesteps questions like why HINFO is not in

i disagree with paul here. see below.

> > used as unknown types and move on.

as with IQUERY, we must document deprecations so that implementors and 
maintainers will know which burdens they can avoid. having it be a matter of 
ad-hoc "in-crowd" knowledged passed down from mother to daughter is not the 
internet engineering way.

-- 
Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 May 2019 17:05:01 -0400

> internet engineering way.

Well, it might _be_ the Internet engineering way, but it doesn't make
for tremendous interoperability.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 14 May 2019 19:48:12 -0400

> I think it's better to rely upon a consensus process. Following the example you're setting here might mean that this is an exercise we repeat in the IETF every year or two. I think that's ok.

I'm not sure it is worth doing any more than marking some RR types as
obsolete in the IANA table, as is already done for some RR types. But
whatever is done, it should be a consensus process and I doubt it
would have to be any more often than once every 4 or 5 years...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]