Re: [eppext] New draft for keyrelay available

[Rik Ribbers <[e-mail]>]

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]
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

[cid:image001.png@01D02F1F.F0E0A450]

James Gould
Distinguished Engineer
[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