Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE]

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka Savola wrote:

> On Wed, 19 Nov 2003, Fred Templin wrote:
>  
>
> > I don't agree that the items you are citing as "not in draft-16"
> > actually need to be specified there.
> >    
>
> If you want to say ISATAP does (foo), it has to be specified to do 
> (foo).  If it isn't specified, it ain't there..

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

> > Also, as to your assertion that ISATAP is a "moving target",
> > the best way to address that would be to either publish it as
> > an RFC now or make it as a v6ops wg item. I prefer the
> > former; we have seen recently how easily RFCs can be
> > (bis)'d so there is no reason to believe that publishing now
> > would amount to casting things in stone.
> >    
>
> I have an entirely different opinion (about publishing as RFC).  
> There is little use documenting a snapshot of a "moving target".  
> That'd clearly show that the moving target has not been specified well
> enough, had its applicability considered at enough length, etc. -- 
> because otherwise it would not be moving any more.

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.

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

> When there are still substantial issues to be ironed out, about the 
> only way to generate a revision of the spec would be creating a 
> non-interoperable new version using a new suffix.  I'm not sure if 
> that'd be warranted either.

Not warranted in my view as there are not still substantial issues
to be ironed out to my knowlege.

Fred
ftemplin@iprg.nokia.com