Internet DRAFT - draft-ellacott-historical-rdap

draft-ellacott-historical-rdap







Network Working Group                                        B. Ellacott
Internet-Draft                                               T. Harrison
Intended status: Standards Track                           APNIC Pty Ltd
Expires: December 30, 2017                                 June 28, 2017


      History of records in the Registration Data Access Protocol
                   draft-ellacott-historical-rdap-00

Abstract

   The Registration Data Access Protocol (RDAP) provides current
   registration information.  This document describes an RDAP query and
   response extension that allows retrieving historical registration
   records.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 30, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Ellacott & Harrison     Expires December 30, 2017               [Page 1]

Internet-Draft               History in RDAP                   June 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  JSON Responses  . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  The History Object Class  . . . . . . . . . . . . . . . .   2
     2.2.  The Record Data Structure . . . . . . . . . . . . . . . .   3
   3.  RDAP Historical Path Segment Specification  . . . . . . . . .   4
     3.1.  IP Network History Path Segment Specification . . . . . .   4
     3.2.  Autonomous System History Path Segment Specification  . .   4
     3.3.  Domain History Path Segment Specification . . . . . . . .   4
     3.4.  Nameserver History Path Segment Specification . . . . . .   5
     3.5.  Entity History Path Segment Specification . . . . . . . .   5
   4.  Query Processing  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Internationalization Considerations . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  An example History response  . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Registration Data Access Protocol (RDAP) offers simple search and
   responses as defined in [RFC7482] and [RFC7483] respectively.  Both
   the search and response documents implicitly describe current
   registration information.  This document provides an extension to
   RDAP allowing the discovery of historical registration information.

1.1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  JSON Responses

   The JSON responses described in [RFC7483] are extended with one
   additional object class, the History object class, described below.

2.1.  The History Object Class

   The history object class is a container in which individual
   registration records are listed, together comprising a history of




Ellacott & Harrison     Expires December 30, 2017               [Page 2]

Internet-Draft               History in RDAP                   June 2017


   registration.  The registration records are represented in the form
   given in [RFC7483], without change.

   The history object class can contain the following members:

   o  objectClassName -- the string "history"

   o  records -- an array of record objects, defined in the next
      subsection

   In addition, any of the common data structures defined in section 4
   of [RFC7483] may be included in accordance with the constraints of
   that section, with the following additional considerations.

   o  Any "rdapConformance" structure in the topmost object of a
      response including a History object MUST include the string
      "history_0" to indicate to clients that the response conforms to
      this specification.

   o  An events structure MAY be included, but none of the values
      defined in section 10.2.3 of [RFC7483] are suitable for a History
      object class.  Future values in the "RDAP JSON Values" registry
      may be suitable, however.

2.2.  The Record Data Structure

   The record data structure describes one historical registration
   record.  It is an object containing the date range during which this
   record was current, and the record's content.  The content of a
   historical record is a JSON response element as defined in [RFC7483].
   In this way, history is defined for all RDAP object classes, and may
   be extended to apply to non-standard or new RDAP object classes
   without requiring a revision to the history specification.

   The date range of the historical registration record consists of an
   element indicating the first moment at which the contained record was
   current, in the "applicableFrom" element, and an element indicating
   the first moment at which the contained record was no longer current,
   in the "applicableUntil" element.  The date range is half-open,
   including the "applicableFrom" date but excluding the
   "applicableUntil" date.  If the "applicableUntil" date is not
   included in the response, this indicates that the associated content
   was current at the time the response was generated.

   An example of the record data structure:






Ellacott & Harrison     Expires December 30, 2017               [Page 3]

Internet-Draft               History in RDAP                   June 2017


              {
                  "applicableFrom": "2008-09-04T06:51:49Z",
                  "applicableUntil": "2008-09-04T07:27:55Z",
                  "content": {
                      "objectClassName": "ip network",
                      ...
                  }
              }

3.  RDAP Historical Path Segment Specification

   Path segments for querying registration data are defined in [RFC7482]
   for five resource types (ip, autnum, domain, nameserver, and entity).
   In addition to these segments, this document defines one additional
   path segment, 'history', for querying the historical data of any of
   the five resource types, where supported by the server.

   The history access specified in this document does not support
   searches.

3.1.  IP Network History Path Segment Specification

   Syntax: "history/ip/<IP address>" or "history/ip/<CIDR prefix>/<CIDR
   length>"

   Queries for the history of IP networks follow the same form as for
   the current registration of IP networks.  However, while the current
   registration query will select the "most-specific" or smallest IP
   network that completely encompasses the query network, an historical
   query selects all networks intersecting the query range.

   A server MAY choose to limit the number of networks selected by a
   query, by limiting the size of sub-networks, or the total number, or
   some other means.

3.2.  Autonomous System History Path Segment Specification

   Syntax: "history/autnum/<autonomous system number>"

   Queries for the history of an autonomous system number follow the
   same form as for the current registration of autonomous system
   numbers.

3.3.  Domain History Path Segment Specification

   Syntax: "history/domain/<domain name>"





Ellacott & Harrison     Expires December 30, 2017               [Page 4]

Internet-Draft               History in RDAP                   June 2017


   Queries for the history of a domain registration.  As with [RFC7482]
   the domain is fully qualified, and SHOULD NOT be represented as a
   mixture of A-labels and U-labels.

3.4.  Nameserver History Path Segment Specification

   Syntax: "history/nameserver/<nameserver name>"

   Queries for the history of a nameserver.  As with [RFC7482] the name
   is a fully qualified host name represented in either A-label or
   U-label format.

