Re: [idn] Future of the requirements document

[John C Klensin <klensin@jck.com>]

Length and tedium warning: I'm going to try to explain the
reasons I recommended dropping the requirements doc, and what I
really recommended instead, one more time.  Those who have
ceased caring should hit "delete" now.


--On Thursday, 20 December, 2001 22:02 +0900 Soobok Lee
<lsb@postel.co.kr> wrote:

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

If we had an agreed-on requirements document, the above might be
true.  Or relevant.  But we don't.  What we have, as far as I
can tell, is a document that few people in the WG have recently
read carefully and "agreement", if any exists, that it isn't
worth the time for such reading and comment.  

It is perhaps interesting that those who have been reading the
thing carefully seem to include those who are most unhappy about
some of the recent WG directions and decisions. You, Eric, and
myself are clearly in that category, although for different
reasons.  But, unless we have reached the point of preferring no
result from the WG, or indefinite delay, if we cannot get the
solutions we each prefer --I have not-- then it is probably
better to argue about substance than about requirements
documents, especially if we can get others to read carefully and
engage in discussions on the former and not on the latter.

Speaking personally, I would have preferred that the WG not have
started on any protocol work until it agreed on a requirements
statement.  I said that at the time the switch was made.  On the
other hand, the pressures to develop protocols were very high
and it is possible that, had we taken a firm "requirements
first" course, we would still be debating them and nothing else.


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

Again, if I really saw informed and considered agreement about
those items, I would feel differently about trying to retain and
repair the document.
 
>> 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. 

At the risk of being very blunt, I believe that the real
"requirement" for the WG, as seen by a number of people, is that
it emit a standard, _any_ standard, and do so soon.  For them,
meeting one functionality goal or another may be less important.
If you think their desire is for unbaked cakes as an improvement
over eating raw and unground grain, I might agree with you.  But
the evidence from discussions in the WG and elsewhere is that
"they" outnumber "us".

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

Well, that is impressive.  At one time or another, the consumer
demand has been at least as strong as the provider demand, and
less patient.  I suggest that different consumers want different
things (just as different providers do) and that the differences
are among the reasons why it has been hard to converge on a
requirements document for which there is general agreement.  I
think some of those consumers had best be [more] careful about
what they wish for, but I've been saying that for a couple of
years now.

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

And I am more pessimistic than Erik because:

	* I don't know where to find some mechanism or drug that
	would make IDN "less political".  Instead, I see it as
	becoming more political the more time elapses before we
	have a solution.
	
	* The people who appear to be most in favor of working
	on the requirements document are those whose substantive
	positions have already been abandoned or ignored by the
	WG.

Again, I count myself, and both the "don't use tricks, use a new
Class" and the "if one needs to do some of this in a
directory/search layer, then do all of it there and don't put
the DNS at risk" positions to be in that second category.  But,
as you have noticed, I've concluded that the WG doesn't want to
address those alternatives, so I am not raising them every week,
nor am I trying to sneak them back in via a "requirements"
document.  I might feel differently about that document if the
WG were interested -- with "interest" measured in terms of
careful reading and discussion by more than a few people -- but
I don't see that interest.

And, as Erik suggests, I'm not advocating a stripped-down
requirements document, or giving up entirely.  I think that most
of the authors of the remaining proposals recognize that they
are not solving the whole problem (those who don't have probably
not been paying enough attention).  So I would like those
authors or their supporters to write introductions to their
particular proposals that document the problems they think they
are solving (and, to the extent possible, those they are not).
Such statements would give the WG, and the IETF, a much stronger
basis for evaluation than a requirements document that has, at
best, lukewarm consensus: they would permit asking, in a focused
way, whether the problem being solved was worth the trouble and
whether the proposed solution actually solved that problem.

    john