Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

From: "Gould, James" <[email-masked]>
Date: Fri, 25 Apr 2014 13:23:13 +0000

I have not received any feedback publicly or privately on the options in the message below.  Any thoughts on this?

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: <Gould>, James Gould <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 13, 2014 at 1:52 PM
To: Antoin Verschuren <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

Antoin,

Thanks for the detailed explanation.  The choice of which form of EPP extension to use (protocol, object, command-response) does not change the process flow at all, but simply determines the syntax of the key relay commands and responses.  Technically draft-ietf-eppext-keyrelay uses both the protocol extension for the command and the object extension for the poll response.  My recommendation is to get down to one type of extension for the specification.   The best way to describe the use of the object and command-response extensions is to provide some examples, which I do below:

Command-Response Extension:

Key Relay Command as extension to empty domain update similar to the restore command in RFC 3915.  To note this is a new verb that is not mixed with the update from a feature and authorization perspective.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
  <command>
    <update>
      <domain:update>
        <domain:name>example.org</domain:name>
      </domain:update>
    </update>
    <extension>
      <keyrelay:keyrelay>
        <keyrelay:name>example.org</keyrelay:name>
        <keyrelay:keyData>
           <secDNS:flags>256</secDNS:flags>
           <secDNS:protocol>3</secDNS:protocol>
           <secDNS:alg>8</secDNS:alg>
           <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
        </keyrelay:keyData>
        <keyrelay:authInfo>
           <domain:pw>JnSdBAZSxxzJ</domain:pw>
        </keyrelay:authInfo>
        <keyrelay:expiry>
           <keyrelay:relative>P1M13D</keyrelay:relative>
        </keyrelay:expiry>
      </keyrelay:keyrelay>
    </extension>
    <clTRID>ABC-12345-XYZ</clTRID>
  </command>
</epp>

Key Relay Poll Response as an extension to the domain info response.

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
  <response>
    <result code="1301">
       <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
       <qDate>1999-04-04T22:01:00.0Z</qDate>
       <msg>Key Relay action completed successfully.</msg>
    </msgQ>
    <resData>
      <domain:infData
        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.org</domain:name>
        <domain:roid>EXAMPLE1-REP</domain:roid>
        <domain:clID>ClientX</domain:clID>
      </domain:infData>
    </resData>
    <extension>
  <keyrelay:panData>
  <keyrelay:name paResult="true">example.org
  </keyrelay:name>
  <keyrelay:paDate>1999-04-04T22:01:00.0Z
  </keyrelay:paDate>
  <keyrelay:keyData>
  <secDNS:flags>256</secDNS:flags>
  <secDNS:protocol>3</secDNS:protocol>
  <secDNS:alg>8</secDNS:alg>
  <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
  </keyrelay:keyData>
  <keyrelay:authInfo>
  <domain:pw>JnSdBAZSxxzJ</domain:pw>
  </keyrelay:authInfo>
  <keyrelay:expiry>
  <keyrelay:relative>P24D</keyrelay:relative>
  </keyrelay:expiry>
  <keyrelay:reID>ClientX</keyrelay:reID>
  <keyrelay:acID>ClientY</keyrelay:acID>
  </keyrelay:panData>
    </extension>
    <trID>
       <clTRID>ABC-12345</clTRID>
       <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

Object Extension:

Key Relay is an object that can be created via the create command and can get information via the info command and response.  The poll message is simply a key relay info response.

Key Relay Command using a Key Relay Create Command.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
 <command>
   <create>
     <keyrelay:create>
       <keyrelay:name>example.org</keyrelay:name>
       <keyrelay:keyData>
          <secDNS:flags>256</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
       </keyrelay:keyData>
       <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</domain:pw>
       </keyrelay:authInfo>
       <keyrelay:expiry>
          <keyrelay:relative>P1M13D</keyrelay:relative>
       </keyrelay:expiry>
     </keyrelay:create>
   </create>
   <clTRID>123456</clTRID>
 </command>
</epp>

