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.

The summary of the review is: Ready with nits

Major Concerns: None

Minor Concerns: 1
6.  Security Considerations
	Although the method described in the '3.3.3. FCFS Name And Signature Validation'
	section seems a good improvement over mDNS security, I second what Anthony
	Somerset highlighted in the dnsdir review; that some text would be welcome about
	a domain/service potentially denying naming to other domains/services by "squatting".

Nits:

Section 3.1.1 Full-featured Hosts
   Since a default registration domain is a requirement for the Service Registration 
   protocol to be discoverable on the local network using the mechanism in the draft,
   perhaps normative language is needed, i.e
   Full-featured hosts MUST be either configured manually with a
   registration domain, or capable of discovering the default registration domain as
   described in Section 11 of [RFC6763].
3.1.2.  Constrained Hosts
   "It is the responsibility of a Constrained-Node Network supporting SRP to
   provide one or more SRP registrar addresses.  It is the
   responsibility of the SRP registrar supporting a Constrained-Node
   Network to handle the updates appropriately."
   Similar to the observation for the previous section, stronger language is
   recommended here for setting clearer expectations of Constrained Hosts and the SRP
   registrar supporting them.
   s/updates may be accepted/updates MAY be accepted/
   s/may be rewritten/MAY be rewritten/
3.2.1.  What to publish
   Text seems to be missing in
   "For any Service Instance Name ([RFC6763], Section 4.1), an SRV RR,
   one or more TXT RRs, and a KEY RR."
   s/In principle Service/In principle, Service/
   Similar to the wording in 3.3.2.  Valid SRP Update Requirements, I would suggest 
   s/There is never more than one hostname in a single SRP update./Each SRP update MUST contain one single hostname./
3.2.4.  How to secure it
   s/what we describe here/the FCFS Naming method we propose/
   Text seems to be missing in "The goal
   is not to provide the level of security of a network managed by a
   skilled operator."
3.3.2.  Valid SRP Update Requirements
   The sentence "An SRP registrar MAY either
   process such messages are either processed as regular RFC2136
   updates" seems unclear.
6.  Security Considerations
   s/credentials to to update/credentials to update/

Other than these, I found the document easy to read and to follow, with good use of
highlights of related protocols and RFCs.
Thank you for your work on this draft.