IETF 123 - REGEXT

Registration Protocols Extensions (REGEXT)
IETF 123 Madrid, Spain and Online

Co-chairs: Jorge Cano, Jim Galvin, Antoin Verschuren
Mailing list: regext@ietf.org

Tuesday, 22 July 2025
9:30 - 11:00 local / 7:30 - 9:00 UTC

Chair slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-chair-slides-00

1. Welcome and Introductions (3 minutes)
   i. NOTE WELL: Noted, along with agenda bashing, etc
   ii. Notes scribe: Richard Wilhelm and
   iii. Welcome to our new co-Chair: Jorge Cano
   iv. New work session (later)

2. Published (1 minutes)

   i. EPP mapping for DNS Time-To-Live (TTL) values
   https://datatracker.ietf.org/doc/rfc9803/

3. RFC Ed Queue (1 minutes)

   i. Additional Email Address Extension for the Extensible
   Provisioning
   Protocol (EPP)
   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
   Proposed Standard

   ii. Best Practices for Deletion of Domain and Host Objects in the
   Extensible Provisioning Protocol (EPP)
   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/

   Best Current Practice

4. Submitted to IESG (1 minutes)

   i. An RDAP Extension for Geofeed Data
   Approved-announcement to be sent::AD Followup
   https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/
   Proposed Standard

   ii. RDAP RIR Search
   Approved-announcement to be sent::AD Followup
   https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/

   Proposed Standard

Latest and greatest: both of these docs are in the RFC Editor Queue.

1. Existing work update (15 minutes)

   i. Versioning in the Registration Data Access Protocol (RDAP)
   (Jim Gould)
   https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-versioning/

   March 2025

Gould: (via chat) The draft was updated to add the EPP Extension
Registry registration in -01.
2 We are looking for addition review by the working group and looking to
gain additional implementation experience.

ii. Using JSContact in RDAP JSON Responses (Mario Loffredo)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
May 2025
Slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-update-on-draft-ietf-regext-rdap-jscontact-00

Mario spoke to the last slide:

• Published 2 updates to the drafts
• Removed references to the UID property
• Added language to add a JSContact profile
• Added some references
• Has been moved to Experimental; and discussing what are the best
  measures to evaluate the experiment

Pawel: Good update to use the Profiles; re: the properties, can be
reduced further. Also, in looking at the reverse search implications,
there could be negative impacts: probably needs attention.

Maarten: re: Experimental status: would rather see it in normal status.
Galvin: we didn't want it to be having it competing with anything
currently standardized.

Andy (as an individual): We may have a slight adjustment: if RPP adopts
JSContact, then there may be an opportunity to open the discussion.

Pawel: The competing part was about SimpleContact.

Discussion on this was deferred to the list.

iii. EPP Transport over QUIC (Jim Gould)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/
September 2025

Gould: (via chat)
3 We can notify the QUIC working group of the draft and ask for feedback
there.
4 We are not aware of any additional work items, so once we have the
desired level of review (REGEXT and QUIC) and implementation experience,
the draft should be ready for WGLC.

Action: Chairs to reach out for review by QUIC WG

iv. EPP Transport over HTTPS (Mario Loffredo)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-https/
September 2025

Mario:

• Since last meeting: added language to do the addition to the
  registry
• Looking for additional implementations

• Think that it's ready for WGLC

  v. RDAP extension for RPKI Registration Data (Jasdip Singh/Andy
  Newton)
  https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rpki/
  July 2025

Jasdip: Presented work to SIDROPS; included their feedback (which was
substantive); will now present revision for the WG

1. Existing work presentations (15 minutes)

   i. RDAP Extensions (Andy Newton) - 10 minutes
   https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/

   January 2025

   Slides:
   https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-draft-ietf-regext-rdap-extensions-00

Andy presented slides

Position 1: Disallow (effectively turn the SHOULD to MUST)
Position 2: Always allow them (effectively remove the SHOULD)

Why disallow:

• This simplifies, makes consistent the rules for writing extensions
  which will reduce mistakes.
• Implementation feedback has indicated that they can cause problems
  under certain circumstances.
• Bare identifiers look like core RDAP and can cause confusion.
• Goes against many IETF RFCs on protocol design: RFC 1958, RFC 5218,
  & RFC 9413.

See:
https://mailarchive.ietf.org/arch/msg/regext/7uEXtk1B5_KoFtJlhrRPICcZ0/

