headers
Aaron Roberts | 29 Feb 2012 16:24

clTRID element clarification

Hi all,
	I'm looking to gauge domain registries' interpretation and use of the clTRID EPP command element in their
EPP server implementations.

It seems that some registry EPP servers (namely .za and .im) use a kind of "cache/lookup" mechanism, based
on the clTRID and (hopefully) scoped to individual registrars.  Where a command is received from a
registrar with a clTRID which has been previously used by the same registrar, the cached server response
is returned to the client, instead of the command being executed a second time.  The intention is to provide
idempotency at the server level, when commands are issued multiple times.

My interpretation of the RFCs is that the clTRID is just a handy identifier for debugging etc.. managed by
the client end and that EPP commands are designed to be idempotent by nature so can be safely executed
multiple times without any considerations given to previous executions.

I'd be very interested to know what everybody is doing in this regard?

Regards,
	Aaron

Domicilium (IOM) Limited | The Isle of Man Datacentre 
Ronaldsway Industrial Estate | Ballasalla | Isle of Man |IM9 2RS
Tel +44 (0) 1624 825278

www.domicilium.com 
www.ipv6.domicilium.com 
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended
recipient. If you have received it in error, please contact the sender immediately by return e-mail.
Please then delete the e-mail and do not disclose its contents to any person.

_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 1 Mar 2012 12:57
Picon
Favicon

Re: clTRID element clarification

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Aaron Roberts
> Sent: Wednesday, February 29, 2012 10:24 AM
> To: provreg <at> ietf.org
> Subject: [provreg] clTRID element clarification
> 
> Hi all,
> 	I'm looking to gauge domain registries' interpretation and use of
> the clTRID EPP command element in their EPP server implementations.
> 
> It seems that some registry EPP servers (namely .za and .im) use a kind
> of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped
> to individual registrars.  Where a command is received from a registrar
> with a clTRID which has been previously used by the same registrar, the
> cached server response is returned to the client, instead of the
> command being executed a second time.  The intention is to provide
> idempotency at the server level, when commands are issued multiple
> times.
> 
> My interpretation of the RFCs is that the clTRID is just a handy
> identifier for debugging etc.. managed by the client end and that EPP
> commands are designed to be idempotent by nature so can be safely
> executed multiple times without any considerations given to previous
> executions.

Your interpretation is correct. Servers should not make *any* assumptions about clTRIDs.

Scott
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Theo Kramer | 2 Mar 2012 09:06
Picon
Favicon

Re: clTRID element clarification


On 01 Mar 2012, at 1:57 PM, Hollenbeck, Scott wrote:

>> -----Original Message-----
>> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
>> Behalf Of Aaron Roberts
>> Sent: Wednesday, February 29, 2012 10:24 AM
>> To: provreg <at> ietf.org
>> Subject: [provreg] clTRID element clarification
>> 
>> Hi all,
>> 	I'm looking to gauge domain registries' interpretation and use of
>> the clTRID EPP command element in their EPP server implementations.
>> 
>> It seems that some registry EPP servers (namely .za and .im) use a kind
>> of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped
>> to individual registrars.  Where a command is received from a registrar
>> with a clTRID which has been previously used by the same registrar, the
>> cached server response is returned to the client, instead of the
>> command being executed a second time.  The intention is to provide
>> idempotency at the server level, when commands are issued multiple
>> times.
>> 
>> My interpretation of the RFCs is that the clTRID is just a handy
>> identifier for debugging etc.. managed by the client end and that EPP
>> commands are designed to be idempotent by nature so can be safely
>> executed multiple times without any considerations given to previous
>> executions.
> 
> Your interpretation is correct. Servers should not make *any* assumptions about clTRIDs.
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 2 Mar 2012 13:21
Picon
Favicon

