Internet DRAFT - draft-sattler-epp-poll-maintenance-response

draft-sattler-epp-poll-maintenance-response



Internet Engineering Task Force                               T. Sattler
Internet-Draft                                          December 4, 2017
Intended status: Standard Track
Expires: May 3, 2018

       JSON response to provide Registry Maintenance Notifications
      within an Extensible Provisioning Protocol (EPP) poll response
            draft-sattler-epp-poll-maintenance-response-07

Abstract
   This document describes the JSON response which can be included in an
   Extensible Provisioning Protocol (EPP) <poll> response to provide
   Domain Name Registry Maintenance Notifications to Domain Name
   Registrars.

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 https://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 May 3, 2018.

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
   (https://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.

Sattler                   Expires May 3, 2018                   [Page 1]

Internet-Draft         Maintenance JSON Response           December 2017

Table of Contents
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Definitions . . . . . . . . . . . . . . .   2
   2.  Common Data Types . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Common Data Structures  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Notifications . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Systems . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Intervention  . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  TLDs  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  EPP <poll> Command. . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Internationalisation Considerations . . . . . . . . . . . . .   7
     7.1.  Character Encoding  . . . . . . . . . . . . . . . . . . .   7
     7.2.  Internationalised Domain Names  . . . . . . . . . . . . .   7
     7.3.  Date-Time Values  . . . . . . . . . . . . . . . . . . . .   7
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1. Normative References . . . . . . . . . . . . . . . . . . .   9
     9.2. Informative References . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Motivations for using JSON . . . . . . . . . . . . .   9
   Appendix B.  Change History . . . . . . . . . . . . . . . . . . .  10
     B.1.  Change from 00 to 01  . . . . . . . . . . . . . . . . . .  10
     B.2.  Change from 01 to 02  . . . . . . . . . . . . . . . . . .  10
     B.3.  Change from 02 to 03  . . . . . . . . . . . . . . . . . .  10
     B.4.  Change from 03 to 04  . . . . . . . . . . . . . . . . . .  10
     B.5.  Change from 04 to 05  . . . . . . . . . . . . . . . . . .  10
     B.6.  Change from 05 to 06  . . . . . . . . . . . . . . . . . .  10
     B.7.  Change from 06 to 07  . . . . . . . . . . . . . . . . . .  11
   Appendix C. Acknowledgements  . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document describes the JSON [RFC7159] response which can be
   included in an Extensible Provisioning Protocol (EPP) [RFC5730]
   <poll> response to provide Domain Name Registry Maintenance
   Notifications to Domain Name Registrars.

1.1.  Terminology and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] when
   specified in their uppercase forms.   

   The following list describes terminology and definitions used
   throughout this document:

   DNRR:             Domain Name Registrar

   DNRY:             Domain Name Registry

Sattler                   Expires May 3, 2018                   [Page 2]

Internet-Draft          Maintenance JSON Response          December 2017

   EPP:              Extensible Provisioning Protocol

   JSON:             JavaScript Object Notation

   NTFY:             Domain Name Registry Maintenance Notification

   UUID:             Universally Unique Identifier

2.  Common Data Types

   JSON [RFC7159] defines the data types of a number, character string,
   boolean, array, object, and null.  This section describes the
   semantics and/or syntax reference for common, JSON character strings
   used in this document.
   
   maintenance:      an array containing specification and one or more
                     notifications
   
   specification:    a string containing the URI to this document to
                     provide more details about this poll message and
                     to facilitate the adoption.

   notification:     an object containing a single NTFY

   id:               a string containing the NTFY ID to identify it.
                     MUST be an UUID according [RFC4122], SHOULD NOT
                     be changed if it gets postponed or updated

   purpose:          a string indicating the purpose of this NTFY; MUST
                     either be 'create', 'update', 'delete'. If it
                     is delete then everything besides id is OPTIONAL.

   systems:          an array of objects containing name, host and
                     impact

   name:             a string indicating the name of affected system

   host:             a string indicating the affected maintained system
                     (host or IP address).
                     hostname SHOULD be Punycode according [RFC3492].
                     IPv4 addresses SHOULD be dotted-decimal notation.
                     An example of this textual representation is
                     "192.0.2.0".
                     IPv6 addresses SHOULD be according [RFC5952].
                     An example of this textual representation is
                     "2001:db8::1:0:0:1". 

   impact:           a string impact containing the level per affected
                     system; values are either 'partial' or 'blackout'

   environment:      a string representing the affected maintained
                     systems; values are 'production', 'ote', 'staging'
                     or 'dev'
                     
Sattler                   Expires May 3, 2018                   [Page 3]

Internet-Draft          Maintenance JSON Response          December 2017

   start:            a string containing the start of maintenance
                     according ISO 8601 [RFC3339]
                     YYYY-MM-DDThh:mm:ssTZ

   end:              a string containing the end of maintenance
                     according ISO 8601 [RFC3339]
                     YYYY-MM-DDThh:mm:ssTZ

   reason:           a string denoting the reason for this maintenance,
                     MUST either be 'planned' or 'emergency'

   remark:           a string containing an URI to detailed maintenance
                     description, MAY be empty

   tlds:             an array of strings containing all affected top
                     -level domains Punycode encoded according [RFC3492]

   intervention:     an object of booleans containing connection and
                     implementation

   connection:       a boolean indicating if DNRR needs to do
                     something that is connection related, such as a
                     reconnect.

   implementation:   a boolean indicating if DNRR needs to do
                     something that is implementation related, such as
                     code changes.

