On Mon, Nov 24, 2014 at 5:26 PM, Melinda Shore <[email protected]> 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.
I don't think the problem is with doing use cases, it is the way we do them. We have this waterfall model in which we first agree on a common direction, then choose a solution. I see no reason at all to agree on a common direction until we pick a solution. The reason I am excluding consideration of hard traffic analysis in my work is because I don't know a good solution. If someone proposes a viable solution then I am more than happy to apply it. So having an argument as to whether we consider traffic analysis misses the point, I have absolutely no problem with it as a requirement. I just object to the cost of potential solutions. > 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 think it is useful to put proposers of solutions on the spot and ask what problem they are trying to solve. Sometimes it causes folk to admit that another proposal actually solves their problem better. > 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. I would suggest: 1) Don't publish as an RFC 2) Don't wordsmith 3) Don't exclude or prioritize until after solutions are proposed. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
