Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-03-17
25 Paul Wouters
[Ballot comment]
Thanks for dropping by at the SEC AD office hours. Note there is is confusion still because I understood you said SRP is …
[Ballot comment]
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.
2024-03-17
25 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss
2024-03-04
25 Ted Lemon New version available: draft-ietf-dnssd-srp-25.txt
2024-03-04
25 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2024-03-04
25 Ted Lemon Uploaded new revision
2024-01-29
24 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-01-29
24 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-29
24 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-01-29
24 Ted Lemon New version available: draft-ietf-dnssd-srp-24.txt
2024-01-29
24 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2024-01-29
24 Ted Lemon Uploaded new revision
2023-08-21
23 Roman Danyliw
[Ballot comment]
Thank you to Joey Salazar for the SECDIR review.

Authors: Thank you for editorial style that provided introductory prose on the protocol design …
[Ballot comment]
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.
2023-08-21
23 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2023-08-10
23 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2023-08-10
23 Jean Mahoney Assignment of request for Last Call review by GENART to Suhas Nandakumar was marked no-response
2023-08-10
23 (System) Changed action holders to Ted Lemon, Stuart Cheshire, Éric Vyncke (IESG state changed)
2023-08-10
23 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2023-08-10
23 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2023-08-10
23 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this specification. Thanks to Joerg Ott for the TSVART review, and  yes, please respond to his comments.

I have …
[Ballot comment]
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?
2023-08-10
23 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2023-08-10
23 Murray Kucherawy
[Ballot comment]
Thanks to Patrik Faltstrom for his ARTART review.

Thanks also for including what's in Section 11.

Nice work on use of BCP 14 …
[Ballot comment]
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.
2023-08-10
23 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2023-08-09
23 Paul Wouters
[Ballot discuss]
1) Other service record types

If we allow SRV records, then we should probably also support this
for the newer types of service …
[Ballot discuss]
1) Other service record types

If we allow SRV records, then we should probably also support this
for the newer types of service records, eg SVCB and HTTPS, as long
as the same constraints are there (eg only pointing to itself)

2) finding the domain name to use

In Section 3.2.2 on where to publish, hosts need to somehow know their
domain name. Especially for roaming devices, this seems unlikely and
the only choice to participate would be to assume the name given by
DHCP for the 'search domain'. I feel that by not stating this explicitly,
that is what is going to happen anyway. So why not state it? Or if this
is really unwanted, add such a statement to Section 3.2.2.

3) KEY rollovers?

How does a SRP requestor do a KEY rollover without running a race condition that
might lose its ownership of its name? Can it send a KEY update containing the
future KEY signed with the current KEY? Should it be double signed to prove ownership
of the future private key?

4) SUDN

Section 10.1 attempts to register a Special-Use domain without a template
as per RFC 6761 Section 5.  Domain Name Reservation Considerations.
(I'm aware of the irony of this wrt one of the authors of this document :-) ]

5) Basically Updates: 2782 without saying so

Section  3.2.5.4 Compression in SRV records basically updates RFC 2782 without
stating so via an Updates: clause. As we are talking about DNS library code reuse,
I think this would be unwise to update. I would drop the option of allowing the
compressing of SRV target names.

6) DNSSEC on resolvers

Section 8.4 point 1 is true for all recursive resolvers and I think it is harmful
to call it out here as if it is still acceptable to run resolvers without DNSSEC
enabled. I would remove the entire point 1.

7) Too generic a name for in .arpa

      the special-use domain name (see [RFC6761]) "default.service.arpa"

Why aren't underscores used here to ensure the space is not considered
a possible valid hostname? eg default._service.arpa or _default._service.arpa
I would also think "service" is far too generic. Possibly "_dns-sd" would be
better. "service.arpa" seems way to generic to be a reference for dns-sd only.

8) Possible replay security implications

