idnits 2.17.1 

draft-ietf-eppext-keyrelay-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (January 19, 2014) is 3749 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-06) exists of
     draft-koch-dnsop-dnssec-operator-change-05


     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	Network Working Group                                          R. Gieben
3	Internet-Draft                                                    Google
4	Intended status: Standards Track                            M. Groeneweg
5	Expires: July 23, 2014                                        R. Ribbers
6	                                                       A.L.J. Verschuren
7	                                                               SIDN Labs
8	                                                        January 19, 2014

10	       Key Relay Mapping for the Extensible Provisioning Protocol
11	                     draft-ietf-eppext-keyrelay-00

13	Abstract

15	   This document describes an Extensible Provisioning Protocol (EPP)
16	   extension mapping for the purpose of relaying DNSSEC key material
17	   from one DNS operator to another, by using the administrative
18	   registration channel through the registrant, registrar and registry.
19	   The mapping introduces "<keyrelay>" as a new command in EPP.

21	   This command will help facilitate changing the DNS operator of a
22	   domain while keeping the DNSSEC chain of trust intact.

24	Status of This Memo

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

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

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

39	   This Internet-Draft will expire on July 23, 2014.

41	Copyright Notice

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

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

56	Table of Contents

58	   1.  Conventions Used in This Document . . . . . . . . . . . . . .   2
59	   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
60	   3.  Relaying Key Material . . . . . . . . . . . . . . . . . . . .   3
61	   4.  Rational For a New Command  . . . . . . . . . . . . . . . . .   4
62	   5.  Key Relay Interface . . . . . . . . . . . . . . . . . . . . .   4
63	     5.1.  Example Key Relay Interface . . . . . . . . . . . . . . .   6
64	   6.  Server Reply  . . . . . . . . . . . . . . . . . . . . . . . .   6
65	   7.  Message Queue Interface . . . . . . . . . . . . . . . . . . .   7
66	     7.1.  Message Queue Format  . . . . . . . . . . . . . . . . . .   7
67	   8.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   8
68	   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
69	   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
70	   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
71	   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
72	     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
73	     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
74	   Appendix A.  Changelog  . . . . . . . . . . . . . . . . . . . . .  12
75	     A.1.  draft-gieben-epp-keyrelay-00  . . . . . . . . . . . . . .  12
76	     A.2.  draft-gieben-epp-keyrelay-01  . . . . . . . . . . . . . .  12
77	     A.3.  draft-gieben-epp-keyrelay-02  . . . . . . . . . . . . . .  12
78	     A.4.  draft-gieben-epp-keyrelay-03  . . . . . . . . . . . . . .  12
79	     A.5.  draft-eppext-epp-keyrelay-00  . . . . . . . . . . . . . .  13
80	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

82	1.  Conventions Used in This Document

84	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
85	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
86	   document are to be interpreted as described in BCP 14, RFC 2119
87	   [RFC2119].

89	   In examples, "C:" represents lines sent by a protocol client, and
90	   "S:" represents lines returned by a protocol server.  "////" is used
91	   to note element values that have been shortened to better fit page
92	   boundaries.  Indentation and white space in examples is provided only
93	   to illustrate element relationships and is not a mandatory feature of
94	   this protocol.

96	   XML is case sensitive.  Unless stated otherwise, XML specifications
97	   and examples provided in this document MUST be interpreted in the
98	   character case presented in order to develop a conforming
99	   implementation.

101	   The term "key material" denotes one or more DNSKEY resource records
102	   [RFC4034].

104	2.  Introduction

106	   Certain transactions for DNSSEC signed zones require an authenticated
107	   exchange of DNSSEC key material between DNS operators.  Often there
108	   is no direct secure channel between the two or it is non-scalable.

