[dnssd] Tsvart last call review of draft-ietf-dnssd-prireq-04

Tommy Pauly via Datatracker <noreply@ietf.org> Thu, 06 February 2020 18:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85353120809; Thu, 6 Feb 2020 10:36:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tommy Pauly via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-dnssd-prireq.all@ietf.org, last-call@ietf.org, dnssd@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Tommy Pauly <tpauly@apple.com>
Message-ID: <158101418447.5086.13358929809191152425@ietfa.amsl.com>
Date: Thu, 06 Feb 2020 10:36:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/APzZH2PZChO38M1xcgifGmSXUTw>
Subject: [dnssd] Tsvart last call review of draft-ietf-dnssd-prireq-04
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 18:36:25 -0000

Reviewer: Tommy Pauly
Review result: Ready with Nits

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