On Wed, 2007-02-14 at 16:43 +0100, Olaf M. Kolkman wrote: > Hello Pars, > > A few thoughts... >
Hello thanks. > > On 12Feb 2007, at 2:35 PM, Pars Mutaf wrote: > > >> The problems that you describe hardly seem related to server-less > >> name > >> resolution in a local network! > > > > > > > > The proposed protocol could also use infrastracture DNS (i.e. > > standard DNS). This would look as follows: > > > > Let us assume that Alice Collins has a personal DNS name > > "alicecollins.domain.com". Her phone has an IP address that is > > registered to this DNS name. > > > > So instead of having to remember Alice Collins' phone number you have > to remember the domain name under which her telephone-number-recovery- > services is located. This is exact. That's why I have serious doubts about using infrastructure DNS and I am promoting MNR (or name-based local IPv6 addresses) as a general but local solution. > > The requestor user enters the name Alice Collins, the proposed > > application generates the corresponding DNS name, > > How does the proposed application do that unambiguously? Given that > the 'Alice Collins' you are looking for might be a completely > different "Alice Collins" than I know. The namespace collision will > be a problem that you will need to solve. Right. Please see below in the context of MNR. > > makes a > > standard DNS query, and obtains the IP address. At this point the > > proposed application can send a private information query to > > Alice's phone. If approved by Alice (in real-time), her phone > > number can be learned. > > > > This would work globally, but I don't think this is realistic. > > (BTW, it can be noted that, one would ask why I need a phone > > number in this case.) > > Indeed, that is the argument above. > > > > > Using multicast name resolution (or, name-based IPv6 addresses) > > with human names that have local significance only, seem > > realistic to me. Here the term "local" may take different > > meanings. It may be a local cellular network that covers a large > > number of cells, or a localized mobility management domain. > > > > Such a local cellular zone can cover a large geographical area. > > This is an important progress compared to using a technology > > like Bluetooth (for exchanging private info). But the proposed > > protocol cannot work globally. That's why we need phone numbers > > and our goal is to allow people to share their phone numbers > > more easily. > > > I think the main problem will be to find a balance between size of > your "locality" and the amount of collisions in your namespace. That > will be problematic, as an illustration: Travel to Volendam (a > village in the Netherlands), walk down the street, and shout "Hey > Piet Veerman" and count the amounts of angry faces. OK. I probably won't do that if I go to Volendam :-) The automated approach to human name collisions can use a collision counter. The user enters his/her human name at configuration time: "Piet Veerman". The application will try to configure pietveerman0, and if it collides, pietveerman1, pietveerman2, etc. The user doesn't have to know which Piet Veerman he is. Note that as users move, these numbers may change. A good implementation should always look for the smallest possible collision count (but without being too aggresive). Then if you need the phone number of a particular Piet Veerman in that village, what happens? The application tries pietveerman0, if no answer, the user pushes on the NEXT button, it tries the next one until you find the searched Piet Veerman. The number of trials is left to the user. If you receive more than one responses, you will choose the right Piet Veerman, or call all of them one-by-one (you will say "sorry wrong number", etc). Another potential problem with colliding names is that for each wrong Piet Veerman, the requesting user will unneccessarily solve a challenge e.g. a CAPTCHA or other Turing tests. That's life. We cannot do more than that for colliding names (may be I'm wrong). Perhaps parents can use this application to detect collisions and avoid a colliding name for their baby? ;-)) > With the problem you are describing the number of angry faces if > relevant. If I were to activate the feature on the phone that would > provide me with the "Do you want to provide your phone number to > <foo>" and I were to receive more than 2 false positive requests for > my phone number, I would turn of the feature. So if I were the target > group solving the name collisions will be important. Yes. If there are many many Piet Veermans in the same area, this application may be less efficient for these persons. May be they should use pseudonyms. I prefer looking at the problem the following way: this would work very well i.e. without or with very few collisions for many many users. The problem to me is the need for an efficient multicast name resolution protocol (or, bypassing it ;-) Regards, pars > --Olaf > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
