Re: [eppext] New draft for keyrelay available

["Gould, James" <[e-mail]>]

All,

I agree with Rik that more from the WG must weigh in on this.  I believe Rik and I understood fully each others perspective, but we simply don’t agree.  Please take some time to review the two different approaches and reply to the list with your opinion.

To be clear, my preferred approach is to use an object extension for both the command and the poll message response as in:

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 message.</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>


The latest version of draft-ietf-eppext-keyrelay incorporates a general r:relayData element with a new extension point for concrete data to relay as in k:keyRelayData.  If an object extension was used, new relay data would be represented using another object extension, which will be present in the greeting and login list of objURI’s.  For example, if I wanted to relay a Hello World message, I would create a Hello World object extension with the URI urn:ietf:params:xml:ns:helloworld-1.0, that follows the relay protocol pattern of defining the create command and the info response for the poll message.

Command looks like:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:helloworld="urn:ietf:params:xml:ns:helloworld-1.0">
 <command>
   <create>
     <helloworld:create>
       <helloworld:value>Hello World from Jim</keyrelay:name>
     </helloworld:create>
   </create>
   <clTRID>123456</clTRID>
 </command>
</epp>

Poll message looks like:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  xmlns:helloworld="urn:ietf:params:xml:ns:helloworld-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>Hello World Relay message.</msg>
    </msgQ>
    <resData>
      <helloworld:infData>
       <helloworld:value>Hello World from Jim</keyrelay:name>
      </keyrelay:infData>
    </resData>
    <trID>
       <clTRID>BCD-23456</clTRID>
       <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>


If both the keyrelay and helloworld extensions were supported, the svcMenu element of the login and greeting may look like:


       <svcMenu>
         <version>1.0</version>
         <lang>en</lang>
         <lang>fr</lang>
         <objURI>urn:ietf:params:xml:ns:obj1</objURI>
         <objURI>urn:ietf:params:xml:ns:obj2</objURI>
         <objURI>urn:ietf:params:xml:ns:obj3</objURI>

         ...


         <objURI>urn:ietf:params:xml:ns:keyrelay-1.0</objURI>


         <objURI>urn:ietf:params:xml:ns:helloworld-1.0</objURI>


         ...

<svcExtension> <extURI>http://custom/obj1ext-1.0</extURI> </svcExtension> </svcMenu>

In doing so, the server will be able to know whether or not the client supports the specific relay message type.  There is a general question of what the server should do in the event that the client cannot process a specific poll message.  Comparing the greeting and login services can easily identify relay object support issues.

In the end, there is no need to utilize a protocol extension to create a transient poll message object and mix a protocol extension for the command and an object extension for the response.

Please provide your feedback.

Thanks,


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

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

On Jan 13, 2015, at 5:09 AM, Rik Ribbers <[e-mail]<mailto:[e-mail]>> wrote:

James,

Thank you for the feedback.

My feedback on issue 1 and 2:

I get a feeling we are running in circles. All arguments have been mentioned in previous posts on this mailinglist. So what it boils down to is what the rest of the WG thinks of this. So I politely , but  urgently ask the other members on this list to respond to the question: Should we reconsider extending EPP with a new command and use the object or protocol extension James proposes (see http://www.ietf.org/mail-archive/web/eppext/current/msg00241.html) If there are no responses the authors and the WG cannot make progress on this document.

For issue 3 and 4: We will incorporate the changes in the next version of the draft.

Gr,
Rik



From: Gould, James [mailto:[e-mail]]
Sent: vrijdag 9 januari 2015 15:29
To: Rik Ribbers
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New draft for keyrelay available

Rik,

Below is my feedback to the updated draft:


  1.  As noted in past mailing list comments and in person discussions, I don’t agree with the mixing of a protocol extension for the command and an object mapping for the poll response.  I have provided examples of implementing this draft using either an object mapping or a command response extension of domain.  In it’s current form, I’m assuming that the EPP greeting and login would include the urn:ietf:params:xml:ns:relay-1.0 URI in both a <objURI> and an <extURI> element.  I highly recommend that you reconsider this.
  2.  You are making keyrelay more generic by creating a new extension point of the data to relay, with the key data being one concrete type.  I still believe that creating a Key Relay Object Mapping would have been the best route to go, since the creation of a Key Relay object would add it into the poll queue for consumption by the losing registrar.  The only command supported by the mapping is create along with the poll info response.  The create is creating a transient object.  If other types of data need to be “relayed”, a similar approach could be taken without having to add an additional layer of extensibility.  A new EPP object mapping would be defined for the new type.  The key relay along with any other relay objects will be properly exposed in the EPP greeting and login <objURI> elements.
  3.  Nit in 3.1.1, “An OPTIONAL <clTRID> (client transaction identifier) element that MAY be used to uniquely identify the command to the registrar”, should reference client instead of registrar.
  4.  What is the expected response to the <relay> command?  I’m assuming that it’s as EPP response as defined in section 2.6 of RFC 5730 where the <clTRID> value is set with the <r:clTRID> value associated with the command if supplied by the client.


Regards,

—


JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://7/[e-mail]>

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

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

On Jan 8, 2015, at 8:41 AM, Rik Ribbers <[e-mail]<mailto:[e-mail]>> wrote:


All,

As you (may) have noticed we submitted a new version of the keyrelay draft. In this draft we tried to solve all the open issues, remarks and feedback we received.

The major  changes are:

  1.  Introducing the <relay> command, and thus seperating the data and
       the command.

   2.  Updated the Introduction, describing the general use of relay vs
       the intended use-case of relaying DNSSEC key data.

   3.  Restructuring the document to make it more inline with existing
       EPP extensions.

In the end it has become a major rewrite and as always feedback is welcome.

Kind regards,
Rik Ribbers
_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext