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

["Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>]

Alain, Pekka, Jordi

I am fine with not referencing the NAPTR draft.

My original reasoning for referencing it was indeed that it wasn't referenced
in draft-palet-v6ops-tun-auto-disc-00.txt.

Thinking more on this issue on the way here, I actually have an additional
reason for not wanting to explicitly reference this particular solution in
the 3gpp-zeroconf draft at this stage in time.

The reason is that whereas for example the prefix'ed DNS search path approach analysed in
draft-palet-v6ops-tun-auto-disc-00.txt may be a good fit for the 3gpp environment, then
the more general NAPTR solution is less optimal from the 3gpp environment perspective
as it would require one additional RT compared to the 1 RT required by the prefix'ed DNS search path approach 
- this as one in the 3gpp environment possibly may assume that the end-user knows the Ipv4 domain name.

Now, I am not trying to say that the NAPTR cannot turn out to be the unified solution for 
server discovery - provided that we are going to have one unified solution, that is - but as
it doesn't seem to be the most optimal approach for the 3gpp environment, it would
be even more wrong to single it out as a solution in this document, I think.

BR, Karen
  

> -----Original Message-----
> From: Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM]
> Sent: Friday, November 05, 2004 6:31 PM
> To: Pekka Savola
> Cc: Karen E. Nielsen (AH/LMD); '''IPv6 Operations ' ' '
> Subject: Re: other comments on
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> 
> Pekka Savola wrote:
> 
> > One comment on a comment,
> >
> > On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> >
> >>> Tunnel end-point discovery
> >>> -------------------------------------
> >>> This document should also reference
> >>> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service-
> >>> discovery-00.txt
> >>>
> >>
> >> Yes, now it should. Thanks.
> >>
> >> Let me and the other authors think about how it should be put 
> >> exactly, I have a small concern with this in the 3gpp 
> environment due 
> >> to RT delays (more or that to come).
> >
> >
> > Let me disagree here, rather strongly.
> >
> > The requirements document like this should not point at various 
> > solutions documents.  In the case of tunnel endpoint discovery, we 
> > have a good document 
> (draft-palet-v6ops-tun-auto-disc-00.txt) -- which 
> > could include more discussion relating to draft-yamamoto-, 
> but there 
> > is no need to refer to that *HERE*.
> 
> We might be in violent agreement. My point is that either the 
> requirement specs reference
> all possible solutions or none and stick to requirements.
> Referencing only one potential solution is wrong.
> That said, I agree that all the tunnel end point discovery solutions 
> should be merged.
> 
>     - Alain.
>