Key Relay Poll Response

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
  xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
  <response>
    <result code="1301">
       <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
       <qDate>1999-04-04T22:01:00.0Z</qDate>
       <msg>Key Relay action completed successfully.</msg>
    </msgQ>
    <resData>
      <keyrelay:infData>
        <keyrelay:name paResult="true">example.org
        </keyrelay:name>
        <keyrelay:paDate>1999-04-04T22:01:00.0Z
        </keyrelay:paDate>
        <keyrelay:keyData>
          <secDNS:flags>256</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>8</secDNS:alg>
          <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey>
        </keyrelay:keyData>
        <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</domain:pw>
        </keyrelay:authInfo>
        <keyrelay:expiry>
          <keyrelay:relative>P24D</keyrelay:relative>
        </keyrelay:expiry>
        <keyrelay:reID>ClientX</keyrelay:reID>
        <keyrelay:acID>ClientY</keyrelay:acID>
      </keyrelay:infData>
    </resData>
    <trID>
       <clTRID>BCD-23456</clTRID>
       <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>

In addition, support can be provided for the Relay Info Command and associated Response (example provided already with the poll response).

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0">
 <command>
   <info>
     <keyrelay:info>
       <keyrelay:name>example.org</keyrelay:name>
     </keyrelay:info>
   </info>
   <clTRID>123456</clTRID>
 </command>
</epp>

In looking at the samples, I actually like the Object Extension the best.  I can provide the XSD’s that I validated the examples against if desired.

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/13/14, 5:39 AM, "Antoin Verschuren" <[email-masked]<mailto:[email-masked]>> wrote:

op 11-03-14 17:36, Gould, James schreef:

Hi James,

Thanks for your suggestions. We have particularly looked at:

2. Create a Command-Response Extension of the domain mapping that
creates a new keyrelay verb similar to the restore verb in RFC
3915, which is an extension of an empty domain update.  The server
can define who is authorized to invoke the new verb on the domain
name.
By defining Key Relay as a new object or a new verb extension to
the domain object, you get all of the advantages of an object
mapping (extensions, client and server transaction identifier).
My recommendation is to go with option #2, since I view Key Relay
as a verb.  In summary, I don’t believe there is the need to create
a protocol extension for this.

One of the requirements from certain registries for keyrelay was that
since keyrelay is only a "preparation communication step" for a DNS
operator change that may or may not be followed by an NS change or
combined transfer/NS change, they did not want any changes made to
records owned by the registrar of record for a domain object. It's not
compulsory to do this "communication" via the registry, it only
facilitates registrars that have no other secure communication
channel. Sometimes a keyrelay command is not followed by an NS change
as the process is abandoned, and that should not lead to changes in
the DB that need to be reverted. The process would then become more
complex than necessary.

Another requirement that we heard from especially gTLD registries is
that a command for which it was necessary to change the database
tables in a fundamental way would not be implemented by those
registries. Since most EPP commands are processes that change an
object in the registry DB and is only authorized by the current
registrar of record, we looked at  a way to do this communication step
without even touching the DB. EPP keyrelay can be implemented without
any changes to the registry DB, and only queries existing records.
This is also how we implemented it.

We only know of one other command that is NOT authorized by the
current registrar of record for a domain object, and that is a
transfer. But if authorized properly by an auth-info token, the goal
of a transfer command is ultimately also to make changes to the domain
object in the DB.

Keyrelay does not intend to change anything to DB objects. That is
ultimately done by an NS change that usually follows a keyrelay if the
process is continued AND the loosing DNS operator cooperates. If the
loosing DNS operator does not cooperate, a different change to the DB
may follow, and it's complex to predict which action would follow.
There is no default process flow, it's up to the gaining registrar
which next step to take (Abandon, postpone, go insecure, transfer and
leave delegation as is, ...), we want him to be in control.

Could you elaberate on how a Command-Response Extension of the domain
mapping would meet the requirement of not changing anything
fundamental to the registry DB, nor creating a complex unpredictable
state flow?
How would the State Diagram similar to Figure 1 of RFC3915 look like
for EPP keyrelay?

