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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf