> The only way you > can get the handle you are looking for is to have something below you > sort out the topological reality. I agree the current name service is > not up to the task, and I believe that we need to get that fixed. > Unfortunately it looks like it will take some very crisp architectural > guidance to get the IESG to refocus the DNS related WGs to even discuss > the issues. if the architecutral guidance were crisp it certainly wouldn't be asking the DNS related WGs to discuss those issues. DNS cannot solve this problem. > As long as the handle stays contained within the machine you are fine. > The problem arises when the app passes that handle to another node, > believing that the topology specific information is already there. If > the blob passed were the same as what the app used to acquire the local > handle, the other nodes would acquire appropriate local handles. this presupposes that the blob that is passed is precisely and reliably bound to the specific host or process that the app wants to refer to, and also that the lookup process that maps blobs to locators and/or identifiers is sufficiently fast and robust. often neither of these conditions holds. > The problems arise from the > mismatched interpretation by the apps, that all 'handles' will be > treated equally by the network, heaven forbid that apps would assume the same thing that the IP network was designed to assume - that there is a uniform address space across the entire network. but you want to change this fundamental architectural design point at layer 3 and then claim that the resulting problems are caused by inappropriate assumptions at layer 7. some would say this is layering violation, but the sharing of identifiers between layer 7 and layer 3 is another fundamental architectural design point. > I agree to a point. My button is pushed by those that claim a technology > 'creates more problems than it solves', when they simultaneously admit > they don't have a clue what problems need solving. I do have an idea about what problems need solving, but I don't claim to be able to make a list that satisfies everyone at the drop of a hat. But it's not clear that SL was actually intended to solve any of these problems. Rather, it seems to me that somebody thought SL was a good idea, and put it into the v6 architecture. And then various people started saying "hey, we can use SL for X", and nobody bothered to examine whether there were conflicts between those various peoples' assumptions (whether specifically about SL or not), or even whether SL was worth the cost, until recently. The problem with trying to make a list of "SL-related problems" is that there is also a set of problems that don't directly involve SL but also need to be solved, and SL precludes solving those problems. Keith