> 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
