**Session Date/Time:** 21 Jul 2026 07:00 # [REGEXT](../wg/regext.html) ## Summary The REGEXT Working Group met to discuss administrative updates, the roadmap for core RDAP extensions, the status of current working group documents, and several new proposals. Key updates included the transition of the working group from the ART area to the OPS area under new Area Director Mohamad Boucadair, and an agreement on a path forward for three historically stalled core RDAP specifications. The group also initiated an experiment utilizing GitHub for document development. The presentation slides can be found in the [Chair Slides](https://datatracker.ietf.org/meeting/126/materials/slides-126-regext-chair-slides-02). --- ## Key Discussion Points ### Administrative and Area Transition * **Area Transfer:** The REGEXT working group has transitioned from the ART area to the OPS area. Mohamad Boucadair is the new Area Director. * **Charter Update:** The charter has been updated to align with OPS area framing. The core responsibilities and scope remain unchanged, but the text is now tighter and more succinct. * **Publication Status:** * The DNS Time-to-Live RDAP extension is with the RFC Editor (to be published as BCP 246 / RFC 10026). * The EPP over QUIC transport draft is also with the RFC Editor. * The EPP Extension Registry draft is pending a final resolution with Roman Danyliw regarding duplicate text from RFC 8126. ### Core RDAP Roadmap Consensus Following an ad hoc meeting between the chairs, AD, authors, and shepherds, a consensus was reached on how to progress three interrelated core RDAP drafts: 1. **`draft-ietf-regext-rdap-extensions`:** Will proceed independently and is expected to move forward largely as-is, with minor language tightening. It is intended to clarify STD 95. A summary of the ad hoc consensus will be sent to the mailing list for a two-week review, followed by a Working Group Last Call (WGLC). 2. **`draft-ietf-regext-rdap-versioning`:** Will proceed independently. The authors published version -06, introducing new features. To resolve a compatibility conflict with the media type draft, a separate parameter specific to the versioning draft was proposed. Outstanding technical issues will be resolved on the mailing list. 3. **`draft-ietf-regext-rdap-x-media-type`:** Will proceed independently but will wait for the publication of `draft-ietf-regext-rdap-extensions` before moving to WGLC. ### GitHub Experiment The chairs announced an experiment to allow authors to draft and discuss documents using GitHub tools. Jorge Cano is drafting a GitHub usage policy document for mailing list discussion. The experiment will begin with `draft-ietf-regext-epp-same-entity` using the newly created IETF REGEXT organization on GitHub. ### Status of Active Working Group Drafts (No Presentations) * **`draft-ietf-regext-rdap-jscontact`:** Mario Loffredo added an operational considerations section as required by the OPS area. The draft is waiting on the resolution of the core RDAP extensions documents before proceeding to WGLC. * **`draft-ietf-regext-balance`:** James Gould reported that version -01 was published, changing the XML schema to use the account balance itself as the object instead of "available credit." * **`draft-ietf-regext-rdap-rpki`:** Jasdip Singh reported that the RPKI community provided positive feedback. The authors aim to fill in the implementation status section and trigger WGLC before the end of the year. * **`draft-ietf-regext-rdap-referrals`:** Gavin Brown reported that version -04 was published. Outstanding issues are being tracked in GitHub, with WGLC targeted by the end of the year. * **`draft-ietf-regext-epp-https`:** James Gould noted that version -03 was published with an operational considerations section to address feedback from Mark Nottingham. Area Director Mohamad Boucadair reminded the group that under the new charter, transport specifications must adhere to BCP 56 and require implementation commitments from at least one registrar and one registry prior to IESG submission. * **`draft-ietf-regext-rfc3915bis`:** Gavin Brown noted no new updates; the draft is still early in its cycle. ### Same Entity Set Support Jim Galvin presented on [Same Entity Set Support](https://datatracker.ietf.org/meeting/126/materials/slides-126-regext-same-entity-set-support-01), covering `draft-ietf-regext-epp-same-entity`. * **Key Changes:** The title was changed from "Domain Variant Support" to "Same Entity Set Support" to generalize the protocol behavior to any equivalent objects (such as Latin diacritics or IDNs) governed by registry policy. XML schema structures and architectural principles have been integrated. * **Technical Complexity:** Antoine Verschuren and Martin noted that handling bundled or equivalent sets of objects introduces complex "generic provisioning" questions (such as how to handle partial cancellations, unique product identifiers, and status syncing) that depart from standard single-object EPP operations. * **Community Feedback:** Ulrich Wisser recommended that the authors consult registries already operating proprietary equivalency solutions. Jim Galvin confirmed they would initiate direct outreach. The working group was polled regarding their comfort with generic provisioning concepts: * **Poll:** *Do you feel comfortable enough to discuss generic provisioning (not EPP/variants) process issues? (Yes/No)* * **Yes:** 13 * **No:** 4 * **No opinion:** 8 * **Total participants voting:** 25 (out of 52 in attendance) ### New Work: Delegation Maintenance Automation Status Extension for EPP Gavin Brown presented [Delegation Maintenance Automation Status Extension for EPP](https://datatracker.ietf.org/meeting/126/materials/slides-126-regext-delegation-maintenance-automation-status-extension-for-epp-00). * **Context:** Proposed operational recommendations for CDS/CDNSKEY and CSYNC delegation automation (to be published as RFC 10026 / BCP 246) dictate that automated DNSSEC maintenance should not be stopped by registry update locks alone. However, many high-value registrants with paid "registry locks" expect absolute stability. * **Proposal:** This EPP extension introduces client-controlled state flags allowing a registrar to explicitly enable or disable DS and/or NS scanning automation for a specific domain, independent of other lock statuses. It also proposes new RDAP status values. * **Discussion:** James Gould questioned if this was strictly necessary on the protocol level, suggesting registry servers could handle this via server policy. Gavin Brown argued that standardizing client signaling is necessary for registrar-managed configurations. Jim Reid suggested looking at Johann Stenstam’s session-signaling notify work in DNSOP to see how this extension might interact with child-to-parent signaling. ### New Work: RDAP Extension for Structured Reliability Assessment Metadata Silvano Romano presented [RDAP Extension for Structured Reliability Assessment Metadata](https://datatracker.ietf.org/meeting/126/materials/slides-126-regext-rdap-extension-for-structured-reliability-assessment-metadata-00) on behalf of himself and Alessandro Femminella. * **Proposal:** An experimental metadata envelope designed to carry standardized, machine-readable security posture scoring (e.g., SPF, DKIM, DMARC, or DNSSEC health assessments) within an RDAP query response. The scoring methodology itself is explicitly out of scope. * **Discussion:** * James Gould and Martin raised concerns regarding who performs the scoring, how false positives are resolved, and how subjective "value judgments" fit into RDAP's historically objective, factual database output. * Rick Wilhelm supported the draft, suggesting it could be run as a standalone RDAP-compliant service by third-party research institutions rather than authoritative registries. Werner Staub agreed, noting it could contribute to a decentralized "web of trust." * Jim Galvin expressed general support for the transport format but noted it currently feels like a "solution in search of a problem." * Mario Loffredo raised concerns regarding reputational risk, legal disputes, and potential NIS2 directive violations if public-facing RDAP servers broadcast an organization's weak security postures to attackers. --- ## Decisions and Action Items * **`draft-ietf-regext-rdap-extensions`:** The chairs will post the ad hoc meeting summary to the mailing list to initiate a two-week review period. If no blocking objections are raised, the document will proceed directly to Working Group Last Call. * **GitHub Migration:** The authors of `draft-ietf-regext-epp-same-entity` will migrate their repository to the newly established IETF REGEXT GitHub organization as the WG's initial tool trial. Jorge Cano will publish the draft GitHub policy on the mailing list for feedback. --- ## Next Steps * **`draft-ietf-regext-rdap-versioning`:** Authors will address the compatibility concerns raised during the ad hoc meeting and discuss proposed x-media parameters on the mailing list. * **Same Entity Support Outreach:** The authors of `draft-ietf-regext-epp-same-entity` will reach out to ccTLDs and registries currently operating custom bundling or diacritic policies to gather practical feedback on the proposed provisioning framework. * **New Work Collaboration:** Gavin Brown will seek a co-author to help refine the delegation maintenance automation extension.