Subject: RE: Proposed way forward with the transition mechanisms

From: <[email-masked]>
Date: Tue, 3 Aug 2004 03:10:16 +0300

Hi all,

Karen made some good comments below. I am also a bit sceptic what comes to a one-size-fits-all, still unspecified solution. Given that there are widely (commercially) deployed, suitable transition mechanisms, why not standardizing them in the first place? In other words, I also would rather go for a limited number of solutions tailored for a subset of the scenarios.

What comes to longer term development, I am certainly not against developing new, more general solutions, but that might take too long time, and is it really certain that the general solution fits well in all environments (not being too heavy, etc.)?

	-Juha-

P.S. As you might guess, I also support publishing Standard's Track ISATAP (base) spec.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Karen E. Nielsen (AH/TED)
Sent: 03 August, 2004 01:57

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: "Fred L. Templin" <[email-masked]>
Date: Mon, 02 Aug 2004 19:59:50 -0700

Obviously, I agree with the comments made by Karen, Juha,
et. al. regarding the simplicity of ISATAP. Pretty much
every 3GPP document I've seen provides a compatible
specification for FQDN discovery as well.

Fred
[email-masked]