Minutes IETF115: regext: Thu 17:00
minutes-115-regext-202211101700-00

Meeting Minutes Registration Protocols Extensions (regext) WG
Date and time 2022-11-10 17:00
Title Minutes IETF115: regext: Thu 17:00
State Active
Other versions markdown
Last updated 2022-11-11

minutes-115-regext-202211101700-00

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)

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)

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

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