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

[Pawel Kowalik <[e-mail]>]

Hi Pierre,

On 26.02.26 21:54, Pierre Thierry wrote:
> Le 24/02/2026 à 18:38, Pawel Kowalik a écrit :
>>
>> 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.
>>
> Sadly, REST is not the norm and it creates a chicken-and-egg problem 
> to adopt it more, when its usefulness is not absolutely obvious.
Yes, but here I am sure we've spent enough of time deliberating that - 
the discussion started already with WG charter. You may browse through 
archives if you like to see what happened.
Only clarification on the terminology. REST (or RESTful) ist not equal 
RMM level 3. Even Level 0 would have been REST, but level 2 is the 
minimum to align with BCP 56, so the consensus was to aim for that.
>>
>> 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.
>>
> My prior probability on these things is 10:1 odds that people didn't 
> anticipate how the server could usefully drive the client with logic 
> that can evolve just server-side.
>
We do, but no flexibility comes without a cost. The benefits have to 
overweight this cost. We decided not to spend time on this upfront in a 
classical waterfall approach when we will fight over it in requirements 
and not touch a line of code.
We were always progressing with RPP over hackathons and code experiments 
and we want to keep on this track. That's why, after having reached 
consensus on the requirements, we push hard to make progress on design 
documents (architecture, core, data objects, dns and json 
representation) to be able to try out things on a certain baseline. A 
lot of updates coming with IETF 125.
>
> But I guess the prior experience with EPP gives you a good expectation 
> of what could evolve or not and the impact on the client-server 
> contract for those.
>
True that.
>
> Wouldn't REST still be useful when it comes to provide attenuated 
> access? For example, redirecting users to a different server for 
> read-only access or even on different servers depending on the 
> sensitivity of objects or actions can make the job of security audits 
> easier. Also, REST makes it possible to decide for a sharding strategy 
> later in a server's life.
>
In RMM 3 this is benefit and the cost same time. Spreading resources 
over dynamically assigned URLs sounds great, same time it pulls quite a 
load of issues to solve - like authorisation, when the resources 
(theoretically) span over different authorities, or unpredictability 
that the client hast to be able to deal with.
I am open to experiment with stuff - don't get me wrong. We even have 
such elements in the architecture already (see 
https://github.com/ietf-wg-rpp/RPP-architecture/blob/main/draft-ietf-rpp-architecture-00.adoc#asynchronous-operation-processing)
This should not make RMM 3 as a guiding principle for whatever price.

>> Here the WG opted also for strict handling of data validation, so a 
>> more coupled design between clients and servers is to be expected.
>>
> Is this aspect documented somewhere?
R4.6 in the requirements
>>
>> If you are interested to participate in the review/discussion, here 
>> the PR:
>> https://github.com/SIDN/ietf-rpp-core/pull/36/changes
>>
> Thanks! I'll start reading the PR.

This is now merged into the version that will be released prior to 
IETF125. We appreciate reviews a lot - not only on this document. 
Especially from REST practitioners.

Kind Regards,
Pawel