To follow-up on this clarification, I would like to post to the mailing list
that I oppose this language in the new charter:
“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).”
Unfortunately, I could not review the charter ahead of it being finalized. The
additional point was added in the 02-02 draft (2026-06-08), less than a month
before the charter was approved (2026-07-02). Checking the regext mailing list,
I am unable to find any discussion history of this point during the recharter
process (though the charter change was suggested in February 2025 in response
to the EPP-over-QUIC and EPP-over-HTTP drafts). It is unclear why this issue
rises to the level of the charter when only three transport drafts have
progressed in EPP’s over twenty-year history.
When the charter is updated in the future, I'm requesting that the language
associated with getting commitment to deploy by a subset of stakeholders be
removed. The IETF uses a consensus model based on participants of the mailing
list, and not a multi-stakeholder model. It should not require commitments from
particular types of stakeholders. More importantly for this change of the
charter, EPP is a general-purpose provisioning protocol that can be used
outside the domain name ecosystem. For example, if an EPP transport extension
were proposed for the AI industry, there would be no application of the 3 R's
(Registrant, Registrar, and Registry) model of the Domain Name Registry (DNR)
industry.
I have additional questions for complying with this new language:
1. Why does this only apply to EPP transports, where EPP
transports is a defined form of extensibility in RFC 5730? If there is concern
over the transports, the language could have been associated with requiring
review by the associated directorate, if one exists.
2. The language is poorly defined, as Mario’s question makes
evident. What form does “a commitment” take, since a commitment can come with
legal connotations?
3. Do these commitments need to be satisfied ahead of
consideration of an EPP transport for working group adoption? This seems
premature when it can take years for the transport to get standardized.
4. What happens if the commitment cannot be met based on the
progression or non-progression of the standard?
5. Should the new language be retroactively applied to existing
working group documents (draft-ietf-regext-epp-https)?
My recommendation for meeting the existing language for
draft-ietf-regext-epp-https is to post the commitment for the record on the
mailing list. Embedding a commitment into the draft itself may bring in the
legal connotation issue.
Thanks,
--
JG
James Gould
Fellow Engineer
[email protected] <mailto:[email protected]>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]
<mailto:[email protected]>>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/> <http://verisigninc.com/>>
On 7/22/26, 2:55 AM, "Mario Loffredo"
<[email protected]
<mailto:[email protected]> <mailto:[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.
Hi AD and Chairs,
given the charter, how should a domain registrar commit to implementing
a new application transport mapping? Is it sufficient to post a message
on the mailing list, or does this commitment need to be included in the
"Implementation Status" section of the transport mapping, or what else?
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://secure-web.cisco.com/19rAhDTb_QwpWMHJhzruH5UwVcSLBdkQhMT3M62LjQjExP9c6I5nuD7qmAhgKxGG-ivIOr0fOYj5t-KJkZRuxbnLm_vm80WnrF0eWYgcUT3tkGMfA_sfGKqCEMLLp6ZNm2sLKLVbI8MtBuaNrFC0ZuobNFq1QCT0LNwNgkvoIPiS2n5IAC6fsZb8bIIlRJMU1FXMM973r61VKJ3_KI_NFJ9Xcw64AboN7p_nojUOdcrSkCoKvaAfnYcoLFiMIF5ONRxpBK7pPFJGvGRSCqD7O5zew3ZrsNhy0zAQnfaBU48c/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
<http://secure-web.cisco.com/19rAhDTb_QwpWMHJhzruH5UwVcSLBdkQhMT3M62LjQjExP9c6I5nuD7qmAhgKxGG-ivIOr0fOYj5t-KJkZRuxbnLm_vm80WnrF0eWYgcUT3tkGMfA_sfGKqCEMLLp6ZNm2sLKLVbI8MtBuaNrFC0ZuobNFq1QCT0LNwNgkvoIPiS2n5IAC6fsZb8bIIlRJMU1FXMM973r61VKJ3_KI_NFJ9Xcw64AboN7p_nojUOdcrSkCoKvaAfnYcoLFiMIF5ONRxpBK7pPFJGvGRSCqD7O5zew3ZrsNhy0zAQnfaBU48c/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
<http://secure-web.cisco.com/19rAhDTb_QwpWMHJhzruH5UwVcSLBdkQhMT3M62LjQjExP9c6I5nuD7qmAhgKxGG-ivIOr0fOYj5t-KJkZRuxbnLm_vm80WnrF0eWYgcUT3tkGMfA_sfGKqCEMLLp6ZNm2sLKLVbI8MtBuaNrFC0ZuobNFq1QCT0LNwNgkvoIPiS2n5IAC6fsZb8bIIlRJMU1FXMM973r61VKJ3_KI_NFJ9Xcw64AboN7p_nojUOdcrSkCoKvaAfnYcoLFiMIF5ONRxpBK7pPFJGvGRSCqD7O5zew3ZrsNhy0zAQnfaBU48c/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
<http://secure-web.cisco.com/19rAhDTb_QwpWMHJhzruH5UwVcSLBdkQhMT3M62LjQjExP9c6I5nuD7qmAhgKxGG-ivIOr0fOYj5t-KJkZRuxbnLm_vm80WnrF0eWYgcUT3tkGMfA_sfGKqCEMLLp6ZNm2sLKLVbI8MtBuaNrFC0ZuobNFq1QCT0LNwNgkvoIPiS2n5IAC6fsZb8bIIlRJMU1FXMM973r61VKJ3_KI_NFJ9Xcw64AboN7p_nojUOdcrSkCoKvaAfnYcoLFiMIF5ONRxpBK7pPFJGvGRSCqD7O5zew3ZrsNhy0zAQnfaBU48c/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>>
_______________________________________________
regext mailing list -- [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
To unsubscribe send an email to [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