Bear in mind, that a pending NS change state for a secure transfer
cannot be held forever, nor can it be predicted what a reasonable
period for that state is. It depends on DNS TTL values that are not
prescribed nor verified in most registry policies. And since we want
the registrant to be in control over his domain, it may well be that
during a pending state, yet another registrar may invoke a keyrelay if
the registrant chooses to change registrars because the process takes
too long or there is another (technical) reason to change his
delegation. So a state diagram is much more difficult to create than a
state diagram for a grace period that is only dependent on 1 registrar
and a state period defined by the registry's policy.

By completely separating the "preparation communication" from the
state of a domain object, we have avoided the need for a complex state
diagram and fundamental changes to the registry DB. It also extends
EPP with a new command type that may have other benefits in the future.

For an (even more) elaborate explanation on how we came to this
conclusion, we have written a white paper:
https://www.sidnlabs.nl/uploads/tx_sidnpublications/wp_2013_EPP-keyrelay_v1.en.pdf

On 3/11/14, 9:23 AM, "Antoin Verschuren"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
wrote:
Hi,
I'd like to answer the question asked in London why EPP keyrelay
is not an object extension or domain update.
Regular EPP commands are submitted to a registry by the current
registrar of record for that object in the database. Only the
registrar of record is allowed to change attributes to a domain
object.
EPP keyrelay is a command that typically is sent to a registry by
a registrar NOT being the registrar of record for that domain
object. So the registrar sending the command is not permitted to
change anything in the database to that object.
EPP keyrelay is therefor only a communication command, and the
domain object is only used to identify the registrar of record for
that domain object as a recipient. The domain object is only
queried to identify the registrar of record, but no attributes are
allowed to be changed.
Hope that clarifies the questions raised in London.
_______________________________________________ EppExt mailing
list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

- --
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]<mailto:[email-masked]>
XMPP: [email-masked]<mailto:[email-masked]>
HTTP://www.sidn.nl/

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 28 Apr 2014 11:58:26 +0200

op 25-04-14 15:23, Gould, James schreef:
> I have not received any feedback publicly or privately on the
> options in the message below.  Any thoughts on this?

Hi James,

First, thank you for your feedback and extensive suggestions.
I did receive private feedback to your suggestions, but was not able
to digest it yet due to a lack of time, sorry about that. I've asked
the commenter to post on-list, but have not been able to get back on that.

The major comments to your suggestions as I understand them were:

<command>

    <update>

This suggest an update of a domain object in the registry DB, but a
keyrelay does not update anything in the DB as it is not submitted by
the registrar of record. A keyrelay only reads object information and
uses that to relay data.

<resData>

The authors can live with the suggested changes to the response.
You'll get the domain info and key info in the response.

<command>

   <create>

     <keyrelay:create>

This is where both the authors and some others have problems with. A
create suggests you're creating an object in the registry DB, but we
don't. One of the requirements for keyrelay was that the DB would be
left unharmed, no special tables or attributes for keyrelay.

I understand the difference between the message syntax and the actual
process flow, but this does seem to confuse people. Are there any
other extensions that use a create or update syntax when there is no
authorization or actual object change? Is it clear enough in the EPP
RFC's that there is this separation of syntax and meaning? RFC 5730
section 2.9 states by definition that <create> and <update> actually
change objects. The authors feel keyrelay does not fit in any of the
current protocol commands. It's not a session management command, not
a query command, and not an object transform command. So keyrelay is
actually a new 4th protocol command type which can best be described
as a communication command.

Another comment was about the double use of the domain name in the
message:

        .....

which seemed unnessecary.

I'll ask my co-authors to follow up on this, but in the mean time, I
would like to hear others comment on the potential violation of RFC
5730 section 2.9 by your suggested syntax on-list.