Re: clTRID element clarification

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Theo Kramer
> Sent: Friday, March 02, 2012 3:07 AM
> To: provreg <at> ietf.org
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> On 01 Mar 2012, at 1:57 PM, Hollenbeck, Scott wrote:
> 
> >> -----Original Message-----
> >> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> >> Behalf Of Aaron Roberts
> >> Sent: Wednesday, February 29, 2012 10:24 AM
> >> To: provreg <at> ietf.org
> >> Subject: [provreg] clTRID element clarification
> >>
> >> Hi all,
> >> 	I'm looking to gauge domain registries' interpretation and use of
> >> the clTRID EPP command element in their EPP server implementations.
> >>
> >> It seems that some registry EPP servers (namely .za and .im) use a
> kind
> >> of "cache/lookup" mechanism, based on the clTRID and (hopefully)
> scoped
> >> to individual registrars.  Where a command is received from a
> registrar
> >> with a clTRID which has been previously used by the same registrar,
> the
> >> cached server response is returned to the client, instead of the
(Continue reading)

Permalink | Reply |
headers
Francisco Obispo | 2 Mar 2012 13:40

Re: clTRID element clarification

+1

The clTRID is to be used by the client to identify the transaction against the server.. this is very useful if
the EPP protocol is used on asynchronous protocols such as SMTP, or if pipelining is used.

On Mar 2, 2012, at 7:21 AM, Hollenbeck, Scott wrote:

> The server shouldn't be generating what's supposed to be a client-provided transaction identifier.
> 
> Scott

Francisco Obispo 
email: fobispo <at> isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE


_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Gould, James | 2 Mar 2012 13:52
Picon
Favicon

Re: clTRID element clarification

++1

For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the
client and is mirrored back in the response.  I agree that it's a
necessary feature for pipelining as an Asynchronous Completion Token
(ACT).    

--

JG

 
James Gould
Principal Software Engineer
jgould <at> verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/2/12 7:40 AM, "Francisco Obispo" <fobispo <at> isc.org> wrote:

>+1
>
>The clTRID is to be used by the client to identify the transaction
>against the server.. this is very useful if the EPP protocol is used on
>asynchronous protocols such as SMTP, or if pipelining is used.
>
>
(Continue reading)

Permalink | Reply |
headers
Theo Kramer | 2 Mar 2012 14:42
Picon
Favicon

Re: clTRID element clarification


On 02 Mar 2012, at 2:52 PM, Gould, James wrote:

> ++1
> 
> For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the
> client and is mirrored back in the response.

Yes - as for co.za when supplied by the client.

>  I agree that it's a
> necessary feature for pipelining as an Asynchronous Completion Token
> (ACT).    

A null clTRID can not be used as an ACT.

and, for a next release

the server will not include a server generated clTRID in a response.
--

-- 
Regards
Theo

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Patrik Fältström | 2 Mar 2012 14:46
Picon
Gravatar

Re: clTRID element clarification


On 2 mar 2012, at 14:42, Theo Kramer wrote:

> On 02 Mar 2012, at 2:52 PM, Gould, James wrote:
> 
>> ++1
>> 
>> For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the
>> client and is mirrored back in the response.
> 
> Yes - as for co.za when supplied by the client.

That is how I think it should be used. I.e. clTRID is something that could be of benefit for the client. Not
policed by the registry. Specifically if we start getting more and more async operations (or rather,
overloading of commands) from the client.

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Ulrich Wisser | 1 Mar 2012 23:11
Picon

Re: clTRID element clarification

Hi Aaron,

at .SE the clTRID is ignored as long as it fits the standard definition 
(3-63 characters). It is returned to the client in the answer, but 
that's it.

We actually do have registrars not sending clTRID at all, sending the 
same clTRID with every command, sending the clTRID from our example code 
with every command, setting clTRID to a hash of the command, ...

Regards from Stockholm

Ulrich

> Hi all,
> 	I'm looking to gauge domain registries' interpretation and use of the clTRID EPP command element in
their EPP server implementations.
>
> It seems that some registry EPP servers (namely .za and .im) use a kind of "cache/lookup" mechanism, based
on the clTRID and (hopefully) scoped to individual registrars.  Where a command is received from a
registrar with a clTRID which has been previously used by the same registrar, the cached server response
is returned to the client, instead of the command being executed a second time.  The intention is to provide
idempotency at the server level, when commands are issued multiple times.
>
> My interpretation of the RFCs is that the clTRID is just a handy identifier for debugging etc.. managed by
the client end and that EPP commands are designed to be idempotent by nature so can be safely executed
multiple times without any considerations given to previous executions.
>
> I'd be very interested to know what everybody is doing in this regard?
>
(Continue reading)

