Well, I fully support the idea of a new layer above the transport with new
names and whatever names resolution system requires. I think that because the
idea is hanging in the air during so long time and being researched by academy
during number of years, there is definitely a need for a new group.
There are few, however quite strong arguments for that. First of all why limit
ourselves with the question "where the indirection layer belongs?" There is no
any indication that more than one indirection layer is possible in the stack
and if right design assumed, there will be no collision rather addition of new
functionality.
Secondly, looking far back in time (end of 70's, beginning of 80's) the right
problem was already addressed by lets say V.Serf, J. Saltzer, D. Reed, D.
Clark, .... It was identified that the current bundling of IP addresses and TCP
port numbers "allows to connect but not allows to reconnect". End-to-end
principal, besides all, states that the function distribution between layers is
one of the most important system design principals. Given that, given the fact
of multihoming, given the need for mobility support, given the need for v6-v4
internetworking, etc., there is a bunch of new stack features, which are
desirable to implement. New layer design becomes more and more demanding.
Thirdly, if to stay below transport layer all efforts will not let go beyond a
device (host) level. Obviously, there is a need for naming users, devices,
content, services or anything else one might think about. Just an example
(there are hundreds of such examples), support for multihoming does not negate
move of a flow from one interface to another (the reason does not really matter
and this is a reasonable service for applications). Staying below transport and
using current, de-facto "endpoint" - socket, which bundles IP address with port
numbers we will not get any further in doing that in a good way. This is still
multihoming of devices, what about "multideviced" users? If one has more than
one device and wants to move a flow between devices would this be possible if
implemented below transport layer? ....
Next, what really surprises, is that all talking about new functionality but
none of the existing implementations should be changed. If so, we will and
already are stuck with virtual interfaces, multiple IP addresses (even per
interface), sending multiple IP headers in packets and end up with hacks
configuring and reconfiguring routing table without even giving a try to
understand that it is not always possible and in the cases when possible might
be harmful for applications not willing to use those services requiring all
imaginable reconfigurations.
/Yuri