Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt

"Gould, James" <jgould@verisign.com> Fri, 24 June 2022 14:08 UTC

Return-Path: <jgould@verisign.com>
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 4ACC9C15AD28 for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 07:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 KuAvWxlI4ykq for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 07:08:54 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FDBC14F73B for <regext@ietf.org>; Fri, 24 Jun 2022 07:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=51716; q=dns/txt; s=VRSN; t=1656079732; h=from:to:subject:date:message-id:mime-version; bh=C23ZEZlX6MD+W2hPyu6P/8Ss3j0KoRI7CiVNu2mtitI=; b=iHdH1u2760BgypMHjmvQSKVwAEY15XFbYuZpXoEZK3m0WZblvZxQEBSx V8CGJZqyMzUu2SLWEdjXr9qQCdSLv9st9WIlN+wcgEJV508+C/mtk1tgb Ua6YOdwjEFQeoUZYvIkiLO+VA26R8kyN8XlW32RwDBnkJcVP0Ka096NGC 2OILx7PKNw7llpNfxTmjRmAXrFPPaMc6rsH8Yew4e20EDstd1/OpihoXS IBdXvfcwC2eyTFo51f20eFx42K/v1UK5bfCLPLBq27eDGMout9kCnRxvw mvWl/9QA4eiZcxVbaCVZfF7IWtx8EsT8P9K1UiA97tOZiSQ16nGfdnpHa Q==;
IronPort-Data: A9a23:GN+Vq6kMGXFDKisXcX6Pgp/o5gyoJ0RdPkR7XQ2eYbSJt16W5oE+e lBvADTXbaqKYmPrO4chWDmFhUNV7JaGndRiTgtv/ixnRnhG+ZCaCdqVdkqrMXrCfpySERM5v sgXM4eecp8/RCTW9kfzP7LqpiUmjPjZTbGsVb6s1kydJONBYH5JZUVLx7dg3uaE+OSEPj5hm e8eguXRNgP1gmUpbD9Ft/ne8R0y5v385mNCt1U3O6AX4ACOnSVMXMMUKJ/qIiqjSOG4PAIYq 8Xrl+jlozyDr3/BLvv/z94Xp2VTGua60TBjDhO6YoD66vR4jnVaPp0TabxNMy+7tx3Tx4ork IsX6cTqIesUFvakdNo1AkEw/x5WYPUuFI/veRBTZuTKkiUq21O1qxlfJBle0b8wo46bMkkXn RAsEw3hWzjY7w6A6OniFrQz3JRLwP7DZ+vzslk4pd3QJah+HcCbG80m7/cAtNs7rpgm8foz+ 6P1wNegBfjNS0QnB7sZNH4xtOiTplvRTgAIknmutZJu+UvMxhNg3IG4ZbI5evTSLSlUtmyig Dv52UnJWkhcKteY0yLD+37qmPXUm2XwX4d6+L+Qr6Ys2QLIgDVOU1tKBTNXotHg4qK6c9BQL FEQ9gIwoLIz702kSJ/2WBjQTHus50BDBooPTrxSBAelx5DT7ia3RTk/VAVfY9k6uOYkbD4M2 Qrc9z/uLXk12FGPclqn6baQrT62PAANLHVEYjULJSMf7tbusJ0bjx/TQJBkCqHdszHuMTvqx WmVqiUu3+xWltARkaC65hXNhHSmvJ6QCBAv/QORVWWghu9kWLOYi0WTwQCzxZ59wEyxFzFtY FBsdxCi0d0z
IronPort-HdrOrdr: A9a23:OEUOTq0Xf66fXztygLTjUAqjBG8kLtp133Aq2lEZdPUzSL38qy nOpoV46faaslYssR0b9+xoW5PufZq0z/cc3WB7B8bAYOCJggqVBbAnw4fkzybpBiHyssVMvJ 0NT4FOTPn9F0Jzg8q/wgWpeuxL/PC3tISln/3XwXsodxxtcK0I1WpEIxyWCVJ7XzNLApcFFJ 6Rj/Atmwad
X-IronPort-AV: E=Sophos;i="5.92,218,1650931200"; d="png'150?scan'150,208,217,150";a="16758759"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Fri, 24 Jun 2022 10:08:48 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Fri, 24 Jun 2022 10:08:48 -0400
From: "Gould, James" <jgould@verisign.com>
To: "Rwilhelm@PIR.org" <Rwilhelm@PIR.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt
Thread-Index: AQHYh9PsaWHkj6I0nEy4jd7P0FANvg==
Date: Fri, 24 Jun 2022 14:08:48 +0000
Message-ID: <AFB1AE68-1E67-453C-B92C-1AE806E771F1@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_AFB1AE681E67453CB92C1AE806E771F1verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/k-NVZlhIsGVn5TeZLU-2Rj2Q_q4>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt
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: Fri, 24 Jun 2022 14:08:58 -0000

