Reviewer: Anthony Somerset Review result: Ready 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
