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