Re: [dns-privacy] I-D Action: draft-ietf-dprive-problem-statement-06.txt

[Stephane Bortzmeyer <[e-mail]>]

On Mon, Jun 15, 2015 at 01:39:40PM -0700,
 [e-mail] <[e-mail]> wrote 
 a message of 38 lines which said:

>         Title           : DNS privacy considerations
> 	Filename        : draft-ietf-dprive-problem-statement-06.txt

This version was done to address IESG
<http://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ballot/>
and Gen-ART comments. The comments which were *not* addressed are
mentioned here with explanations:


Alissa Cooper:
> You might want to include a reference to ENUM in Section 2.2.

Enum is dead.

Stephen Farrell
> primary request: "of interest to the eavesdropper" isn't quite right
> - the eavesdropper is probably more interested in the URL and not
> just the DNS name from the URL.

Depends. Anyway, "of interest" was relative to the secondary and
tertiary requests not to other sources of information.

> "glue records" - you didn't say what those are

[I-D.ietf-dnsop-dns-terminology] seems sufficient

> the [denis-edns-client-subnet] reference doesn't point at a great
> URL for an RFC, be great if there were a better reference.

It's a good text, well written, and right to the point. I have no
better reference.

> The same issue may come up wrt some of the other references.

See issue #7 <https://github.com/bortzmeyer/my-IETF-work/issues/7> I
was not able to find better references. (Personal rant: I prefer URLs
of personal Web pages, that I can find and read immediately, rather
than reference to a scientific symposium hold ten years ago and whose
speeches are not available publically.)

Joel Jaeggli
> I would probably consign the actual
> description of the dns protocol in the introduction ( paragraph 3/4) to a
> subsection 

The vast majority of the introduction is about the DNS protocol so I
believe that the rest of the section would be very small.

Suresh Krishnan (Gen-ART)
> Not really sure if it belongs in this document, but I personally think
> that DNScrypt is probably worth at least a passing mention

We give the priority to drafts adopted by working groups, which is the
case for the two mentioned in the Security Considerations as possible
solutions.

> Why is there a separate class of references for URI? Shouldn't this be
> folded into either Normative or Informative? 

This is the default behaviour of xml2rfc.