Minutes IETF120: regext: Tue 00:30
minutes-120-regext-202407230030-00

Meeting Minutes Registration Protocols Extensions (regext) WG
Date and time 2024-07-23 00:30
Title Minutes IETF120: regext: Tue 00:30
State Active
Other versions markdown
Last updated 2024-07-29

minutes-120-regext-202407230030-00

Registration Protocols Extensions (REGEXT)
IETF 120 Vancouver, CA / Online

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

Monday, 22 July 2024, 17:30-18:30 Georgia B
https://meetings.conf.meetecho.com/ietf120/?session=33206

Wednesday, 24 July 2024, 13:00-15:00 Plaza B
https://meetings.conf.meetecho.com/ietf120/?session=33166

Monday, 22 July 2024, 17:30-18:30 Georgia B
https://meetings.conf.meetecho.com/ietf120/?session=33206

  1. Welcome and Introductions (3 minutes)
    i. NOTE WELL
    ii. Notes scribe

    • Rick Wilhelm (and others)
      iii.Document management

  2. Published (3 minutes)

https://datatracker.ietf.org/doc/rfc9536/
Registration Data Access Protocol (RDAP) Reverse Search

https://datatracker.ietf.org/doc/rfc9537/
Redacted Fields in the Registration Data Access Protocol (RDAP)
Response

https://datatracker.ietf.org/doc/rfc9560/
Federated Authentication for the Registration Data Access Protocol
(RDAP) Using OpenID Connect

Briefly reviewed by Jim Galvin

  1. RFC Ed Queue

Nothing currently in the Ed Queue

  1. Submitted to IESG (1 minute)

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/ Extensible
Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values

In review with AD and will soon be with IESG

  1. Past WG last call (1 minute)

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/
Best Practices for Deletion of Domain and Host Objects in the Extensible
Provisioning Protocol (EPP)

Waiting for Doc Shepherd write-up and then onward.

  1. In WG Last Call (2 minutes)

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/
An RDAP Extension for Geofeed Data

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/
RDAP RIR Search

These are out on the mailing list. Last Call expected to close next
Friday. (~August 2)

  1. Related work (5 minutes)

https://datatracker.ietf.org/doc/draft-albanna-regext-rdap-deleg/
RDAP Extension for DNS DELEG

https://datatracker.ietf.org/doc/draft-brown-epp-deleg/
Extensible Provisioning Protocol (EPP) mapping for DELEG records

DELEG WG met earlier today (July 22). See slide for notes. Pasting here:

● DELEG working group
○ https://datatracker.ietf.org/group/deleg/about/
○ The DNS protocol has limited ability for authoritative servers to
signal their capabilities to
recursive resolvers. In part, this stems from the lack of a mechanism
for parents (often registries) to specify additional information about
child delegations (often registrants) beyond NS, DS, and glue records.
Further complicating matters is the similar lack of a mechanism for a
registrant to signal that the operation of a delegation point is being
outsourced to a different operator, leaving a challenge when operators
need to update parental information that is only in the control of the
child. Data is often out of synchronization between parents and
children, which causes significant operational problems.
● https://datatracker.ietf.org/doc/draft-albanna-regext-rdap-deleg/ ○
RDAP Extension for DNS DELEG
● https://datatracker.ietf.org/doc/draft-brown-epp-deleg/
○ Extensible Provisioning Protocol (EPP) mapping for DELEG records

Jim Reid: Expectation is that the Requirements Draft should be ready for
IETF 121 (Dublin). Might be a new RR Type, but might be other solutions.

Tale Lawrence: Current proposals based on a parent-based solutions.
Another option being considered is a non-parent-based solution, which
would result in other approach. See Willem Toorop's talk in DELEG.

Jim Galvin: See also the informational preso I gave to DELEG.

Jim Gould: Assuming those drafts are not ready for implementation work?
(Most in the room agreed)

  1. REGEXT Implementations Required (20 minutes)

https://datatracker.ietf.org/doc/slides-120-regext-regext-implementations-required/

REGEXT Implementations Required

Andy Newton presented the above slides. And now discussion.