Permalink | Reply |
headers
Christopher Browne | 2 Mar 2012 00:43

Re: clTRID element clarification

On Thu, Mar 1, 2012 at 5:11 PM, Ulrich Wisser <ulrich <at> wisser.se> wrote:
> We actually do have registrars not sending clTRID at all, sending the same
> clTRID with every command, sending the clTRID from our example code with
> every command, setting clTRID to a hash of the command, ...

I periodically bring up the idea that we ought to consider putting a
unique constraint on clTRID on a per-registrar basis; in principle,
that ought to be someone a registry could consider imposing as a
policy.

Nobody gets terribly enthused about that idea.  They expect, and I
think they're right, that this would irritate registrars that are
using particularly lazily-constructed client trids.

Furthermore, it does not seem likely that there would be huge value to
be gained from doing a lot of work interpreting clTRID values.

It's an interesting idea to put an object cache that uses client trid
as the basis for identifying that two requests ought to be interpreted
the same way.  But that seems likely to be counterproductive, looking
at a couple of cases:

1.  To repeat a write operation seems likely to cause trouble.
Re-requesting a domain renew shouldn't be able to work, for instance,
as two separate renew requests will need to be different as they need
to include different expiry dates.

2.  Caching read operations means that registrars are getting
increasingly stale data, and if they were doing a domain check to see
if a domain has become available, there's a risk that they are getting
(Continue reading)

Permalink | Reply |
headers
Aaron Roberts | 7 Mar 2012 16:42

Re: clTRID element clarification


> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On 
> Behalf Of Aaron Roberts
> Sent: 29 February 2012 15:24
> To: provreg <at> ietf.org
> Subject: [provreg] clTRID element clarification
> 
> Hi all,
> 	I'm looking to gauge domain registries' interpretation and use of the 
> clTRID EPP command element in their EPP server implementations.
> 
> It seems that some registry EPP servers (namely .za and .im) use a 
> kind of "cache/lookup" mechanism, based on the clTRID and (hopefully) 
> scoped to individual registrars.  Where a command is received from a 
> registrar with a clTRID which has been previously used by the same 
> registrar, the cached server response is returned to the client, 
> instead of the command being executed a second time.  The intention is 
> to provide idempotency at the server level, when commands are issued multiple times.
> 
> My interpretation of the RFCs is that the clTRID is just a handy 
> identifier for debugging etc.. managed by the client end and that EPP 
> commands are designed to be idempotent by nature so can be safely 
> executed multiple times without any considerations given to previous executions.
> 
> I'd be very interested to know what everybody is doing in this regard?
> 

Thanks to everyone for your responses.
The consensus from the responses that I received are that an EPP server should not be doing anything with the
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 7 Mar 2012 18:08
Picon
Favicon

Re: clTRID element clarification

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Aaron Roberts
> Sent: Wednesday, March 07, 2012 10:42 AM
> To: provreg <at> ietfa.amsl.com
> Subject: Re: [provreg] clTRID element clarification
> 
> The consensus from the responses that I received are that an EPP server
> should not be doing anything with the clTRID, (except returning it to
> the client in responses, as RFC5730 section 2.6 states).  Does anybody
> feel that section 2.5 of RFC5730 ("command format") should include some
> extra text to explicitly prohibit servers from making assumptions about
> the clTRID element (or something similar)?

Given that RFC 5730 is part of Standard 69 there's not much chance of a near-term amendment, but our process
allows us to collect errata. I'm not convinced that there's anything here to correct, though. Section 2.5
currently says this:

"MAY be used to uniquely identify the command *to the client*"

(emphasis mine), and

"Clients are responsible for maintaining their own transaction identifier space to ensure uniqueness."

This doesn't seem ambiguous to me.

Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
(Continue reading)

Permalink | Reply |
headers
Luis Muñoz | 7 Mar 2012 18:11

Re: clTRID element clarification


On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote:

> "MAY be used to uniquely identify the command *to the client*"
> 
> (emphasis mine), and
> 
> "Clients are responsible for maintaining their own transaction identifier space to ensure uniqueness."
> 
> This doesn't seem ambiguous to me.