Why allow:

The only consistent reason given is that it looks better (“beautyˮ).

• but that is an aesthetics argument, not a technical argument.
• hidden from the user, so only software sees this beauty.
• unusable if more than one identifier of a type is defined.

The Compromise:

• The compromise is allowance just in case there is something we did
  not consider (after 10 years, this is unlikely).
• It does what all compromises are supposed to… move us past this
  issue.

Clarifying questions/discussion:

Pawel:

• If we prefix, we will be stuck with this;
• Typically the only feedback that is registered is negative
• The underscores make the protocol less readable by humans (forbids
  snake case)
• Agree that one way is better than to ways, but... (didn't catch)

Gould:
In chat: I recommend BARE EXTENSIONS ALWAYS ALLOWED with a guidance,
where a bare extension identifier can be used when there is a single
element of a particular type (path segment, query parameter, JSON name,
HTTP header parameter)

Scott: Asked for folks to weigh in.

Jim Galvin: Proposing that we land on not allowing Bare Identifiers.
Compromise lacks the guidance that's needed. It's the simpler approach.
Leave those extensions that currently use bare identifiers.

Orie: Chair proposal needs time on the list.

ii. An RDAP With Extensions Media Type (Andy Newton) - 5 minutes
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/
March 2025

 Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-draft-regext-rdap-x-media-type-00

Andy presented the slides:

See slide 2 for details

No discussion

1. Update on related work (5 minutes)

   i. EPP Extensibility and Extension Analysis Update (Jim Gould)
   Slides:
   https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-epp-extensibility-and-extension-analysis-update-rpp-update-00

(Jim Gould had audio issues)
Jim to present same deck in RPP, by which time he hopes to have his
audio sorted.

Deck identifies issues related to consistency between current EPP and
RPP futures.

1. Potential new work presentations (40 minutes)

   i. Domain variant support for EPP
   James Galvin
   https://datatracker.ietf.org/doc/draft-galvin-regext-epp-variants/

   Slides:
   https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-domain-variant-support-for-epp-00

Jim Galvin presented slides (taking off Chair hat):

First 9 slides are repeats of slides presented previously, moved quickly
to Open Issues.

Aiming for sense of the room for adoption

Ruth (Nominet): Asking about thin vs. think Registries, does this still
apply?

• Yes, it does: it can be a requirement on the registry, but that's a
  matter of policy.

Key issues:

• Switch from "variant" to "related group"
• Use of vs for removing variants

Discussion:

• Scott: Concerns about IDN expertise, we should talk about how we get
  IDN expertise.
• Q: On DNSSEC, IDN variants probably doesn't work for DNSSEC; I think
  that a better approach would be to use create/delete, rather than
  update

• Gavin:

  • Doc would benefit from a clear description of the problem being
    solved;
  • re: update vs create - in the policy space, this was
    contentious;
  • Concerned that there are too many policy assumptions (about the
    gTLD world);

  • Using as a variant source could be a performance problem;

    • Jim: the is only for activated variants, not possible
      variants, not the allocatable ones

  • Certainly a problem that needs to be solved

• Ruth: How are lock statuses going to interact with this?

  • Jim: statuses would be applied to the group

Jim: will be asking for adoption.

Antoin: take to the list

ii. Domain Registry Grace Period Mapping for the EPP
Roger Carney, Rick Wilhelm, Gavin Brown
https://datatracker.ietf.org/doc/draft-carney-regext-rfc3915bis/

 Slides: https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-updating-the-registry-grace-period-rgp-mapping-00

Rick presented slides.

Discussion:

Pawel: Asked about possible changes to simplify the process. Rick: not
in scope for this doc

Q: Just fixing one bug? Rick: yes.

iii. Extension Registry for the Extensible Provisioning Protocol
Scott Hollenbeck
https://datatracker.ietf.org/doc/draft-hollenbeck-rfc7451bis

Slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-review-of-the-epp-extension-registry-01

Gavin & Scott presented. No discussion (largely because we were pressed
for time)

iv. RDAP response extension for verification status information
Mario Loffredo
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-verified-contacts

Slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-regext-rdap-extension-for-verified-contact-information-00

Mario presented slides (very briefly as meeting as pressed for time)

Discussion:

• Werner: Glad to see this work

1. AOB (time permitting)