Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04

From: Joe Abley <[email-masked]>
Date: Wed, 15 Apr 2015 17:09:07 -0400

I am an assigned INT directorate reviewer for <draft-ietf-dprive-problem-statement-04>. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

I have reviewed the document draft-ietf-dprive-problem-statement-04.

General

The document adopts a colloquial style which I think achieves the goal of presenting the various aspects under consideration in a clear and understandable way. The document structure makes sense and covers the various angles well. The treatment seems comprehensive, as is the document's self-stated goal.

There are various DNS-specific acronyms which are not expanded at first use and whose capitalisation occasionally varies from that seen in other documents that have a DNS focus (e.g. qname vs. QNAME). There are also a small number of grammatical/typographical errors. These are not addressed in this review, since the RFC editor will do a better job at it than I could.

I picked out a few suggestions for improvement in the sections that follow, but on the whole I think the document meets its objectives well and as an individual contributor I would not object to it proceeding without any further changes.

Specific

Section 1: Introduction

Paragraph 2: the DNS specification (if we can suggest that one exists at all, with a straight face) is more than just 1034/1035. Suggest s/is specified/was originally specified in/.

Paragraph 6: it seems reasonable to note that forwarders also don't see the identity of the client that originated the DNS request either, since the query they receive was originated from a downstream resolver rather than an end user. Arguably, different privacy concerns exist with knowledge of the identity of the stub resolver, the content of the query, and the combination of the two. You cover this in section 2.2, but I think foreshadowing that in the introduction is worth considering.

Paragraph 7: DNSCurve provides another channel encryption mechanism. I appreciate that it's not specified in the IETF, but it exists and people use it.

Paragraph 8: "almost all" seems like it would benefit from a citation (that should not be hard to find).

Section 4: Legalities

I wonder about the wisdom of appearing to give legal advice in this document. Unless we are able to cite a study by someone properly qualified in international and all national laws, this section seems awkward. It's fair to say that no DNS-specific laws are known to exist by non-lawyers in the combined experience of the author and the reviewers, but that level of qualification starts to look like we don't really have anything to say.

(review ends)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2015 21:14:43 +0000

Thanks Joe!!

- Bernie

-----Original Message-----
From: Int-dir [mailto:[email-masked]] On Behalf Of Joe Abley
Sent: Wednesday, April 15, 2015 5:09 PM
To: Terry Manderson
Cc: Warren Kumari; Stephane Bortzmeyer; [email-masked]
Subject: Re: [Int-dir] INT-AREA Directorate Review Request - draft-ietf-dprive-problem-statement-04

General

Specific

Section 1: Introduction

Section 4: Legalities

(review ends)

---

From: Terry Manderson <[email-masked]>
Date: Thu, 16 Apr 2015 02:08:29 +0000

Thanks Joe!!

Cheers
Terry

On 16/04/2015 7:09 am, "Joe Abley" <[email-masked]> wrote:

>I am an assigned INT directorate reviewer for
><draft-ietf-dprive-problem-statement-04>. These comments were written
>primarily for the benefit of the Internet Area Directors. Document
>editors and shepherd(s) should treat these comments just like they would
>treat comments from any other IETF contributors and resolve them along
>with any other Last Call comments that have been received. For more
>details on the INT Directorate, see
>http://www.ietf.org/iesg/directorate.html.
>
>The document adopts a colloquial style which I think achieves the goal of
>presenting the various aspects under consideration in a clear and
>understandable way. The document structure makes sense and covers the
>various angles well. The treatment seems comprehensive, as is the
>document's self-stated goal.
>
>There are various DNS-specific acronyms which are not expanded at first
>use and whose capitalisation occasionally varies from that seen in other
>documents that have a DNS focus (e.g. qname vs. QNAME). There are also a
>small number of grammatical/typographical errors. These are not addressed
>in this review, since the RFC editor will do a better job at it than I
>could.
>
>I picked out a few suggestions for improvement in the sections that
>follow, but on the whole I think the document meets its objectives well
>and as an individual contributor I would not object to it proceeding
>without any further changes.
>
>Specific
>
>Section 1: Introduction
>
>Paragraph 2: the DNS specification (if we can suggest that one exists at
>all, with a straight face) is more than just 1034/1035. Suggest s/is
>specified/was originally specified in/.
>
>Paragraph 6: it seems reasonable to note that forwarders also don't see
>the identity of the client that originated the DNS request either, since
>the query they receive was originated from a downstream resolver rather
>than an end user. Arguably, different privacy concerns exist with
>knowledge of the identity of the stub resolver, the content of the query,
>and the combination of the two. You cover this in section 2.2, but I
>think foreshadowing that in the introduction is worth considering.
>
>Paragraph 7: DNSCurve provides another channel encryption mechanism. I
>appreciate that it's not specified in the IETF, but it exists and people
>use it.
>
>I wonder about the wisdom of appearing to give legal advice in this
>document. Unless we are able to cite a study by someone properly
>qualified in international and all national laws, this section seems
>awkward. It's fair to say that no DNS-specific laws are known to exist by
>non-lawyers in the combined experience of the author and the reviewers,
>but that level of qualification starts to look like we don't really have
>anything to say.
>
>(review ends)
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Apr 2015 10:49:23 +0200

On Wed, Apr 15, 2015 at 05:09:07PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 100 lines which said:

> resolve them along with any other Last Call comments that have been
> received. 

OK, waiting for the Last Call to start.

> There are various DNS-specific acronyms which are not expanded at
> first use and whose capitalisation occasionally varies from that
> seen in other documents that have a DNS focus (e.g. qname
> vs. QNAME).

This specific one is fixed in the reference repository
<https://github.com/bortzmeyer/my-IETF-work/commits/master/draft-ietf-dprive-problem-statement> 
but not yet in a published draft.

> Section 1: Introduction
> 
> Paragraph 2: the DNS specification (if we can suggest that one
> exists at all, with a straight face) is more than just
> 1034/1035. Suggest s/is specified/was originally specified in/.

OK. TODO: read the other RFCs on DNS to see which text they use. For
instance, RFC 4033 does exactly like the DPRIVE draft...

> Paragraph 6: it seems reasonable to note that forwarders also don't
> see the identity of the client that originated the DNS request
> either, since the query they receive was originated from a
> downstream resolver rather than an end user. Arguably, different
> privacy concerns exist with knowledge of the identity of the stub
> resolver, the content of the query, and the combination of the
> two. You cover this in section 2.2, but I think foreshadowing that
> in the introduction is worth considering.

OK

> Paragraph 7: DNSCurve provides another channel encryption
> mechanism. I appreciate that it's not specified in the IETF, but it
> exists and people use it.

DNScrypt is used and could be mentioned. Nobody uses DNScurve.

> Paragraph 8: "almost all" seems like it would benefit from a
> citation (that should not be hard to find).

TODO: read Hedgehog Web site :-)

> document. 

Complicated issue. Postponed as issue #12
<https://github.com/bortzmeyer/my-IETF-work/issues/12>

Thanks for the review.