On 11/24/14 5:26 PM, Melinda Shore wrote:
On 11/24/14 1:05 PM, Tim Wicinski wrote:
I did not say a requirements document. I said the Problem Statement, and
evaluation metrics. Neither are requirements.
I've been concerned about the proliferation of problem statement
documents (and use case documents, but less about requirements
documents). They introduce delay into the process. Sometimes that
delay is necessary or helpful but often it isn't. The situations
in which problem statement documents are helpful include those
where the working group charter is unacceptably fuzzy or where
there's a lot of contention for "ownership" of solutions. I'm
not sure that I see that a problem statement document will be
particularly helpful for moving this work forward. One thing
that might minimize the process damage from having one is agreeing
ahead of time that a dprive "problem statement" will *not* be
published as an RFC.
Melinda,
I know that when the initial charter discussion was taking place, there
was careful discussion to focus on a specific problem space, and not
letting things get out of hand.
One of the ways the ADs were going to do this was by a problem
statement. I think if you poll the IESG you will get a solid percentage
of them that are following this group closely.
Also, the chairs were not interested in letting the problem statement
drag along. We did feel everyone wants to work on their answers and
very few folks appear to place serious eyes on it.
If the group feels that the problem statement should never leave be
published, and the ADs are fine with that, we can do that. However, I
feel we can have a WGLC for the problem statement on or near 1/1/2015
and be done.
The chairs had no desires to spend time on working on requirement
documents or use case documents. That is what the wiki is for.
Also, if people want to work on their solutions, they are more than
welcome to. They do not need to have drafts adopted to continue studying.
Thanks
tim
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
