> Perhaps one option would be if each WG maintained a problem-statement > and rationale draft. This could reference the documents that provided > the solutions to the problems found, and act as an overview to > outsiders of the WG's previously discarded arguments, etc, as well as > how they see the specifications used in practise. > > This would act in part as Keith's "requirements document", and also > act as a lure for external (to the WG, at least) reviewers. please note: I am _not_ a proponent of requirements documents. I think WGs need to define their problems and refine their scopes beyond that stated in their charters, write down their design goals, and perhaps to try to characterize design tradeoffs. A few of those design goals thus identified might qualify as hard-and-fast requirements. But asking WGs to state things in terms of requirements is tantamount to asking them to make those design tradeoffs before they are understood. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf