On 25 Mar 2018, at 9:05, Evan Hunt wrote:
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.
Fully agree. I would hope that such guidance gets into the draft before
it moves forwards.
These RR types have text representations and wire format
representations,
which from a complexity standpoint seem quite harmless to implement.
Yes.
There
are the old annoying rules about name compression and sorting, which
do add
some complexity, but are already implemented in all the existing
codebases.
....and probably needs to be kept for the future to interoperate with the
current code bases.
I don't see how the IETF can mandate that they be removed, nor am I
sure
it's particuilarly worth doing.
Right.
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.
Perhaps that's all Ondrej has in mind?
Only he can say. :-)
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
