Andy, The DE evaluation criteria look high-level to me, but if the DEs are not appropriate for registration requests of proprietary transport extensions, then it may be best for EPP transport extensions to go through the IESG process. This would apply draft-ietf-regext-epp-https and draft-ietf-regext-epp-quic if they make it to RFCs.
-- 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 3/5/26, 2:28 PM, "Andy Newton" <[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. I think most of use assume that extending EPP XML through XML namespaces would not result in security issues. Even if one did, the blast radius would likely be limited. The same is not true for transports. EPP relies on the layers beneath it for the security properties necessary to make EPP usable. The security concerns for each are not the same. Furthermore, the guidance on the XML extensions is contained in an entire RFC, whereas the guidance for EPP transports is one page of high-level bullet points, one of which laughably mentions SMTP as a possible choice. The guidance for the DEs is not nearly the same. Plus, the EPP extension registry DEs are EPP experts, not security and transport experts. It is inappropriate for them to making judgements of this type. -andy, as an individual On 04-03-2026 4:43 PM, Gould, James wrote: > Andy, > > We need to consider the purpose of the EPP Extension Registry for any form of > EPP extension. I believe the purpose of the EPP Extension Registry is to > provide visibility for EPP extension specifications to help encourage > consolidation, which is the case of EoH. I don't see EPP transports any > differently from EPP XML extensions, since both can include security and > private issues, which are not factors for consideration of the DE in > draft-ietf-regext-ext-registry-epp. > > Please clarify your statement "security and transaction semantics wrong" with > EoH since I haven't seen any supporting feedback on the mailing list. > > Please clarify your statement " EPP-over-HTTP discussion has focused a lot on > the costs to the registries but nobody has mentioned the costs to the > registrars" since I haven't seen any discussion on the mailing list > associated with this. Your statement " New EPP transports should only be > encouraged when the costs to all parties are weighed" doesn't align with the > language in RFC 5730, where the intend was to support the extensibility of > EPP transports. We presented multiple times to the REGEXT WG of the perceived > value in adding the two new EPP transports for HTTPS and QUIC with > draft-ietf-regext-epp-https and draft-ietf-regext-epp-quic. > > We should allow for the registration of all forms of EPP extensions in the > EPP Extension Registry, where there are no additional hurdles defined in RFC > 5730 for EPP transports other than meeting the recommendations in Section 2.1 > of RFC 5730. > > Thanks, > _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
