Re: Comments on zeroconf draft

["JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>]

Hi Pekka, all,

See my response in-line, below.

Regards,
Jordi

---- Original Message ----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
Cc: "'Radhakrishnan Suryanarayanan'" <rkrishnan.s@samsung.com>;
<juha.wiljakka@nokia.com>; "V6OPS WG" <v6ops@ops.ietf.org> Sent: Wednesday,
September 08, 2004 1:14 PM Subject: RE: Comments on zeroconf draft

> My personal opinions only.
> 
> On Wed, 8 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
>> Apart from this as i had already mentioned in my previous mails
>> about a thought of expanding the applicability of this document
>> beyond 3GPP. Maybe this is for the WG chair to decide.
>> 
>> [Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect
>> also. [...] 
>> 
>> Now given that we have the requirements, this document could be used
>> to decide:
>> 
>> * Initial: whether the 3GPP case is sufficiently different from
>> assisted tunnelling for it to have its on life requirements wise
> 
> I'd say, no, "zeroconf" requirements are common enough; some are
> 3GPP-specific, but many are not.  Then a logical approach would seem
> to be have a "generic requirements" section (which would still be
> sufficiently grounded in the operational scenarios), and sections on
> specific requirements under different scenarios.

I've a similar view. I think it will be very useful to, once we have finalized the actual 3GPP specific requirements, complement or even rearrange the document in such way that we describe what of those requirements fit also in other scenarios (not just 3GPP). But we need to understand, as already explained before, that the main goal of the document is 3GPP. I mean, once 3GPP is done, now is more and more clear for all that it also provides a good set for a simple solution that could fit very well in other situations.

> 
>> (and solution wise) - (if not the timing requirements alone makes it
>> necessary for it to have its own life).
> 
> IMHO, as this is just the requirements, the solutions could be the
> same or not if everything was done under the label of "zeroconf", so I
> don't see this as a big factor.
> 
>> * Subsequently: if zeroconf tunneling as a concept is granted its
>> own life, are there additional scenarios where this may be
>> applicable.
>> 
>> Further are the additional requirements that should be served by
>> zeroconf tunnelling so that it will be applicable to additional
>> scenarios, which do not fit within the framework of assisted
>> tunnelling.
> 
> IMHO, yes.
> 
> I can't see additional requirements which weren't there under the
> assisted tunneling.
> 
> Remember that assisted tunneling went out to provide requirements for
> two different cases:  "zero-conf -like", and "controlled".  Now that
> there is draft out on "zero-conf -like", it doesn't seem to be useful
> to cover that under assisted tunneling, but just make it cover
> "controlled".  Overlap won't do us any good..

This is a very good point. Actually zero-conf looks for a simple solution, which probably means not-controlled (assumed to be "self-controlled" because only works for the own-network-customers, read own-network as the ISP network, 3GPP network, enterprise network, etc.).




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