A DNS Update for "default.service.arpa" seen in one network could be replayed as
a DNS Update in another network (even if one does not have the private key). I'm
a bit concerned this could have security implications, eg of impersonating a device.
2023-08-09
23 Paul Wouters
[Ballot comment]
Why are there two different ways of removing content? One using a DNS Update DELETE
command, and one using a DNS Update refresh …
[Ballot comment]
Why are there two different ways of removing content? One using a DNS Update DELETE
command, and one using a DNS Update refresh with lease time of 0 ?
Also, the notion of delete being a lease of 0 update should be specified in
draft-ietf-dnssd-update-lease and maybe not in this document, especially as that
draft currently states "SHOULD NOT" for lease values < 3600

Section 3.3.2:

        A DNS Update that contains any additional adds or deletes that
        cannot be identified as Service Discovery, Service Description
        or Host Description Instructions is not an SRP Update.

I think this means to say "So nothing from the entire DNS Update should be
processed in the context of dns-sd srp" ? I think that point should be made more explicit.

        An SRP registrar MAY either process such messages as regular
        RFC2136 updates, including access control checks and constraint
        checks, if supported, or MAY reject them with Refused RCODE.

I think processing as regular 2136 would fail, based on the fact that there
would be no proper TSIG authentication in place. Unless it was not a dnsdsd-srp
message at all, which again would be obvious for using TSIG and not SIG(0).

But also, I don't know how to parse the construct of "MAY x or MAY y". Does the "or"
imply I MUST do one of the MAYs? Or can both MAYs be skipped?

        If the server fails to renew its service registration before the
        KEY lease (Section 4 of [I-D.ietf-dnssd-update-lease]) expires,
        its name is no longer protected.

What does "no longer protected" mean? Does it mean the name remains active
but anyone can claim it? Or does it mean the name is removed. From a security
point of view, I think if KEY_LEASE < LEASE, LEASE should be reduced to KEY_LEASE.

ection 3.2.5.1 states:

        When the device changes ownership, it may be appropriate to erase the old key pair and install a new one.

I think it should remove the advise for "install a new one". The new owner couldn't trust
the old owner knows the key, and would have to re-refactory-default the unit to get rid of
the 'new' old key.

      The policy described here for managing keys assumes that the
        keys are only used for SRP. If a key that is used for SRP is also
        used for other purposes, the policy described here is likely to
        be insufficient.

I think this should be much stronger, eg a "MUST NOT be used for anything else
except SRP". Since the public key appears as KEY in DNS, it seems much too dangerous
to allow this key to be used for anything else.

      To prevent such spoofing, TCP is required for such networks.

It should say "source validated connections, such as TCP or UDP with COOKIES"
(same later on in section 6.1) and normatively reference RFC 7873. Constrained
devices could also use UDP with COOKIES.

Section 6.3 could also advise adding "www", "mail" etc to the zone so that no
SRP requesters can request it.

Section 6.6 states:

        SRP registrars SHOULD implement the algorithms specified in
        [RFC8624], Section 3.1, in the validation column of the table,
        that are numbered 13 or higher and have a "MUST", "RECOMMENDED",
        or "MAY" designation in the validation column of the table.

There is a 8624bis that puts this properly into a registry, so hopefully this
document could state something about RFC8624 and its successors instead of
manually hacking column recommendations into the draft?

        In other network environments, updates for names ending in
        "default.service.arpa" may be rewritten by the registrar to
        names with broader visibility.

Can we avoid the use of "registrar" to avoid confusion with Registrar,
which in DNS speak usually refers to a domain registrar? How about using
"network authority" ? Or consistently use "SRP registrar". (see also the
use of "registrar" in section 3.3.6, 5.1, 6.1, 7)

        In this case, the requestor MUST either abandon the service
        registration attempt, or else choose a new name.

The word "attempt" should be removed here. It is the registration that is
aborted entirely, not just this attempt (or else try a new registration with
a different name)

        If the key lease time

Should be: if the KEY lease time
2023-08-09
23 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2023-08-08
23 Martin Duke [Ballot comment]
I see no on-list response to Joerg Ott's TSVART review. If there is not a private one, please respond.
2023-08-08
23 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2023-08-08
23 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-08-08
23 Erik Kline
[Ballot comment]

