Subject: [eppext] New draft for keyrelay available

From: Rik Ribbers <[email-masked]>
Date: Thu, 8 Jan 2015 13:41:41 +0000

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 9 Jan 2015 14:29:15 +0000

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
[email-masked]

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

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

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

All,

The major  changes are:

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

---

From: Rik Ribbers <[email-masked]>
Date: Tue, 13 Jan 2015 10:09:04 +0000

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:[email-masked]]
Sent: vrijdag 9 januari 2015 15:29
To: Rik Ribbers
Cc: [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Rik,

  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
[email-masked]

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

All,

The major  changes are:

Kind regards,
Rik Ribbers

---

From: "Gould, James" <[email-masked]>
Date: Tue, 13 Jan 2015 13:22:31 +0000

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

James Gould
Distinguished Engineer
[email-masked]

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

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

James,

Gr,
Rik

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

Rik,

Regards,

—

JG

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

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

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

All,

The major  changes are:

Kind regards,
Rik Ribbers

---

From: Miek Gieben <[email-masked]>
Date: Mon, 19 Jan 2015 09:47:34 +0000

[ Quoting <[email-masked]> in "Re: [eppext] New draft for keyrelay..." ]
>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.

I didn't see any replies, so I'm assuming not that many people care about this
issue.

As one of the draft authors I think we should leave the draft in its current
state.

/Miek

--
Miek Gieben

---

From: Maarten Bosteels <[email-masked]>
Date: Mon, 19 Jan 2015 11:26:16 +0000

Hi all,

I agree with James that creating a Key Relay Object Mapping instead of 
mixing of a protocol extension for the command and an object mapping for 
the poll response seems simpler.
And I am all for simpler ;-)
At DNS Belgium we have in the past created extra verbs using a protocol 
extension, but in most cases it proved afterwards to be more appropriate 
to use an plain command/response extension or a new Object Mapping.

Like Miek, I also assume not many people care about this issue. I think 
for the following reasons:
A) Both options will work: it's a very technical choice with little impact 
on the actual users
B) I assume not many registries (and RAR's) are considering implementing 
key relay in the near future. But I'd love to be proved wrong here !

Miek or Rik, is the key-relay functionality implemented by SIDN actively 
used by many registrars ?  On both sides of the transfer/relay ?

Regards
Maarten

On 19/01/15 09:47, "Miek Gieben" <[email-masked]> wrote:

>[email-masked]

---

From: Rik Ribbers <[email-masked]>
Date: Tue, 20 Jan 2015 08:01:45 +0000

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer.

Kind regards,
Rik Ribbers

-----Original Message-----
From: Maarten Bosteels [mailto:[email-masked]] 
Sent: maandag 19 januari 2015 12:26
To: Miek Gieben; Gould, James; [email-masked]
Cc: Rik Ribbers
Subject: Re: [eppext] New draft for keyrelay available

Hi all,

I agree with James that creating a Key Relay Object Mapping instead of mixing of a protocol extension for the command and an object mapping for the poll response seems simpler.
And I am all for simpler ;-)
At DNS Belgium we have in the past created extra verbs using a protocol extension, but in most cases it proved afterwards to be more appropriate to use an plain command/response extension or a new Object Mapping.

Like Miek, I also assume not many people care about this issue. I think for the following reasons:
A) Both options will work: it's a very technical choice with little impact on the actual users
B) I assume not many registries (and RAR's) are considering implementing key relay in the near future. But I'd love to be proved wrong here !

Miek or Rik, is the key-relay functionality implemented by SIDN actively used by many registrars ?  On both sides of the transfer/relay ?

Regards
Maarten

On 19/01/15 09:47, "Miek Gieben" <[email-masked]> wrote:

>>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.
>
>I didn't see any replies, so I'm assuming not that many people care 
>about this issue.
>
>As one of the draft authors I think we should leave the draft in its 
>current state.
>
>/Miek
>
>--
>Miek Gieben
>

---

From: Ulrich Wisser <[email-masked]>
Date: Fri, 30 Jan 2015 10:14:29 +0100

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 <[email-masked]>:

> 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.
>
>
>
> *From:* Gould, James [mailto:[email-masked]]
> *Sent:* vrijdag 9 januari 2015 15:29
> *To:* Rik Ribbers
> *Cc:* [email-masked]
> *Subject:* Re: [eppext] New draft for keyrelay available
>
>
>
> Rik,
>
>
>
>    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
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
>
>
> On Jan 8, 2015, at 8:41 AM, Rik Ribbers <[email-masked]> 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:
>
>
>

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 30 Jan 2015 09:34:59 +0000

Hello Ullrich,

Thanks for your response, it looks like we’re getting somewhere. Like I said in Honolulu James and I don’t agree but we need others to share their thoughts on this and that is starting to happen.

Hopefully more people express there opinion on the issue and get the draft moving again.

Kind regards,

Rik Ribbers

From: EppExt [mailto:[email-masked]] On Behalf Of Ulrich Wisser
Sent: vrijdag 30 januari 2015 10:14
To: [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

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 <[email-masked]<mailto:[email-masked]>>:
James,

Gr,
Rik

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

Rik,

Regards,

—

JG

James Gould
Distinguished Engineer
[email-masked]<http://[email-masked]>

703-948-3271<tel:703-948-3271>
12061 Bluemont Way
Reston, VA 20190

All,

The major  changes are:

Kind regards,
Rik Ribbers

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 14:20:01 +0000

> From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
> Sent: Tuesday, January 20, 2015 3:02 AM
> To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]
> Thx for the feedback, I hope more people with experience on extending
> EPP will state their opinion on the list.
> 
> We have implemented the functionality in our registration system, but
> it is not very actively used. What we see is that most registrars go
> insecure. Most of the time we see a transfer command followed (some
> time later in time) by a domain update to remove the old key material
> and add new key material. There is even a losing registrar that removes
> all DNS key data when a registrant requests its authorization token
> before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this differently. EPP commands typically act on or read data from objects, and if I'm reading keyrelay correctly the <relay> command isn't doing either of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrieved with a <poll> command. It would be more architecturally consistent to create a temporary relay object with the needed information and use an <info> command to retrieve the data. <poll> can be used to notify the receiving client that the information is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't widely supported by registrars, so it makes sense that we're not seeing a lot of use. I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 14:57:27 +0000

Scott,

I believe the intent is to insert the transient object into the poll queue for the target client.  The acknowledgement of the poll message should result in the implicit removal of the transient object from the server.  With what you’re proposing, the source client would create the transient object that I’m assuming would result in a poll notification containing a signal to the client to submit an info command to get the transient object information?  I’m assuming that the target client would then need to delete the transient object once they’re done with processing the message.  I believe it’s simpler and consistent with the concept of creating a transient poll message to support the create to create the poll message and the info response poll message for the consumption of the transient object.  In this case the poll queue is functioning as the repository for the transient object with the signal and data being one and the same, and the deletion of the transient object handled via the standard poll queue mechanism.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 15:08:30 +0000

EPP has no concept of "objects" in the poll queue. The poll queue manipulates messages. Objects are manipulated by transform commands like create, delete, etc.

I was thinking that the source client would create a relay object, which would result in a message being queued for the target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which would be slightly longer-lived, but would be automatically deleted when it expired).

Scott

From: Gould, James
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Scott,

I believe the intent is to insert the transient object into the poll queue for the target client.  The acknowledgement of the poll message should result in the implicit removal of the transient object from the server.  With what you're proposing, the source client would create the transient object that I'm assuming would result in a poll notification containing a signal to the client to submit an info command to get the transient object information?  I'm assuming that the target client would then need to delete the transient object once they're done with processing the message.  I believe it's simpler and consistent with the concept of creating a transient poll message to support the create to create the poll message and the info response poll message for the consumption of the transient object.  In this case the poll queue is functioning as the repository for the transient object with the signal and data being one and the same, and the deletion of the transient object handled via the standard poll queue mechanism.

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 15:32:08 +0000

Scott,

EPP can be extended to support new types of objects, and objects can support a different set of commands and responses based on the requirements of those objects.   Objects can be created on the server-side without any support for transform by the client.  In this case, the intent is to create a poll queue message object that is consumed and automatically deleted when consumed, so the create functions as an enqueue and the poll info response functions as a dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert the message in the poll queue and the poll message in the form of an info response to consume the message.  There is no need for the implementation to create any form of a transient object outside the poll queue, since the poll queue is the transient object store for this object type.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

EPP has no concept of “objects” in the poll queue. The poll queue manipulates messages. Objects are manipulated by transform commands like create, delete, etc.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Scott,

—

JG

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

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 15:35:03 +0000

Jim, that's not how I would have designed it. To each his own.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 30 Jan 2015 16:39:40 +0000

Scott,

The intention of the relay command is more of sending a message (with information) then the manipulation of objects, but James explained it pretty well.

The  thing that triggered me is the second part of your reply:

Ø  I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work.

Although I'm not an IETF expert I assumed that when the document was adapted by the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational or standards track. And as far I understood it is not up to the WG to make a document informational, that is something the IESG does. Feel free to correct me if I misunderstood things.

However the real question is: Who can confirm this need?

