[dns-privacy] Barry Leiba's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-dprive-bcp-op-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben’s DISCUSS.

Other comments:

Throughout, “privacy-related” needs the hyphen, as it’s a compound modifier.

— Section 1 —

   For example the user has a clear expectation of which
   resolvers have visibility of their query data however this resolver/
   transport selection may provide an added mechanism to track them as
   they move across network environments.

This sentence needs some punctuation: certainty, a comma after “for example”,
and probably one before “however”.  Even with those, it’s an awkward sentence
and you might consider rephrasing it.

   It is an untested area that simply using a DNS
   resolution service constitutes consent from the user for the operator
   to process their query data.

NEW
   Whether simply using a DNS resolution service constitutes consent
   from the user for the operator to process their query data is as yet
   untested.
END

   o  To introduce the DNS Recursive Operator Privacy (DROP) statement
      and present a framework to assist writers of this document.

When I read this, I thought you meant *this* document, and that didn’t make
sense.  You mean “that document”, or, better, “writers of a DROP statement.”

      DROP statement is a document that an operator can publish
      outlining their operational practices and commitments with regard
      to privacy thereby providing a means for clients to evaluate the
      privacy properties of a given DNS privacy service.

This needs at least a comma before “thereby”.  I might also change to “publish,
which outlines ... privacy, and thereby provides a means”.

(At this point I’m going to stop calling out all but the most hard-to-follow
editorial issues.)

— Section 2 —

   Whilst the issues raised here are targeted at those operators who
   choose to offer a DNS privacy service, considerations for areas 2 and
   3 could equally apply to operators who only offer DNS over
   unencrypted transports but who would like to align with privacy best
   practice.

If we’re considering encryption to be part of the best practice, this seems
odd.  Maybe say “but who would otherwise like to align...”?

— Section 5.1.1 —

   o  DNS-over-TLS [RFC7858] and [RFC8310].
   o  DoH [RFC8484].

There’s no reason to hyphenate the former, and the latter should also be
expanded here:

NEW
   o  DNS over TLS [RFC7858] and [RFC8310].
   o  DNS over HTTPS [RFC8484].
END

Similarly, take the hyphens out of “DNS over DTLS” in the next paragraph, and
out of “DNS over TLS” throughout the document.

— Section 5.1.3.2 —
It’s “forgo” (give up), not “forego” (go before).

— Section 8 —
For a document such as this, the Security Considerations sectiin seems very
meagre.  As the Sec ADs have not called this out, I’ll presume they think it’s
OK, and I won’t press the issue.  Perhaps all relevant information is already
elsewhere in the document.