Re: [Tsv-art] [dnssd] Tsvart last call review of draft-ietf-dnssd-prireq-04

[Christian Huitema <[e-mail]>]

Thanks for the review, Tommy. We will fix the nits in the next revision.

-- Christian Huitema

On 2/6/2020 10:36 AM, Tommy Pauly via Datatracker wrote:
> 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
> [e-mail] 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).
>