> On 25 Mar 2018, at 15:19, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > >> We can make them optional to implement in >> the future, though. > > ...except that, if some implementer reads this document as meaning that they > don't have to handle the listed RRtypes in any special way, they could get > nailed when interoperating with implementations that handle the compression > correctly.
That’s one of the goals of the document - saying: “it’s ok to not implement those RR Types, and it’s ok to break if you receive them" > I think it would help if there were more clarity on what exactly is being > proposed, other than adding the words "obsolete" or "deprecated" to a list > of RRtypes on a website somewhere. The draft didn't seem to have > particularly clear guidance to implementers. Correct, and I was also seeking more feedback from the DNS people on that matter. Currently, there are RR Types already marked as “OBSOLETE” in the IANA registry without clear understanding what that does really mean. I guess the document might be able to specify what “OBSOLETE” means for RR Types (in the line of ^^^ “it’s ok to …”.) Ondrej -- Ondřej Surý ond...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
