Minutes
Previous notes are here: https://notes.ietf.org/notes-ietf-123-rpp
Date: Thu 06 Nov 2025
Time: 09:30 - 11:00 EST (14:30 - 16:00 UTC)
Note takers: Caspar Schutijser, Pawel Kowalik (helping), Christian
Simmen (helping)
Administrivia
- 'Blue Sheets', Note Well, Note Taker, Agenda Bashing [5 min]
- Notes:
- Marco starts the meeting, Gavin presents the agenda.
- Gavin asks WG to pay special attention to the requirements
document which shall reach WG consensus in the coming month
according to the milestones, do not wait till WG LC
Working Group Business
Various Updates [20 min]
-
Hackathon Recap (M. Wullink) [5 min]
-
Final recommendations from the EPP Extensibility and Extension Tiger
Team (E. Skoglund) [10 min]
-
Open mic for clarifying questions/discussion [5 min]
- Pawel stated that most recommendations were already part of the
requirements. Missing ones were added as reuirements. One
section went missing and will be added shortly after 124
meeting.
- James Gould: this work was very enlightning. This work should be
done periodically for any protocol.
- Scott Hollenbeck: these are reasonable recommendations. We
should do something to get them accepted as work items if
possible.
Deliverables / Milestones; current status and active documents [30 min]
-
I-D: draft-ietf-rpp-requirements-02 delta from -01 (M. Wullink) [10
min]
- [Slides]
https://datatracker.ietf.org/meeting/124/materials/slides-124-rpp-rpp-requirements-01
- Authors feel like the draft is in good shape. Appreciate
feedback from the group so that progress can be made.
-
Presents resolved issues based on feedback from IETF 123.
- Difficult issue: client data omission is still open. Right
now leaning towards that direct support is maybe not the
goal, but a design principle of having as many fields as
possible "optional" and profile setting what is required
would enable this use case
- MUST support profiles is also still open, we need input
from the WG for these two.
-
Presents other updates in version -02.
-
Next steps:
-
Question James Gould: excellent work. Commits to going through
document and provide feedback. Should be careful with the
normative language like "MUST". And we need to consider scope of
the protocol. Saw "search" in there, but it's a provisioning
protocol. Perhaps that should be a different protocol.
- Maarten: thanks for taking the time to look into it.
Regarding "search": we're not reinventing EPP so we could
add stuff that is not part of EPP. We can discuss.
-
Question Cristian Simmen: profiles are a solution to something
we really want, which is to signal capabilities.
- Maarten: agree that's something we need. If you have a
proposal, please submit a pull request.
-
I-D: draft-kowalik-rpp-architecture-03 delta from -02 (P. Kowalik),
[5 min]
-
I-D: draft-wullink-rpp-core-03 delta from -01 and discussion (M.
Wullink), [10 min]
- [Slides]
https://datatracker.ietf.org/meeting/124/materials/slides-124-rpp-rpp-core-01
- Requirements are not finished yet but that didn't stop us from
looking into potential solutions. It's a work-in-progress
- Presents document updates.
- RPP-Code Header: backwards compatible with EPP result code,
allow for adding RPP-specific result codes
- RPP-Authorization Header
- Process
- Check for Availability: new
/availability resource
- Problem Detail (RFC 9457)
-
Next steps:
- Aligh current work with requirements, need concensus on
requirements
- Incorporating Tiger Team recommendations
- Request for adoption
-
Question James Gould: I like the idea of existing EPP result
codes and adding a prefix. Did you consider creating an IANA
registry of the codes?
- Maarten: did not consider that yet. It's an option, we can
do that. Currently they're not in an IANA registry yet?
- James: XML enumerations.
- Maarten: hard to extend.
- James: would be careful with mow many places you leverage
HTTP headers, but also good to see what our best practices
in the industry are.
- Maarten: we'd like to reuse work in HTTP not to reinvent the
wheel.
-
Question Pawel: question to EPP experts in the room: what we
modeled here (slide 7) is an array of errors. Is not in standard
RFC 9457. Do we need multiple codes?
- James Gould: I completely forgot about that. I'll look into
that.
- Jody Kolker: multiple error codes are fine, as long as we're
able to parse through them.
- James Gould: I thought what you said is what is most
important is to see success and error. (Something about log
files.)
- Jody: we'd definitely look at log files to see what's wrong.
- Maarten: I'm not sure if having multiple errors is useful,
for example if you have 2 errors, the second one might
depend on the first one and if you fix the first one, the
second one might change.
- James: instead of having them as a list, maybe a primary and
some additional detailed ones.
- Maarten: should we have this as a backwards compatible thing
for EPP or not?
- Gavin: I want to suggest maybe there's someone in the Tiger
Team could feedback on.
-
Open mic for clarifying questions/discussion [5 min]
- (No questions or comments.)
For consideration [25 min]
AOB/closing [10 min]
- AOB [9 min]
- Werner Staub: status of information that we have and having
proof that it is true (registrant of domain name is such and
such). Would be good to have a way to express in data model to
see whether a fact is true and has been verified. Some people
have a need for this.
- Pawel Kowalik: Data Object draft foresees extensibility. If
contact object is described, it would be relatively easy to
extend it with additional information like verification
information.