Minutes IETF122: rpp: Mon 06:00
minutes-122-rpp-202503170600-00

Meeting Minutes RESTful Provisioning Protocol (rpp) WG
Date and time 2025-03-17 06:00
Title Minutes IETF122: rpp: Mon 06:00
State Active
Other versions markdown
Last updated 2025-03-17

minutes-122-rpp-202503170600-00

IETF 122 - RPP

Date: Monday 17 March 2025
Time: 13:00 - 15:00 ICT (06:00 - 08:00 UTC)
Note takers: Richard Wilhelm, Caspar Schutijser

Chair slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-1-chair-slides-02

Agenda items

Administrivia [10 min]

Agenda Bashing, Blue Sheets, Note Well, etc. [5 min]

  • Agenda was bashed, we were Well-Noted, and scribes were
    press-ganged.

A word from the ADs, no slides [5 min]

Orie:

  • Thx to everyone for engaging
  • If any questions about process, just reach out to WG chairs

Working Group Business

WG Operation [10 min]

  • Tools and working group process [10 min]

    • Going to be using GitHub
    • https://github.com/ietf-wg-rpp
    • Community wiki: https://wiki.ietf.org/group/rpp
    • See chair slide 8 for more details
    • Planning on keeping the discussions on the mailing list (rather
      than discussion on github)
    • Discussion...
      • Pavel: Re: discussions and the tradeoff between github and
        mailing list. Discussions of the issue in the pull request
        was pretty good. Perhaps try it out. Re: the wiki, share
        concerns about its fluidity.
      • Scott Hollenbeck: Found it hard to follow the Charter
        discussion on github; strong proponent of the mailing list.
        According to RFC 8874, work in github has no special status.
      • Noting simultaneous comments in chat of support for mailing
        list from J. Reid, J. Gould, and Mario.

  • Deliverables / Milestones [10 min]

    • Postponed until after Architectures (see the end) b/c of
      difficulties w/ audio for Gavin

Various Updates [35 min]

  • Hackathon Recap (M. Wullink) [10 min]

    • Slides:
      https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-hackathon-rpp-01
    • Maarten provides updates from these slides
    • TL;DR: Working code for RPP domain create use case was
      functional... end-to-end; expect more at the Madrid Hackathon
      (Slides contain links to github repos)
    • Discussion:
      • J. Reid: Has any of this been written up? Maaten: not yet...
        but planning on doing so, probably on the wiki
      • Pavel: Related to this question, might discuss if time
        allows

  • CENTR Survey Insights (P. Kowalik) [10 min]

    • Slides:
      https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-epp-extensions-analysis-centr-survey-results-01
    • Pawel presented survey results related to EPP extensions using
      the above slides

    • Slide 15 has the Conclusions:

      • 2 extensions are very widely used: DNSSEC and RGP
      • 2 runners-up: launch fase and (registry) fee: under 20%
        (likely due to ccTLD bias)

    • Discussion:

      • J. Galvin: Re: Slide 9 (missing functionality) What about
        the missing feature: multiple login users/roles per
        registrar         and additional layer of authN in addition to
        user/pw (e.g. MFA)         Response: registrars would like to have
        multiple users to assign different access levels (e.g., read
        only) instead of just one account that has access to
        everything. Galvin: seems like these things wouldn't belong
        in EPP
      • J. Gould: interesting report. Hopefully the gTLDs can do a
        similar survey. Opportunities to enhance EPP.

  • EPP Extensibility & Extensions – Tiger Team Progress Update (J.
    Gould) [10 min]

    • Slides:
      https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-epp-extensibility-and-extension-analysis-update-00
    • Jim Gould presented (remotely) from the above slides
    • Tiger Team output is in this googledoc.
    • Context is that this Tiger Team got together to consider
      extension scope and requirements for RPP, given the historical
      context of the installed base of EPP extensitions.
    • If there are any additional extensions that should be analyzed,
      let the team know.
    • Discussion:
      • Andy (in chat): Seems like embedding (and extension) might
        make RPP unusable for non-domain use cases.
      • R. Wilhelm: thanks to Jim and others in the Tiger Team. Have
        not seen such a comprehensive document with all EPP
        extensions.

  • Open mic for clarifying questions [5 min]

