Minutes IETF114: regext: Thu 17:30
minutes-114-regext-202207281730-00

IETF 114 REGEXT Meeting Notes

Registration Protocols Extensions (REGEXT)
IETF 114 Philadelphia US / Online

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

Thursday, 28 July 2022 17:30-18:30 local; 21:30-22:30 UTC
Room: Philadelphia North
Meetecho:
https://meetings.conf.meetecho.com/ietf114/?group=regext&short=&item=1

Galvin in person and Antoin attending remote

1. Welcome and Introductions (4 minutes)

   i. Notes scribe
   ii. NOTE WELL
   iii. Document management

2. Published (0 minutes)

   None

None published since last meeting.

1. Status of documents past WGLC (RFC Editor, IESG, AD evaluation) (2
   minutes)

   Use of Internationalized Email Addresses in EPP protocol (Dmitry
   Belyavsky/Jody Kolker)
   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
   This document has quite some discussion in the IETF-wide last call,
   and issues reported from:
   i18ndir, secdir and artart LC.

No in-meeting comments beyond the above.

1. Status of existing work no presentation. (2 minutes)

i. Simple Registration Reporting (James Galvin)
https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/

Expecting to pubish a new version soon, incorporating recent feedback.

1. Existing work discusion documents (10 minutes)

i. Registration Data Dictionary (Steve Crocker/Heather Flanagan)
https://datatracker.ietf.org/doc/draft-ietf-regext-datadictionary/

Slides:
https://datatracker.ietf.org/meeting/114/materials/slides-114-regext-datadictionary-00

Preso from Heather

Discussion and debate with comments from Wilhelm and Michaelson, along
with the authors.

In chat, Koch mentioned RFC 8499 as a comparable, noting that it's
"only" a BCP and does not use normative language

1. Discussion topic on RDAP extensions identifier conformance. (30
   minutes)

Slides:
https://datatracker.ietf.org/meeting/114/materials/slides-114-regext-rdap-extension-identifier-and-rdapconformance-00

  There was a long discusion in the mailinglist about RDAP extension versioning and conformance.
  There is an inconsistency in RFC9083 that led to interpretation differences that needs to be 
  corrected and now affects progress of the following documents:

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

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

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

iv. Using JSContact in RDAP JSON Responses (Mario Loffredo/Gavin Brown)

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/

  We will have an extensive discussion on how to progress with this.
  Please all read the discussion on the mailinglist to form an opinion before the meeting.

Galvin presented slides. (See above link.)

Essentially, proposal is to tighten up RFC9083 and not try to put in
versioning. See slide 7 for details.

Supportive comments from Gould; suggested that we address versioning
separately.

Hollenbeck suggested a slight change to the proposal to improve 9083.
That is, instead of changing the example from "lunarNIC_level_0" to
"lunarNIC", it would go in the other direction: from "lunarNIC" to
"lunarNIC_level_0". This is suggested because the RDAP label is
"rdap_level_0".

(in chat and later at the mic) Gould wants to ensure that identifiers
like icann_rdap_response_profile_0 and
icann_rdap_technical_implementation_guide_0 can continue to be
registered, since versioning is not an RDAP Extension Registry feature.

Hollenbeck confirmed at the mic

General agreement in the room and in the chat, but this will be taken to
the list to be fully sorted and finalized.

Next steps:

• Chairs to send a note to the list
• WG members to comment; allows Chairs to assess consensus
• Hollenbeck said that (after receiving direction from Chairs), he
  will work on an errata report for RFC 9083 (which will eventually
  circulate back to the WG for a consensus check)

1. AOB