Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Mario Loffredo <mario.loffredo@iit.cnr.it> Thu, 16 June 2022 06:59 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346BBC157B34 for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 23:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.785
X-Spam-Level:
X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XV9nT8Kj0f2 for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 23:59:13 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF9FC14792F for <regext@ietf.org>; Wed, 15 Jun 2022 23:59:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id A9FFBB802B1 for <regext@ietf.org>; Thu, 16 Jun 2022 08:59:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o3jNslV6jAO for <regext@ietf.org>; Thu, 16 Jun 2022 08:58:58 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.staff.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 223CAB80269 for <regext@ietf.org>; Thu, 16 Jun 2022 08:58:58 +0200 (CEST)
Message-ID: <f6c5d2a4-8680-b5f1-b47c-b98dc46e5aca@iit.cnr.it>
Date: Thu, 16 Jun 2022 08:56:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
To: regext@ietf.org
References: <9829de8f693543abb91aa9f583472b34@verisign.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <9829de8f693543abb91aa9f583472b34@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/XFELCXq0C3X7blHdZz6_KwM43Oc>
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 06:59:17 -0000

Hi folks,

I invite you to consider that, currently, rdap-reverse-search and, 
potentially, three other RDAP-related docs are blocked waiting for the 
end of this discussion.

In addition, it seems to me more logical, first, to decide how RDAP 
exentions must be treated and, then, correct RFC 9083 to make it 
consistent with what decided.

Once agreed on which approach to follow, we could proceed in parallel 
with the correction of RFC 9083 and the writing of a document defining 
the guidelines for extending RDAP.

For the sake of completeness and comprehension, such a document might 
include the scenarios Jasdip has described in his analysis.


Best,

Mario


Il 15/06/2022 19:27, Hollenbeck, Scott ha scritto:
> Thanks for doing all this work, Jasdip. Now we have to decide what to do with
> all of this information.
>
> As a first step, I think we need to submit errata to address issues with the
> existing RFC(s). RFC 9083 uses both "lunarNIC" and "lunarNIC_level_0".  At a
> minimum, Andy and I agree that "lunarNIC_level_0" should be replaced with
> "lunarNIC".
>
> Rationale: Section 2.1 of RFC 9083 describes "lunarNIC" as an example of an
> identifying prefix and includes examples of this value being used as an
> extension prefix. Section 4.1 says "For example, if the fictional Registry of
> the Moon wants to signify that their JSON responses are conformant with their
> registered extensions, the string used might be "lunarNIC_level_0". We believe
> that 4.1 and 2.1 are inconsistent and that they can be made consistent by
> changing "lunarNIC_level_0" with "lunarNIC" in 4.1.
>
> Additional errata may be needed. If so, where, and what else needs to be done?
>
> Scott
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo