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 Ops Directorate (opsdir)
Deadline 2023-06-13
Requested 2023-05-30
Authors Ted Lemon , Stuart Cheshire
I-D last updated 2023-06-13
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 Dhruv Dhody
State Completed
Request Last Call review on draft-ietf-dnssd-srp by Ops Directorate Assigned
Posted at
Reviewed revision 20 (document currently at 25)
Result Has nits
Completed 2023-06-13
# OPSDIR review of draft-ietf-dnssd-srp

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last-call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last-call comments.

The document is very clear and well-written. The motivation is described well.
A separate section dealing with Operational Considerations would be an
excellent addition that could explicitly deal with Backward compatibility,
Logging requirements, Default values settings, Monitoring requirements etc. See
RFC 5706 for inspiration. This is just a suggestion...

The document is ready. I have a few minor comments and nits -

## Minor

* I suggest the I-D explicitly state the default values which can be overridden
via configurations. The use of the word "typically" in section is a bit

* Section 8. My preference would be to disregard brevity and list all
considerations for "" instead of relying on "" in RFC8375.
In my reading, the text refers to homenet at places and seems incorrect to
blindly rely on it. Again just a suggestion and something to think about.

## Nits

* Expand IoT in Abstract. Also, put the abbreviation next to "DNS-Based Service
Discovery" as you use the abbreviation later on.

* Section 3.1.1.

    * Remove the "," at "..a registration domain, or discover the default.."

    * Remove the "," at "..mechanisms are possible, but are.."

    * s/out of scope for this document/out of the scope of this document/

    * Add a "," at "For these names they then discover" i.e. "For these names,
    they then discover"

* Section 3.2.4

    * Expand TSIG

    * I suggest rewording this "The goal is not to provide the level of
    security of a network managed by a skilled operator."!

* Add a suitable reference for "a YXDomain RCODE" (Section

* Weird capitalization in "..both the Delete An RR From An RRset update and the
Add To An RRSet update,.." (Section

* Section 3.3.1

    * s/RFC2136/[RFC2136]/g -- If you don't want to make this update, consider
    using a hyphen as in RFC2136-implementations etc.

    * Should you also state what happens when the MUST in this section are not

* s/are rejected with Refused./are rejected with Refused RCODE./ (section 3.3.6)

* Section 6.1

    * Add reference to TCP Fast Open

    * s/credentials to to update/credentials to update/

* Table 1, please remove the last "." in ""; See

* The IDNITS has some warnings. I guess that no change is needed, but just
making sure -


*In case of bad formatting, see this message at  -*