# 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 …
[Ballot comment]

# 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?
2023-08-08
23 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-08-08
23 Joey Salazar Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Joey Salazar. Sent review to list.
2023-08-06
23 Anthony Somerset Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset. Sent review to list. Submission of review completed at an earlier date.
2023-08-06
23 Anthony Somerset Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset.
2023-08-05
23 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-08-05
23 Jim Reid Request for Telechat review by DNSDIR is assigned to Anthony Somerset
2023-08-04
23 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-08-04
23 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-08-04
23 Ted Lemon New version available: draft-ietf-dnssd-srp-23.txt
2023-08-04
23 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-08-04
23 Ted Lemon Uploaded new revision
2023-08-04
22 Christian Amsüss Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Christian Amsüss. Sent review to list.
2023-08-04
22 Lars Eggert
[Ballot comment]
# 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 …
[Ballot comment]
# 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
2023-08-04
22 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2023-08-03
22 Jean-Michel Combes Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Jean-Michel Combes. Sent review to list.
2023-07-16
22 Ines Robles Assignment of request for Telechat review by IOTDIR to Erik Nordmark was rejected
2023-07-15
22 Ines Robles Request for Telechat review by IOTDIR is assigned to Erik Nordmark
2023-07-15
22 Ines Robles Assignment of request for Telechat review by IOTDIR to Christian Amsüss was rejected
2023-07-13
22 Tero Kivinen Request for Telechat review by SECDIR is assigned to Joey Salazar
2023-07-12
22 Roman Danyliw
[Ballot discuss]
** Documenting the risk of malicious, internal clients

-- Section 1.

  This is considered reasonably safe because it requires physical
  presence …
[Ballot discuss]
** Documenting the risk of malicious, internal clients

-- Section 1.

  This is considered reasonably safe because it requires physical
  presence on the network in order to advertise.

-- Section 6.1.
  SRP Updates have no authorization semantics other than FCFS.  This
  means that if an attacker from outside of the administrative domain
  of the registrar knows the registrar's IP address, it can in
  principle send updates to the registrar that will be processed
  successfully.

The Security Considerations and introductory framing go to great lengths to helpfully describe the risk of malicious registrations from outside of the administrative domain.  However, I am unable to find any discussion of the risks malicious clients inside the administrative domain pose.  Is this a perimeter-based security model (trust everything once insider the network)?  After initial compromise, a compromised system could register information that would support the steering of traffic to servers controlled by this attacker.

I scanned how RFC6763, RFC3007, RFC2136 and RFC2137 handle it.  As an aside, note that none of their Security Considerations are said to be applicable.  Section 5 of RFC2137 reminds us that dynamically configured domains are inherently less secure. Section 8.1 of RFC2136 comes closest with a mitigation of using IPsec, but it isn’t clear that is desired here.
2023-07-12
22 Roman Danyliw
[Ballot comment]
Thank you to Joey Salazar for the SECDIR review.

Authors: Thank you for editorial style that provided introductory prose on the protocol design …
[Ballot comment]
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.

** 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”? 

** Section 3.1.2.  Editorial
  ... the (proposed) special-
  use domain name (see [RFC6761]) "default.service.arpa" is used.

Remove “(proposed)” as this will be approved by the time the document is an RFC.

** Section 3.1.2 
  In
  other network environments, updates for names ending in
  "default.service.arpa" may be rewritten internally to names with
  broader visibility.

How would a constrained client know which names in default.services.arpa to rewrite and which ones it should not?

** Section 3.1
Networks that are not constrained networks can have more complicated
  topologies at the IP layer. 
...

  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.

-- Is a registrar supposed to reject UDP based traffic when it thinks it is operating in a non-constrained environment?

-- Is it possible to for unconstrained and constrained nodes to use the same registrar?  If so, how would the registrar know the node type per each request (so it could reject UDP)?

** Section 3.2.4.1
  a server that registers its service using DNS-SD Registration
  protocol is given ownership of a name for an extended period of time
  based on the key used to authenticate the DNS Update.

