Subject: [dns-privacy] DPRIVE next steps

From: Tim Wicinski <[email-masked]>
Date: Mon, 24 Nov 2014 16:22:48 -0500

(I was waiting to confirm the wording with Warren, but I failed to 
remember he was away last week).

Coming out of IETF91, we saw good discussion around the problem 
statement; the beginnings of a discussion around evaluation metrics; and 
several different solutions searching for the appropriate problem.

The chairs feel that it is too early to address the solution documents. 
  We are looking to see solid work done on the Problem Statement.  It 
needs some strong editorial work to bring it front and center. It should 
be possible to generate that into a Working Group Last Call before Dallas.

Then we would like to see some action on the evaluation document. I know 
when I spoke with Allison they were having some resource scheduling 
conflicts, and I had offered to assist with the document if there was a 
working outline. Perhaps others will feel so inclined.

While I think we all like to work on solution space, we need to move the 
first part of the work forward.

thanks
tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Nov 2014 17:02:36 -0500

On Mon, Nov 24, 2014 at 4:22 PM, Tim Wicinski <[email-masked]> wrote:
>
> (I was waiting to confirm the wording with Warren, but I failed to remember
> he was away last week).
>
> Coming out of IETF91, we saw good discussion around the problem statement;
> the beginnings of a discussion around evaluation metrics; and several
> different solutions searching for the appropriate problem.

And how do we go about that?

The reason I am very skeptical of the value of requirements exercises
in IETF is that my experience is that they are almost invariably a
proxy fight for the solution space and in particular a fight to frame
the requirements so that a particular favored solution is the winner.

Which is why I believe that requirements capture should be driven by
use cases and there should be NO discussion of whether the use cases
are valid or not. Bear me out on this, I see no point in spending six
weeks arguing about whether a use case is important or not or what the
relative order of priority should be. Such efforts are invariably an
underhand approach to constraining the solution space so that the
favored proposal wins.

Rather than developing a requirements document, a Wiki would be much
more appropriate. And no need to turn it into an RFC either.

I am sure that if you narrow the scope of the work down it is possible
to find a viewpoint from which the differences between them disappear.
But what is the point in doing that? The point is to make a decision
and to make a decision, differences are useful.

> working outline. Perhaps others will feel so inclined.

I submitted such a framework some time ago:

http://tools.ietf.org/html/draft-hallambaker-dnse-02

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 24 Nov 2014 17:05:55 -0500

Philip,

I did not say a requirements document. I said the Problem Statement, and 
evaluation metrics.  Neither are requirements.

I do not expect to spend six weeks bike shedding use cases.  I believe 
we can move both of these forward before Dallas, if sufficient energy is 
put into them.

tim

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Nov 2014 13:26:46 -0900

> 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

---

From: "Mankin, Allison" <[email-masked]>
Date: Mon, 24 Nov 2014 23:11:43 +0000

Just one comment for now, before setting out into commuter-land:  evaluation is not the same as requirements.  I heard an AD statement at the mic to avoid adding any kind of requirements document, and I agree with that, as, I’m sure, do many others in the WG.

Allison

On Nov 24, 2014, at 5:02 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Nov 2014 18:23:55 -0500

On Mon, Nov 24, 2014 at 5:26 PM, Melinda Shore <[email-masked]> wrote:
> 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
> 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

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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 25 Nov 2014 11:29:28 +0100

On Mon, Nov 24, 2014 at 01:26:46PM -0900,
 Melinda Shore <[email-masked]> wrote 
 a message of 23 lines which said:

> They introduce delay into the process.

The goal of the IETF is not just to produce protocols! Documenting the
existing systems, so that people use them properly, is also necessary.

> 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.

Or simply when there is no actual solution in the short term but it is
useful to document that (a good example is section 8 of RFC 6973).

> 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.

Strong disagreement. Today, there is no comprehensive and serious
document on the privacy properties/issues of the DNS and, as a result,
people either ignore the problem or write nonsense about it.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 25 Nov 2014 14:06:17 -0500

> ahead of time that a dprive "problem statement" will *not* be

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