<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.26 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-generalized-notify-09" number="9859" updates="" obsoletes="" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 --> version="3" xml:lang="en" submissionType="IETF">

  <front>
    <title abbrev="Generalized Notifications">Generalized DNS Notifications</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-generalized-notify-09"/> name="RFC" value="9859"/>
    <author initials="J." surname="Stenstam" fullname="Johan Stenstam">
      <organization>The Swedish Internet Foundation</organization>
      <address>
        <email>johan.stenstam@internetstiftelsen.se</email>
      </address>
    </author>
    <author initials="P." surname="Thomassen" fullname="Peter Thomassen">
      <organization>deSEC, Secure Systems Engineering</organization>
      <address>
        <email>peter@desec.io</email>
      </address>
    </author>
    <author initials="J." surname="Levine" fullname="John Levine">
      <organization>Standcore LLC</organization>
      <address>
        <email>standards@standcore.com</email>
      </address>
    </author>
    <date/>
    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <date month="September" year="2025"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

    <abstract>
      <?line 37?>
<t>This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond
conventional zone transfer hints, hints to allow triggering other types of actions
via the DNS
that were previously lacking a trigger mechanism. mechanism to be triggered via the DNS.
Notifications merely nudge the receiver to initiate a predefined action promptly
(instead of on a schedule); they do not alter the action itself
(including any security checks it might employ).</t>
      <t>To enable this functionality, a method for discovering the receiver endpoint
for such notification messages is introduced, via the new DSYNC record type.
Notification types are recorded in a new registry, with initial support for
parental NS and DS record updates including DNSSEC bootstrapping.</t>
      <t>TO BE REMOVED: This document is being collaborated on in Github at:
<eref target="https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify">https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify</eref>.
The most recent working version of the document, open issues, etc. should all be
available there.  The authors (gratefully) accept pull requests.</t>
    </abstract>
  </front>
  <middle>
    <?line 56?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Traditional DNS notifications <xref target="RFC1996"/>, which are here referred to as
"NOTIFY(SOA)", are sent from a primary server to a secondary server to
minimize the latter's convergence time to a new version of the
zone. This mechanism successfully addresses a significant inefficiency
in the original protocol.</t>
      <t>Today
      <t>Today, similar inefficiencies occur in new use cases, in particular particular, delegation
maintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a new
set of notification types will have a major positive benefit by
allowing the DNS infrastructure to completely sidestep these
inefficiencies. For additional context, see <xref target="context"/>.</t>
      <t>Although this document primarily deals with applying generalized notifications
to the delegation maintenance use case, future extension for other applications
(such as multi-signer key exchange) is possible.</t>
      <t>No DNS protocol changes are introduced by this document. The Instead, the mechanism
instead
makes use of a wider range of DNS messages allowed by the protocol.</t>
      <t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"/>, including
<xref target="RFC6781"/>, <xref target="RFC7344"/>, <xref target="RFC7477"/>, <xref target="RFC7583"/>, <xref target="RFC8078"/>,
<xref target="RFC8901"/>, and <xref target="RFC9615"/>.
DNS-specific terminology can be found in <xref target="RFC9499"/>.</t>
      <section anchor="design-goals-for-delegation-maintenance">
        <name>Design Goals for Delegation Maintenance</name>
        <t>When the parent operator is interested in notifications for delegation
maintenance (such as DS or NS update hints), a service to accept these notifications will need to be
made available for accepting these notifications. available. Depending on the
context, this service may be run by the parent operator themselves,
or by a designated entity who is in charge of handling the domain's
delegation data (such as a domain registrar).</t>
        <t>It seems desirable to minimize the number of steps that the notification sender
needs to perform in order to figure out where to send the NOTIFY. This suggests
that the lookup process be ignorant of the details of the parent-side
relationships (e.g., whether or not there is a registrar or not). registrar.) This is
addressed by parameterizing the lookup with the name of the child. The
parent operator may then (optionally) announce the notification endpoint
in a delegation-specific way, way by publishing it at a child-specific name.
(A catch-all endpoint may be indicated by wildcarding.)</t>
        <t>The solution proposed here is thus for the parent operator to publish
the address where someone listens for notifications, in a child-specific
way (see <xref target="signaling"/>). Potential senders can easily determine the name
of the parent and then look up that information (see <xref target="discovery"/>).</t>
      </section>
      <section anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
<?line -6?>
        </t>

      </section>
    </section>
    <section anchor="dsyncrdtype">
      <name>DSYNC RR Type</name>
      <t>This section defines the DSYNC RR type type, which is subsequently used for
discovering notification endpoints.</t>
      <section anchor="wire-format">
        <name>Wire Format</name>
        <t>The DSYNC RDATA wire format is encoded as follows:</t>
        <artwork><![CDATA[
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RRtype                        | Scheme        | Port
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | Target ...  /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
]]></artwork>
        <dl>
          <dt>RRtype</dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/]]></artwork>
        <dl spacing="normal">
          <dt>RRtype:</dt>
          <dd>
            <t>The type of generalized NOTIFY that this DSYNC RR defines the
desired target address for (see the "Resource Record (RR) TYPEs" IANA
registry). For now, only CDS and CSYNC are supported values, with
the former indicating an updated CDS or CDNSKEY record set.</t>
          </dd>
          <dt>Scheme</dt>
          <dt>Scheme:</dt>
          <dd>
            <t>The mode used for contacting the desired notification address. This is an
8-bit unsigned integer. Records with value 0 (null scheme) are ignored by consumers.
Value 1 is described in this document, and values 128-255 are reserved Reserved for
private use.
Private Use.  All other values are currently unassigned.</t>
          </dd>
          <dt>Port</dt>
          <dt>Port:</dt>
          <dd>
            <t>The port on the target host of the notification service. This
is a 16-bit unsigned integer in network byte order. Records with
value 0 are ignored by consumers.</t>
          </dd>
          <dt>Target</dt>
          <dt>Target:</dt>
          <dd>
            <t>The fully-qualified, uncompressed domain name of the target host
providing the service of listening for generalized notifications of the
specified type. This name MUST <bcp14>MUST</bcp14> resolve to one or more address records.</t>
          </dd>
        </dl>
      </section>
      <section anchor="presentation-format">
        <name>Presentation Format</name>
        <t>The presentation format of the RDATA portion is as follows:</t>
        <ul spacing="normal">
          <li>
            <t>The RRtype field is represented as a mnemonic from the "Resource
Record (RR) TYPEs" registry.</t>
          </li>
          <li>
            <t>The Scheme field is represented by its mnemonic mnemonic, if assigned (see
<xref target="schemeregistry"/>), and is otherwise represented as an unsigned decimal integer.</t>
          </li>
          <li>
            <t>The Port field is represented as an unsigned decimal integer.</t>
          </li>
          <li>
            <t>The Target field is represented as a &lt;domain-name&gt; (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>).</t>
          </li>
        </ul>
      </section>
      <section anchor="semantics">
        <name>Semantics</name>
        <t>For now, the only scheme defined is 1 (mnemonic: NOTIFY).  By publishing a
DSYNC record with this scheme, a parent indicates that they would like child
operators to send them a NOTIFY message (see <xref target="cnotify"/>) upon publication of
a new CDS/CDNSKEY/CSYNC RRset, RRset to the address and port listed in that DSYNC
record and using conventional <xref target="RFC1035"/> DNS transport.</t> transport <xref target="RFC1035"/>.</t>
        <t>Example (for the owner names of these records, see <xref target="signaling"/>):</t>
        <artwork><![CDATA[
IN DSYNC  CDS   NOTIFY 5359 cds-scanner.example.net.
IN DSYNC  CSYNC NOTIFY 5360 csync-scanner.example.net.
]]></artwork>
        <t>Should a need for other mechanisms arise, other schemes may be defined
to deal with such requirements using alternative logic.</t>
        <t>Schemes are independent of the RRtype. They merely specify a method of
contacting the target (whereas the RRtype is part of the notification
payload).</t>
      </section>
    </section>
    <section anchor="signaling">
      <name>Publication of Notification Targets</name>
      <t>To use generalized notifications, it is necessary for the sender to know
where to direct each NOTIFY message. This section describes the
procedure for discovering that notification target.</t>
      <t>Note that generalized NOTIFY messages are but one mechanism for
improving the efficiency of automated delegation maintenance. Other
alternatives, such as contacting the parent operator via an API or
DNS Update (<xref target="RFC2136"/>), <xref target="RFC2136"/>, may (or may not) be more suitable in
individual cases. Like generalized notifications, they similarly require
a means for discovering where to send the API or DNS Update requests.</t>
      <t>As the scope for the publication mechanism is wider than only to
support generalized notifications, a unified approach that works
independently of the notification method is specified in this section.</t>
      <t>Parent operators participating in the discovery scheme for the purpose of
delegation maintenance notifications MUST <bcp14>MUST</bcp14> publish endpoint information
using the record type defined in <xref target="dsyncrdtype"/> under the <tt>_dsync</tt>
subdomain of the parent zone, as described in the following subsections.</t>
      <t>There MUST NOT <bcp14>MUST NOT</bcp14> be more than one DSYNC record for each combination of
RRtype and Scheme.
It is RECOMMENDED to secure <bcp14>RECOMMENDED</bcp14> that zones containing DSYNC records with DNSSEC.</t> DNSSEC be secure.</t>
      <t>For practical purposes, the parent operator MAY <bcp14>MAY</bcp14> delegate the <tt>_dsync</tt>
domain as a separate zone, zone and/or synthesize records under it. If
child-specificity is not needed, the parent can publish a static
wildcard DSYNC record.</t>
      <section anchor="wildcard-method">
        <name>Wildcard Method</name>
        <t>If the parent operator itself performs CDS/CDNSKEY or CSYNC processing
for some or all delegations, or if the parent operator wants to forward notifications to some
other party, a default notification target may be specified as follows:</t>
        <artwork><![CDATA[
*._dsync.example.  IN DSYNC  CDS   NOTIFY port target
*._dsync.example.  IN DSYNC  CSYNC NOTIFY port target
]]></artwork>
        <t>To accommodate indirect delegation management models, the
