Patrik,
PF> On May 17, 2004, at 16:40, Dave Crocker wrote:
On the other hand, we again must note the poor record of adoption of
new record types, within any sort of near-term timeframe. While it is
always possible that things will get quicker, an established
performance history suggests caution.
PF> Depends on whether you talk about the provisioning side, or the client
PF> side.
I was taling about the "usage" side. That is, whatever is involved in
making the think actually useful to... users. The track record of
achieving real utility for new RR types has been very slow indeed.
PF> BUT, one have to remember that:
I'm guessing that this is the distinction between a new RR type,
versus a new use of an existing RR. Of course, any new definition of
an SRV must overcome the user-side adoption issues (in this case,
administration by name owners and use by the rest of the dns client
world.
PF> - On the sending side, there is a problem because the DNS people in an
PF> organisation is not the same as the people managing mail, and there is
PF> not many argument(s) for the DNS people to upgrade/change their
PF> provisioning system due to some mail issues.
Well, at a minimum, your observation makes clear that a) having the
dns people change their administration model is one of the various
barriers to adoption that must be anticipated, and b) frequent or
massive changes are not likely to be feasible anytime soon.
PF> On the other hand, you
PF> need to change the provisioning and other things anyway if you want to
PF> inject MARID stuff in records, regardless of the type of the RR.
There is a difference between adding a new record, here and there,
occasionally, versus lots of new records and/or lot of changes over
time.
PF> Finally, if one run a DNS server which can not by any means handle
PF> unknown RRs (even via the provisioning, for example by use of **VERY**
PF> old version of BIND) you should most certainly upgrade your server
PF> anyway. DNSSEC etc is coming, with many many new RRs. MARID is not the
PF> only wg which is introducing (as I hope) new RR types.
My view is that this is the sort of thing that leads to failure of a new
proposal. It establishes problematic dependences for
otherwise-independent efforts.
It's not that your statements are incorrect, it is that they involve
unknown amounts of additional delay, and that sometimes the delay
turns out to be infinite. For example, the entire world was promised
that we would all be using X.400. Anyone who built that into their
business model had a problem.
In other words, predicting the future of independent activities is
always a dangerous enterprise.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>