[dnssd] AD review of draft-ietf-dnssd-srp-19

["Eric Vyncke (evyncke)" <[e-mail]>]

Dear authors, shepherd, WG,

Thank you for the work done in this document. As usual, I have done my own AD review before proceeding to the IETF Last Call.

Here are some comments:

Generic:
- either use "DNSSD" or "DNS-SD" (the latter is preferred IMHO)
- check the grammatical use of commas around "and", "or", ... my grammar checker has found many of those potential errors
- RFC 2136 uses "delete" and not "remove", suggest using "delete" in this I-D as well
- the I-D often contains "DNS Update adds and removes" and I keep reading "adds" as the verb and not the action. Suggest using "additions and deletions" (longer but perhaps easier to read)
- "we" often appears in the text, please consider rewriting in a less personal way
- "RCODE" or "rcode" ?

Abstract
- please prefix IEEE for 802.11
- isn't " against attack" obvious ? I.e., remove those 2 words ;-)

Section 1
- please provide reference/explanation/data for "There is already a large installed base"
- should "The document is intended to provide" be more assertive in a standard track document ?
- please expand "DNS-Based Service Discovery (DNS‑SD)" at the first use of DNS-SD same applies for "Service Registration Protocol for DNS‑SD (SRP)"
- unsure whether the reference to DHCP lease is helpful especially since the client/server roles are swapped (note as well that there are 2 references for DHCP one for IPv4 and one for IPv6)
- the default lease time is "one hour" while in the update-lease it is "30 minutes", please use the same recommendation among those 2 I-D and in 3.2.5.3 it is "two hours"
- s/described in this document/specified in this document/
- please do not use "we" in "ll DNS‑SD client implementations of which we are aware support DNS‑SD"
- s/knowledgable/knowledgeable/

Section 3.1.1
- an example would be useful for the reader

Section 3.1.3
- should "the Internet layer" rather be "IP layer" or "network layer" ?
- "To prevent such spoofing, TCP is required for such networks." While I had in mind that all DNS updates are authenticated anyway ? I.e., UDP could be used securely. Also, what about DoT ? or DoQ ? Suggest to add a link to section 6.1

Section 3.2.1: 
- "The types of records that are updated" should "added" also be part of this sentence ?
- "an SRP requestor may be required to suppress some addresses", assuming that it is to removed link-local addresses 1/ then this may be stated here as well in addition to the reference to RFC 8766 2/ should the registrar do the same ?
- "first-come, first-serve" please use "FCFS" as the acronym has been defined earlier (comment applicable through the whole document)

Section 3.2.2:
- what is "specific unicast namespace" ?

Section 3.2.3.1
- this section is not so much about "DNS update" but more on the behavior of a SRP registrar vs. DNS server receiving a DNS update. Should the text reflect this ?

Section 3.2.5.1
- s/erase the old key/erase the old key pair/

Section 3.2.5.4
- in which case a requester may not follow the "SHOULD" ?

Section 5.1
- what are "Dual-use servers" ?

Section 10.6
- what is the role of the anycast address ? I find no reference to it in the document except in appendix A, which does not bring a lot of useful content IMHO


As usual, I will wait a reply and/or revised I-D addressing all the above before proceeding with the publication process.

Regards and thanks again for your hard work on this specification

-éric