[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Going forward with zero-config tunneling requirement

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


(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?
A requirements document makes sense when multiple answers are acceptable, but you seem to be saying that only one answer would be acceptable.

I don't have a problem with an experimental RFC describing ISATAP as currently implemented, and perhaps a separate document describing its limitations.

   Erik