Registration Protocols Extensions (REGEXT)
IETF 115 London UK / Online

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

Thursday, November 10, 2022 17:00-18:00 Richmond 2, 17:00-18:00 UTC
Meetecho
https://meetings.conf.meetecho.com/ietf115/?group=regext&short=&item=1

Meeting opened on time, with both co-chairs in-person

1. Welcome and Introductions (4 minutes)

• i. Notes scribe
  Rick Wilhelm, and others...
• ii. NOTE WELL
  Noted, along with mask reminder

Agenda bashing: see slides... no comments

• iii. Document management

Reviewed doc mgmt slide (slide 8)

Key points:

• fair amount of iteration during WGLC, which makes it hard on doc
  shepherds
• Looking for issue tracking to ensure the integrity of the process
• Try to have a stable document heading into WGLC

1. Published (0 minutes)

   None

2. Documents in WGLC (2 minutes)

• 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/

Plan to deal with both of these on the list.

Brief comments about the side meeting related to regext-rdap-openid;
discussion to be continued on the mailing list.

1. Status of existing work. (4 minutes)

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

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

• iii.Redacted Fields in the RDAP Response (Jody Kolker/Roger Carney)

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

Noted that i, ii, and iii are all ready for WGLC.

Process is that REGEXT tries to have just one group in the queue at a
time. Would like to sort the two that are in WGLC.

Comment from R. Wilhelm that it would be helpful for related ICANN
policy work to have rdap-redacted moved to WGLC sooner rather than
later.

Comment from J. Gould about rdap-redacted, which is waiting on a change
related to JSON path that should be clearing the editor queue sometime
in the next month.

Comment from Galvin that it should be possible to proceed in parallel.

Comment from M. Blanchet: rdap-redacted and jscontact should be the
highest priorities

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

Galvin: authors of datadictionary have not requested WGLC but should be
getting close

1. Discuss issues with document in IETF-wide Last Call (20 minutes)

   We want to spend some time in our WG to allow resolution of issues
   in the IETF-wide last call for a document that was the result of our
   WG: Use of Internationalized Email Addresses in EPP protocol (Dmitry
   Belyavsky/Jody Kolker)
   https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
   This document had quite some discussion in the IETF wide last call,
   and issues reported from: i18ndir, secdir and artart LC.
   The chairs will invite representatives from these directorates so we
   can all learn and understand and perhaps resolve the issues at hand.

See slide deck presented by J. Gould
https://datatracker.ietf.org/meeting/115/materials/slides-115-regext-draft-ietf-regext-epp-eai-cardinality

Key issue relates to email cardinality

“If a non-ASCII email address is to be supported, there should be
provision for an all-ASCII alternative to be provided”

Three approaches (slide 4)
a. Keep Existing Cardinality (1)
b. Change of Cardinality to One or Two (ASCII or SMTPUTF8)
c. Change of Cardinality to Many (List of ASCII or SMTPUTF8)

Author recommendation:
b. Change of Cardinality to One or Two (ASCII or SMTPUTF8)
See Slide 5 for rationale

Comments from J. Klensin:

• Supports the recommendation, not necessarily the terminology
• Talking about this as "cardinality" implies just a list of
  addresses, and that misses the point.
• A list of email addresses get it closer to "mailing list"
  functionality

Comments from D. Belyavskiy

• Supports the recommendation

Comments from V. Kukhovni:

• Supports the recommendation, but does not think that the transition
  period will end soon

Comments from P. Resnick:

• Doesn't like the terminology... more about a different protocol:
  SMTP vs SMTPUTF8
• Pete in the chat: "I agree with John that thinking of an EAI address
  as a "second" email address is kind of goofy. This is a separate
  thing, that can be used when you use the SMTPUTF8 protocol instead
  of SMTP. (That is, it's a second mail protocol you're using, not a
  second email address.)"

Comments from J. Galvin:

• Should this stay in WGLC? How much discussion do we need in the WG?

Comments from J. Klensin:

• If we think about this as address per protocol (or non-ASCII address
  and fallback (ASCII) address, then it should be relatively simple.
• The cardinality approach seems harder

Comments from P. Resnick: in chat and iterated at the mic

• I think you could say that you always use what's in that field if
  you're using SMTPUTF8 and never use the ASCII email address. If you
  support the extension, then you must fill in that field, even if
  it's with an identical ASCII-only address.
• And the ASCII address MUST always be set
• If you implement the new approach... they both must be filled in
• If you implmement the old approach... only the ASCII

Comments from D. Belyavskiy:

• Quite limited set of situations... Registrar termination, individual
  name transfers,
• Can get challenging in certain situations involving transfers

Comments from J. Klensin:

• The transition period is not only about this part of the technology,
  but across the ecosystem
• The "transition" won't be over until we have, not just MUAs that are
  completely language, writing system, and script-independent, but
  users all of whom are comfortable working with all of the world's
  writing systems (present and past). Not soon.

Comments from J. Gould (in the chat)

• The existing draft can accept an ASCII or an EAI address in the
  existing fields. The difference is to be able to support an
  alternate value, where one of them must be an ASCII value during the
  transition period.

Comments from W. Staub:

• We have had a need for alternative email addresses for a long time
  (to contact registrants). Seems like this would be an opportunity to
  help this.

Comments from G. Lozano (in chat)

• Additional addresses linked to contact may have downstream effects
  on policies (gTLDs and ccTLDs). Policies usually talk about sending
  an email to the registrant, contact X or Y, and it's well-understood
  that only one email address exists for the contact. If we have
  multiple email addresses linked to a contact, which is going to be
  considered authoritative from a policy perspective.

Regarding the process of doc mgmt and next steps:

Murray K (our AD)

• This is largely up to the WG Chairs and the WG
• If the WG thinks that they have a path forward...

J. Gould has indicated that he has a revised document ready for
publication.

J. Galvin capturing action in the chat:
Clearly we have some discussion to be had about how to do what we want.
I think we have agreement on the action. Two parts.

1. Describe this as support for two email protocols, not two email
   addresses.
2. Priority should be for the non-ascii email if both are present.

There is some discussion to be had about exactly how to get number 2
covered. Concern is to make sure legacy systems work as is.

1. IP and ASN searches in RDAP (Tom Harrison, 10 minutes)
   https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-rir-search/

T. Harrison did the preso. See:
https://datatracker.ietf.org/meeting/115/materials/slides-115-regext-rdap-rir-search

Next steps:

• Request adoption
• Get input from subregional registries
• Consider extension identifier/prefix issue
• More implementations

1. RDAP for space objects and networks (Marc Blanchet, 10 minutes)
   https://datatracker.ietf.org/doc/draft-blanchet-regext-rdap-space/

M. Blachet presentation:
https://datatracker.ietf.org/meeting/115/materials/slides-115-regext-rdap-space-objects

Interesting note: SANA (Space Assigned Numbers Authority) was created
using the IANA model to provide registry services to the space community

https://sanaregistry.org

This draft uses JSContact, not jCard

General comments in chat that were supportive of pursuing the work.

1. AOB

Comment from V. Dukhovni

• Looking to put TTL into DNS provisioning commands; said he is
  starting to work with G. Brown on the topic