ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [ga] Letter from ICANN to New.net


> From: Kent Crispin [mailto:kent@songbird.com]
> Sent: Friday, July 27, 2001 3:03 PM
> 
> On Fri, Jul 27, 2001 at 02:33:49PM -0700, William S. Lovell wrote:
> [...]
> > being expressed. What is being said by Mr. Crispin, and the 
> positions
> > being taken by this "protocol community," are based upon business
> > interests, not technology.
> 
> Nope.  They are based on technology.

In that case, the proof is ready for refutation ... where? It *does* include
running code, right?

Note that MHSC has had running code up for four years and every one of those
systems is connected via the Internet and are publically available. Also
ROOT-SERVICE.NET has had root zone servers on various colo clients for over
three years now. One of them is a very popular photo sharing site. It is
definitely connected to the Internet and sees more than 40 Mbps of traffic
24x7. it's part of a 4-way DNS cluster. You can reference one of the
resolvers, at 209.249.202.166, ignore the cache poisoning FUD.

Name space collisions are a people problem, not a technical one. This is why
the IAB abd PSO has no place pretending to authority on this issue.

> > > Right.  Medicine doesn't exist for the benefit of doctors.  But if
> > > doctors tell us something is a bad idea, we generally 
> listen.  If we
> > > got practically universal agreement among doctors that a 
> procedure was a
> > > bad idea, we should almost certainly dump it.
> > 
> > Again, the analogy doesn't hold.  There is no "practically universal
> > agreement."
> 
> Yes, among knowledgable protocol designers, there is.  You apparently
> don't hang out with such people. 

I can point out a whole crowd that disagrees. If you want to claim that they
are not knowlegable, then we can get down to a plain old fashioned coding
contest, or compare resumes, including my own, which is it? My choice of
weapons is gcc, on a Linux box, no GUI tools. My lab or yours?

> > > The problem is protocol engineering really is a species of "rocket
> > > science"* -- it takes a long time to really understand 
> the issues.  And,
> > > despitewhat you hear, most of the participants on these 
> lists really
> > > aren't rocket scientists of the proper variety.
> > 
> > So IETF presumes to speak for these non-rocket scientists?
> 
> Don't be silly.  The IETF speaks about protocol matters.  It is not 
> speaking *for* you or anyone else.

That we differ between unified-root or partitioned-root are not protocol
issues. In fact, the DNS is a distributed application that uses a particular
protocol. The application layer is what we are talking about.

> > Not for
> > me.  The problem with a group such as the IETF (to whom several
> > years ago I had begun to look to for expert guidance, but then gave
> > that up quite rapidly when I saw what it had done and was doing)
> > is that it becomes an in-grown cabal of "right thinkers," for whom
> > "right" more often has a business than a technological origin.
> 
> That simply illustrates your own lack of knowledge, I'm afraid.

I'm afraid that simply illustrates your level of troll-factor.

> >  My
> > profession lies in determining what technology will work, and what
> > will not, and when are things being done for technological reasons
> > and when are they not.  I have learned not to depend on the IETF
> > for anything.
> 
> I look forward to the cessation of your use of email, then, 
> since the design 
> of the email protocols came straight out of the IETF...

Current email protocols came straight out of sendmail. Eric will be quite
surpised to hear you claim otherwise. IETF adopted them after the fact.
FidoNet had email back in 1982. IETF didn't exist until 1989 or so. ...
amazing how those time-warps work to your sole benefit.
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>