designated notification target may relay notifications to a third party
(such as the registrar, in ICANN's model). The details of such
arrangements are out of scope for this document.</t>
        <t>If for some reason the parent operator cannot publish wildcard records,
the wildcard label may be dropped from the DSYNC owner name (i.e., it
may be published at the <tt>_dsync</tt> label instead). This practice requires
an additional step during discovery (see <xref target="discovery"/>), target="discovery"/>) and is
therefore NOT RECOMMENDED.</t> <bcp14>NOT RECOMMENDED</bcp14>.</t>
      </section>
      <section anchor="child-specific-method">
        <name>Child-specific Method</name>
        <t>It is also possible to publish child-specific records where the parent zone's
labels are stripped from the child's FQDN Fully Qualified Domain Name (FQDN), and the result is used in place of
the wildcard label.</t>
        <t>As an example, consider a registrar offering domains like
<tt>child.example</tt>, delegated from <tt>example</tt> zone. If the registrar
provides the notification endpoint, e.g., <tt>rr-endpoint.example:5300</tt>,
the parent may publish this information as follows:</t>
        <artwork><![CDATA[
child._dsync.example.  IN DSYNC  CDS NOTIFY 5300 rr-endpoint.example.
]]></artwork>
      </section>
    </section>
    <section anchor="cnotify">
      <name>Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications</name>
      <t>Delegation maintenance notifications address the inefficiencies related
to scanning child zones for CDS/CDNSKEY records
<xref target="RFC7344"/><xref target="RFC8078"/><xref target="RFC8078"/> <xref target="RFC9615"/>. (For an overview of the issues,
see <xref target="context"/>.)</t>
      <t>NOTIFY messages for delegation maintenance MUST <bcp14>MUST</bcp14> be formatted as described in
<xref target="RFC1996"/>, with the <tt>qtype</tt> field replaced as appropriate.</t>
      <t>To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with
<tt>qtype=CDS</tt>) is defined to indicate any child-side changes pertaining
to an upcoming update of DS records.
As the child DNS operator generally is unaware of whether the parent
side consumes CDS records or prefers CDNSKEY, or when that policy
changes, it seems advisable to publish both types of records,
preferably using automation features of common authoritative nameserver
software for ensuring consistency.</t>
      <t>Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, registry or
registrar) SHOULD <bcp14>SHOULD</bcp14> initiate the same DNS lookups and verifications for
DNSSEC bootstrapping <xref target="RFC9615"/> or DS maintenance
<xref target="RFC7344"/><xref target="RFC7344"/> <xref target="RFC8078"/> that would otherwise be triggered based on a
timer.</t>
      <t>The CSYNC <xref target="RFC7477"/> inefficiency may be similarly treated, with the
child sending a NOTIFY(CSYNC) message (with <tt>qtype=CSYNC</tt>) to an address
where the parent operator (or a designated party) is listening for CSYNC
notifications.</t>
      <t>In both cases cases, the notification will speed up processing times by
providing the recipient with a hint that a particular child zone has
published new CDS, CDNSKEY CDNSKEY, and/or CSYNC records.</t>
      <section anchor="discovery">
        <name>Endpoint Discovery</name>
        <t>To locate the target for outgoing delegation maintenance notifications,
the notification sender MUST <bcp14>MUST</bcp14> perform the following steps:</t>
        <ol spacing="normal" type="1"><li> type="1">
	  <li>
            <t>Construct the lookup name, name by inserting the <tt>_dsync</tt> label after the
first label of the delegation owner name.</t>
          </li>
          <li>
            <t>Perform a lookup of type DSYNC for the lookup name, and validate the
response if DNSSEC is enabled. If this results in a positive DSYNC answer,
return it.</t>
          </li>
          <li>
            <t>If the query resulted in a negative response:  </t>
            <ul spacing="normal">
              <li>
                <t>If the response's SOA record indicates that the parent is more than
one label away from the <tt>_dsync</tt> label, construct a new lookup name
by inserting the <tt>_dsync</tt> label into the delegation owner name just
before the parent zone labels inferred from the negative response,
and response.
Then go to step 2.      </t> 2.</t>
                <t>
For example, assume that <tt>subsub.sub.child.example</tt> is delegated from
<tt>example</tt> (and not from <tt>sub.child.example</tt> or <tt>child.example</tt>). The
initial DSYNC query relating to it is thus directed at
<tt>subsub._dsync.sub.child.example</tt>. This is expected to result in a
negative response from <tt>example</tt>, and another query for
<tt>subsub.sub.child._dsync.example</tt> is then required.</t>
              </li>
              <li>
                <t>Otherwise, if the lookup name has any labels in front of the
<tt>_dsync</tt> label, remove them to construct a new lookup name (such
as <tt>_dsync.example</tt>), and <tt>_dsync.example</tt>). Then go to step 2.
(This is to enable zone structures without wildcards.)</t>
              </li>
              <li>
                <t>Otherwise, return null (no notification target available).</t>
              </li>
            </ul>
          </li>
        </ol>
      </section>
      <section anchor="sending-notifications">
        <name>Sending Notifications</name>
        <t>When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone,
the DNS operator SHOULD <bcp14>SHOULD</bcp14> send a suitable notification to one of the
endpoints discovered as described in the previous section.</t>
        <t>A NOTIFY message can only carry information about changes concerning one
child zone. When there are changes to several child zones, the sender
MUST
<bcp14>MUST</bcp14> send a separate notification for each one.</t>
        <t>When a primary name server publishes a new RRset in the child, there
typically is a time delay until all publicly visible copies of the zone
are updated. If the primary sends a notification at the exact time of
publication, there is a potential for CDS/CDNSKEY/CSYNC processing to be
attempted before the corresponding records are served. As a result, a
desired update may not be detected (or appear inconsistent), preventing
it from being applied.</t>
        <t>It
        <t>Therefore, it is therefore RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the child delays delay sending notifications
to the recipient until a consistent public view of the pertinent
records is ensured.</t>
        <section anchor="timeouts-and-error-handling">
          <name>Timeouts and Error Handling</name>
          <t>NOTIFY messages are expected to elicit a response from the recipient
(<xref target="RFC1996"/> target="RFC1996"/>, Section 4.7). If no response is received, senders SHOULD <bcp14>SHOULD</bcp14>
employ the same logic as for SOA notifications (<xref target="RFC1996"/> target="RFC1996"/>, Sections 3.5 and 3.6).</t>
          <t>The recipient's attempt to act upon the delegation update request may
fail for a variety of reasons (e.g., due to violation of the continuity
requirement set forth in <xref target="RFC7344"/> Section 4.1). target="RFC7344" sectionFormat="comma" section="4.1"/>). Such failures may
occur asynchronously, even after the NOTIFY response has been sent.</t>
          <t>In order to learn about such failures, senders MAY <bcp14>MAY</bcp14> include an
<xref target="RFC9567"/>
EDNS0 Report-Channel option <xref target="RFC9567"/> in the NOTIFY message to
request that the receiving side to report any errors by making a report query
with an appropriate extended DNS error code as described in
<xref target="RFC8914"/>.
(The prohibition of this option in queries (<xref section="6.1" sectionFormat="comma" target="RFC9567"/>) only
applies to resolver queries and thus does not cover NOTIFY messages.)</t>
          <t>When including this EDNS0 option, its agent domain MUST <bcp14>MUST</bcp14> be subordinate
or equal to one of the NS hostnames, as listed in the child's delegation
in the parent zone.
This is to prevent malicious senders from causing the NOTIFY recipient
to send unsolicited report queries to unrelated third parties.</t>
        </section>
        <section anchor="roles">
          <name>Roles</name>
          <t>While the CDS/CDNSKEY/CSYNC processing following that follows the receipt of a NOTIFY
will often be performed by the registry, the protocol anticipates that
in some contexts (especially for ICANN gTLDs), gTLDs) registrars may take on
the task. In such cases, the current registrar notification endpoint may
be published, enabling notifications to be directed to the
appropriate target. The mechanics of how this is arranged between
registry and registrar are out of scope for this document; the protocol
only offers the possibility to arrange things such that from the child
perspective, it is inconsequential how the parent-side parties are
organized: notifications
organized is inconsequential: Notifications are simply sent to the published address.</t>
          <t>Because of the security model where a notification by itself never
causes a change (it can only speed up the time until the next
check for the same thing), the sender's identity is not crucial.
This opens up the possibility of having an arbitrary party (e.g., a
side-car service) send the notifications, enabling this functionality
even before the emergence of native support in nameserver software.</t>
        </section>
      </section>
      <section anchor="processing-of-notify-messages-for-delegation-maintenance">
        <name>Processing of NOTIFY Messages for Delegation Maintenance</name>

        <t>The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) processing.</t>
        <t>NOTIFY messages carrying notification payloads (records) for more
than one child zone MUST <bcp14>MUST</bcp14> be discarded, as sending them is an error.</t>
        <t>Otherwise, upon receipt of a (potentially forwarded) NOTIFY message for
a particular child zone at the published notification endpoint,
the receiving side (parent registry or registrar) has two options:</t>
        <ol spacing="normal" type="1"><li> type="1">
	  <li>
            <t>Acknowledge receipt by sending a NOTIFY response as described in
<xref target="RFC1996"/> target="RFC1996"/>, Section 4.7, and schedule
an immediate check of the CDS/CDNSKEY/CSYNC RRsets published by that
particular child zone (as appropriate for the type of NOTIFY received).  </t>
            <t>
If the NOTIFY message contains an <xref target="RFC9567"/> EDNS0 Report-Channel
option <xref target="RFC9567"/> with an agent domain subordinate or equal to one of the NS
hostnames listed in the delegation, the processing party SHOULD <bcp14>SHOULD</bcp14>
report any errors occurring during CDS/CDNSKEY/CSYNC processing by sending
a report query with an appropriate extended DNS error code as
described in <xref target="RFC8914"/>. Reporting may be done asynchronously
(outside of the NOTIFY transaction).  </t>
            <t>
When using periodic scanning, notifications preempt the scanning
timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/CSYNC RRset
is indeed new or has changed, the corresponding child's timer may
be reset and the scanning frequency reduced (e.g., to once a week).
If a CDS/CDNSKEY/CSYNC change is later detected through scanning (without
having received a notification), the NOTIFY-related state SHOULD <bcp14>SHOULD</bcp14> be
cleared, reverting to the default scanning schedule for this child.  </t>
            <t>
