Re: [idn] Future of the requirements document

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

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

My concern is not "can't satisfy yet" - it is that there might not ever
be a solution which satisfies all the requirements in the draft.

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

But, continuting your analogy, keeping the cake in the oven for too long
might not be ideal either. The result could be an overcooked or burned cake,
or the people that originally wanted to eat the cake might have gone elsewhere
for norishment.

Ignoring the analogy, I don't think we can delay this work forever until
it is viewed to be perfect. 


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

I think what you refer to as "political" is really that there is a rich set
of different assumptions, as well as views on what the "real" problem to
solve, among the WG participants. While the WG discussions have let to
better shared understanding of the issues, I haven't seen any indication
that the richness in assumptions has decreased over time. (But of
course I could be wrong on this.)

But even if this issue was not present there would be significant work to
actually get the requirement document to provide the right level of
requirements i.e. walk the fine line between capturing the critical and
important requirements and overconstraining the problem by placing too many
and/or to detailed requirements.

   Erik