Is it the key, or the lease lifetime requested when “registering” the key?

** Section 3.2.5.1
  if there is no
  writable stable storage on the SRP requestor, the SRP requestor MUST
  be pre-configured with a public/private key pair in read-only storage
  that can be used.  This key pair MUST be unique to the device.  A
  device with rewritable storage should retain this key indefinitely.
  When the device changes ownership, it may be appropriate to erase the
  old key pair and install a new one.

Thanks for discussing the issues around key management.

-- In the case of compromised device with read-write storage, it seems like the key MUST be regenerated.

-- What is the proposed behavior for a compromised device with read-only storage?

-- In what cases would it NOT be appropriate to erase the key when the device changes ownership?

** Section 3.2.5.*  It appears field experience of some kind if being cited (with the use of “typically”).  Can it be cited?  Is this typical behavior recommended?

-- Section 3.2.5.2: “There is no specific requirement for how this is done; typically, however, the requestor will append a number to the  referred name.“

-- Section 3.2.5.3: “The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records [RFC6763] uses the LEASE field of the Update Lease option, and is typically set to two hours.”

Is this 2 hour lease time a recommended or default value?

-- Section 3.2.5.3: “The lifetime of the KEY records is set using the KEY-LEASE field of the Update Lease Option, and should be set to a much longer time, typically 14 days.”

Is 14 days a recommended value?

Section 5.1 later says “A default limit of two hours for the Lease and 14 days for the SIG(0) KEY are currently thought to be good choices.”

** Section 6.1
  Registrars should therefore be configured to reject
  updates from source addresses outside of the administrative domain of
  the registrar.

What are the circumstances under which registrars would not reject updates outside of the administrative domain?  Why isn’t s/should therefore be configured/MUST be configured/

** Section 6.1
  This would ordinarily be accomplished by measures such as
  are described in Section 4.5 of [RFC7084]

Is there IPv4 guidance?  This reference only discusses IPv6 routers.

** Section 8.2
  It is not possible
  to register a PKI certificate for a subdomain of 'service.arpa.'
  because it is a locally-served domain name.

Is this saying that one couldn’t get a PKI certificate from a public CA (as in, for the Web PKI/CAB Forum-compliant CA)?  Couldn’t an administrative domain running its own CA to issue certificates with these names, especially since this shouldn’t be an internet exposed service.
2023-07-12
22 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2023-07-12
22 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Jean-Michel Combes
2023-07-12
22 Éric Vyncke Requested Telechat review by INTDIR
2023-07-12
22 Ines Robles Request for Telechat review by IOTDIR is assigned to Christian Amsüss
2023-07-12
22 Ines Robles Assignment of request for Telechat review by IOTDIR to Emmanuel Baccelli was rejected
2023-07-12
22 Ines Robles Request for Telechat review by IOTDIR is assigned to Emmanuel Baccelli
2023-07-11
22 Éric Vyncke Requested Telechat review by IOTDIR
2023-07-11
22 Éric Vyncke Requested Telechat review by IOTDIR
2023-07-11
22 Éric Vyncke Telechat date has been changed to 2023-08-10 from 2023-07-13
2023-07-11
22 Anthony Somerset Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset. Sent review to list.
2023-07-10
22 Jim Reid Request for Telechat review by DNSDIR is assigned to Anthony Somerset
2023-07-10
22 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2023-07-10
22 Éric Vyncke Placed on agenda for telechat - 2023-07-13
2023-07-10
22 Éric Vyncke Ballot writeup was changed
2023-07-10
22 Éric Vyncke Ballot has been issued
2023-07-10
22 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2023-07-10
22 Éric Vyncke Created "Approve" ballot
2023-07-10
22 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2023-07-10
22 Éric Vyncke Ballot writeup was changed
2023-07-10
22 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-07-10
22 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-07-10
22 Ted Lemon New version available: draft-ietf-dnssd-srp-22.txt
2023-07-10
22 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-07-10
22 Ted Lemon Uploaded new revision
2023-07-10
21 Éric Vyncke Ballot writeup was changed
2023-07-10
21 Éric Vyncke This I-D does not pass the 'idnits' check: there are two missing references in the new text.
2023-07-10
21 (System) Changed action holders to Ted Lemon, Stuart Cheshire, Éric Vyncke (IESG state changed)
2023-07-10
21 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup
2023-07-07
21 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-07-07
21 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-07-07
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2023-07-07
21 Ted Lemon New version available: draft-ietf-dnssd-srp-21.txt
2023-07-07
21 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-07-07
21 Ted Lemon Uploaded new revision
2023-06-19
20 Éric Vyncke To address IANA comments.
2023-06-19
20 (System) Changed action holders to Éric Vyncke, Ted Lemon, Stuart Cheshire (IESG state changed)
2023-06-19
20 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2023-06-13
20 Joerg Ott Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Joerg Ott. Sent review to list.
2023-06-13
20 Dhruv Dhody Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Dhruv Dhody. Sent review to list.
2023-06-13
20 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-06-12
20 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2023-06-12
20 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnssd-srp-20. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnssd-srp-20. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the third action requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, the current draft requests that service.arpa be added to the Special-Use Domain Names Registry located at:

