Last Call Review of draft-ietf-dnssd-prireq-04
review-ietf-dnssd-prireq-04-tsvart-lc-pauly-2020-02-06-00

Request Review of draft-ietf-dnssd-prireq
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2020-02-12
Requested 2020-01-29
Authors Christian Huitema, Daniel Kaiser
Draft last updated 2020-02-06
Completed reviews Iotdir Last Call review of -04 by Samita Chakrabarti (diff)
Intdir Last Call review of -04 by Bob Halley (diff)
Secdir Last Call review of -04 by Robert Sparks (diff)
Genart Last Call review of -04 by Robert Sparks (diff)
Tsvart Last Call review of -04 by Tommy Pauly (diff)
Opsdir Last Call review of -04 by Tianran Zhou (diff)
Assignment Reviewer Tommy Pauly 
State Completed
Review review-ietf-dnssd-prireq-04-tsvart-lc-pauly-2020-02-06
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/wx9hi_QjxjO_A7ohO6FHPyT68iU
Reviewed rev. 04 (document currently at 08)
Review result Ready with Nits
Review completed: 2020-02-06

Review
review-ietf-dnssd-prireq-04-tsvart-lc-pauly-2020-02-06

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thanks for the well-written document! As an informational overview of privacy attacks to be concerned about in service discovery (particularly DNS-SD over mDNS), this document doesn’t define any new protocol behavior, but provides useful guidance for future work.

From a transport perspective, the most relevant section is the operational considerations in sections 3.4.2 and 4.3, which notes that privacy-preserving mechanism that increase the amount of traffic can cause unnecessary load on the network. This can in turn lead to congestion and general performance degradation, within the multicast scope in which some discovery mechanism is being used. This consideration seems appropriate, and any future documents that go on to propose a privacy-preserving discovery mechanism should have similar considerations on the impact on network congestion, and avoiding amplification attacks.

I also think this is the first time I’ve seen a smartwatch on a stick figure drawn in ASCII art. Any interest in SVG drawings? =)

Nits:

Abstract
I’d suggest hyphenating “privacy-respecting” in this sentence:

We analyze the requirements of a privacy respecting
   discovery service.

Section 1
Perhaps write out Multicast DNS (mDNS) upon first introduction

In the third paragraph, the same phrase “DNS-SD over mDNS” is used with duplicate references as in the first paragraph. These references seem a bit redundant.

Section 3.1.3
Extra apostrophe in “David' is here.” In the thought bubble

Section 3.2.5
“A sometimes heard argument is that…” sounds a bit awkward. Perhaps “An argument is sometimes made that…”

Section 3.3.1
The questions, (“Can we trust the information we receive?”) changes the voice used in the document, and it may not be immediately clear who the “we” is. I would suggest rephrasing this to be specific about which parties need to question which information.

Section 3.3.2
The term ‘The “Discover” operation’ is used with quotes and capitalization, however the term has not been used prior in the document or formally introduced. I would suggest either adding a reference if this is a particular term, or else making the phrasing more generic, such as “The process of service discovery…”

Sections 4.1 and 4.2
The formatting of the numbered lists has some issues (duplicated numbers).