[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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)" <karen.e.nielsen@ericsson.com>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Sun, 7 Nov 2004 22:11:48 +0100
> Para: "'Alain.Durand@Sun.COM'" <Alain.Durand@Sun.COM>, Pekka Savola
> <pekkas@netcore.fi>
> CC: "'''IPv6 Operations ' ' '" <v6ops@ops.ietf.org>
> Asunto: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> 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.
>> 
> 
> 



**********************************
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.