ISATAP spec stability [Re: ISATAP and admin/IP domains]

[Pekka Savola <pekkas@netcore.fi>]

Whether or not ISATAP is stable or not is beside the original point, 
so I don't think I'll continue this thread..

On Wed, 19 Nov 2003, Fred Templin wrote:
> That's not what I'm saying; ISATAP is an IPv6-over-(foo) document
> whose sole purpose is to specify the operation of IPv6 neighbor
> discovery over a particular link type. 

Right..

> As such, it doesn't have any
> business specifying things that might be happening further up the
> stack. ISATAP is a substrate on top of which other mechanisms
> might be layered, but that does NOT mean specifications for
> those other mechanisms belong in the ISATAP spec.

That's fine, just don't describe that as ISATAP behaviour then (as 
you did, in the original thread, a few messages back).

> Actually, I should have more strongly disagreed with your assertion;
> ISATAP is NOT a moving target. ISATAP is stabilized, and I have
> not received any input to the contrary.

I have to disagree here.

Let's have a look at when different versions of the ISATAP spec were 
published:

draft-templin-ngtrans-v6v4compat-00.txt: Mar 2000
draft-templin-ngtrans-v6v4compat-01.txt: Sep 2000
draft-ietf-ngtrans-isatap-00.txt: Mar 2001
draft-ietf-ngtrans-isatap-01.txt: May 2001
draft-ietf-ngtrans-isatap-02.txt: Nov 2001
draft-ietf-ngtrans-isatap-03.txt: Jan 2002
draft-ietf-ngtrans-isatap-04.txt: Apr 2002
                                                                                
<ngtrans replaced by v6ops on Aug 2002>
                                                                                
draft-ietf-ngtrans-isatap-05.txt: Oct 2002
draft-ietf-ngtrans-isatap-06.txt: Oct 2002
draft-ietf-ngtrans-isatap-07.txt: Dec 2002
draft-ietf-ngtrans-isatap-08.txt: Dec 2002
draft-ietf-ngtrans-isatap-09.txt: Dec 2002
draft-ietf-ngtrans-isatap-10.txt: Jan 2003
draft-ietf-ngtrans-isatap-11.txt: Jan 2003
draft-ietf-ngtrans-isatap-12.txt: Jan 2003
draft-ietf-ngtrans-isatap-13.txt: Mar 2003
draft-ietf-ngtrans-isatap-14.txt: Aug 2003
draft-ietf-ngtrans-isatap-15.txt: Sep 2003
draft-ietf-ngtrans-isatap-16.txt: Oct 2003

.. seems to have been very much of a moving target to me :-).  Of
course, you'd argue that it *has* been a moving target, but now is
frozen.  Looking at the spec (there are a large number of things to
fix) and its past change history does not convince me.

(But of course, this is a fundamental problem caused by the fact that
there is no clear goal for ISATAP, no clear objective; it has tried to
be "little everything for everybody"; when new uses for it have come
up, it has been modified to fit.  If there was a clear goal where to
apply ISATAP and which direction to develop it, I guess the need for
fundamental changes would have gone down a long time ago.)
 
> >On the other hand, when a mechanism does not change substantially any
> >more, it's either because (1) people lost interest, or (2) the
> >mechanism is clear enough (from every angle) that there is no more
> >NEED to substantially refine it further.
> 
> (2) above best describes the case for ISATAP as I understand it.

I don't agree.

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