DNS Push Notifications
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: email@example.com, The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Tim Wicinski <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Protocol Action: 'DNS Push Notifications' to Proposed Standard (draft-ietf-dnssd-push-25.txt) The IESG has approved the following document: - 'DNS Push Notifications' (draft-ietf-dnssd-push-25.txt) as Proposed Standard This document is the product of the Extensions for Scalable DNS Service Discovery Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/
Technical Summary The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. Working Group Summary The significant thing was the initial version of the draft had both protocols and process. The decision was made after discussion with DNSOP, to split this work into a separate draft and the protocol work into draft-ietf-dnsop-session-signal, which is now RFC8490. Document Quality The documents is of good quality. There currently is some non-published implementations. The reviews on this document were vigorous and thorough. Personnel Document Shepherd is Tim Wicinski. Area Director is Éric Vyncke. IANA Note New entries to be added in two existing registries.
RFC Editor Note This document is part of C367 (where draft-sekar-dns-llq will be added as soon as the IESG agrees that there is no conflict) and the ideal RFC ordering should be: 1) RFC n is draft-sekar-dns-llq Independent Stream (Informational) 2) RFC n+1 is draft-ietf-dnssd-push (successor to LLQ) this document 3) RFC n+2 is draft-ietf-dnssd-hybrid (depends on draft-ietf-dnssd-push) already in C367 for months