I've been asked to present some slides on this topic at the meeting
later this week. Starting with some of my own experience, and mostly
a preview copy of the txt draft cited earlier in this thread, I have
a partial set of slides done - before seeing this thread.
The first section of my slides urges the group to choose the fourth
option Andy enumerated - creating a new resource record. (Perhaps
there's an outside shot at reusing a record, I doubt that it would be
the TXT RR.) I'm using the word "urging" because this isn't a
commandment, this isn't a ruling from anyone who's been working on
the DNS for many years or even any committee. It's prudent
engineering in my personal opinion.
The reason I'm urging a new type is based on the same reason DNSSEC
has taken so long to be developed. The real reason DNSSEC has taken
so long is that the extension development process did not heed the
philosophy of the original system. (Note that I am not presenting
specifics of the DNSSEC development process.)
Not heeding the original philosophy resulted in many instances of
"corner cases" - situations in which design elements conflicted with
each other. The mere presence of "corner cases" caused out-right
implementation failures, excessive amount of protocol document work,
and a lot of failed attempts to introduce the extensions to the
operational world. The bottom line is an excessive delay (to date)
in the deployment of DNSSEC.
And delay is not what the MARID WG wants to see. (No one wants delay.)
So, how does MARID avoid this? First by looking at how DNS is
supposed to be extended. In my personal opinion, of course.
DNS has three "dimensions" of data. "Type" is one of them. The
kinds of data DNS can hold is supposed to be extended by adding
types. Yes, in the past DNS engineers feared doing so, because of
this "corner cases" have appeared.
I'm not claiming that blindly adding a new type will grease the skids
for any MARID proposal. (Note - hypothetical comment here:) But I
suspect that any approach not adding a new data type will trigger a
deeper cycle of review and more delays.
What I've put in this message isn't the complete treatment of the
topic, but it's a start. Admittedly, I've run roughshod over the DNS
protocol details here.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
Even the voices inside my head are refusing to talk to me anymore.