Gorry Fairhurst has entered the following ballot position for draft-ietf-regext-epp-quic-10: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please find below a blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the point below, which I expect will be very easy to resolve: The current text says: "Operators are encouraged to provision network paths with appropriate MTU sizes to avoid packet fragmentation for EPP message delivery." - I don't really understand what this is asking for and what is needed, please clarify. - When I started reading I assumed this was the standard QUIC datagram size (as in section 14), but maybe this means to say more, or I was just thrown by the term "MTU" here? - And please explain what is the fragmentation described here? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for submitting this document, I have the following comments: (1) 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. (2) 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. Best wishes, Gorry _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