When introducing CDS/CDNSKEY/CSYNC scanning support at the same time
as NOTIFY support, backwards compatibility considerations
regarding the scanning interval do not apply; thus, a low-frequency
scanning schedule MAY thus <bcp14>MAY</bcp14> be used by default in such cases.</t>
          </li>
          <li>

            <t>Do not act upon the notification. To prevent retries, recipients
SHOULD
<bcp14>SHOULD</bcp14> acknowledge the notification by sending a NOTIFY response
even when otherwise ignoring the request, combined with a report
query if feasible (see above). One reason to do this may be a rate
limit (see <xref target="security"/>), in which case "Blocked" Blocked (15) may be a
suitable extended DNS error code.</t>
          </li>
        </ol>
        <t>Implementing the first option will significantly decrease the
convergence time (between publication of a new CDS/CDNSKEY/CSYNC record in the
child and publication of the resulting DS), thereby providing improved
service for the child.</t>
        <t>If, in addition to scheduling an immediate check for the child zone of
the notification, the scanning schedule is also modified to be less
frequent, the cost of providing the scanning service will be reduced.</t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>If an action is triggered by the receipt of a DNS NOTIFY, its execution relies
on the same security model which that the receiving party would apply if the action
had been
were triggered by something else. This is because the notification affects
the action's timing alone. For example, DS bootstrapping is expected to be
performed the same way way, independently of the type of trigger; this includes all
security and authentication requirements (e.g., <xref target="RFC9615"/>) which that the parent
registry/registrar has chosen to apply.</t>
      <t>The original NOTIFY specification sidesteps most security issues by not
relying on the information in the NOTIFY message in any way, way and instead
only using it to "enter the state it would if the zone's refresh timer
had expired" (<xref section="4.7" sectionFormat="of" (Section 4.7 of <xref target="RFC1996"/>).</t>
      <t>This security model is reused for generalized NOTIFY messages. It
therefore Therefore, it
seems impossible to affect the behaviour of the recipient of
the NOTIFY other than by hastening the timing for when different checks
are initiated.
As a consequence, while notifications themselves can be secured via access
control mechanisms, this is not a requirement.</t>
      <t>The
      <t>In general, the receipt of a notification message will, in general, will cause the
receiving party to perform one or more outbound queries for the records
of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY
queries). When done using standard DNS, the size of these queries is
comparable to that of the NOTIFY messages themselves, rendering any
amplification attempts futile. The number of queries triggered per
notification is also limited by the requirement that a NOTIFY message
can refer to one child only.</t>

<!-- [rfced] How may "unreasonable" be clarified? We ask because we aren't
sure if this will be completely clear to the reader.

Current:
   However, when the outgoing query occurs via encrypted transport, some
   amplification is possible, both with respect to bandwidth and
   computational burden.  In this case, the usual principle of bounding
   the work applies, even under unreasonable events.
-->

      <t>However, when the outgoing query occurs via encrypted transport, some
amplification is possible, both with respect to bandwidth and
computational burden. In this case, the usual principle of bounding the
work,
work applies, even under unreasonable events, applies.</t>
      <t>Receivers therefore MUST events.</t>
      <t>Therefore, receivers <bcp14>MUST</bcp14> implement rate limiting for notification
processing. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to configure rate limiting independently
for both the notification's source IP address and the name of the zone
that is conveyed in the NOTIFY message. Rate limiting also mitigates
the processing load from garbage notifications.</t>
      <t>Alternative solutions (such as signing notifications and validating
their signatures) appear significantly more expensive without tangible
benefit.</t>
      <t>In order to facilitate schemes that are authenticated outside of DNSSEC
(such as via SIG(0)), zones containing DSYNC records are not required to
be signed. Spoofed DSYNC responses would prevent notifications from
reaching their legitimate target, and a different party may receive
unsolicited notifications; both effects, however, both effects can also be achieved
in the presence of DNSSEC. The illegitimate target is also enabled to
learn notification contents in real-time, real time, which may be a privacy concern
for the sender. If so, the sender may choose to ignore unsigned DSYNC
records.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t><strong>Note to the RFC Editor</strong>: In this section, please replace occurrences of "(this document)" with a proper reference.</t>
      <section anchor="dsync-rr-type">
        <name>DSYNC RR Type</name>
        <t>IANA is requested to update has registered DSYNC in the "Resource Record (RR) TYPEs" registry
under the "Domain Name System (DNS) Parameters" registry group as follows:</t>
        <dl>
          <dt>Type</dt>
          <dd>
            <t>DSYNC</t>
          </dd>
          <dt>Value</dt>
          <dd>
            <t>66</t>
          </dd>
          <dt>Meaning</dt>
          <dd>
            <t>Endpoint

        <dl spacing="compact" newline="false">
          <dt>Type:</dt> <dd>DSYNC</dd>
          <dt>Value:</dt> <dd>66</dd>
          <dt>Meaning:</dt> <dd>Endpoint discovery for delegation synchronization</t>
          </dd>
          <dt>Reference</dt>
          <dd>
            <t>(this document)</t>
          </dd>
          synchronization</dd>
          <dt>Reference:</dt> <dd>RFC 9859</dd>
        </dl>
      </section>
      <section anchor="schemeregistry">
        <name>DSYNC Scheme Registration</name>
        <t>IANA is requested to create and maintain has created the following new registry in the
"Domain Name System (DNS) Parameters" registry group:</t>
        <dl>
          <dt>Name</dt>
          <dd>
            <t>DSYNC:
        <dl spacing="compact" newline="false">
          <dt>Name:</dt> <dd>DSYNC: Location of Synchronization Endpoints</t>
          </dd>
          <dt>Assignment Policy</dt>
          <dd>
            <t>Expert Review</t>
          </dd>
          <dt>Reference</dt>
          <dd>
            <t>(this document)</t>
          </dd> Endpoints</dd>
          <dt>Registration Procedure:</dt> <dd>Expert Review</dd>
          <dt>Reference:</dt> <dd>RFC 9859</dd>
        </dl>

        <t>The initial contents for the registry are as follows:</t>
        <table>
          <thead>
            <tr>
              <th align="left">RRtype</th>
              <th align="left">Scheme</th>
              <th align="left">Mnemonic</th>
              <th align="left">Purpose</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left"> </td> align="left"> </td>
              <td align="left">0</td>
              <td align="left"> </td> align="left"> </td>
              <td align="left">Null scheme (no-op)</td>
              <td align="left">(this document)</td> align="left">RFC 9859</td>
            </tr>
            <tr>
              <td align="left">CDS</td>
              <td align="left">1</td>
              <td align="left">NOTIFY</td>
              <td align="left">Delegation management</td>
              <td align="left">(this document)</td> align="left">RFC 9859</td>
            </tr>
            <tr>
              <td align="left">CSYNC</td>
              <td align="left">1</td>
              <td align="left">NOTIFY</td>
              <td align="left">Delegation management</td>
              <td align="left">(this document)</td> align="left">RFC 9859</td>
            </tr>
            <tr>
              <td align="left"> </td> align="left"> </td>
              <td align="left">2-127</td>
              <td align="left"> </td> align="left"> </td>
              <td align="left">Unassigned</td>
              <td align="left"> </td> align="left"> </td>
            </tr>
            <tr>
              <td align="left"> </td> align="left"> </td>
              <td align="left">128-255</td>
              <td align="left"> </td> align="left"> </td>
              <td align="left">Reserved (private use)</td> for Private Use</td>
              <td align="left">(this document)</td> align="left">RFC 9859</td>
            </tr>
          </tbody>
        </table>
        <t>Requests to register additional entries MUST <bcp14>MUST</bcp14> include the following fields:</t>
        <dl>
          <dt>RRtype</dt>
          <dd>
            <t>An
        <dl spacing="compact" newline="false">
          <dt>RRtype:</dt> <dd>An RRtype that is defined for use</t>
          </dd>
          <dt>Scheme</dt>
          <dd>
            <t>The use</dd>
          <dt>Scheme:</dt> <dd>The mode used for contacting the desired
          notification address</t>
          </dd>
          <dt>Mnemonic</dt>
          <dd>
            <t>The address</dd>
          <dt>Mnemonic:</dt> <dd>The scheme's shorthand string used in
          presentation format</t>
          </dd>
          <dt>Purpose</dt>
          <dd>
            <t>Use format</dd>
          <dt>Purpose:</dt> <dd>Use case description</t>
          </dd>
          <dt>Reference</dt>
          <dd>
            <t>Location description</dd>
          <dt>Reference:</dt> <dd>Location of specification or registration source</t>
          </dd>
          source</dd>
        </dl>
        <t>Registration requests are to be recorded by IANA after Expert Review <xref target="RFC8126"/>.
Expert reviewers Reviewers should take into consideration the following points,
but points below into consideration; however,
they are being designated as experts for a reason, so they and should be given substantial latitude:</t>

<!-- [rfced] Is it correct that the Scheme and Mneumonic are tied together, so registrations with the same mneumonic would have the same scheme value?  We ask because RRtypes CDS and CSYNC both display "1" in the Scheme column in the "DSYNC: Location of Synchronization Endpoints" registry.

Also, is it correct that the Scheme column is the range of code points available for assignment (i.e., a separate column for values is not needed)?

Original:
   *  Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.
      The code points tagged as "Private Use" are intended for testing
      purposes and closed environments.  Code points in other ranges
      should not be assigned for testing.

From the IANA registry <https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dsync-location-of-synchronization-endpoints>

RRtype 	Scheme 	Mnemonic 	Purpose
 	0 		        Null scheme (no-op)
CDS 	1 	NOTIFY 	        Delegation management
CSYNC 	1 	NOTIFY 	        Delegation management
	2-127 		        Unassigned
	128-255 		Reserved for Private Use
-->

        <ul spacing="normal">
          <li>
            <t>Point squatting should be discouraged.  Reviewers are encouraged
    to get sufficient information for registration requests to ensure
    that the usage is not going to duplicate one that is already
    registered and that the point is likely to be used in deployments.
    The code points tagged as "Private Use" are intended for testing
    purposes and closed environments.  Code points in other ranges
    should not be assigned for testing.</t>
          </li>
          <li>
            <t>A specification of a scheme is desirable, but early assignment before a
    specification is available is also possible.  When
    specifications are not provided, the description provided needs to
    have sufficient information to identify what the point is being
    used for.</t>
          </li>
          <li>
            <t>Experts should take into account that field values are fit for purpose.