> From: <Gould>, James Gould <[email-masked] 
> <mailto:[email-masked]>> Date: Thursday, March 13, 2014 at
> 1:52 PM To: Antoin Verschuren <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> Subject: Re: [eppext]
> draft-ietf-eppext-keyrelay-00 Feedback
> 
> Antoin,
> 
> Thanks for the detailed explanation.  The choice of which form of 
> EPP extension to use (protocol, object, command-response) does not 
> change the process flow at all, but simply determines the syntax
> of the key relay commands and responses.  Technically 
> draft-ietf-eppext-keyrelay uses both the protocol extension for
> the command and the object extension for the poll response.  My 
> recommendation is to get down to one type of extension for the 
> specification.   The best way to describe the use of the object
> and command-response extensions is to provide some examples, which
> I do below:
> 
> *Command-Response Extension:*
> 
> *Key Relay Command* as extension to empty domain update similar to
> the restore command in RFC 3915.  To note this is a new verb that
> is not mixed with the update from a feature and authorization
> perspective.
> 
> 
> *Key Relay Poll Response* as an extension to the domain info 
> response.
> 
> 
> *Object Extension:*
> Key Relay is an object that can be created via the create command
> and can get information via the info command and response.  The
> poll message is simply a key relay info response.
> 
> *Key Relay Command *using a Key Relay Create Command.
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp
> xmlns="urn:ietf:params:xml:ns:epp-1.0" 
> xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> <command> 
> <create> <keyrelay:create> 
> <keyrelay:name>example.org</keyrelay:name> <keyrelay:keyData> 
> <secDNS:protocol>3</secDNS:protocol> <secDNS:alg>8</secDNS:alg> 
> </keyrelay:keyData> <keyrelay:authInfo> 
> <domain:pw>JnSdBAZSxxzJ</domain:pw> </keyrelay:authInfo> 
> <keyrelay:expiry> <keyrelay:relative>P1M13D</keyrelay:relative> 
> </keyrelay:expiry> </keyrelay:create> </create> 
> <clTRID>123456</clTRID> </command> </epp>
> 
> *Key Relay Poll Response* * * <epp
> xmlns="urn:ietf:params:xml:ns:epp-1.0" 
> xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> <response> 
> <result code="1301"> <msg>Command completed successfully; ack to
> dequeue</msg> </result> <msgQ count="5" id="12345"> 
> <qDate>1999-04-04T22:01:00.0Z</qDate> <msg>Key Relay action
> completed successfully.</msg> </msgQ> <resData> <keyrelay:infData> 
> <keyrelay:name paResult="true">example.org </keyrelay:name> 
> <keyrelay:paDate>1999-04-04T22:01:00.0Z </keyrelay:paDate> 
> <keyrelay:keyData> <secDNS:flags>256</secDNS:flags> 
> <secDNS:protocol>3</secDNS:protocol> <secDNS:alg>8</secDNS:alg> 
> </keyrelay:keyData> <keyrelay:authInfo> 
> <domain:pw>JnSdBAZSxxzJ</domain:pw> </keyrelay:authInfo> 
> <keyrelay:expiry> <keyrelay:relative>P24D</keyrelay:relative> 
> </keyrelay:expiry> <keyrelay:reID>ClientX</keyrelay:reID> 
> <keyrelay:acID>ClientY</keyrelay:acID> </keyrelay:infData> 
> </resData> <trID> <clTRID>BCD-23456</clTRID> 
> <svTRID>65432-WXY</svTRID> </trID> </response> </epp>
> 
> In addition, support can be provided for the Relay Info Command and
> associated Response (example provided already with the poll 
> response).
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp
> xmlns="urn:ietf:params:xml:ns:epp-1.0" 
> xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0"> <command> 
> <info> <keyrelay:info> <keyrelay:name>example.org</keyrelay:name> 
> </keyrelay:info> </info> <clTRID>123456</clTRID> </command> </epp> 
> * *
> 
> In looking at the samples, I actually like the Object Extension
> the best.  I can provide the XSD’s that I validated the examples
> against if desired.
> 
> Thanks,
> 
> --
> 
> JG
> 
> 
> 
> James Gould Principal Software Engineer [email-masked]
> <mailto:[email-masked]>
> 
> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 
> VerisignInc.com
> 
> 
> 
> On 3/13/14, 5:39 AM, "Antoin Verschuren"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> name. By defining Key Relay as a new object or a new verb extension
> to the domain object, you get all of the advantages of an object 
> mapping (extensions, client and server transaction identifier). My
> recommendation is to go with option #2, since I view Key Relay as a
> verb.  In summary, I don’t believe there is the need to create a
> protocol extension for this.
> 
> 
> One of the requirements from certain registries for keyrelay was 
> that since keyrelay is only a "preparation communication step" for
> a DNS operator change that may or may not be followed by an NS
> change or combined transfer/NS change, they did not want any
> changes made to records owned by the registrar of record for a
> domain object. It's not compulsory to do this "communication" via
> the registry, it only facilitates registrars that have no other
> secure communication channel. Sometimes a keyrelay command is not
> followed by an NS change as the process is abandoned, and that
> should not lead to changes in the DB that need to be reverted. The
> process would then become more complex than necessary.
> 
> Another requirement that we heard from especially gTLD registries
> is that a command for which it was necessary to change the
> database tables in a fundamental way would not be implemented by
> those registries. Since most EPP commands are processes that change
> an object in the registry DB and is only authorized by the current 
> registrar of record, we looked at  a way to do this communication
> step without even touching the DB. EPP keyrelay can be implemented 
> without any changes to the registry DB, and only queries existing
> records. This is also how we implemented it.
> 
> transfer. But if authorized properly by an auth-info token, the
> goal of a transfer command is ultimately also to make changes to
> the domain object in the DB.
> 
> ultimately done by an NS change that usually follows a keyrelay if
> the process is continued AND the loosing DNS operator cooperates.
> If the loosing DNS operator does not cooperate, a different change
> to the DB may follow, and it's complex to predict which action
> would follow. There is no default process flow, it's up to the
> gaining registrar which next step to take (Abandon, postpone, go
> insecure, transfer and leave delegation as is, ...), we want him to
> be in control.
> 
> Could you elaberate on how a Command-Response Extension of the 
> domain mapping would meet the requirement of not changing anything 
> fundamental to the registry DB, nor creating a complex
> unpredictable state flow? How would the State Diagram similar to
> Figure 1 of RFC3915 look like for EPP keyrelay?
> 
> period for that state is. It depends on DNS TTL values that are
> not prescribed nor verified in most registry policies. And since we
> want the registrant to be in control over his domain, it may well
> be that during a pending state, yet another registrar may invoke a 
> keyrelay if the registrant chooses to change registrars because the
> process takes too long or there is another (technical) reason to
> change his delegation. So a state diagram is much more difficult to
> create than a state diagram for a grace period that is only
> dependent on 1 registrar and a state period defined by the
> registry's policy.
> 
> state of a domain object, we have avoided the need for a complex 
> state diagram and fundamental changes to the registry DB. It also
> extends EPP with a new command type that may have other benefits in
> the future.
> 
> <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>> wrote: Hi, I'd like to answer
> the question asked in London why EPP keyrelay is not an object
> extension or domain update. Regular EPP commands are submitted to a
> registry by the current registrar of record for that object in the
> database. Only the registrar of record is allowed to change
> attributes to a domain object. EPP keyrelay is a command that
> typically is sent to a registry by a registrar NOT being the
> registrar of record for that domain object. So the registrar
> sending the command is not permitted to change anything in the
> database to that object. EPP keyrelay is therefor only a
> communication command, and the domain object is only used to
> identify the registrar of record for that domain object as a
> recipient. The domain object is only queried to identify the
> registrar of record, but no attributes are allowed to be changed. 
> _______________________________________________ EppExt mailing list
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 

