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 |