https://www.iana.org/assignments/special-use-domain-names/

The Special-Use Domain Name registry is governed by rules in RFC6761. Specifically, Section 5 of RFC6761 requires seven sections in the IANA Considerations section of the draft. The authors have provided two of those sections outside the IANA Considerations section and refer the reader to RFC8375 for the remaining sections. However, RFC8375 is specific to home.arpa and not service.arpa. IANA would prefer that these sections appear in the IANA Considerations section of the draft and that text for the remaining RFC6761 requirements be incorporated into the current draft (with references to service.arpa rather than home.arpa) so that the draft can work as a standalone document.

Second, in the Transport-Independent Locally-Served DNS Zone Registry on the Locally-Served DNS Zones registry page located at:

https://www.iana.org/assignments/locally-served-dns-zones/

a single new registration is to be made as follows:

Zone: service.arpa.
Description: DNS-SD Service Registration Protocol Special-Use Domain
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the service.arpa Subdomain Registry.

IANA Question --> NOTE: Wherever possible, IANA prefers that the word "Registry" be omitted from registry names, unless doing so will cause confusion. Is "service.arpa Subdomains" an acceptable registry name?

The new registry will be managed via Standards Action or IESG Approval as defined in RFC8126. The new registry is to be located on the Locally-Served DNS Zones registry page located at:

https://www.iana.org/assignments/locally-served-dns-zones/

There is a single initial registration in the new registry as follows:

Subdomain Name Description Reference
----------------------+--------------------------------+-------------
default.service.arpa. Default domain for SRP updates [ RFC-to-be ]

Fourth, in the the Service and Port Numbers registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

two new registrations will be made as follows:

Service Name: dnssd-srp
Transport Protocol: TCP
Description: DNS-SD Service Registration
Assignee: IESG
Contact: IETF Chair 
Reference: [ RFC-to-be ]

Service Name: dnssd-srp-tls
Transport Protocol: TCP
Description: DNS-SD Service Registration (TLS)
Assignee: IESG
Contact: IETF Chair 
Reference: [ RFC-to-be ]

Fifth, IANA will allocate an address from the IANA IPv6 Special-Purpose Address Registry located at:

https://www.iana.org/assignments/iana-ipv6-special-registry/

The address allocated based on this request will be similar to the Port Control Protocol anycast address, 2001:1::1. The allocation will be as follows:

