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

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