We see the need for an automated secure transfer of domainnames in our daily operation. As the adoption of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solution which is described in the draft and believe it is a good pragmatic solution for a the problem. But  I agree that the need is not extremely high at this point, but it will be in the near future. Should we wait for that or act upon what we believe is inevitable?  We choose not to wait.

Kind regards,
Rik

From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: RE: [eppext] New draft for keyrelay available

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 17:02:40 +0000

Rik,

We have not implemented the extension, but as you point out if the adoption for DNSSEC grows then so will the need for such an extension.  I support the idea of creating a standards track extension for this purpose; although we need to ensure that there is community consensus and there is more than one implementation of it.  There has been some good dialog on the list lately, so hopefully it will continue or even better yet pick up.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Jan 30, 2015, at 11:39 AM, Rik Ribbers <[email-masked]<mailto:[email-masked]>> wrote:

Scott,

The  thing that triggered me is the second part of your reply:

>  I don't have an issue with continuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current approach on the standards track. We should confirm the need before doing standards track work.

Although I’m not an IETF expert I assumed that when the document was adapted by the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational or standards track. And as far I understood it is not up to the WG to make a document informational, that is something the IESG does. Feel free to correct me if I misunderstood things.

Kind regards,
Rik

Jim, that’s not how I would have designed it. To each his own.

Scott

From: Gould, James

Scott,

—

JG

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

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

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 17:27:07 +0000

> when the document was adapted by the WG the WG acknowledges the need for a standard

No, it means the IETF and the WG decided to work on the document to meet the purpose stated in the WG charter. That purpose and the charter can change if time reveals the need for change. We can propose anything to the IESG for consideration if it makes sense to do so, especially if it becomes clear that we do not have consensus on a particular topic.

You said "adapted" - did you mean adopted? "Adapted" would imply "change", but you've indicated a preference to not change the basic approach. Without consensus on the approach it's going to be tough to produce a Proposed Standard.

Scott

From: Rik Ribbers [mailto:[email-masked]]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; [email-masked]
Subject: RE: [eppext] New draft for keyrelay available

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 18:39:26 +0000

> The intention of the relay command is more of sending a message (with information) then the manipulation of objects, but James explained it pretty well.

I just thought of something else while re-reading this sentence. What happens if the exact same command is sent twice? Is a second message sent?

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 18:49:30 +0000

Yes, each create would result in a new message to get created and enqueued.  Since the create is for a transient message object, there is no issue with creating more then one message with the same data.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

Cc: Maarten Bosteels; Miek Gieben; [email-masked]<mailto:[email-masked]>

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

—

JG

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

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

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 30 Jan 2015 19:07:58 +0000

Scott,

Thanks for the clarification and I did mean adopted.

Ø  but you've indicated a preference to not change the basic approach.

That is indeed our preference but as two people (Ulrich Wisser and Maarten Bosteels) this week clearly stated that they think the proposal of James is the way to go we might have to reconsider as standard track is also our preference. But than again the majority of the working group members do not actively participate in this discussion. So are 2 (Ok 3, as you are someone in the EPP community ;-)) people enough to reconsider? I got no clue on how big the WG actually is (anybody?), but  I'm still hoping that more people (especially the ones that hummed in Honolulu) state on the issue. If the majority of the WG thinks we've done it wrong who are we not to reconsider things and go for the proposal of James, the concept of relaying DNSSEC data doesn't change only the XML will  and in the end the concept is the most important part.

