Date: Sun, 19 Nov 2006 07:11:18 -0800
From: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
Message-ID: <198A730C2044DE4A96749D13E167AD37E7E5C9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
I don't care about this draft one way or the other, I have long since
abandoned any hope of any kind of technical solution to spam being possible
(many things help as long as they're not widely used - as soon as they
become widely used, the spammers find a "workaround" - this is after
all their income that is being affected...)
However, if this ...
| It is somewhat unfortunate that the choices draft does not take a more
| realistic approach to deployment constraints. This has been raised on
| numerous occasions but the fact is that the best information we have
| available is the information presented during the MARID working group
| which indicated that at the time only 50% of the deployed DNS
| infrastructure does in fact support new RRs in a production mode
| (i.e. you can add the RR using the standard admin tool and the
| configuration will survive a reboot).
is an example of the quality of argument that is swaying the consensus of
the group, then the IESG (and IETF as a whole) should be taking a very very
close look at what is being produced, and most probably, simply abandoning
the WG in question.
Whether it is possible to add a new RR type to an existing DNS server
(without upgrading it) - whether due to design limitations, or bugs,
is 100% irrelevant to the question of which is the best way to add
data to the DNS.
If someone wants to add a new RR type to their DNS server, and their
server cannot handle it, then they can simply replace/upgrade their server.
This is no different than anyone else who wants new functionality in
a system that doesn't support the new stuff, and nothing at all remarkable.
The same is true at the other end - if the system that wants to perform
a lookup of a DNS RR type cannot, because either its resolver, or local
DNS cache (or API, or anything else) doesn't support the new RR type,
then they need to upgrade whatever is imposing the restriction to
something newer, that can handle the new lookup.
If this were not true, then you may as well abandon DKIM now - after all,
my mailer, and most other site's mailers (I'd hazard a guess, way more than
50% of the deployed mailers) don't support DKIM, and, by the argument above,
that's enough to render the technique unrealistic.
Of course, that's absurd.
The issue that one needs to consider, is whether some third party's
system is either going to interfere with my use of the new functionality
(examples of firewalls in ISPs and similar are places where this kind
of consideration might apply), or whether the new functionality is going
to cause problems for third party systems. If those kinds of problems
are identified with a proposed solution then that's a good argument to
look elsewhere. But "the users who want to use it would have to upgrade"
is not an argument against anything - at most, between two otherwise
essentially identical approaches, it may sway the choice slightly in one
direction or the other, but in the face of any other reason to prefer one
solution to the other, this one (requiring upgrade) would (or should) be
discounted.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf