Registration Protocols Extensions (REGEXT) @IETF113

Registration Protocols Extensions (REGEXT)
IETF 113 Vienna, Austria / Online

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

Tuesday, March 22, 2022 13:00-14:00 CEST Grand Klimt, 12:00-13:00 UTC Meetecho
https://meetings.conf.meetecho.com/ietf113/?group=regext&short=&item=1

1. Welcome and Introductions (4 minutes)

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

2. Published (1 minute)

   Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer
   https://datatracker.ietf.org/doc/rfc9154/

   Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)
   https://datatracker.ietf.org/doc/rfc9167/

The above was noted by the chairs

3. Status of existing work in Progress (RFC Editor, IESG, AD evaluation) (2 minutes)

   Finding the Authoritative Registration Data (RDAP) Service
   https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/
   RFC Ed Queue

   Use of Internationalized Email Addresses in EPP protocol (Dmitry Belyavsky/Jody Kolker)
   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
   WGLC closed, Waiting for shepherd confirmation and writeup

The above was noted by the chairs.

4. Existing work. (36 minutes)

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

Authors believe ready for working group last call. Will ask on the list after IETF113.

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

Mario gave update on recent implementation updates. Indicated that doc is likely ready for WGLC.

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

Document has changed substantially since last version.

Please look at list of query purposes.

Maybe just one more version and we should move to WGLC.

iv. Using JSContact in RDAP JSON Responses (Mario Loffredo/Gavin Brown)
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/

Wilhelm noted that the ICANN RDAP Working Group is modifying the ICANN RDAP Profile such that RDAP responses may use JSContact and are not required to use jCard.

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

Some work is being done in the ICANN RDAP Working Group that may impact this work.

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

See github at https://github.com/hlflanagan/Registration-Data-Dictionary if that helps you
Heather and Steve reviewed the slides (see meeting materials)

Jim Galvin: A-label vs U-label - you probably have to have both. You can't control anything else down the tree.

James Gould: Confused about the purpose of the draft because it has a mix of syntax. Some have a syntax definition, some don't. If we use the data elements in the protocol, they may not match. Are we trying to normalize the syntax as well, that gets hard. Suggest we remove syntax entirely.

Steve Crocker: need to be careful to pull out "domain" where we can so we don't confuse people with DNS

James Gould: choice of the data elements - seeing new elements unfamiliar with TBD, don't see many data elements that exist in other RFCs related to registrations. Suggest reviewing those RFCs for elements that may be applicable. Also, make sure that the data elements follow a consistent naming convention (seeing upper case, lower case, some with underscores, etc - normalize this).

Gustavo Lozano: registry should include revision history for each definitions. (Michelle Cotton will find an example and send it to Steve and Heather)

Jim Galvin: there was a comment about whether there is any concern about contracts, regulations, laws that might impact what an element might look like. Should we care more about the semantics and syntax? Let's take a step back and figure out where to go with this document.

Steve Crocker: We're not trying to solve conflicts as much as we're trying to provide common terminology where sensible; if there are issues with how the definitions are used, that goes up a level to a different venue. Can envision a situation where the separation between what is commonly understood and local interpretations could make things interesting.

Eduardo Alvarez: The IDN repository uses some form of tracking of historical versions. That might be useful.

Jothan Frakes: Wearing the registrar representative hat - There are concerns about some of the fields being collected and defined for registrar information. There is a lot of variation between registrars regarding what they collect. The presence of fields might result in questions about why they don't collect everything. Need to think about what fields should/shouldn't be there.

Jasdip Singh: The starting point could be, if you look at RDAP, that's a common protocol between DNRs and RIRS, and it defines data structures fairly well for both types of registries. To help capture the right set of data elements, that could be a good starting point.

5. New work and requests for adoption presentations (10 minutes)

i. Extensible Provisioning Protocol (EPP) Transport over HTTP (Mario Loffredo)
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/

With respect to HTTPS, please inherit the security considerations regarding the use of TLS.

Client authentication requirements are different between this document and HTTP3. This needs to be reconciled.

No cookies please. EPP doesn't have them so why here?

6. AOB