Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-25

# Internet AD comments for draft-ietf-dnssd-srp-23
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1.1

* "discover the server to which they should send SRP updates"

  What about servers, plural?  Can there reasonably be more than one
  registrar, and if so does a client just send updates to all of them
  (and, further, how does it handle a partial failure issuing an update)?

### S6.1

* When checking an update for its on-link property, consider whether
  recommending RFC 5082 "The Generalized TTL Security Mechanism (GTSM)"
  might be appropriate.

### S10.6

* How should DNS-over-TLS work in this scenario?  Should the certificate
  claim to be valid for this address, or for default.service.arpa.,
  or something?

Thanks to Patrik Faltstrom for his ARTART review.

Thanks also for including what's in Section 11.

Nice work on use of BCP 14.  I often end up griping about misuse of SHOULD and such, but there was none of that here for me.

Thanks for dropping by at the SEC AD office hours. Note there is is confusion still because I understood you said SRP is always TCP, but that does not seem to be the case if I read https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25#section-6.1

As a related argument is that SRP clients implement TCP, but might not implement DNS-COOKIES, and there is no advertisement/negotiation on whether COOKIES can be used, I think it is reasonable to not mention COOKIES as alternative for TCP in this case. I do hope a future rev of the spec might take cookies into consideration to avoid TCP.

Thank you to Joey Salazar for the SECDIR review.

Authors: Thank you for editorial style that provided introductory prose on the protocol design before discussing the protocol itself.

Thanks for the revised text and explanations to address my earlier DISCUSS and COMMENT feedback.

Per this earlier comment:

> ** Section 1.  
>   So we can only publish information that we feel safe in publishing
>   even though we do not have any basis for trusting the requestor.
>
> What is the basis of considering particular information “safe”?  

I was indeed reacting to the word "safe" as noted here: https://mailarchive.ietf.org/arch/msg/dnssd/tjfqY9HYNsFUqJCR0VfJhHBEvsY/.  The found the explanation in this thread illuminating and these would have been good words to include in the document.

Thanks for working on this specification. Thanks to Joerg Ott for the TSVART review, and  yes, please respond to his comments.

I have following observations/questions and hope to get some responses 

- This document left me we with the feel that TCP is the only preferred transport for the DNS updates when it comes to SRP, even though UDP seems like a very potential transport for constrained devices. is this the intention?

- Now that we have DoQ (DNS over QUIC), which have similar security/privacy properties as DoT and can be used for Zone transfer, and claims to be have same latency characteristic as DNS over UDP. I was wondering why QUIC a transport protocol was not considered in the specification. Is that a deliberate choice by the working group? 

- Specially this claim about TCP is required -

    This creates the possibility of off-network spoofing, where a device from a foreign network registers a service on the local network in order to attack devices on the local network. To prevent such spoofing, TCP is required for such networks.

  Will this not be fulfilled with QUIC as transport?

# GEN AD review of draft-ietf-dnssd-srp-22

CC @larseggert

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `master`; alternatives might be `active`, `central`, `initiator`,
   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` (matched
   `master` rule, pattern ((\bmaster\w*\b)\w*))
 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread` (matched
   `tradition` rule, pattern ((\btradition\w*\b)\w*))

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-dnssd-advertising-proxy-02`, but `-03` is the
latest available revision.

### Grammar/style

#### Section 3.2.5.3, paragraph 1
```
the SRP server will handle this. Therefore SRP registrars MUST support compr
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 3.2.5.3, paragraph 3
```
oving a host. However, in some cases a SRP requestor may not have retained s
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 3.3.1.1, paragraph 3
```
A and/or AAAA records that are not of of sufficient scope to be validly publ
                                   ^^^^^
```
Possible typo: you repeated a word.

#### Section 8.4, paragraph 2
```
cally-Served Zones" subregistry of the the "Locally-Served DNS Zones" registr
                                   ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 10.5, paragraph 1
```
mental edit, Tim Wattenberg for doing a SRP requestor proof-of-concept implem
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

I see no on-list response to Joerg Ott's TSVART review. If there is not a private one, please respond.