Hi James, Thank you for the responses. Please see inline [GF] Regards,
Giuseppe -----Original Message----- From: Gould, James <[email protected]> Sent: Monday, June 22, 2026 7:25 PM To: Giuseppe Fioccola <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-regext-epp-quic-09 ietf last call Opsdir review Giuseppe, Thank you for the review and feedback. I provide responses to your feedback embedded below, prefixed with "JG-". -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/22/26, 9:29 AM, "Giuseppe Fioccola via Datatracker" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Document: draft-ietf-regext-epp-quic Title: Extensible Provisioning Protocol (EPP) Transport over QUIC Reviewer: Giuseppe Fioccola Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://secure-web.cisco.com/1ajx8uyfBKpI9oczVZq10tns7S_j30hRTC4nEj2AoVqeRUvE8Y0kdlGdcHrlkXDp1Wo3npKUyI6vLwfUGu8fTdepKnJ8pdVEHHIZ_V9OdC2xQWi-uZpaCpM-s4D5XA9fsHGUjgJbH7GaTpqlHC2napOC94R9gf2VEbvY3epmdeI-0cJ6YGsCpXXMHNZXwZ1y_fs2zwLhyxDqFxMGaNxF7f7qCmeHYTvOhivL_PI9OieSOF-l4wDG1hYZFwHPq87eeEceAWTGXAIZM2ki4kVbuuYZ728UM21V6JMlodonERrA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-rfc5706bis%2F <https://secure-web.cisco.com/1ajx8uyfBKpI9oczVZq10tns7S_j30hRTC4nEj2AoVqeRUvE8Y0kdlGdcHrlkXDp1Wo3npKUyI6vLwfUGu8fTdepKnJ8pdVEHHIZ_V9OdC2xQWi-uZpaCpM-s4D5XA9fsHGUjgJbH7GaTpqlHC2napOC94R9gf2VEbvY3epmdeI-0cJ6YGsCpXXMHNZXwZ1y_fs2zwLhyxDqFxMGaNxF7f7qCmeHYTvOhivL_PI9OieSOF-l4wDG1hYZFwHPq87eeEceAWTGXAIZM2ki4kVbuuYZ728UM21V6JMlodonERrA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-rfc5706bis%2F> While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-regext-epp-quic-09 - Reviewer: Giuseppe Fioccola - Review Date: 2026-06-22 - Intended Status: Standards Track --- ## Summary - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis > This document specifies how the Extensible Provisioning Protocol (EPP) > is mapped onto QUIC. > I would have expected a section or at least some text to explain the > use cases where EPP over QUIC can be deployed. > In this regards, for example, it can be interesting to understand how > EPP over QUIC can be used as alternative or replacement of the other possible connections (e.g. TCP, HTTP,...). JG-EPP over QUIC (EoQ) follows the template used for the first and currently only transport for EPP with EPP over TCP (EoT) in RFC 5734, where all the considerations in section 2.1 "Transport Mapping Considerations" of the EPP RFC 5730 must be met. With that context in mind, EoQ is pluggable with EoT and EPP over HTTPS (EoH) defined in draft-ietf-regext-epp-https. The choice of transport(s) is based on deployment architecture considerations, such as use of the public cloud, security, and performance. We can add some text to the end of the Introduction to describe the motivation of adding a choice to the EPP transports, such as: NEW: EPP [RFC5730] was designed for pluggability of transports that must follow section 2.1 of [RFC5730]. EoQ defines a fully pluggable QUIC transport for EPP as an alternative to other EPP transports, such as EPP over TCP (EoT) defined in [RFC5734]. The server can choose to offer EoQ in addition to EoT or as a replacement for EoT, based on the security and performance considerations of QUIC and the preferred deployment architecture of the server and clients. [GF]: Ok, the proposed text can help to clarify. > Section 10 on the Operational Considerations should be reviewed. > Currently, it includes several subsections, but it would be better to have some general considerations at the beginning to introduce the following subsections. > I would move section 10.7 on the Authentication Considerations under > the Security Considerations section since it is more related to security. JG-We got similar feedback from the Secdir that Operational Considerations 10.7 and 10.8 are also Security Considerations, so should probably be copied / referenced from 11. Security Considerations. We can move both 10.7 and 10.8 under the Security Considerations to address the feedback from Secdir and Opsdir. [GF]: Yes, it makes sense to move those sections. ## Major Issues > From an OPSDIR point of view, it is good to have the Operational Considerations section. However, I suggest to revise that section to improve its readability, as mentioned above. In addition, it would be useful to mention the possible use cases. JG-We will look at the Operational Considerations section for improvements. The use cases for EoQ are generic, since EoQ is fully pluggable with EoT and it becomes a choice based on security, performance, and deployment architecture considerations as described above. [GF]: Thanks! In particular, you can add some general considerations before the different subsections. --- ## Minor Issues > In section 5, it is not clear the reason why the total length of the > EPP data unit is a 32-bit field. I suggest to add an explanation about this design choice. JG-The choice of a 32-bit field is to match the packet framing defined for EoT to support transport pluggability. We can make a note of the basis for the length to match EoT in [RFC5734]. [GF]: I see, a note to explain it would be useful. --- ## Nits > In section 3, the different steps of the message exchange are already mentioned. I suggest to add a reference to Figure 1 of section 4 to make it easier for the reader to understand. JG-Thanks, we can add a reference to Figure 1 from Section 3. [GF]: Ok > The Operational Considerations section could be moved before the IANA Considerations section. JG-We can move the Operations Considerations section to be just before the IANA Considerations section. [GF]: Ok --- _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