For example, the mnemonic should be indicative and and have a plausible
connection to the scheme's notification mechanism.</t>
          </li>
        </ul>
      </section>
      <section anchor="dsync-underscore-name">
        <name>_dsync Underscore Name</name>
        <t>Per <xref target="RFC8552"/>, IANA is requested to add has registered the following entries to the
"Underscored and Globally Scoped DNS Node Names" registry:</t>
        <artwork><![CDATA[
+---------+------------+-----------------+
| RR Type | _NODE NAME | Reference       |
+---------+------------+-----------------+
| DSYNC   | _dsync     | (this document) |
+---------+------------+-----------------+
]]></artwork>
      </section>
    </section>
    <section anchor="implementation-status">
      <name>Implementation Status</name>
      <t><strong>Note to registry within the RFC Editor</strong>: please remove this entire section before publication.</t>
      <t>Johan Stenstam's experimental nameserver implements this draft
(https://github.com/johanix/tdns).</t>
      <section anchor="child-dns-operator-side">
        <name>Child DNS Operator-side</name>
        <ul spacing="normal">
          <li>
            <t>IronDNS implementation under way</t>
          </li>
          <li>
            <t>deSEC implementation under way (Q1/2025)</t>
          </li>
        </ul>
      </section>
      <section anchor="parent-side">
        <name>Parent-side</name>
        <ul spacing="normal">
          <li>
            <t>SWITCH (.CH/.LI) implementation is under way.</t>
          </li>
          <li>
            <t>.SE/.NU will implement this once it is an RFC.</t>
          </li>
        </ul> "Domain Name System (DNS) Parameters" registry group:</t>

<table>
  <thead>
    <tr><th>RR Type</th><th>_NODE NAME</th><th>Reference</th></tr>
  </thead>
  <tbody>
    <tr><td>DSYNC</td><td>_dsync</td><td>RFC 9859</td></tr>
  </tbody>
</table>
      </section>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>In order of first contribution or review:
Joe Abley, Mark Andrews, Christian Elmerot, Ólafur Guðmundsson, Paul
Wouters, Brian Dickson, Warren Kumari, Patrick Mevzek, Tim Wicinski,
Q Misell, Stefan Ubbink, Matthijs Mekking, Kevin P. Fleming, Nicolai
Leymann, Giuseppe Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman
Danyliw, Peter van Dijk, John Scudder, Éric Vyncke.</t>
    </section>

  </middle>
  <back>
    <displayreference target="I-D.ietf-dnsop-dnssec-automation" to="DNSSEC-AUTO"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC1996">
          <front>
            <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <date month="August" year="1996"/>
            <abstract>
              <t>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1996"/>
          <seriesInfo name="DOI" value="10.17487/RFC1996"/>
        </reference>
        <reference anchor="RFC9364">
          <front>
            <title>DNS Security Extensions (DNSSEC)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="February" year="2023"/>
            <abstract>
              <t>This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="237"/>
          <seriesInfo name="RFC" value="9364"/>
          <seriesInfo name="DOI" value="10.17487/RFC9364"/>
        </reference>
        <reference anchor="RFC7344">
          <front>
            <title>Automating DNSSEC Delegation Trust Maintenance</title>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="G. Barwood" initials="G." surname="Barwood"/>
            <date month="September" year="2014"/>
            <abstract>
              <t>This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7344"/>
          <seriesInfo name="DOI" value="10.17487/RFC7344"/>
        </reference>
        <reference anchor="RFC7477">
          <front>
            <title>Child-to-Parent Synchronization in DNS</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <date month="March" year="2015"/>
            <abstract>
              <t>This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7477"/>
          <seriesInfo name="DOI" value="10.17487/RFC7477"/>
        </reference>
        <reference anchor="RFC8078">
          <front>
            <title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="P. Wouters" initials="P." surname="Wouters"/>
            <date month="March" year="2017"/>
            <abstract>
              <t>RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.</t>
              <t>Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.</t>
              <t>This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).</t>
              <t>It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8078"/>
          <seriesInfo name="DOI" value="10.17487/RFC8078"/>
        </reference>
        <reference anchor="RFC9615">
          <front>
            <title>Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator</title>
            <author fullname="P. Thomassen" initials="P." surname="Thomassen"/>
            <author fullname="N. Wisiol" initials="N." surname="Wisiol"/>
            <date month="July" year="2024"/>
            <abstract>
              <t>This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated.</t>
              <t>Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay".</t>
              <t>This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9615"/>
          <seriesInfo name="DOI" value="10.17487/RFC9615"/>
        </reference>
        <reference anchor="RFC9499">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="9499"/>
          <seriesInfo name="DOI" value="10.17487/RFC9499"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC2136">
          <front>
            <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
            <author fullname="P. Vixie" initials="P." role="editor" surname="Vixie"/>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="J. Bound" initials="J." surname="Bound"/>
            <date month="April" year="1997"/>
            <abstract>
              <t>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2136"/>
          <seriesInfo name="DOI" value="10.17487/RFC2136"/>
        </reference>
        <reference anchor="RFC9567">
          <front>
            <title>DNS Error Reporting</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <date month="April" year="2024"/>
            <abstract>
              <t>DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914.</t>
              <t>When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9567"/>
          <seriesInfo name="DOI" value="10.17487/RFC9567"/>
        </reference>
        <reference anchor="RFC8914">
          <front>
            <title>Extended DNS Errors</title>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <author fullname="E. Hunt" initials="E." surname="Hunt"/>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
            <date month="October" year="2020"/>
            <abstract>
              <t>This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8914"/>
          <seriesInfo name="DOI" value="10.17487/RFC8914"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8552">
          <front>
            <title>Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves</title>
            <author fullname="D. Crocker" initials="D." surname="Crocker"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="222"/>
          <seriesInfo name="RFC" value="8552"/>
          <seriesInfo name="DOI" value="10.17487/RFC8552"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7344.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7477.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8078.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9615.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9567.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC6781">
          <front>
            <title>DNSSEC Operational Practices, Version 2</title>
            <author fullname="O. Kolkman" initials="O." surname="Kolkman"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <author fullname="R. Gieben" initials="R." surname="Gieben"/>
            <date month="December" year="2012"/>
            <abstract>
              <t>This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</t>
              <t>The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t>
              <t>This document obsoletes RFC 4641,
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6781.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7583.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml"/>

<!-- [I-D.ietf-dnsop-dnssec-automation] IESG State: Expired as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6781"/>
          <seriesInfo name="DOI" value="10.17487/RFC6781"/>
        </reference>
        <reference anchor="RFC7583">
          <front>
            <title>DNSSEC Key Rollover Timing Considerations</title>
            <author fullname="S. Morris" initials="S." surname="Morris"/>
            <author fullname="J. Ihren" initials="J." surname="Ihren"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7583"/>
          <seriesInfo name="DOI" value="10.17487/RFC7583"/>
        </reference>
        <reference anchor="RFC8901">
          <front>
            <title>Multi-Signer DNSSEC Models</title>
            <author fullname="S. Huque" initials="S." surname="Huque"/>
            <author fullname="P. Aras" initials="P." surname="Aras"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="J. Vcelak" initials="J." surname="Vcelak"/>
            <author fullname="D. Blacka" initials="D." surname="Blacka"/>
            <date month="September" year="2020"/>
            <abstract>
              <t>Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8901"/>
          <seriesInfo name="DOI" value="10.17487/RFC8901"/>
        </reference>
        <reference anchor="I-D.ietf-dnsop-dnssec-automation">
          <front>
            <title>DNSSEC automation</title>
            <author fullname="Ulrich Wisser" initials="U." surname="Wisser">
         </author>
            <author fullname="Shumon Huque" initials="S." surname="Huque">
              <organization>Salesforce</organization>
            </author>
            <author fullname="Johan Stenstam" initials="J." surname="Stenstam">
              <organization>The Swedish Internet Foundation</organization>
            </author>
            <date day="19" month="October" year="2024"/>
            <abstract>
              <t>   This document describes an algorithm and protocol to automate the
   setup, operations, and decomissioning of Multi-Signer DNSSEC
   [RFC8901] configurations.  It employs Model 2 of the multi-signer
   specification, where each operator has their own distinct KSK and ZSK
   sets (or CSK sets), Managing DS Records from the Parent via CDS/
   CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS
   [RFC7477] to accomplish this.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-dnssec-automation-03"/>
        </reference> 07/17/25 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-dnssec-automation.xml"/>
      </references>
    </references>
    <?line 633?>

<section anchor="context">
      <name>Efficiency and Convergence Issues in DNS Scanning</name>
      <section anchor="original-notify-for-zone-transfer-nudging">
        <name>Original NOTIFY for Zone Transfer Nudging</name>
        <t><xref target="RFC1996"/> introduced the concept of a DNS Notify message message, which was used
to improve the convergence time for secondary servers when a DNS zone
had been updated in the primary. The basic idea was to augment the
traditional "pull" mechanism (a periodic SOA query) with a "push"
mechanism (a Notify) for a common case that was otherwise very
inefficient (due to either slow convergence or wasteful and overly
frequent scanning of the primary for changes).</t>
        <t>While it is possible to indicate how frequently checks should occur
(via the SOA Refresh parameter), these checks did not allow catching
zone changes that fall between checkpoints. <xref target="RFC1996"/> addressed the
optimization of the time-and-cost trade-off between a secondary frequent checking
frequently
for new versions of a zone, zone and infrequent checking, by
replacing scheduled scanning with the more efficient NOTIFY mechanism.</t>
      </section>
      <section anchor="similar-issues-for-ds-maintenance-and-beyond">
        <name>Similar Issues for DS Maintenance and Beyond</name>
        <t>Today, we have similar issues with slow updates of DNS data in spite of
the data having been published. The two most obvious cases are CDS and
CSYNC scanners deployed in a growing number of TLD registries. Because of
the large number of child delegations, scanning for CDS and CSYNC records
is rather slow (as in in, infrequent).</t>
        <t>It
        <t>There is only a very small number of the delegations that will have updated
CDS or CDNSKEY record in between two scanning runs. However, frequent
scanning for CDS and CDNSKEY records is costly, and infrequent scanning
causes slower convergence (i.e., delay until the DS RRset is updated).</t>
        <t>Unlike in the original case, where the primary is able to suggest the
