From: Maarten Wullink <maarten.wullink@sidn.nl>
To: Pawel Kowalik <kowalik=40denic.de@dmarc.ietf.org>
Thread-Topic: [rpp] Why the limit to RMM level 2?
Thread-Index: AQHcpjNc+208rMOfs0yyz6Dwo9W+jg==
Date: Wed, 25 Feb 2026 08:47:23 +0000
Message-ID: <15AA0546-704A-4486-8CA1-2111932167E4@sidn.nl>
References: <5835bb17-790d-4606-83fa-e8eacadf0ac3@nothos.net>
 <03429da4-33e2-4105-bc39-9b63b632800c@denic.de>
In-Reply-To: <03429da4-33e2-4105-bc39-9b63b632800c@denic.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?wQK5qo0EH3ZeB7PTUwrs8yM76L2yNEnUVcEUN0ylFZa7SIuyz1DoOOPUbhbd?=
 =?us-ascii?Q?CcFs+Ua/KEih1pO+PKB4/A1EZzAuzQawOy31GX1/6QxZo4ejxgoRymsaE0AD?=
 =?us-ascii?Q?ZRMjEW8n8Q7Tzt99BxpszticNvdBZDqvKGPPrAG/baoWmkI3g+4gt9EXFYx0?=
 =?us-ascii?Q?njms99ZvqNd2v9Uwogs+qSg+0/8hkWVzKcfrv6mChIiYpVnkCby/qFwW3JLB?=
 =?us-ascii?Q?jl+qA/gQq31bGQWb6Hi2U6Fu3TyHxO/QrE2GY6NbEl+SWcdc3M0q53wpu7q2?=
 =?us-ascii?Q?dECQNehIzeqx31M8OSaxWOFe3NBLvFpSw9h9GRzvgV1SplxS61C0nYTKDS8E?=
 =?us-ascii?Q?8XrFk1KxR2EgDzf9EUpVbMN2ZBuzsGZqufOVuNrCCRI+8Vfs9QhMmAn0097U?=
 =?us-ascii?Q?pa8DJw06dZfnZBsiRABRMMzjd01Dh9WW3+glOC0da1ty8vgjjt+1JwdclXCH?=
 =?us-ascii?Q?r5GJ8uaVNJzxp2IteJYj7S4P79roqILmCmALpcRByizphnd++7TPKtTLVXSc?=
 =?us-ascii?Q?lIrAVckpvnuwK3fmyUjhRI3XVQUnEonwVSqdRMOjXOQm4G5NZAIS+9qaCLsz?=
 =?us-ascii?Q?0PupS6DaVh1cP2qRZGrCiLsdcJrPWMErNC77eG9vADx1k0xStSSD8Si7UmQj?=
 =?us-ascii?Q?J4J1kEA7cocHWCXHXpwZuH+3V/SxHd9Y3ZWWwLc+DVbGkpz+Ww5O80Q/AGMK?=
 =?us-ascii?Q?UEUSmRpEElB9851vZOtMfHQt7kEgKI0IFshaWbyhFWvlF2EEp/Qz1qlT/Zwg?=
 =?us-ascii?Q?R6a8JrSu+CVQn6x3a9UnR2Pz4dkMKolFi7+Z9iUd7brDBxCU+DDVbztuOQ8E?=
 =?us-ascii?Q?VMsAxCXEbfEosiEjeXoo8nsI6o3orhq8UZyHGO6qs1/s3JAdwMWW26Q6Tdgc?=
 =?us-ascii?Q?78+EmjN9cyroyEcmEIYskADLw+W+q+mLSCXHS/DegL9IbkhXVzK9Otegwq/M?=
 =?us-ascii?Q?v5dJX+yyAZvbH2fNI/k9WBvMrXdL8NCripKRjKI8vHosmZZIMOo2c5OoKXAb?=
 =?us-ascii?Q?F1E/xYwJ671RgyUDi0JRFeK8c0R/VKHwvu8avovTu3PrbU/YEV3MIKSVgFJw?=
 =?us-ascii?Q?BFMlyv/L1ZMH5FTnnW0YSPhK11fUixHufIfUdkpjK5EfvT0gaFG4FgTpouYq?=
 =?us-ascii?Q?2GHh9vQOlotjJV9g+vHOAvSPsxIraeRjFOJsY4RnvPp4/lJdQrlDeQ7Cg3mP?=
 =?us-ascii?Q?98p7RM55r+UlLR4j70+eqWiNL7wvWgxtf0JdPGlcjnBn+oV/HL2aczQ72BwP?=
 =?us-ascii?Q?LMnWeFnZschEIciIW09kWVEQyXTk2RAcDZR0sg8kKSCetGARqXb89bNvhzgJ?=
 =?us-ascii?Q?GN+PNBCqOXXVRF141HpLcKnJNVWaOaMLmExIOtOWYSV+KlVWyXmMULev8iCG?=
 =?us-ascii?Q?6qj+JhwjLAUOuH5wSSi4Pe6aKAHc/e3hHWbOwOcj3S6XyTHuImbRqWMihf6a?=
 =?us-ascii?Q?eU1yLIiCYFnio2IGnsRiAZW6LXJEFV42hT2Dts7IOG3a+J5fhj15hgSvYmzg?=
 =?us-ascii?Q?eZpyggK7CF/fVHCFCOYkDiid5vxa028pn/JeA/hsp1Faf9F4LmKfBn1N3uO9?=
 =?us-ascii?Q?xjtFOBuJSaXdzf++hz2cKfyyBo19BS15RZLLrqy+wnNoTRlZz1CO710hogfs?=
 =?us-ascii?Q?C+f2/TyCFzfSvoSO/r6KbPhH3UcqxUhSdndQlFUw6nWflo1Pw9Fcaxy0EiKz?=
 =?us-ascii?Q?die9FGrC984LenMVjOvNr6bKW+ZTbh4/8XLduN1iRk4S1HKXUZQZjtOIIwgW?=
 =?us-ascii?Q?W/VpvlRpi5a0+55O3GP8zEX8nM26psAoPXoHDmD2OsAS6hlnusmn?=
