If you have a solution that requires pieces A, B and C, saying you can't deploy one unless the others are already deployed is a recipe for statis.
it's not a matter of what is being said, it's a matter of what is required for things to work well. or to put it another way, if your proposed solution requires pieces A, B, and C, but you don't even know how to build pieces B and C, there's a good chance you are on entirely the wrong track.
In general, in these discussion I am not differentiating between "edge of the network" and "hosts", because the important thing is that it's not *in* "the network" - i.e. completely unavoidable by all users.
if you think in terms of the network, what you care about is whether this functionality is in the network. if you think in terms of hosts and apps, what you care about is whether this functionality is in the hosts. to me, the important thing is that the routing functionality is NOT in the hosts. whether it's "in" the network or at the edge of the network matters less to me, because no matter what it will have to be provided outside of the host. or maybe there's room for an implementation at the border of the host and the network, especially to accommodate hosts with interfaces on multiple networks, but it needs to be feasible for single-interface hosts to work reliably without this functionality.
Once you have moved things "out of the network", it's a second order decision whether you do it in the hosts, or whether you have some intermediate set of substrate (e.g. DNS) at the "edges" (from the point of view of "the network") that does it.
no, not "e.g. DNS". there is essentially nothing about either the DNS protocol or the delegation tree or the infrastructure that lends itself to this task.
Keith
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
