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. In fact, this reasoning is in line with the new network
protocol stack architecture proposed in [1]:
As I explained to Keith in my previous email, in the proposed stack
architecture, connections are initiated by specifying a remote service
instead of a remote host. They are initiated using the combination of a
service name and a DNS hostname, where the hostname is, despite its
intuitive meaning of being specific to a physical machine, just a set of
IP addresses through which the service of interest can be reached.
Of course, it would alternatively be possible to directly embed service
semantics into DNS hostnames, similar to what we do today with SRV
records. The result would then be a name, retrievable via the DNS, that
specifies a service in globally unique manner. I am open to such
embedding, but the embedding would conceptual make no difference. There
are two reasons why I chose to separate service names from hostnames in
the initial design of the proposed stack architecture: First, due to the
different constraints for service names versus hostnames: Only
hostnames can be selected freely; service names need to be well known.
Secondly, because service names and hostnames don't always go together:
To accept incoming connections, only a local service must be named, but
a local hostname is unnecessary. And to filter incoming connections,
only a remote hostname is needed, but not a remote service name.
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 input.
- Christian
[1] Christian Vogt: Towards A Hostname-Oriented Network Protocol
Stack for Flexible Addressing in a Dynamic Internet,
http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf
On Dec 1, 2008, John Day wrote:
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. 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.
Naming the host is sometimes useful for network management purposes,
but
really has nothing to do with the problem of forwarding or delivering
packets. I realize there is a lot of sentimental attachment to the
idea
of naming a host, but as I said that was a sloppy habit we got in very
early and for some reason sloppiness has prevailed.
The "entity" to be named is whatever the packets are delivered to.
That
may reside on a host, but that fact is purely coincidental. As long
as
sentimentality trumps logic, it will be difficult to get it right, but
in the current climate it will be possible to publish a lot of papers.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf