Subject: RE: Proposed way forward with the transition mechanisms

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 3 Aug 2004 01:59:28 +0200

Alain,

Something else I perhaps forgot to stress in my answer, is
that 3GPP explicitly demands a lightweight protocol - tailored for usage
on mobile devices for a limited time only, draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the requirements of your document seems to be anything but that.

Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Karen E. Nielsen (AH/TED)
> Sent: Tuesday, August 03, 2004 12:57 AM
> To: [email-masked]'; 'Pekka Savola'
> Cc: Karim El-Malki (AL/EAB); 'Soininen Jonne '; [email-masked] '
> Subject: RE: Proposed way forward with the transition mechanisms
> 
> 
> > > 
> > 
> > Karen,
> > 
> > We had this discussion before. 
> 
> Yes, I know. But you, not I, started this....
> 
> This is NOT because we want to 
> > be able to 
> > support environment with NAT or prefix delegation,.. that this
> > (still to de defined) protocol will not work with no overhead
> > in environments like 3GPP where those features are not (yet) needed.
> 
> I'm a little lost here, but let me try to answers what I 
> think your question is:
> 
> There are MUST requirements in the 
> assited-tunneling-requirements document 
> that are not mandated by all scenarios (3GPP in particular).
> 
> I assume that this is based on the prerequisite that you are 
> looking for 
> one-and-only-one "zero-configuration" tunnelling protocol to 
> suit all scenarios.
> 
> Had we infinite time and infinite resources I may support 
> defining one solution that fits it all. However given that 
> this one-solution-fits-it-all isn't here for some time yet as 
> well as it may end up be an over complex monster. I would 
> rather go for a (limited, yes) number of good solutions each 
> tailored for some appropriate subset of the scenarios.
> 
> To answers Pekka email as well, what I am missing from your 
> document is a differentiation in between the various 
> scenarios. In particular a requirement should only be a MUST 
> if it is anticipated to be required by all scenarios.
> Either that or a recognition that this document isn't 
> applicable to 3GPP environments (at least).
> 
> > 
> > So you still haven't answered my question. Let me ask it 
> differently.
> > What does Isatap enable that a protocol metting the requirements
> > described in draft-ietf-v6ops-assisted-tunneling-requirements-00.txt
> > will not?
> > 
> 
> One major requirement I have which is not met by your "yet to 
> be defined" protocol
> is that it is exactly that - i.e. a yet to be defined 
> protocol. Whereas Isatap
> is defined, it is ready to use (and standardize) and it 
> fulfils the requirement of 3GPP (which is not going to wait forever).
> 
> BR, Karen
> 
> > 	- Alain.
> > 
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Aug 2004 03:07:03 +0300 (EEST)

On Tue, 3 Aug 2004, Karen E. Nielsen (AH/TED) wrote:
> Something else I perhaps forgot to stress in my answer, is that 3GPP
> explicitly demands a lightweight protocol - tailored for usage on
> mobile devices for a limited time only,
> draft-ietf-v6ops-3gpp-analysis-10.txt - a protocol fulfilling the
> requirements of your document seems to be anything but that.

Please look at the 'non-registered mode' in the document.  It could be 
*very* simple.

-- 
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: Alain Durand <[email-masked]>
Date: Mon, 02 Aug 2004 21:41:10 -0700

Karen E. Nielsen (AH/TED) wrote:
> on mobile devices for a limited time only, draft-ietf-v6ops-3gpp-analysis-10.txt 
 >
>- a protocol fulfilling the requirements of your document seems to be anything but that.

Until we made an analysis of the existing protocols that could be taken 
as is or augmented to satisfy the "goals", it is not fair to say that
the protocol will not be "lightweight".

	- Alain.