Scott Hollenbeck:

  • Risk of breakage in Routing is a lot higher than in RDAP or EPP. Bar
    should be higher there.
  • We've been stalemated on a couple of topics; perhaps it makes more
    sense to publish as Experimental
  • As a small group, it can become hard to get a measure of consensus;
    not sure how this solves that process
  • Given the size of the group, we're more heavily weighted toward
    server-side implementers; we can have issues if we don't get
    client-side implementers

Peter Koch:

  • This rule has been area-wide (as Scott noted)
  • For the routing protocols, they are independent; are these going to
    be independent implementation?
  • Implementation is one thing, but in this space, there is a
    siginficant overlap with policy topics. Willing to implement is one
    thing, but willing/able to deploy is another

James Gould:

  • Does not support.
  • Would be better to encourage more support -- and earlier;
  • Experimental actually discourages participation

Jody Kolker:

  • Does not support.
  • Concerned about how many people who will be able to do the draft and
    who will be doing implementation
  • Can one person do both client and server?

Richard Wilhelm:

  • Does not support
  • We need to be promoting RDAP adoption and growing the client side,
    not making it harder for people to be getting their RDAP extensions
    into production

Jasdip Singh

  • Interesting discussion. Should be helping to grow the ecosystem.
    Client implementers should not be surprised.

Jim Galvin:

  • The IANA registries are first-come, first-served, so people don't
    have to go through the IETF

(As chair)

  • Judging the quality of a particular proposed extension is
    challenging, because sometimes the utility is limited. Should we
    require anyone to implement them?

Scott Hollenbeck

  • I very much like the idea of using the Wiki of documenting the
    implementation experience

  • We have always had the ability to consider documents on-the-fly; so
    we can always just publish that document as Experimental to break
    the logjam

Jim Gould

  • It would be useful for client and server implementers to be captured
    on the wiki

Pawel Kowalik

  • Supporting the idea of the wiki

Rick Wilhelm

  • +1 to Jim Galvin's comment about the targeted utility of extensions
    in general

Jim Galvin (after wrapping the discussion)

  • Not sensing consensus in changing our process, but we might require
    implementations from time-to-time
  • Please review the documents
  • Make use of the wiki!
  • We have a process issue about what to do about stalemates. Maybe we
    can use Experimental as a way to get past stalemates? Something to
    consider. Want to be cautious. There are other options:
    Informational, not Working Group process.

AOB

Wednesday, 24 July 2024, 13:00-15:00 Plaza B
https://meetings.conf.meetecho.com/ietf120/?session=33166

Meeting began at 1:01 PDT with Jim Galvin chairing.

Recording may indicate that at the meeting start there was something
that sounded quite like a jackhammer that was quite notiable in the
meeting room.

Jim noted the Note Well, etc.

Chair slides for Wed:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-chair-slides-wednesday

  1. Existing work (15 minutes)

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
Remanded back to WG for resolution

  • Orie: Supporting continued work; sorry that we had to hand it back
    to the WG; thx to chairs and authors for their work

  • Galvin:

    • New draft is soon-to-be available, which takes a different,
      perhaps simpler approach; seems like it will pass previous IETF
      Last Call concerns.
    • There is the option that the WG could take a 3rd option of just
      stopping work on this. Seems like perhaps not the best option
    • Two doc teams are now working together
    • Expecting that the two docs will be reconciled and available in
      the next few weeks

  • Jim Gould: Supportive of the approach of waiting on the new draft

  • Scott Hollenbeck: (one of the authors of the new draft) Current
    draft implicitly updated RFC 5733 and other extensions that include
    email adresses. The goal of this was to leave RFC 5733 alone and
    simplify the extension so that it carries one addl email addr and
    (essentially a flag of the email addr being primary or secondary).
    Please speak up if you have any concerns on this approach.
  • Galvin: This simplified version seeks to be very sure that nothing
    updates RFC 5733
  • Edmon Chung: This is an important feature; glad to see this move
    forward
  • Q. Misell: Supportive. What if the only email addr available is
    UTF-8?
  • Galvin: That's currently an open question. The new doc will get a
    full discussion in the WG
  • Pete Resnick: If you only have an EAI addr, you are going to need
    other mechanisms to get consistent email delivery.

