[rpp] Re: [IANA #1446148] Early review: draft-kowalik-rpp-data-objects-03 (IETF 125)

Pawel Kowalik <kowalik@denic.de> Thu, 12 March 2026 06:54 UTC

Return-Path: <kowalik@denic.de>
X-Original-To: rpp@mail2.ietf.org
Delivered-To: rpp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 46F6DC8C18EF; Wed, 11 Mar 2026 23:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNxzfmCQqPYd; Wed, 11 Mar 2026 23:54:36 -0700 (PDT)
Received: from mout-b-202.mailbox.org (mout-b-202.mailbox.org [195.10.208.62]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5D4ACC8C18D6; Wed, 11 Mar 2026 23:54:33 -0700 (PDT)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-202.mailbox.org (Postfix) with ESMTPS id 4fWddW45VKzDsDV; Thu, 12 Mar 2026 07:54:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1773298463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CzHK5LB/qQP5w1sV0hh7VWQTIk9tWuGvRg267BxTCPQ=; b=LvOjqvzcb/QK3XaLU+0V0ZhkksEfgRRz70o2f29rn79cwHcAwGL54UI/AkZF4Lx8Z4VZkJ cyBVtVZNxsX7I4Tt1WRvFro6TWDQAkeLnYJ7cVUJomjdKHn9XgZpu/ZVc4RCLQmKwz4cpS gDidHcDaxJMKLJ7LoIRuyPmZ6fvJbuaAlru1NivDHaBc/o6tzVSy5If/QJA9E/F4Xu6e/u EDaBjuhzkIXpra3hH4rZ9xR11Iq4j4YO4b4NlrUac5pFG0u1JoMMEcZKq96ZjjxjD/a0Jn wGU4NKALI17O2LZJ+eTopWsbaMvKTg3b4MzELp0LqMGd7EBz4zZU5JXD8zyn8g==
Message-ID: <5c23c6f8-19ef-4aed-a3f4-05ed208933fc@denic.de>
Date: Thu, 12 Mar 2026 07:54:22 +0100
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: iana-issues@iana.org
References: <RT-Ticket-1446148@icann.org> <rt-5.0.3-569499-1773290431-274.1446148-37-0@icann.org> <rt-5.0.3-563628-1773290490-1944.1446148-37-0@icann.org>
Content-Language: en-GB, de-DE
In-Reply-To: <rt-5.0.3-563628-1773290490-1944.1446148-37-0@icann.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms040500080004050004030905"
X-MBO-RS-META: jmcm17ytitymntpukzcoiw1mzrih1ox9
X-MBO-RS-ID: c18755b0d652edc7b24
Message-ID-Hash: 6N3OQRORLZ2C3FW45OHALQGJDTKXEW25
X-Message-ID-Hash: 6N3OQRORLZ2C3FW45OHALQGJDTKXEW25
X-MailFrom: kowalik@denic.de
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: draft-kowalik-rpp-data-objects.all@ietf.org, rpp@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rpp] Re: [IANA #1446148] Early review: draft-kowalik-rpp-data-objects-03 (IETF 125)
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/N3-yEHkpUHj43C6p36qZ2XAyxR0>
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>

Hi Amanda,

Thank you for this valuable feedback.

Yes, these are the aspects we will definitely define in the further 
works on this draft.

This is absolutely right approach to align registry definitions from 
draft-kowalik-rpp-data-objects and draft-wullink-rpp-core, and have all 
these registries within same registry group.

Issues are open:

https://github.com/pawel-kow/draft-kowalik-rpp-data-objects/issues/29

https://github.com/pawel-kow/draft-kowalik-rpp-data-objects/issues/44

https://github.com/pawel-kow/draft-kowalik-rpp-data-objects/issues/7

Kind Regards,
Pawel

On 12.03.26 05:41, Amanda Baber via RT wrote:
> Dear Authors,
>
> Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about this document:
>
> https://datatracker.ietf.org/doc/html/draft-kowalik-rpp-data-objects-03
>
> It doesn't have to be discussed now, but it looks like it might be a good idea to discuss different ways to present this registry information. Should the “Data Elements” table for each registration itself be considered a registry that can receive new registrations? If so, we could fill in this field with a link to a “<Data Object Name> Data Elements” subregistry. (This would also require establishing registration procedures for those subregistries and determining whether those procedures would apply to all future Data Objects’ Data Element subregistries, which might be desirable.)
>
> A similar solution was eventually arrived at https://www.iana.org/assignments/ipfix, where many of the current subregistries for the Information Elements registry initially started as tables in individual Information Element registrations’ “Description” fields.
>
> Also, can this be a “RESTful Provisioning Protocol (RPP) Data Objects” registry in a new “RESTful Provisioning Protocol (RPP)” registry group, as suggested in draft-wullink-rpp-core, rather than a “RESTful Provisioning Protocol (RPP) Data Object Registry”? In recent years, we’ve asked authors to leave the word “Registry” out of registry names wherever possible, and the help page linked below describes registries and registry groups.
>
> If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at iana@iana.org.
>
> For more information about IANA Considerations section requirements, please see
>
> https://www.iana.org/help/protocol-registration
>
> Best regards,
>
> Amanda Baber
> IANA
>
> _______________________________________________
> rpp mailing list -- rpp@ietf.org
> To unsubscribe send an email to rpp-leave@ietf.org