Subject: [eppext] Moving forward with the keyrelay draft

From: Rik Ribbers <[email-masked]>
Date: Wed, 12 Nov 2014 19:55:24 +0000

I've been in contact with the other authors after the discussion in the WG last Monday and there are two thing I promised to bring back to the list.

1) The authors support the standards track. Depending of the outcome of the discussion on the mailing list we will publish a new version of the document.

That was the easy part. The next part will hopefully spark some discussion on the list.

2) Major issue for moving forward with the draft is how we:
  A) Resolve the issue James Gould brought up on the namespaces  in the EPP greeting.
  B) Reach consensus on which extensions to be used.

As stated in the WG session we think none of the existing commands or the existing object mappings reflect what we want to accomplish. For us it is more then slightly modifying the protocol in our favor (as described in RFC3735).

What we want to do with the XML is in short the following
- Create a separate new namespace "urn:ietf:params:xml:ns:relay-1.0" for sending the command to the registry.
- Use the "urn:ietf:params:xml:ns:keyrelay-1.0" namespace for defining the data to be relayed.
- To avoid confusion between namespaces in the xml, rename the command from <keyrelay> to <relay>. This was originally suggested by Jay Daley on the mailing list. Side effect is that the relay command becomes more generic and can be reused for relaying data if more business cases emerge in the future.

The resulting  XML will look like this (I stripped the fluffy stuff to focus on the structure)

The EPP command:

<epp><extension>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
    ...
   </k:keyData>
   </r:relay>
</extension></epp>

The EPP poll response:

...
<resData>
   <r:relay xmlns:r="urn:ietf:params:xml:ns:relay-1.0">
   <k:keyData  xmlns:k="urn:ietf:params:xml:ns:keyrelay-1.0">
     ...
     {key data}
     ...
   </k:keyData>
   </r:relay>
</resData>
...

And the greeting will become like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <greeting>
    ...
    <svcMenu>
      ...
      <objURI>urn:ietf:params:xml:ns:keyrelay-1.0</objURI>
      <svcExtension>
        ...
        <extURI>urn:ietf:params:xml:ns:relay-1.0</extURI>
      </svcExtension>
    </svcMenu>
    ...
  </greeting>
</epp>

Please provide feedback on the list or come up to me if you are in Honolulu. I will be (t)here until Friday.

Rik

---

From: "Gould, James" <[email-masked]>
Date: Wed, 12 Nov 2014 20:24:01 +0000

Rik,

I still believe that this can be easily accomplished by creating a single object extension called Key Relay that supports create to enqueue the poll message and the info response as the content of the dequeue of the poll message.  I understand the concern around creating an object extension for a transient object, but I don’t believe the EPP RFC’s limit the type of objects that can be provisioned.  An object can be a standard object stored in the database for subsequent update (e.g. domain, host, contact), an object can be a message object put into a queue for consumption by an authorized client (e.g. key relay), or an object can be a read-only object created by the server for various purposes like (name suggestion, registry meta-data, etc.).  Can you describe to the list your issue with creating an object mapping for key relay as opposed to creating a combination of a protocol extension for the enqueue and an object extension for the dequeue?  Creating two separate namespaces is a step in the right direction if two extensions are needed, but I believe that the use of a protocol extension for the enqueue is overly complex and can be better handled by using an object extension.  One additional question is wether two separate extensions (protocol and object) requires two separate drafts?

We can discuss this more in person tomorrow and report the results of the discussion back to the list.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Nov 12, 2014, at 9:55 AM, Rik Ribbers <[email-masked]<mailto:[email-masked]>> wrote:

The EPP command:

<epp><extension>

The EPP poll response:

...
<resData>

Rik
_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Rik Ribbers <[email-masked]>
Date: Wed, 12 Nov 2014 21:06:10 +0000

James,

Thanks for the feedback. I'm fully aware of your opinion, but I'm hoping other people will step up and state their opinion on the matter.

|Can you describe to the list your issue with creating an object mapping for key relay as opposed to creating a
|combination of a protocol extension for the enqueue and an object extension for the dequeue?

Looking at the object mappings there are, we would have to provide mapping for an existing command, the most obvious ones would be:

<create> --> The keyData is not created as a result of the protocol command <create>. The key is created by the DNS operator and relayed to losing DNS operator (using the Registrar/Registry channel).
<transfer> --> Transfer is not used as a transfer is all about changing ownership of data managed by the Registry.
<update>   --> An <update> should in our opinion be reserved for the registrar of record (for an object managed by the Registry).

Other commands are for obvious reasons not usable, so these are the reasons behind the choice.

|One additional question is wether two separate extensions (protocol and object) requires two separate drafts?

That's a valid question on which I don't know the answer but if needed we will split them into two drafts. Actually this would require a re-charter of the WG. Let's first wait on the feedback on the first part and then see if splitting up is required.

Rik

