Minutes IETF119: regext
minutes-119-regext-00

REGEXT - IETF 119 - Brisbane - 2024-03-20

Registration Protocols Extensions (REGEXT)
IETF 119 Brisbane, AU / Online

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

Wednesday, March 20, 2024 9:30-11:30 M2, Tuesday March 19 23:30-1:30 UTC
Meetecho https://meetings.conf.meetecho.com/ietf119/?session=32057

Chairs’ Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-chair-slides

Jim on-site and Antoin remote

    Welcome and Introductions (4 minutes)

i. NOTE WELL
Well-noted by Jim
ii. Notes scribe
Wilhelm and…
iii.Document management

    Published (0 minutes)

    None
    (at this time… but)

    RFC Ed Queue (1 minute)

i. RDAP Reverse search capabilities (Mario Loffredo)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

ii. Federated Authentication for the RDAP using OpenID Connect (Scott
Hollenbeck) https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/

iii.Redacted Fields in the RDAP Response (Jody Kolker/Roger Carney)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/

The above are all quite close to being published.

    Submitted to IESG (1 minute)

iv. Use of Internationalized Email Addresses in EPP protocol (Dmitry
Belyavsky/Jody Kolker)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

Has been in IESG queue for a bit; some discussion with the ART directorate
related to email address support. Might have impacts on other parts of EPP
because it impacts a ‘global setting’. There will be a WG review prior, via the
mailing list.

From chat: George Michaelson: Would I be right in thinking this has interest
for ICANN tech compliance because of universal acceptance? (intl emails). Jim:
No, this is not due to interest from ICANN compliance. It’s related to how it
impacts general mail services.

    Past WG last call (2 minutes)

    i. IP and ASN searches in RDAP (Tom Harrison/Jasdip Singh)
    https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/

Waiting for Doc Shepherd writeup on this one.

    Existing work (11 minutes)

Antoin: Turning it over to Gavin

