Shannon -jj Behrens wrote: > If A connects to B, and B wishes to pass the connection info > to C, B only has the address with which A accessed B. If A > and B are in the same site and used site-local communication, > and C is not in that site, B does not have enough information > to refer C to A. Hence, your suggestion does not solve this case. I agree, but is it reasonable for B to tell C to talk to A, or is it more reasonable for B to tell A to connect to C by the 'name blob' it would have used to contact C? Please don't think I am picking on this instance, but the whole mode of attack by finding a failure case, without thinking through alternatives is a waste of everyone's time. > > > Doing otherwise ignores the reality that the > > network does not look the same from all points. > > I agree, and in fact, that's what I'm asking you how to work around. See above about changing the message sequence. > ... > That's true, and that sufficiently solves one side of the > problem. However, > the other side of the problem is knowing which name resolver > to go to in the first place. Unless there is some hint in the name string, the only approach I know of is to shotgun all the servers. > If I use my home resolver, I > won't be able to get the address of > (e.g.) my printer, but if I use my work resolver, I won't be > able to get the > address of my toaster. Do I need to always check both? It > seems that we're encountering this situation because DNS > implicitly assumes (at least in my limited understanding) > that choice of a DNS proxy should not affect the results. Which is my argument to the IAB: the infrastructure components that pass around topology information are completely out of step with the reality of the deployed network topology. We need to fix this because it will not get better on its own. > ... > > The fact that SL does not provide multiple concentric > security zones > > is not a failure of SL, because that was not a design requirement > > (again we need to agree on the problems to be solved). > > Well, that's a fair answer. > > By the way, I do applaud your effort in making a site-locals > requirements document. I think such a document will > ultimately be useful if it presents requirements in such a > way that people who wish to replace the functionality that > site-locals provide know what needs replacing. I am not trying to claim I have all the answers, so if anyone has content for it, please send them. Tony