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

Amanda Baber via RT <iana-issues@iana.org> Thu, 12 March 2026 04:41 UTC

Return-Path: <iana-shared@iana.org>
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 B4E38C8AF603; Wed, 11 Mar 2026 21:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Level:
X-Spam-Status: No, score=-1.079 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, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=iana.org
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 cVfquclh8N6q; Wed, 11 Mar 2026 21:41:31 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 44163C8AF600; Wed, 11 Mar 2026 21:41:31 -0700 (PDT)
Received: from request7.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 42321E1FCD; Thu, 12 Mar 2026 04:41:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.lax.icann.org 42321E1FCD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iana.org; s=202509s; t=1773290490; bh=iXEW5AyC97mUr/9wi386IHYEt7TBFVvTOhRAkIJF0NY=; h=Subject:From:Reply-To:In-Reply-To:References:CC:Date:From; b=SIjdW04PfgDxQIYsuCKOVwHCckhRJr6yXbelobIgbMnGAqEv/kfFPkPT2fj81yJQo 0k2f5lf9Z0T9f3gGCP0YbDjwrLK6afq8yNfIo42gQ9UQnGjl1Kq6QVkFMfvkMEQQ16 jSCOJtYUTwUVmU4sysIiKNcuSAZdEmRh737/+4cM=
Received: by request7.lax.icann.org (Postfix, from userid 48) id 40BDAC08F726; Thu, 12 Mar 2026 04:41:30 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-issues@iana.org>
In-Reply-To: <rt-5.0.3-569499-1773290431-274.1446148-37-0@icann.org>
References: <RT-Ticket-1446148@icann.org> <rt-5.0.3-569499-1773290431-274.1446148-37-0@icann.org>
Message-ID: <rt-5.0.3-563628-1773290490-1944.1446148-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1446148
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 12 Mar 2026 04:41:30 +0000
MIME-Version: 1.0
Message-ID-Hash: EYJJ6EAOKPKYHFISW2LR7G4GR67RJGVZ
X-Message-ID-Hash: EYJJ6EAOKPKYHFISW2LR7G4GR67RJGVZ
X-MailFrom: iana-shared@iana.org
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
Reply-To: iana-issues@iana.org
Subject: [rpp] [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/pmC5WtEjD-ssPrIVpj8pYmFK_xM>
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>

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