Address Block: 2001:1::TBD/128
Name: DNS-SD Service Registration Protocol Anycast Address
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-Registration ]
Termination Date: N/A
Source: True
Destination: True
Forwardable: True
Global: True
Reserved-by-protocol: False

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2023-06-12
20 Joey Salazar Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Joey Salazar. Sent review to list.
2023-06-11
20 Patrik Fältström Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Patrik Fältström. Sent review to list.
2023-06-02
20 Magnus Westerlund Request for Last Call review by TSVART is assigned to Joerg Ott
2023-06-02
20 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dhruv Dhody
2023-06-01
20 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2023-06-01
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Joey Salazar
2023-05-30
20 Anthony Somerset Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset. Sent review to list. Submission of review completed at an earlier date.
2023-05-30
20 Anthony Somerset Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Anthony Somerset.
2023-05-30
20 Barry Leiba Request for Last Call review by ARTART is assigned to Patrik Fältström
2023-05-30
20 Jim Reid Request for Last Call review by DNSDIR is assigned to Anthony Somerset
2023-05-30
20 Amy Vezza IANA Review state changed to IANA - Review Needed
2023-05-30
20 Amy Vezza
The following Last Call announcement was sent out (ends 2023-06-13):

From: The IESG
To: IETF-Announce
CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-srp@ietf.org, dschinazi.ietf@gmail.com, evyncke@cisco.com …
The following Last Call announcement was sent out (ends 2023-06-13):

From: The IESG
To: IETF-Announce
CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-srp@ietf.org, dschinazi.ietf@gmail.com, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service Registration Protocol for DNS-Based Service Discovery) to Proposed Standard


The IESG has received a request from the Extensions for Scalable DNS Service
Discovery WG (dnssd) to consider the following document: - 'Service
Registration Protocol for DNS-Based Service Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-06-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Another IETF draft, draft-ietf-dnssd-update-lease, is closely related to this document. Reviewers are advised to read and review the two documents at the same time.

Abstract


  The Service Registration Protocol for DNS-Based Service Discovery
  uses the standard DNS Update mechanism to enable DNS-Based Service
  Discovery using only unicast packets.  This makes it possible to
  deploy DNS Service Discovery without multicast, which greatly
  improves scalability and improves performance on networks where
  multicast service is not an optimal choice, particularly IEEE 802.11
  (Wi-Fi) and IEEE 802.15.4 (IoT) networks.  DNS-SD Service
  registration uses public keys and SIG(0) to allow services to defend
  their registrations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/



No IPR declarations have been submitted directly on this I-D.




2023-05-30
20 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2023-05-30
20 Amy Vezza Last call announcement was changed
2023-05-29
20 Éric Vyncke Last call was requested
2023-05-29
20 Éric Vyncke Ballot approval text was generated
2023-05-29
20 Éric Vyncke Ballot writeup was generated
2023-05-29
20 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-05-29
20 Éric Vyncke Last call announcement was changed
2023-05-29
20 Éric Vyncke Last call announcement was generated
2023-05-29
20 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-05-29
20 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-05-29
20 Ted Lemon New version available: draft-ietf-dnssd-srp-20.txt
2023-05-29
20 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-05-29
20 Ted Lemon Uploaded new revision
2023-04-07
19 Éric Vyncke AD review comments at: https://mailarchive.ietf.org/arch/msg/dnssd/WziinuzSzGaUXbHTelwu0ly3NwA/
2023-04-07
19 (System) Changed action holders to Ted Lemon, Éric Vyncke, Stuart Cheshire (IESG state changed)
2023-04-07
19 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2023-04-03
19 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-04-03
19 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2023-03-27
19 David Schinazi
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Broad agreement. DNSSD has historically been a pretty small WG with a very small
number of vocal participants, but this draft is required for CHIP/Matter (another
SDO in the home space) and that brought in vocal participants and implementers.
The draft in its current shape represents the broad agreement of these folks.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We're aware of at least two implementations already in production or going into
production soon, with more to come after publication.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

We have gotten reviews from multiple individuals involved with Matter. They
support publication of the draft.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

