On Mon, 13 May 2019, Paul Hoffman wrote:
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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
