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

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Sun, 7 Nov 2004 22:11:48 +0100

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: [email-masked] [mailto:[email-masked]]
> 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.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 07 Nov 2004 21:07:41 -0500

Hi Karen,

Yes, when tun-auto-disc was published, the other one was still not
available. We could mention it in the next version, no problem on that.

Regards,
Jordi

> De: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
> Responder a: [email-masked]
> Fecha: Sun, 7 Nov 2004 22:11:48 +0100
> Para: "[email-masked]'" <[email-masked]>, Pekka Savola
> <[email-masked]>
> CC: "'''IPv6 Operations ' ' '" <[email-masked]>
> Asunto: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> Alain, Pekka, Jordi
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Alain Durand <[email-masked]>
Date: Sun, 07 Nov 2004 20:14:13 -0800

>as it would require one additional RT compared to the 1 RT required by the prefix'ed DNS search path approach 
You can use only one RT with the NAPTR solution using the additional 
section data.

    - Alain.