Re: [eppext] New draft for keyrelay available

[Ulrich Wisser <[e-mail]>]

Hi!

At first I would like to point out that both yours and James ideas are not
that far apart.
Introduction of a new temporary object which is send from registrar to
registrar via the registry.
That would obviously need some changes to current systems at the registry
and registrars.
I believe we should keep the needed changes as small as possible.
Therefor I think that James idea to use existing commands is the way to go.

Kind regards

Ulrich


2015-01-13 11:09 GMT+01:00 Rik Ribbers <[e-mail]>nl>:

>  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
>
>
>
>
>
> *James Gould *Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
>
>
> On Jan 8, 2015, at 8:41 AM, Rik Ribbers <[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]
> https://www.ietf.org/mailman/listinfo/eppext
>
>
>
> _______________________________________________
> EppExt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eppext
>
>