Requirements [20 min]

  • Further Exploration + discussion (M. Wullink) [10+10 min]
    • Slides:
      https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-rpp-requirements-01
    • Maarten presented using the above slides about an approach of
      specifying requirements, and about groups of requirements to
      think about

    • Discussion:

      • J. Gould on API: in EPP, a server must validate input from
        clients. (Whereas in RDAP, it doesn't.) What should RPP do
        about partially understood messages? Maarten: Deserves
        further study.
      • P. Kowalik on Data Representation: yaml could be a future
        extension
      • J. Gould on Data Representation: as for data formats, should
        be considered separately from REST transport layer.
      • Q Missel on Data Representation: ideally one format, then
        there's no issue with mismatch between what client and
        server offers. Maarten: indeed it's possible we'll go with
        just JSON. Q: that would be my preference.
      • P. Kowalik on Data Representation: We wanted to maintain
        some flexibility for this, based on the learnings from EPP.
      • J. Reid on Data Representation: it's important to have
        flexibility w.r.t. data formats, but there should be at
        least one data format which is mandatory to support.
      • J. Reid on Discoverability: concerned about putting hooks in
        there for discovery mechanisms. Is going to overly
        complicate the protocol. Perhaps keep that out of the
        protocol, it should be in the contract between the Registry
        and the Registrar. (That is, it's policy.) Maarten: indeed,
        if there's not a clear use case we should not include it.
      • G. Brown on Discoverability: it's worth differentiating
        between discoverability of where RPP servers are located and
        functionality of the RPP server. Maarten: you are right.
      • P. Kowalik on Discoverability: Urging caution about
        overapplying the principles of hypermedia
      • J. Gould on EPP Compatibility: most important aspect is the
        data model itself. When designing EPP, we were careful with
        how the existing extensions are approached. Perhaps regext
        group can facilitate extensions to RPP (after a recharter),
        then the RPP WG does not have to work on everything.
      • C. Simmen on EPP Compatibility: Tiger Team has mentioned
        they experiences various extensions of different kinds.
        There are data extensions, procss extensions. Maybe there
        are solutions not the same for differnt types of extensions.
        I would consider research.
      • Orie on EPP Compatibility: WG is not chartered to extend
        EPP. These are two separate WGs. There is not a requirement
        for comparibility. If there is a need to coordinate or
        create something that's inspired by this WG, then take that
        over there.
      • Maarten: Yup... agreed.

      • J. Galvin on Security: re: Transfer. There is a new domain
        transfer model coming in gTLDs that doesn't use the AuthInfo
        code. Also look at a new doc in REGEXT for PKI in transfers.

        • Editor: the new ICANN Transfer Policy is available
          here. Look for text related to the Transfer
          Authorization Code"

      • J. Gould on Security: very interested what Jim has to say
        about that. We should be careful related to trying to get
        creative associated with things like authinfo code
        interoperability with EPP.

Architecture [20 min]

WG Operation (part 2)

  • Deliverables / Milestones [10 min]
    • Slides:
      https://datatracker.ietf.org/meeting/122/materials/slides-122-rpp-chair-slides-milestones-deliverables-revised-00
    • Gavin presented using the chair slides (9 onward)
    • Gavin came back and presented at the 1h 44m mark in the meeting
    • Gavin's slides had the addl milestone of "WG consense on
      Requirements" as Sep 2025"
    • Discussion:
      • J. Gould: suggesting to target IETF 124 (November) for
        requirements; thinks we're going to need more time
      • M. Wullink: not quite sure about core architecture and other
        documents and their timelines. Probably need to work on them
        simultaniosly and see if they work together. Gavin: they are
        not deadlines fixed in stone. We need to measure progress.
      • P. Kowalik: milestones are ambitious but we should keep
        them.
      • J. Reid: the timeline looks reasonable to me. We should
        first deal with the requirements.
      • R. Wilhelm: agree with Jim on the requirements. Perhaps a
        couple of interim meetings would help.
      • M. Wullink: responding to J. Reid re. working on
        requirements before architecture: I understand, but don't
        want to exclude working on architecture. Thinking about
        architecture will help us think and potentially change
        requirements.

Time permitting [5 min]

AOB [2 min]

Now wrapping up (on time)... Gavin expresses his thanks to all involved.