* needed - yes, there is demand for this coming from Matter and the IoT space
* clearly written - yes
* complete - yes
* correctly designed - yes (as far as this shepherd can tell)
* ready for AD - yes

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The shepherd has gone through the list and did not find any relevant issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, this makes sense for a protocol definition with multiple
implementations. Datatracker is up to date.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, both authors have explicitly confirmed no awareness of IPR on this draft
https://mailarchive.ietf.org/arch/msg/dnssd/95pR6si77GlgQJE7oplEjRDDZ-s/
https://mailarchive.ietf.org/arch/msg/dnssd/wxv0fy925st5FlKHaJM_z_nh91I/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2023-03-27
19 David Schinazi Responsible AD changed to Éric Vyncke
2023-03-27
19 David Schinazi IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2023-03-27
19 David Schinazi IESG state changed to Publication Requested from I-D Exists
2023-03-27
19 David Schinazi Document is now in IESG state Publication Requested
2023-03-26
19 Ted Lemon New version available: draft-ietf-dnssd-srp-19.txt
2023-03-26
19 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-03-26
19 Ted Lemon Uploaded new revision
2023-03-14
18 David Schinazi Tag Revised I-D Needed - Issue raised by WG cleared.
2023-03-14
18 David Schinazi IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2023-01-09
18 Ted Lemon New version available: draft-ietf-dnssd-srp-18.txt
2023-01-09
18 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2023-01-09
18 Ted Lemon Uploaded new revision
2022-10-13
17 David Schinazi
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Broad agreement. DNSSD has historically been a pretty small WG with a very small
number of vocal participants, but this draft is required for CHIP/Matter (another
SDO in the home space) and that brought in vocal participants and implementers.
The draft in its current shape represents the broad agreement of these folks.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We're aware of at least two implementations already in production or going into
production soon, with more to come after publication.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

We have gotten reviews from multiple individuals involved with Matter. They
support publication of the draft.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

