Skip to main content

Last Call Review of draft-ietf-dnssd-srp-20

Request Review of draft-ietf-dnssd-srp
Requested revision No specific revision (document currently at 25)
Type Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2023-06-13
Requested 2023-05-30
Authors Ted Lemon , Stuart Cheshire
I-D last updated 2023-05-30
Completed reviews Dnsdir Telechat review of -23 by Anthony Somerset (diff)
Dnsdir Last Call review of -20 by Anthony Somerset (diff)
Artart Last Call review of -20 by Patrik Fältström (diff)
Secdir Last Call review of -20 by Joey Salazar (diff)
Opsdir Last Call review of -20 by Dhruv Dhody (diff)
Tsvart Last Call review of -20 by Joerg Ott (diff)
Dnsdir Telechat review of -22 by Anthony Somerset (diff)
Iotdir Telechat review of -22 by Christian Amsüss (diff)
Intdir Telechat review of -22 by Jean-Michel Combes (diff)
Secdir Telechat review of -23 by Joey Salazar (diff)
Assignment Reviewer Anthony Somerset
State Completed
Request Last Call review on draft-ietf-dnssd-srp by DNS Directorate Assigned
Posted at
Reviewed revision 20 (document currently at 25)
Result Ready
Completed 2023-05-30

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

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 
   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