Hi Jim, My overall comment is that I am still concerned about the different lifecycle used for HTTP session and for EPP session. this may introduce more states than currently exist in the RFC5730 state diagram. I would like to see the diagram in the draft to also include the different new states, so its clear when what type of session is created and destroyed.
Also, I think the draft could benefit from using more of the Terminology defined in RFC9119 JG2-Use of HTTP sessions makes for a stateful HTTP connection to a server, which is really not an overlap with the EPP session layer, but a building block for defining a statement EPP connection on HTTP. MW2- This reminds me of another issue i was thinking about: The draft talks about mapping HTTP session to a EPP connection, it would be better when you map HTTP session to EPP session. Statement such as "The HTTP session represents an EPP connection" are not correct. JG2-The EPP session is dependent on the stateful connection, so if the stateful HTTP connection fails so does the EPP session. This is the same case as for a TCP connection. Is your concern related to the speed by which the client will recognize that the EPP session has been terminated, which can take more time than a TCP connection, but the client will be able to identify that the HTTP session is no longer active. Do you see any gaps in draft-ietf-regext-epp-https to help clarify this? MW2: There is no such thing as a stateful HTPP conenction, HTTP is connectionless and state is managed using a HTTP session. There could be multiple TCP connections used to perform HTTP requests, these request will use the same session. How does the client detect the HTTP server is not linked to a active EPP session? maybe i missed this in the draft but I cannot find text about this. JG2-This is existing behavior for servers that do implement an idle timeout. The requirement for an idle timeout is independent of the underlying transport, where the server can automatically terminate the EoT connection or EoH connection if there has been no commands received within the idle timeout. MW2: By relying on timeout for destroying unused sessions, and always creating a HTTP session for the first GET then you run the risk that an attacker might create lots of sessions and try resource exhaustion attack? Maybe this can also be added to the securities considerations? JG2-Please review draft-ietf-regext-epp-https and provide feedback on normative language that can help address your concern. We cannot help implementers from going beyond what's defined in the RFC, but we can include normative language to help define the guardrails. MW2: Not sure if you can overcome this with any language, the fast is that when developers have the option to use limited HTTP functionality for EPP, then they will also would like to start using other HTTP function and capabilitties. This may then lead to more work for the wg in the form of new drafts, i'm not saying this is a bad thing, but we should take this into consideration. HTTP offers much more extension options then plain TCP does. so there is a big difference in this regard between TCP and HTTP.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
