Subject: Re: [eppext] New draft for keyrelay available

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Feb 2015 13:16:18 +0000

> -----Original Message-----
> From: Antoin Verschuren [mailto:[email-masked]]
> Sent: Thursday, February 05, 2015 7:45 AM
> To: Hollenbeck, Scott
> Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels;
> [email-masked]
> Subject: Re: [eppext] New draft for keyrelay available
> 
> Scott,
> 
> What do you considder a duplication?

The exact same message being sent or received more than once. This introduces a risk of inconsistency between client and server if there isn't a way to provide command idempotency, which is one of the reasons I prefer an approach that involves creating a transient object. Note that Section 2 of RFC 5730 includes this statement about EPP commands:

"EPP commands fall into three categories: session management commands, query commands, and object transform commands."

Which of these categories does the <relay> command fall into? The draft describes it as a "transient" command, and there's no mention of "transient" commands in 5730.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 5 Feb 2015 14:08:06 +0000

Scott,

I believe that RFC 5730 is not limited to a certain class of objects that can be provisioned.  A create of a transient, immutable message object is a transform command and the use of a poll response supports a query command.  In this case the server is being used to support the passing of messages between two clients.  There is no idempotency issue between the clients and the server since the object is immutable, but there is an idempotency issue between the participating clients that could be addressed by including a unique relay identifier in the relay message that the consuming client can simply verify against previously applied relay identifiers ahead of applying the relay message.  There could be other use cases were clients need to communicate through the server using a transient object message pattern.

My recommendation to the authors of the Key Relay Extension is to make the draft an object mapping with a create transform command, a the poll response, and with a unique relay identifier to address the end-to-end idempotency concern.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Feb 5, 2015, at 8:16 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Antoin Verschuren [mailto:[email-masked]]
Sent: Thursday, February 05, 2015 7:45 AM
To: Hollenbeck, Scott
Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels;
[email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] New draft for keyrelay available

Scott,

Scott

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 5 Feb 2015 15:32:45 +0100

I believe this is the essence of the confusion.
The authors believe that like Scott, an "EPP <create> Command" always creates an object in the registry. That is how we read section 2.9.3 of RFC5730.
James believes that a create command can also be used to create "something” in the poll queue only, without creating an object in the registry. Reusing the create command like this is less work.

For relay, it is not desirable to create an object in the registry, as nothing is done with the object data after queueing in the poll queue, and just polutes the registry, let alone the question of who owns the object and what will trigger it to be deleted.

For relay we are looking for a process to place data in the poll queue only without it becomming an object in the registry.
That is why the relay draft sugested a 4th section (2.9.4) of a new type of protocol commands that we will call "Communication Commands” where a command will create a poll queue message, but does not create or change any objects in the registry. 

We cannot call this new command an "EPP <create> Command” under this new "Communication Commands” section, just like there is a difference between an "EPP <transfer> Query Command” under Query Commands, and an "EPP <transfer> Command” under the Object Transform Commands.

I have no deep knowledge of XML namespaces or mixing protocol and command extensions, but this is what this new command needs to do, and is something EPP hasn’t seen the need to do before. All previous commands were meant to touch an object in the registry.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:[email-masked]

Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott <[email-masked]> het volgende geschreven:

> 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]
> 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
> 
> VerisignInc.com
>  
> On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <[email-masked]> wrote:
> 
> 
> 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]
> 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.
> 
> 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
>  
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 5 Feb 2015 15:49:37 +0100

Like I said, I believe the <relay> command falls into a 4th category of EPP commands which I'd like to call "Communication Commands” or "Transient Commands” (name to be discussed).
So we will have session management commands, query commands, object transform commands and communication commands.
We didn’t see the need for this category back then. That is the innovative idea of relay.
Communication commands don’t touch objects, so there is no risk of inconsistency in the registry.

- -- 
Antoin Verschuren

---

From: Maarten Bosteels <[email-masked]>
Date: Thu, 5 Feb 2015 14:57:08 +0000

I completely agree with James' argumentation and recommendation.

Best regards,
Maarten

From: <Gould>, James <[email-masked]<mailto:[email-masked]>>
Date: Thursday 5 February 2015 15:08
To: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Cc: Antoin Verschuren <[email-masked]<mailto:[email-masked]>>, Rik Ribbers <[email-masked]<mailto:[email-masked]>>, Miek Gieben <[email-masked]<mailto:[email-masked]>>, Maarten Bosteels <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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

