Re: Going forward with zero-config tunneling requirement

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 30 Sep 2004, Erik Nordmark wrote:
> > I was saying that with s/mechanism/requirements/
> > 
> > I.e., having requirements in separate documents, allowing them to be 
> > developed separately, does not mean that the solutions need to be 
> > different.  Similarly, if all the requirements for different scenarios 
> > were in the same document, it wouldn't mean that one solution would 
> > have to fulfill all the requirements.
> 
> But you were excluding the "simple" from the assisted tunneling 
> requirements, and I don't understand why. If this is all about
> allowing different communities needing to express their requirements in 
> a separate document, then don't exclude things from the documents.

This is probably a terminology issue.  'simple assisted tunneling'
(providing simple access by 1st hop ISPs) is considered pretty much
synonomous with 'generic zero-configutation tunneling', so if a new
generic zct requirements document ends up being written, it would
cover 'simple' as well, just under a different name.  Removing it from
the 'assisted tunneling' document would help focus the document to be
solely about 'registered assisted tunneling', which is often a
completely different problem space (providing access by 3rd party
ISPs).

> > (Completely personal opinion below)
> > The critical thing will be whether the IETF 'honors' the 3GPP
> > deadlines for a [standards track] solution (November this year).  As
> > you write, doing so would be very counterproductive.  On the other
> > hand, it could be also considered practical and admitting the reality.  
> > However, as such ISATAP will already go for Experimental RFC, so there
> > will exist some documentation to create interoperable implementations
> > in any case.  There doesn't seem to be any particular reason to move
> > it to standards track just because of 3GPP.
> 
> If the purpose of the 3GPP requirements is solely to convince the IETF
> that they will use ISATAP (which they might have already decided), why 
> are we wasting time on a 3GPP requirements document?

It's already pretty much done except for the fact that a more generic 
solution would also fit the bill, if not for the timing 
considerations.

> A requirements document makes sense when multiple answers are 
> acceptable, but you seem to be saying that only one answer would be 
> acceptable.

Depends on how people interpret 'acceptable'. :)
 

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