Galvin: Sense of the room: people would like to see the rewrite and we
will go from there.

Orie: Please confirm on the list.
Galvin: Agreed

  1. Potential New Work

i. DomainConnect Update - Pawel Kowalek (10 minutes)

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-domain-connect-update

Pawel presented slides.

Q&A:

  • Hollenbeck: Supportive. Where is the right place? Not sure there
    there is a better place than REGEXT.
  • Q. Misell: Agree that this is difficult to place. This is the better
    place. Extension to DNS configuration. Technical point: would be
    good to allow HTTP POST requests (rather than just HTTP GET)
  • Hans-Jorg Happel: Important work for people who want to move
    services between providers.
  • Jim Reid: Good idea to do it here, rather than DNSOP. This is a
    rather self-contained project. IT will get to the DNS Directorate
    regardless
  • Jim Gould: Impressed with the level of adoption. Not sure if this is
    the right spot.
  • Rick Wilhelm: Supportive. This is a better solution than a number of
    other ways that DNS data can get updated, like polling, etc.
  • Suzanne Woolf: As DNSOP Co-Chair, in DNSOps, we can have people take
    a look at the draft. The Chairs and discuss with ADs

Galvin: sense of the room is support, we'll take to mailing list and
talk to ADs

See also: https://www.domainconnect.org

ii. RESTful EPP - Maarten Wullink (10 minutes)

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-restful-epp-status

Side Meeting: Thursday, Tennyson 1300-1400

Maarten presented slides:

Q&A

  • Q. Misell: don't think it's an extension. Seems like it's a
    reimplementation. Seems like it's this WG. Prefers XML over JSON.
    Would like simple mapping of XML to HTTP.

Galvin: is this just a different transport or a different data model? If
it's competitive to EPP, then that's a different issue, because those
are standards. Then they should probably be Experimental (because EPP is
Standard). So the question is: Is this EPP or not?

  • Jim Gould: Seems like this is different provisioning protocol.

  • Jim Reid: There should be enough room in the WG to avoid
    rechartering.

  • Pawel Kowalik: Should move forward.

  • Pete ResnicK: Chartering a new WG gives you the ability to open up
    things and the flexibilty to start with the clean slate.

Galvin: Suggesting that we not focus too much on the charter.

  • Andy Newton: Agree with Pete... Rechartering would be better. We
    need new entrants in the markets. We can have many provisioning
    protocols.

  • Rick Wilhelm: Perhaps just take a smaller solution of keep XML and
    swap out TLS and move to HTTPS.

  • Pawel: Consider making sure that the data model doesn't change. The
    stability of the data structure is important

  • Scott Hollenbeck: Re: conformance of data structures. Would like the
    schema to be compatible such that existing parsers can handle it.
    Also consider who is maintaining state (client or server)

  • Orie Steele (our AD): Lots of interest, would need to recharter.
    Perhaps need to separate the maintenance work from new work?

Will discuss on the list. See also Side Meeting.

iii. RDAP Considerations - Andy Newton (20 minutes)

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-considerations-on-rfc-9537

Andy presented slides

Q&A:

  • Galvin: Did you see Jody's note on the list. In that his team
    created an implementation in just a few hours.

    • Andy: no; hadn't seen that

  • Scott Hollenbeck: what about the possibiity of a "bis" draft, even

    • Andy: open to that

  • Tom Harrison: Generally supportive of letting this run. RIPE are
    relying on this. It seems premature to say that JSON path
    implementations won't get better. Whatever replaces this, can't be
    string-replace fields. That will break existing clients.

  • Jim Gould: Creating a bis draft; but we should wait on that. Also,
    we spent 2.5 years on this draft; including making the path
    expressions optional.

  • Jody Kolker: They did a server implementation. Also: the examples
    are a little strange because the types weren't in the IANA registry
    yet. One more thing: we're trying to make this into a text version.
    Seems like we know where things are; we don't need to know exactly
    where it is.

    • Andy: That's doable, but it's not very flexible for smaller
      registries.
    • Jody: If you're doing a client that's supposed to display all
      the info, you'll need to keep the code updated.
    • (Further discussion on this)

  • Jasdip Singh: I appreciate the generic client's view point; there
    are few generic client's viewpoint. Generally redaction is in
    situ    , but I think that clients would appreciate that accuracy
    pin-pointed. Making JSONpath optional does not fix the problems.

  • Pawel Kowalik: It's useful for data that has been redacted in place,
    it can be useful.
  • Rick Wilhelm: There really isn't a sequence in RDAP responses, so
    in situ doesn't quite apply.