-----Original Message-----
From: Antoin Verschuren [mailto:[email-masked]]
Sent: Thursday, February 05, 2015 7:45 AM
To: Hollenbeck, Scott
Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels;

Scott,

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 5 Feb 2015 15:13:19 +0000

Antoin,

My understanding of EPP is that it defines 7 object verbs (check, info, create, delete, renew, transfer query / request / cancel / reject / approve, and update), where I don’t capture some of the base protocol commands like login, logout, and poll, with the ability to extend the protocol to support new objects in separate specifications that define which verbs are supported for those objects and what is passed in the commands and responses.  Nowhere does it state in RFC 5730 or RFC 3735 that an object extension must support a specific set of verbs and that a create must create “an object in the registry” with a single class of object.  The verbs supported are specific to the object that exists in some form in the registry.  An object could be a standard object like domain, it could be an immutable message object like with the key relay message, or could be a generated object based on a client info command ( Name Suggestion Mapping - http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html).  I believe the key is that there can be many forms of objects that are supported by the server that can be represented using an EPP object extension.  The specification of the EPP object extension defines the specifics about what verbs are supported.

Reusing a create command is not simply less work but matches what the client is doing.  The client is creating a immutable message object that is delivered to a consuming client via the poll queue.  There is a message object getting created in the registry that is automatically removed once consumed.  I don’t view this as a protocol extension based on the extensibility options provided in RFC 5730.

Please show me in the RFC’s where it states that all previous commands were meant to touch an object in the registry.  There is no way that RFC 5730 could foresee all of the possible set of objects that a server could support, which is why there is the concept of an object extension.  There is variance in the set of verbs supported by the EPP domain, host, and contact RFC’s.  A transfer and renew is not applicable to a host object and a renew is not applicable to a contact object.  EPP provides the ability to specifically define what verbs apply and what data needs to be sent and received to meet the needs of the particular object.

As stated many times on this list, there should be no mixing of a protocol extension and an object extension in a single specification, which is what is currently being done in draft-ietf-eppext-keyrelay.  Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue and is not disallowed by any text that I’m aware of in the EPP RFC’S.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Feb 5, 2015, at 9:32 AM, Antoin Verschuren <[email-masked]<mailto:[email-masked]>> wrote:

- --
Antoin Verschuren

Op 30 jan. 2015, om 16:08 heeft Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

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

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

VerisignInc.com

-----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]
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

One more opinion:

Scott

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Feb 2015 16:08:06 +0000

> Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue...

I could support this. It's consistent with what I described in this message:

http://www.ietf.org/mail-archive/web/eppext/current/msg00319.html

Scott