i. EPP mapping for DNS TTL values (Gavin Brown, 5 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/

Gavin Brown:

Reviewed slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-draft-ietf-regext-epp-ttl-slides-for-ietf-119

Requested feedback and said that will be publishing an updated version shortly.

ii. RDAP Extension for Geofeed Data (Jasdip Sing, 6 minutes)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/

Reviewed slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-rdap-geofeed-extension

Scott Hollenbeck: Suggested to include the URL for the IANA registry. Jasdip:
Good idea

(The exchange below could likely benefit from clarification because it seemed
to stem from a prior conversation between Antoin and Jasdip)

Antoin: James had a suggestion about the contents of the feed. Could the
geofeed be evolved? Jasdip: Yes, the feed could be evolved in other ways.
Perhaps as RPKI matures.

Jim Gould: The form of extension might be interesting to include in the RDAP
form of extensions draft. Jasdip: Agreed. Will discuss with Andy Newton.

    RDAP versioning and extensions discussion (37 minutes)

    Versioning in the Registration Data Access Protocol
    https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-versioning/

    RDAP Extensions
    https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/

    An RDAP With Extensions Media Type
    https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/
        What problem or problems are we trying to solve?
        What contribution(s) does/do each of these documents make to the
        problem(s)?

    The Chairs will be kicking off this conversation during our IETF119 meeting.
    Because that time will be limited, the plan is to use that time to organise
    and structure an interim meeting during which we will address those
    questions and our path to a solution.

Galvin: The plan is for an interim meeting in April.

Two questions (see the above)

From Chair Slide deck, slide 20:

Documents appear to be related

    They are not fully cross-referenced with each other – should they be
    Documents appear to overlap
    Are they sufficiently clear and specific about their roles?
    There should be only one standard for a function
    Anything else should be experimental

Jim Gould: These docs are solving different problems; First is guidelines for
extentions, similar to RFC 3735; Versioning extension is related to (basicaly)
versioning, and allows the client to specify a preference. And the Media Type
doc is more specializied.

Andy Newton: Agree with Jim’s point. Each draft references the other, in some
way. I don’t think that we help each other by consolidating.

Antoin: What problem needs to be solved? Is this a problem worth solving?

Rick Wilhelm: Agreed that this is a problem that needs to be solved. We need
clalrity around extensions for RDAP to make them simple.

Pavel: Would like to see clarity related to extensions.

Scott: We do not have a 3735 corrollary for RDAP. We need something like 3735
for RDAP. Not too concerned whether or not they are not one doc or multiple.

Antoin: Would like to get standard approach to extensions.

Jasdip: Generally agree with comments. As RDAP matures, there have been
questions about extensions, would be good to have more clarity. Each of these
mechanisms have well-defined needs.

Galvin: Versioning and Extension Guidelines: Good to have clarity on these.
Perhaps an interim discussion on these would be helpful. Will work on a Doodle
to try to have a session on this.

Have not heard much discussion about the media type discussion, but not the
media type doc. Would be good to have clarity about the media type doc.

Antoin: Is a negotiation of media type something that happens in RDAP?

Andy Newton: The reason the media type came up, you need a way for the client
to signal which version of the extension they want. It’s content negotiation.

    New work with presentations (45 minutes)

i. RDAP Extension for DNS Time-To-Live (Gavin Brown, 5 minutes)
https://datatracker.ietf.org/doc/draft-brown-rdap-ttl-extension/

Reviewed slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-rdap-ttl-extension

Jim Galvin: Should this and the EPP doc be done concurrently?

Gavin: Seems like the EPP certainly needs to be done first.

Rick Wilhelm: Seems like we are letting DNS data into the DNS

Andy: This provides value to end users

Galvin: The TTL is subject to registry policy; it’s useful to have a means to
understand what the registry thinks is the state of the world. The TTL value
being there is consistent with what we have done historically.

Jim Reid: Is this a problem that is worth solving?

Stephane Bortzmeyer: There is a difference between the various records and the
TTL. It’s important to be able to checked that they are correct. What applies
to NS, DS, and glue does not apply to TTL.

Jasdip: This would be useful.

Wes Hardaker: DELEG BoF chair: this is not on the near-term roadmap for DELEG.

ii. EPP mapping for DELEG records (Gavin Brown, 10 minutes)
https://datatracker.ietf.org/doc/draft-brown-epp-deleg/

Attempted to review slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-epp-deleg-extension

(delayed due to technical issues)

This item actually only received about 25 seconds at the end of the session due
to technical issues with the slides.

Jim Reid: Timelines on DELEG are not clear. WG may or may not be up before
Vancouver.

Wes Hardaker: The structure of the solution is not even clear. There may be
counter-proposals.

David Lawrence: A proposed RR, but also a WG.

iii.RESTful interface for EPP (Maarten Wullink, 10 minutes)
https://datatracker.ietf.org/doc/draft-wullink-restful-epp/

Reviews slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-restful-interface-for-epp-maarten-wullink

Scott Hollenbeck: thx for the work; modifying schema in 5730 means that this
isn’t EPP, but is “EPPish”, we’re not chartered to do EPP 2.0. Maybe this is
Experimental, but seems outside of WG scope

Jody Kolker in chat: How would fee extension be mapped? Maarten: should work;
but deserves study.

iv. EPP Transport over HTTP (Mario Loffredo, 10 minutes)
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/

Reviewed slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-epp-over-http

Rick Wilhelm asked a question about the self-signed server certs. Will cover
off-line.

Wes Hardaker: Suggest that the Security Section in the draft get some attention
about its specificity.

Maarten: Draft doesn’t have URL path specifics. Is that open to the
implementer? Mario: Sessions stars when you open the GET method.

v. EPP Transport over QUIC (Jiankang Yao/Dan Keathley/James Gould, 10 minutes)
https://datatracker.ietf.org/doc/draft-yao-regext-epp-quic/

Reviewed slides provided in meeting materials.

https://datatracker.ietf.org/meeting/119/materials/slides-119-regext-epp-over-quic

Presented by Jiankang

Stephane Bortzmeyer: Some benefits of QUIC may not apply to EPP, not convinced
of the benefits of QUIC for EPP; first slides might be overselling the
benefits. Jiankang: not looking to replace TCP/TLS, but looking to give more
choice

Jim Gould: There could be performance benefits by allowing multiple streams.
Also, since transports are defined in 5730, additional transports are within
scope of the charter. (ed. there was discussion in the chat about whether or
not this is in scope of the charter)

Scott Hollenbeck: While transport extension is in-scope of EPP, I don’t know if
we have a good way for transports to be discovered. Something we need to think
about.

    AOB

Murray: this is my last WG as AD

Orie Steele: I’m the new AD!

Meeting closed at 11:35 local by Antoin