Subject: Re: [Mipshop] WG Last Call comments on draft-ietf-mipshop-lmm-requirements-00.txt

From: gabriel montenegro <[email-masked]>
Date: Sat, 01 Nov 2003 09:29:04 +0100

James Kempf wrote:
> So what is the point of the requirements document then? 

The usual, but notice we're not working on standards track stuff.
If we were, we'd have more of the multi6 problem Pekka refers to.

It's a snapshot of what folks think the requirements are if we were to
work on a standard-track MIP-based lmm protocol. As such, it is thought to be
valuable information to capture. That does not mean our experimental
protocols will have to comply with them completely. The idea is to
get these out quickly, and document non-compliance rather than reworking
it much longer. So even though the lmm document seems valuable to
publish as informational material, the main point of the WG is to
publish experimental protocols, and we don't want this lmm document
to "get in the way".

One might think that perhaps "historic" status also could be
appropriate, but that carries a sense of obsolescence, and I'm not
sure we've concluded that this is the case.

Thoughts?

-gabriel

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Nov 2003 10:26:18 -0800

> If we were, we'd have more of the multi6 problem Pekka refers to.

Yes, I'm sure that would be the case. We had the same problem in Seamoby
with the context transfer requirements (2.5 years of arguing, nothing in the
end).

> publish experimental protocols, and we don't want this lmm document

Agree about the main point of the WG, but I'm having some difficulty seeing
what the point is of a requirments document that isn't intended to guide any
standards development, and will be irrelevent to the IRTF effort, if the
IRTF effort is really open to alternative solutions.

In Seamoby, we discarded our problem statement and requirements documents
when we decided to take the protocols to experimental. There's little point
in increasing the IESG's work burden for something that isn't really
necessary for the standards process. And, if a technical area is to be
opened for research, requirements that have embedded in them a desired
solution are too inhibiting, because people must be prepared to think "out
of the box" to get creative solutions.

> sure we've concluded that this is the case.

The problem with publishing such a document is people can cite it such as
they have done for the Seamoby paging requirements (RFC 3132 which I was the
unfortunate editor of) as a way to keep alternatives from being considered,
or for considering solutions that are architecturally or technically flawed
but which nevertheless satisfy the requirements.

Let me give you a "for instance". Suppose somebody comes up with a really
cool localized mobility management solution in IRTF that is architecturally
clean but doesn't involve Mobile IP. People can use the requirements
document politically, to try to supress this idea rather than letting it
come to the IETF.

            jak