Content-Type: multipart/alternative;
	boundary="_000_15AA0546704A44868CA12111932167E4sidnnl_"
MIME-Version: 1.0
X-OriginatorOrg: sidn.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P194MB1577.EURP194.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 f6d85656-28d5-4d2c-a696-08de744a7ea2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2026 08:47:23.3784
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 le9TBUBzxzZKazoiOoZ5jr0hZO0ZMe6kvtUepxnAtHIWZLIo71wEY9PUAgM33oWg3nczosx8obYfanZ+k5u1Tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P194MB1420
Message-ID-Hash: VLNH6KAHTDKS2KJS4TZ6I6DUZWEECAEA
X-Message-ID-Hash: VLNH6KAHTDKS2KJS4TZ6I6DUZWEECAEA
X-MailFrom: maarten.wullink@sidn.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; nonmember-moderation; administrivia;
 implicit-dest; max-recipients; max-size; news-moderation; no-subject;
 digests; suspicious-header
CC: Pierre Thierry <pierre@nothos.net>, "rpp@ietf.org" <rpp@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5Brpp=5D_Re=3A_Why_the_limit_to_RMM_level_2=3F?=
List-Id: "This list discusses a provisioning protocol based on RESTful
 principles and corresponding data representations using JSON." <rpp.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rpp/wAVeQ8yvjlfANzoL49Pf4fymeLg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rpp>
List-Help: <mailto:rpp-request@ietf.org?subject=help>
List-Owner: <mailto:rpp-owner@ietf.org>
List-Post: <mailto:rpp@ietf.org>
List-Subscribe: <mailto:rpp-join@ietf.org>
List-Unsubscribe: <mailto:rpp-leave@ietf.org>

--_000_15AA0546704A44868CA12111932167E4sidnnl_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It was also understood by me (anecdotal evidence through blogs) that the us=
e 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 alrea=
dy 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=3D40denic.de@dmarc.ie=
tf.org> 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 th=
e other end a provisioning protocol does not necessarily have to drive appl=
ication
state in a way unpredictable to the client and the clients rarely have a ne=
ed to follow breadcrumbs of path they don't know. Just the opposite - the c=
lients need
to know business logic of the server (registry) to know what payloads and p=
arameters they have to provide in the requests.
Here the WG opted also for strict handling of data validation, so a more co=
upled design between clients and servers is to be expected.

However, there is a great bit of discoverability capabilities already in ar=
chitecture and in design.

We have already an almost ready updated text about discoverability in the a=
rchitecture document:
https://github.com/ietf-wg-rpp/RPP-architecture/blob/f94960bc14f12da944238d=
58ab430b32c886a27a/draft-ietf-rpp-architecture-01.adoc#5121-definition-of-s=
pecial-resources

This will be released with -01 prior to IETF 125.

When working on a new version of rpp-core document Maarten started some des=
ign work on Discovery documents, but this is still on an early stage, so li=
kely 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 disc=
overability in the requirements, I was wondering why the level 2 of the Ric=
hardson Maturity Model was set as a requirement instead of fully adhering t=
o 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 me=
ssage 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 requir=
ements better than stopping at RMM L2:

  *   R9.11/R10.1: representational state transfers make it possible for th=
