RE: Proposed way forward with the transition mechanisms

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Karen E. Nielsen (AH/TED)
> Sent: Tuesday, August 03, 2004 12:57 AM
> To: 'Alain.Durand@Sun.COM'; 'Pekka Savola'
> Cc: Karim El-Malki (AL/EAB); 'Soininen Jonne '; 'v6ops@ops.ietf.org '
> 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.
> > 
>