So again I call upon the members of this working group to review the draft and see what the problem is (http://www.ietf.org/mail-archive/web/eppext/current/msg00241.html) and state their opinion on this mailing list. Even if you don't care or have no objection let it know then at least we know where we are standing and can decide on how to proceed.

Kind regards,
Rik Ribbers

From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: vrijdag 30 januari 2015 18:27
To: Rik Ribbers; Gould, James
Cc: Maarten Bosteels; Miek Gieben; [email-masked]
Subject: RE: [eppext] New draft for keyrelay available

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 19:11:07 +0000

> Since the create is for a transient message object, there is no issue with creating more then one message with the same data.

If two or more messages end up being enqueued, what is the client supposed to assume about any repeats after retrieving and acting on the first message? How is idempotency preserved?

Scott

From: Gould, James
Sent: Friday, January 30, 2015 1:50 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 30 Jan 2015 19:12:21 +0000

Yes for every relay command a message is sent.

We've taken some measures in our system for not flooding the system. In the draft we've written some security considerations regarding this  as one could flood the registrars poll queue.

Kind regards
Rik

Sent: vrijdag 30 januari 2015 19:39

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 20:02:52 +0000

Scott,

There is a level of indirection here, where the goal of the extension is to create a message to be sent to another party.  There is no idempotency issue with the creation of the message itself since it’s transient and immutable.  Creating a duplicate message  with the same data creates another immutable, transient object.  The consuming client will handle the idempotency aspects by ensuring that receipt of a duplicate message does not change the result.  For example, consumption of the relay of the same key should not result in the key getting duplicated in the resulting zone.  This is the responsibility of the consuming client and not of the server.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

JG

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

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

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 20:18:01 +0000

> This is the responsibility of the consuming client and not of the server

EPP commands are supposed to be idempotent *without* the client needing to assume responsibility for any special actions. We can do better.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 3:03 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Scott,

There is a level of indirection here, where the goal of the extension is to create a message to be sent to another party.  There is no idempotency issue with the creation of the message itself since it's transient and immutable.  Creating a duplicate message  with the same data creates another immutable, transient object.  The consuming client will handle the idempotency aspects by ensuring that receipt of a duplicate message does not change the result.  For example, consumption of the relay of the same key should not result in the key getting duplicated in the resulting zone.  This is the responsibility of the consuming client and not of the server.

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

JG

James Gould
Distinguished Engineer

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

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Jan 2015 20:34:42 +0000

Scott,

There are three parties here which include the producing client, the server, and the consuming client.  What you’re referring to in the EPP command is the producing client and server, which does not have any idempotent issue since the message is transient and immutable.  To address your idempotency concern end-to-end, maybe the producing client should add a unique relay identifier that the relaying consumer ensures to process only once.  Messages with a duplicate relay identifier must be processed a single time by the relaying consumer.  Does that work?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

—

JG

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

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

Scott

From: Gould, James

JG

James Gould
Distinguished Engineer

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

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

Scott,

—

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: Santosh Kalsangrah <[email-masked]>
Date: Fri, 30 Jan 2015 20:36:08 +0000

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:[email-masked]] On Behalf Of Rik Ribbers
Sent: Thursday, January 08, 2015 7:12 PM
To: [email-masked]
Subject: [eppext] New draft for keyrelay available

All,

The major  changes are:

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.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Jan 2015 21:02:27 +0000

> Messages with a duplicate relay identifier must be processed a single time by the relaying consumer.  Does that work?

I'm not a fan of this approach so I'd rather not try to fix it, but anything that reduces the risk of a repeated action would be an improvement. I think it would be better to consider an alternative that carries no risk of duplication.

Scott

From: Gould, James
Sent: Friday, January 30, 2015 3:35 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Scott,

There are three parties here which include the producing client, the server, and the consuming client.  What you're referring to in the EPP command is the producing client and server, which does not have any idempotent issue since the message is transient and immutable.  To address your idempotency concern end-to-end, maybe the producing client should add a unique relay identifier that the relaying consumer ensures to process only once.  Messages with a duplicate relay identifier must be processed a single time by the relaying consumer.  Does that work?

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

JG

James Gould
Distinguished Engineer

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

Scott

Scott,

Kind regards,
Rik

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

Scott

From: Gould, James

Scott,

-

JG

James Gould
Distinguished Engineer

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

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 30 Jan 2015 21:30:45 +0000

Forgot to include the list.... sorry

From: Rik Ribbers
Sent: vrijdag 30 januari 2015 22:30
To: 'Santosh Kalsangrah'
Subject: RE: New draft for keyrelay available

Hello Santosh,

Thx for the feedback. Here are my answers:

1)      This draft uses the validated trusted EPP channel. According to RFC5734, section 8 this must be a TCP/TLS connection. The idea is here that a registrar doesn't always know how or to whom the DNSSEC key material must be send. By using the registry EPP interface there is a secure and trusted path.

2)      In the draft we state that depending on the use case a server must determine what elements of the data must be used for 1) validating the request and 2) determining the registrar to relay the data to. For the keyrelay usecase this is  the authInfo element for 1) and for 2) the domainname is used.

3)      This is actually out-of scope for this specific draft. The mechanism is  to send the command and if the server approves (return EPP code 1000) the gaining registrar must assume the message is on the poll queue of the losing registrar. There is a different draft which describes the process of a secure domain transfer which describes the complete process (https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 )

4)      This depends on the policy of the registry. For us a registrar must acknowledge the poll message what happens afterwards it out of our hands and depends on the registrars. There are several issues (e.g. the registrar is not always the DNS-operator) that are involved with the secure transfer of a domainname that are not covered here. This draft focusses on relaying  the keymaterial from registrar 1 and 2. Again see the draft https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 for more information.

Kind regards,
Rik

From: Santosh Kalsangrah [mailto:[email-masked]]
Sent: vrijdag 30 januari 2015 21:36
To: Rik Ribbers; [email-masked]<mailto:[email-masked]>
Subject: RE: New draft for keyrelay available

Rik,

Thanks,
Santosh K

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

All,

The major  changes are:

Kind regards,
Rik Ribbers