From: Gould, James [mailto:[email-masked]]
Sent: woensdag 12 november 2014 10:24
To: Rik Ribbers
Cc: [email-masked]
Subject: Re: [eppext] Moving forward with the keyrelay draft

Rik,

I still believe that this can be easily accomplished by creating a single object extension called Key Relay that supports create to enqueue the poll message and the info response as the content of the dequeue of the poll message.  I understand the concern around creating an object extension for a transient object, but I don't believe the EPP RFC's limit the type of objects that can be provisioned.  An object can be a standard object stored in the database for subsequent update (e.g. domain, host, contact), an object can be a message object put into a queue for consumption by an authorized client (e.g. key relay), or an object can be a read-only object created by the server for various purposes like (name suggestion, registry meta-data, etc.).  Can you describe to the list your issue with creating an object mapping for key relay as opposed to creating a combination of a protocol extension for the enqueue and an object extension for the dequeue?  Creating two separate namespaces is a step in the right direction if two extensions are needed, but I believe that the use of a protocol extension for the enqueue is overly complex and can be better handled by using an object extension.  One additional question is wether two separate extensions (protocol and object) requires two separate drafts?

Thanks,

-

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

The EPP command:

<epp><extension>

The EPP poll response:

...
<resData>

Rik

---

From: "Gould, James" <[email-masked]>
Date: Wed, 12 Nov 2014 21:34:36 +0000

Rik,

I completely agree that others should weigh in on this.  Those that hummed, please respond.  I see two options that have been presented, where I’ll remove the command-response extension option to simplify things.  I include some notes embedded in your message below.

1. Use protocol extension with object extension

Command looks like:

<epp><extension>

Poll message looks looks like:

...
<resData>
…

2. Use object extension

Command looks like:

<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<http://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>

Poll message looks like:

<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<http://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>

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Nov 12, 2014, at 11:06 AM, Rik Ribbers <[email-masked]<mailto:[email-masked]>> wrote:

James,

A Key Relay poll message is created.  The keyData is contained within the Key Relay poll message.  The purpose of the Key Relay object is to be enqueued into the poll queue of the losing Registrar to be consumed via a dequeue.  I don’t see an issue with creating a poll message object via a create.

I don’t believe transfer is applicable if a new Key Relay object extension is created, since the first step is to create the Key Relay message.  There is no need for a transfer.

Yes, I don’t see the update in play if an object extension is defined.  The extension of <update> could be used if a command response extension of domain is desired, but I don’t believe the command response extension is the right way to go.

Rik

From: Gould, James [mailto:[email-masked]]
Sent: woensdag 12 november 2014 10:24
To: Rik Ribbers
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] Moving forward with the keyrelay draft

Rik,

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://81/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

The EPP command:

<epp><extension>

The EPP poll response:

...
<resData>

Rik

---

From: Rubens Kuhl <[email-masked]>
Date: Wed, 12 Nov 2014 19:38:55 -0200

James,

It would be interesting to know which of the options would trigger IPR like the ones described in https://datatracker.ietf.org/ipr/2393/ <https://datatracker.ietf.org/ipr/2393/> and which ones does not, as this might be a factor in its acceptance by the community. 

Rubens

> Em 12/11/2014, à(s) 18:24:000, Gould, James <[email-masked]> escreveu:
> 
> Rik,
> 
> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
> 
> James Gould
> Distinguished Engineer
> [email-masked] <x-msg://38/[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com <http://verisigninc.com/>
> On Nov 12, 2014, at 9:55 AM, Rik Ribbers <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/eppext <https://www.ietf.org/mailman/listinfo/eppext>
> [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Nov 2014 18:37:28 +0000

Rubens,

This thread is centered around coming up with the best structure of the keyrelay extension.  Do you have an opinion related to the structural options?

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Nov 12, 2014, at 11:38 AM, Rubens Kuhl <[email-masked]<mailto:[email-masked]>> wrote:

James,

It would be interesting to know which of the options would trigger IPR like the ones described in https://datatracker.ietf.org/ipr/2393/ and which ones does not, as this might be a factor in its acceptance by the community.

Rubens

Em 12/11/2014, à(s) 18:24:000, Gould, James <[email-masked]<mailto:[email-masked]>> escreveu:

Rik,

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]<x-msg://38/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

The EPP command:

<epp><extension>

The EPP poll response:

...
<resData>

Rik

---

From: Rik Ribbers <[email-masked]>
Date: Thu, 13 Nov 2014 18:45:03 +0000

+1 Let's not start an IPR discussion here.

Please provide feedback on the options.

Rik

From: Gould, James [mailto:[email-masked]]
Sent: donderdag 13 november 2014 8:37
To: Rubens Kuhl
Cc: Rik Ribbers; [email-masked]
Subject: Re: [eppext] Moving forward with the keyrelay draft

Rubens,

Thanks,

-

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

James,

Rubens

Rik,

Thanks,

-

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

The EPP command:

<epp><extension>

The EPP poll response:

...
<resData>

Rik