That language does not directly contradicts a server using it to provide a cached response to a command with
the same (command, clTRID, arguments...) n-tuple, right?

-lem
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Aaron Roberts | 7 Mar 2012 18:32

Re: clTRID element clarification


> -----Original Message-----
> From: Luis Muñoz [mailto:lem <at> isc.org]
> Sent: 07 March 2012 17:11
> To: Hollenbeck, Scott
> Cc: Aaron Roberts; provreg <at> ietfa.amsl.com
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote:
> 
> > "MAY be used to uniquely identify the command *to the client*"
> >
> > (emphasis mine), and
> >
> > "Clients are responsible for maintaining their own transaction identifier space
> to ensure uniqueness."
> >
> > This doesn't seem ambiguous to me.
> 
> That language does not directly contradicts a server using it to provide a
> cached response to a command with the same (command, clTRID,
> arguments...) n-tuple, right?
> 

It is pretty clear that the cached response server behaviour is miles outside the definition of the clTRID. 
However, all the stuff which should not be done with the clTRID, at the server end, is only covered by the
implication of the statement that the clTRID "MAY be used to uniquely identify the command to the client". 
One of the other registries, in their responses, said that they had seriously considered this sort of
server behaviour, at points in their development.  If registries are making the decision to implement
(Continue reading)

Permalink | Reply |
headers
Hollenbeck, Scott | 7 Mar 2012 19:07
Picon
Favicon

Re: clTRID element clarification

> -----Original Message-----
> From: Luis Muñoz [mailto:lem <at> isc.org]
> Sent: Wednesday, March 07, 2012 12:11 PM
> To: Hollenbeck, Scott
> Cc: Aaron Roberts; provreg <at> ietfa.amsl.com
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> On Mar 7, 2012, at 12:08 PM, Hollenbeck, Scott wrote:
> 
> > "MAY be used to uniquely identify the command *to the client*"
> >
> > (emphasis mine), and
> >
> > "Clients are responsible for maintaining their own transaction
> identifier space to ensure uniqueness."
> >
> > This doesn't seem ambiguous to me.
> 
> That language does not directly contradicts a server using it to
> provide a cached response to a command with the same (command, clTRID,
> arguments...) n-tuple, right?

No, it doesn't. It also doesn't include restrictions for any number of other behaviors. It describes who
owns the item and what may do with it. One shouldn't assume that something is allowable unless it's
expressly prohibited.

Scott
_______________________________________________
provreg mailing list
(Continue reading)

Permalink | Reply |
headers
Theo Kramer | 9 Mar 2012 05:32
Picon
Favicon

Re: clTRID element clarification


On 07 Mar 2012, at 11:08 AM, Hollenbeck, Scott wrote:
> 
> Given that RFC 5730 is part of Standard 69 there's not much chance of a near-term amendment, but our process
allows us to collect errata. I'm not convinced that there's anything here to correct, though. Section 2.5
currently says this:
> 
> "MAY be used to uniquely identify the command *to the client*"
> 

Is that not perhaps something that slipped through the cracks? Ie. should it not read

"MAY be used to uniquely identify the command from the client" ?

--

-- 
Regards
Theo

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Hollenbeck, Scott | 9 Mar 2012 13:04
Picon
Favicon

Re: clTRID element clarification

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Theo Kramer
> Sent: Thursday, March 08, 2012 11:33 PM
> To: provreg <at> ietfa.amsl.com
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> On 07 Mar 2012, at 11:08 AM, Hollenbeck, Scott wrote:
> >
> > Given that RFC 5730 is part of Standard 69 there's not much chance of
> a near-term amendment, but our process allows us to collect errata. I'm
> not convinced that there's anything here to correct, though. Section
> 2.5 currently says this:
> >
> > "MAY be used to uniquely identify the command *to the client*"
> >
> 
> Is that not perhaps something that slipped through the cracks? Ie.
> should it not read
> 
> "MAY be used to uniquely identify the command from the client" ?

No, the intention is for the clTRID to have meaning only in the client's context. That's not a typo about
sending commands to clients.

Scott
_______________________________________________
provreg mailing list
provreg <at> ietf.org
(Continue reading)

Permalink | Reply |

Gmane