Diff: rfc9664.original.xml

	rfc9664.original.xml	rfc9664.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<rfc category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease
	-08" ipr="trust200902"
	xmlns:xi="http://www.w3.org/2001/XInclude" version="3"
	scripts="Common,Latin" sortRefs="false" consensus="true"
	symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
	<front>
	<title abbrev='Dynamic DNS Update Leases'>
	An EDNS(0) option to negotiate Leases on DNS Updates
	</title>


	<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>	<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
		ETF" docName="draft-ietf-dnssd-update-lease-08" number="9664" updates="" obsolet
		es="" ipr="trust200902" version="3" sortRefs="false" consensus="true" symRefs="t
		rue" tocDepth="3" tocInclude="true" xml:lang="en">

		<front>
		<title abbrev='Dynamic DNS Update Leases'>An EDNS(0) Option to Negotiate Lea
		ses on DNS Updates</title>
		<seriesInfo name="RFC" value="9664"/>
		<author initials='S.' surname='Cheshire' fullname='Stuart Cheshire'>
	<organization>Apple Inc.</organization>	<organization>Apple Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>One Apple Park Way</street>	<street>One Apple Park Way</street>
	<city>Cupertino</city>	<city>Cupertino</city>

	<region>California</region>	<region>CA</region>
	<code>95014</code>	<code>95014</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 408 974 3207</phone>	<phone>+1 408 974 3207</phone>
	<email>cheshire@apple.com</email>	<email>cheshire@apple.com</email>
	</address>	</address>
	</author>	</author>


	<author initials="T" surname="Lemon" fullname="Ted Lemon">	<author initials="T." surname="Lemon" fullname="Ted Lemon">
	<organization>Apple Inc</organization>	<organization>Apple Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>P.O. Box 958</street>	<street>P.O. Box 958</street>
	<city>Brattleboro</city>	<city>Brattleboro</city>

	<region>Vermont</region>	<region>VT</region>
	<country>United States of America</country>	<country>United States of America</country>
	<code>05302</code>	<code>05302</code>
	</postal>	</postal>
	<email>mellon@fugue.com</email>	<email>mellon@fugue.com</email>
	</address>	</address>
	</author>	</author>


	<date>2023-07-07</date>	<date month="October" year="2024"/>
	<area>Internet</area>	<area>INT</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>dnssd</workgroup>
	<keyword>DNS Update</keyword>	<keyword>DNS Update</keyword>
	<abstract>	<abstract>

	<t>This document describes an EDNS(0) option that can be used by DNS Updat	<t>This document describes an Extension Mechanisms for DNS (EDNS(0)) optio
	e requestors and	n that can be used by DNS
	DNS servers to include a lease lifetime in a DNS Update or response, allow	Update requestors and DNS servers to include a lease lifetime in a DNS
	ing a server to garbage collect stale	Update or response, allowing a server to garbage collect stale resource
	resource records that have been added by DNS Updates</t>	records that have been added by DNS Updates.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	dnssd-wg.github.io/draft-ietf-dnssd-update-lease/draft-ietf-dnssd-update-lease.h
	tml"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	DNSSD Working Group mailing list (<eref target="mailto:dnssd@ietf.org"/>
	),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/dnssd/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dnssd/"
	/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease"
	/>.</t>
	</note>
	</front>	</front>

	<middle>	<middle>

	<section>	<section>
	<name>Introduction</name>	<name>Introduction</name>

	<t>Dynamic DNS Update <xref target="RFC2136"/> allows for a mapping from a persistent	<t>A Dynamic DNS Update <xref target="RFC2136"/> allows for a mapping from a persistent
	hostname to a dynamic IP address. This capability is particularly	hostname to a dynamic IP address. This capability is particularly
	beneficial to mobile hosts, whose IP address may frequently change	beneficial to mobile hosts, whose IP address may frequently change
	with location. However, the mobile nature of such hosts often means	with location. However, the mobile nature of such hosts often means
	that dynamically updated resource records are not properly	that dynamically updated resource records are not properly

	deleted. Consider, for instance, a mobile user who publishes address	deleted. For instance, consider a mobile user who publishes address
	records via dynamic update. If this user moves	records via dynamic update. If this user moves
	their laptop out of range of the Wi-Fi access point,	their laptop out of range of the Wi-Fi access point,
	the address record containing stale information	the address record containing stale information
	may remain on the server indefinitely.	may remain on the server indefinitely.

	An extension to Dynamic Update is	Thus, an extension to Dynamic Update is
	thus required to tell the server to automatically delete resource	required to tell the server to automatically delete resource
	records if they are not refreshed after a period of time.</t>	records if they are not refreshed after a period of time.</t>
	</section>	</section>

	<section>	<section>


	<name>Conventions and Terminology Used in this Document</name>	<name>Conventions and Terminology Used in This Document</name>
	<t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"MAY", and "OPTIONAL" in this document are to be interpreted as described	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	in BCP 14 <xref target="RFC2119"/>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<xref target="RFC8174"/> when, and only when, they appear in all capital	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	s, as shown here.	be interpreted as
	</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

	<section>	<section>
	<name>Abbreviations</name>	<name>Abbreviations</name>
	<dl>	<dl>

	<dt>DNS-SD</dt><dd>DNS-based service discovery <xref target="RFC6763"/>	<dt>DNS-SD:</dt><dd>DNS-based Service Discovery <xref target="RFC6763"/
	</dd>	></dd>
	<dt>EDNS(0)</dt><dd>Extension Mechanisms for DNS, version 0 <xref targe	<dt>EDNS(0):</dt><dd>Extension Mechanisms for DNS <xref target="RFC6891
	t="RFC6891"/></dd>	"/></dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Mechanisms</name>	<name>Mechanisms</name>
	<t>The EDNS(0) Update Lease option is included in a standard DNS Update me ssage <xref	<t>The EDNS(0) Update Lease option is included in a standard DNS Update me ssage <xref
	target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t>	target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t>
	</section>	</section>

	<section anchor="update">	<section anchor="update">
	<name>Update Message Format</name>	<name>Update Message Format</name>


		<!--[rfced] We had two related questions about these sentences:

		a) We were unsure if some singular/plural changes should be made with
		regard to "Leases". See suggested text below.

		b) Should the use of "DNS" be made uniform? That is, "Dynamic DNS
		Update Leases Requests and Responses" or "Dynamic Update Leases
		Requests and Responses"?

		Original 1:

		Dynamic DNS Update Leases Requests and Responses are formatted as
		standard DNS Dynamic Update messages [RFC2136]. This update MUST
		include the EDNS(0) OPT RR, as described in [RFC6891].

		Perhaps ("Leases" becomes "Lease" and "This update" becomes "These
		updates"):

		Dynamic DNS Update Lease Requests and Responses are formatted as
		standard DNS Dynamic Update messages [RFC2136]. These updates MUST
		include the EDNS(0) OPT RR, as described in [RFC6891].

		or perhaps ("Leases" becomes "Lease" and "These updates" becomes "This
		new format"):

		Dynamic DNS Update Lease Requests and Responses are formatted as
		standard DNS Dynamic Update messages [RFC2136]. This new format
		MUST include the EDNS(0) OPT RR, as described in [RFC6891].

		Original 2:

		Refresh messages are formatted like Dynamic Update Leases Requests
		and Responses...

		Perhaps ("Leases" becomes "Lease"):

		Refresh messages are formatted like Dynamic Update Lease Requests
		and Responses...

		-->

	<t>	<t>
	Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic	Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic

	Update messages <xref target="RFC2136"/>. This update MUST include the EDN	Update messages <xref target="RFC2136"/>. This update <bcp14>MUST</bcp14>
	S(0) OPT RR, as	include the EDNS(0) OPT RR, as
	described in <xref target="RFC6891"/>. This OPT RR MUST include an EDNS(0	described in <xref target="RFC6891"/>. This OPT RR <bcp14>MUST</bcp14> in
	) Option as shown	clude an EDNS(0) Option as shown
	below.</t>	below.</t>

	<t>The Update Lease EDNS(0) option is formatted as follows:</t>	<t>The Update Lease EDNS(0) option is formatted as follows:</t>


	<figure align="center" anchor="lease_opt" suppress-title="true"><artwork align="	<table anchor="lease_opt">
	center"><![CDATA[	<name></name>
	Field Name Field Type Description	<thead>
	OPTION-CODE u_int16_t UPDATE-LEASE (2)	<tr>
	OPTION-LENGTH u_int16_t 4 or 8	<th>Field Name</th>
	LEASE u_int32_t desired lease (request) or	<th>Field Type</th>
	granted lease (response), in seconds	<th>Description</th>
	KEY-LEASE u_int32_t optional desired (or granted)	</tr>
	lease for KEY records, in seconds	</thead>
	]]></artwork></figure>	<tbody>
		<tr>
		<td>OPTION-CODE</td>
		<td>u_int16_t</td>

		<td>UPDATE-LEASE (2)</td>
		</tr>
		<tr>
		<td>OPTION-LENGTH</td>
		<td>u_int16_t</td>
		<td>4 or 8</td>
		</tr>
		<tr>
		<td>LEASE</td>
		<td>u_int32_t</td>
		<td>desired lease (request) or granted lease (response), in seconds</td>
		</tr>
		<tr>
		<td>KEY-LEASE</td>
		<td>u_int32_t</td>
		<td>optional desired (or granted) lease for KEY records, in seconds</td>
		</tr>
		</tbody>
		</table>

	<t>Update Requests contain, in the LEASE field of the OPT RDATA, an	<t>Update Requests contain, in the LEASE field of the OPT RDATA, an
	unsigned 32-bit integer indicating the lease lifetime, in seconds, desired	unsigned 32-bit integer indicating the lease lifetime, in seconds, desired
	by the requestor, represented in network (big-endian) byte order.	by the requestor, represented in network (big-endian) byte order.
	In Update Responses, this field contains the actual	In Update Responses, this field contains the actual
	lease granted by the server. The lease granted by the	lease granted by the server. The lease granted by the
	server may be less than, greater than, or equal to the value	server may be less than, greater than, or equal to the value
	requested by the requestor.</t>	requested by the requestor.</t>


	<t>There are two variants of the EDNS(0) UPDATE-LEASE option,	<t>There are two variants of the EDNS(0) UPDATE-LEASE option:
	the basic (4-byte) variant and the extended (8-byte) variant.</t>	the basic (4-byte) variant and the extended (8-byte) variant.</t>

	<t>In the basic (4-byte) variant, the LEASE indicated in the	<t>In the basic (4-byte) variant, the LEASE indicated in the
	Update Lease option applies to all resource records in the Update section. </t>	Update Lease option applies to all resource records in the Update section. </t>

	<t>In the extended (8-byte) variant, the Update Lease communicates two lea se lifetimes.	<t>In the extended (8-byte) variant, the Update Lease communicates two lea se lifetimes.
	The LEASE indicated in the Update Lease option applies to all resource rec ords in the	The LEASE indicated in the Update Lease option applies to all resource rec ords in the

	Update section except for KEY records. The KEY-LEASE indicated in the U pdate Lease	Update section <em>except</em> for KEY records. The KEY-LEASE indicated i n the Update Lease
	option applies to KEY records in the Update section.</t>	option applies to KEY records in the Update section.</t>


	<t>The reason the KEY record can be given a special lease time is that thi	<t>The KEY record can be given a special lease time because this record is
	s record is used	used
	in the DNS-SD Service Registration Protocol <xref target="I-D.ietf-dnssd-s	in the DNS-SD Service Registration Protocol <xref target="RFC9665"/> to re
	rp"/> to reserve	serve
	a name (or names) when the service is not present.</t>	a name (or names) when the service is not present.</t>

	<t>In the case of a KEY record and some other record, obviously the KEY LE ASE applies to	<t>In the case of a KEY record and some other record, obviously the KEY LE ASE applies to
	the key, and the LEASE applies to the other record. If more than one recor d that is not	the key, and the LEASE applies to the other record. If more than one recor d that is not
	a KEY record is added by the update, the LEASE (not the KEY LEASE) is appl ied to all such	a KEY record is added by the update, the LEASE (not the KEY LEASE) is appl ied to all such
	records. Records that are removed are permanently removed.</t>	records. Records that are removed are permanently removed.</t>

	<section anchor="update-refresh">	<section anchor="update-refresh">

	<name>Types of DNS Update Request messages</name>	<name>Types of DNS Update Request Messages</name>
	<t>This document describes two types of updates: Registrations and Refres	<t>This document describes two types of updates: Registrations and
	hes. A	Refreshes. A Registration is a DNS Update Request that is intended to
	Registration is a DNS Update Request that is intended to add information	add information not already present on the DNS server. A Refresh is
	not already	intended simply to renew the lease on a previous Registration without
	present on the DNS server. A Refresh is intended simply to renew the leas	changing anything. Both messages are DNS Update messages, so the term
	e on a previous	"DNS Update message" is to specify behavior that is the same for both
	Registration without changing anything. Both messages are DNS Update mess	types of DNS Update messages.</t>
	ages, so the
	term "DNS Update message" is to specify behavior that is the same for bot
	h types of
	DNS Update message.</t>


	<t>In some cases it may be necessary to add new information without remov	<t>In some cases, it may be necessary to add new information without
	ing old information.	removing old information. For the purpose of this document, such
	For the purpose of this document, such messages are referred to as Regist	messages are Registrations, although in effect, they
	rations, although	may also refresh whatever information is unchanged from a previous
	in effect they may also refresh whatever information is unchanged from a	registration.</t>
	previous registration.</t>
	</section>	</section>

	<section anchor="requestor">	<section anchor="requestor">
	<name>Requestor Behavior</name>	<name>Requestor Behavior</name>

	<t>DNS Update requestors MUST send an Update Lease option with any DNS Up	<t>DNS Update requestors <bcp14>MUST</bcp14> send an Update Lease
	date that is	option with any DNS Update that is not intended to be present
	not intended to be present indefinitely. The Update Lease option SHOULD s	indefinitely. The Update Lease option <bcp14>SHOULD</bcp14> specify a
	pecify a time	time interval that is no shorter than 1800 seconds (30
	interval that is no shorter than 1800 seconds (30 minutes). Requestors MA	minutes). Requestors <bcp14>MAY</bcp14> specify a shorter lease if
	Y specify a	they anticipate that the records being updated will change in less than
	shorter lease if they anticipate that the records being updated will chan	30 minutes. Requestors that expect the updated records to be
	ge sooner than	relatively static <bcp14>SHOULD</bcp14> request appropriately longer
	30 minutes. Requestors that expect the updated records to be relatively	leases.</t>
	static SHOULD
	request appropriately longer leases.</t>


	<t>If the DNS response received by the requestor does not include an Upda	<t>If the DNS response received by the requestor does not include an
	te Lease option,	Update Lease option, this is an indication that the DNS server does
	this is an indication that the DNS server does not support the Update Lea	not support the Update Lease option. In this case, the requestor
	se option. The	<bcp14>SHOULD</bcp14> continue sending Refresh messages (see below) as
	requestor SHOULD in this case continue sending Refresh messages (see belo	if the server had returned an identical update lease option in its
	w) as if the	response.</t>
	server had returned an identical update lease option in its response.</t>


	<t>If the DNS response does include an Update Lease option, the requestor	<t>If the DNS response does include an Update Lease option, the
	MUST use the	requestor <bcp14>MUST</bcp14> use the interval or intervals returned in t
	interval(s) returned in this option when determining when to send Refresh	his
	messages. This	option when determining when to send Refresh messages. This is true
	is true both if the interval(s) returned by the server are shorter and if	both if the interval or intervals returned by the server are shorter and
	they are	if they
	longer.</t>	are longer.</t>


	<t>When sending a Registration, the requestor MUST delay the initial tran	<t>When sending a Registration, the requestor <bcp14>MUST</bcp14>
	smission by a	delay the initial transmission by a random amount of time across the
	random amount of time across the range of 0-3000 milliseconds, with a gra	range of 0-3000 milliseconds, with a granularity of no more than 10
	nularity of no	milliseconds. This prevents synchronization of multiple devices of the
	more than 10 milliseconds. This prevents synchronization of multiple devi	same type at a site upon recovery from a power failure. This
	ces of the same	requirement applies only to the initial Registration on startup; since
	type at a site upon recovery from a power failure. This requirement appli	Refreshes include a random factor as well, any synchronization that
	es only to the	occurs after such an event should quickly randomize.</t>
	initial Registration on startup: since Refreshes include a random factor
	as well, any
	synchronization that occurs after such an event should quickly randomize.
	</t>


	<t>Note: the requirement for 10ms granularity is a scheduling requirement	<t>Note: the 10 ms granularity is a scheduling requirement intended to
	intended to	result in an even spread of requests so that every request doesn't come a
	result in an even spread of requests, so that every request doesn't come	n exact number
	an exact number
	of seconds after startup. This requirement should not be construed as req uiring anything	of seconds after startup. This requirement should not be construed as req uiring anything
	of the link layer on which the packet is transmitted: the link layer may well impose its	of the link layer on which the packet is transmitted: the link layer may well impose its
	own constraints on the timing at which a message is sent, and this docume nt does not	own constraints on the timing at which a message is sent, and this docume nt does not
	claim to override such constraints.</t>	claim to override such constraints.</t>


	<t>Note: the reason for the 3000ms (three second) random interval as oppo sed to some	<t>Note: the use of a 3000 ms (3-second) random interval as opposed to so me
	other random interval is to allow for enough time to meaningfully spread the load when	other random interval is to allow for enough time to meaningfully spread the load when
	many devices renew at once, without delaying so long that the delay in di scovery of	many devices renew at once, without delaying so long that the delay in di scovery of

	devices becomes obvious to an end user. A 3-second random delay means tha	devices becomes obvious to an end user. A 3-second random delay means tha
	t if there are	t if there are,
	for example 100 devices, and the random number generator spread is even,	for example, 100 devices, and the random number generator spread is even,
	we would have	we would have
	one renewal every 30ms. In practice, on relatively constrained devices a	one renewal every 30 ms. In practice, on relatively constrained devices
	cting as SRP	acting as Service Registration Protocol (SRP)
	servers, we are seeing the processing time for an SRP registration taking on the order	servers, we are seeing the processing time for an SRP registration taking on the order

	of 7ms, so this seems reasonable.</t>	of 7 ms, so this seems reasonable.</t>
	</section>	</section>

	<section>	<section>
	<name>Server Behavior</name>	<name>Server Behavior</name>

	<t>DNS Servers implementing the Update Lease option MUST include an Updat
	e Lease option	<!--[rfced] Might the following update be less redundant than the
	in response to any successful DNS Update (RCODE=0) that includes an Updat	original?
	e Lease option.
	Servers MAY return different lease interval(s) than specified by the requ	Original:
	estor, granting	DNS Servers implementing the Update Lease option MUST include an
	relatively longer or shorter leases to reduce network traffic due to Refr	Update Lease option in response to any successful DNS Update
	eshes, or	(RCODE=0) that includes an Update Lease option.
	reduce stale data, respectively.</t>
	<t>Note that both the 4-byte and 8-byte variant are valid on both client	Perhaps:
	s and servers, but	DNS servers MUST include an Update Lease option in response to any
	clients and servers may exist that do not support the newer 8-byte varian	successful DNS Update (RCODE=0) that also includes one.
	t. Therefore,	-->
	clients and servers that do support this variant must account for the pos
	sibility that	<t>DNS servers implementing the Update Lease option
	the server with which they are communicating does not.</t>	<bcp14>MUST</bcp14> include an Update Lease option in response to any
	<t>A client that receives a 4-byte variant from a server when it sent an	successful DNS Update (RCODE=0) that includes an Update Lease option.
	8-byte variant	Servers <bcp14>MAY</bcp14> return a different lease interval or intervals
	MUST treat the 4-byte variant as specifying both the lease time and the k	than
	ey lease time.	specified by the requestor, granting relatively longer or shorter
	A server that supports the 8-byte variant MUST treat the 4-byte variant a	leases to reduce network traffic due to Refreshes or to reduce stale
	s specifying	data, respectively.</t>
	both the lease time and the key lease time. When a server receives a 4-by
	te variant, it	<t>Note that both the 4-byte and 8-byte variant are valid on
	MUST respond with a 4-byte variant. In this case the key and the other re	both clients and servers, but clients and servers may exist that do
	cords expire at	not support the newer 8-byte variant. Therefore, clients and servers
	the same time.</t>	that do support this variant must account for the possibility that the
		server with which they are communicating does not.</t>
		<t>A client that receives a 4-byte variant from a server when it sent
		an 8-byte variant <bcp14>MUST</bcp14> treat the 4-byte variant as
		specifying both the lease time and the key lease time. A server that
		supports the 8-byte variant <bcp14>MUST</bcp14> treat the 4-byte
		variant as specifying both the lease time and the key lease time. When
		a server receives a 4-byte variant, it <bcp14>MUST</bcp14> respond
		with a 4-byte variant. In this case, the key and the other records
		expire at the same time.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="refresh">	<section anchor="refresh">
	<name>Refresh Messages</name>	<name>Refresh Messages</name>

	<t>A Refresh message is a DNS Update message that is sent to the server af ter an initial	<t>A Refresh message is a DNS Update message that is sent to the server af ter an initial

	DNS Update has been sent, in order to prevent the update's records from be ing garbage	DNS Update has been sent in order to prevent the update's records from bei ng garbage
	collected.</t>	collected.</t>

	<section>	<section>
	<name>Refresh Message Format</name>	<name>Refresh Message Format</name>


	<t>Refresh messages are formatted like Dynamic Update Leases Requests an	<t>Refresh messages are formatted like Dynamic Update Leases Requests
	d Responses (see	and Responses (see <xref target="update" format="default"/>). The Refres
	<xref target="update"/> "Update Message Format"). The Refresh message is	h message is constructed
	constructed with the assumption that the result of the previous Registra	with the assumption that the result of the previous Registration or
	tion or Refresh is	Refresh is still in effect. In the case that
	still in effect. The Refresh message will, in the case that the records	the records added in a previous update were for some reason garbage
	added in a	collected, the Refresh message will result in those records being added
	previous update were for some reason garbage collected, result in those	again.</t>
	records being
	added again.</t>


	<t>The Refresh message SHOULD NOT include any update prerequisites that w	<t>The Refresh message <bcp14>SHOULD NOT</bcp14> include any update
	ould fail if	prerequisites that would fail if the requestor's previous Registration
	the requestor's previous Registration or Refresh is still in effect. It a	or Refresh is still in effect. It also <bcp14>SHOULD NOT</bcp14>
	lso SHOULD NOT	include prerequisites that would fail if the records affected by the
	include prerequisites that would fail if the records affected by the prev	previous Registration or Refresh are no longer present; that is, the
	ious Registration or	Refresh should also work as a Registration. There may be cases where
	Refresh are no longer present--that is, the Refresh should also work as a	this is not possible; in which case, the response from the server can
	Registration.	be used to determine how to proceed when the Refresh fails.</t>
	There may be cases where this is not possible, in which case the response
	from
	the server can be used to determine how to proceed when the Refresh fails
	.</t>

	<t>An update message that changes the server state resulting from a previ ous Refresh or	<t>An update message that changes the server state resulting from a previ ous Refresh or
	Registration is a Registration, not a Refresh.</t>	Registration is a Registration, not a Refresh.</t>

	<t>The Update Lease option in a Refresh message contains the desired new lease for	<t>The Update Lease option in a Refresh message contains the desired new lease for
	Requests, and the actual granted lease for Responses. The LEASE interval indicated in the	Requests, and the actual granted lease for Responses. The LEASE interval indicated in the
	Update Lease option applies to all resource records in the Update section of the Refresh	Update Lease option applies to all resource records in the Update section of the Refresh
	request, except that if a KEY-LEASE interval is included as well, that in terval applies	request, except that if a KEY-LEASE interval is included as well, that in terval applies
	to any KEY records included in the Update section.</t>	to any KEY records included in the Update section.</t>
	</section>	</section>

	<section>	<section>
	<name>Requestor Behavior</name>	<name>Requestor Behavior</name>


	<t>A requestor that intends that its records from a previous update, whet	<t>A requestor that intends for its records from a previous Registration
	her a Registration	or Refresh to remain active <bcp14>MUST</bcp14>
	or a Refresh, remain active, MUST send a Refresh message before the lease	send a Refresh message before the lease elapses; otherwise, the records
	elapses, or else the records
	will be removed by the server.</t>	will be removed by the server.</t>


	<t>In order to prevent records expiring, requestors MUST refresh resource	<!--[rfced] May we update this text as follows to reduce redundancy?
	records before they
	expire. At the time of registration, the client computes an interval that
	is 80% of the lease
	time plus a random offset between 0 and 5% of the lease time. The random
	offset is to prevent
	refreshes from being synchronized. When this interval has expired, the cl
	ient MUST refresh the
	message if the data in the initial Registration should continue to be adv
	ertised.</t>


	<t>For Refresh messages, the server is expected to return an Update Lease	Original:
	option, if	In order to prevent records expiring, requestors MUST refresh
	supported, just as with the initial Registration. As with the Registratio	resource records before they expire.
	n, the
	requestor MUST use the interval(s) specified by the server when determini
	ng when to send
	the next Refresh message.</t>


	<t>When sending Refresh messages, the requestor MUST include an Update Le	Perhaps:
	ase option, as	In order to prevent records expiring, requestors MUST refresh
	it did for the initial Registration. The Update Lease option MAY either s	them.
	pecify the same	-->
	intervals as in the initial Registration, or MAY use the values returned
	by the server	<t>In order to prevent records expiring, requestors
	in the previous Update Response, whether it was a response to a Registrat	<bcp14>MUST</bcp14> refresh resource records before they expire. At
	ion a	the time of registration, the client computes an interval that is 80%
	Refresh. As with responses to Registrations, the requestor MUST use the i	of the lease time plus a random offset between 0% and 5% of the lease
	ntervals	time. The random offset is to prevent refreshes from being
		synchronized. When this interval has expired, the client
		<bcp14>MUST</bcp14> refresh the message if the data in the initial
		Registration should continue to be advertised.</t>

		<t>For Refresh messages, the server is expected to return an Update
		Lease option, if supported, just as with the initial Registration. As
		with the Registration, the requestor <bcp14>MUST</bcp14> use the
		intervals specified by the server when determining when to send the
		next Refresh message.</t>

		<t>When sending Refresh messages, the requestor <bcp14>MUST</bcp14> inclu
		de an Update Lease option, as
		it did for the initial Registration.

		The Update Lease option <bcp14>MAY</bcp14> either specify the same
		intervals as in the initial Registration or use the values returned by th
		e server
		in the previous Update Response, whether it was a response to a Registrat
		ion or a
		Refresh. As with responses to Registrations, the requestor <bcp14>MUST</b
		cp14> use the interval or intervals
	returned by the server in the response when determining when to send the next Refresh	returned by the server in the response when determining when to send the next Refresh
	message.</t>	message.</t>

	<section>	<section>
	<name>Coalescing Refresh Messages</name>	<name>Coalescing Refresh Messages</name>
	<t>If the requestor has performed multiple successful Registrations wi th a single server,	<t>If the requestor has performed multiple successful Registrations wi th a single server,

	the requestor MAY include Refreshes for all such Registrations to that server in a single	the requestor <bcp14>MAY</bcp14> include Refreshes for all such Regist rations to that server in a single
	message. This effectively places all records for a requestor on the sa me expiration	message. This effectively places all records for a requestor on the sa me expiration
	schedule, reducing network traffic due to Refreshes.</t>	schedule, reducing network traffic due to Refreshes.</t>

	<t>In doing so, the requestor includes in the Refresh message all exist ing updates to	<t>In doing so, the requestor includes in the Refresh message all exist ing updates to
	the server, including those not yet close to expiration, so long as at least one	the server, including those not yet close to expiration, so long as at least one
	resource record in the message has elapsed at least 75% of its original lease. If the	resource record in the message has elapsed at least 75% of its original lease. If the

	requestor uses UDP, the requestor MUST NOT coalesce Refresh messages if doing so would	requestor uses UDP, the requestor <bcp14>MUST NOT</bcp14> coalesce Refr esh messages if doing so would
	cause truncation of the message; in this case, the requestor should eit her send multiple	cause truncation of the message; in this case, the requestor should eit her send multiple

	messages or should use TCP to send the entire update at once.</t>	messages or use TCP to send the entire update at once.</t>


	<t>Requestors SHOULD NOT send a Refresh messages when all of the record s in the	<t>Requestors <bcp14>SHOULD NOT</bcp14> send Refresh messages when all of the records in the
	Refresh have more than 50% of their lease interval remaining before exp iry. However,	Refresh have more than 50% of their lease interval remaining before exp iry. However,

	there may be cases where the requestor needs to send an early Refresh, and it MAY do	there may be cases where the requestor needs to send an early Refresh, and it <bcp14>MAY</bcp14> do
	so. For example, a power-constrained (sleepy) device may need to send a n update when the radio	so. For example, a power-constrained (sleepy) device may need to send a n update when the radio
	is powered so as to avoid having to power it up later.</t>	is powered so as to avoid having to power it up later.</t>

	<t>Another case where this may be needed is if the lease interval regis tered with the	<t>Another case where this may be needed is if the lease interval regis tered with the
	server is no longer appropriate and the Requestor wishes to negotiate a different	server is no longer appropriate and the Requestor wishes to negotiate a different
	lease interval. However, in this case, if the server does not honor the requested	lease interval. However, in this case, if the server does not honor the requested

	interval in its response, the requestor MUST NOT retry this negotiation .</t>	interval in its response, the requestor <bcp14>MUST NOT</bcp14> retry t his negotiation.</t>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Server Behavior</name>	<name>Server Behavior</name>

	<t>Upon receiving a valid Refresh Request, the server MUST send an ackno wledgment. This	<t>Upon receiving a valid Refresh Request, the server <bcp14>MUST</bcp14 > send an acknowledgment. This
	acknowledgment is identical to the Update Response format described in < xref	acknowledgment is identical to the Update Response format described in < xref

	target="update"/> "Update Message Format", and contains the new lease of	target="update"/> and contains the new lease of the resource
	the resource	records being Refreshed. The server <bcp14>MUST NOT</bcp14> increment t
	records being Refreshed. The server MUST NOT increment the serial numbe	he serial number of a zone
	r of a zone
	as the result of a Refresh.</t>	as the result of a Refresh.</t>

	<t>However, the server's state may not match what the client expects. In this case, a	<t>However, the server's state may not match what the client expects. In this case, a
	Refresh may actually appear to be a Registration, from the server's persp ective. If the	Refresh may actually appear to be a Registration, from the server's persp ective. If the

	Refresh changes the contents of the zone, the server MUST update the zone serial	Refresh changes the contents of the zone, the server <bcp14>MUST</bcp14> update the zone serial
	number.</t>	number.</t>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Retransmission Strategy</name>	<name>Retransmission Strategy</name>
	<t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable	<t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable
	transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a	transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a
	reasonable interval. <xref target="RFC1035" section="4.2.1" sectionFormat= "of"/> provides some	reasonable interval. <xref target="RFC1035" section="4.2.1" sectionFormat= "of"/> provides some
	guidance on this topic, as does <xref target="RFC1536" section="1" section Format="of"/>.	guidance on this topic, as does <xref target="RFC1536" section="1" section Format="of"/>.
	<xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also provides useful guidance that	<xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also provides useful guidance that
	is particularly relevant to DNS.</t>	is particularly relevant to DNS.</t>
	</section>	</section>

	<section>	<section>
	<name>Garbage Collection</name>	<name>Garbage Collection</name>

	<t>If the Update Lease of a resource record elapses without being refreshe d, the server	<t>If the Update Lease of a resource record elapses without being refreshe d, the server

	MUST NOT return the expired record in answers to queries. The server MAY d	<bcp14>MUST NOT</bcp14> return the expired record in answers to queries. T
	elete the record	he server <bcp14>MAY</bcp14> delete the record
	from its database. The lease interval(s) returned by the server to the req	from its database. The lease interval or intervals returned by the server
	uestor are used	to the requestor are used
	in determining when the lease on a resource record has expired.</t>	in determining when the lease on a resource record has expired.</t>

	<t>For all resource records other than a KEY record included in a DNS Upda te request, the	<t>For all resource records other than a KEY record included in a DNS Upda te request, the
	Update Lease is the LEASE value in the Update Lease option. For KEY record s, if the	Update Lease is the LEASE value in the Update Lease option. For KEY record s, if the
	optional KEY-LEASE value was included, this interval is used rather than t he interval	optional KEY-LEASE value was included, this interval is used rather than t he interval

	specified in LEASE. If KEY-LEASE was not specified, the interval specified in LEASE is	specified in the LEASE. If the KEY-LEASE was not specified, the interval s pecified in the LEASE is
	used.	used.
	</t>	</t>
	</section>	</section>


	<section title="Security Considerations">	<section>
		<name>Security Considerations</name>
	<t><xref target="RFC2136" section="8" sectionFormat="of"/> describes probl ems that can occur	<t><xref target="RFC2136" section="8" sectionFormat="of"/> describes probl ems that can occur
	around DNS updates. Servers implementing this specification should follow these recommendations.</t>	around DNS updates. Servers implementing this specification should follow these recommendations.</t>

	<t>Several additional issues can arise when relying on the Update Lease op tion. First, a	<t>Several additional issues can arise when relying on the Update Lease op tion. First, a
	too-long lease time is not much different than no lease time: the records associated with	too-long lease time is not much different than no lease time: the records associated with

	this lease time will effectively never be cleaned up. Servers implementing Update Lease	this lease time will effectively never be cleaned up. Servers implementing the Update Lease
	should have a default upper bound on the maximum acceptable value both for the LEASE and	should have a default upper bound on the maximum acceptable value both for the LEASE and

	KEY-LEASE values sent by the client. Servers MAY provide a way for the ope rator to change	KEY-LEASE values sent by the client. Servers <bcp14>MAY</bcp14> provide a way for the operator to change
	this upper limit. Default values for these limits of 24 hours and 7 days, respectively,	this upper limit. Default values for these limits of 24 hours and 7 days, respectively,

	are RECOMMENDED.</t>	are <bcp14>RECOMMENDED</bcp14>.</t>

	<t>The second issue is that a too-short lease can result in increased serv er load as	<t>The second issue is that a too-short lease can result in increased serv er load as
	requestors rapidly renew the lease. A delay in renewing could result in th e data being	requestors rapidly renew the lease. A delay in renewing could result in th e data being

	removed prematurely. Servers implementing Update Lease MUST have a defaul	removed prematurely. Servers implementing Update Lease <bcp14>MUST</bcp14
	t minimum lease	> have a default minimum lease
	interval that avoids this issue. We RECOMMEND a minimum of 30 seconds for	interval that avoids this issue.
	both the LEASE
		<!-- [rfced] We suggest the following update as BCP 14 uses
		"RECOMMENDED" (with the -ed ending). Please let us know any
		objections.

		Current:
		We RECOMMEND a minimum of 30 seconds for
		both the LEASE and KEY-LEASE intervals.

		Perhaps:
		A minimum of 30 seconds for both the LEASE and KEY-LEASE
		intervals is RECOMMENDED.
		-->

		We RECOMMEND a minimum of 30 seconds for both the LEASE
	and KEY-LEASE intervals. However, in most cases, much longer lease times ( for example, an hour)	and KEY-LEASE intervals. However, in most cases, much longer lease times ( for example, an hour)

	are RECOMMENDED.</t>	are <bcp14>RECOMMENDED</bcp14>.</t>


	<t>There may be some cost associated with renewing leases. A malicious (or	<t>There may be some cost associated with renewing leases. A malicious
	buggy) client	(or buggy) client could renew at a high rate in order to overload the
	could renew at a high rate in order to overload the server more than it wo	server more than it would be overloaded by query traffic. This risk is
	uld be	present for a regular DNS update as well. The server <bcp14>MUST</bcp14>
	overloaded by query traffic. This risk is present for regular DNS update a	enforce a minimum interval between updates. After a Refresh or
	s well. The	Registration has been successfully processed and acknowledged, another
	server MUST enforce a minimum interval between updates. After a Refresh or	Update of either type from the client during that interval
	Registration	<bcp14>MUST</bcp14> be silently ignored by the server.</t>
	has been successfully processed and acknowledged, another Update of either
	type from the
	client during that interval MUST be silently ignored by the server.</t>


	<t>Some authentication strategy should be used when accepting DNS updates.	<t>Some authentication strategy should be used when accepting DNS
	Shared secret	updates. A shared secret <xref target="RFC8945"/> or public key signing
	<xref target="RFC8945"/> or public key signing (e.g. SIG(0) <xref target="	(e.g., SIG(0) <xref target="RFC2931"/>) should be required. Keys should
	RFC2931"/>) should be required. Keys should have limited	have limited authority: compromise of a key should not result in
	authority: compromise of a key should not result in compromise of the enti	compromise of the entire contents of one or more zones managed by the
	re contents of one	server. Key management strategy is out of scope for this document. An
	or more zones managed by the server. Key management strategy is out of sco	example of a key management strategy can be found in <xref
	pe for this document.	target="RFC9665"/>, which uses "First Come, First Served Naming" rather
	An example of a key management strategy can be found in <xref target="I-D.	than an explicit trust establishment process to confer update
	ietf-dnssd-srp"/>,	permission to a set of records.</t>
	which uses "first come, first-served naming" rather than an explicit trust
	establishment process,
	to confer update permission to a set of records.</t>
	</section>	</section>

	<section>	<section>
	<name>IANA Considerations</name>	<name>IANA Considerations</name>


	<t>The EDNS(0) OPTION CODE 2 has already been assigned for this DNS extens	<t>IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry <xref targ
	ion. This	et="EDNS0Codes"/> as regards value 2 as follows:</t>
	document appears in the DNS EDNS0 Option Codes (OPT) registry <xref target
	="EDNS0Codes"/> with the name 'UL' and the status 'On-hold,' and a
	document reference to an older version of this document. When this documen
	t has been
	approved, the IANA is asked to update the registry as follows:</t>
	<sourcecode>
	OLD:
	Value: 2
	Name: UL
	Status: On-hold
	Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt


	NEW:	<dl newline="false" spacing="compact">
	Value: 2	<dt>Value:</dt> <dd>2</dd>
	Name: Update Lease	<dt>Name:</dt> <dd>Update Lease</dd>
	Status: Standard	<dt>Status:</dt> <dd>Standard</dd>
	Reference: [this document]	<dt>Reference:</dt> <dd>RFC 9664</dd>
	</sourcecode>	</dl>
	</section>


	<section>
	<name>Acknowledgments</name>
	<t>Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the p
	recursor to this
	document. Thanks also to Roger Pantos and Chris Sharp for their contribut
	ions. Thanks to
	Chris Box, Esko Dijk, Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nat
	han Dyck, Steve
	Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their worki
	ng group reviews of this document.
	Thanks to David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib
	for their directorate
	reviews and IANA reviews.</t>
	</section>	</section>


	</middle>	</middle>

	<back>	<back>

	<!-- This needLines directive is to keep the Authors' Addresses heading from bei
	ng split from the list -->
	<!-- <displayreference target="I-D.sctl-service-registration" to="RegProt"/>
	-->
	<!-- <displayreference target="I-D.ietf-dnssd-hybrid" to="I-D.ietf-dnssd-hyb
	rid"/> appears to not work in xml2rfc 2.6.2 -->
	<references title="Normative References">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.1035.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2136.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6891.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8174.xml"/>
	</references>


	<references title="Informative References">	<references>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<name>References</name>
	.1536.xml"/>	<references>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<name>Normative References</name>
	.2931.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	5.xml"/>
	.6763.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	9.xml"/>
	.8085.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.213
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	6.xml"/>
	.8945.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-	1.xml"/>
	D.ietf-dnssd-srp.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	<reference anchor="EDNS0Codes" target="https://www.iana.org/assignments/dn	4.xml"/>
	s-parameters/dns-parameters.xml">	</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.153
		6.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.293
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.676
		3.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808
		5.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894
		5.xml"/>

		<!-- [I-D.ietf-dnssd-srp] companion document RFC 9665-->
		<reference anchor="RFC9665" target="https://www.rfc-editor.org/info/rfc966
		5">
		<front>
		<title>Service Registration Protocol for DNS-Based Service Discovery</t
		itle>
		<author fullname="Ted Lemon" initials="T." surname="Lemon">
		<organization>Apple Inc.</organization>
		</author>
		<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
		<organization>Apple Inc.</organization>
		</author>
		<date month="October" year="2024"/>
		</front>
		<seriesInfo name="RFC" value="9665"/>
		<seriesInfo name="DOI" value="10.17487/RFC9665"/>
		</reference>

		<reference anchor="EDNS0Codes" target="https://www.iana.org/assignments/dn
		s-parameters">
	<front>	<front>
	<title>DNS EDNS0 Option Codes (OPT)</title>	<title>DNS EDNS0 Option Codes (OPT)</title>

	<author/>	<author>
	<date month="April" year="2023"/>	<organization>IANA</organization>
		</author>
	</front>	</front>
	</reference>	</reference>

		</references>
	</references>	</references>


		<section numbered="false">
		<name>Acknowledgments</name>
		<t>Thanks to <contact fullname="Marc Krochmal"/> and <contact
		fullname="Kiren Sekar"/> for their work in 2006 on the precursor to this
		document. Thanks also to <contact fullname="Roger Pantos"/> and
		<contact fullname="Chris Sharp"/> for their contributions. Thanks to
		<contact fullname="Chris Box"/>, <contact fullname="Esko Dijk"/>,
		<contact fullname="Jonathan Hui"/>, <contact fullname="Peter van
		Dijk"/>, <contact fullname="Abtin Keshvarzian"/>, <contact
		fullname="Nathan Dyck"/>, <contact fullname="Steve Hanna"/>, <contact
		fullname="Gabriel Montenegro"/>, <contact fullname="Kangping Dong"/>,
		and <contact fullname="Tim Wicinski"/> for their working group reviews
		of this document. Thanks to <contact fullname="David Dong"/>, <contact
		fullname="Olafur Gudmundsson"/>, <contact fullname="Brian Trammel"/>,
		and <contact fullname="Shivan Sahib"/> for their directorate reviews and
		IANA reviews.</t>
		</section>

	</back>	</back>


		<!--[rfced] We had the following questions related to terminology used
		throughout the document:

		We see the following similar terms. Please let us know if/how they
		may be made uniform.

		(4-byte) variant vs. 4-byte variant
		(8-byte) variant vs. 8-byte variant

		-->

		<!-- [rfced] Please review whether any of the notes in this document
		should be in the <aside> element. It is defined as "a container
		for content that is semantically less important or tangential to
		the content that surrounds it"
		(https://authors.ietf.org/en/rfcxml-vocabulary#aside).

		Specifically, we're referring to the instances of "Note:" in Section
		4.2 and of "Note that" in Section 4.3.
		-->

		<!-- [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 are needed.

		Note that our script did not flag any words in particular, but this
		should still be reviewed as a best practice.
		-->

	</rfc>	</rfc>

End of changes. 67 change blocks.
	349 lines changed or deleted	449 lines changed or added
This html diff was produced by rfcdiff 1.48.