Re: 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