Hi,
I agree with James that new EPP transports should be registrable EPP
extensions, like the EPP XML extensions.
Mario
Il 02/03/2026 15:42, Gould, James ha scritto:
Andy,
I agree that EPP transports are not defined in RFC 3735, which is
associated with EPP XML extensions, but EPP transport extension is a
valid form of EPP extensible as defined in RFC 5730 and there are
registrations included in draft-ietf-regext-epp-https and
draft-ietf-regext-epp-quic. I believe its best that we explicitly
support the inclusion of EPP transport extensions to go along with the
EPP XML extension guidelines in RFC 3735. The goal of the EPP
Extension Registry is to ensure that extension specifications are
published to reduce duplicate extensions, which applies to EPP
transports. In reviewing the references to RFC 3735 in
draft-ietf-regext-ext-registry-epp, the following is language that can
be updated to provide support for EPP transports explicitly:
1. In Section 1 “Introduction”, modify "Guidelines for extending EPP
are documented in RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>]." to "Guidelines for
extending EPP transports are documented in Section 2.1 of RFC 5730
[RFC5730 <https://www.rfc-editor.org/info/rfc5730>] and for
extending EPP XML are documented in RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>]."
2. Section 2.1 “Extension Specification, modify "Note that Section
2.1 of RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>] provides specific
guidelines for documenting EPP extensions." to "Note that Section
2.1 of RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>] provides specific
guidelines for documenting EPP XML extensions."
3. Section 2.1.1 “Designated Expert Evaluation Criteria”, modify
"Note that Section 2.1 of RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>] provides specific
guidelines for documenting EPP extensions." to "Note that Section
2.1 of RFC 3735 [RFC3735
<https://www.rfc-editor.org/info/rfc3735>] provides specific
guidelines for documenting EPP XML extensions."
4. Section 4 “Security Considerations”, modify “However, extensions
should be evaluated according to the Security Considerations of
RFC 5730 [RFC5730 <https://www.rfc-editor.org/info/rfc5730>] and
RFC 3735 [RFC3735 <https://www.rfc-editor.org/info/rfc3735>]."
Thanks,
--
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 2/26/26, 11:32 AM, "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.
On 2/26/26 9:38 AM, Hollenbeck, Scott wrote:
> *From:*Gould, James <[email protected]
<mailto:[email protected]>>
> *Sent:* Wednesday, February 25, 2026 4:19 PM
> *To:* [email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
> *Subject:* [EXTERNAL] [regext] Re: WG Last Call:
draft-ietf-regext-ext-registry-epp-03 (Ends 2026-03-09)
>
>
>
> *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,
>
> In reviewing draft-ietf-regext-ext-registry-epp-03
<https://secure-web.cisco.com/1bgYj_zFv2XYognfRiZ8vTIxnZxNA-yN-bnB8wxbr_4p_XSMhUwfCGyRAgtn0ey2qhCLBz5mP7CLWLtUyWLEgDwR1DRx_fv2FT8aN3nBUWOHUICYkhMkkpx3So0dcQYcfleJodmje7zI0-lE1AFDmiVESUS7MEweRCxKQq_oNGMFBNOUQgM6JBQ_u4IYO3su_JqakdeH_UpaO7vAk5v4tnM-WW8_-MJPDn87zYYQvANW3hVnVm8p7z84BEj-_NacyRu7Un8hYxK_Pm3-W1ftC3QKNk4eGfBuCzdXgsiCtWAjlDGr3w4vvImLOfoqvjiUi/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-ext-registry-epp-03>
<https://secure-web.cisco.com/1bgYj_zFv2XYognfRiZ8vTIxnZxNA-yN-bnB8wxbr_4p_XSMhUwfCGyRAgtn0ey2qhCLBz5mP7CLWLtUyWLEgDwR1DRx_fv2FT8aN3nBUWOHUICYkhMkkpx3So0dcQYcfleJodmje7zI0-lE1AFDmiVESUS7MEweRCxKQq_oNGMFBNOUQgM6JBQ_u4IYO3su_JqakdeH_UpaO7vAk5v4tnM-WW8_-MJPDn87zYYQvANW3hVnVm8p7z84BEj-_NacyRu7Un8hYxK_Pm3-W1ftC3QKNk4eGfBuCzdXgsiCtWAjlDGr3w4vvImLOfoqvjiUi/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-ext-registry-epp-03>>,
I have the following feedback items:
>
> 1. In Section 2.1.1, it's recommended change "XML schema and
namespace URIs MUST be registered in the IETF XML Registry using the
procedures described in RFC 3688 [RFC3688]" to "*Defined* XML schema
and namespace URIs MUST be registered in the IETF XML Registry using
the procedures described in RFC 3688 [RFC3688]" to make it clear that
extensions are not required to have at least one XML schema and
namespace URI, which would not be the case for EPP transport extensions.
>
> */[SAH] Let me suggest a different re-wording: “XML schemas, XML
schema URIs, and XML namespace URIs defined in the extension
specification MUST be registered in the IETF XML Registry using the
procedures described in RFC 3688 [RFC3688].” We need to include XML
schemas, too, and this is clearer about what “defined” means./*
>
I am good with the wording, but EPP transports are not extensions
according to RFC 3735. For clarity, that needs to be stated.
Also, RFC 3735 is an informative reference but needs to be a normative
reference.
> 2. In Section 2.2.2, "TLDs: "Any"|<one or more TLD text strings
separated by commas>" needs to be modified to "TLDs:
"Any"|*"N/A"|*<one or more TLD text strings separated by commas>" to
include the new "N/A" value.
>
> */[SAH] Yes, good catch. Thanks./*
I agree. This is a good change.
>
> 3. In Section 2.2.3, it's recommended to change "Records in this
registry may only be removed or deactivated with IESG Approval (see
[RFC8126])." to be "*IETF specification* records in this registry may
only be removed or deactivated with IESG Approval (see [RFC8126]).".
This would only require inclusion of the IESG for IETF specifications
and not non-IETF / proprietary specifications.
>
> */[SAH] Maybe, but this change doesn’t explain how to deal with
non-IETF specification records. Another sentence is needed. Perhaps
something like this: “Non-IETF specification records in this registry
may only be removed or deactivated with the approval of the original
registrant.”./*
>
> */Does anyone have any concerns with any of these changes?/*
This is backwards. The IESG should not be removing registrations
created via IETF consensus. However, the IESG should have the power to
remove bad registrations, such as those wrongly using URIs not under
the control of the registrant, or references that rot and become
malware distribution points, or even court-orders requiring removal.
Also, it could be argued that any registration that is a link to an
IETF Internet Draft or are derived from an IETF Internet Drafts or
improperly use an IETF namespace are IETF specifications. So
"non-IETF" is ambiguous.
I suggest the following:
"Registrations not created through IETF consensus may be removed or
deactivated with the approval of the IESG, in consultation with or at
the request of the Designated Experts."
-andy, as an individual
_______________________________________________
regext mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
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
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
