[rpp] Re: Why the limit to RMM level 2?

[Maarten Wullink <[e-mail]>]

It was also understood by me (anecdotal evidence through blogs) that the use of true RMM level 3 was not that common, but i could be wrong here.
Anyway, the use of RMM3 might be redundant when all API endpoints are already known and described in IETF document(s)

Pawel already mentioned this, but we do intend to allow the clients to take advantage of discoverability features.

any help or suggestions on how to improve RPP design in this area are very much welcome.

-
Maarten


Op 24 feb 2026, om 18:38 heeft Pawel Kowalik <kowalik=[e-mail]> het volgende geschreven:


Hi Pierre,

We didn't put level 3 as requirement or ambition basically because of split opinions in the WG about usefulness of those mechanisms for a provisioning protocol.
I am convinced however, that some of these mechanism would be useful. On the other end a provisioning protocol does not necessarily have to drive application
state in a way unpredictable to the client and the clients rarely have a need to follow breadcrumbs of path they don't know. Just the opposite - the clients need
to know business logic of the server (registry) to know what payloads and parameters they have to provide in the requests.
Here the WG opted also for strict handling of data validation, so a more coupled design between clients and servers is to be expected.

However, there is a great bit of discoverability capabilities already in architecture and in design.

We have already an almost ready updated text about discoverability in the architecture document:
https://github.com/ietf-wg-rpp/RPP-architecture/blob/f94960bc14f12da944238d58ab430b32c886a27a/draft-ietf-rpp-architecture-01.adoc#5121-definition-of-special-resources

This will be released with -01 prior to IETF 125.

When working on a new version of rpp-core document Maarten started some design work on Discovery documents, but this is still on an early stage, so likely won't make it into the version we plan to release prior to IETF 125.

If you are interested to participate in the review/discussion, here the PR:
https://github.com/SIDN/ietf-rpp-core/pull/36/changes

Kind Regards,
Pawel

On 24.02.26 14:06, Pierre Thierry wrote:

Hi,

I started reading the RPP RFCs and as there already is a good level of discoverability in the requirements, I was wondering why the level 2 of the Richardson Maturity Model was set as a requirement instead of fully adhering to REST and using State Transfers in Representations?

As a concrete example, in RPP Core, message deletion goes through the hard-coded but relative URI of "/messages/{id}", but the response message for message polling could as well contain a "deletion" link.

Section 3.2 from RFC 9205 lists a few advantages of that approach.

I'll note that fully using REST would also accomodate some exisiting requirements better than stopping at RMM L2:

  *   R9.11/R10.1: representational state transfers make it possible for the RPP server to present links to attenuated facets of the provisioning objects
     *   a read-only view (that needs authenticated access or not, depending on the use case)
     *   a link to a provisioning process that has single-use confirm/abort links
  *   R10.1/R10.2: when collections and object operations are provided as representational state transfers, a generic RPP UI can present new data elements, new object types and even some new operations to some extent, even without prior knowledge

Curiously,
Pierre Thierry
--

[e-mail]<mailto:[e-mail]>
0xD9D50D8A



_______________________________________________
rpp mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


_______________________________________________
rpp mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]