Last Call Review of draft-ietf-dnssd-srp-20
review-ietf-dnssd-srp-20-dnsdir-lc-somerset-2023-05-30-00

Hello

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

There are are clear and direct references to various DNS RFC's and this
draft is not in any conflict with the wider DNS space.

All in all I think this is a very well written document, although quite 
lengthy and makes lots of references to the appropriate RFC's it is well
understandable and didn't take me too long to get to grips with the context.

I have a few editorial comments and queries - consider them as not quite nits 
and feel free to ignore at your leisure. :-) Therefore I otherwise consider
this document as "Ready"

In the Intro, there is this sentence:

There is already a large installed base of DNS-SD
   clients that can discover services using the DNS protocol (e.g.
   Android, Windows, Linux, Apple).
   
I would suggest being consistent with the naming, Apple should probably be 
referred to as MacOS, iOS (and likely the derivatives like iPadOS etc) or 
perhaps:
   e.g. Android, Windows, Linux, and Apple based Operating Systems
   
Also in the Introduction section:
SRP also adds a feature called First-Come, First-Served (FCFS)
   Naming, which allows the requestor to claim a name that is not yet in
   use, and, using SIG(0) [RFC2931],
   
Should there be some commentary about preventing a domain/service squatting
type denial of service in the security considerations? or am I just being
overly cynical here?

Section 4 
TTLs sent in SRP Updates are advisory: they indicate the SRP
   requestor's guess as to what a good TTL would be.  SRP registrars may
   override these TTLs.  SRP registrars SHOULD ensure that TTLs are
   reasonable: neither too long nor too short.  The TTL should never be
   longer than the lease time (Section 5.1).
   
I would suggest a RECOMMENDED TTL or upper and lower bound - otherwise this is
vague. I like how you handled a similar suggestion around leases in section 5.1
which could be applied here, the rest of the section makes a good explanation
to the various tradeoffs which helps bring context.

Section 6.1 mentions UDP - but earlier says only TCP in 3.1.3, also 10.4 
and 10.5 only reference TCP service entries

There is no matching reference to UDP in 3.1.2 as the reference in 6.1 is to 
constrained networks. Maybe a reference to state that UDP is possible in
constrained networks?

Also does the smallest possible SRP update fit inside a UDP datagram in the
first place, especially given the use of public keys in updates?

Otherwise Thanks for a high quality document

Best Regards

Anthony Somerset