Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

On Fri, 5 Nov 2004, JORDI PALET MARTINEZ wrote:
> You mean including in the next version of 
> draft-palet-v6ops-tun-auto-disc something specific to 3GPP 
> considerations ?

Not really, though if it's believed that 3GPP's case differs 
significantly in scenarios in section 2, more text could be added 
there.  I'd think the 3GPP should be already rather well covered there 
and in the other documents.

I was referring that the 3GPP goals document might want to expand a 
bit on its endpoint discovery requirements.

See below..

> No problem in doing that. Will try to work on this next week, but can't
> promise being so fast this time !

No big hurry with this.

> Also, we have already some text regarding NAPTR, but we can expand if
> required. Any specific suggestion or text that someone want to propose ?

This was more what I was after with respect to 'tun-auto-disc' 
solution.  If Alain thought the current reference to 'tun-auto-disc' 
was not sufficient, that seemed to hint that the attributes of the 
solution might not have been sufficiently discussed in tun-auto-disc.

As to the attributes of the reverse lookup schemes, one might say a 
few good / bad sides, like:
 - bad side is that requires a lot of records
 - also requires some kind of special population of the private 
address space etc. if used between the user and the customer, pretty 
ugly.
 - increases the number of required lookups
 - on the other side, allows more flexible, IP-specific configuration

Also, two particular more generic issues, AFAIR, which could be 
discussed a bit more might be:

 - the "granularity" of the discovery process, i.e., how precisely and 
easily should you be able to modify the results of the lookup, e.g., 
tune that hosts A..B within a single administrative domain should 
discover X, hosts B..C should discover Y, etc. (for example, when 
using DNS, one way to achieve this would be split-faced DNS, or 
looking up stuff from the reverses like Alain proposes).

 - the manageability domain of the host.  It can be argued that IP 
addresses are often more "local" than host names.  A search path could 
include even all of the enterprise, all over the world, while 
customizing the lookup results (above) based on the IP address might 
go closer to the administrative domains.

It could also be argued that this may not be all that severe a problem 
here, if DNS is combined with anycast (provided that split DNS is not 
used).  Even if node X gets the same IP address everywhere by looking 
up x_srv.example.com, x_srv.example.com can be anycasted, set up 
everywhere using the same IP address.

But as said, there are certainly a lot of arguments for or against 
about this kind of customization.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings