<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-brown-rdap-ttl-extension-00" submissionType="IETF" category="std" xml:lang="en" indexInclude="true" consensus="true">

<front>
  <title abbrev="RDAP TTL Extension">RDAP Extension for DNS Time-To-Live (TTL Values)</title>
  <seriesInfo value="draft-brown-rdap-ttl-extension" stream="IETF" status="standard" name="Internet-Draft"/>
  <author initials="G." surname="Brown" fullname="Gavin Brown">
    <organization>ICANN</organization>
    <address>
      <postal>
        <street>12025 Waterfront Drive, Suite 300</street>
        <city>Los Angeles</city>
        <code>90094-2536</code>
        <country>US</country>
        <region>CA</region>
      </postal>
      <email>gavin.brown@icann.org</email>
    </address>
  </author>
  <date/>
  <area>Internet</area>
  <workgroup>Registration Extensions (REGEXT)</workgroup>

<abstract><t>
This document describes an extension to the Registration Data Access Protocol (<xref target="RFC9083"/>) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses.
</t></abstract>

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

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>
While <xref target="RFC9083"/> allows RDAP server operators to provide information about the content of the <tt>NS</tt>, <tt>DS</tt>, <tt>A</tt> and <tt>AAAA</tt> record(s) which are published in the DNS for a given registry object (domain or host object), it does not provide a mechanism to allow the Time-To-Live (TTL) values of those records to be included in responses.
</t>

<t>
This document describes how TTL information can be included in domain and nameserver objects in RDAP responses.
</t>

<t>
This document is complementary to the EPP TTL extension (<xref target="I-D.ietf-regext-epp-ttl"/>), but registry operators do not need to implement that extension in their EPP server in order to implement this RDAP extension.
</t>

</section>

<section><name>Conventions used in this document</name>

<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as 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 anchor="rdap-response-specification"><name>RDAP Response Specification</name>
<t>
Servers which support this extension <bcp14>MUST</bcp14> include a <tt>ttl_values</tt> object in any domain and nameserver objects included in RDAP responses.
</t>

<t>
The <tt>ttl_values</tt> object has property names which are DNS record types, and values which are integers representing the TTL values used for those record types.
</t>

<t>
Example domain object:
</t>

<sourcecode><![CDATA[{
    "objectClassName": "domain",
    "ldhName": "example.com",
    "ttl_values": {
        "NS": 3600,
        "DS": 60
    }
}]]></sourcecode>

<t>
Example nameserver object:
</t>

<sourcecode><![CDATA[{
    "objectClassName": "nameserver",
    "ldhName": "ns1.example.com",
    "ttl_values": {
        "A": 86400,
        "AAAA": 172800
    }
}]]></sourcecode>

<section anchor="rdap-conformance"><name>RDAP Conformance</name><t>
Servers returning responses containing TTL values <bcp14>MUST</bcp14> include the string "<tt>ttl</tt>" in the <tt>rdapConformance</tt> array.
</t></section>

</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>
IANA is requested to register the following value in the RDAP Extensions Registry:
</t>

<t>
<strong>Extension identifier:</strong> <tt>ttl</tt>
</t>

<t>
<strong>Registry operator:</strong> Any
</t>

<t>
<strong>Published specification:</strong> this document
</t>

<t>
<strong>Contact:</strong> IETF &lt;<eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref>&gt;
</t>

<t>
<strong>Intended usage:</strong> this extension describes how DNS TTL values can be included in RDAP responses.
</t>

</section>

</middle>

<back>
  <references>
    <name>Normative References</name>
    <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
    <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
    <reference anchor="RFC9083" target="https://www.rfc-editor.org/info/rfc9083">
  <front>
    <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
    <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/>
    <author fullname="A. Newton" initials="A." surname="Newton"/>
    <date month="June" year="2021"/>
    <abstract>
      <t>This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="95"/>
  <seriesInfo name="RFC" value="9083"/>
  <seriesInfo name="DOI" value="10.17487/RFC9083"/>
</reference>
  </references>

  <references>
    <name>Informative References</name>
    <reference anchor="I-D.ietf-regext-epp-ttl" target="https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-04">
  <front>
    <title>Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values</title>
    <author fullname="Gavin Brown" initials="G." surname="Brown">
      <organization>ICANN</organization>
    </author>
    <date day="14" month="December" year="2023"/>
    <abstract>
      <t>This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-ttl-extension.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-regext-epp-ttl-04"/>
</reference>
  </references>
</back>

</rfc>
