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

[Pawel Kowalik <[e-mail]>]

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
>       o a read-only view (that needs authenticated access or not,
>         depending on the use case)
>       o 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]
> 0xD9D50D8A
>
> _______________________________________________
> rpp mailing list [e-mail]
> To unsubscribe send an email [e-mail]