Gorry Fairhurst has entered the following ballot position for draft-ietf-regext-epp-quic-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for submitting this document, I have the following (non-blocking) comments: ## I couldn't really understand why this RFC is specifying transport over QUIC, but expect there was some specific need. I think that ought to be clearer. GF: DONE in rev -12 ## The security properties of QUIC do differ to those of TLS/TCP, in as much as QUIC us an encrypted transport - see 21.1 in the security considerations of RFC9000. GF: DONE in rev -12 # Please address the issues raised by Zahed as a part of his TSVART review: ## Even though section 3 explains it the correct way, in section 6, it says - The EoQ Connection Start Packet is written by the client after creating a QUIC stream to signal to the server to create the QUIC stream. This is inaccurate when client-initiated bi-directional streams are used. The server does not create streams; it just uses the streams created by the client. The snipped emphasizes that "signal to the server to create stream " that needs to be fixed. If there are no specific explanations, then it would suggest to rewrite the sentence to -- The EoQ Connection Start Packet is sent by the client after creating a QUIC connection to signal to the server, on the client-initiated stream, respond with EPP<greeting>. GF: DONE in rev -12 # Nits - - Section 7 : the references to RFC9000 are out of order in the description of "Stateful Nature". RFC 9000 section 2 is about streams and section 5 is about connections. GF: DONE in rev -12 I thank you for addressing my discussion topics in rev -12. Best wishes, Gorry _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
