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, -- 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/4/26, 9:22 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. I disagree. I think this is a bad idea. First, how many transports are we expecting? If it is a lot, then that is a problem as it fractures the EPP ecosystem and the cost of a hundred EPP transports will be born by the registrars. If it is only 2, this is a waste of time. Second, the EPP extensions registry is a Specifications Required registry. That means anybody can register an EPP transport, which is bad because as we have seen with the EPP-over-HTTP discussions it is easy to get the security and transaction semantics wrong. EPP transports need IETF consensus so they get the proper scrutiny. Allowing people to register EPP-over-REST or EPP-over-Anycast or EPP-over-FastHTTP or EPP-over-WebSockets or EPP-over-OHTTP or EPP-over-IPsec or whatever doesn't sound like a good idea. Third, we should not be encouraging lots of EPP transports. The EPP-over-HTTP discussion has focused a lot on the costs to the registries but nobody has mentioned the costs to the registrars. While the registries get to be selective in which transport they deploy, the registrars have a much higher burden in that they have to implement most of the transports and EPP XML extensions. New EPP transports should only be encouraged when the costs to all parties are weighed. -andy On 03-03-2026 4:19 AM, Mario Loffredo wrote: > 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://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>]." >> to "Guidelines for extending EPP transports are documented in Section 2.1 >> of RFC 5730 [RFC5730 >> <https://secure-web.cisco.com/1WGpruwmY4SR7OS02VYlE95slFWggD7JaJ7Ocop8ymIpjLViGgR-gowNp209tS-AZBwaIY-7h5x1T_jb_JRk3UK_iicKhF0rxHOUbrr7tAqe3XcilQKAgc10wgQkWvbhFqD68i5dQVwuI5Tpwvm45JbEr8VKi-v07b4IjIScqVk5wX_K-OzvKuq5hPHVdnoqJ1YETZRnkVFqeAEFw0JtMapRTGQ5wD9UQqM5TL1fcIFOCD48od_UM2VLZU76_KZSgI3Mb7QLV2m43ZUCiWTefUh-aKi_9pXjNVixxl7zNE-I/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5730> >> >> <https://secure-web.cisco.com/1WGpruwmY4SR7OS02VYlE95slFWggD7JaJ7Ocop8ymIpjLViGgR-gowNp209tS-AZBwaIY-7h5x1T_jb_JRk3UK_iicKhF0rxHOUbrr7tAqe3XcilQKAgc10wgQkWvbhFqD68i5dQVwuI5Tpwvm45JbEr8VKi-v07b4IjIScqVk5wX_K-OzvKuq5hPHVdnoqJ1YETZRnkVFqeAEFw0JtMapRTGQ5wD9UQqM5TL1fcIFOCD48od_UM2VLZU76_KZSgI3Mb7QLV2m43ZUCiWTefUh-aKi_9pXjNVixxl7zNE-I/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5730>>] >> and for extending EPP XML are documented in RFC 3735 [RFC3735 >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>]." >> 2. Section 2.1 “Extension Specification, modify "Note that Section 2.1 of >> RFC 3735 [RFC3735 >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>] >> provides specific guidelines for documenting EPP extensions." to "Note that >> Section 2.1 of RFC 3735 [RFC3735 >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>] >> 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://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>] >> provides specific guidelines for documenting EPP extensions." to "Note that >> Section 2.1 of RFC 3735 [RFC3735 >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>] >> 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://secure-web.cisco.com/1WGpruwmY4SR7OS02VYlE95slFWggD7JaJ7Ocop8ymIpjLViGgR-gowNp209tS-AZBwaIY-7h5x1T_jb_JRk3UK_iicKhF0rxHOUbrr7tAqe3XcilQKAgc10wgQkWvbhFqD68i5dQVwuI5Tpwvm45JbEr8VKi-v07b4IjIScqVk5wX_K-OzvKuq5hPHVdnoqJ1YETZRnkVFqeAEFw0JtMapRTGQ5wD9UQqM5TL1fcIFOCD48od_UM2VLZU76_KZSgI3Mb7QLV2m43ZUCiWTefUh-aKi_9pXjNVixxl7zNE-I/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5730> >> >> <https://secure-web.cisco.com/1WGpruwmY4SR7OS02VYlE95slFWggD7JaJ7Ocop8ymIpjLViGgR-gowNp209tS-AZBwaIY-7h5x1T_jb_JRk3UK_iicKhF0rxHOUbrr7tAqe3XcilQKAgc10wgQkWvbhFqD68i5dQVwuI5Tpwvm45JbEr8VKi-v07b4IjIScqVk5wX_K-OzvKuq5hPHVdnoqJ1YETZRnkVFqeAEFw0JtMapRTGQ5wD9UQqM5TL1fcIFOCD48od_UM2VLZU76_KZSgI3Mb7QLV2m43ZUCiWTefUh-aKi_9pXjNVixxl7zNE-I/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5730>>] >> and RFC 3735 [RFC3735 >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735> >> >> <https://secure-web.cisco.com/1jJIu7x9d30UW9NfqwWZ3shTbLEQF3xJjKnwKEnaC1XMozuJzTrftlsGcwab1irgvvs8vx34AQq68my9GgxAQxVR3HERHeGLTd4NEAyPDWU19Vfiji3-qQS0kNki-m2PBgLleG4R-4uP6ZHwDJZSqHpQ5DMRPKQ-4CFVz4TXDeKZ6vyWB9zGPSWQUQ-tmOHZtkzKnSkhpdTHcJBI_xRfFz4mR4Km1zWdwc379CPb4Bj7FTyrOxocgnY5FH_3c7R0xolqM_rJrPLKl3z2SmAWA8-MfCU1FkuVInAGwxRW9mUg/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3735>>]." >> >> 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://secure-web.cisco.com/1-rNtAx0kZMjDjGLD3kMJ_mdnNPO0YGsgkJPsvFzYc_MMi-6ZA8WjYKmibXwEmdWvp6jJX7F_4iFk_VuhsTc3Gar6f8JTH6bJwvw_EAZhOYZqNpJs6xXOGpBj9I33gjvTM5XrVPkWFoZ186UqQBcNwI5xCbdR_tNTXMS52-Hot3U2iAoNMPtG8r7FoBg_OxALCfCUbwWTjEduvkd4BHx0v3HWLjumiSKyaIYcyaUBCH0oNZ3-jMAU02iGUVzYmb8gPtrW4hxmHkTZsq-GO_fPs67G2__ATxZKYCbYfkhZg44/http%3A%2F%2Fverisigninc.com%2F> >> >> <http://secure-web.cisco.com/1-rNtAx0kZMjDjGLD3kMJ_mdnNPO0YGsgkJPsvFzYc_MMi-6ZA8WjYKmibXwEmdWvp6jJX7F_4iFk_VuhsTc3Gar6f8JTH6bJwvw_EAZhOYZqNpJs6xXOGpBj9I33gjvTM5XrVPkWFoZ186UqQBcNwI5xCbdR_tNTXMS52-Hot3U2iAoNMPtG8r7FoBg_OxALCfCUbwWTjEduvkd4BHx0v3HWLjumiSKyaIYcyaUBCH0oNZ3-jMAU02iGUVzYmb8gPtrW4hxmHkTZsq-GO_fPs67G2__ATxZKYCbYfkhZg44/http%3A%2F%2Fverisigninc.com%2F>> >> >> On 2/26/26, 11:32 AM, "Andy Newton" <[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. >> >> On 2/26/26 9:38 AM, Hollenbeck, Scott wrote: >> >> > *From:*Gould, James <[email protected] >> > <mailto:[email protected]> >> > <mailto:[email protected] >> > <mailto:[email protected]>>> >> >> > *Sent:* Wednesday, February 25, 2026 4:19 PM >> >> > *To:* [email protected] <mailto:[email protected]> <mailto:[email protected] >> > <mailto:[email protected]>>; [email protected] >> > <mailto:[email protected]> >> > <mailto:[email protected] >> > <mailto:[email protected]>>; >> > [email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>; >> > [email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>; >> > [email protected] <mailto:[email protected]> <mailto:[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>> >> > >> > <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&gt;>>, >> > 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]> >> <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] <mailto:[email protected]> >> To unsubscribe send an email [email protected] >> <mailto:[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://secure-web.cisco.com/10bzrCgTeckRVwbvVRR3KtFFYw9C_nzwg339d5HM7dezAo8GoadPb4YKw0JKgHJJAFgk3sSHCfgUI3RkubsEF5KkOxb3xDpW8cvKw2Ep9a4ktUlj454cANS3bqlK2ZxI1ra6JreLnIHP7pk11R3XtMXT4ryxhsdQdLYqAC1WC0uyxJcDKI_xSnlW0H8L3joDbcPcKvS7GLA5gPnEa6cV3xmcfqP0xs1WkmikWok2lhEhNjpwo9o1zjyoUQHl2ArspyBOqdtrOARDlSncN8DqcdS4V3oQVW77uCZufROetBrg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo > > <http://secure-web.cisco.com/10bzrCgTeckRVwbvVRR3KtFFYw9C_nzwg339d5HM7dezAo8GoadPb4YKw0JKgHJJAFgk3sSHCfgUI3RkubsEF5KkOxb3xDpW8cvKw2Ep9a4ktUlj454cANS3bqlK2ZxI1ra6JreLnIHP7pk11R3XtMXT4ryxhsdQdLYqAC1WC0uyxJcDKI_xSnlW0H8L3joDbcPcKvS7GLA5gPnEa6cV3xmcfqP0xs1WkmikWok2lhEhNjpwo9o1zjyoUQHl2ArspyBOqdtrOARDlSncN8DqcdS4V3oQVW77uCZufROetBrg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> > _______________________________________________ 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 to [email protected]
