Re: [eppext] New draft for keyrelay available

[Santosh Kalsangrah <[e-mail]>]

Rik,

Here is my feedback, (actually questions:))


1.       It seems it's assumed that all EPP messaging between registrar 1<->registry<->registrar 2 proposed in this draft is over secure transport. Is that ok if either or both registrar(s) connects to registry over non-secure transport?

2.       How is key information validated by receiving registrar that it is what was sent by the  other registrar. Or how is sender assured that key information would be sent as is to other end? Or this is not important?

3.       How would gaining registrar be notified back that key info it has sent is acknowledged/read by losing registrar. Or is it that gaining registrar need not to know?

4.       In case if losing registrar does not support extension in this draft, what will happen to key info?

Thanks,
Santosh K

From: EppExt [mailto:[e-mail]] On Behalf Of Rik Ribbers
Sent: Thursday, January 08, 2015 7:12 PM
To: [e-mail]
Subject: [eppext] New draft for keyrelay available

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

________________________________






NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.