Rick,

Thank you for doing a detailed review of the draft.  I include responses to your feedback embedded below.

--

JG

[cid:image001.png@01D887B2.657F4E40]

James Gould
Fellow Engineer
jgould@Verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Rick Wilhelm <Rwilhelm@PIR.org>
Date: Thursday, June 23, 2022 at 4:51 PM
To: "regext@ietf.org" <regext@ietf.org>, James Gould <jgould@verisign.com>
Cc: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt

Jim, et al,

While there is clearly work going on to determine a direction related to the conformance values, I wanted to invest some time to give a careful review of the current rdap-redacted draft to have it better prepared to progress after the WG comes to some consensus.

JG – I also want to get to a target approach for the conformance values.  Look at the mailing list posting https://mailarchive.ietf.org/arch/msg/regext/fIA70fb4qqQGD9G1u4rk7aKrFTc/ for a break down and example of each of the approaches.  As noted in that message, I prefer Approach C, but I believe Approach B is a reasonable compromise for Approach A and C.  Please reply to that thread if you have a preference.

Overall, I think that this draft looks really good.  I’m hoping that we can figure out the conformance thing soon.

In that context, and in the order of the document, here is some feedback.  Most of these are small, trending toward nit.


1. Introduction

Regarding:

A redacted RDAP field is one that has data
   removed from the RDAP response due to the lack of client privilege to
   receive the field.

