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 > tsv-art@xxxxxxxx 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). > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
