Minutes IETF121: rpp: Wed 09:30
minutes-121-rpp-202411060930-00

RPP BOF - IETF 121 - 2024-11-06 - Dublin

RESTful Provisioning Protocol
BoF
IETF 121 Dublin, IE
Wednesday: 6 November 2024 09:30-11:30 UTC

Co-chairs: Darrel Miller, Andy Newton
Mailing list: rpp@ietf.org

1. Welcome - Chairs (10 min)

   • Greetings

   • Note Takers
     ^

   • Rick Wilhelm

   • Others??
     • Note Well
   • Noted by Andy
     • Note Really Well
   • Also noted by Andy
     • History and BoF Purpose

Chair slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-introduction-and-agenda-slides-02

Chairs slides included the proposed time allocation.

Andy reviewed Chair slides 6-8 in detail regarding history and BoF
purpose. No questions.

1. EPP and ICANN - Gavin Brown (10 min)
   A presentation on the current state of EPP and
   contractual obligations under ICANN.

Gavin's slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-background-on-epp-icann-00

Gavin reviewed these slides.

Key points (from the Agenda slide):

• A description of the Extensible Provisioning Protocol (EPP) for the
  uninitiated.
• The role of EPP in the generic TLD namespace.
• How a new provisioning protocol might be deployed in the gTLD
  namespace.

Relevant docs includee STD 69, et al.

Q&A:

Rick Wilhelm: raised the point about the ICANN Fast Track RSEP process.
Gavin elaborated on the new process being discussed around the next
round of gTLDs.

Jim Gould: Suggested that the Fast Track have an 'experimental' status

1. RPP Motivations And Current Work - Pawel Kowolik (20 min)
   This presentation will cover the motivations for a RESTful
   provisioning protocol, and cover the current work in this area.

Pawel's slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-ietf-121-rpp-bof-motivation-current-work-in-the-area-01

Pawel reviewed slides.

Perhaps a key point: (see slide 25)

• RPPs-like APIs are being created and used - so this is what people
  seem to want more. Starting the work on RPP now will limit future
  fragmentation

No questions at the mic.

1. Technical Choices - Timo Vohmar (10 min)
   This presentation will describe the choices made in using a
   RESTful protocol for domain provisioning in .ee.

Timo's slides:

https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-restful-epp-ee-00

Timo reviewed slides (presented remotely).

Notable tidbit: .EE has been using REST API since 2014.

Link from slides: https://internetee.github.io/repp-apidoc

Clarification of "proprietary" point on slide 2: EPP is "unknown outside
the domain industry"

(some discussion in the chat about the level of structure between XML
and JSON, and the familiarity of "newer" programmers with XML)

No questions at the mic. Interesting comment from Gavin in the chat: XML
schemas make it very easy to identify what's wrong with a particular XML
instance. In my experience JSON Schema implementations are very lacking
in many programming languages

Darrel added: JSON Schema implementations have improved over recent
years. The primary challenge is which draft of JSON Schema they support.
Decent ones are available in most languages.

1. Drafts and Requirements - Maarten Wullink (20 min)
   A discussion of the requirements for RPP and current drafts.
   Requirements:
   https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/requirements.md

   Draft: https://datatracker.ietf.org/doc/draft-wullink-rpp-json/

Maarten's slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-rpp-drafts-requirements-01

Maarten reviewed the slides.

Included examples of tradeoffs of implementation styles.

Temporary requirements doc; to be moved to WG wiki:
https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/requirements.md

Q&A:

Rick Wilhelm: Suggested that Transition be part of the requirements.

Jim Gould:

• Best to map, rather than convert EPP
• AuthN would need to be further investigated, especially involving
  MFA
• RPP doesn't need to maintain EPP compatibility
• Important to learn from EPP, especially related to the extension
  points.
• Everything should be an extension: Domain, host, and contact should
  be an extension, like in EPP.
  • Maarten: Agree with everything, but not sure about the last
    point about everything being an extension. Certainly agree that
    we need to change.

1. Charter Discussion - Chairs (40 min)
   A discussion of the charter for a potential working group.
   Proposed charter in github:
   https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/rpp-charter.md

Charter slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-rpp-charter-discussion-slides-00

Andy led the Charter discussion.

Reviewed the Charter Slides (see above).

Discussion:

Murray Kucherawy: Why is this "not a replacement for EPP"?