As has been discussed elsewhere and is presented in this document, the concept of “redaction” is broader than “removal” and also includes “edit”.  Additionally, there may be any number of reasons why a response would be redacted (which would most certainly include “lack of client privilege”, but could also include other reasons.  To that end, I would suggest the following edit:

A redacted RDAP field is one that has data
   in the RDAP response edited due to policy, for example, the lack of client privilege to
   receive the field.

JG – I believe that edited is not descriptive enough.  How about including the case of replacement and incorporate your more generic language on the reason with:

A redacted RDAP field is one that has data
removed or replaced in the RDAP response due to server policy, such as the lack of client privilege to
receive the field.


3. Redaction Methods

Regarding:

   The redaction of RDAP fields fall into the two categories of
   Redaction by Removal Method (Section 3.1) and Redaction by Empty
   Value Method (Section 3.2), defined in the following sub-sections.

I think that this paragraph needs updating to account for (the recently added) Section 3.3.  As in:

   The redaction of RDAP fields fall into the two categories of
   Redaction by Removal Method (Section 3.1), Redaction by Empty
   Value Method (Section 3.2), and Redaction by Replacement Value
   Method (Section 3.3), defined in the following sub-sections.

JG – Good catch.  That does need to be updated to cover the three categories.  I believe it’s easy to remove the direct references and simply state:


The redaction of RDAP fields fall into the three categories defined in the following sub-sections.


3.1 Redaction by Removal Method

Nit:  Suggest putting a paragraph break before “An example of redacting…” in order to better separate the example from the normative text.

JG – Yes that can be done and it will be more consistent with the other examples.

4.2 “redacted member”

Regarding:

   The "redacted" member MUST be added to the RDAP response when there
   are redacted fields.

Suggest that this is updated to have the MUST unambiguously cover the case when there is exactly 1 redacted field

   The "redacted" member MUST be added to the RDAP response when there
   Is one or more redacted fields.

JG – That is fine.  The “Is” will be a lowercase “is” as in:


The "redacted" member MUST be added to the RDAP response when there

is one or more redacted fields.


Regarding:

   "method":  OPTIONAL redaction method used with "removal" indicating
       the Redaction By Removal Method (Section 3.1), "emptyValue"
       indicating the Redaction by Empty Value Method (Section 3.2), and
       "replacementValue" indicating the Redaction by Replacement Value
       Method (Section 3.3).  The default value is "removal" when not
       provided.

I think that there is punctuation needed and a minor ed in the first line to improve clarity.  Suggested edit:

   "method":  OPTIONAL redaction method used; with one of the following values: "removal" indicating
       the Redaction By Removal Method (Section 3.1), "emptyValue"
       indicating the Redaction by Empty Value Method (Section 3.2), and
       "replacementValue" indicating the Redaction by Replacement Value
       Method (Section 3.3).  The default value is "removal" when not
       provided.

JG – Do you believe that the values should be included in a list?  I’m thinking that it should.

Hope that helps.  Questions welcome.

Thanks
Rick


From: regext <regext-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
Date: Thursday, May 26, 2022 at 1:46 PM
To: i-d-announce@ietf.org <i-d-announce@ietf.org>
Cc: regext@ietf.org <regext@ietf.org>
Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rdap-redacted-07.txt
CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

Title : Redacted Fields in the Registration Data Access Protocol (RDAP) Response
Authors : James Gould
David Smith
Jody Kolker
Roger Carney
Filename : draft-ietf-regext-rdap-redacted-07.txt
Pages : 37
Date : 2022-05-26

Abstract:
This document describes an RDAP extension for explicitly identifying
redacted RDAP response fields, using JSONPath as the default
expression language.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/<https://secure-web.cisco.com/1emO4uu4xlB2otHW5q0eTCg1zomz9nS7AX3C78avS_ReK3HIPztjYXy6W5cVH9V1ijcPh8PV_Eth1_yxnmPdua81oh28ct5NQA1RRnNWrQzGisEKSfnxRWppvfiqFRRlK0FFox-rT3hxsDJOiaXB_oiIEdllNZkEmMYqjFf1Aa_AFnOh-mk_9mYdiHh4rAGfeZYc-2QttoqMQhKoSNUuAl8dj2i9GVVfO5GVlIkrFoIMrjijFvU6ic1CvFFXYKFra/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FocBQC0RPwLiGp2VCOzYRs%3Fdomain%3Ddatatracker.ietf.org>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-redacted-07.html<https://secure-web.cisco.com/1MTseqekckZ6LqYMfhw9wxz2dvcfsfk9NaI8rjzDo-Wi5Y6OcyOau670vvyzVH87NIJZ1tGyJZqRhcK2rRhvUPk1sYfbcGbahQeJdFXEDKnKAbk6CExlSb7eI5JNrMGGN-KB6KcOLn1FRxthopUSS-ZTGKqgK2e6uzehWuqFo_IRghh20W-o9KBmUz5OwdEEDPZdDDsW72N_MIfw_iOIFf0ou_UQAN8QMRrnCG6AcSLz9hs5q15xS2JaWdKCw9KbB/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FYCfQCgJNR2fADl9H7GDCZ%3Fdomain%3Dietf.org>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-redacted-07<https://secure-web.cisco.com/1rs6ZCMhWqCWg2FOn1dDjcNyTNYnIRijbVHGeYuDE-A7XDA00Cc-CxiTPf-qkDDyOYgOw1ipeQd4Dq3sBlPMhhXSkdtdhoBa4jO56dHIRLasPn2ohMVLKkKX0fboG7syGlWyATHgy1lf7U8do9I6UKrc8tntNJi9HUT_M4mmvMR96HzbA2X8nhdFu2HEtiOniTvSQcQqDQz-cyQ3qdTP4VaXfoI6I22R-GGd1xpQ28qB2xqwDW219GdczDZiIPAa8/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F_x_zCjRNX8inVj8Cjhvdu%3Fdomain%3Dietf.org>


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1KjbxvotupGvZULTnK5Jotwd22SS8jsIg1J1TZrA3GZI2NfSAUqXhSqPb5FbuiW3cYxzROygh9sTDo5bUDoJlKtlJbz4ibcyz53M3tY0DuHnUeRi3fE7LC16gKSpE-NcCQccP_PxVMi31-sqbQPrzhmJ1s7fSjUXdLoDDnOuyQRwG1fYItFMdiuBB-6FZ8PN3wfuBVpPf7VoQth14p5ovyCs1nFSK0VGqpQABoYul7Nnd4ksVWS0O8-Z6PbnL7oBV/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FwhMrCkRNY7iOPn9SNnQJU%3Fdomain%3Dietf.org>