Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

"Gould, James" <> Tue, 02 August 2022 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BB12C375634 for <>; Tue, 2 Aug 2022 08:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LwkWYbsDtFhx for <>; Tue, 2 Aug 2022 08:51:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3681C13C520 for <>; Tue, 2 Aug 2022 08:51:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=8622; q=dns/txt; s=VRSN; t=1659455504; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QEJ3DlqdPVkihvBMrOxzG/Q7EQOl8aW5Ttw7z3RBVac=; b=m2USpDCGLJgqWDO9Vy/nEJX2uJJqds+sBqi0Zgkx4BDCtqCywgIT91av JV1SWp5PCf0ZngINWP/8Fvtjh3pC63OaKkrP7vUxoQUctdsaWXlmp2Y8u JjQVIvO/3jWiAq7I6JB7kVhZa6ZbGB/ukLFo4KWsm5pA8W6mbGAZmYGzs h2vbQAcvgVybj8PmXCziZv2pSEorJVth8PK4L7bV9jbNqee3UCbcDOyGn WvMYPveaPZe9EfULSTdYlcy/3Ijo5QvUaJYHGS9qCr0Qj5depytOuzRmP 55Xz7F6s4LtKf51lucLvux4STg4ewYvPYhO6u4EFyNSyBw9CJ52MUYDa6 A==;
IronPort-Data: A9a23:JPnsV6n/Y0ZJHXXJ8EJ4ouro5gw6JERdPkR7XQ2eYbSJt1+Wr1Gzt xIYXjiGaf3eZGKjLogkOorgpEkGsMXQx4BmSAJrrn1jRC4T+ZvOCOrCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZllwtMQMcacUsxLbVYMpBwJ1FQywIbVvqYy2YLjW1PV4 4upyyHiEATNNwBcYzp8B52r9UsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf Nsv+Znilo/v10x0Vo76yOaTnnoiGdY+NSDW4pZfc/b63kga/kTe2I5jXBYXQR8/ZzlkA7mdY TiC3HC9YV5BA0HCpAgSeyNUAihyIbBAw6boPly26+6CkBH3IlK5lp2CDGluVWEZ0sxNJzhx0 9EocGpLcBuEnfrwyb79VPN3gIIoK8yD0IE34ykmlG6CS697GtafEs0m5vcBtNs0rsJBGuvaa +IHZCBudxXPZVtEPVJ/5JcWxbj33iOmLG0wRFS9vPow6Hjt9SpN2ebnb/GJdvrSeuRkkRPNz o7B1yGjav0AD/SQwD6b83SEi+vOhj/rHokVEdWQ7PNljU2P7m0eFBNQUkG0ycRVkWa0QdQGN EoZ6nJ06LMs7gquT8K4VRr+qmSC51gCQcFWVeY97Wlh15bp3upQPUBcJhYpVTDsnJZeqeACv rNRo+7UOA==
IronPort-HdrOrdr: A9a23:211w0qBJBR6XkiTlHelx55DYdb4zR+YMi2TDsHoBLCC9E/bo9f xG88566faZslgssRIb9uxoUZPoKU80nqQFgrX5U43CYCDW/EWlK4145ZbvznnKC0TFmtJ15O NFf7JlANP9SXp3na/BijWQIpIFzMOc+K6lwd3CyWxgJDsGV4h74xxnBh2gHkp6eQlDCfMCf6 ah2g==
X-IronPort-AV: E=Sophos;i="5.93,211,1654560000"; d="scan'208";a="17702178"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Tue, 2 Aug 2022 11:51:42 -0400
Received: from ([]) by ([]) with mapi id 15.01.2375.028; Tue, 2 Aug 2022 11:51:42 -0400
From: "Gould, James" <>
To: "" <>
CC: "" <>
Thread-Topic: Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance
Thread-Index: AQHYpofC2SJYu2Pz2EqYAWbiQ3PX8w==
Date: Tue, 02 Aug 2022 15:51:42 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2022 15:51:49 -0000


For #1, I just want to ensure that " the RDAP protocol and RDAP Extensions Registry do not directly support versioning of extensions" does not prohibit the registration of versioned profile extension identifiers, since "icann_rdap_response_profile_1" and " icann_rdap_technical_implementation_guide_1" will need to be registered in the future.  The quick answer sounds to be no, so there is no risk of rejecting the inclusion of "versioning" or "visual versioning" in an extension identifier.  Is that correct?  


James Gould
Fellow Engineer <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/>

12061 Bluemont Way
Reston, VA 20190 <>

On 8/2/22, 10:12 AM, "James Galvin" <> wrote:

    On 2 Aug 2022, at 8:16, Gould, James wrote:

    > Jim,
    > I support the chair's proposal with two comments that I communicated at the REGEXT meeting during IETF114:
    > 1. Registration of versioned policy (profile) identifiers will continue to be allowed in the RDAP Extensions Registry, such as "icann_rdap_response_profile_0" and " icann_rdap_technical_implementation_guide_0".

    As a personal observation, I characterize this as “visual versioning”.  If you add a digit(s) to the end of a name then a user looking at it might interpret it as a version.  However, the extension registry would require each individual identifier to be registered.

    On the other hand, there’s nothing that prevents an extension itself from defining for itself how it wants to support versioning.  This could get tricky but it’s all doable and allowed, if you really think you need to go in this direction.

    > 2. There is the need to address extension versioning in the RDAP protocol in the future.

    Speaking as a co-Chair, thanks for this.


    > Thanks,
    > -- 
    > JG
    > James Gould
    > Fellow Engineer
    > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/>
    > 703-948-3271
    > 12061 Bluemont Way
    > Reston, VA 20190
    > <>
    > On 8/1/22, 9:49 AM, "regext on behalf of James Galvin" < on behalf of> wrote:
    >     Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
    >     As everyone knows there has been quite some discussion on the mailing list regarding how to implement rdapConformance.  This was a significant topic of discussion at the REGEXT meeting during IETF114.
    >     Three options were proposed on the mailing list and unfortunately the Chairs do not believe there was a consensus on the mailing list as to how to proceed.  So, the Chairs developed a proposal for how to proceed and presented that at the IETF114 meeting.
    >     Since all decision must be made on the mailing list, the purpose of this message is to state the proposal and ask for support or objections, similar to how we handle WGLC for documents.  Please indicate your support by replying to this message with a “+1” or explaining any objection you have.
    >     This CONSENSUS CALL will close in two weeks on 15 August 2022 at close of business everywhere.
    >     This proposal had consensus during the IETF114 meeting and is summarized as follows.
    >     1. Given that both RFC7480 and RFC9083 are Internet Standards, the bar for changes is quite high.
    >     2. There is a generally accepted consensus for how rdapConformance is to be used and it is widely deployed today.
    >     3. Although any one of the three options could be a reasonable choice, none of them has a broad consensus sufficient to justify changing the Standard.
    >     4. The proposal has two parts as follows:
    >     A. Accept that the RDAP protocol and RDAP Extensions Registry do not directly support versioning of extensions and that both support unique extension identifiers.
    >     B. Submit Errata to the appropriate RFC in STD95 to harmonize the example usage of the extension identifiers “lunarNIC” and “lunarNIC_level_0” to improve clarity on the uniqueness of identifiers.
    >     For additional details working group members are referred to the slides used by the Chairs during the discussion and recording of the meeting:
    >     SLIDES:
    >     RECORDING:
    >     Thanks,
    >     Antoin and Jim
    >     _______________________________________________
    >     regext mailing list