> From: Keith Moore <[EMAIL PROTECTED]>
> The costs aren't just getting pushed to the multihoming site, because
> the software that has to deal with multihoming isn't just distributed to
> those users. The costs are getting pushed on to software developers,
> and from there, to
the weakest link.
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Thu 12/4/2008 4:29 PM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: The internet architecture
Hallam-Baker, Phillip wrote:
> I am trying to parse t
Hallam-Baker, Phillip wrote:
> I am trying to parse this claim.
>
> Are you saying that the DNS is fragile and raw IP relatively robust?
DNS is layered on top of IP. So for a large class of IP failures, DNS
won't work either. And if IP routing fails, DNS is likely to be
irrelevant because the a
: Bryan Ford
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: The internet architecture
Bryan Ford wrote:
> To throw in my quick $.02 (and perhaps invite more discussion :) ), I
> think we absolutely need to migrate both networking APIs and transport
> layer protocols themselves towar
Christian Vogt wrote:
>
> Keith -
>
> thanks for the careful elaboration. I agree with you that it is very
> important to consider the DNS-related issues that you identified when
> designing methods that make new use of the DNS. But note that the
> hostname-oriented network protocol stack archi
Noel Chiappa wrote:
> > From: Keith Moore <[EMAIL PROTECTED]>
>
> > for wanting to move the cost of multihoming out of the core. But
> > pushing those costs onto hosts and applications was moving those costs
> > even further away from those who benefit from multihoming, than was t
> From: Keith Moore <[EMAIL PROTECTED]>
> for wanting to move the cost of multihoming out of the core. But
> pushing those costs onto hosts and applications was moving those costs
> even further away from those who benefit from multihoming, than was the
> case in IPv4.
I am co
Bryan Ford wrote:
> To throw in my quick $.02 (and perhaps invite more discussion :) ), I
> think we absolutely need to migrate both networking APIs and transport
> layer protocols themselves toward a model where an "endpoint" is an
> opaque (to the transport/application) variable-length string of
I know this follow-up is a bit late, but on the topic of transitioning
upper-layer protocols such as transports and applications toward being
"IP address oblivious" - either by using DNS names instead, or
location-independent crytpographic identifiers as in HIP, or personal
names as in UIA,
John,
yep, I understand, and do fully agree to, your point that applications
are primarily interested in connecting to a particular service, which
makes it in general irrelevant which physical host is running the
service. Hence it is in general unnecessary to name a specific physical
machine.
Keith -
thanks for the careful elaboration. I agree with you that it is very
important to consider the DNS-related issues that you identified when
designing methods that make new use of the DNS. But note that the
hostname-oriented network protocol stack architecture, as proposed in
[1], does n
Sunday, November 30, 2008 7:11:59 AM
Subject: Re: The internet architecture
> From: Keith Moore <[EMAIL PROTECTED]>
> while it's true that IP addresses don't have the right semantics,
> neither do DNS names.
What aspects of DNS semantics makes them inapprop
On Dec 1, 2008, at 15:43 , <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Process control doesn't need IP at all at the
edge of their network.
This is a side-track, but:
Some people in the IETF, as well as in the industry, might disagree...
Watch out for the next billion nodes on the Intern
assign
them a globally routable IPv6 address. But the device itself will never see it.
-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Mon 12/1/2008 9:43 AM
To: ietf@ietf.org
Subject: RE: The internet architecture
> I know IETF thinks IP is the center of
> I know IETF thinks IP is the center of the universe and the
> one true religion. But not in process control it is not. A
> PIC controller comes with 384 bytes (BYTES, not kilo) of RAM.
This is wildly out of date. For at least the last 10 years
cheap and common PICs have been made with more R
D] on behalf of Dave CROCKER
Sent: Mon 12/1/2008 12:05 AM
To: John Day
Cc: Keith Moore; ietf@ietf.org
Subject: Re: The internet architecture
John Day wrote:
>>
>>
>> Please elaborate. I agree that the current resolution protocol is not
>> perfect but what is wrong with th
On 30 nov 2008, at 17:30, Keith Moore wrote:
DNS names as
currently used with A, , MX, and SRV records don't have the right
semantics. Part of the reason is that we don't distinguish between
DNS
names that are used to name services (which may be implemented on
multiple hosts, each of whi
John Day wrote:
Please elaborate. I agree that the current resolution protocol is not
perfect but what is wrong with the semantics of domain names?
As we have known since the early 80s, naming the host has nothing to do
with the problem at hand. It is sloppy and gets in the way of getting
Please elaborate. I agree that the current resolution protocol is not
perfect but what is wrong with the semantics of domain names?
As we have known since the early 80s, naming the host has nothing to
do with the problem at hand. It is sloppy and gets in the way of
getting it right. Curren
Stephane Bortzmeyer wrote:
On Sat, Nov 29, 2008 at 11:26:54PM -0500,
Keith Moore <[EMAIL PROTECTED]> wrote
a message of 27 lines which said:
If by "hostname" the authors mean DNS names,
I would personally make a difference between the concept of a domain
name and the protocol used to re
Noel Chiappa wrote:
What aspects of DNS semantics makes them inappropriate for this function?
And therein lies what seems to be the challenge in most id/locator discussions:
careful specification of the required characteristics for the ID.
d/
--
Dave Crocker
Brandenburg InternetWork
Noel Chiappa wrote:
> > From: Keith Moore <[EMAIL PROTECTED]>
>
> > while it's true that IP addresses don't have the right semantics,
> > neither do DNS names.
>
> What aspects of DNS semantics makes them inappropriate for this function?
I could have been a bit more precise and said
On Sat, Nov 29, 2008 at 11:26:54PM -0500,
Keith Moore <[EMAIL PROTECTED]> wrote
a message of 27 lines which said:
> If by "hostname" the authors mean DNS names,
I would personally make a difference between the concept of a domain
name and the protocol used to resolve them (today, mostly DNS).
> From: Keith Moore <[EMAIL PROTECTED]>
> while it's true that IP addresses don't have the right semantics,
> neither do DNS names.
What aspects of DNS semantics makes them inappropriate for this function?
If you could specify an 'ideal' endpoint name, what semantics and syntax
would
Stephane Bortzmeyer wrote:
> On Wed, Nov 26, 2008 at 08:44:31AM -0800,
> Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote
> a message of 431 lines which said:
>
>> In fact it would be best for the O/S to provide an API which hides
>> the details of the IP address from the application entirely in
In fact it would be best for the O/S to provide an API which hides
the details of the IP address from the application entirely in the
same way that the ethernet MAC address is hidden.
I agree and some people are working on it:
Towards A Hostname-Oriented Network Protocol Stack for Flexible
Addr
On Wed, Nov 26, 2008 at 08:44:31AM -0800,
Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote
a message of 431 lines which said:
> In fact it would be best for the O/S to provide an API which hides
> the details of the IP address from the application entirely in the
> same way that the ethernet MAC
ming
precisely because having rules about what is allowed to depend on what makes it
much easier to innovate in useful ways in the future. Discipline is not
incompatible with creativity.
Today the Internet architecture looks a bit like a program written in Cobol.
The program works, it perform
that IESG
> approves too many broken documents, and that too many WGs are having
> an adverse effect on the Internet architecture - the solution to
> this problem might somehow involve IETF process, but we would not be
> likely to find a solution by chartering a WG that is centered around
101 - 129 of 129 matches
Mail list logo
