> -----Original Message----- > From: Andy Newton <[email protected]> > Sent: Thursday, February 26, 2026 11:33 AM > To: [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. > > > > On 2/26/26 9:38 AM, Hollenbeck, Scott wrote: > > *From:*Gould, James <[email protected]> > > *Sent:* Wednesday, February 25, 2026 4:19 PM > > *To:* [email protected]; [email protected]; > [email protected]; [email protected]; [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_XSMhUwfCGyRAgtn0ey2qhCLBz5mP7CLWLtUyWLEgDwR1DR > x_fv2FT8aN3nBUWOHUICYkhMkkpx3So0dcQYcfleJodmje7zI0- > lE1AFDmiVESUS7MEweRCxKQq_oNGMFBNOUQgM6JBQ_u4IYO3su_JqakdeH > _UpaO7vAk5v4tnM-WW8_-MJPDn87zYYQvANW3hVnVm8p7z84BEj- > _NacyRu7Un8hYxK_Pm3- > W1ftC3QKNk4eGfBuCzdXgsiCtWAjlDGr3w4vvImLOfoqvjiUi/https%3A%2F%2 > Fdatatracker.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.
[SAH] I agree that 3735 should be normative. I don't think we need to state what isn't an extension, though. Isn't it enough to use what's already in the text? "Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735]". Anything that doesn't adhere to those guidelines isn't in scope. > > 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." [SAH] Sorry, I need to ask for a clarification. Here's the existing text: "Records in this registry may only be removed or deactivated with IESG Approval (see [RFC8126])" Proposed replacement (I've modified Jim's original proposal to be consistent with Andy's proposed text)? "Registrations created through IETF consensus can only be removed or deactivated with IESG Approval (see [RFC8126]). Registrations not created through IETF consensus can be removed or deactivated with the approval of the IESG, in consultation with or at the request of the Designated Experts." If so, that still leaves out the evaluation criteria for a request to remove or deactivate a registration not created through IETF consensus received from someone other than the IESG. Can we add this? "Registrations not created through IETF consensus can also be removed or deactivated by the original registrant, in consultation with the Designated Experts." I've changed instances of "may" to "can" to avoid those worms, too. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