From: EppExt [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Thursday, February 05, 2015 10:13 AM
To: Antoin Verschuren
Cc: [email-masked]
Subject: Re: [eppext] New draft for keyrelay available

Antoin,

My understanding of EPP is that it defines 7 object verbs (check, info, create, delete, renew, transfer query / request / cancel / reject / approve, and update), where I don't capture some of the base protocol commands like login, logout, and poll, with the ability to extend the protocol to support new objects in separate specifications that define which verbs are supported for those objects and what is passed in the commands and responses.  Nowhere does it state in RFC 5730 or RFC 3735 that an object extension must support a specific set of verbs and that a create must create "an object in the registry" with a single class of object.  The verbs supported are specific to the object that exists in some form in the registry.  An object could be a standard object like domain, it could be an immutable message object like with the key relay message, or could be a generated object based on a client info command ( Name Suggestion Mapping - http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf and Balance Mapping - http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html).  I believe the key is that there can be many forms of objects that are supported by the server that can be represented using an EPP object extension.  The specification of the EPP object extension defines the specifics about what verbs are supported.

Reusing a create command is not simply less work but matches what the client is doing.  The client is creating a immutable message object that is delivered to a consuming client via the poll queue.  There is a message object getting created in the registry that is automatically removed once consumed.  I don't view this as a protocol extension based on the extensibility options provided in RFC 5730.

Please show me in the RFC's where it states that all previous commands were meant to touch an object in the registry.  There is no way that RFC 5730 could foresee all of the possible set of objects that a server could support, which is why there is the concept of an object extension.  There is variance in the set of verbs supported by the EPP domain, host, and contact RFC's.  A transfer and renew is not applicable to a host object and a renew is not applicable to a contact object.  EPP provides the ability to specifically define what verbs apply and what data needs to be sent and received to meet the needs of the particular object.

As stated many times on this list, there should be no mixing of a protocol extension and an object extension in a single specification, which is what is currently being done in draft-ietf-eppext-keyrelay.  Making draft-ietf-eppext-keyrelay an object extension that includes support for the create command addresses this issue and is not disallowed by any text that I'm aware of in the EPP RFC'S.

Thanks,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

I believe this is the essence of the confusion.
The authors believe that like Scott, an "EPP <create> Command" always creates an object in the registry. That is how we read section 2.9.3 of RFC5730.
James believes that a create command can also be used to create "something" in the poll queue only, without creating an object in the registry. Reusing the create command like this is less work.

For relay we are looking for a process to place data in the poll queue only without it becomming an object in the registry.
That is why the relay draft sugested a 4th section (2.9.4) of a new type of protocol commands that we will call "Communication Commands" where a command will create a poll queue message, but does not create or change any objects in the registry.

We cannot call this new command an "EPP <create> Command" under this new "Communication Commands" section, just like there is a difference between an "EPP <transfer> Query Command" under Query Commands, and an "EPP <transfer> Command" under the Object Transform Commands.

I have no deep knowledge of XML namespaces or mixing protocol and command extensions, but this is what this new command needs to do, and is something EPP hasn't seen the need to do before. All previous commands were meant to touch an object in the registry.

- --
Antoin Verschuren

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

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

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

VerisignInc.com

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: Antoin Verschuren <[email-masked]>
Date: Thu, 5 Feb 2015 18:07:50 +0100

Op 5 feb. 2015, om 15:08 heeft Gould, James <[email-masked]> het volgende geschreven:

> I believe that RFC 5730 is not limited to a certain class of objects that can be provisioned.  A create of a transient, immutable message object is a transform command and the use of a poll response supports a query command.  

Apologies James if I am confused. 

So the question boiles down to:

-What is meant by "object” in RFC5730?

The authors believe what is meant here with "object" is something stored in the registry database that requires uniqueness and ownership. Not all EPP commands can be performed on all objects, A database can be extended with new objects which will require an extension to provision the new object, or an existing object could be extended with new records which needs an extension of the command to provision the new records.
You think "object" does not relate to a registry database table and can be any data blob in the communication stream as well.

If we all agree that an object means any blob, should that be clarified in RFC5730?
At least I am confused when object does not refer to an object in the registry database, as I cannot verify uniqueness and consistancy of the EPP processes over the database.

> My recommendation to the authors of the Key Relay Extension is to make the draft an object mapping with a create transform command, a the poll response, and with a unique relay identifier to addres…

I don’t see the need for a seperate unique relay identifier. Since the timestamp can be part of the calculation of the expiry of the relayed key, no second message is identical. If and only if the timestamp is different and the expiry is not dependant of the timestamp and the rest of the message is identical can the message be disguarded as identical, but we don’t need a duplicate field to identify that, and it is left to the receiver how to interpret that. There may be future use cases where only the timestamp is different but where the message is valid and needs to be processed by the receiver.

- -- 
Antoin Verschuren

---

From: "Gould, James" <[email-masked]>
Date: Thu, 5 Feb 2015 18:22:38 +0000

Antoin,

RFC 5730 does not explicitly specify what an object is or is not.  I believe that you are putting unnecessary restrictions on what an object in EPP can be.  To give you an example, the IDN Table Mapping ( https://tools.ietf.org/html/draft-gould-idn-table ) that was posted today defines a new IDN Table object that supports no transform commands and it may or may not be physically stored in the registry database.  Should it be defined as a protocol extension as well based on your restriction?  The protocol does not and should not dictate whether an object is physically stored in the database, is an immutable object that is stored in a queue or in a specific database table, or is cached or generated to provide information to the client.  A blob that is well formed and structured is an object in a programming language as well as in a protocol like EPP.  My recommendation is to create a single EPP extension form in draft-ietf-eppext-keyrelay, where an object extension makes the most sense.  The responses on the list seem to support this approach.

Use of a unique relay identifier is a straight forward mechanism for the consuming client to know that it has or has not processed the message before.  There is no need to rely on some heuristic on the timestamp or comparing a set of fields to address the concern that Scott raised.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Feb 5, 2015, at 12:07 PM, Antoin Verschuren <[email-masked]<mailto:[email-masked]>> wrote:

Op 5 feb. 2015, om 15:08 heeft Gould, James <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

- --
Antoin Verschuren