scanning interval via the SOA Refresh parameter, an equivalent mechanism
does not exist for DS-related scanning.</t>
        <t>All of the above also applies to automated NS and glue record
maintenance via CSYNC scanning <xref target="RFC7477"/>. Again, given that CSYNC
records change only rarely, frequent scanning of a large number of
delegations seems disproportionately costly, while infrequent scanning
causes slower convergence (delay until the delegation is updated).</t>
        <t>While use of the NOTIFY mechanism for coordinating the key exchange in
multi-signer setups <xref target="I-D.ietf-dnsop-dnssec-automation"/> is
conceivable, the detailed specification is left for future work.</t>
      </section>
    </section>

    <section anchor="change-history-to-be-removed-before-publication">
      <name>Change History (to be removed before publication)</name>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-09</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Leftover editorial changes</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-08</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>IESG review editorial changes</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Added guidelines anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>In order of first contribution or review: <contact fullname="Joe
      Abley"/>, <contact fullname="Mark Andrews"/>, <contact
      fullname="Christian Elmerot"/>, <contact fullname="Ólafur
      Guðmundsson"/>, <contact fullname="Paul Wouters"/>, <contact
      fullname="Brian Dickson"/>, <contact fullname="Warren Kumari"/>,
      <contact fullname="Patrick Mevzek"/>, <contact fullname="Tim
      Wicinski"/>, <contact fullname="Q Misell"/>, <contact fullname="Stefan
      Ubbink"/>, <contact fullname="Matthijs Mekking"/>, <contact
      fullname="Kevin P. Fleming"/>, <contact fullname="Nicolai Leymann"/>,
      <contact fullname="Giuseppe Fioccola"/>, <contact fullname="Peter
      Yee"/>, <contact fullname="Tony Li"/>, <contact fullname="Paul
      Wouters"/>, <contact fullname="Roman Danyliw"/>, <contact
      fullname="Peter van Dijk"/>, <contact fullname="John Scudder"/>, and
      <contact fullname="Éric Vyncke"/>.</t>
    </section>

  </back>

<!-- [rfced] May we expand "DS" and "NS" as Delegation Signer and Name Server upon first usage for expert review (IESG feedback)</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits from Dnsdir telechat review</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-07</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>IESG clarity?

FYI - we added the expansion "Fully Qualified Domain Name" for FQDN. Please
let us know if this is objectionable.
-->

<!-- [rfced] For consistency, should "Notify" be "NOTIFY" in the
Appendix? We ask because the term is fully capitalized throughout the
document, excluding the Appendix section.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes (notable: scheme now has mnemonic; else editorial)</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits from Opsdir telechat review</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-06</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits from Genart review</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits from Opsdir review</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits from Dnsdir review</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-05</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Editorial changes</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-04</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Add section on Implementation Status</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Use assigned DSYNC RRtype value</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Define DSYNC presentation format</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Make all needed IANA requests</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Editorial changes</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-03</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Include DNSSEC bootstrapping use case</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Remove sections with approaches not pursued</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Editorial changes</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-02</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Nits by Tim Wicinski</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Dnsdir feedback</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Specify timeout are needed.

In addition, please consider whether "traditional" and error handling</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Editorial nits</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Reserve scheme value 0</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-01</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Reserve scheme values 128-255</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message)</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Describe endpoint discovery</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Discussion on garbage notifications</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>More discussion on amplification risks</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Clean-up, editorial changes</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-ietf-dnsop-generalized-notify-00</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Revision after adoption.</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-thomassen-dnsop-generalized-dns-notify-02</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Add rationale "native" should be updated for staying clarity.  While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
These are subjective terms, as they may mean the same thing for everyone.
Note that updates of this nature typically result in band</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Add John more precise language,
which is helpful for readers.

Current A:
   Traditional DNS notifications [RFC1996], which are here referred to
   as an author</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-thomassen-dnsop-generalized-dns-notify-01</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Mention Ry-to-Rr forwarding "NOTIFY(SOA)", are sent from a primary server to accommodate RRR model</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Add port number flexibility</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Add scheme parameter</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Drop SRV-based alternative in favour of a secondary
   server, to minimize the latter's convergence time to a new NOTIFY RR</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Editorial improvements</t>
        </li>
      </ul>
      <ul spacing="normal">
        <li>
          <t>draft-thomassen-dnsop-generalized-dns-notify-00</t>
        </li>
      </ul>
      <ul empty="true">
        <li>
          <t>Initial public draft.</t>
        </li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA619W3rjxrXue42ijvxg0iHZrb63vI8TWZLbSrrViqSOP+/L
lwaBIgULBGgUIJluewD7+UzgDOGM4WRie93qBlJ2O44cxxIJFKpWrcu/boXp
dKq6sqvMgX5latNmVfmjKfTx2aU+a7pyUeZZVza1Vdl83prb9Kr0iqLJ62wF
AxVttuimpekW06K2zXq6DPdMa7xnM334UhVZBxd/OD68OvlZwSBm2bSbA227
Qqly3R7oru1t9+jhw5cPH6msNdmBPq0709amU3dNe7Nsm359gFN9e66/gQ/K
eqlf4YfqxmzgiiLcMD3GOSllu6wu/p5VTQ2P3hir1uWB/o+uySfaNm3XmoWF
3zYr/OW/lMr67rppD5SeKg0/ZW0P9J9n+rIzNYy0og95zX9urrM6/aJpl1ld
/kjUOdBX10Zf3pmitNd+Vvqrpq8LuoDuMKusrA70dzjWzMpYfyrlaguE60xl
DXxnkimdz2D4ZpVZ+C6a07mBGwffwKRgg8zlydFEX5q8b2FWG3jUyuqTelnW
xrRAxng2axzlT4WxJp+VzZAUr80t3JQSoo4/pQdeItnzBh72+vVRPDjtR9YW
9k/WXTLLm5VSddOugDC35gCYoV5Ef02nU53NbddmOWzo1XVpNXBevzJ1pwOj
WQ3DafMDELGwugPi99boZsGc/fbq9Ktv9ejiqyO9//Lls7Gem01TFypv6lsY
B/Yjq/SPwCTAg1ltF0DGa9gG4I2u0VlVNXfwRblcErF0A8O3utus4anwBJgX
ycNtmdGD8YndddbpOwMEWIMUlU1vq42uspx4NnOD6ZXJYetLu5qpRLbgi9bA
HXVfLA0N2prcAD1anFBZl10J8gMDweiFWQDtC5kGfNKs1l21USPYss5kBU4R
Ps+0za9N0Vdm/DmOuAEqahBOWB5yDT5DRig7a6oF3p9XfUETrjfaIvOU3UbD
KPmNhav0qlxed7Cz66rZjGewN402dTavcMawS4u+zpm0cNsEJrAyIF2Fhs3V
IBZ5c8vkTJYH27dugPQKr7J9fq3riDAwhLXZEugO48NVbVP0uSkm2tG+Nnf6
+PLbsyMcETQC7VJKXNk4UDByDdCuRPrgva1ZlsBqMN27srsWSlcwkfUa1AVO
Xa3hzrqDD2GbkeeOL92z+jWqOJyYIxywAkienjdNhwy8XsOHSKi3+ssTfXHy
5u3fTo5RVcQ8Db/PDd6cN1WVzZsWxixwB2GSr2BS/Vxn3YH6j+uuW9uDBw+W
9BlK0QMS3c7J/4OP0Mv/NfqXDAO7j/pu1diOthKWcScKGjbVItWBC3GD3DIn
ulkbWJO1vQExM10+0/a66asC5Q0ooLJb0BjCTSANM00qlTW01aMl0mXRV9Vm
DIybm3Wn1/AXPP57GLGzM9Ycq7IoKqPUJ6iEiV1I+6qrNitKEXwU2DoRvw8f
/hfoClQVP/8MrHBdAh8iw+BE4AmgH0DuSDdYtcfaZXT59nC8N6HLLBJgAYJI
ElqushblpxXxzVCWGlSD0adqBby2ApISlaqsgy341GpSUC0QPIcvypXh+5FT
U7oqVF4z5iSvVFB+chAYopLOiqKFP5D1tS2XNS0X+a02C/i1hGdsQPXS8xvQ
TyWSBrQJGMumIukuMpgwTLLK2viuEtVgDtoBORSnhpo3zyzuK3wC8tKVeY83
FaYySzZ/YA7AzNUZLmx0zJJ0NpSk8Uz/GSABUFnLxCJa0yMmTA1lwbgCJept
Ob8rgSmus1vUlqvsO9Aq68aWaFuAyWARoMfmG0U63ikj5AewQW0GMgv8gjYT
yA6Ssa5AMiokApjHzqzxajDNKS1mYOVbpLZjL9jDDgwT4AxjgLPkz59/Bpoe
VsDN/fKaFaZXAcwzJTypMFllWReB9qg2OMVI/FK2VTBLkjFPZh2T2W3LBDQz
LYqsJTERKlu2avgUP96IFDBQf9VXXTlFroFLAGzBrchjSzNGdQUEtSUIKizo
rCHqObbRfBVr26CvgeLpimck255xlTNdq+wGbhZLngEdCnh+i0M60+4NAu2g
G9rEjHsBI4Gw0BzMD2uTdyy7c6MXGXBzCZxJFBZtzcL/8vGzJyj8XpmrDx/+
CJ8/e/5iHz/nq54/fvIk+uvJ8+f8F175/OmLx+G7Fw+fv4C/ZJQXLx/SKMj2
8rxn+0+RJ2ASUwuTxG3VoARALzRVswS7C3gTp4wQEsVBbnvy8iWx0ief6GOD
O6RfNcgzuKXHgRHeBEZQ6ptrw+LEtgxVMWhTuIGtKig527FVTNUiWe57ZNix
CsgyXAU7wzLMOGo8Ia3X3pZwKUkkAE/ZBBimAOH02h4fwgpd5BF2P5nGDNYF
toMMbEPrUF7EiKvcg1agr4BibV97rhisFz5bAdi5BVWl4E+4KoMFIhXJ6CI0
BMRzd90wZZCdW+Y9YNSicgqjaJAUn4JLFAgOi88CVTK5xgGMrEXAdNqhTgAo
js9s2dY1OrEEdb+aA8/DE1HhWAaW9EWs6sDgAIsrJKrFIWB9CKFxyghwyOws
yiUKfdODbSY7Bp/hfZFeFQNiewCnYEKVf1jVNDf9GoUK7QkSFUgEyKTuvF03
HWygdX8yoaeoKBUgWd646xIWMDKz5QxtqmEUTVMpkUKeNMhAsLyxTKcEZ1Rs
F4k3jA2eB3Bp+aPbAJkfSTERBy5wU8mvy6ogBaOG248M0qEsjJo1K2tCE3UN
MpabbTJ7cEp4MWx2ENi7DKAjzrGfV+D54fzAwAAVM55HuBKnOFOjQ5DrLr+e
IuhxwzvGLYHHc2JEGBGkpsjBc0IEOVYEt2xT9Q7zgw6G6xwxAcqxtO5k+sZN
TxHqZ9oKU9hmZdAPgq/RONAgifRNGCynq1GwbmB2sm8kPSgaP/8MO3jedChF
iKGJRy3pMZNZtm6s4IzfNJXwD6lH2iDcYNAozP7eP4Sly0OdP7HBh5IyvAAc
WLYGrYvFwEUmuA8GRwOG4QKr9968u7wC0Eb/RSHA3y9O/vru9OLkGH+//Prw
9Wv/i5IrLr9+++71cfgt3Hn09s2bk7Njvhk+1clHau/N4bd7rPX33p5fnb49
O3y9x9gmtv8ZSyexAFAInDxkggz1i83bcs66+cuj8///f/efiCF4tL8PhsAZ
m/3nYJZwS2t+WlNXG/kTfT8FZt4QiiO0nWfrEjwa2FtQVYDC72ripJn6tz9W
uDvTZ3/8QiGGZtfq4kJfAbbSHz4p7KbO2wKR1s/imwO2Zf1Hbim74v42vFDg
NOmZuUW0XoO7ikaeXEMVu4Y7pc/yBn8Du4tQCxiBt1Wecnx4dQjS0pIlWWXk
UAEyawoiIXyIQMEeKApL7PzZ3/HPox3/PNaPeZCHdMFj/UQ/1c/0c/1Cv/wt
n9Egf5j+zn9olJ+AykTke35+0pfgv69M+Psc/Np/4QS2H3iFJrPTsxl4cA8+
4kkPALHRGhQH0Wg5oBZi2CsBHbFPpQ0cFrGdIquKMINn4BQdqjRSG3sXxjZ9
C5r+gt2O0cXFWF99e35i9/Tp4dmhcuGAMYP6urmbsCgdictyRM8ln49DBPC4
26winxatEWlY5EPTOnXOARWBRwWNBEMfAe77y8m3zgECfwa4nPdK6LACDvZS
Qk4FxmscApGlJgIjC/ZmFB6rXkznYJD6mrB8QfpladqZUEBcDVoBcOaoRo/a
0izGjOHR7LNBghlYUFctiOPf6Pp9fESioRKtxoqIiaP3H72YPnr6VKIw5AWz
9IPrc4uwERYK/HIIj2e/RO7D68HTbEVn1JnlhQCxiJGZVBSrYWjoNv8aQxNi
XAbQicAiE0kRENl/tpNI7N52GNiA9XeGoVVKOuVIdz+xFAuETJV88+n3PTD2
osRIFiAPcDQF7QhojOFMtB4gVnNbFo4HHOyFC9l64xfIK/c6jC54IGbcSLiM
+YUeSnYRJtMARkaThNAAgROGdp08McuKVj7H3azZ2ibaeR1/IZpZlsQqGzeN
wo82VdNTopOoNZhkVeAlrZEBWauDb1+bVVMDsKK4Cw7rxRuUzg4Bd7I9c48Q
zbjzEbCFJeAI/5AS3FFhPdIl8AhAPjSAGxeQyISZ964EFwYnWQeeKoDiK0BF
TgDdJM4pzHjfKj9iAFG39xPqP/+NuWqKG/yfX+iRBLsePn46gWVciv1+Otv3
WOrSrADql7lVyqtBChOhKuRVaxeGhkfu65Ej1IGoalCg+ssEFmcqidMKdEdU
QOOhwygg0MHg4PwgfMNIYVXeCL5XDt3a2K3B+JuYCokTOLyYc9wSVgiKGBE0
Tkw0QrNQHGID1fxA9PKDIzEwoJgpKRAjZ9RrpHJI7ETzwUxpgUoWiBf1luO6
UdIhEB/wGmUOMAGBowHpT37IMOakRw7KAzIDPYQb52TXuii2dfGlGH8Lyjk9
EwNJ1kY7mjx9/PSlzgs7tYDJYeCZ4efNarQ+gxvpP/7GZw91jthv963qUiK5
7OaH6JKP8KAmLzEUxZ/znlvn+AgvYTwLA2DMHORKtzGqZ3JS/qKmbBG4Ccsy
94bThZ0KChcYdlZZkZA/uHFpFtZ/m5CiABYYGFhRuyPykjKGtaKTMAKWtTut
C3icm6rJCpQjgM/nCZcl6VSRWwugOmwgpVQw+nWvBp+ge4nK2qBjjhFlxyrs
biGr3oC8Ku/yF0C+vAMPDKiZyobz/j2AZ0vOWIpc/6JnVD1I3wCrp4FXWgpF
AzvD3+8AbyFyB4PO+45sS4hdIxgoV2ThZAtCmJqigX0HaqwjTbgr3DnTb5G1
VMQeKCISjxns7tBFxnQSKNvD81OwdhiS0+84mjVyztbjZ6TfkWFHEknAkAVy
LxlH24NHhQGdslaowMBO9xgLxrD4TL9GxfULm0o6TkLtwJ/C9Qr5M3NxuGgL
tuM5PHMdzTzKixwy+8L9axOiBBFvhl0orQRdO0x3k77vGuXSYb+wggwsFUMK
cDXbBrmNc6KAnqyKZLLa7IRlIojIjx6cOEQpHIqYL903K8mGcs0wW5IGPjjg
bFVYc4txExT3e2LmKVwiNCQ2LERronCEYpUkGU2Xfwy2EaO2sc/8M1CpkOzr
+7/TN++BunPBfWkwBFM85KEPMLYRsIRPJpea89Ezwl2tYDiMRTjelL00aaYU
iUJaAfDnvKy9LRQth/aL1eoM45awDVFog3mPqgtwliJfJSHQ+CE2DrTPGE2s
MbEPJK7cdjD/b8nkm8NvnaiblGBCLUI31mB4sDOOWnXxABPJmxptJQZV3USY
8GU306eg7JNoFsZ8Uac2HdkvROXRhDB+5Xggw4KGDuNfEp1LVuviFPLVG2Jp
pU4XO9fHaXcXurUx+iAHkQaWCCymIyhB3qwIj2MQJ3AwEBA+u8vQRmLgt2nv
8PkpL+OONRhwIwOMckM5emDVrK92KnRnnYNAboVTPpvxnng4cC/2IP3B437E
nTH4iO9E+5jlwLDgHOOmo6Yl85aIcw1mhuJq6EJXzF4qCvPft1YMXG+2yYaV
BiXQk2gWcmQs9BLCpijp6dHh2dmnlh875hxXFCfHG1XWUjqLAU0m8Xn8MlLO
caKM2MdvPUKRZncqB3FZ03lO9Qzq0CJFJvynVTY3lYdfbbNeI25znhRvQwCf
elTOzAyxh5Jb5DHIE10inDKyJPRcSF9k3jjLZlVWxylTSq4C2kD9EbT3jlgv
BxVKTFWAqlugdhtEXVkIj9LguxdFUmRZZRufxIzC48OQvddhbG5TzfypVbRU
3kVggjKlIY0FzPDVX4/PXFwbPWsUttJyYAez5VVGLvyO7WHLjdFzFpEJRRXI
OifJk8WCUQGrRUteknrPaRC59f3Eq1KZ4nv3jeZKAlFSfliJNUhAd2dcdqI5
tfO+bafuM/fAg6ePHz58z0wnREPOcYQmHo/D+luahaf/K9rFuycPH+odk2AQ
vjspepDo2xDaS8uyPnziHEeljj8GMTgXEdc9KJmgtBg7OeREkWuIqxQTuqCo
YJiTcJ+KE89xajlJI+sRFSGAAb/FqBA4s4IlpOBGDWsRxkoNcXma7U0WSZBi
7iLsElqIYYkaVNC4xNz77xFMvJfwRGuI3TkwgTBx3WJdG5eSxaSL6VCU+XUD
2H8ziStC4IpxcPIpFMfP+t/wzfsxhyYZhVEFHYcUqLJNpByY25crgBIV+ILb
Q9FaMDK4Q5LVxuqDyxD5EkTN24eg26thgcgVIYq+zu5Ixy/i/KcIhOIZcKCQ
zL9XOISSsOrIujgxW3hO44PGXTeA3TdKpk9OISeWs+K2tNlArc0b3A1XvugN
Aj8CLt44z5pdLArYmQxLRugGMre1VGKVHXveFJOgYiZlm0VHyyRECctpJeph
KSqZY8TtHQZdqOhvTeYu2sUYbPGuwHXlukSdMYJZI1SsYPNdnA09tJBV15KR
8zWS5OmgzcJt4TwxR2zQd0pKG9Suar2kOoNcqstYEu6VRuftYBgkBAHnxpV+
Ykwxs1zYlyks7WoZsIveiQtKkhItj8K8d9gBCugQpDopYzhLziCXmzrq4sgD
KdFOSvA7kBNmd5E9tWXpPF+j05vUShAaIjlLg880sEoLOMDw1syF5A9vmxQq
EQG7a7AULAK9VANnsWArDX0HDuFSKao64S3I4gK0oF/1dWZVQC0S7pvoyAI8
8Kg7iXCfOL/v2AOTD58ETEK6q2pyx3uCJykG1nfLhizzR5gOtpU7qjzEC5UK
j4H7hzUiYDH3Z/oIxqDytbhAAqWU6hMAF4CKc+QbgLVsIRXBaHkXZWs7+cLX
evjpB0wIxHk00+cyrcw9EW9B95GttHO8k+lIWqgshGT4VOA+0BAgMeXClWVR
GhdVWSHohILbiJ8slyT4uj5+VlbbO9NOeDRQXljYDJN87LHN9z3uHQ8RaoCX
rM/cBBh+TAMe4o8ByF2+PXSu83aE2seubXC5OT9KxRVMZiya8Pgw3QPGdrx/
HIyOSMYD/douAl9tlQNGEP673nYyEOPmAZ7VgmYBlXG1q5/pFo0mPA7u47Ih
xxLh+6OZpNgRiXjImlk0b0yn9xit6Ocz/DeFp2yuY4DKQwWUOsKnoYPD6HXH
EPDUAehlF4xHcpXdzCuOFSqOGyFC6HwdDbuU5NrILGTegka3nx0yrnG9oQP7
qPBpnC1CDqA4i0ZWs4vOc0Q7lUwiPD0Fx+95/qZ2PlYxE1Z+68zRBKVrII6o
FwkV+e3HSfk6L3n2gFdbs2puDWdcqFL2XtblijjhF+sGCjs02cFFdPHIUbTz
TQbEpb5El0NLVN0mXpNFUDtcsagCSmyP6man7+9rEX36iw1p2v7EVZQ5Gl+q
RGwZPbLFvSd15AJ2wQ6xmk8goyAYiuVmIZCczlRSsbwpvjLGO8vbiJzlW5pR
ohDq4TBDlrtAL9Cw3aRe2Rzp60AybHNu2prLMB3oYO/RFZhilrgNsJqihLeI
h2NPZxLlKxQZN7d0F8tLlu7jlPgk2YVQZk9MJlX1zrxb4cPtLZjwJJWHlVyJ
SJX2BUV/+rorK4qvcYAcLgFETYGCvFmXPg9HS8GuNVfY4c1MaADAzqRsUKLB
1gL4Hw11SWl+FYXiJ3GB5NrX0g18wwfD4KBU1qJrtlpT/jroeLBYrG+Ip52L
wW0LWIYx04dcjYnaCuTRl9GI6yOpDs7TdazdCA26kjKP9DsQZ+Q4nDR4UqUo
a+5uoUJzUkqnompdACeJKzt7yvxCe2I9st1Z/R6woOxdcD0kHJbr2CNekwlF
B8zRgpAGuC2GI7if6CvYGOB89htO2hZW+7XU/267zcMyc1NhRJkpGmn5ZKpq
FPvLPgf/ZPZ8THxUNxEisq5bqpj4okrWGYp7sYLPQ/lQDqa0BFjS6MTOp1qA
SE9ppY9nz8bilPiZAvARriJXAbiW8ucDnNEnOSdkGbUAncq13QD22tJ0G3Y+
MYDpq4KLnhxV0FGVz5IyzyILgSbcqCgDjFVSOCQ1aiUF+REF94GClxiixQmQ
ncDZcL9KhsbnGswb9edNNLJqQL9OMXrKo2mcG0NAvGMnxldXV8D7TkHa+HFh
jzCBwd0EGHcQz/Hl02fo4Z2AID/UFwaD29Oja8ypA9xec0FM3Pri1XTXKEde
YSVgCfIB0GUmuEGRcrTlBlkW3SZsqGADJd8SqFDsNNVxDEZaKaU1mAbQWEN5
T6Dnxcv9J9iGMOJSn+a6nJdhA4Flw1rwkag3R9wJgQSY+P16RlUnZH8Uawgr
0AkrkFp/MwdQEZw1hjM1ZPaGuWVEAGQgQksezYbJzXOaUGUPXA0MJZkkF94C
bNVgxTXQA9sDDJZppaYXGx2wFIvCH5Sci2tAQtQ36pook3g92UsVgRtRmLBT
qDfYVjP/kNrIs5Bi9PzptIjLAPe1bUjrmCLeaCFmX0voMcpjYN8S67qLpjIE
bkruvPtlOxNcT8+EHNBxQQdFrnwDMkXdK+K2hj6d0HDJtlL6hqjcCNO44lMh
1SjjIRFL1BgUlyejjWqFki16efX6GLtNfECIa0q67AarlRQ75PYGlGrNYip9
arRXXFcYhdJ3hrlJf8QpjwkD0i2DJCXc3n1g+6RiIZNKibj7KSdEcY0dx65q
k1NEaMS7O1A/viqVpCDM9tezR58nRFaE8ihdwCEYToGU2K5Lyp2fi0PUS8vk
Inuc5jQU7CluBXoyrhyFQQDXdiNe4eWkUT1hO5y2ktZ5UxwM4+ctRbrW1Yab
KsXGR+kmqXFV6kuDsuEF0/crU/ZNcjYD9MVVfZh1rRGWKhrAUncDrXxUdgEO
+3AUMRFCNcYX7BL/0ClqjA71N9lKSDeOAS7ogrKQviLJMefgwQCRRAtgW6x1
j4l3hJqObqV6OGtBv7YIKynu5uxnRkHkKSB3Vw06DjUhgwoNz7TbzdqKDGGE
GbGskZtQscmSnVZXBCL1qYK5XfDXVYN6TeGDvPpNnGC4r0XtKolrZdUSQ83X
Kx0ZhTjyT+2jSZQzKKnZNkYj12arwUCKtUC3CBIc0xQxgKN8zUQUQnRmAp2u
rKU6gSyAU/KGS07YofmEaUR+aD8IgGd65OE9a7Q7GnI8tPsYALgvpuliTyGs
uTNPp3YAhpHYoyiqHvWqEfTp7hoxmZyU2wdPIcfissrgKQVuMfPNVuQ5QKgh
eiDf/j7sy8EAd2yBCzLpcgX2g9QnS5wI/D0ut43IQTbHRXF2k3CUpqK8OLsu
hGBzCYGPXZBLnL2hL81lMMQEv4r3JD64lgi4QLIYl0R4RN+LR3gYD0oGgCQA
EW9xnYSyJhFPggbZhpCEmzm7zGmdX0QHgRVk8xLYqX8b7OQhkpBGgj2Fmvhc
V8dAMpFgfAkmoTOHXN8ku0alt3wIht9XQo8MucDOlU0B/pRL104GxgqgGztG
VFzH1/AonN9JmWRa1twMLXaj5INLRIbv4WYJXlqqapW8BZAIxZNtltQqpU6+
Q6E0DcIvEvil3gvfZhfy0AtyLTDbBE4wTVIMDDFbjoYUkMjNeOaZf1fIS6wo
poQy9Kl8uKCD/cCud/+8kcTuhHfZzDkZG1htMKdCQAdjsQbLuLDZXBRFjh4Z
kgPxdOvCuiwCXOLkn+40TABMHFCNWcA1r+/m+TCUGEXZRQYBpQvZwy4Jq8l1
Ez3P8hvU9JbOF4AFirV3pR0S2xBxXHIDaLpZ1CN4C5rAHeiCBwV8TimYu6nf
SR5ie83olZInNZfuovnGU6iMQTKR49FMH8tTYtc/3h9As8GLaU2HbsckOCmy
FtmtLDIgW/muX7IkPArhFEqDhxwrdd0Ej4Rc5IkUNZrCJQhZEfEorI3KBWa5
ObRHlUbgzN+a8Uy/rUOhVYNEJhYRHQMjoXdI41TlCgCja4MV/ElFSmUtXY9I
Sb33ZdXkN6bY06P9p2M/kuyQi/feowkx7oCx8hVH1TgBSDk6bzkwdxoO+KA+
WwxTW86ubR0pMhK/YtAEoe9rgvBJryjXTC0Q6e2hvomrQMcSy8TuaJ+85Qpv
UyjXvOTsrZPA0wU3HEttGIWQmXUFCQ/RQDIA23Sppop5a5KKkJcGVw0GToM0
RJEPV2EyXESpcxqWG8oGPVh+xPiwA1K0pEe5BOnS+SZHiZRj7b/jGqrzQ9uY
u6aoqHDAuc4RegzHXHE8w/wAI9GtoCVBApVIquX4+MA3KvPrQRSJwQDXL5BC
cbkinpC6zgqOhSXTQhedfB6N55aFNNhcfLMtEc/A+8zppAE3MpspBv2US0jS
h8eXg/KMQY4NtH8IMfj1YqJ1Z8m5Q3WyiM/F5+YgHZ0pojytKBfXY0atc7NP
ulHEQsb1IuOItFLk4/D1g+C3s/FurCHuJmJL1NUfw+OshlQiSjmAnEJj+dwl
P1Eu8cLtAFLj6QubcFJGks7ZHVhEaQPARycZUHEll25ytICRUEmO+B42lYmz
Sxa4dAUvZUiJfIrRapAcLPJD9EGMAzuGGYU9jAFGeB93IngCHHrmcv+YWyn+
7ftgf6GxBPBWF9WFckEUKJyo0JPZjyY7Nwg7mr4NusvlEUR/yPBy+hv6g0Bi
2DwpdpGwgKt7IasESmRhuGqcTk1T3JDEpUkF1Y1xeoKNtKGzpqphEWHnTylx
h8BwrX3BfSp0xhP1K7VNFbVYTXwEiex1zK0hqh80yK5z1kh9kQIWOk+0F2Q1
VBbRuSNxmyjAujmdWeNCkE5Du4JGeLo7dIY73by0xx4+KVJ+eGSSlAw6lpwj
QX5mUnfUIKpGUfdY/+/b5tx0SqTdCjONwhSEwZtd/ly8FQhpMKAj5+MpnHKc
16McCcZVurLidrPoLBcfjfXKc43Ht8Q74CwRgYpY6Yf0h9Q3pXNUyCJUyec8
Q7aEKL6w7V83d4iHJ6540ISqJIZB5OFZ4izgyHZD6UPflDjhpoF0sdERUBMu
6yKQ1VKEllTFHLbirizI3SuI3D13AoNum/ctKGWKyDL2piOqcGa97ekIMtDH
JbZBAuGIk0Ta6FBQSdpwNwdGthGnMX5CAIoxeY4Y0UFQfMhgnGykGE7pABWB
OSa5k+O0nS8ElfTOJhiQQjlnJx0psT7UusFFmAN7CNpSTiQ4PU/aS+nCqAuc
ss18GIocErcJPv6wre8imQrjG/gdi2tstCSNwS8O7oKfMUfxH5btHUa9lu70
GRtOOSLUuRUGj+q7qKD22pSt5rpBTJCNXeY4xaykO9C0A0K6Nb64o8MSC9he
JYe3DdJwiyxH/wkX7HpKWUpaExtvrLsMIQAuMAudHMj7l6evRg/HgFl/pZ8J
B0b16opsMC9H1Zl0KoG+XDfNwoS2IHZerNhJ5yUNTtnCcqcWSxyE0YFcFaAF
MC4hZyC1QZGFYSXMfSvE5ypOAyWP+Jy5zzD4mmB4npUC6g7iD/RH4PkGoXmo
HbEuBCwNXKTVQC8PJ+eVlxTsIVE4QZqoOMrl1Fy+B+utpogQ3HGL3r+iEyHy
jSs3UWmDKwVVbBOH2OlWAFTY2YeVXHQKQ2icj7uyLeNxPOtjgMWV+uwzbl/l
oAEeHXsCPkjTfvbZgddVUkYz0aA/MmrFlv6NnJNJOdeH7I2SNMx4z3mhGPfC
E+0M7WEuUfPklB3gb5wdoR7yZRnoSoYdp/aLx5g4vKlCo+HeMUcTz1Cf8GHA
egQ7Otbn7mSt6EZNxy5j/C00ZFzx6SxMST79A/589kypNyajqNdBKJMN/TuD
hgIXmJMjk1E/Cxng9gHFVEQYOafhQgA0jQWeU3r4wj1ko3Itbmakyttsq4My
PgXW+bj/DMWATHi5I9OBft0E3/gyXbonlsUWH+RTMkbnXNUPtPwBi1RgxVi3
8it0IpGU4kYvYAFyucxha9IeG39wUDgh6Cf9xh138ZM+l1bZwQ/c5ibjPoGh
pvSj3S/Rb/Gv6c/2FzSUfw7/PPS/0Ydn4XwarOabNusxfzEgCw3F/Yd+gH28
ny0lfni8s2PwvqG45+hfMVS0wEfT/UfP0wW+8yfcDMi+tRHxUO50nWSoC3fM
zig6Y2e8c1bqQprFufYCecYkR5rCdYRfGT1JTUsqR9Thg5zlD3M6rB2POeDi
OnKQPWEy/6oDj0ANCePKSMwhn9LZZi16bgU16GE7j2u72z6dRinheRjknRyd
KumH9ba+iqU7ddOjRBqrPT6TRiX6y3XnR0e/+cOpAfmTLuPCpEQX+OPeHj3D
6hv5rqXvEOfKicpU/kD14ElYebBjrIEmCs9ioDMZDPcq+BaPjGMtrSiUTKKi
6BPgUBt5HOKfZYmoHEuUu4xLALCgqwM2oRN9zsky2O978JPIV+N5Si4VCARC
A+hJVukPb63dV3LUGCwI0YbtpTsmPRpwMaR8G3E1F/i5cVzWpecICHvM7BVh
yLfnM3ENuVOOebMKll9IXN1LiSkEr7tcLB8RwF2YdHqCD7SXeMYG1utR/EhS
KcSvlPGSit4uWy6Z9nvnIrfAjXvuRF0OEZN+h6X5hJPvpafZ5BWdDmnq2xKM
Dj9OA+AJTyklgs6H60qM3m2LVHt6TRQ9jY4dOhxy/EJOm18ZORKMDzed0DEf
hpqWsmDmpM4gcw9NxkJC+6Nhh726M07O7LoxIHNpXJXEWCTA/hvtzk2Vgei0
6HuYCgEl1W8s8DzF4SaTyMgoTnMRiU5EbrYEErvXe+fLc1dkdNQZnk6N1Jbd
RB5JwqH4cH8mVRAid9LcrZEOgsKdgA3wtCfSwUigC2oJvgnI9XpyEAvyLykg
FMY1+2CasCqNXvJAQEedA/uIPnr69BG2fe6EYKCkB4rHWRMpkNoLI/PcX1XN
nKoiLrGsyb2spODnRsBLWoX/4BHEH2I48Yfp8CccmcjnWf6k/3729vhEnx2+
OdmJbP6p0aU/GUdnwt2HUH7j6OS4uMAF79Ql/Lf/FdfFeyrSskHFzl1JAVJm
BpHHKJ0DG5++7+RTsQTlil+FEBUA+ViKldozehHLrtcM0GtPyh8edEVtx1Gb
Pu3vW+mG4COEQYJOQXPRwezpktmtucs2eA295+TeK/Tor/sPHj189HTMtUnR
EcVw7+U3p1dHX+vR7OjrB7PXp+PhMKUNI5FIzy5PHszO3nFgMkSQuNoVuYZL
4YBqsAHsZ0blMkShKHYBOpOzeBTHLed9wA5oAg9gA4w+BMHdTPSbrL0BNAVY
5w6c96PrFri/hOecVOAANd1E/+P/VNmib/Wr/h//bwWztmSlz7O+Ut80PXor
E/1li7ccl/kNfflNhv6q/kuPB8/jtTCJ/Ea/Mbc/mpsJVsDrb0Ad1vamnKi/
6jelNRgZBoZYwDDv5vOyvsGZdbD+7wAYmpsbqpD4C74ZBl9Y8xXQhz45K/Om
ykr12mwAHcOjX5WgKtcgf1+V4DfDdxN5k823BlTcVVNv9OuSp6/99C/AI6vV
cVZvqvLO3XBLK/oOJkJvpbnM+6LAsMY//hsWo/8Gwndj5L0QmHenPTkJnbXU
9R9lR085kQLzR8a7dKm9D5+4tnnio7eDJA3q639HoHDlXiVz1hdLahVICp2i
4/A5n1jTSyxCNo8OGgiReIqK3GV8VASW+kru1N2dJnXpiJDBayYsB315eIog
+iyeO43Ux3qoZ4UDPPPM4omHhcno8ajC+6XwulFd9CKNPXwDx150fNQoC1Uz
2H5AIeaxi37A5fZ6TyWX86rHAjCl1Tzn3DU2VMMEQqofowrR2xc6PZIGAlMS
mLH44p6YNHQsjqX3htDJCBiLlaxuSN02ad/OwnV2GdJSXBjNsh2nkvyRAljr
6gat/OtyxDhTYEiN3OtqkCYXkh7zx5pzotwad2tRFvKiHloOHheO3PQjx/al
s4rgA785hZP5dLOcl5xW2IXD1HH/sGpg5eIQLi0KHDQFaZhSkht32EybxcKP
Hb/BhJ5D5xGFNVPcPLyjhN+SFE5kopdrCNXd7diVrDh8Fifki7At/gwJjgz7
PffR7oBSsGdP3lMiMrzgzv2oxJQm8iW/BorfbTLRd0awn3vJCd/Mxw8i8d0b
fuTlE3TGPxbJrMvOlxnQh1LCNPdlFVh/yOKEZZSUsG3m3IvHPfAI9+RUYRUV
FaHUspfgWpSXrQSqfDbp6vWxw0D0/pFQCU0TquidBeFy30oVjosKhV/cWBYd
gOKydAjjsiBVI34nS9jJse/kokRxpvnAtRXyZHh2WoIofBte0SJqSO0+FLms
PQciEf2k2x5fCuEzW25Gaveq0uNUOH9iu2qzxZq+hE/KwnHdpk30iZyDFLcK
4grhUdJraN2SkDzvajqwdPiOHU54RUctiOJB8CDKRd7IQAK7Xff1i9pkQgXI
3/fgOlbUV+JfsuJbZ8wPwDoiIqGoTh5DWR/f+k81UeyERZXY4SxGeSfWEg9B
ZgonbwnBmQ4q5uKDLmb6cAlXTyR8QMxxFIfrXUkhsVibYW1D2O9Eg2dDtlcx
28lbN0pLb06gc4czerOPYwVOw/9GZhiyQRTrThmBbUjUrDDUYRLxkmJfF/OK
X7yDxdPJW3mA3fBkkw8f/ng6PZ5Fb+uC/wdtPQ2HuSD2oHoBzBKxX86zxZPJ
cOeHDnhlFswe8t4gzLsyoD3iuXwN/NPgAV0ucoW+RbHDkQDk/dnHvi5SfaFf
w4OprcuQ+0IhbTZ4Hz3OCxzn9OTylQDpXUN9oQ8LDAMsewA5VekOXzJxNE2P
aJCFMQVCxzHedYaFVpQvPa5tUWJQpMIddPd89CSfDyfpzPoIrsAdOnDhFHAf
qF7IOf2fU6FVWNRgXm/Xv2tez9LRXoEUt2GQHQ/a9ZXQ5jc++ikOcvJPb/sT
2VXv1ML/7nGWv6Dorg9uueQbBaopFIOXHFOkWr7cGSz+AsDFjaFOcT40kqMf
Lub4+5bzmBhE4uw7jylyL/fCCy/Yt3cHgfrXh9ExrKLz130L2Kb4fdN65Hd6
vklcRCIZ77uTGPzoUs5Z7rifml/ZSZWt7nVK6XzqkgknqQsnBHLG/kdPc/++
Mfx7CPgCKrBwdcYtZyoa2fMRHZ1MMc8ez9Ai1k4LLcbMKNyfENoFff6TvoY/
emuFI3eWWRArod4skmvTkhtw+W/oyqPKZPW0X09+h458yMvHcw0a1/+cFVxO
PAuj+DdC7hgKPkm5AmWvlRIf8Ua7bMOwhcqB3EXkqfPZ9nyi2G9/IO3vGz5S
XV9spl0zvWhdC5XE8ONTQi8uLriW0M2BSvYFKSwqgENchO91CLOMh1S0kQAc
9OXF36Z8ild8CDkemZLdSiUhukHCJhcXKXeL/y6RoN+66IesEjjRK8ca0Agz
9T8bltBy5HkAAA== version of
   the zone.

Current B:
   The basic idea was to augment
   the traditional "pull" mechanism (a periodic SOA query) with a "push"
   mechanism (a Notify) for a common case that was otherwise very
   inefficient (due to either slow convergence or wasteful and overly
   frequent scanning of the primary for changes).

Current C:
   This
   opens up the possibility of having an arbitrary party (e.g., a side-
   car service) send the notifications, enabling this functionality even
   before the emergence of native support in nameserver software.
-->

</rfc>