e RPP server to present links to attenuated facets of the provisioning obje=
cts
     *   a read-only view (that needs authenticated access or not, dependin=
g 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 r=
epresentational state transfers, a generic RPP UI can present new data elem=
ents, new object types and even some new operations to some extent, even wi=
thout prior knowledge

Curiously,
Pierre Thierry
--

pierre@nothos.net<mailto:pierre@nothos.net>
0xD9D50D8A



_______________________________________________
rpp mailing list -- rpp@ietf.org<mailto:rpp@ietf.org>
To unsubscribe send an email to rpp-leave@ietf.org<mailto:rpp-leave@ietf.or=
g>


_______________________________________________
rpp mailing list -- rpp@ietf.org
To unsubscribe send an email to rpp-leave@ietf.org


--_000_15AA0546704A44868CA12111932167E4sidnnl_
Content-Type: text/html; charset="us-ascii"
Content-ID: <1A07C6702F35A34DB24BE94D89E38F0C@EURP194.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable

<html aria-label=3D"message body">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; line-br=
eak: after-white-space;">
It was also understood by me (anecdotal evidence through blogs) that the us=
e of true RMM level 3 was not that common, but i could be wrong here.
<div>Anyway, the use of RMM3 might be redundant when all API endpoints are =
already known and described in IETF document(s)</div>
<div><br>
<div>Pawel already mentioned this, but we do intend to allow the clients to=
 take advantage of discoverability features.</div>
<div><br>
</div>
<div>any help or suggestions on how to improve RPP design in this area are =
very much welcome.</div>
<div><br>
</div>
<div>-</div>
<div>Maarten</div>
<div><br id=3D"lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type=3D"cite">
<div>Op 24 feb 2026, om 18:38 heeft Pawel Kowalik &lt;kowalik=3D40denic.de@=
dmarc.ietf.org&gt; het volgende geschreven:</div>
<br class=3D"Apple-interchange-newline">
<div>
<div>
<p>Hi Pierre,</p>
<p>We didn't put level 3 as requirement or ambition basically because of sp=
lit opinions in the WG about usefulness of those mechanisms for a provision=
ing protocol.<br>
I am convinced however, that some of these mechanism would be useful. On th=
e other end a provisioning protocol does not necessarily have to drive appl=
ication<br>
state in a way unpredictable to the client and the clients rarely have a ne=
ed to follow breadcrumbs of path they don't know. Just the opposite - the c=
lients need<br>
to know business logic of the server (registry) to know what payloads and p=
arameters they have to provide in the requests.<br>
Here the WG opted also for strict handling of data validation, so a more co=
upled design between clients and servers is to be expected.</p>
<p>However, there is a great bit of discoverability capabilities already in=
 architecture and in design.</p>
<p>We have already an almost ready updated text about discoverability in th=
e architecture document:<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/ietf-wg-rpp/R=
PP-architecture/blob/f94960bc14f12da944238d58ab430b32c886a27a/draft-ietf-rp=
p-architecture-01.adoc#5121-definition-of-special-resources">https://github=
.com/ietf-wg-rpp/RPP-architecture/blob/f94960bc14f12da944238d58ab430b32c886=
a27a/draft-ietf-rpp-architecture-01.adoc#5121-definition-of-special-resourc=
es</a></p>
<p>This will be released with -01&nbsp;prior to IETF 125.</p>
<p>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=
.</p>
<p>If you are interested to participate in the review/discussion, here the =
PR:<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/SIDN/ietf-rpp=
-core/pull/36/changes">https://github.com/SIDN/ietf-rpp-core/pull/36/change=
s</a></p>
<p>Kind Regards,<br>
Pawel</p>
<div class=3D"moz-cite-prefix">On 24.02.26 14:06, Pierre Thierry wrote:<br>
</div>
<blockquote type=3D"cite" cite=3D"mid:5835bb17-790d-4606-83fa-e8eacadf0ac3@=
nothos.net">
<p>Hi,</p>
<p>I started reading the RPP RFCs and as there already is a good level of d=
iscoverability in the requirements, I was wondering why the level 2 of the =
Richardson Maturity Model was set as a requirement instead of fully adherin=
g to REST and using State Transfers
 in Representations?</p>
<p>As a concrete example, in RPP Core, message deletion goes through the ha=
rd-coded but relative URI of &quot;/messages/{id}&quot;, but the response m=
essage for message polling could as well contain a &quot;deletion&quot; lin=
k.</p>
<p>Section 3.2 from RFC 9205 lists a few advantages of that approach.</p>
<p>I'll note that fully using REST would also accomodate some exisiting req=
uirements better than stopping at RMM L2:</p>
<ul>
<li>R9.11/R10.1: representational state transfers make it possible for the =
RPP server to present links to attenuated facets of the provisioning object=
s</li><ul>
<li>a read-only view (that needs authenticated access or not, depending on =
the use case)</li><li>a link to a provisioning process that has single-use =
confirm/abort links</li></ul>
<li>R10.1/R10.2: when collections and object operations are provided as rep=
resentational state transfers, a generic RPP UI can present new data elemen=
ts, new object types and even some new operations to some extent, even with=
out prior knowledge</li></ul>
<p>Curiously,<br>
Pierre Thierry<br>
-- <br>
</p>
<div class=3D"moz-signature">
<pre><a href=3D"mailto:pierre@nothos.net" class=3D"moz-txt-link-freetext" m=
oz-do-not-send=3D"true">pierre@nothos.net</a>
0xD9D50D8A</pre>
</div>
<br>
<fieldset class=3D"moz-mime-attachment-header"></fieldset>
<pre wrap=3D"" class=3D"moz-quote-pre">____________________________________=
___________
rpp mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:rp=
p@ietf.org">rpp@ietf.org</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" href=
=3D"mailto:rpp-leave@ietf.org">rpp-leave@ietf.org</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
rpp mailing list -- rpp@ietf.org<br>
To unsubscribe send an email to rpp-leave@ietf.org<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>

--_000_15AA0546704A44868CA12111932167E4sidnnl_--