I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Please note that I previously reviewed version 20 of this draft and at that
time stated that the document was "Ready with Nits/Has Nits"

I am therefore only reviewing the differences between version 20 and current
version (23)

The summary of the review is: Ready with nits

Major Concerns: None

Minor Concerns: None
The minor concern highlighted in the previous review has been addressed with the text added to 6.3.  Risks of allowing arbitrary names to be registered in SRP updates

Nits:

1.  Introduction
The mention of authentication in mDNS might be confusing, perhaps something along the lines
"In this regard, our goal with this specification is
   to impose similar constraints to mDNS [RFC6762], which allows arbitrary hosts on a single IP link
   to advertise services [RFC6763] and relies on whatever service is
   advertised to provide authentication. This pratice in mDNS is considered reasonably safe because it requires physical
   presence on the network in order to advertise, with an off-network mDNS
   attack simply being not possible.
   Because of this you will see..."
   
Alternatively, shorter text in the introduction section might make the text more concise, with these new paragraphs explaining the reasoning either in Section 3.3.3 FCFS Name And Signature Validation or a subsection of its own.
The shorter text could be along the lines
"Section x explains the reasoning for a limited/constrained authentication scope in this protocol"

6.  Security Considerations
Even though specifying key management policies is out of scope, perhaps it could be worthwhile to add a short mention that "If a key that is used for SRP is also used for
   other purposes" it could represent a vulnerability.
   
Other than these remarks, I continue to find the document easy to read and to follow, with good use of
highlights of related protocols and RFCs.

Thank you for your work.