Subject: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt

From: "Bound, Jim" <[email-masked]>
Date: Thu, 4 Nov 2004 14:37:13 -0500

Same comments as the previous on 3GPP zeronconf but this spec does
address IP4-in-IPv6 tunneling which is good all be it only basically and
needs more work.  But again has assumptions of the network working in
lieu of NATS ad Firewalls and I am not clear that is a valid assumption
for many cases.  

http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-re
qs-01.txt

It seems to be that this zerconf spec, 3gpp zerconf spec, and assisted
tunneling spec have many common properties and could we reduce this to
just one spec?

Thanks
/jim

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Nov 2004 22:39:42 +0200 (EET)

Hi,

> tunneling spec have many common properties and could we reduce this to

Yes, they certainly share a number of common properties.

However, the problem spaces they're covering seem to be slightly 
different.

In particular, the assisted tunneling assumes explicit user 
registration, which typically maps to providing the service to 
pre-agreed (registered) third parties or as a VPN-like service 
(without encryption).  Registered mode can of course also be used in a 
scenario where registration is not really necessary. If you will, one 
could imagine non-anonymous-mode TSP as an instance of this model.

Now, the explicit goal of both zero-conf documents is to avoid 
registration, and to provide just a simple, very easy way to obtain 
connectivity, without the bells and whistles.  One could consider 
ISATAP run inside an enterprise an example of this kind of solution, 
or a simplified, anonymous-mode, TSP-like solution.

Hence, there is IMHO some value in keeping these separate even though 
there is overlap.  On the other hand, I personally think that the 
documents do not currently describe sufficiently clearly what I wrote 
above, so a reader unfamiliar with the work is unlikely to see much 
difference there at least at first.

That said, if folks think more consolidation is good, to eliminate 
overlap and make it more concise, yes, that's a possibility -- please 
speak up.  This comes with the expense of blurring the (special, and 
conflicting) requirements of different scenarios, though.  Not an easy 
tradeoff.

(We actually tried to start with this project as one spec -- 
draft-ietf-v6ops-assisted-tunneling-requirements-00 intended to cover 
all the cases, but 3GPP folks wanted to separately clearly describe 
their own requirements, and then generalized case of 3GPP was also put 
in a separate document.  So, I guess this argues that there was 
attempt at doing just one document, and it didn't quite work out due 
to differences in requirements esp. from 3GPP..)

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 Nov 2004 00:34:04 +0100

Hi Jim,

I totally agree here.

As one of the co-authors, I precisely asked to include other tunneling
options (namely 4in6 and 6in6) as a must.

In a message that I sent to the WG a few days ago, I explicitly asked the WG
opinion on that ...

Regarding to having a single document, the idea was initially like that, but
then we come out to the conclusion that is easier, because different small
particularities, to work in separate documents, and may be join some of them
at the end, but I'm now not absolutely clear about that being so easy.

Instead, if we can find a single solution for all the 3 requirement
documents ... then it will be easier at that point.

Regards,
Jordi

> De: "Bound, Jim" <[email-masked]>
> Responder a: [email-masked]
> Fecha: Thu, 4 Nov 2004 14:37:13 -0500
> Para: <[email-masked]>
> Asunto: Comments: draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
> 

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