Diff: rfc9803xml2.original.xml

	rfc9803xml2.original.xml	rfc9803.xml

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbsp " ">
	C.2119.xml">	<!ENTITY zwsp "">
	<!ENTITY RFC3688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF	<!ENTITY nbhy "‑">
	C.3688.xml">	<!ENTITY wj "⁠">
	<!ENTITY RFC5731 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5731.xml">
	<!ENTITY RFC5732 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5732.xml">
	<!ENTITY RFC5910 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5910.xml">
	<!ENTITY RFC6895 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6895.xml">
	<!ENTITY RFC6927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6927.xml">
	<!ENTITY RFC7451 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7451.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8174.xml">
	<!ENTITY RFC8590 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8590.xml">
	<!ENTITY RFC9364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.9364.xml">
	<!ENTITY RFC9499 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.9499.xml">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<?rfc strict="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc toc="yes"?>	tf-regext-epp-ttl-18" number="9803" ipr="trust200902" submissionType="IETF" cons
	<?rfc tocdepth="4"?>	ensus="true" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updat
	<?rfc symrefs="yes"?>	es="" obsoletes="" version="3" xml:lang="en">
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-regext-epp-ttl-18" ipr="trust200902" submissionType="IETF" consensus="true">
	<front>	<front>

	<title abbrev="TTL mapping for EPP">	<title abbrev="TTL Mapping for EPP">Extensible Provisioning Protocol (EPP) M
	Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values	apping for DNS Time-to-Live (TTL) Values</title>
	</title>	<seriesInfo name="RFC" value="9803"/>
	<author fullname="Gavin Brown">	<author fullname="Gavin Brown">
	<organization>ICANN</organization>	<organization>ICANN</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12025 Waterfront Drive, Suite 300</street>	<street>12025 Waterfront Drive, Suite 300</street>
	<city>Los Angeles</city>	<city>Los Angeles</city>
	<region>CA</region>	<region>CA</region>
	<code>90292</code>	<code>90292</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>gavin.brown@icann.org</email>	<email>gavin.brown@icann.org</email>
	<uri>https://www.icann.org/</uri>	<uri>https://www.icann.org/</uri>
	</address>	</address>
	</author>	</author>

	<date/>	<date month="June" year="2025"/>
	<area>Applications</area>	<area>ART</area>
	<workgroup>Registration Protocols Extensions (regext)</workgroup>	<workgroup>regext</workgroup>
		<keyword>EPP</keyword>
		<keyword>DNS</keyword>
		<keyword>TTL</keyword>
		<keyword>time-to-live</keyword>

	<abstract>	<abstract>

	<t>	<t>This document describes an extension to the Extensible Provisioning
	This document describes an extension to the Extensible Provisioning Protocol (EP	Protocol (EPP) that allows EPP clients to manage the Time-to-Live (TTL)
	P) that allows EPP clients to manage the Time-To-Live (TTL) value for domain nam	value for domain name delegation records.
	e delegation records.	</t>
	</t>
	</abstract>	</abstract>

	<note title="About this draft" removeInRFC="true">
	<t>
	The source for this draft, and an issue tracker, may can be found at <eref targe
	t="https://github.com/gbxyz/epp-ttl-extension"/>.
	</t>
	</note>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section>
		<name>Introduction</name>
	<t>	<t>

	The principal output of any domain name registry system is a DNS zone file, whic	The principal output of any domain name registry system is a DNS zone
	h contains the delegation record(s) for names registered within a zone (such as	file, which contains the delegation record(s) for names registered
	a top-level domain).	within a zone (such as a top-level domain). These records typically
	These records typically include one or more <tt>NS</tt> records, but may also in	include one or more <tt>NS</tt> records, but may also include
	clude <tt>DS</tt> records for domains secured with DNSSEC (<xref target="RFC9364	<tt>DS</tt> records for domains secured with DNSSEC <xref
	"/>), and <tt>DNAME</tt> records for IDN variants (<xref target="RFC6927"/>).	target="RFC9364"/>, and <tt>DNAME</tt> records for Internationalized Doma
	<tt>A</tt> and/or <tt>AAAA</tt> records may also be published for nameservers wh	in Name (IDN) variants <xref
	ere required by DNS resolvers to avoid an infinite loop.	target="RFC6927"/>. <tt>A</tt> and/or <tt>AAAA</tt> records may also
	</t>	be published for nameservers where they are required by DNS resolvers
		to avoid an infinite loop.</t>
	<t>	<t>

	Typically, the Time-To-Live value (TTL, see <xref section="5" sectionFormat="of"	Typically, the Time-to-Live (TTL) value (see <xref section="5"
	target="RFC9499"/>) of these records is determined by the registry operator.	sectionFormat="of" target="RFC9499"/>) of these records is determined
	However, in some circumstances it may be desirable to allow the sponsoring clien	by the registry operator. However, in some circumstances it may be
	t of a domain name to change the TTL values used for that domain's delegation:	desirable to allow the sponsoring client of a domain name to change
	for example, to reduce the amount of time required to complete a change of DNS s	the TTL values used for that domain's delegation: for example, to
	ervers, DNSSEC deployment or key rollover, or to allow for fast rollback of such	reduce the amount of time required to complete a change of DNS
	changes.	servers, DNSSEC deployment or key rollover, or to allow for fast
	</t>	rollback of such changes.</t>
	<t>	<t>

	This document describes an EPP extension to the domain name and host object mapp	This document describes an EPP extension to the domain name and host
	ings (described in <xref target="RFC5731"/> and <xref target="RFC5732"/>, respec	object mappings (described in <xref target="RFC5731"/> and <xref
	tively) which allows the sponsor of a domain name or host object to change the T	target="RFC5732"/>, respectively) that allows the sponsor of a domain
	TL values of the resource record(s) associated with that object.	name or host object to change the TTL values of the resource record(s)
	It also describes how EPP servers should handle TTLs specified by EPP clients an	associated with that object. It also describes how EPP servers should
	d how both parties co-ordinate to manage TTL values in response to changes in op	handle TTLs specified by EPP clients and how both parties coordinate
	erational or security requirements.	to manage TTL values in response to changes in operational or security
	</t>	requirements.</t>
	<section title="Conventions used in this document">
		<section>
		<name>Conventions Used in This Document</name>
	<t>	<t>

	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</b	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	cp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT R	",
	ECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	document are to be interpreted as described in BCP 14 <xref target="RFC2119" fo	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	rmat="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC81	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	74" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and onl	be
	y when, they appear in all capitals, as shown here.	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
	</t>	target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>

	<t>	<t>

	In examples, "C:" represents lines sent by a protocol client and "S:" represents	In this document's examples, "C:" represents lines sent by a protocol c
	lines returned by a protocol server.	lient and
	Indentation and white space in examples are provided only to illustrate element	"S:" represents lines returned by a protocol server. Indentation
	relationships and are not required features of this protocol.	and white space in these examples are provided only to illustrate eleme
	</t>	nt
		relationships and are not required features of this protocol.</t>
	<t>	<t>

	A protocol client that is authorized to manage an existing object is described a	A protocol client that is authorized to manage an existing object is
	s a "sponsoring" client throughout this document.	described as a "sponsoring" client throughout this document.</t>
	</t>
	<t>	<t>

	XML is case sensitive.	XML is case sensitive. Unless stated otherwise, the XML specifications
	Unless stated otherwise, XML specifications and examples provided in this docume	and examples provided in this document <bcp14>MUST</bcp14> be
	nt <bcp14>MUST</bcp14> be interpreted in the character case presented in order t	interpreted in the character case presented in order to develop a
	o develop a conforming implementation.	conforming implementation.</t>
	</t>
	<t>	<t>

	EPP uses XML namespaces to provide an extensible object management framework and	EPP uses XML namespaces to provide an extensible object management
	to identify schemas required for XML instance parsing and validation.	framework and to identify schemas required for XML instance parsing
	These namespaces and schema definitions are used to identify both the base proto	and validation. These namespaces and schema definitions are used to
	col schema and the schemas for managed objects.	identify both the base protocol schema and the schemas for managed
	</t>	objects.</t>
	<t>	<t>

	The XML namespace prefixes used in examples (such as the string <tt>ttl</tt> in	The XML namespace prefixes used in these examples (such as the string
	<tt>ttl:create</tt>) are solely for illustrative purposes.	<tt>ttl</tt> in <tt>ttl:create</tt>) are solely for illustrative
	A conforming implementation <bcp14>MUST NOT</bcp14> require the use of these or	purposes. A conforming implementation <bcp14>MUST NOT</bcp14>
	any other specific namespace prefixes.	require the use of these or any other specific namespace prefixes.</t>
	</t>
	<t>	<t>

	In accordance with <xref target="XSD-DATATYPES">Section 3.2.2.1 of XML Schema Pa	In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes
	rt 2: Datatypes</xref>,	<xref target="XSD-DATATYPES"/>, the allowable lexical
	the allowable lexical representations for the <tt>xs:boolean</tt> datatype are t	representations for the <tt>xs:boolean</tt> datatype are the strings
	he strings "<tt>0</tt>" and "<tt>false</tt>" for the concept 'false' and the str	"<tt>0</tt>" and "<tt>false</tt>" for the concept 'false' and the
	ings "<tt>1</tt>" and "<tt>true</tt>" for the concept 'true'.	strings "<tt>1</tt>" and "<tt>true</tt>" for the concept 'true'.
	Implementations <bcp14>MUST</bcp14> support both styles of lexical representatio	Implementations <bcp14>MUST</bcp14> support both styles of lexical
	n.	representation.</t>
	</t>
	</section>	</section>

	<section title="Extension elements" anchor="extension-elements">
	<t>	<section anchor="extension-elements">
	This extension adds additional elements to the EPP domain and host mappings.	<name>Extension Elements</name>
	</t>	<t>This extension adds additional elements to the EPP domain and host ma
	<section anchor="ttl_element" title="The <ttl:ttl> element">	ppings.</t>
		<section anchor="ttl_element">
		<name>The <ttl:ttl> Element</name>
	<t>	<t>

	The <tt><ttl:ttl></tt> element is used to define TTL values for the DNS re	The <tt><ttl:ttl></tt> element is used to define TTL values
	source records associated with domain and host objects.	for the DNS resource records associated with domain and host
	</t>	objects.
	<t><tt><ttl:ttl></tt> elements have the optional following attri	</t>
	butes, depending on whether they appear in an EPP command or response:
	</t>
	<ol>
	<li>
	"<tt>for</tt>", which is <bcp14>REQUIRED</bcp14> in both commands and responses,
	and which specifies the DNS record type to which the TTL value pertains.
	This attribute <bcp14>MUST</bcp14> have one of the following values: "<tt>NS</tt
	>", "<tt>DS</tt>", "<tt>DNAME</tt>", "<tt>A</tt>", "<tt>AAAA</tt>" or "<tt>custo
	m</tt>";
	</li>
	<li>
	If the value of the "<tt>for</tt>" attribute is "<tt>custom</tt>",
	then the <tt><ttl:ttl></tt> element <bcp14>MUST</bcp14> also have a "<tt>c
	ustom</tt>" attribute containing a DNS record type conforming with the regular e
	xpression in <xref sectionFormat="of" section="3.1" target="RFC6895"/>.
	Additionally, the record type <bcp14>MUST</bcp14> be registered with IANA in <xr
	ef target="IANA-RRTYPES"/>.
	</li>
	<li>
	"<tt>min</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but <bc
	p14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"/>),
	and which is used by the server to indicate the lowest value that may be set;
	</li>
	<li>
	"<tt>default</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but
	<bcp14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"
	/>), and which is used by the server to indicate the default value;
	</li>
	<li>
	"<tt>max</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but <bc
	p14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"/>),
	and which is used by the server to indicate the highest value that may be set;
	</li>
	</ol>
	<t>	<t>

	When present, the value of the "<tt>min</tt>" attribute <bcp14>MUST</bcp14> be l	<tt><ttl:ttl></tt> elements have the optional following
	ower than the value of the "<tt>max</tt>" attribute. The "<tt>default</tt>" attr	attributes, depending on whether they appear in an EPP command or
	ibute <bcp14>MUST</bcp14> be between the "<tt>min</tt>" and "<tt>max</tt>" value	response:
	s, inclusively.	</t>
	</t>	<dl newline="true">
	<section title="Element content" anchor="element-content">	<dt>"<tt>for</tt>"</dt>
		<dd>
		<bcp14>REQUIRED</bcp14> in both commands and responses, and
		specifies the DNS record type to which the TTL value pertains.
		This attribute <bcp14>MUST</bcp14> have one of the following
		values: "<tt>NS</tt>", "<tt>DS</tt>", "<tt>DNAME</tt>",
		"<tt>A</tt>", "<tt>AAAA</tt>" or "<tt>custom</tt>".
		</dd>
		<dt>"<tt>custom</tt>"</dt>
		<dd>If the value of the "<tt>for</tt>" attribute is
		"<tt>custom</tt>", then the <tt><ttl:ttl></tt> element
		<bcp14>MUST</bcp14> also have a "<tt>custom</tt>" attribute
		containing a DNS record type conforming with the regular
		expression in <xref sectionFormat="of" section="3.1"
		target="RFC6895"/>. Additionally, the record type
		<bcp14>MUST</bcp14> be registered with IANA in <xref
		target="IANA-RRTYPES"/>.
		</dd>

		<dt>"<tt>min</tt>"</dt>
		<dd>
		<bcp14>MUST NOT</bcp14> be present in EPP commands but
		<bcp14>MAY</bcp14> be present in EPP responses (see <xref
		target="info-command"/>). It is used by the server to
		indicate the lowest value that may be set.
		</dd>

		<dt>"<tt>default</tt>"</dt>
		<dd>
		<bcp14>MUST NOT</bcp14> be present in EPP commands but
		<bcp14>MAY</bcp14> be present in EPP responses (see <xref
		target="info-command"/>). It is used by the server to
		indicate the default value.
		</dd>

		<dt>"<tt>max</tt>"</dt>
		<dd>
		<bcp14>MUST NOT</bcp14> be present in EPP commands but
		<bcp14>MAY</bcp14> be present in EPP responses (see <xref
		target="info-command"/>). It is used by the server to
		indicate the highest value that may be set.
		</dd>
		</dl>

		<t>
		When present, the value of the "<tt>min</tt>" attribute
		<bcp14>MUST</bcp14> be lower than the value of the "<tt>max</tt>"
		attribute. The "<tt>default</tt>" attribute <bcp14>MUST</bcp14> be
		between the "<tt>min</tt>" and "<tt>max</tt>" values, inclusively.</t
		>

		<section anchor="element-content">
		<name>Element Content</name>
	<t>	<t>

	The XML schema found in <xref target="formal-syntax"/> of this document restrict	The XML schema found in <xref target="formal-syntax"/> of this
	s the content of <tt><ttl:ttl></tt> elements to be either:	document restricts the content of <tt><ttl:ttl></tt>
	</t>	elements to be either:</t>
	<ol>	<ol>

	<li>	<li>a non-negative integer, indicating the value of the TTL in sec
	a non-negative integer, indicating the value of the TTL in seconds, or	onds, or</li>
	</li>	<li>empty, in which case the server's default TTL for the given re
	<li>	cord type is to be applied.</li>
	empty, in which case the server's default TTL for the given record type is to be
	applied.
	</li>
	</ol>	</ol>
	</section>	</section>

	<section title="Supported DNS record types" anchor="supported-dns-reco
	rd-types">	<section anchor="supported-dns-record-types">
		<name>Supported DNS Record Types</name>
	<t>	<t>

	To facilitate forward compatibility with future changes to the DNS protocol,	To facilitate forward compatibility with future changes to the
	this document does not enumerate or restrict the DNS record types that can be in	DNS protocol, this document does not enumerate or restrict the
	cluded in the "<tt>custom</tt>" attribute of the <tt><ttl:ttl></tt> elemen	DNS record types that can be included in the "<tt>custom</tt>"
	t.	attribute of the <tt><ttl:ttl></tt> element.</t>
	</t>
	<t>	<t>

	The regular expression which is used to validate the values of the "<tt>custom</	The regular expression that is used to validate the values of
	tt>" attribute is based on the expression found in <xref sectionFormat="of" sect	the "<tt>custom</tt>" attribute is based on the expression found
	ion="3.1" target="RFC6895"/>,	in <xref sectionFormat="of" section="3.1" target="RFC6895"/>,
	and is intended to match both existing and future RRTYPE mnemonics.	and it is intended to match both existing and future RRTYPE
	This eliminates the need to update this document in the event that new DNS recor	mnemonics. This eliminates the need to update this document in
	ds that exist above a zone cut (<xref sectionFormat="of" section="7" target="RFC	the event that new DNS records that exist above a zone cut
	9499"/>) are specified.	(<xref sectionFormat="of" section="7" target="RFC9499"/>) are
	</t>	specified.</t>
	<t>	<t>

	Nevertheless, EPP servers which implement this extension <bcp14>MUST</bcp14> res	Nevertheless, EPP servers that implement this extension
	trict the DNS record types that are accepted in <tt><create></tt> and <tt>	<bcp14>MUST</bcp14> restrict the DNS record types that are
	<update></tt> commands,	accepted in <tt><create></tt> and <tt><update></tt>
	and included in <tt><info></tt> responses,	commands, and included in <tt><info></tt> responses,
	allowing only those types that are (a) registered in <xref target="IANA-RRTYPES"	allowing only those types that are (a) registered in <xref
	/> and (b) appropriate for use above a zone cut.	target="IANA-RRTYPES"/> and (b) appropriate for use above a zone
	</t>	cut.</t>
	<t>	<t>

	A server that receives a <tt><create></tt> or <tt><update></tt> comm	A server that receives a <tt><create></tt> or
	and that attempts to set TTL values for inapplicable DNS record types <bcp14>MUS	<tt><update></tt> command that attempts to set TTL values
	T</bcp14> respond with a 2306 "Parameter value policy" error.	for inapplicable DNS record types <bcp14>MUST</bcp14> respond
	</t>	with a 2306 "Parameter value policy" error.</t>
	<t>	<t>

	As an illustrative example, a server <bcp14>MAY</bcp14> allow clients to specify	As an illustrative example, a server <bcp14>MAY</bcp14> allow
	TTL values for the following record types for domain objects:	clients to specify TTL values for the following record types for
	</t>	domain objects:
		</t>

	<ol>	<ol>

	<li><tt>NS</tt>;	<li>
	</li>	<tt>NS</tt>;
	<li><tt>DS</tt> (if the server also implements <xref target="RFC59	</li>
	10"/>);	<li>
	</li>	<tt>DS</tt> (if the server also implements <xref target="RFC5910
	<li><tt>DNAME</tt> (if the server implements IDN variants using <t	"/>);
	t>DNAME</tt> records).	</li>
	</li>	<li>
		<tt>DNAME</tt> (if the server implements IDN variants using
		<tt>DNAME</tt> records).
		</li>
	</ol>	</ol>

	<section title="Glue records">
		<section>
		<name>Glue Records</name>
	<t>	<t>

	Glue records are described in <xref section="7" sectionFormat="of" target="RFC94	Glue records are described in <xref section="7"
	99"/>.	sectionFormat="of" target="RFC9499"/>.</t>
	</t>
	<t>	<t>

	Servers which implement host objects (<xref target="RFC5732"/>) <bcp14>MAY</bcp1	Servers that implement host objects <xref target="RFC5732"/>
	4> allow clients to specify TTL values for <tt>A</tt> and <tt>AAAA</tt> records	<bcp14>MAY</bcp14> allow clients to specify TTL values for
	for host objects.	<tt>A</tt> and <tt>AAAA</tt> records for host objects.</t>
	</t>
	<t>	<t>

	A server supporting host objects which receives a command that attempts to set T	A server supporting host objects that receives a command that
	TL values for <tt>A</tt> and <tt>AAAA</tt> records on a domain object <bcp14>MUS	attempts to set TTL values for <tt>A</tt> and <tt>AAAA</tt>
	T</bcp14> respond with a 2306 "Parameter value policy" error.	records on a domain object <bcp14>MUST</bcp14> respond with a
	</t>	2306 "Parameter value policy" error.</t>
	<t>	<t>

	EPP servers which use the "host attribute" model	EPP servers that use the host attribute model (described in
	(described in <xref sectionFormat="of" section="1.1" target="RFC5731"/>)	<xref sectionFormat="of" section="1.1" target="RFC5731"/>)
	<bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>A</tt> and <tt>AA	<bcp14>MAY</bcp14> allow clients to specify TTL values for
	AA</tt> records for domain objects.	<tt>A</tt> and <tt>AAAA</tt> records for domain objects.</t>
	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="info-element" title="The <ttl:info> element">
		<section anchor="info-element">
		<name>The <ttl:info> Element</name>
	<t>	<t>

	The <tt><ttl:info></tt> element is used by clients to request that the ser	The <tt><ttl:info></tt> element is used by clients to
	ver include additional information in <tt><info></tt> responses for domain	request that the server include additional information in
	and host objects.	<tt><info></tt> responses for domain and host objects.</t>
	</t>
	<t>	<t>

	It has a single <bcp14>OPTIONAL</bcp14> <tt>policy</tt> attribute, which takes a	It has a single <bcp14>OPTIONAL</bcp14> "<tt>policy</tt>"
	boolean value with a default value of <tt>false</tt>.	attribute, which takes a boolean value with a default value of
	</t>	"<tt>false</tt>".</t>
	<t>	<t>

	The semantics of this element are described in <xref target="info-command"/>.	The semantics of this element are described in <xref
	</t>	target="info-command"/>.</t>
	<section title="Example">
	<sourcecode><ttl:info policy="true"/></sourcecode>	<t>Below is an example of a <tt><ttl:info></tt>
	</section>	element with an explicit "<tt>policy</tt>" attribute:</t>

		<sourcecode type="xml"><![CDATA[
		<ttl:info policy="true"/>
		]]></sourcecode>

	</section>	</section>
	</section>	</section>

	<section title="Examples">
	<section title="Explicit TTL value (<create> or <update> c	<section>
	ommand)">	<name>Examples</name>
	<sourcecode><ttl:ttl for="NS">3600</ttl:ttl></sourcecode	<section>
	>	<name>Explicit TTL Value (<create> or <update> Command)<
		/name>
		<sourcecode type="xml"><![CDATA[
		<ttl:ttl for="NS">3600</ttl:ttl>
		]]></sourcecode>
	</section>	</section>

	<section title="Explicit TTL value (<info> policy mode)">
	<sourcecode><ttl:ttl	<section>
		<name>Explicit TTL Value (<info> Policy Mode)</name>
		<sourcecode type="xml"><![CDATA[
		<ttl:ttl
	for="NS"	for="NS"
	min="60"	min="60"
	default="86400"	default="86400"

	max="172800">3600</ttl:ttl></sourcecode>	max="172800">3600</ttl:ttl>
		]]></sourcecode>
	</section>	</section>

	<section title="Empty value indicating default TTL (<create> or	<section>
	<update> command, <info> default mode)">	<name>Empty Value Indicating Default TTL (<create> or <upda
	<sourcecode><ttl:ttl for="NS"/></sourcecode>	te> Command, <info> Default Mode)</name>

		<sourcecode type="xml"><![CDATA[
		<ttl:ttl for="NS"/>
		]]></sourcecode>
	</section>	</section>

	<section title="Custom record type (<create> or <update> c
	ommand, <info> default mode)">	<section>
	<sourcecode><ttl:ttl	<name>Custom Record Type (<create> or <update> Command,
		<info> Default Mode)</name>
		<sourcecode type="xml"><![CDATA[
		<ttl:ttl
	for="custom"	for="custom"

	custom="NEWRRTYPE">3600</ttl:ttl></sourcecode>	custom="NEWRRTYPE">3600</ttl:ttl>
		]]></sourcecode>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section title="EPP command mapping">	<section>
	<section title="EPP query commands">	<name>EPP Command Mapping</name>
	<section anchor="info-command" title="EPP <info> command">	<section>
		<name>EPP Query Commands</name>
		<section anchor="info-command">
		<name>EPP <info> Command</name>
	<t>	<t>

	This extension defines an additional element for EPP <tt><info></tt> comma	This extension defines an additional element for EPP
	nds and responses for domain and host objects.	<tt><info></tt> commands and responses for domain and host
	</t>	objects.</t>
	<t>	<t>

	The EPP <tt><info></tt> command is extended to support two different modes	The EPP <tt><info></tt> command is extended to support two
	:	different modes:</t>
	</t>
	<ol>	<ol>

	<li>	<li>The Default Mode (<xref target="default-mode"/>), which
	The Default Mode (<xref target="default-mode"/>),	requests the inclusion of all non-default TTL values in the
	which requests the inclusion of all non-default TTL values in the response; and	response; and</li>
	</li>	<li>The Policy Mode (<xref target="policy-mode"/>), which requests
	<li>	the inclusion of TTL information for all supported DNS record
	The Policy Mode (<xref target="policy-mode"/>),	types in the response, along with the minimum, default, and maximum
	which requests the inclusion of TTL information for all supported DNS record typ	values for those records.</li>
	es in the response,
	along with the minimum, default and maximum values for those records.
	</li>
	</ol>	</ol>

	<section title="Default Mode" anchor="default-mode">
		<section anchor="default-mode">
		<name>Default Mode</name>
	<t>	<t>

	If a server receives an <tt><info></tt> command for a domain or host objec	If a server receives an <tt><info></tt> command for a
	t which includes a <tt><ttl:info></tt> element	domain or host object that includes a <tt><ttl:info></tt>
	with a "<tt>policy</tt>" attribute that is "<tt>0</tt>" or "<tt>false</tt>",	element with a "<tt>policy</tt>" attribute that is "<tt>0</tt>"
	then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> recor	or "<tt>false</tt>", then the EPP response <bcp14>MUST</bcp14>
	ds for all DNS record types that have non-default TTL values.	contain <tt><ttl:ttl></tt> records for all DNS record
	These elements <bcp14>MUST NOT</bcp14> have the "<tt>min</tt>", "<tt>default</tt	types that have non-default TTL values. These elements
	>" and "<tt>max</tt>" attributes.	<bcp14>MUST NOT</bcp14> have the "<tt>min</tt>",
	</t>	"<tt>default</tt>", and "<tt>max</tt>" attributes.</t>
	<t>	<t>

	Example domain <tt><info></tt> command with a <tt><ttl:info></tt> el	Below is an example domain <tt><info></tt> command with a
	ement with a <tt>policy</tt> attribute that is <tt>false</tt>:	<tt><ttl:info></tt> element with a "<tt>policy</tt>"
	</t>	attribute that is "<tt>false</tt>":</t>
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="n
	o"?>	<sourcecode type="xml" markers="false"><![CDATA[
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C: <command>	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <info>	C: <command>
	C: <domain:info	C: <info>
	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	C: <domain:info
	C: <domain:name>example.com</domain:name>	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	C: </domain:info>	C: <domain:name>example.com</domain:name>
	C: </info>	C: </domain:info>
	C: <extension>	C: </info>
	C: <ttl:info	C: <extension>
		C: <ttl:info
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"

	C: policy="false"/>	C: policy="false"/>
	C: </extension>	C: </extension>
	C: </command>	C: </command>
	C: </epp>	C: </epp>
	</sourcecode>	]]></sourcecode>

	<t>	<t>

	Example domain <tt><info></tt> response to a command with a <tt><ttl:in	Below is an example domain <tt><info></tt> response to a comm
	fo></tt> element with a <tt>policy</tt> attribute that is <tt>false</tt>:	and with
	</t>	a <tt><ttl:info></tt> element with a "<tt>policy</tt>"
	<sourcecode>S: <?xml version="1.0" encoding="utf-8" standalone="n	attribute that is "<tt>false</tt>":</t>
	o"?>
	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	<sourcecode type="xml" markers="false"><![CDATA[
	S: <response>	S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
	S: <result code="1000">	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <msg>Command completed successfully</msg>	S: <response>
	S: </result>	S: <result code="1000">
	S: <resData>	S: <msg>Command completed successfully</msg>
	S: <domain:infData	S: </result>
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: <resData>
	S: <domain:name>example.com</domain:name>	S: <domain:infData
	S: <domain:roid>EXAMPLE1-REP</domain:roid>	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:status s="ok"/>	S: <domain:name>example.com</domain:name>
	S: <domain:ns>	S: <domain:roid>EXAMPLE1-REP</domain:roid>
	S: <domain:hostObj>ns1.example.com</domain:hostObj>	S: <domain:status s="ok"/>
	S: <domain:hostObj>ns1.example.net</domain:hostObj>	S: <domain:ns>
	S: </domain:ns>	S: <domain:hostObj>ns1.example.com</domain:hostObj>
	S: <domain:clID>ClientX</domain:clID>	S: <domain:hostObj>ns1.example.net</domain:hostObj>
	S: <domain:crID>ClientX</domain:crID>	S: </domain:ns>
	S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>	S: <domain:clID>ClientX</domain:clID>
	S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>	S: <domain:crID>ClientX</domain:crID>
	S: </domain:infData>	S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>
	S: </resData>	S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>
	S: <extension>	S: </domain:infData>
	S: <ttl:infData	S: </resData>
	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">	S: <extension>
	S: <ttl:ttl for="NS">172800</ttl:ttl>	S: <ttl:infData
	S: <ttl:ttl for="DS">300</ttl:ttl>	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	S: </ttl:infData>	S: <ttl:ttl for="NS">172800</ttl:ttl>
	S: <secDNS:infData	S: <ttl:ttl for="DS">300</ttl:ttl>
	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">	S: </ttl:infData>
	S: <secDNS:dsData>	S: <secDNS:infData
	S: <secDNS:keyTag>12345</secDNS:keyTag>	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
	S: <secDNS:alg>13</secDNS:alg>	S: <secDNS:dsData>
	S: <secDNS:digestType>2</secDNS:digestType>	S: <secDNS:keyTag>12345</secDNS:keyTag>
	S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>	S: <secDNS:alg>13</secDNS:alg>
	S: </secDNS:dsData>	S: <secDNS:digestType>2</secDNS:digestType>
	S: </secDNS:infData>	S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
	S: </extension>	S: </secDNS:dsData>
	S: <trID>	S: </secDNS:infData>
	S: <clTRID>ABC-12345</clTRID>	S: </extension>
	S: <svTRID>54322-XYZ</svTRID>	S: <trID>
	S: </trID>	S: <clTRID>ABC-12345</clTRID>
	S: </response>	S: <svTRID>54322-XYZ</svTRID>
	S: </epp>	S: </trID>
	</sourcecode>	S: </response>
		S: </epp>
		]]></sourcecode>

	<t>	<t>

	Example host <tt><info></tt> command with a <ttl:info> element with	Below is an example host <tt><info></tt> command with a
	a <tt>policy</tt> attribute that is <tt>false</tt>:	<ttl:info> element with a "<tt>policy</tt>" attribute that
	</t>	is "<tt>false</tt>":</t>
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="n
	o"?>	<sourcecode type="xml" markers="false"><![CDATA[
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C: <command>	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <info>	C: <command>
	C: <host:info	C: <info>
	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	C: <host:info
	C: <host:name>ns1.example.com</host:name>	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
	C: </host:info>	C: <host:name>ns1.example.com</host:name>
	C: </info>	C: </host:info>
	C: <extension>	C: </info>
	C: <ttl:info	C: <extension>
		C: <ttl:info
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"

	C: policy="false"/>	C: policy="false"/>
	C: </extension>	C: </extension>
	C: </command>	C: </command>
	C: </epp>	C: </epp>
	</sourcecode>	]]></sourcecode>
	<t>
	Example host <tt><info></tt> response to a command with a <ttl:info>	<t>Below is an example host <tt><info></tt> response to a comm
	element with a <tt>policy</tt> attribute that is <tt>false</tt>:	and with a
	</t>	<ttl:info> element with a "<tt>policy</tt>" attribute that is
	<sourcecode>S: <?xml version="1.0" encoding="UTF-8" standalone="n	"<tt>false</tt>":</t>
	o"?>
	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	<sourcecode type="xml" markers="false"><![CDATA[
	S: <response>	S: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S: <result code="1000">	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <msg>Command completed successfully</msg>	S: <response>
	S: </result>	S: <result code="1000">
	S: <resData>	S: <msg>Command completed successfully</msg>
	S: <host:infData	S: </result>
	S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	S: <resData>
	S: <host:name>ns1.example.com</host:name>	S: <host:infData
	S: <host:roid>NS1_EXAMPLE1-REP</host:roid>	S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
	S: <host:status s="ok"/>	S: <host:name>ns1.example.com</host:name>
	S: <host:addr ip="v4">192.0.2.2</host:addr>	S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
	S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>	S: <host:status s="ok"/>
	S: <host:clID>ClientX</host:clID>	S: <host:addr ip="v4">192.0.2.2</host:addr>
	S: <host:crID>ClientX</host:crID>	S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
	S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>	S: <host:clID>ClientX</host:clID>
	S: </host:infData>	S: <host:crID>ClientX</host:crID>
	S: </resData>	S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>
	S: <extension>	S: </host:infData>
	S: <ttl:infData	S: </resData>
	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">	S: <extension>
	S: <ttl:ttl for="A">172800</ttl:ttl>	S: <ttl:infData
	S: <ttl:ttl for="AAAA">86400</ttl:ttl>	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	S: </ttl:infData>	S: <ttl:ttl for="A">172800</ttl:ttl>
	S: </extension>	S: <ttl:ttl for="AAAA">86400</ttl:ttl>
	S: <trID>	S: </ttl:infData>
	S: <clTRID>ABC-12345</clTRID>	S: </extension>
	S: <svTRID>54322-XYZ</svTRID>	S: <trID>
	S: </trID>	S: <clTRID>ABC-12345</clTRID>
	S: </response>	S: <svTRID>54322-XYZ</svTRID>
	S: </epp>	S: </trID>
	</sourcecode>	S: </response>
		S: </epp>
		]]></sourcecode>

	</section>	</section>

	<section title="Policy Mode" anchor="policy-mode">	<section anchor="policy-mode">
		<name>Policy Mode</name>
	<t>	<t>

	If a server receives an <tt><info></tt> command for a domain or host objec	If a server receives an <tt><info></tt> command for a
	t which includes a <tt><ttl:info></tt> element	domain or host object that includes a <tt><ttl:info></tt>
	with a "<tt>policy</tt>" attribute is "<tt>1</tt>" or "<tt>true</tt>",	element with a "<tt>policy</tt>" attribute that is "<tt>1</tt>" or
	then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> recor	"<tt>true</tt>", then the EPP response <bcp14>MUST</bcp14>
	ds for all supported DNS record types,	contain <tt><ttl:ttl></tt> records for all supported DNS
	irrespective of whether those record types are actually in use by the object in	record types, irrespective of whether those record types are
	question.	actually in use by the object in question. These elements
	These elements <bcp14>MUST</bcp14> have the "<tt>min</tt>", "<tt>default</tt>" a	<bcp14>MUST</bcp14> have the "<tt>min</tt>", "<tt>default</tt>",
	nd "<tt>max</tt>" attributes.	and "<tt>max</tt>" attributes.</t>
	</t>
	<t>	<t>

	Example domain <tt><info></tt> command requesting the server policies:	Below is an example domain <tt><info></tt> command requesting
	</t>	the
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="n	server policies:</t>
	o"?>
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	<sourcecode type="xml" markers="false"><![CDATA[
	C: <command>	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C: <info>	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <domain:info	C: <command>
	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	C: <info>
	C: <domain:name>example.com</domain:name>	C: <domain:info
	C: </domain:info>	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	C: </info>	C: <domain:name>example.com</domain:name>
	C: <extension>	C: </domain:info>
	C: <ttl:info	C: </info>
		C: <extension>
		C: <ttl:info
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"

	C: policy="true"/>	C: policy="true"/>
	C: </extension>	C: </extension>
	C: </command>	C: </command>
	C: </epp>	C: </epp>
	</sourcecode>	]]></sourcecode>
	<t>
	Example domain <tt><info></tt> response providing the server policies:	<t>Below is an example domain <tt><info></tt> response providi
	</t>	ng the server policies:</t>
	<sourcecode>S: <?xml version="1.0" encoding="utf-8" standalone="n
	o"?>	<sourcecode type="xml" markers="false"><![CDATA[
	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
	S: <response>	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <result code="1000">	S: <response>
	S: <msg>Command completed successfully</msg>	S: <result code="1000">
	S: </result>	S: <msg>Command completed successfully</msg>
	S: <resData>	S: </result>
	S: <domain:infData	S: <resData>
	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">	S: <domain:infData
	S: <domain:name>example.com</domain:name>	S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	S: <domain:roid>EXAMPLE1-REP</domain:roid>	S: <domain:name>example.com</domain:name>
	S: <domain:status s="ok"/>	S: <domain:roid>EXAMPLE1-REP</domain:roid>
	S: <domain:ns>	S: <domain:status s="ok"/>
	S: <domain:hostObj>ns1.example.com</domain:hostObj>	S: <domain:ns>
	S: <domain:hostObj>ns1.example.net</domain:hostObj>	S: <domain:hostObj>ns1.example.com</domain:hostObj>
	S: </domain:ns>	S: <domain:hostObj>ns1.example.net</domain:hostObj>
	S: <domain:clID>ClientX</domain:clID>	S: </domain:ns>
	S: <domain:crID>ClientX</domain:crID>	S: <domain:clID>ClientX</domain:clID>
	S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>	S: <domain:crID>ClientX</domain:crID>
	S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>	S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>
	S: </domain:infData>	S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>
	S: </resData>	S: </domain:infData>
	S: <extension>	S: </resData>
	S: <ttl:infData	S: <extension>
	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">	S: <ttl:infData
	S: <ttl:ttl for="NS"	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		S: <ttl:ttl for="NS"
	S: min="3600"	S: min="3600"
	S: default="86400"	S: default="86400"

	S: max="172800">172800</ttl:ttl>	S: max="172800">172800</ttl:ttl>
	S: <ttl:ttl for="DS"	S: <ttl:ttl for="DS"
	S: min="60"	S: min="60"
	S: default="86400"	S: default="86400"

	S: max="172800">300</ttl:ttl>	S: max="172800">300</ttl:ttl>
	S: </ttl:infData>	S: </ttl:infData>
	S: <secDNS:infData	S: <secDNS:infData
	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">	S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
	S: <secDNS:dsData>	S: <secDNS:dsData>
	S: <secDNS:keyTag>12345</secDNS:keyTag>	S: <secDNS:keyTag>12345</secDNS:keyTag>
	S: <secDNS:alg>13</secDNS:alg>	S: <secDNS:alg>13</secDNS:alg>
	S: <secDNS:digestType>2</secDNS:digestType>	S: <secDNS:digestType>2</secDNS:digestType>
	S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>	S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
	S: </secDNS:dsData>	S: </secDNS:dsData>
	S: </secDNS:infData>	S: </secDNS:infData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S: </epp>	S: </epp>
	</sourcecode>	]]></sourcecode>
	<t>
	Example host <tt><info></tt> command requesting the server policies:	<t>Below is an example host <tt><info></tt> command requesting
	</t>	the server policies:</t>
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="n
	o"?>	<sourcecode type="xml" markers="false"><![CDATA[
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C: <command>	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <info>	C: <command>
	C: <host:info	C: <info>
	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	C: <host:info
	C: <host:name>ns1.example.com</host:name>	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
	C: </host:info>	C: <host:name>ns1.example.com</host:name>
	C: </info>	C: </host:info>
	C: <extension>	C: </info>
	C: <ttl:info	C: <extension>
		C: <ttl:info
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"

	C: policy="true"/>	C: policy="true"/>
	C: </extension>	C: </extension>
	C: </command>	C: </command>
	C: </epp>	C: </epp>
	</sourcecode>	]]></sourcecode>
	<t>
	Example host <tt><info></tt> response providing the server policies:	<t>Below is an example host <tt><info></tt> response providing
	</t>	the server policies:</t>
	<sourcecode>S: <?xml version="1.0" encoding="UTF-8" standalone="n
	o"?>	<sourcecode type="xml" markers="false"><![CDATA[
	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S: <response>	S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <result code="1000">	S: <response>
	S: <msg>Command completed successfully</msg>	S: <result code="1000">
	S: </result>	S: <msg>Command completed successfully</msg>
	S: <resData>	S: </result>
	S: <host:infData	S: <resData>
	S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	S: <host:infData
	S: <host:name>ns1.example.com</host:name>	S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
	S: <host:roid>NS1_EXAMPLE1-REP</host:roid>	S: <host:name>ns1.example.com</host:name>
	S: <host:status s="ok"/>	S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
	S: <host:addr ip="v4">192.0.2.2</host:addr>	S: <host:status s="ok"/>
	S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>	S: <host:addr ip="v4">192.0.2.2</host:addr>
	S: <host:clID>ClientX</host:clID>	S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
	S: <host:crID>ClientX</host:crID>	S: <host:clID>ClientX</host:clID>
	S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>	S: <host:crID>ClientX</host:crID>
	S: </host:infData>	S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>
	S: </resData>	S: </host:infData>
	S: <extension>	S: </resData>
	S: <ttl:infData	S: <extension>
	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">	S: <ttl:infData
	S: <ttl:ttl for="A"	S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		S: <ttl:ttl for="A"
	S: min="3600"	S: min="3600"
	S: default="86400"	S: default="86400"

	S: max="172800">172800</ttl:ttl>	S: max="172800">172800</ttl:ttl>
	S: <ttl:ttl for="AAAA"	S: <ttl:ttl for="AAAA"
	S: min="3600"	S: min="3600"
	S: default="86400"	S: default="86400"

	S: max="172800">86400</ttl:ttl>	S: max="172800">86400</ttl:ttl>
	S: </ttl:infData>	S: </ttl:infData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54322-XYZ</svTRID>	S: <svTRID>54322-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>
	S: </epp>	S: </epp>
	</sourcecode>	]]></sourcecode>

	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section title="EPP transform commands">
	<section title="EPP <create> command">	<section>
	<t>	<name>EPP Transform Commands</name>
	This extension defines an additional element for EPP <tt><create></tt> com	<section>
	mands for domain and host objects.	<name>EPP <create> Command</name>
	</t>
	<t>
	The <tt><command></tt> element of the <tt><create></tt> command <bcp
	14>MAY</bcp14> contain an <tt><extension></tt> element which <bcp14>MAY</b
	cp14> contain a <tt><ttl:create></tt> element.
	This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> re
	cords as described in <xref target="extension-elements"/>.
	</t>
	<t>	<t>

	Example domain <tt><create></tt> command:	This extension defines an additional element for EPP
	</t>	<tt><create></tt> commands for domain and host objects.</t>
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="no"
	?>
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>
	C: <create>
	C: <domain:create
	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	C: <domain:name>example.com</domain:name>
	C: <domain:period unit="y">1</domain:period>
	C: <domain:ns>
	C: <domain:hostObj>ns1.example.com</domain:hostObj>
	C: <domain:hostObj>ns1.example.net</domain:hostObj>
	C: </domain:ns>
	C: <domain:authInfo>
	C: <domain:pw/>
	C: </domain:authInfo>
	C: </domain:create>
	C: </create>
	C: <extension>
	C: <ttl:create
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	C: <ttl:ttl for="NS">172800</ttl:ttl>
	C: <ttl:ttl for="DS">300</ttl:ttl>
	C: </ttl:create>
	C: <secDNS:create
	C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
	C: <secDNS:dsData>
	C: <secDNS:keyTag>12345</secDNS:keyTag>
	C: <secDNS:alg>13</secDNS:alg>
	C: <secDNS:digestType>2</secDNS:digestType>
	C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
	C: </secDNS:dsData>
	C: </secDNS:create>
	C: </extension>
	C: <clTRID>ABC-12345</clTRID>
	C: </command>
	C: </epp>
	</sourcecode>
	<t>	<t>

	Example host <tt><create></tt> command:	The <tt><command></tt> element of the
	</t>	<tt><create></tt> command <bcp14>MAY</bcp14> contain an
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="no"	<tt><extension></tt> element that <bcp14>MAY</bcp14>
	?>	contain a <tt><ttl:create></tt> element. This element
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	<bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt>
	C: <command>	records as described in <xref target="extension-elements"/>.</t>
	C: <create>
	C: <host:create	<t>If an EPP server receives a <tt><create></tt> command
	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	containing a TTL value that is outside the server's permitted range,
	C: <host:name>ns1.example.com</host:name>	it <bcp14>MUST</bcp14> reject the command with a 2004
	C: <host:addr ip="v4">192.0.2.2</host:addr>	"Parameter value range error" response.</t>
	C: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
	C: </host:create>
	C: </create>
	C: <extension>
	C: <ttl:create
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	C: <ttl:ttl for="A"/>
	C: <ttl:ttl for="AAAA">86400</ttl:ttl>
	C: </ttl:create>
	C: </extension>
	C: <clTRID>ABC-12345</clTRID>
	C: </command>
	C: </epp>
	</sourcecode>
	<t>	<t>

	If an EPP server receives a <tt><create></tt> command containing a TTL val	Below is an example domain <tt><create></tt> command:</t>
	ue that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject t
	he command with a <tt>2004</tt> "Parameter value range error" response.	<sourcecode type="xml" markers="false"><![CDATA[
	</t>	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
		C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
		C: <command>
		C: <create>
		C: <domain:create
		C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
		C: <domain:name>example.com</domain:name>
		C: <domain:period unit="y">1</domain:period>
		C: <domain:ns>
		C: <domain:hostObj>ns1.example.com</domain:hostObj>
		C: <domain:hostObj>ns1.example.net</domain:hostObj>
		C: </domain:ns>
		C: <domain:authInfo>
		C: <domain:pw/>
		C: </domain:authInfo>
		C: </domain:create>
		C: </create>
		C: <extension>
		C: <ttl:create
		C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		C: <ttl:ttl for="NS">172800</ttl:ttl>
		C: <ttl:ttl for="DS">300</ttl:ttl>
		C: </ttl:create>
		C: <secDNS:create
		C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
		C: <secDNS:dsData>
		C: <secDNS:keyTag>12345</secDNS:keyTag>
		C: <secDNS:alg>13</secDNS:alg>
		C: <secDNS:digestType>2</secDNS:digestType>
		C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
		C: </secDNS:dsData>
		C: </secDNS:create>
		C: </extension>
		C: <clTRID>ABC-12345</clTRID>
		C: </command>
		C: </epp>
		]]></sourcecode>

		<t>Below is an example host <tt><create></tt> command:</t>

		<sourcecode type="xml" markers="false"><![CDATA[
		C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
		C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
		C: <command>
		C: <create>
		C: <host:create
		C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
		C: <host:name>ns1.example.com</host:name>
		C: <host:addr ip="v4">192.0.2.2</host:addr>
		C: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
		C: </host:create>
		C: </create>
		C: <extension>
		C: <ttl:create
		C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		C: <ttl:ttl for="A"/>
		C: <ttl:ttl for="AAAA">86400</ttl:ttl>
		C: </ttl:create>
		C: </extension>
		C: <clTRID>ABC-12345</clTRID>
		C: </command>
		C: </epp>
		]]></sourcecode>
	</section>	</section>

	<section title="EPP <update> command">	<section>
	<t>	<name>EPP <update> Command</name>
	This extension defines an additional element for EPP <tt><update></tt> com
	mands for domain and host objects.
	</t>
	<t>
	The <tt><command></tt> element of the <tt><update></tt> command <bcp
	14>MAY</bcp14> contain an <tt><extension></tt> element which <bcp14>MAY</b
	cp14> contain a <tt><ttl:update></tt> element.
	This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> re
	cords as described in <xref target="extension-elements"/>.
	</t>
	<t>	<t>

	Example domain <tt><update></tt> command:	This extension defines an additional element for EPP
	</t>	<tt><update></tt> commands for domain and host objects.</t>
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="no"
	?>
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>
	C: <update>
	C: <domain:update
	C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
	C: <domain:name>example.com</domain:name>
	C: </domain:update>
	C: </update>
	C: <extension>
	C: <ttl:update
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	C: <ttl:ttl for="NS"/>
	C: <ttl:ttl for="custom"
	C: custom="DELEG"/>
	C: <ttl:ttl for="DS">86400</ttl:ttl>
	C: </ttl:update>
	C: </extension>
	C: <clTRID>ABC-12345</clTRID>
	C: </command>
	C: </epp>
	</sourcecode>
	<t>	<t>

	Example host <tt><update></tt> command:	The <tt><command></tt> element of the
	</t>	<tt><update></tt> command <bcp14>MAY</bcp14> contain an
	<sourcecode>C: <?xml version="1.0" encoding="UTF-8" standalone="no"	<tt><extension></tt> element that <bcp14>MAY</bcp14>
	?>	contain a <tt><ttl:update></tt> element. This element
	C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	<bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt>
	C: <command>	records as described in <xref target="extension-elements"/>.</t>
	C: <update>
	C: <host:update	<t>
	C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">	If an EPP server receives an <tt><update></tt> command
	C: <host:name>ns1.example.com</host:name>	containing a TTL value that is outside the server's permitted
	C: </host:update>	range, it <bcp14>MUST</bcp14> reject the command with a
	C: </update>	2004 "Parameter value range error" response.</t>
	C: <extension>
	C: <ttl:update
	C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
	C: <ttl:ttl for="A">86400</ttl:ttl>
	C: <ttl:ttl for="AAAA">3600</ttl:ttl>
	C: </ttl:update>
	C: </extension>
	C: <clTRID>ABC-12345</clTRID>
	C: </command>
	C: </epp>
	</sourcecode>
	<t>	<t>

	If an EPP server receives an <tt><update></tt> command containing a TTL va	Below is an example domain <tt><update></tt> command:</t>
	lue that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject
	the command with a <tt>2004</tt> "Parameter value range error" response.	<sourcecode type="xml" markers="false"><![CDATA[
	</t>	C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
		C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
		C: <command>
		C: <update>
		C: <domain:update
		C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
		C: <domain:name>example.com</domain:name>
		C: </domain:update>
		C: </update>
		C: <extension>
		C: <ttl:update
		C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		C: <ttl:ttl for="NS"/>
		C: <ttl:ttl for="custom"
		C: custom="DELEG"/>
		C: <ttl:ttl for="DS">86400</ttl:ttl>
		C: </ttl:update>
		C: </extension>
		C: <clTRID>ABC-12345</clTRID>
		C: </command>
		C: </epp>
		]]></sourcecode>

		<t>Below is an example host <tt><update></tt> command:</t>

		<sourcecode type="xml" markers="false"><![CDATA[
		C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
		C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
		C: <command>
		C: <update>
		C: <host:update
		C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
		C: <host:name>ns1.example.com</host:name>
		C: </host:update>
		C: </update>
		C: <extension>
		C: <ttl:update
		C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
		C: <ttl:ttl for="A">86400</ttl:ttl>
		C: <ttl:ttl for="AAAA">3600</ttl:ttl>
		C: </ttl:update>
		C: </extension>
		C: <clTRID>ABC-12345</clTRID>
		C: </command>
		C: </epp>
		]]></sourcecode>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="server-processing" title="Server processing of TTL values">
	<section anchor="permitted-types" title="Permitted record types">	<section anchor="server-processing">
		<name>Server Processing of TTL Values</name>
		<section anchor="permitted-types">
		<name>Permitted Record Types</name>
	<t>	<t>

	EPP servers <bcp14>MAY</bcp14> restrict the supported DNS record types.	EPP servers <bcp14>MAY</bcp14> restrict the supported DNS record
	For example, a server <bcp14>MAY</bcp14> allow clients to specify TTL values for	types. For example, a server <bcp14>MAY</bcp14> allow clients to
	<tt>DS</tt> records only.	specify TTL values for <tt>DS</tt> records only.</t>
	</t>
	<t>	<t>

	A server which receives a <tt><create></tt> or <tt><update></tt> com	A server that receives a <tt><create></tt> or
	mand which includes a restricted record type <bcp14>MUST</bcp14> respond with a	<tt><update></tt> command that includes a restricted record
	2306 "Parameter value policy" error.	type <bcp14>MUST</bcp14> respond with a 2306 "Parameter value
		policy" error.</t>
	</t>
	<t>	<t>

	Clients can discover the DNS record types for which an EPP server permits TTL va	Clients can discover the DNS record types for which an EPP server
	lues to be changed by performing a "Policy Mode" <tt><info></tt> command,	permits TTL values to be changed by performing a Policy Mode
	as outlined in <xref target="policy-mode"/>.	<tt><info></tt> command, as outlined in <xref
	</t>	target="policy-mode"/>.</t>
	</section>	</section>

	<section title="Use of TTL values in delegation records" anchor="using_ttl
	_values">	<section anchor="using_ttl_values">
		<name>Use of TTL Values in Delegation Records</name>
	<t>	<t>

	EPP servers which implement this extension <bcp14>SHOULD</bcp14> use the values	EPP servers that implement this extension <bcp14>SHOULD</bcp14> use
	provided by EPP clients for the TTL values of records published in the DNS for d	the values provided by EPP clients for the TTL values of records
	omain and (if supported) host objects.	published in the DNS for domain and (if supported) host objects.
	Server operators <bcp14>MAY</bcp14> disregard these values in order to address s	Server operators <bcp14>MAY</bcp14> disregard these values in order
	ecurity and stability issues,	to address security and stability issues, as described in <xref
	as described in <xref target="operational-considerations"/> and <xref target="se	target="operational-considerations"/> and <xref
	curity-considerations"/>.	target="security-considerations"/>.</t>
	</t>
	<t>	<t>

	EPP servers that use the "host attribute" model <bcp14>SHOULD</bcp14> use any <t	EPP servers that use the host attribute model
	t>NS</tt>, <tt>A</tt> and/or <tt>AAAA</tt> TTL values specified for the domain o	<bcp14>SHOULD</bcp14> use any <tt>NS</tt>, <tt>A</tt>, and/or
	bject when publishing <tt>NS</tt>, <tt>A</tt> and/or <tt>AAAA</tt> records deriv	<tt>AAAA</tt> TTL values specified for the domain object when
	ed from host attributes.	publishing <tt>NS</tt>, <tt>A</tt>, and/or <tt>AAAA</tt> records
	</t>	derived from host attributes.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="oob-changes" title="Out-of-band changes to TTL values">
	<t>	<section anchor="oob-changes">
	EPP server operators <bcp14>MAY</bcp14>, in order to address operational or secu	<name>Out-of-Band Changes to TTL Values</name>
	rity issues, make changes to TTL values out-of-band (that is, not in response to	<t>In order to address operational or security issues, EPP server
	an <tt><update></tt> command received from the sponsoring client).	operators <bcp14>MAY</bcp14> make changes to TTL values out-of-band
	</t>	(that is, not in response to an <tt><update></tt> command received
		from the sponsoring client).
		</t>
	<t>	<t>

	Server operators <bcp14>MAY</bcp14> also implement automatic reset of TTL values	Server operators <bcp14>MAY</bcp14> also implement automatic reset of
	, so that they revert to the default value a certain amount of time after an upd	TTL values, so that they revert to the default value a certain amount
	ate has been made.	of time after an update has been made.
	</t>	</t>
	<t>	<t>

	If a TTL value is changed out-of-band, EPP server operators <bcp14>MAY</bcp14> n	If a TTL value is changed out-of-band, EPP server operators
	otify the sponsoring client using the EPP Change Poll extension (<xref target="R	<bcp14>MAY</bcp14> notify the sponsoring client using the EPP Change
	FC8590"/>), which provides a generalised method for EPP servers to notify client	Poll Extension <xref target="RFC8590"/>, which provides a
	s of changes to objects under their sponsorship.	generalized method for EPP servers to notify clients of changes to
	</t>	objects under their sponsorship.
		</t>
	</section>	</section>

	<section anchor="operational-considerations" title="Operational consideratio
	ns">	<section anchor="operational-considerations">
	<section title="Operational impact of TTL values">	<name>Operational Considerations</name>
		<section>
		<name>Operational Impact of TTL Values</name>
	<t>	<t>

	Registry operators must consider the balance between registrants' desire for cha	Registry operators must consider the balance between registrants'
	nges to domains to be visible in the DNS quickly, and the increased DNS query tr	desire for changes to domains to be visible in the DNS quickly, and
	affic that short TTLs can bring.	the increased DNS query traffic that short TTLs can bring.</t>
	</t>
	<t>	<t>

	Registry operators <bcp14>SHOULD</bcp14> implement limits on the maximum and min	Registry operators <bcp14>SHOULD</bcp14> implement limits on the
	imum accepted TTL values that are narrower than the values permitted in the XML	maximum and minimum accepted TTL values that are narrower than the
	schema in the <xref target="formal-syntax" format="title"/> (which were chosen t	values permitted in the XML schema in <xref target="formal-syntax"/>
	o allow any TTL permitted in DNS records), in order to prevent scenarios where a	(which were chosen to allow any TTL permitted in DNS records). This
	n excessively high or low TTL causes operational issues on either side of the zo	is in order to prevent scenarios where an excessively high or low
	ne cut.	TTL causes operational issues on either side of the zone cut.</t>
	</t>	<t><xref target="oob-changes"/> describes how server operators
	<t><xref target="oob-changes"/> describes how server operators <bcp14>MA	<bcp14>MAY</bcp14> unilaterally change TTL values in order to address
	Y</bcp14> unilaterally change TTL values in order to address operational or secu	operational or security issues, or only permit changes for limited
	rity issues, or only permit changes for limited time periods (after which TTLs r	time periods (after which TTLs revert to the default).</t>
	evert to the default).
	</t>
	</section>	</section>

	<section title="When TTL values should be changed">	<section>
		<name>When TTL Values Should Be Changed</name>
	<t>	<t>

	A common operational mistake is changing of DNS record TTLs during or after the	A common operational mistake is changing the DNS record TTLs during
	planned change to the records themselves.	or after the planned change to the records themselves. This arises
	This arises due to a misunderstanding about how TTLs work.	due to a misunderstanding about how TTLs work.</t>
	</t>
	<t>	<t>

	It is <bcp14>RECOMMENDED</bcp14> that guidance be provided to users so they are	It is <bcp14>RECOMMENDED</bcp14> that guidance be provided to users
	aware that changes to a TTL are only effective in shortening transition periods	so they are aware that changes to a TTL are only effective in
	if implemented a period of time — at least equal to the current TTL — <em>before	shortening transition periods if implemented a period of time (at
	</em> the planned change.	least equal to the current TTL) <em>before</em> the planned change.
	The latency between receipt of the <tt><update></tt> command and the actua	The latency between receipt of the <tt><update></tt> command
	l publication of the changes in the DNS should also be taken into consideration	and the actual publication of the changes in the DNS should also be
	in this calculation.	taken into consideration in this calculation.</t>
	</t>
	</section>	</section>

	<section title="Changes to server policy">	<section>
		<name>Changes to Server Policy</name>
	<t>	<t>

	Registry operators may change their policies relating to TTL values from time to	Registry operators may change their policies relating to TTL values
	time.	from time to time. Previously configured TTL values may
	Previously configured TTL values may consequently fall outside a newly-applied p	consequently fall outside a newly applied policy. This document
	olicy.	places no obligation on EPP server operators in respect of these
	This document places no obligation on EPP server operators in respect of these v	values, and server operators may, as part of a policy change, change
	alues,	the TTL values specified by clients for domain and host objects.
	and server operators may, as part of a policy change, change the TTL values spec	<xref target="oob-changes"/> describes how such out-of-band changes
	ified by clients for domain and host objects.	should be carried out.</t>
	<xref target="oob-changes"/> describes how such out-of-band changes should be ca
	rried out.
	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="security-considerations" title="Security considerations">	<section anchor="security-considerations">
	<section title="Fast-flux DNS">	<name>Security Considerations</name>
		<section>
		<name>Fast Flux DNS</name>
	<t>	<t>

	Some malicious actors use a technique called "fast flux DNS" (<xref target="SAC-	Some malicious actors use a technique called "fast flux DNS" <xref
	025"/>) to rapidly change the DNS configuration for a zone in order to evade tak	target="SAC-025"/> to rapidly change the DNS configuration for a
	edown and law enforcement activity.	zone in order to evade takedown and law enforcement activity.
	Server operators should take this into consideration when setting the lower limi	Server operators should take this into consideration when setting
	t on TTL values, since a short TTL on delegations may enhance the effectiveness	the lower limit on TTL values, since a short TTL on delegations may
	of fast flux techniques on evasion.	enhance the effectiveness of fast flux techniques on evasion.</t>
	</t>
	<t>	<t>

	Client implementations which provide an interface for customers to configure TTL	Client implementations that provide an interface for customers to
	values for domain names should consider implementing controls to deter and miti	configure TTL values for domain names should consider implementing
	gate abusive behaviour,	controls to deter and mitigate abusive behavior, such as those
	such as those outlined in the "Current and Possible Mitigation Alternatives" sec	outlined in the "Current and Possible Mitigation Alternatives"
	tion of <xref target="SAC-025"/>.	section of <xref target="SAC-025"/>.</t>
	</t>
	</section>	</section>

	<section title="Compromised user accounts">	<section>
		<name>Compromised User Accounts</name>
	<t>	<t>

	An attacker who obtains access to a customer account at a domain registrar which	An attacker who obtains access to a customer account at a domain
	supports this extension could make unauthorised changes to the <tt>NS</tt> and/	registrar that supports this extension could make unauthorized
	or glue records for a domain,	changes to the <tt>NS</tt> and/or glue records for a domain, and
	and then increase the associated TTLs so that the changes persist in caches for	then increase the associated TTLs so that the changes persist in
	a long time after the attack has been detected.	caches for a long time after the attack has been detected.</t>
	</t>
	<t>	<t>

	Client implementations which provide an interface for customers to configure TTL	Client implementations that provide an interface for customers to
	values for domain names should consider implementing upper limits in order to r	configure TTL values for domain names should consider implementing
	educe the impact of account compromise,	upper limits in order to reduce the impact of account compromise, in
	in addition to best practices relating to credential management, multi-factor au	addition to best practices relating to credential management,
	thentication, risk-based access control, and so on.	multi-factor authentication, risk-based access control, and so on.</t>
	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="IANA" title="IANA considerations">	<section anchor="IANA">
	<section title="XML namespace">	<name>IANA Considerations</name>
	<t>	<section>
	This document uses URNs to describe XML namespaces and XML schemas conforming to	<name>XML Namespace</name>
	a registry mechanism described in <xref target="RFC3688"/>.	<t>This document uses URNs to describe XML namespaces and XML schemas
	The following URI assignment is requested of IANA:	conforming to a registry mechanism described in <xref
	</t>	target="RFC3688"/>. The following URI assignments have been made by
	<t>	IANA:</t>
	Registration for the TTL namespace:
	</t>	<t>Registration for the TTL namespace:</t>
	<list>	<dl spacing="compact" newline="false">
	<t>	<dt>URI:</dt><dd><tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt></dd>
	<strong>URI:</strong>	<dt>Registrant Contact:</dt><dd>IESG</dd>
	<tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt>	<dt>XML:</dt><dd>None. Namespace URIs do not represent an XML specific
	</t>	ation.</dd>
	<t><strong>Registrant Contact:</strong> IESG	</dl>
	</t>
	<t><strong>XML:</strong> None. Namespace URIs do not represent an XML	<t>Registration for the TTL XML schema:</t>
	specification	<dl spacing="compact" newline="false">
	</t>	<dt>URI:</dt><dd><tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt></dd>
	</list>	<dt>Registrant Contact:</dt><dd>IESG</dd>
	<t>	<dt>XML:</dt><dd>See <xref target="formal-syntax"/> of this
	Registration for the TTL XML schema:	document.</dd>
	</t>	</dl>
	<list>
	<t>
	<strong>URI:</strong>
	<tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt>
	</t>
	<t><strong>Registrant Contact:</strong> IESG
	</t>
	<t><strong>XML:</strong> See the "<xref target="formal-syntax" format=
	"title"/>" section of this document
	</t>
	</list>
	</section>	</section>

	<section title="EPP extension registry">	<section>
	<t>	<name>EPP Extension Registry</name>
	The EPP extension described in this document is to be registered by IANA in the
	Extensions for the "Extensible Provisioning Protocol (EPP)" registry described i	<t>The EPP extension described in this document has been registered by
	n <xref target="RFC7451"/>.	IANA in the "Extensions for the Extensible Provisioning Protocol
	The details of the registration are as follows:	(EPP)" registry described in <xref target="RFC7451"/>. The details of
	</t>	the registration are as follows:</t>
	<list>
	<t><strong>Name of Extension:</strong> Extensible Provisioning Protoco	<dl spacing="compact" newline="false">
	l (EPP) Mapping for DNS Time-To-Live (TTL) values	<dt>Name of Extension:</dt>
	</t>	<dd>Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live
	<t><strong>Document Status:</strong> Standards Track	(TTL) Values</dd>
	</t>
	<t><strong>Reference:</strong> URL of this document	<dt>Document Status:</dt>
	</t>	<dd>Standards Track</dd>
	<t><strong>Registrant Name and Email Address:</strong> IESG
	</t>	<dt>Reference:</dt>
	<t><strong>TLDs:</strong> Any	<dd>RFC 9803</dd>
	</t>
	<t><strong>IPR Disclosure:</strong> None	<dt>Registrant:</dt>
	</t>	<dd>IESG</dd>
	<t><strong>Status:</strong> Active
	</t>	<dt>TLDs:</dt>
	<t><strong>Notes:</strong> None	<dd>Any</dd>
	</t>
	</list>	<dt>IPR Disclosure:</dt>
		<dd>None</dd>

		<dt>Status:</dt>
		<dd>Active</dd>

		<dt>Notes:</dt>
		<dd>None</dd>
		</dl>
	</section>	</section>
	</section>	</section>

	<section anchor="formal-syntax" title="Formal syntax">	<section anchor="formal-syntax">
		<name>Formal Syntax</name>
	<t>	<t>

	The formal syntax presented here is a complete schema representation of the exte	The formal syntax presented here is a complete schema representation
	nsion suitable for automated validation of EPP XML instances.	of the extension suitable for automated validation of EPP XML
	</t>	instances.</t>
	<sourcecode><?xml version="1.0" encoding="UTF-8"?>
	<schema	<sourcecode type="xml" markers="false"><![CDATA[
		<?xml version="1.0" encoding="UTF-8"?>
		<schema
	xmlns="http://www.w3.org/2001/XMLSchema"	xmlns="http://www.w3.org/2001/XMLSchema"
	targetNamespace="urn:ietf:params:xml:ns:epp:ttl-1.0"	targetNamespace="urn:ietf:params:xml:ns:epp:ttl-1.0"
	xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"	xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"

	elementFormDefault="qualified">	elementFormDefault="qualified">
	<annotation>	<annotation>
	<documentation>	<documentation>
	Extensible Provisioning Protocol v1.0 extension	Extensible Provisioning Protocol v1.0 extension

	schema for Time-To-Live (TTL) values for domain	schema for Time-to-Live (TTL) Values for domain
	and host objects.	and host objects.

	</documentation>	</documentation>
	</annotation>	</annotation>


	<element name="info">	<element name="info">
	<complexType>	<complexType>
	<attribute name="policy" type="boolean" default="false"/>	<attribute name="policy" type="boolean" default="false"/>
	</complexType>	</complexType>
	</element>	</element>


	<!--	<!--
	<ttl> elements can appear in <create> and	<ttl> elements can appear in <create> and
	<update> commands, and <info> responses	<update> commands, and <info> responses
	-->	-->


	<element name="create" type="ttl:commandContainer">	<element name="create" type="ttl:commandContainer">
	<unique name="uniqueRRTypeForCreate">	<unique name="uniqueRRTypeForCreate">
	<selector xpath="ttl:ttl"/>	<selector xpath="ttl:ttl"/>
	<field xpath="@for"/>	<field xpath="@for"/>
	</unique>	</unique>
	</element>	</element>


	<element name="update" type="ttl:commandContainer">	<element name="update" type="ttl:commandContainer">
	<unique name="uniqueRRTypeForUpdate">	<unique name="uniqueRRTypeForUpdate">
	<selector xpath="ttl:ttl"/>	<selector xpath="ttl:ttl"/>
	<field xpath="@for"/>	<field xpath="@for"/>
	</unique>	</unique>
	</element>	</element>


	<element name="infData" type="ttl:responseContainer">	<element name="infData" type="ttl:responseContainer">
	<unique name="uniqueRRTypeForInfo">	<unique name="uniqueRRTypeForInfo">
	<selector xpath="ttl:ttl"/>	<selector xpath="ttl:ttl"/>
	<field xpath="@for"/>	<field xpath="@for"/>
	</unique>	</unique>
	</element>	</element>


	<complexType name="commandContainer">	<complexType name="commandContainer">
	<sequence>	<sequence>
	<element	<element
	name="ttl"	name="ttl"
	type="ttl:commandTTLType"	type="ttl:commandTTLType"
	minOccurs="1"	minOccurs="1"

	maxOccurs="unbounded"/>	maxOccurs="unbounded"/>
	</sequence>	</sequence>
	</complexType>	</complexType>


	<complexType name="responseContainer">	<complexType name="responseContainer">
	<sequence>	<sequence>
	<element	<element
	name="ttl"	name="ttl"
	type="ttl:responseTTLType"	type="ttl:responseTTLType"
	minOccurs="1"	minOccurs="1"

	maxOccurs="unbounded"/>	maxOccurs="unbounded"/>
	</sequence>	</sequence>
	</complexType>	</complexType>


	<complexType name="commandTTLType">	<complexType name="commandTTLType">
	<simpleContent>	<simpleContent>
	<extension base="ttl:ttlOrNull">	<extension base="ttl:ttlOrNull">
	<attribute	<attribute
	name="for"	name="for"
	type="ttl:rrType"	type="ttl:rrType"

	use="required"/>	use="required"/>


	<attribute	<attribute
	name="custom"	name="custom"

	type="ttl:customRRType"/>	type="ttl:customRRType"/>
	</extension>	</extension>
	</simpleContent>	</simpleContent>
	</complexType>	</complexType>


	<complexType name="responseTTLType">	<complexType name="responseTTLType">
	<simpleContent>	<simpleContent>
	<extension base="ttl:ttlOrNull">	<extension base="ttl:ttlOrNull">
	<attribute	<attribute
	name="for"	name="for"
	type="ttl:rrType"	type="ttl:rrType"

	use="required"/>	use="required"/>


	<attribute	<attribute
	name="custom"	name="custom"

	type="ttl:customRRType"/>	type="ttl:customRRType"/>


	<attribute	<attribute
	name="min"	name="min"

	type="ttl:ttlValue"/>	type="ttl:ttlValue"/>


	<attribute	<attribute
	name="default"	name="default"

	type="ttl:ttlValue"/>	type="ttl:ttlValue"/>


	<attribute	<attribute
	name="max"	name="max"

	type="ttl:ttlValue"/>	type="ttl:ttlValue"/>
	</extension>	</extension>
	</simpleContent>	</simpleContent>
	</complexType>	</complexType>


	<!--	<!--
	union type allowing the element to either contain	union type allowing the element to either contain
	nothing or a TTL value	nothing or a TTL value

	-->	-->
	<simpleType name="ttlOrNull">	<simpleType name="ttlOrNull">
	<union	<union
	memberTypes="ttl:emptyValue ttl:ttlValue"/>	memberTypes="ttl:emptyValue ttl:ttlValue"/>
	</simpleType>	</simpleType>


	<!-- empty value type -->	<!-- empty value type -->
	<simpleType name="emptyValue">	<simpleType name="emptyValue">
	<restriction base="token">	<restriction base="token">
	<length value="0"/>	<length value="0"/>
	</restriction>	</restriction>
	</simpleType>	</simpleType>


	<!-- TTL value type -->	<!-- TTL value type -->
	<simpleType name="ttlValue">	<simpleType name="ttlValue">
	<restriction base="nonNegativeInteger">	<restriction base="nonNegativeInteger">
	<minInclusive value="0"/>	<minInclusive value="0"/>
	<maxInclusive value="2147483647"/>	<maxInclusive value="2147483647"/>
	</restriction>	</restriction>
	</simpleType>	</simpleType>


	<!-- resource record mnemonic type -->	<!-- resource record mnemonic type -->
	<simpleType name="rrType">	<simpleType name="rrType">
	<restriction base="token">	<restriction base="token">
	<enumeration value="NS" />	<enumeration value="NS" />
	<enumeration value="DS" />	<enumeration value="DS" />
	<enumeration value="DNAME" />	<enumeration value="DNAME" />
	<enumeration value="A" />	<enumeration value="A" />
	<enumeration value="AAAA" />	<enumeration value="AAAA" />
	<enumeration value="custom" />	<enumeration value="custom" />
	</restriction>	</restriction>
	</simpleType>	</simpleType>

		<!-- custom resource record type -->
		<simpleType name="customRRType">
		<restriction base="token">
		<pattern value="A\|[A-Z][A-Z0-9\-]*[A-Z0-9]"/>
		</restriction>
		</simpleType>
		</schema>
		]]></sourcecode>


	<!-- custom resource record type -->
	<simpleType name="customRRType">
	<restriction base="token">
	<pattern value="A\|[A-Z][A-Z0-9\-]*[A-Z0-9]"/>
	</restriction>
	</simpleType>
	</schema>
	</sourcecode>
	</section>
	<section anchor="implementation-status" title="Implementation status" remove
	InRFC="true">
	<section title="Verisign EPP SDK">
	<t><strong>Organization:</strong> Verisign Inc.
	</t>
	<t><strong>Name:</strong> Verisign EPP SDK
	</t>
	<t><strong>Description:</strong> The Verisign EPP SDK includes both a fu
	ll client implementation and a full server stub implementation of this specifica
	tion.
	</t>
	<t><strong>Level of maturity:</strong> Development
	</t>
	<t><strong>Coverage:</strong> All aspects of the protocol are implemente
	d.
	</t>
	<t><strong>Licensing:</strong> GNU Lesser General Public License
	</t>
	<t><strong>Contact:</strong> jgould@verisign.com
	</t>
	<t><strong>URL:</strong> https://www.verisign.com/en_US/channel-resource
	s/domain-registry-products/epp-sdks
	</t>
	</section>
	<section title="Pepper EPP Client">
	<t><strong>Name:</strong> Pepper EPP Client
	</t>
	<t><strong>Description:</strong> The Pepper EPP client fully implements
	this specification.
	The underlying <tt>Net::EPP::</tt> Perl module also implements this specificatio
	n.
	</t>
	<t><strong>Level of maturity:</strong> Development
	</t>
	<t><strong>Coverage:</strong> All aspects of the protocol will be implem
	ented.
	</t>
	<t><strong>Licensing:</strong> Perl Artistic License
	</t>
	<t><strong>Contact:</strong> The author of this document.
	</t>
	<t><strong>URL:</strong> https://github.com/gbxyz/pepper
	</t>
	</section>
	</section>
	<section title="Change log" anchor="change_log" removeInRFC="true">
	<section title="Changes from 17 to 18">
	<ol>
	<li>
	Add a space after the <tt>C:</tt> and <tt>S:</tt> line prefixes in examples.
	</li>
	<li>
	Fixed the prefixing of lines in the example in Section 2.1.1.2 (thanks Tim Bray)
	.
	</li>
	<li>
	Fixed broken end tags in examples in Section 1.2.2 and the capitalisation of IPv
	6 addresses (thanks Erik Kline).
	</li>
	<li>
	Added normative reference to <xref target="IANA-RRTYPES"/>.
	</li>
	<li>
	Replaced references to "command/response frames" with "EPP commands/responses".
	</li>
	<li>
	Minor wording change in paragraph 2 of <xref target="ttl_element"/>.
	</li>
	<li>
	Clarified wording in <xref target="supported-dns-record-types"/>.
	</li>
	<li>
	Wordsmithing of <xref target="server-processing"/> due to feedback from the IESG
	.
	</li>
	</ol>
	</section>
	<section title="Changes from 16 to 17">
	<ol>
	<li>
	Further updates as suggested during IESG review.
	</li>
	</ol>
	</section>
	<section title="Changes from 15 to 16">
	<ol>
	<li>
	Updates as suggested during IESG review.
	</li>
	</ol>
	</section>
	<section title="Changes from 14 to 15">
	<ol>
	<li>
	Updates as suggested during AD review.
	</li>
	<li>
	In the last paragraph of Section 3.2, make both lists of RR types be the same.
	</li>
	<li>
	Update error codes to be consistent: 2004 (range error) when the TTL value is ou
	tside the permitted range,
	and 2306 (policy error) for an invalid record type.
	</li>
	<li>
	Correct section in reference to RFC 6895 (thanks Jasdip Singh).
	</li>
	<li>
	Minor typographic fixes (thanks Jasdip Singh).
	</li>
	</ol>
	</section>
	<section title="Changes from 13 to 14">
	<ol>
	<li>
	Resolve remaining nit before IESG submission.
	</li>
	</ol>
	</section>
	<section title="Changes from 12 to 13">
	<ol>
	<li>
	Updates as per the document shepherd's suggestions.
	</li>
	</ol>
	</section>
	<section title="Changes from 11 to 12">
	<ol>
	<li>
	Updates as per the document shepherd's email to the list of 2024-06-10.
	</li>
	</ol>
	</section>
	<section title="Changes from 10 to 11">
	<ol>
	<li>
	Fix double word in <xref target="using_ttl_values"/>.
	</li>
	</ol>
	</section>
	<section title="Changes from 09 to 10">
	<t>
	Changes resulting from the Dnsdir review:
	</t>
	<ol>
	<li>
	Fixed example IPv6 addresses to use the preferred prefix 2001:DB8::.
	</li>
	<li>
	Added paragraph to <xref target="permitted-types"/> describing how clients can u
	se the Policy Mode <tt><info></tt> command (<xref target="policy-mode"/>)
	to discover the DNS record types supported by the server.
	</li>
	</ol>
	</section>
	<section title="Changes from 08 to 09">
	<ol>
	<li>
	Some wording changes suggested by James Gould and Tim Wicinski.
	</li>
	</ol>
	</section>
	<section title="Changes from 07 to 08">
	<ol>
	<li>
	Some wording changes suggested by Rick Wilhelm.
	</li>
	</ol>
	</section>
	<section title="Changes from 06 to 07">
	<ol>
	<li>
	Minor wording changes and nits reported by JG.
	</li>
	</ol>
	</section>
	<section title="Changes from 05 to 06">
	<ol>
	<li>
	Changed how <tt><info></tt> commands work so that a <tt><ttl:info></
	tt> element is required in order for <tt><ttl:ttl></tt> elements to be inc
	luded in the response.
	Thanks to JG for this feedback.
	</li>
	</ol>
	</section>
	<section title="Changes from 04 to 05">
	<ol>
	<li>
	removed the erroneous <tt>required="true"</tt> attribute from the <tt>min</tt>,
	<tt>default</tt> and <tt>max</tt> attributes of the <tt>responseTTLType</tt> typ
	e (thanks JG).
	</li>
	<li>
	fixed the reference to RFC 6895 (thanks HS).
	</li>
	</ol>
	</section>
	<section title="Changes from 04 to 05">
	<ol>
	<li>
	Add the Verisign EPP SDK to <xref target="implementation-status"/>.
	</li>
	<li>
	Add the <tt><ttl:info></tt> element and document how it affects server <tt
	><info></tt> responses.
	</li>
	<li>
	Updated examples to exercise more of the schema.
	</li>
	<li>
	Minor schema issue fixed.
	</li>
	</ol>
	</section>
	<section title="Changes from 03 to 04">
	<ol>
	<li>
	Changed the <tt>for</tt> attribute to be an enumeration and added the <tt>custom
	</tt> attribute.
	</li>
	<li>
	Added the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributes.
	</li>
	<li>
	Apply feedback from Jim Gould.
	</li>
	</ol>
	</section>
	<section title="Changes from 02 to 03">
	<ol>
	<li>
	Rolled back the "straw man" syntax from 02.
	<tt>ttl:ttl</tt> now has a <tt>for</tt> attribute which can be any DNS record ty
	pe.
	<xref target="supported-dns-record-types"/> describes how the set of supported r
	ecord types may be limited.
	</li>
	<li>
	Removed the global/explicit models and just use the explicit model.
	</li>
	<li>
	Removed the cascading effect where a TTL set on a domain affects subordinate hos
	ts.
	</li>
	</ol>
	</section>
	<section title="Changes from 01 to 02">
	<ol>
	<li>
	Renamed the <tt>ttl:seconds</tt> XSD type to <tt>ttl:container</tt>, and the <tt
	>ttl:nonNegativeInteger</tt> type to <tt>ttl:ttlType</tt>, to permit multiple TT
	L values.
	</li>
	<li>
	Converted XML instances from artwork to source code.
	</li>
	</ol>
	</section>
	<section title="Changes from 00 to 01">
	<ol>
	<li>
	Incorporate feedback from Jim Gould.
	</li>
	<li>
	Add wording to describe how TTL values are jointly managed by both clients and s
	ervers.
	</li>
	<li>
	Fix minimum/maximum TTL value and schema namespace (thanks Patrick Mevzek).
	</li>
	<li>
	Moved text on how the server should handle impermissible TTL values from the top
	of Section 4 to Sections 3.2.1 and 3.2.2 (thanks Rick Wilhelm).
	</li>
	<li>
	Namespace changed from <tt>urn:ietf:params:xml:ns:ttl-1.0</tt> to <tt>urn:ietf:p
	arams:xml:ns:epp:ttl-1.0</tt>.
	</li>
	<li>
	Added discussion on EPP servers which use the host attribute model in <xref targ
	et="using_ttl_values"/> (thanks Hugo Salgado).
	</li>
	<li>
	Added a <xref target="change_log">Change Log</xref>.
	</li>
	</ol>
	</section>
	</section>
	<section title="Acknowledgements">
	<t>
	The author wishes to thank the following people for their advice and feedback du
	ring the development of this document:
	</t>
	<ol>
	<li>James Gould</li>
	<li>Hugo Salgado</li>
	<li>Patrick Mevzek</li>
	<li>Rick Wilhelm</li>
	<li>Marc Groeneweg</li>
	<li>Ties de Kock</li>
	<li>Tim Wicinski</li>
	<li>Jasdip Singh</li>
	</ol>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>

	<references title="Normative references">	<references>
	&RFC2119;	<name>References</name>
	&RFC3688;	<references>
	&RFC5731;	<name>Normative References</name>
	&RFC5732;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	&RFC5910;	119.xml"/>
	&RFC6895;	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	&RFC8174;	688.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<reference anchor="XSD-DATATYPES" target="https://www.w3.org/TR/xmlschema-2/"><f	731.xml"/>
	ront><title>XML Schema Part 2: Datatypes Second Edition</title><author><organiza	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	tion>World Wide Web Consortium (W3C)</organization></author><date month="October	732.xml"/>
	" year="2004"/></front></reference>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		910.xml"/>
	<reference anchor="IANA-RRTYPES" target="https://www.iana.org/assignments/dns-pa	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	rameters/dns-parameters.xhtml#dns-parameters-4"><front><title>Resource Record (R	895.xml"/>
	R) TYPEs</title><author><organization>IANA</organization></author></front></refe	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	rence>	174.xml"/>

	</references>
	<references title="Informative references">
	&RFC6927;
	&RFC7451;
	&RFC8590;
	&RFC9364;
	&RFC9499;


	<reference anchor="SAC-025" target="https://www.icann.org/en/system/files/files/	<reference anchor="XSD-DATATYPES" target="https://www.w3.org/TR/2004/REC
	sac-025-en.pdf"><front><title>SSAC Advisory on Fast Flux Hosting and DNS</title>	-xmlschema-2-20041028/">
	<author><organization>ICANN Security and Stability Advisory Committee (SSAC)</or	<front>
	ganization></author><date month="January" year="2008"/></front><seriesInfo name=	<title>XML Schema Part 2: Datatypes Second Edition</title>
	"SAC" value="25"/></reference>	<author initials="P." surname="Biron" fullname="Paul V. Biron" role=
		"editor"/>
		<author initials="A." surname="Malhotra" fullname="Ashok Malhotra" r
		ole="editor"/>
		<date month="October" year="2004"/>
		</front>
		<refcontent>W3C Recommendation</refcontent>
		<annotation>Latest version available at <eref target="https://www.w3.o
		rg/TR/xmlschema-2/" brackets="angle"/>.</annotation>
		</reference>
		<reference anchor="IANA-RRTYPES" target="https://www.iana.org/assignment
		s/dns-parameters">
		<front>
		<title>Resource Record (RR) TYPEs</title>
		<author>
		<organization>IANA</organization>
		</author>
		</front>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		927.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		451.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		590.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		364.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		499.xml"/>
		<reference anchor="SAC-025" target="https://www.icann.org/en/system/file
		s/files/sac-025-en.pdf">
		<front>
		<title>SSAC Advisory on Fast Flux Hosting and DNS</title>
		<author>
		<organization>ICANN Security and Stability Advisory Committee (SSA
		C)</organization>
		</author>
		<date month="January" year="2008"/>
		</front>
		<seriesInfo name="SAC" value="025"/>
		</reference>
		</references>
		</references>


	</references>	<section numbered="false">
		<name>Acknowledgments</name>
		<t>The author wishes to thank the following people for their advice and
		feedback during the development of this document:</t>
		<ul>
		<li><t><contact fullname="James Gould"/></t></li>
		<li><t><contact fullname="Hugo Salgado"/></t></li>
		<li><t><contact fullname="Patrick Mevzek"/></t></li>
		<li><t><contact fullname="Rick Wilhelm"/></t></li>
		<li><t><contact fullname="Marc Groeneweg"/></t></li>
		<li><t><contact fullname="Ties de Kock"/></t></li>
		<li><t><contact fullname="Tim Wicinski"/></t></li>
		<li><t><contact fullname="Jasdip Singh"/></t></li>
		</ul>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 138 change blocks.
	1334 lines changed or deleted	1122 lines changed or added
This html diff was produced by rfcdiff 1.48.