• Andy: EPP is still going to be used for the foreseeable future
• Murray: If not a replacement: who is going to keep them in sync? Not
  objecting... but want to make sure that we're not ignoring the
  problem of reconciliation

Jim Gould: Don't think that we need to keep them in sync. Think that
there should be an effort to try. But I noticed that we haven't
mentioned the RIRs.

Jasdip: We are paying attention to this. Historically, we haven't used a
provisioning API, due to scale considerations.

Paul Hoffman: It's not a replacement for EPP b/c EPP isn't used
everywhere. The question of replacement is if the IETF says that EPP
shouldn't be used. There would be coexistance.

Murray: These are two closely related things. How do we develop them in
parallel?

• Coordination with REGEXT is helpful

Robert Sparks: If we charter a group and it creates a protocol, is it
required to make sure that it's a superset of EPP?

• Darrel: there has been an expressed desire of not being a superset
• Robert: is there an expressed desire to have it be an exact set of
  operations? (No) Seems like there is just a communication challenge
  to be solved, not a technical coordination.

Pawel: To address this: Perhaps there is an EPP Compatibility Profile,
to provide clarity.

Jim Reid: The draft charter looks good. Coordination is not likely a
practical problem b/c the same people are going to be involved in both
working groups.

Jody Kolker: As a Registrar, this does belong in the IETF because a
registrar wants to see this standardized. Also, RRP needs to be a
superset; we can't lose functionality.

Jim Galvin: As one of the REGEXT co-chairs: Trying to understand, what
is different than EPP. As long as this is not changing EPP, then it
should be in REGEXT. If we have two groups, then it's competing with
REGEXT. Second comment: From a technical point of view, trying to decide
if this is more than just changing transport. At least half of our
industry uses EPP and is mandated to support it. One's ability to adopt
this is constrained in half the industry. Concerned the the IETF would
propose something that is going to be unimplemtable.

Rick Wilhelm: Supportive of the idea but please include Transition.
Important for eventual adoption. A new protocol is important for the
next 20 years of growth of domains because it could open up the
ecosystem for new entrants.

Antoin: Supportive of the idea. A few reservations of the goals. We did
EPP with the goal of consolidation and standardization. The charter is
missing the goal of generic provisioning.

Merike Kao: Supportive of the work. Always better to have something
standardized.

Werner Staub: Would like to have indirect provisioning added.

Paul Hoffman: Instead of being 'more generic', listing known use cases
in the charter would be helpful. Also: a different connection model is
quite different than a different transport.

Pawel: Important that the new protocol is not constrained by EPP.

Maarten: Response to Antoin: Charter text contains this... but will work
to expand.

1. BoF Questions - Chairs (10 min)

ANDY/DARREL: Pls double-check the numbers, but I think that they are
accurate.

• Who has read the charter?

  • Yes: 26
  • No: 8
  • No Opinion: 1

• Is this is problem that needs solving?

  • Yes: 30
  • No: 0
  • No opinion: 9

• Is the IETF the right place to solve it?

  • Yes: 34
  • No: 0
  • No opinion: 5

• Does the charter describe the motivation as presented?

  • Yes: 25
  • No: 1
  • No opinion: 12

• Does the charter reasonably scope the work?

  • Yes: 16
  • No: 3
  • No opinion: 18

• Does the charter describe the deliverables?

  • Yes: 17
  • No: 1
  • No opinion: 17

• Do we have enough people and the right people to work on thies
  problem in the IETF?

  • Yes: 26
  • No: 3
  • No Opinion: 9

Chairs invited comments:

• Murray: If you have concerns with charter, pls sent text
• Galvin: Concerned about the relationship between this WG and REGEXT
• Antoin: Same
• Gould: Will send text
• Gavin: Concerns about what the impact there will be on REGEXT
• Galvin: I worry more about REGEXT losing people than about RPP
  losing people. Am concerned about the scope: is it provisioning or a
  connection model on top of EPP. Don't think it's clearly answered in
  current charter
• Maarten: REGEXT is a small group; RPP will likely also be a small
  group. But a lot of interested in ccTLDs, especially the CENTR
  group.
• Gould: Perhaps underestimating the amount of work that is in front
  of us. We also don't have many registrars. That could make it
  challenging to create something for the entire ecosystem.
• Pawel: There are others that can/will participate

1. Conclusions and Next Steps - Chairs + AD.

Orie: Thanking all involved. Will be reviewing the Charter. Please come
to me with any input.