[Tsv-art] Tsvart last call review of draft-ietf-dnssd-prireq-04
Tommy Pauly via Datatracker <firstname.lastname@example.org> Thu, 06 February 2020 18:36 UTC
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)
Content-Type: text/plain; charset="utf-8"
From: Tommy Pauly via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Tommy Pauly <email@example.com>
Date: Thu, 06 Feb 2020 10:36:24 -0800
Subject: [Tsv-art] Tsvart last call review of draft-ietf-dnssd-prireq-04
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:email@example.com?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 firstname.lastname@example.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).
- [Tsv-art] Tsvart last call review of draft-ietf-d… Tommy Pauly via Datatracker
- Re: [Tsv-art] [dnssd] Tsvart last call review of … Christian Huitema