Re: [idn] Future of the requirements document

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
> It's also believed that the set of solutions that satisfy the requirements
> document in its current form is the null set.
> If that is indeed the case there should be no suprise that IDNA, just
> like any other proposal, can't satisfy all of them.
>
> *If* the requirements document indeed captured the minimum requirements
> and there were multiple fully worked out proposals then the document could be
> useful as a guide in selecting between the proposals.
> But given that the requirement document doesn't appear to (correctly) capture
> the minimum requirements it would seem like this approach assumes that the
> WG would spend time first on correcting the requirements document then
> looking around for additional fully specified proposals.
> This would not be fast process.

If we drop the agreed-on requirement document that solutions can't satify yet, we will look like a ostrich who buries its head in
the sand  before a tiger.

What really matter is whether or not we should ignore unsatisfied requirement
items. Fixing old one and writing new one, either one  cannot avoid this issue.

>
> Thus assuming we all actually want to see an IDN solution soon it seems
> to make a lot more sense to drop the requirement document.

No one would like to eat unbaked or half-baked or rotten cakes, however soon they come out. If IETF is ever driven by consumers and
work for consumers,
current provider-centric haste and biases in IDN WG could not have been tolerated.


> The WG last call, IETF last call, and IESG review can then focus on
> more basic questions like:
> 1. Does the proposed protocol work?
> 2. Can it be introduced in some incremental fashion?
> 3. Can it deal with the future?
>
> > Writing another new shorter requirements document, intentionally avoiding
> > the following hot-debated yet-unsatisfied requirement issues, looks poor and
> > is unlikely to succeed. No one would like to go to this path. It is not a
> > "path".
>
> Note that John and the chairs did not suggest a shorter requirements document
> but instead a document which describes the problem the WG set out to solve
> (and presumably something about the believed constraints for solving the
> problem).
>
> If it happens to be that the requirements document, even after resolving
> the hotly debated issues you are alluding to, ends up so strict that there
> still does not exist a solution, what would we have accomplished?

I am  not so pessimistic, if we become less political than now and in SLC.

Soobok Lee