Hi Mario/Jim, Thank you for sharing your thoughts on this.
Let me remind that the reasoning for having such policy in the charter is to ensure that we are defining new mappings that are motivated by real operational needs. Process-wise, consensus to adopt a document does not mean that the document will be necessary progressed to an RFC. Consensus to publish will typically be assessed during WGLC. Also, a WG may decide to adopt a doc, but decide later that it is better to park a spec , etc. Now back to this specific document, the information you shared below is a great info to record in the document writeup to demonstrate how it adheres to the deployment policy in the charter. FYI, we received comments during the IESG review of the QUIC draft on that same point. We managed to address it as I already had the required arguments gathered as part of my AD review (thanks to the authors). Thank you. Cheers, Med De : Mario Loffredo <[email protected]> Envoyé : mercredi 9 septembre 2026 10:38 À : Gould, James <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; [email protected] Cc : [email protected] Objet : Re: [regext] Re: Request for clarification on the charter Hi, please find my comments below. Il 08/09/2026 16:35, Gould, James ha scritto: I'm replying to my own message to answer the question "Should the new language be retroactively applied to existing working group documents (draft-ietf-regext-epp-https)?". The answer to this question for draft-ietf-regext-epp-https should be "no", based on the following: 1. draft-ietf-regext-epp-https was adopted by REGEXT on 2/2025 based on an earlier charter (Charter 02). A question was raised on the mailing list whether the charter's scope supported the transport drafts (EoH in draft-ietf-regext-epp-https) and EoQ in draft-ietf-regext-epp-quic), which was determined to be in-scope and the transport drafts were adopted. 2. The charter was updated to clarify that EoH and EoQ are in scope in Charter 03, that was approved on 7/2026. 3. The new charter (Charter 04), approved on 9/2026, was described as "Minor reframing of Charter to better align with general pattern of OPS area Charters", where the language "New application transport mappings for EPP following relevant and appropriate IETF standards to address operational gaps for which at least one domain registry and at least one domain registrar have made a commitment to deploy (Standards Track or Experimental)" is a material change that adds a new obligation applicable to a multistakeholder governance model. 4. The "commitment to deploy" language is unique to the REGEXT charter and needs further review and discussion on the mailing list that is independent of the draft-ietf-regext-epp-https work. Thanks, [ML] I believe the phrase "New application transport mappings for EPP ..." applies more naturally when RegExt evaluates the adoption of additional EPP transport mappings. IMO, there is no indication that this specific revision of the charter was intended to reopen the previously reached consensus on EoH or to impose a new adoption criterion for an existing WG document. Furthermore, EPP over HTTPS is not merely a hypothetical deployment model. Registro .it has operated an HTTPS-based EPP server since 2009, and .it registrars have used this transport approach for many years. Some of the operational considerations outlined in the draft stem from the experience gained over this period. Although the existing .it implementation slightly differs from draft-ietf-regext-epp-https - notably, when the HTTP session is established - it provides substantial operational evidence that both the registry and its registrars have accepted EPP over HTTPS as a viable deployment model. Against that background, requiring a registrar to make a formal "commitment to deploy" merely because the charter language changed after adoption of the document would add little evidence of actual deployability. It would amount to imposing a recently introduced procedural formality on activities for which long-standing operational procedures and registrar acceptance already exist. Best, Mario -- Dott. Mario Loffredo Senior Technologist Technological Unit "Digital Innovation" Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
