Re: draft-wullink-restful-epp-00.txt

I can see this argument  with a high velocity, high volume system, however
load-balancing via TCP sessions is a trivial issue with a domain or number
registry and individual traffic flows are commonly handled through packet
shapers these days.  Add in some policy driven rate-limiting and you are
more than covered.

Now don't assume I am negative on innovating, quite the opposite, I'd love
to see us being progressive however I am not sure I see any distinct benefit
to moving to a stateless EPP.  

It would help if you could build a list of pros and cons for stateless EPP
and also describe the trust model you would use for the source traffic - so
we can understand how the current solution stacks up against what you are
proposing.



Best Regards,

Michael Young

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Maarten Wullink
Sent: April-23-12 10:03 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

Stateless EPP makes it possible to load balance individual EPP requests
instead of EPP connections. This should make it easier to distribute to load
evenly across the servers.
Distributing tcp connections across EPP servers does not guarantee an equal
load on every server. This is because not all EPP connections are equal.

Also when there is no persistent tcp connection it should be easier to
remove a server from the server pool for maintenance without having to
disconnect the tcp connections of the clients connected to the server.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Gould, James
Sent: maandag 23 april 2012 14:43
To: Miek Gieben; [email protected]
Cc: [email protected]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

This is the first time that I've heard of challenges in load-balanced
environments or EPP session state not being linked to an active TCP session.
Can you go into more detail of these issues?  I've been involved with many
EPP-based systems through the years and I've never come across any of these
issues.  This goes to the heart of the reliability of stateful TCP sessions,
which is used with many other protocols.  It would be good to discuss the
problems posed prior to consideration of a new stateless version of EPP on
top of REST.

--
  
JG
 

 
James Gould
Principal Software Engineer
[email protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 4/23/12 6:51 AM, "Miek Gieben" <[email protected]> wrote:

>Hello,
>
>[I've cross posted this also to [email protected]]
>
>SIDN, being the registry for .nl, employs EPP as the primary interface 
>for registrars to submit or manipulate domain names. Even though the 
>protocol is working quite well, at SIDN Labs we believed there was room 
>for improvement.
>
>Experience over the years revealed certain operational shortcomings in 
>EPP, mainly related to the stateful nature of the protocol:
>
>* EPP may pose challenges in load-balanced environments, when a active 
>session
>  has to be switched from one EPP server to another and state is kept 
>on a per
>  server basis.
>
>* EPP sessions can wind up in a state where they are no longer linked 
>to an
>  active TCP connection. This may raise problems in situations where 
>session
>  limits are enforced.
>
>Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt
>aims to solve these issues, by proposing a RESTful EPP interface.
>
>The Abstract reads:
>
>       This document specifies a 'RESTful interface for EPP' (REPP) with
>the    
>       aim to improve efficiency and interoperability of EPP systems.
>      
>
>       This document includes a new EPP Protocol Extension as well as a 
>mapping
>       of [RFC5730] XML-commands to an HTTP based (RESTful) interface.
>Existing 
>       semantics and mappings as defined in [RFC5731], [RFC5732] and 
>[RFC5733]
>       are largely retained and reusable in RESTful EPP.
>      
>
>       With REPP, no session is created on the EPP server. Each request
>from    
>       client to server will contain all of the information necessary 
>to
>      
>       understand the request. The server will close the connection 
>after each
>       HTTP request.
>      
>
>As the provreg WG is dormant, we have submitted our draft as an 
>individual submission.
>
>Since the provreg mailinglist is still very much alive, we are kindly 
>requesting its subscribers to provide us with feedback on our proposal.
>
>Kind regards,
>
>--
>
> Miek Gieben
> SIDN Labs
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg