[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] On identifiers, was: Re: Does every host need a FQDN
Hi Iljitsch -
But: You are arguing that (1) solving the second isn't worthwhile (2)
because it would fail to help solving the first.
No, I was saying that because 2 doesn't solve 1, 1 can't be used as a
sufficient argument for doing 2.
Ok.
<snip>
I'm thinking that if we want to make such an API so abstract that it
doesn't care about mundane details such as the transport protocol or
NAT, [...]
Hiding the transport protocol from applications would go far beyond
simply hiding IP addresses (and therefore the existence of NATs). I
was thinking of only hiding IP addresses.
[...] we probably need significant additional logic that does
discovery
and resolving, probably to the degree that we need additional protocol
logic, for instance to discover whether a remote service is reachable
over TCP vs SCTP or UDP vs DCCP.
Some functionality that used to reside at application layer will have
to move to lower layers, that's right. How much extra functionality
is needed at lower layers depends on what you want to hide from
applications. If you only hide IP addresses from applications and
transport protocols, IP-address-specific functions such as hostname
resolution, IP address selection, or NAT traversal would have to be
moved from the application layer to the IP layer. If you also wanted
to hide the transport protocol from application, you would have to go
further. But I don't see a good reason to hide the transport protocol
from applications.
I think this is worthwhile work, but my question remains: should we
take this on in RRG?
Right, this question should be thought about. I would argue that the
new API is within the scope of RRG. As I mentioned in my previous
email: A new API would make renumbering easier, and therefore
potentially facilitate the class of routing scalability solutions that
do not eliminate edge network renumbering.
Well, IPv6 solves the address depletion problem and yet the
availability of an IPv6 API hasn't helped us much here, so far at
least.
Well, that comparison is a bit off, isn't it? The reason why IPv6
solves the address depletion problem is not its new API. As a matter
of fact, the IPv6 API is conceptually no different than the IPv4 API.
What I am after is a conceptual change to the API.
But I guess we can come up with a compatibility layer at some point.
Definitely. The new API needs to be backwards compatible. Fully
agree.
- Christian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg