RE: Proposed way forward with the transition mechanisms

["Karim El-Malki (AL/EAB)" <karim.el-malki@ericsson.com>]

Isn't there a reason number 3 you forgot about?

3) It is an appropriate solution for the 3GPP scenario.

We can't all either be conspiring to push our solution
(your reason 1) or plain stupid (your reason 2: we don't
know why we want ISATAP but it takes little work to
complete it). I haven't heard one valid technical
reason why ISATAP doesn't make sense in a 3gpp network.
So I can't see how you reach your conclusion nor a reason
why ISATAP should go experimental instead of standards
track.
/Karim

-----Original Message-----
From: Pekka Savola
To: Karim El-Malki (AL/EAB)
Cc: 'Soininen Jonne (Nokia-NET/Helsinki) '; 'v6ops@ops.ietf.org '
Sent: 7/30/2004 1:08 AM
Subject: RE: Proposed way forward with the transition mechanisms

(note -- please don't copy v6ops-owner@)

On Fri, 30 Jul 2004, Karim El-Malki (AL/EAB) wrote:
> I agree with Jonne. ISATAP is the most promising solution for 3gpp
> tunnelling so I think it should be listed amongst those that will
> proceed onto standards track. Actually I thought there had been
> enough consensus on the list for ISATAP and assumed it was on that
> list already. /Karim

FWIW, my own personal opinion...

I do not see a strong technical reason for ISATAP, especially in 3GPP.

Any relatively simple tunneling solution which requires no user
interaction to set up should be sufficient there.

The only reasons I can think of why folks want to go for ISATAP are:
 1) some have already started deploying it or piloted it, and may even 
    have already committed to it -- meaning if they care about the 
    IETF, their only option is to push for it as hard as they can.
 2) it's already "out there", requiring a smaller amount of 
    specification etc. than other mechanisms.

I personally believe that we could make do with one additional
mechanism, a tunnel server, developed based on the assisted tunneling
requirements.  If there is sufficient commitment from the people,
achieving that, even in the short term, should not be too challenging.

A significant goal has been to minimize the number of mechanisms --
"Less is More"; this was also stated by the ADs at IETF59 as well.  
Producing just one slightly more generic mechanism could help us to
obviate the need for an additional mechanism -- and thus not going for
ISATAP in 3GPP would seem useful at least for the reduction of the
required mechanisms.

And remember, ISATAP -- as implemented -- is going to be published as
Experimental RFC even if it didn't go for Standards Track -- it's
already in the RFC editor's queue.  That's sufficient for documenting
a protocol and creating interoperable implementations.  There's no
need for Standards Track (just) for that.  Standards Track should IMHO
mean just those mechanisms we really, really need -- the "IETF seal of
approval and review".  IMHO, ISATAP doesn't seem to fulfill that
criterium.

That is why I must oppose adding ISATAP to the list of standardized
mechanisms at this point.

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