* needed - yes, there is demand for this coming from Matter and the IoT space
* clearly written - yes
* complete - yes
* correctly designed - yes (as far as this shepherd can tell)
* ready for AD - yes

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The shepherd has gone through the list and did not find any relevant issues.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, this makes sense for a protocol definition with multiple
implementations. Datatracker is up to date.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, both authors have explicitly confirmed no awareness of IPR on this draft
https://mailarchive.ietf.org/arch/msg/dnssd/95pR6si77GlgQJE7oplEjRDDZ-s/
https://mailarchive.ietf.org/arch/msg/dnssd/wxv0fy925st5FlKHaJM_z_nh91I/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2022-10-12
17 Ted Lemon New version available: draft-ietf-dnssd-srp-17.txt
2022-10-12
17 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2022-10-12
17 Ted Lemon Uploaded new revision
2022-10-10
16 David Schinazi Notification list changed to dschinazi.ietf@gmail.com because the document shepherd was set
2022-10-10
16 David Schinazi Document shepherd changed to David Schinazi
2022-10-07
16 Ted Lemon New version available: draft-ietf-dnssd-srp-16.txt
2022-10-07
16 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2022-10-07
16 Ted Lemon Uploaded new revision
2022-09-14
15 Ted Lemon New version available: draft-ietf-dnssd-srp-15.txt
2022-09-14
15 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2022-09-14
15 Ted Lemon Uploaded new revision
2022-07-11
14 Ted Lemon New version available: draft-ietf-dnssd-srp-14.txt
2022-07-11
14 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2022-07-11
14 Ted Lemon Uploaded new revision
2022-04-24
13 Ted Lemon New version available: draft-ietf-dnssd-srp-13.txt
2022-04-24
13 Ted Lemon New version accepted (logged-in submitter: Ted Lemon)
2022-04-24
13 Ted Lemon Uploaded new revision
2021-10-24
12 Ted Lemon New version available: draft-ietf-dnssd-srp-12.txt
2021-10-24
12 (System) New version approved
2021-10-24
12 (System) Request for posting confirmation emailed to previous authors: Stuart Cheshire , Ted Lemon
2021-10-24
12 Ted Lemon Uploaded new revision
2021-10-22
11 Ted Lemon New version available: draft-ietf-dnssd-srp-11.txt
2021-10-22
11 (System) New version accepted (logged-in submitter: Ted Lemon)
2021-10-22
11 Ted Lemon Uploaded new revision
2021-08-19
10 David Schinazi Tag Revised I-D Needed - Issue raised by WG set.
2021-08-19
10 David Schinazi IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2021-08-19
10 David Schinazi Changed consensus to Yes from Unknown
2021-08-19
10 David Schinazi Intended Status changed to Proposed Standard from None
2021-07-28
10 David Schinazi IETF WG state changed to In WG Last Call from WG Document
2021-07-12
10 Ted Lemon New version available: draft-ietf-dnssd-srp-10.txt
2021-07-12
10 (System) New version accepted (logged-in submitter: Ted Lemon)
2021-07-12
10 Ted Lemon Uploaded new revision
2021-03-12
09 Barbara Stark Added to session: IETF-110: dnssd  Fri-1300
2021-01-11
09 Ted Lemon New version available: draft-ietf-dnssd-srp-09.txt
2021-01-11
09 (System) New version accepted (logged-in submitter: Ted Lemon)
2021-01-11
09 Ted Lemon Uploaded new revision
2021-01-07
08 Ted Lemon New version available: draft-ietf-dnssd-srp-08.txt
2021-01-07
08 (System) New version accepted (logged-in submitter: Ted Lemon)
2021-01-07
08 Ted Lemon Uploaded new revision
2020-12-18
07 Ted Lemon New version available: draft-ietf-dnssd-srp-07.txt
2020-12-18
07 (System) New version accepted (logged-in submitter: Ted Lemon)
2020-12-18
07 Ted Lemon Uploaded new revision
2020-11-18
06 Ted Lemon New version available: draft-ietf-dnssd-srp-06.txt
2020-11-18
06 (System) New version accepted (logged-in submitter: Ted Lemon)
2020-11-18
06 Ted Lemon Uploaded new revision
2020-10-29
05 Ted Lemon New version available: draft-ietf-dnssd-srp-05.txt
2020-10-29
05 (System) New version accepted (logged-in submitter: Ted Lemon)
2020-10-29
05 Ted Lemon Uploaded new revision
2020-07-13
04 Ted Lemon New version available: draft-ietf-dnssd-srp-04.txt
2020-07-13
04 (System) New version approved
2020-07-13
04 (System) Request for posting confirmation emailed to previous authors: Ted Lemon , Stuart Cheshire
2020-07-13
04 Ted Lemon Uploaded new revision
2020-07-13
03 Ted Lemon New version available: draft-ietf-dnssd-srp-03.txt
2020-07-13
03 (System) New version approved
2020-07-13
03 (System) Request for posting confirmation emailed to previous authors: Ted Lemon , Stuart Cheshire
2020-07-13
03 Ted Lemon Uploaded new revision
2020-01-09
02 (System) Document has expired
2019-07-10
02 David Schinazi Added to session: IETF-105: dnssd  Thu-1330
2019-07-08
02 Ted Lemon New version available: draft-ietf-dnssd-srp-02.txt
2019-07-08
02 (System) New version approved
2019-07-08
02 (System) Request for posting confirmation emailed to previous authors: Stuart Cheshire , Ted Lemon
2019-07-08
02 Ted Lemon Uploaded new revision
2019-03-11
01 Ted Lemon New version available: draft-ietf-dnssd-srp-01.txt
2019-03-11
01 (System) New version approved
2019-03-11
01 (System) Request for posting confirmation emailed to previous authors: Stuart Cheshire , Ted Lemon
2019-03-11
01 Ted Lemon Uploaded new revision
2018-10-23
00 Barbara Stark This document now replaces draft-sctl-service-registration instead of None
2018-10-23
00 Ted Lemon New version available: draft-ietf-dnssd-srp-00.txt
2018-10-23
00 (System) WG -00 approved
2018-10-23
00 Ted Lemon Set submitter to "Ted Lemon ", replaces to draft-sctl-service-registration and sent approval email to group chairs: dnssd-chairs@ietf.org
2018-10-23
00 Ted Lemon Uploaded new revision