Re: Going forward with zero-config tunneling requirement

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 30 Sep 2004, Erik Nordmark wrote:
> Pekka Savola wrote:
> > People who have commented on this seem to have reached (off-list)  
> > consensus that draft-nielsen should be revised to be more explicitly
> > 3GPP -specific, the 'simple' mode should be removed from assisted
> > tunneling requirements, and a new document, discussing the the more
> > general 'zero-config' problem space (ISP/unmanaged, possibly
> > enterprise) should be written.
> 
> I don't understand what this would mean.
> I don't think we want a 3GPP specific (simple) tunneling mechanism,
> which is incapable to work across v4NATs, while the generic tunneling 
> mechanism (which can work across NATs) is prohibited from having a 
> simple mode i.e. a mode which doesn't require pre-registration.
> 
> But when reading the paragraph above that seems to be what you are 
> saying :-(
> 
> Did you intend to say something else?

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.

> The other big picture thing I don't understand is this space is the 
> issue about handling IPv4 NATs.
> 
> The 3GPP specific requirements do not require working across a NAT, 
> which makes sense. But I see this being used as an argument that 3GPP 
> needs a solution which is incapable of working across a NAT, which makes 
> no sense at all; if there is a solution which satisfies the 3GPP 
> requirements as stated, then whether that solution satisfies additional 
> requirements should be ok.

Personally, I completely agree with you wrt. the solution.

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

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