Jim Galvin: Moving this to the mailing list

iv. Contact Object Discussion - multiple people (30 minutes)

Galvin presenting these slides:

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-contact-object-discussion

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
Using JSContact in Registration Data Access Protocol (RDAP) JSON
Responses

EPP Contact Object in XML

"Simple Contact"

Galvin:

  • Suggestion: jsContact to Experimental?
  • Andy: jsContact would be more interesting if it removed sigalling
    and transition
  • Pawel: jsContact would be good to narrow down and proceed.

v. Version, Signal, Transition Discussion

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-version-signal-transition-discussion

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

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

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/
An RDAP With Extensions Media Type

Galvin:

  • See Jim Gould's post to list July 22, which is a good summary of the
    issues.

Pasting here:
I believe we’ve discussed the problem being solved by the draft’s
multiple times. To be clear, these are the problems that I see the
drafts solving:

draft-ietf-regext-rdap-versioning – While progressing the most recent
RDAP extensions it was agreed that there was no formal versioning in
RDAP other than what is referred to as opaque versioning.
draft-ietf-regext-rdap-versioning provides for extensible versioning in
RDAP, with support for the server to provide versioning information to
the client in the help and the query responses and support the
capability for the client to provide the hint of the desired extension
versions in the query. There is built-in support for Opaque Versioning
and Semantic Versioning and there is support for the client to provide
the hint of the desired extension versions using a query parameter or
using draft-ietf-regext-rdap-x-media-type.

draft-ietf-regext-rdap-x-media-type – Andy and Jasdip can provide a
better description, but my take is that
draft-ietf-regext-rdap-x-media-type enables a client to provide the hint
of the desired extensions using an HTTP header, which survives
redirects.

draft-ietf-regext-rdap-extensions – Based on the large volume of
discussion on the mailing list related to extension identifiers, it was
clear that guidance was needed for RDAP extensions, which I believe is
the purpose of draft-ietf-regext-rdap-extensions. I see this draft as
meeting the need that RFC 3735 does for EPP, so we can really consider
many areas of RDAP extension guidance in this draft. Again, Andy and
Jasdip can provide the authoritative description for this draft.

  • We (simply) need to sort through the issues and advance the work
  • Andy Newton: Agree that versioning and media type need to be
    compatible; not sure if they need to be merged
  • Scott Hollenbeck: See value in all three of these. Agree that we
    need an RDAP equivalent of RFC 3735 on extensions
  • Jim Gould: I see a path for all three. Good point by Scott on RFC
    1. Versioning and X-Media could, but don't need to be merged.
  • Pawel: Slightly disagree that there is no overlap. Would rather like
    to see them merged. Due to their overlap on signalling.
  • Jim Gould: An update was made to the Versioning draft to include
    support for signaling via query parameter as well as X-Media

Galvin: We certainly need to make sure that these are compatible. Doc
authors need to press things going forward on the mailing list.

vi. IDN Variants - Jim Galvin (30 minutes)

Slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-idn-variants-discussion

Galvin:

  • There was a joint meeting with ICANN TechOps to expose more people
    related to the proposal and issues related to IDN Variants
  • There is a doc that is being worked on that is targed to be
    published related to extensions to both EPP and RDAP.

Jim Reid: Will this have a clear indication of the problem statement.

  • Galvin: Yes, the key issue is that you have to deal with domain
    names as a set.

AOB

Orie: Thanks to everyone for a great meeting.