Re: [regext] Comments to the feedback about epp-over-http

[Matthias Pfeifer <[e-mail]>]

Hello,

i would also add a comment and questions:

 >In the perspective of moving to the cloud to achieve scalability and
 >  cost reduction, it should be further noted that application protocols
 >   that aren't based on HTTP can be hardly migrated by using cloud-
 >   native features, both on client side and server side.  In addition,
 >   from the security point of view, registries would be limited in terms
 >   of the third-party security services available to protect their EPP
 >   servers.

Can you please elaborate on

 >"registries would be limited in terms of the third-party security 
services available to protect their EPP >servers."

Why?


And also on

 >"and should be further noted that application protocols
 >that aren't based on HTTP can be hardly migrated by using cloud-
 >native features, both on client side and server side. " (since the 
cloudproviders offer tcp LB as well)


 >While TCP is connection-oriented, HTTP is stateless but not session
 >less.  This means that, by making an EPP session untied from the
 >network connection, the EPP communication over HTTP is more flexible
 >and efficient than over TCP.

They work on different Layers so IMHO its hard to make a comparsion in 
that way.


 >While HTTP load balancers are very common and are quite often 
software, TCP load
 > balancers are usually implemented in dedicated hardware

Whats the point? TCP and HTTP LBs are even used in combination

 >An EPP server made up of a server pool must always operate with
 >respect to the constraint that, once an EPP session is established,
 >all the requests related to that session should be processed by the
 >servers in the pool as long as the session is alive.

This is true in general and there are workarounds (eg CARP or VRRP  and 
token)
The LB part looks too one-sided to me

And a comment:

 >The reasons why we have used session cookiea are that they represent a 
standard method >(RFC6265), >well known to the community of REST service 
implementers, largely used and natively >supported by >libraries and 
frameworks on both client and server side. For example, it is the same 
 >method used by >rdap-openid to map an RDAP session and tie it to an 
access token :-)

 > Which method other than session cookie shoud be used instead ?

For (REST) API I would prefer token(JWT) based model in general. Login / 
Logout including session management would add (at least a little bit) 
more complexity and probably CORS issues on client side.


Why we don't chase the transport protocol restriction out of EPP in 
general? :)


Thx and best, Matthias




On 28.03.22 12:56, Mario Loffredo wrote:
> The reasons why we have used session cookiea are that they represent a 
> standard method (RFC6265), well known to the community of REST service 
> implementers, largely used and natively supported by libraries and 
> frameworks on both client and server side. For example, it is the same 
> method used by rdap-openid to map an RDAP session and tie it to an 
> access token :-)