110	   One of such transactions is changing the DNS operator for DNSSEC
111	   signed zones ([I-D.koch-dnsop-dnssec-operator-change].  We suggest
112	   DNS operators use the administrative channel that is used to
113	   bootstrap the delegation to relay the key material for the zone.  In
114	   this document we define a protocol extension for use in EPP that
115	   helps to implement and automate this transaction.  This protocol
116	   extension introduces a new command called "<keyrelay>".

118	3.  Relaying Key Material

120	   The "<keyrelay>" command uses the existing authenticated EPP channel
121	   with the registry.  Registrars can securely talk to the registry and
122	   as such the registry can serve as a drop box for relaying key
123	   material between them (see Figure 1).

125	            +-------------------+  DNSKEY  +--------------------+
126	            |losing DNS operator| <~~~~~~~ |gaining DNS operator|
127	            +-------------------+          +--------------------+
128	                             ^              |
129	                             |              v
130	              +-----------------+          +---------+
131	              |current registrar|          |registrar|
132	              +-----------------+          +---------+
133	                             ^              |
134	                    EPP poll |              | EPP keyrelay
135	                             |              V
136	                            +----------------+
137	                            |    registry    |
138	                            +----------------+

140	    Figure 1: The gaining and losing DNS operators should talk directly
141	    to each other (the ~ arrow) to exchange the DNSKEY, but often there
142	    is no trusted path between the two.  As both can securely interact
143	       with the registry over the administrative channel through the

145	      registrar, the registry can act as a relay for the key material
146	                                 exchange.

148	   The "<keyrelay>" command uploads new key(s) to the registry for a
149	   given domain.  This key material is then relayed to the current
150	   registrar's message queue.  This may be the same registrar as the one
151	   that submitted the "<keyrelay>" command in the situation where the
152	   DNS operators change, but the registrar stays the same.  There is no
153	   need for the registry to store the relayed key in the registry
154	   system, although the registry MAY save the "<keyrelay>" message for
155	   administrative purposes.

157	   The registrar may upload multiple keys in one "<keyrelay>" message.

159	   There is no restriction on the type (for instance Key Signing Keys or
160	   Zone Signing Keys) of keys that can be put in the message.  It is up
161	   to the gaining DNS operator to select the keys that are needed in the
162	   losing operator's zone for the intended transaction to complete
163	   successfully.  It is up to the losing DNS operator to validate the
164	   correctness of the key material, and remove duplicate keys (Flags
165	   Field, Protocol Field, Algorithm Field and Public Key Field are
166	   equal) when identical keys are already in the zone.

168	   If for some reason the registry can not process the "<keyrelay>"
169	   command an EPP error response MUST be returned.  If the registry does
170	   process the "<keyrelay>" command it MUST put all uploaded keys on to
171	   the current registrar's message queue.

173	4.  Rational For a New Command

175	   The existing commands in EPP all deal with data which either has an
176	   owner, or soon will have one (EPP create).  The "<keyrelay>" command
177	   is different, because it allows an upload of key material which will
178	   never have an owner (in the registry system).  All the "<keyrelay>"
179	   command does is relay data in preparation for one of the other
180	   existing EPP commands in a process.  This way, existing commands
181	   don't need to change, and backward compatibility for existing
182	   commands is guaranteed.  It allows the client to be flexible in
183	   timing the individual steps necessary to complete a complex process
184	   like changing the DNS operator for a zone.  Creating a separate
185	   command also allows the command to be used or extended to relay key
186	   or other data for other future processes besides DNS operator
187	   changes.  This new category of EPP commands can best be described as
188	   "communication command" as it only facilitates communication of data
189	   between two EPP clients without changing any objects at the registry.

191	5.  Key Relay Interface
192	   The Key Relay Interface uses a "<keyrelay>" element for relaying the
193	   key material.  It needs a minimum of three elements: a domain name,
194	   the key(s) to upload, a token which indicates the request is
195	   authorized by the registrant, and an OPTIONAL expire element.

197	   Thus a "<keyrelay>" element MUST contain the following child
198	   elements:

200	   o  A "<name>" element that contains the domain name for which we
201	      upload the key.

203	   o  A "<keyData>" element that contains the key material as described
204	      in [RFC5910], Section 4.2.

206	   o  An "<authInfo>" that contains an authorization token ([RFC5731],
207	      Section 3.2.4).  This indicates that the registrar has
208	      authorization from the registrant to change the zone data, and a
209	      possible future transfer is authorized.  The registry MAY check if
210	      the "<authInfo>" data is correct and if it does, it MUST return an
211	      EPP error response if the authorization token is not correct.

213	   And MAY contain:

215	   o  An "<expiry>" element that describes the expected lifetime of the
216	      relayed key(s) in the zone.  The losing DNS operator can use this
217	      as an indication when to safely remove the inserted key material
218	      from the zone.  This may be because the transaction that needed
219	      the insertion is either completed or has been abandoned if not
220	      completed before this expire time.  The <expiry> element MUST
221	      contain one of the following child elements:

223	      *  "<absolute/>": The policy is valid from the current date and
224	         time until it expires on the specified date and time.

226	      *  "<relative/>": The policy is valid from the current date and
227	         time until the end of the specified duration.

229	      The current date and time are taken from the "<keyrelay>" service
230	      message's "<qDate>" element, see Section 7.1.

232	   o  An "<clTRID>" (client transaction identifier) as described in
233	      [RFC5730], Section 2.5.

235	5.1.  Example Key Relay Interface

237	   The following is an example of the "<keyrelay>" command, where a key
238	   is uploaded with a relative expire date of one month and 13 days.

240	   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
241	   C:  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
242	   C:  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
243	   C:  xmlns:ext="urn:ietf:params:xml:ns:keyrelay-1.0">
244	   C:  <extension>
245	   C:    <ext:command>
246	   C:      <ext:keyrelay>
247	   C:        <ext:name>example.org</ext:name>
248	   C:        <ext:keyData>
249	   C:           <secDNS:flags>256</secDNS:flags>
250	   C:           <secDNS:protocol>3</secDNS:protocol>
251	   C:           <secDNS:alg>8</secDNS:alg>
252	   C:           <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
253	   C:        </ext:keyData>
254	   C:        <ext:authInfo>
255	   C:           <domain:pw>JnSdBAZSxxzJ</domain:pw>
256	   C:        </ext:authInfo>
257	   C:        <ext:expiry>
258	   C:           <ext:relative>P1M13D</ext:relative>
259	   C:        </ext:expiry>
260	   C:      </ext:keyrelay>
261	   C:      <ext:clTRID>ABC-12345</ext:clTRID>
262	   C:    </ext:command>
263	   C:  </extension>
264	   C:</epp>

266	6.  Server Reply

268	   Example "<keyrelay>" response:

270	   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
271	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
272	   S:  <response>
273	   S:    <result code="1000">
274	   S:       <msg>Command completed successfully</msg>
275	   S:    </result>
276	   S:    <trID>
277	   S:       <clTRID>ABC-12345</clTRID>
278	   S:       <svTRID>54321-ZYX</svTRID>
279	   S:    </trID>
280	   S:  </response>
281	   S:</epp>

283	   As stated an EPP error response MUST be returned if a "<keyrelay>"
284	   command can not be processed for any reason.

286	7.  Message Queue Interface

288	   The message queue interface uses the interface as defined in
289	   [RFC5730], Section 2.6.  All elements that are present in the
290	   "<keyrelay>" EPP message are put on the message queue of the current
291	   registrar for the domain in the "<name>" element.

293	   A "<keyrelay>" message MUST be delivered to the current registrar's
294	   message queue, even if the current registrar has indicated that it
295	   does not support "<keyrelay">.

297	7.1.  Message Queue Format

299	   This is an example "<keyrelay>" service message.  Note that the
300	   optional clTRID in this message is the clTRID value from the command
301	   that polls the message queue.  It is not the clTRID value used in the
302	   EPP "<keyrelay>" command.

304	   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
305	   S:  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
306	   S:  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
307	   S:  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
308	   S:  <response>
309	   S:     <result code="1301">
310	   S:        <msg>Command completed successfully; ack to dequeue</msg>
311	   S:     </result>
312	   S:     <msgQ count="5" id="12345">
313	   S:        <qDate>1999-04-04T22:01:00.0Z</qDate>
314	   S:        <msg>Key Relay action completed successfully.</msg>
315	   S:     </msgQ>
316	   S:     <resData>
317	   S:        <keyrelay:response>
318	   S:           <keyrelay:panData>
319	   S:              <keyrelay:name paResult="true">example.org
320	   S:              </keyrelay:name>
321	   S:              <keyrelay:paDate>1999-04-04T22:01:00.0Z
322	   S:              </keyrelay:paDate>
323	   S:              <keyrelay:keyData>
324	   S:                 <secDNS:flags>256</secDNS:flags>
325	   S:                 <secDNS:protocol>3</secDNS:protocol>
326	   S:                 <secDNS:alg>8</secDNS:alg>
327	   S:                 <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
328	   S:              </keyrelay:keyData>
329	   S:              <keyrelay:authInfo>
330	   S:                 <domain:pw>JnSdBAZSxxzJ</domain:pw>
331	   S:              </keyrelay:authInfo>
332	   S:              <keyrelay:expiry>
333	   S:                 <keyrelay:relative>P24D</keyrelay:relative>
334	   S:              </keyrelay:expiry>
335	   S:              <keyrelay:reID>ClientX</keyrelay:reID>
336	   S:              <keyrelay:acID>ClientY</keyrelay:acID>
337	   S:           </keyrelay:panData>
338	   S:        </keyrelay:response>
339	   S:     </resData>
340	   S:     <trID>
341	   S:        <clTRID>BCD-23456</clTRID>
342	   S:        <svTRID>65432-WXY</svTRID>
343	   S:     </trID>
344	   S:  </response>
345	   S:</epp>

347	8.  Formal Syntax

349	   An EPP object mapping is specified in XML Schema notation.  The
350	   formal syntax presented here is a complete schema representation of
351	   the object mapping suitable for automated validation of EPP XML
352	   instances.

354	   "<keyrelay>" command schema:

356	   <?xml version="1.0" encoding="UTF-8"?>
357	   <schema targetNamespace="urn:ietf:params:xml:ns:keyrelay-1.0"
358	           xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"
359	           xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
360	           xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
361	           xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
362	           xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
363	           xmlns="http://www.w3.org/2001/XMLSchema"
364	           elementFormDefault="qualified">

366	      <annotation>
367	         <documentation>
368	            Extensible Provisioning Protocol v1.0 domain name
369	            extension schema for relaying key material.
370	         </documentation>
371	      </annotation>

373	      <import namespace="urn:ietf:params:xml:ns:epp-1.0"
374	              schemaLocation="epp-1.0.xsd" />
375	      <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
376	              schemaLocation="eppcom-1.0.xsd" />
377	      <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
378	              schemaLocation="secdns-1.1.xsd" />
379	      <import namespace="urn:ietf:params:xml:ns:domain-1.0"
380	              schemaLocation="domain-1.0.xsd" />

382	      <element name="command" type="keyrelay:commandType" />
383	      <element name="response" type="keyrelay:responseType" />

385	      <complexType name="responseType">
386	         <sequence>
387	            <element name="panData"
388	                     type="keyrelay:panKeyRelayDataType"/>
389	         </sequence>
390	      </complexType>

392	      <complexType name="commandType">
393	         <sequence>
394	            <element name="keyrelay"
395	                     type="keyrelay:keyRelayType" />
396	            <element name="clTRID" type="epp:trIDStringType"
397	                     minOccurs="0"/>
398	         </sequence>
399	      </complexType>

401	      <complexType name="keyRelayExpiryType">
402	         <choice>
403	            <element name="absolute" type="dateTime" />
404	            <element name="relative" type="duration" />
405	         </choice>
406	      </complexType>

408	      <complexType name="keyRelayType">
409	         <sequence>
410	            <element name="name" type="eppcom:labelType" />
411	            <element name="keyData" type="secDNS:keyDataType"
412	                     minOccurs="1" maxOccurs="unbounded" />
413	            <element name="authInfo"
414	                     type="domain:authInfoType" />
415	            <element name="expiry"
416	               type="keyrelay:keyRelayExpiryType" minOccurs="0" />
417	         </sequence>
418	      </complexType>

420	      <complexType name="panKeyRelayDataType">
421	         <sequence>
422	            <element name="name" type="domain:paNameType" />
423	            <element name="paDate" type="dateTime" />
424	            <element name="keyData" type="secDNS:keyDataType"
425	                     minOccurs="1" maxOccurs="unbounded" />
426	            <element name="authInfo" type="domain:authInfoType" />
427	            <element name="expiry"
428	               type="keyrelay:keyRelayExpiryType" minOccurs="0" />
429	            <element name="reID" type="eppcom:clIDType"/>
430	            <element name="acID" type="eppcom:clIDType"/>
431	         </sequence>
432	      </complexType>
433	   </schema>

435	9.  IANA Considerations

437	   This document uses URNs to describe XML namespaces and XML schemas
438	   conforming to a registry mechanism described in RFC 3688 [RFC3688].

440	   Two URI assignments must be completed by the IANA.

442	   Registration request for the extension namespace:

444	   URI: urn:ietf:params:xml:ns:keyrelay-1.0

446	   Registrant Contact: IESG

448	   XML: None.  Namespace URIs do not represent an XML specification.

450	   Registration request for the extension XML schema:

452	   URI: urn:ietf:params:xml:schema:keyrelay-1.0

454	   Registrant Contact: IESG

456	   XML: See the "Formal Syntax" section of this document.

458	10.  Security Considerations

460	   The "<keyrelay>" EPP extension does not allow for any object
461	   transformations.

463	   Any registrar can use this mechanism to put key material on the
464	   message queue of another registrar, thus mounting a denial of service
465	   attack.  However this can, and should be detected by the registry.  A
466	   correct "<ext:authInfo>" element can be used as an indication that
467	   putting the key material on the losing registrar's message queue is
468	   authorized by the registrant of that registrar.  A registry MAY set a
469	   server policy which limits or rejects "<keyrelay>" messages if it
470	   detects the mechanism is being abused.

472	   Communication between a registrar and registry is mostly done over
473	   EPP, but communication between DNS operators, registrants or
474	   registrars often is not.  If EPP is not used between these entities,
475	   relaying the key between a DNS operator and registrar should be
476	   adequately authenticated for the complete relay channel to remain
477	   secure.  It's out of scope for this document to describe how to
478	   authenticate with other methods than EPP.

480	11.  Acknowledgements

482	   We like to thank the following individuals for their valuable input,
483	   review, constructive criticism in earlier revisions or support for
484	   the concepts described in this document:

486	   Maarten Wullink, Marco Davids, Ed Lewis, James Mitchell, David Peal,
487	   Patrik Faltstrom, Klaus Malorny, James Gould, Patrick Mevzek and Seth
488	   Goldman.

490	12.  References

492	12.1.  Normative References

494	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
495	              Requirement Levels", BCP 14, RFC 2119, March 1997.

497	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
498	              January 2004.

500	   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
501	              Rose, "Resource Records for the DNS Security Extensions",
502	              RFC 4034, March 2005.

504	   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
505	              STD 69, RFC 5730, August 2009.

507	   [RFC5910]  Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
508	              Security Extensions Mapping for the Extensible
509	              Provisioning Protocol (EPP)", RFC 5910, May 2010.

511	12.2.  Informative References

513	   [I-D.koch-dnsop-dnssec-operator-change]
514	              Koch, P., Sanz, M., and A. Verschuren, "Changing DNS
515	              Operators for DNSSEC signed Zones", draft-koch-dnsop-
516	              dnssec-operator-change-05 (work in progress), July 2013.

518	   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
519	              Domain Name Mapping", STD 69, RFC 5731, August 2009.

521	Appendix A.  Changelog

523	   [This section should be removed by the RFC editor before publishing]

525	A.1.  draft-gieben-epp-keyrelay-00

527	   1.  Initial document.

529	A.2.  draft-gieben-epp-keyrelay-01

531	   1.  Style and grammar changes;

533	   2.  Added an expire element as per suggestion by Klaus Malorny;

535	   3.  Make the authInfo element mandatory and make the registry check
536	       it as per feedback by Klaus Malorny and James Gould.

538	A.3.  draft-gieben-epp-keyrelay-02

540	   1.  Added element to identify the relaying EPP client as suggested by
541	       Klaus Malorny;

543	   2.  Corrected XML for missing and excess clTRID as noted by Patrick
544	       Mevzek;

546	   3.  Added clarifications for the examples based on feedback by
547	       Patrick Mevzeck;

549	   4.  Reviewed the consistency of using DNS operator versus registrar
550	       after review comments by Patrick Faltstrom and Ed Lewis.

552	A.4.  draft-gieben-epp-keyrelay-03

554	   1.  Style and grammar changes
555	   2.  Corrected acknowledgement section

557	   3.  Corrected XML for Expire element to not be mandatory but only
558	       occur once.

560	A.5.  draft-eppext-epp-keyrelay-00

562	   1.  Added feedback from Seth Goldman and put him in the
563	       acknowledgement section.

565	   2.  IDnits formatting ajustments

567	Authors' Addresses

569	   R. (Miek) Gieben
570	   Google

572	   Email: miek@google.com

574	   M. Groeneweg
575	   SIDN Labs
576	   Meander 501
577	   Arnhem  6825 MD
578	   NL

580	   Email: marc.groeneweg@sidn.nl
581	   URI:   https://www.sidn.nl/

583	   Rik Ribbers
584	   SIDN Labs
585	   Meander 501
586	   Arnhem  6825 MD
587	   NL

589	   Email: rik.ribbers@sidn.nl
590	   URI:   https://www.sidn.nl/

592	   Antoin Verschuren
593	   SIDN Labs
594	   Meander 501
595	   Arnhem  6825 MD
596	   NL

598	   Email: antoin.verschuren@sidn.nl
599	   URI:   https://www.sidn.nl/