3.  Common Data Structures

   This section defines common data structures used in responses.

3.1. Notification

   The data structure named "notification" is an object and contains a
   single NTFY.

   An example "notification" data structure:

   "notification":{
     "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6",
     "purpose":"create",
     "systems":[{
       "name":"EPP",
       "host":"epp.registry.example",
       "impact":"blackout"
     }],
     "environment":"production",
     "start":"2017-04-30T06:00:00Z",
     "end":"2017-04-30T07:00:00Z",
     "reason":"planned",
     "remark":"https://www.registry.example/notice?123",
     "tlds":["example","test"],

Sattler                   Expires May 3, 2018                   [Page 4]

Internet-Draft          Maintenance JSON Response          December 2017

     "intervention":{
       "connection":false,
       "implementation":false
     }
   }

3.2.  Systems

   The data structure named "systems" is an array of objects, indicating
   the systems affected by the maintenance.

   An example "systems" data structure:

   "systems":
   [
     {
       "name":"EPP",
       "host":"epp.registry.example",
       "impact":"partial"
     },
     {
       "name":"WHOIS",
       "host":"whois.registry.example",
       "impact":"partial"
     },
     {
       "name":"Portal",
       "host":"https://portal.registry.example",
       "impact":"blackout"
     }
   ]

3.3.  Intervention

   The data structure named "intervention" is an object of booleans,
   each indicating if the DNRR needs to do something.
   
   An example "intervention" data structure:
   
   "intervention":{
     "connection":true,
     "implementation":false
   }
   
3.4. TLDs

   The data structure named "tlds" is an array of strings indicating the
   affected top level domains of the DNRY.

   An example "tlds" data structure:

   "tlds":[
     "example",
     "test"
   ]
Sattler                   Expires May 3, 2018                   [Page 5]

Internet-Draft          Maintenance JSON Response          December 2017

4.  EPP Command Mapping

   A detailed description of the EPP syntax and semantics can be found
   in [RFC5730].

4.1.  EPP <poll> Command

   According to EPP [RFC5730], the response to an EPP <poll> command
   allows mixed content and also be returned without object information.

   Below is an example <poll> response with JSON.

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1301">
   S:      <msg>Command completed successfully; ack to dequeue</msg>
   S:    </result>
   S:    <msgQ count="4" id="12346">
   S:      <qDate>2017-02-08T22:10:00.0Z</qDate>
   S:      <msg lang="en">
   S:       {"maintenance":[
   S:         {"specification":"https://datatracker.ietf.org/doc/
   S:            draft-sattler-epp-poll-maintenance-response/"},
   S:         {"notification":{
   S:           "id":"2e6df9b0-4092-4491-bcc8-9fb2166dcee6",
   S:           "purpose":"create",
   S:           "systems":[{"name":"EPP","host":"epp.registry.example",
   S:             "impact":"blackout"}],
   S:           "environment":"production",
   S:           "start":"2017-04-30T06:00:00Z",
   S:           "end":"2017-04-30T07:00:00Z",
   S:           "reason":"planned",
   S:           "remark":"https://www.registry.example/notice?123",
   S:           "tlds":["example","test"],
   S:           "intervention":
   S:             {"connection":false,"implementation":false}
   S:         }},
   S:         {"notification":{
   S:           "id":"91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f",
   S:           "purpose":"update",
   S:           "systems":[{"name":"EPP","host":"epp.registry.example",
   S:               "impact":"partial"},
   S:             {"name":"WHOIS","host":"whois.registry.example",
   S:               "impact":"partial"},
   S:             {"name":"Portal",
   S:               "host":"https://portal.registry.example",
   S:               "impact":"blackout"}],
   S:           "environment":"production",
   S:           "start":"2017-06-15T04:30:00Z",
   S:           "end":"2017-06-15T05:30:00Z",
   S:           "reason":"emergency",
   S:           "remark":"https://www.registry.example/notice?456",
   S:           "tlds":["example"],

Sattler                   Expires May 3, 2018                   [Page 6]

Internet-Draft          Maintenance JSON Response          December 2017

   S:           "intervention":
   S:             {"connection":true,"implementation":false}
   S:         }},
   S:         {"notification":{
   S:           "id":"644e9b83-5087-4aa7-9b41-0170a0f3e00f",
   S:           "purpose":"delete"
   S:         }}
   S:       ]}
   S:      </msg>
   S:    </msgQ>   
   S:    <trID>
   S:      <clTRID>ABC-12346</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

5.  IANA Considerations

   This document has no actions for IANA.

6.  Security Considerations

   This specification models information serialized in JSON format.  As
   JSON is a subset of JavaScript, implementations are advised to follow
   the security considerations outlined in Section 6 of [RFC7159] to
   prevent code injection.

   Implementers should be aware of the security considerations specified
   in [RFC5730].

7.  Internationalisation Considerations

7.1.  Character Encoding

   The default text encoding for JSON responses is UTF-8 [RFC3629], and
   all servers and clients MUST support UTF-8.

7.2.  Internationalised Domain Names

   Affected TLDs as mention in Section 2 SHOULD be provided in Punycode
   according [RFC3492].

7.3.  Date-Time Values

   All date-time values presented via MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar. JSON schema allows use
   of time zone identifiers to indicate offsets from the zero meridian,
   but this option MUST NOT be used. The extended date-time form using
   upper case "T" and "Z" characters defined in ISO 8601 [RFC3339] MUST
   be used to represent date-time values.

Sattler                   Expires May 3, 2018                   [Page 7]

Internet-Draft          Maintenance JSON Response          December 2017

8.  Implementation Status

   Note to RFC Editor: Please remove this section and the reference to
   [RFC7942] before publication.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   Add implementation details once available.

9.  References

9.1.  Normative References

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

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO 10646"
              , RFC3629, November 2003,
              <https://www.rfc-editor.org/info/rfc3629>

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014,
              <https://www.rfc-editor.org/info/rfc7159>.

Sattler                   Expires May 3, 2018                   [Page 8]

Internet-Draft          Maintenance JSON Response          December 2017

9.2.  Informative References

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications (IDNA)
              ", RFC 3492, March 2003,
              <https://www.rfc-editor.org/info/rfc3492>.

   [RFC4122]  Leach, P., Mealling, M. and Salz, R., "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122, July
              2015,
              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC5952]  Kawamura, S. and Kawashima, M., "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010,
              <https://www.rfc-editor.org/info/rfc5952>.

   [RFC7942]  Sheffer, Y. and Farrel, A., "Improving Awareness of
              Running Code: The Implementation Status Section", RFC
              7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>

Appendix A.  Motivations for using JSON

   This section addresses a common question regarding the use of JSON
   over other data formats, most notably XML.

   It is often pointed out that DNRY and DNRR support the EPP
   [RFC5730] standard, which is an XML serialised protocol.  The logic
   is that since EPP is a common protocol in the industry, it follows
   that XML would be a more natural choice.

   While that being true, the intent to use JSON is to use the already
   approved and reliable EPP command <poll> and its capabilities to
   transport mixed content without object information instead of
   creating a new EPP extension. The adoption of a new extension would
   need more time and might not be more beneficial.

Sattler                   Expires May 3, 2018                   [Page 9]

Internet-Draft          Maintenance JSON Response          December 2017

Appendix B.  Change History

B.1.  Change from 00 to 01

   Removed JSON Schema. Clarified unique id with UUID. Added
   Common Data Structures for better explanation. Fixed EPP poll
   response example. Added und fixed References.

B.2.  Change from 01 to 02

   Clarified host field. Added TLDs to Common Data Structure. Added
   Internationalisation Considerations. Changed authors address and
   contact details.

B.3.  Change from 02 to 03

   Added date-time Values to Internationalisation Considerations.
   Sorted Terminology and Definitions alphabetically. Changed start
   and end date-time. Changed Reference URI to HTTPS.

B.4.  Change from 03 to 04

   Added Acknowledgements. Clarified UUID field to be not changed at
   all. Clarified environment field with production, ote, staging and
   dev. Clarified connection and implementation fields. Fixed writing
   of systems field. Removed author's private address. Moved this
   draft from Experimental to Standard Track.

B.5.  Change from 04 to 05

   Changed title of this draft to be more specific. Added Change Log.
   Split References into Normative and Informative References. Clarified
   Common Data Types. Rephrased Abstract and Introduction. Added
   Implementation Status section.

B.6.  Change from 05 to 06

   Added IANA Considerations. Changed URIs from http to https. Added
   new main section 4. EPP Command Mapping. Added new JSON field purpose
   for announce, change or cancel of a maintenance notification.

Sattler                   Expires May 3, 2018                  [Page 10]

Internet-Draft          Maintenance JSON Response          December 2017

B.7.  Change from 06 to 07

   Fixed typo in section 3.4. and added missing comma in the example of
   section 4.1. Added the field specification to help facilitate the
   adoption of this document. Changed possible purposes to create,
   update and delete to be closer to the EPP syntax. Cleaned
   whitespaces. Updated Acknowledgements.

Appendix C. Acknowledgements

   The author wishes to thank the following persons for their feedback
   and suggestions (sorted alphabetically by company):

   * Neal McPherson of 1&1 Internet
   * Christopher Martens of Donuts
   * Jody Kolker and Roger Carney of GoDaddy
   * Raymond Zylstra of Neustar
   * Andreas Huber of united-domains
   * Craig Marchant of VentraIP

Author's Address

   Tobias Sattler

   Email: tobias.sattler@me.com
   URI: https://tobiassattler.com

Sattler                   Expires May 3, 2018                  [Page 11]