On Thu, Dec 04, 2008 at 04:29:51PM -0500,
Keith Moore [EMAIL PROTECTED] wrote
a message of 28 lines which said:
It's a question of whether increasing reliance on DNS by trying to
get apps and other things to use DNS names exclusively, makes those
apps and other things less reliable.
For a
On Thu, Dec 04, 2008 at 04:51:20PM -0500,
Keith Moore [EMAIL PROTECTED] wrote
a message of 40 lines which said:
Not a week goes by when I'm not asked to figure out why people
can't get to a web server or why email isn't working. In about
70% of the web server cases and 30% of the email
Rémi Després wrote:
IMO, service names and SRV records SHOULD be supported asap in all
resolvers (in addition to host names and A/ records that they
support today).
Any view on this?
a) SRV records only apply to applications that use them. to use them
otherwise would break
Stephane Bortzmeyer wrote:
On Thu, Dec 04, 2008 at 04:29:51PM -0500,
Keith Moore [EMAIL PROTECTED] wrote
a message of 28 lines which said:
It's a question of whether increasing reliance on DNS by trying to
get apps and other things to use DNS names exclusively, makes those
apps and
Stephane Bortzmeyer wrote:
On Thu, Dec 04, 2008 at 04:51:20PM -0500,
Keith Moore [EMAIL PROTECTED] wrote
a message of 40 lines which said:
Not a week goes by when I'm not asked to figure out why people
can't get to a web server or why email isn't working. In about
70% of the web server
Keith Moore [EMAIL PROTECTED] writes:
Just think how much easier the IPv4 to IPv6 transition would have
been if nothing above the IP layer cared exactly what an IP
address looks like or how big it is.
It wouldn't have made much difference at all,
Wow. I find this statement simply
Keith Moore [EMAIL PROTECTED] writes:
So it's not a question of whether DNS is less reliable than IP (it is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is). It's a question of whether increasing reliance on DNS by
trying to get apps and other things to use
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
This certainly seems to be the way that modern APIs are heading. If
I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other
scripting languages have a
Keith Moore [EMAIL PROTECTED] wrote:
please figure out how to make DNS more reliable, more in sync with the
world, and less of a single point of failure and control, before
insisting that we place more trust in it.
A while back, in the SIDR mail-list, a banking-level wish-list was
Thomas Narten wrote:
And, if one wants to look back and see could we have done it
differently, go back to the BSD folk that came up with the socket
API. It was designed to support multiple network stacks precisely
because at that point in time, there were many, and TCP/IP was
certainly not
IMO, one of the biggest challenges surrounding IPv6
adoption/deployment is that all applications are potentially
impacted, and each and everyone one of them needs to be
explicitely enabled to work with IPv6.
Or NAT-PT needs to improved so that middleboxes can be inserted
into a network to
On 12/5/08 9:59 AM, Dave Crocker [EMAIL PROTECTED] wrote:
If you are citing BSD because you think that they made a bad design decision,
then you are faulting them for something that was common in the networking
culture at the time.
Not to go too far afield, but I think there's consensus
among
It may
well be that having applications be more brittle would be an
acceptable cost for getting a viable multihoming approach
that address the route scalability problem. (All depends on
what more brittle really means.) But the only way to answer
such questions in a productive manner is
Melinda Shore wrote:
Not to go too far afield, but I think there's consensus
among us old Unix folk that the mistake that CSRG made
wasn't in the use of addresses but in having sockets
instead of using file descriptors. This was actually
fixed in SysVRSomethingOrOther with the introduction of
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
That had been the original plan and there were APIs that did that.
But for some reason, the lunacy of the protocol specific sockets
interface was preferred. I know
On 12/5/08 10:18 AM, Dave Crocker [EMAIL PROTECTED] wrote:
It's possible that this represents insight worth sharing broadly,
I doubt that very much, since it's really about API
design and ideological purity and I think has had only
a negligible impact on deployability, but
It isn't
It is so reassuring when modern is a third of a century old.
Sorry, but I am finding this new found wisdom just a little frustrating.
At 9:40 -0500 2008/12/05, Henning Schulzrinne wrote:
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS
When our group put the first Unix system on the Net in the summer of
1975, this is how we did it. The hosts were viewed as part of the
file system. It was a natural way to do it.
At 15:01 + 2008/12/05, [EMAIL PROTECTED] wrote:
IMO, one of the biggest challenges surrounding IPv6
Speak for yourself David. These problems have been well understood
and discussed since 1972. But you are correct, that there were still
a large unwashed that didn't and I am still not sure why that was.
This seems to be elementary system architecture.
At 6:59 -0800 2008/12/05, Dave CROCKER
From: Melinda Shore [EMAIL PROTECTED]
Unix ... was designed around a few abstractions, like pipes,
filedescriptors, and processes, and by the time IP was implemented we'd
pretty much settled on filedescriptors as endpoints for communications.
We could do things with them
Thomas Narten wrote:
Keith Moore [EMAIL PROTECTED] writes:
Just think how much easier the IPv4 to IPv6 transition would have
been if nothing above the IP layer cared exactly what an IP
address looks like or how big it is.
It wouldn't have made much difference at all,
Wow. I find this
Thomas Narten wrote:
Keith Moore [EMAIL PROTECTED] writes:
So it's not a question of whether DNS is less reliable than IP (it is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is). It's a question of whether increasing reliance on DNS by
trying to get apps
It's possible that this represents insight worth sharing
broadly, so I'm copying the list.
It isn't immediately obvious to me why file descriptors would
have had a major impact, so can you elaborate?
Down at the end of this page
http://ph7spot.com/articles/in_unix_everything_is_a_file
John Day wrote:
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
That had been the original plan and there were APIs that did that. But
for some reason, the lunacy of the protocol specific sockets interface
was
Not sure when the RAND work was. But if you were worrying about UDP
it was much later. When Illinois put UNIX on the Net in the summer of
75, we ran into several initial problems. There were real limits on
kernel size. So the NCP was in the kernel, telnet, etc. were
applications.
In the
Henning Schulzrinne wrote:
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
This certainly seems to be the way that modern APIs are heading. If
I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other
John Day wrote:
Speak for yourself David. These problems have been well understood and
discussed since 1972. But you are correct, that there were still a
large unwashed that didn't and I am still not sure why that was. This
seems to be elementary system architecture.
John,
After your
John Day wrote:
Not sure when the RAND work was.
1977. One of several IPC efforts for Unix around that time.
I was in that group, but had nothing to do with that work and frankly failed to
tracking its significance.
But if you were worrying about UDP it
was much later. When Illinois
In other words the failure of a university education.
At 8:46 -0800 2008/12/05, Dave CROCKER wrote:
John Day wrote:
Speak for yourself David. These problems have been well understood
and discussed since 1972. But you are correct, that there were
still a large unwashed that didn't and I am
As we all know, all attempts to turn a sow's ear into a silk purse,
generally meet with failure.
You can only cover up so much. I have written (or tried to write)
too many device emulators and every time it is the same lesson. ;-)
We use to have this tag line, when you found that pesky bug
On Fri, 5 Dec 2008, Dave CROCKER wrote:
Melinda Shore wrote:
Not to go too far afield, but I think there's consensus among us old
Unix folk that the mistake that CSRG made wasn't in the use of
addresses but in having sockets instead of using file descriptors.
This was actually fixed in
Christian Vogt - le (m/j/a) 12/4/08 10:26 AM:
In any case, your comment is useful input, as it shows that calling the
proposed stack architecture in [1] hostname-oriented may be wrong.
Calling it service-name-oriented -- or simply name-oriented -- may
be more appropriate. Thanks for the
On Fri, Dec 05, 2008 at 09:22:39AM -0500, Keith Moore wrote:
but you're really missing the point, which is that DNS fails a lot.
note that DNS failures aren't all with the authoritative servers -
they're often with caches, resolver configuration, etc.
Before the thread degenerates
On Fri, 5 Dec 2008, Keith Moore wrote:
Stephane Bortzmeyer wrote:
For a good part, this is already done. You cannot use IP addresses for
many important applications (the Web because of virtual hosting and
email because most MTA setup prevent it).
you're generalizing about the entire
On Fri, Dec 05, 2008 at 08:46:48AM -0800, Dave CROCKER wrote:
John Day wrote:
discussed since 1972. But you are correct, that there were still a large
unwashed that didn't and I am still not sure why that was. This seems to
After your or I or whoever indulges in our flash of brilliant
Keith Moore [EMAIL PROTECTED] writes:
There were also a bazillion deployed applications that would never be
upgraded to deal with Y2K. Somehow people managed. But part of how
they managed was by replacing some applications rather than
upgrading them.
There were clear business motivations
Thomas Narten wrote:
Keith Moore [EMAIL PROTECTED] writes:
There were also a bazillion deployed applications that would never be
upgraded to deal with Y2K. Somehow people managed. But part of how
they managed was by replacing some applications rather than
upgrading them.
There were
Keith Moore [EMAIL PROTECTED] writes:
Thomas Narten wrote:
Keith Moore [EMAIL PROTECTED] writes:
There were also a bazillion deployed applications that would never be
upgraded to deal with Y2K. Somehow people managed. But part of how
they managed was by replacing some applications
Thomas Narten wrote:
I suppose it follows that people don't actually need those applications
to work in order to continue doing business... in which case, of course
they shouldn't upgrade them.
Keith, this is umbelievably simplisitic logic.
This whole discussion is unbelievably simplistic
Yes, that is indeed where the world is going.
My point is that it would be nice if the IETF had a means of guiding the
outcome here through an appropriate statement from the IAB.
Legacy applications are legacy. But we can and should push new applications to
use SRV based connections or some
Am 05.12.2008 um 11:25 schrieb Rémi Després:
Christian Vogt - le (m/j/a) 12/4/08 10:26 AM:
In any case, your comment is useful input, as it shows that calling
the
proposed stack architecture in [1] hostname-oriented may be wrong.
Calling it service-name-oriented -- or simply name-oriented
41 matches
Mail list logo
