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 :-)
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
