Right, the DNS is no longer providing mere hostname mapping and host discovery,
it is providing service mapping and service discovery.
dcrocker(_at_)example(_dot_)com does not connect to an IP address, the outgoing
email server first attempts to resolve MX records.
What we are discussing here is architecture, that is not just about solving the
problems of today, it is looking forward to the problems that are emerging
today and will be worse over time. Questions such as performance are really not
very relevant. It is very easy to over-optimize for the current network and use
and foreclose better ways of solving problems.
If resolving service endpoints is your biggest performance concern, you
probably don't have a performance concern.
Is the current situation entirely ideal? Certainly not, or else there would be
no work to be done. We have a lot of pieces but no integration between them.
DHCP and DNS are only sometimes integrated. If we had an architectural
statement we could make that a much stronger assumption.
Another, bigger problem is that the IETF/W3C split has led to a situation where
we don't have so many of the application developers here. Now in Web Services
land they have a model, but the original model had a box labeled UDDI which
clearly is not going to happen. So now we (apps folk) have a bunch of
bubbleware, an abstraction without a specified reification as protocol. And
there are slight differences in each instantiation.
OK we now have two standards orgs producing platform, but we can only have one
Internet architecture. And the bigger problem here is that instead of arguments
being followed through to a conclusion, each camp can retreat to its own tent.
And the discussion never gets finished.
Case in point here being the question of whether schema URIs should be URLs or
URNs. The arguments made by both camps are true. But instead of developing an
architecture that resolves both sets of requirements W3C does things one way
and IETF another.
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. Good luck getting an IP stack in there. And even if
you use a bigger processor with a built in TCP/IP stack you can only run it
over Ethernet type media. You can't use RS485 which looks a much better bet for
hardwired home automation systems to me, it is what process control has used
for decades.
What I think we need here is for IETF to construct a service discovery
architecture. By this I mean the mechanism that all future protocols MUST
support and the one mechanism that all future network layer protocol changes
will be required to support. Protocols can do whatever they like in addition.
And then the IETF needs to convince the W3C and OASIS architecture boards to
make this a requirement at their end. And this needs to be through negotiation,
not a diktat.
And the W3C needs to come up with a framework for device and service
description that works in that service discovery architecture and sell it to
the IETF. This will involve lots of angle bracket thingies but essentially it
is a MIB for applications.
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Dave CROCKER
Sent: Mon 12/1/2008 12:05 AM
To: John Day
Cc: Keith Moore; ietf(_at_)ietf(_dot_)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 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
"The problem at hand" is what, exactly? Concretely and specifically.
it right. Currently, domain name is a synonym for an IP-address. The
IP-address names the interface and is largely redundant since the MAC
address does the same thing.
Ignoring, for the moment, that a domain name does not always map to an IP
Address, nevermind that it often maps to a set of them, the fact of mapping is
not quite the same as being "synonymous". It can be -- and often is --
equivalent to find a path to the named resource. A path is not a synonym.
www.example.com is a common name for the an organization's online web presence.
That sort of description of the name is quite different from the mechanical and
narrow simplicity of a host name or a synonym for a *set of* IP Addresses that
might refer to a single machine or to multiple.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf