> Mark, et al,
>
> > we looked at the process and removed most of the hurdles.
> >
> > * We cleaned up where compress domain names could be used.
> > * We formalised the handling of unknown types and classes.
> > * We gave IANA guidance on how to allocate new types and classes.
> >
> > People didn't take advantage of the changes we put in place.
> > They wouldn't listen to us when we said things had changed.
>
> Why?
Mainly FUD.
> In all other matters of adopting IETF work, the real choice of whether to use
> that work is a matter of decision by the market. If the "we" you refer to ha
> s
> not yet convinced the market of IETF developers who are designing new
> applications that use the DNS, then that "we" clearly has more work to do,
> beyond complaining or exercising a frustrating veto,
We conviced the SSH wg and we now have SSHFP.
I got DLV through relatively fast. The hardest part was
convincing the IESG that it was not a run around the IETF
process.
There was also a DLV testbed before that using a private
type value.
> > In reality it is easy to get a new type and deploy new RRs.
> > I've done it. I've watched others do it.
>
> The DNS core community seems to be missing the fact that DNS "application"
> groups keep considering the issue quite carefully -- since they are not unawa
> re
> of the push-back from the DNS core community -- and keep coming to a differen
> t
> conclusion. The considerations include extensive discussion with the core
> community.
They keep coming back with "it won't work with Microsoft"
because Microsoft decided to not support unknown RR properly.
The rest of the world has basically supported unknown RR
since word dot or has intended to support them.
As far as I can tell this is the only arguement today against
deploying new RRs. Guess what. The way to fix this problem
is to deploy new RRs. Force the broken implementation to
be fixed. If there is no pressure they won't be fixed.
> No doubt your own assessment is right and the application groups are wrong, b
> ut
> have you considered wondering why repeated, diligent consideration by groups
> interested in timely deployment of their applications come to a different
> conclusion? At the least, the core community needs to create compelling
> documentation and convince the rest of the community.
>
> However there is a meta-issue here that seems to get lost: It is the differe
> nce
> between doing things in a way that is comfortable for the folks fielding the
> application, versus doing it in a way that that group has deemed more risky.
> If
> the former does not actually break the DNS, then what is the basis for blocki
> ng it?
The problem is that continuing to use the TXT record *will*
break the DNS. IT DOES NOT SCALE. It may not be today but
as each application comes along and decides "we can use TXT
records" it is one more pile of straw on the camel's back.
We have problems today with application making "*" queries.
These are causing caches to have to fallback to TCP.
Sometimes even the TCP responses are truncated. One gets
around this by making queries for the types you want. The
same thing will happen with TXT record but there won't be
a work around. You will have to choose which protocol you
can do without.
TXT is a fine way to prototype. It is not and never will
be a long term solution. Re-using the TXT format for the
new RR is also almost always a sub-optimal solution but that
is a different arguement.
> 4. On the matter of "it won't work" as applied to "breaking the DNS", we need
> to
> distinguish between doing something that degrades aggregate DNS usage, versus
> something that limits the DNS for a particular application. Surely the
> application-related group making the decisions should be afforded the right t
> o
> decide to accept the limitations, as long as it is clear they understand the
> choice? In any event anyone complaining about their choice certainly has the
> obligation to provide detailed explanation of how it will not work or how it
> will degrade aggregate DNS operation.
>
> d/
>
> ps. I changed the Subject because this sub-thread seems to be interesting, bu
> t
> unrelated to the matter of an underscore registry.
>
> --
>
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