- -- 
Antoin Verschuren

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: "Gould, James" <[email-masked]>
Date: Mon, 28 Apr 2014 14:13:11 +0000

Antoin,

My feedback is below.

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/28/14, 5:58 AM, "Antoin Verschuren" <[email-masked]<mailto:[email-masked]>> wrote:

Hi James,

<command>

    <update>

The Key Relay is associated with the domain name.  A Key Relay Command, by overriding the update with a new verb (“Key Relay”), does persist information to the registry database to relay to the losing hosting provider in the form of a poll message.  Using the Command-Response Extension, you're defining a new command verb, similar to what is done with a protocol extension, but following the pattern that has been followed with other extensions like the RGP extension (e.g. restore command).

<resData>

<command>

   <create>

     <keyrelay:create>

I believe you are adding more requirements around an object extension than exists.  If the Key Relay was an object extension, you are creating a Key Relay message to the losing hosting provider.  This is similar to sending an e-mail by creating an e-mail message and sending it to your SMTP server.  You are persisting / creating information in the registry database in the form of a poll message in this instance.

A object extension does not require support for all of the transform commands.  We have creating custom object extensions that don’t use all or any of the transform commands.  Examples include:

  1.  Suggestion Mapping ( http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf ) - This is an EPP object extension to support name suggestions in the form of a Name Suggestion object that only supports an info command and response.
  2.  Balance Mapping ( http://www.verisigninc.com/assets/epp-balance-mapping.pdf ) - This is an EPP object extension to support getting the balance, available credit, and credit limit information in the form of a Balance object that only supports an info command and response.
  3.  WhoWas Mapping ( http://www.verisigninc.com/assets/epp-whowas-mapping.pdf ) - This is an EPP object extension to support getting history information (e.g. domain, host, contact) information in the form of a WhoWas object that support an info command and response.

In the case of a Key Relay object extension, you can use the element <keyrelay:domainName> in place of the shorter form <keyrelay:name>, but the description of the element is the same in being the domain name that the Key Relay is associated with.

There is no violation of RFC 5730.  It comes down to whether you are extending the domain object extension in the form of a Command-Response Extension, creating a new object extension for the Key Relay message object, or creating a mix of a protocol extension (command) and an object extension (poll response).

From: <Gould>, James Gould <[email-masked]<mailto:[email-masked]>
1:52 PM To: Antoin Verschuren <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
James Gould Principal Software Engineer [email-masked]<mailto:[email-masked]>

<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>

- --
Antoin Verschuren

---

From: Christopher Browne <[email-masked]>
Date: Mon, 28 Apr 2014 11:49:34 -0400

Reactions here were broadly consistent with yours, James.

The proposal that this be an object-less command wasn't terribly popular;
several people thought that it would be more logical for this to be
something to be added or returned as an extension to the domain object.

I understand there being a desire not to add more data to associate with
domains in a registry, but frankly, if, as a registry operator operator, we
planned to support this, I think we'd rather associate the data with
domains than anything else.

Alternately, to point at the opposite position, were we inclined to refuse
to associate key data with domains, we'd be mostly inclined to refuse to
support the extension altogether; that's an entirely simpler answer to the
matter.  (And if the idea was to "not update anything in the DB", that
would indeed need to be the outcome.  If it's not to go in the DB, then it
can't go in the Poll Queue, as that is in the DB.)

The common thinking here was that it seemed like a good idea to:
a) Add keyrelay data via an extension to <domain:update>
b) Perhaps pass, to the recipient, a message indicating presence of such
data, via Poll Queue, perhaps also including all the data in the poll queue.
c) Access the data via an extension to <domain:info>.  That suggests that
there might be storage of data beyond "just" in the poll queue.

The proposal that James Gould just put forth for a Keyrelay object
extension seems no worse than that, and that seems cleaner than the initial
proposal in that it presents the same sort of object/command division of
things as we have elsewhere in the EPP standards.

I have a bit of a meta-comment...  There are several references to
databases such as the following:
   "we looked at a way to do this communication step without even touching
the DB."

It seems to me that there's something rather peculiar about discussing
databases here; while I tend to "live the database" in many of my
day-to-day duties, I try to be careful to take that hat off here.  What
we're doing here is protocol design, and that should be kept independent of
internal implementation considerations.  Whether someone's using a
relational database, hash tables, IMS, or passing data through
message-oriented middleware shouldn't be tightly encoded into the protocol.

It also seems odd to me that it seems to be imagined that associating data
with a domain indicates that there *are* database updates, whereas
associating data with a poll queue indicates that there *are not* database
updates there, when poll queue entries still need to be kept durable enough
to survive until they are sent to their recipients.

(Indeed, and this is certainly an aside, I'm a bit unhappy that RFC 4930
requires having a message count, e.g. - <msgQ count="5" id="12345"/>.
 That's more data about what's in the queue than I think there ought to
need to be.)