3.5.  Entity History Path Segment Specification

   Syntax: "history/entity/<handle>"

   Queries for the history of an entity.  The syntax of the handle is
   specific to the registration provider.

4.  Query Processing

   The processing of queries proceeds as in [RFC7482] and [RFC7480].
   Associated records, as documented in section 4.2 of [RFC7482],
   contribute to the history of a registration record, and so any change
   to the record or any of its associated records SHOULD be included in
   the response to a history query.

   A server MAY choose to limit the responses given to a history query.
   For example, the date range of returned records may be restricted, or
   the number of distinct records may be limited.  A server MAY choose
   to abridge history, such as eliding a short-lived record state.  If a
   server limites responses in this way, it SHOULD indicate to the user
   that it has done so, either through the "help" path segment
   documented in [RFC7482], or in a "notice" element as documented in
   section 4.3 of [RFC7483] using an appropriate notice type such as
   "result set truncated due to unexplainable reasons".

5.  Internationalization Considerations

   Character encoding considerations are described in section 6.1 of
   [RFC7482].

6.  IANA Considerations

   The IANA is requested to add this document to the IANA RDAP
   Extensions Registry.





Ellacott & Harrison     Expires December 30, 2017               [Page 5]

Internet-Draft               History in RDAP                   June 2017


   TO BE REMOVED: This registration should take place at
   <https://www.iana.org/assignments/rdap-extensions/rdap-
   extensions.xhtml>

   Extension identifier: history_0

   Registry operator: Asia Pacific Network Information Center

   Published specification: TBD

   Person & email address to contact for further information: Byron
   Ellacott <mailto:bje@apnic.net>

   Intended usage: This extension allows an RDAP operator to provide
   historical registration data.

7.  Security Considerations

   Historical records may contain information which was inadvertently
   entered into a record, and subsequently amended.  It may contain
   information which was removed by request of the information holder.
   Additional privacy constraints may apply to data held for a long
   period.  Operators of a history-capable RDAP service SHOULD ensure
   they have understood the privacy implications of this facility.

   A query for historical records may consume more computing resources
   than a query for current records.  Implementations SHOULD take care
   to offer operators the appropriate means to manage the operational
   cost of a historical service, limiting query rates or response sizes
   or both, where appropriate.

8.  Acknowledgements

   Substantial feedback on the initial draft was provided by Andrew
   Newton of ARIN.

9.  References

9.1.  Normative References

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", RFC 7480,
              DOI 10.17487/RFC7480, March 2015,
              <http://www.rfc-editor.org/info/rfc7480>.







Ellacott & Harrison     Expires December 30, 2017               [Page 6]

Internet-Draft               History in RDAP                   June 2017


   [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
              Protocol (RDAP) Query Format", RFC 7482,
              DOI 10.17487/RFC7482, March 2015,
              <http://www.rfc-editor.org/info/rfc7482>.

   [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", RFC 7483,
              DOI 10.17487/RFC7483, March 2015,
              <http://www.rfc-editor.org/info/rfc7483>.

9.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Appendix A.  An example History response

































Ellacott & Harrison     Expires December 30, 2017               [Page 7]

Internet-Draft               History in RDAP                   June 2017


             {
               "rdapConformance": [
                 "history_0",
                 "rdap_level_0"
               ],
               "notices": [
                 {
                   "title": "Example Only",
                   "description": [
                     "This is an example object only."
                   ]
                 }
               ],
               "objectClassName": "history",
               "records": [
                 {
                   "applicableFrom": "2009-01-20T07:00:00Z",
                   "applicableUntil": "2017-01-20T07:00:00Z",
                   "content": {
                     "objectClassName": "entity",
                     "handle": "POTUS",
                     "vcardArray": [
                       "vcard",
                       [
                         [ "version", {}, "text", "4.0" ],
                         [ "fn", {}, "text", "Barack Obama" ]
                       ]
                     ]
                   }
                 },
                 {
                   "applicableFrom": "2017-01-20T07:00:00Z",
                   "content": {
                     "objectClassName": "entity",
                     "handle": "POTUS",
                     "vcardArray": [
                       "vcard",
                       [
                         [ "version", {}, "text", "4.0" ],
                         [ "fn", {}, "text", "Donald Trump" ]
                       ]
                     ]
                   }
                 }
               ]
             }





Ellacott & Harrison     Expires December 30, 2017               [Page 8]

Internet-Draft               History in RDAP                   June 2017


   In this example, the "POTUS" entity has two historical records.  The
   applicability range of the first record is left-closed, indicating
   that the "POTUS" entity had the first record's contents at noon EST
   on the 20th of January, 2009, and right-open, indicating that the
   "POTUS" entity no longer had the first record's contents at noon EST
   on the 20th of Janauary, 2017.  The absence of a gap between the
   "applicableUntil" date of the first record and the "applicableFrom"
   date of the second record indicates that the record was updated,
   while a gap may indicate that the record was removed, then a similar
   record with the same key was subsequently added.  The second record
   has no "applicableUntil" element, which indicates that, as of the
   time that this RDAP History response was prepared, the second record
   was still in effect.

   This example also suggests that this response elides a number of
   previous versions of this record.  A registry's local policy will
   determine what historical registration information is available, and
   may vary based on the identity of the entity retrieving the
   information.

Authors' Addresses

   Byron Ellacott
   APNIC Pty Ltd

   Email: bje@apnic.net


   Tom Harrison
   APNIC Pty Ltd

   Email: tomh@apnic.net



















Ellacott & Harrison     Expires December 30, 2017               [Page 9]