Re: [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated
Jasdip Singh <jasdips@arin.net> Thu, 20 April 2023 15:49 UTC
Return-Path: <jasdips@arin.net>
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 67DE1C14CE40 for <regext@ietfa.amsl.com>; Thu, 20 Apr 2023 08:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 fS6Uk1CqKlcQ for <regext@ietfa.amsl.com>; Thu, 20 Apr 2023 08:49:41 -0700 (PDT)
Received: from smtp3.arin.net (smtp3.arin.net [199.43.0.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC69BC14CF13 for <regext@ietf.org>; Thu, 20 Apr 2023 08:49:41 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.arin.net (Postfix) with ESMTPS id DEBE710733E6; Thu, 20 Apr 2023 11:49:39 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Apr 2023 11:49:38 -0400
Received: from CAS01CHA.corp.arin.net ([fe80::e5af:ace4:3b7a:df63]) by CAS01CHA.corp.arin.net ([fe80::e5af:ace4:3b7a:df63%17]) with mapi id 15.00.1497.000; Thu, 20 Apr 2023 11:49:39 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated
Thread-Index: AQHZc3pJzqba8gI1hE23r4rzu1GM0K80WHgA
Date: Thu, 20 Apr 2023 15:49:39 +0000
Message-ID: <CDF6905F-1B28-4064-B1A9-08D46F0D0539@arin.net>
References: <0B19F52B-D131-4AC0-AA18-4BF770C65090@verisign.com>
In-Reply-To: <0B19F52B-D131-4AC0-AA18-4BF770C65090@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: multipart/related; boundary="_004_CDF6905F1B284064B1A908D46F0D0539arinnet_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/RPIBmaFIN5IjR3CRzSSUhMQhPjo>
Subject: Re: [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated
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, 20 Apr 2023 15:49:46 -0000
Hi. Agree with James’ input -- not violating the JSContact spec for the mandatory uid, and using the redaction-by-replacement method. Using a nil UUID as a replacement string for uid looks elegant. Thanks, Jasdip From: regext <regext-bounces@ietf.org> on behalf of "Gould, James" <jgould=40verisign.com@dmarc.ietf.org> Date: Thursday, April 20, 2023 at 7:21 AM To: "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated Mario, I agree if you can’t remove the mandatory UID field to comply with the JSContact specification and are forced to use a literal value (placeholder text) than the Redaction by Replacement Value Method is the best route to go for redaction, since it explicitly signals the use of replacement value to the client. -- JG [cid87442*image001.png@01D960C5.C631DA40] 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: regext <regext-bounces@ietf.org> on behalf of Mario Loffredo <mario.loffredo@iit.cnr.it> Date: Thursday, April 20, 2023 at 2:00 AM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated Hi all, willing to finalize the discussion about how to redact JSContact uid in RDAP, I first would like to thank everyone who has provided feedback. Really appreciated it. SInce it seems to me that no option has collected the largest consensus, I would like to make a new proposal that hopefully will be more widely shared. The proposal preserves the mandatory constraint on uid and doesn't introduce new redaction methods. Assuming that an RDAP operator should be free to use any of the uid formats allowed, the redaction method might differ accordingly. In particular, I envisage two methods could be used. If an RDAP operator opted for the free-text format, the Empty Value method would work better. If the UUID format is selected, the Replacement Value method using the nil UUID as replacing value is the most appropriate in my opinion. Don't find a reason to register a specific URN value when an unspecified value already exists and considering that what really matters is not the returned value but rather that a related item is added to the redacted array. Neither we really need to add specific redaction methods because "Replacement Value" already fits the case of replacing the original value with another one. An URI value could be redacted by using any of the two methods above. For example, if the uid was usually set to the URL of the RDAP entity related to the contact (e.g. "https://example.com/rdap/entity/XYZ12345"<https://secure-web.cisco.com/1rDGIVN-8DyNZZDElSveDJ9praztoNUxraj0RbbphWU5YOuyLkDeF5n9uI-Xa27lO8Yohymola6AB43mtojkxdiCKj4wp9USxFGegxKZv47a4rc9ergNENNxpTwLN9rI5APXm9T_o3dbbESGAOOVIXuyDnzXZPaY09JJzXJ724g0tdDciTBFg8hDJOrBCxTx8vw3Mjokv6Qu1500caNV4kE1vrFjKITuWtneqCfvHtIk-JsBE9B7UWR9UtY4DwXZU0RDa9iLZbS-o33nw2-ANQOyaXeIpYILute_EZmWBAXc/https%3A%2F%2Fexample.com%2Frdap%2Fentity%2FXYZ12345>), the redaction could consist in replacing the entity handle with a fixed literal (e.g "https://example.com/rdap/entity/XXXXX"<https://secure-web.cisco.com/1S9wdaf6gbDO2S66l-_aLxaDPjllKgPEDBG-qOKQFFqLcNKb0-rBHOOe5V1Qdt8l1UHkP0Z_HvsNtDJt2bhaOQoT6AC6_8DhCl8MtAAKPszMU8X2rPRXToaK-Wk_pbtsr_UKWHF5Fqj103BhxEkMXgvxIBeSB82IdJS5NbqJJGXixLNI7wVcZE_O6ZAltyyoOIS28LkfGSXljmeHWoXNGuBEcNY55zl8FIyyj819sacUxl8vWUkS5iFl-4wk3J-AqN4Xk02HauPYky8aga3kyQWT46HbwQ4sXl0mWMYqArn4/https%3A%2F%2Fexample.com%2Frdap%2Fentity%2FXXXXX>). Still believe that overriding the mandatory constraint is the most correct approach from the conceptual perspective but couldn't be natively supported by libraries handling the JSContact format and strictly adhering to the specification. If there are no objections, I'll incorporate the proposal into rdap-jscontact. Best, Mario -------- Messaggio Inoltrato -------- Oggetto: Re: [regext] [Ext] Re: Redacting JSContact uid in RDAP - Updated Data: Tue, 4 Apr 2023 12:44:17 +0200 Mittente: Mario Loffredo <mario.loffredo@iit.cnr.it><mailto:mario.loffredo@iit.cnr.it> A: Gustavo Lozano Ibarra <gustavo.lozano@icann.org><mailto:gustavo.lozano@icann.org>, Andrew Newton <andy@hxr.us><mailto:andy@hxr.us> CC: Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org><mailto:shollenbeck=40verisign.com@dmarc.ietf.org>, regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org> Hi Gustavo, thanks for you comment. For the sake of limiting the implications of rdap-jscontact on rdap-redacted, just checked on some web sites providing UUID generators that "nil UUID" and "empty UUID" are synonyms. Since rdap-redacted defines "redaction by Empty Value" (rather than empty string), wonder if we could consider the setting of the uid property to an Empty/nill UUID (i.e. "00000000-0000-0000-0000-000000000000") as an usage of such a method. As a result, the same redaction method could be used to redact uid values in both free-text and UUID formats. Another possible solution is to define in rdap-redacted a registry including the redaction methods. New redaction method names like those suggested by Gustavo could be defined by future documents (rdap-jscontact primarily) that can't find a match among the methods listed in rdap-redacted. Thoughts? Best, Mario Il 04/04/2023 04:24, Gustavo Lozano Ibarra ha scritto: Hi Mario, et. Al., Comments inline. Regards, Gustavo On 4/2/23, 11:38 PM, "regext on behalf of Mario Loffredo" <regext-bounces@ietf.org on behalf of mario.loffredo@iit.cnr.it><mailto:regext-bounces@ietf.orgonbehalfofmario.loffredo@iit.cnr.it> wrote: HI Andy, Il 31/03/2023 23:36, Andrew Newton ha scritto: > If the uid can be free text according to JSContact, why do we need to > override that? RDAP servers can just put random text in that field, > which has the same effect of the UUID URN. > > That said, I like Gavin's idea. I could live with Option 4 or Option 3. [ML] I would have no objection to use Option 3 or Option 4 but both of them require to define a new redaction method because none of those currently defined can be used in those cases. GL - Correct, and I think that having those new redaction methods defined in draft-ietf-regext-rdap-redacted is a must. I have been in conversations with users of RDDS (a term in the gTLD world that means the service used to consume registration data) in which there is a desire to differentiate between: * No data was provided in the response because no data exists in the server's database. * Data exists in the database, but it was redacted in the response. * The data provided in the response is the actual data in the database, even if the semantics of the value are non-customary, for example, a registrant providing "REDACTED FOR PRIVACY" (a well-known string used in Whois to indicate redaction) as their name. The "redacted" member defined in draft-ietf-regext-rdap-redacted provides the signaling mechanism that satisfies the requirements above. If option 3 is selected with a random value, a signal is needed to differentiate between data persisted in the database and randomly generated values. Maybe we can add "redaction by random value" to draft-ietf-regext-rdap-redacted? If option 4 is selected, I think adding a signal in the "redacted" member is also desired in order to have a central place signaling all redactions in the response. It is straightforward for an implementer to understand that "redacted" contains all redacted data elements, and they need to do "X" in the interface if a data element is defined as redacted. If we go with option 4 without support in draft-ietf-regext-rdap-redacted, there would be this unique scenario that it's not in the "redacted" member, but it's still redacted if you find the special value. Maybe we can "redaction by placeholder value" to draft-ietf-regext-rdap-redacted? Otherwise uid could be the only RDAP property that can be redacted through a kind of placeholder value without being included in the redacted array. Do you agree about it ? Option 1 leverages the Empty Value redaction method and free-text format but it's likely that a JSContact implementation will check not only for the not null constraint but also for the not empty constraint. Therefore, even in this case and similarly to Option 2, a JSContact implementation should distignuish cards used outside RDAP from those used inside RDAP. Option 2 doesn't need a new redaction method and enbales an RDAP server to set the uid property as it sees fit: - assigning it with a valid value and, when needed, redacting it by the Removal method - omitting the uid property That being said, if the WG agreed about adding a new redaction method to macth Option 3 and Option 4, I wouldn't object. Best, Mario > -andy > > On Fri, Mar 31, 2023 at 11:52 PM Mario Loffredo > <mario.loffredo@iit.cnr.it><mailto:mario.loffredo@iit.cnr.it> wrote: >> Hi Scott, >> >> Il 31/03/2023 14:32, Hollenbeck, Scott ha scritto: >>>> -----Original Message----- >>>> From: regext<regext-bounces@ietf.org><mailto:regext-bounces@ietf.org> On Behalf Of Mario Loffredo >>>> Sent: Friday, March 31, 2023 7:45 AM >>>> To:regext@ietf.org<mailto:To:regext@ietf.org> >>>> Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated >>>> >>>> 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. >>>> >>>> Hi folks, >>>> >>>> just reported below all the options (including Gavin's proposal) and the >>>> preferences given thus far. >>>> >>>> Please, express your preference(s). >>>> >>>> Thanks a lot in advance. >>>> >>>> >>>> 1) Redacting by Empty Value method >>>> >>>> 2) Making uid optional in RDAP and then redacting by Removal method >>>> >>>> - J.Gould >>>> >>>> 3) Recommending the use of UUIDs that prevent from correlation (e.g. >>>> either randomly generated or nil UUIDs) >>>> >>>> 4) Redacting by using a registered URN in the IANA namespace (e.g. >>>> "urn:ietf:params:json:rdap+jscontact:uidRedacted") >>>> >>>> - G. Brown >>>> >>>> 5) Anything else ? >>> [SAH] Which of these options is the least likely to break a JSContact parser? >> [ML] I would say that it all depends on the constraints your >> implementation checks. >> >> Since uid is a JSON String and assuming that it isn't used to model some >> JSContact relationship, the possible constraints to check are in order >> of priority: >> >> - Not null >> >> - Not empty >> >> - Compliance to a possible format >> >> Unless RDAP overrides the JSContact spec (as stated by options 3 and 4) >> , the uid value can be a free-text hence the last constraint can't be >> checked. >> >> With regard to the first two constraints: >> >> - option 3 and 4 will make both the checks result in a success >> >> - option 2 will make both the checks result in a failure >> >> - option 1 will make the check on 2nd constraint result in a failure >> >> >> Some additional considerations: >> >> - if we comply to JSContact recommendation of assigning uid with an URN >> in the UUID namespace, option 3 would be preferrable. URI and free-text >> (including the empty string) are presently allowed for compatibility >> with RFC6350 but could be deprecated in the future. To redact a >> mandatory UUID to prevent from correlation, maybe an addtional redaction >> method should be considered. >> >> - jscontact-tools checks for the first two constraints (and, in the case >> of a group card, it executes other consistency checks). Such constraints >> are validated statically through annotations on properties but it's >> quite easy to intercept the error messages and skip the failure of "not >> null" constraint depending on the validation context. >> >> >> Given that, my opinion is that option 2 would be preferrable because it >> would enable the uid implementation in RDAP to be detached from the >> possible uid evolution in the main spec. >> >> As a result, I would also recommend to use an UUID when a server returns >> an undisclosed uid property. >> >> Note that an UUIDv5 can be generated from another property (like the >> handle) and this enables a server to generate always the same uid value >> without storing it somewhere. >> >> >> Apologize for the long explanation. >> >> Hope it could be helpful. >> >> Best, >> >> Mario >> >>> My preference is leans towards whichever option or options will be the most >>> compatible with implementations of JSContact such that any RDAP complexity is >>> handled in the RDAP-implementing software. >>> >>> Scott >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org<mailto:regext@ietf.org> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!5N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk$<https://secure-web.cisco.com/1-aeNi0LNbOuh6J7-XYSjVlmq3ShwwClBp8_vsIMmXp3olsLWp6vcUQl_Xw6ZfNc4GRfjHu6rWAX4ooDguVztuP64yTD4ge89z0eMuQgvbKHc_l5ux33-4_lrdOeFdRV2FbLOcf0DX_XhYixO5V6vwQvOd7-z5Bq32z7lwu_EaWwzFi0YdHUEDU8DazgXmPZYUo0CeT_bSmwapqqz08Zp8_jnjYc9-7ATFRG6vZic8EQ659MA0sDyRl_SLhtJwYqkG3tWFDZJ-dutoVZ1dREoOAHJevvH0z3feJRjpoBVAQg/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext__%3B%21%21PtGJab4%215N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk%24> [ietf[.]org] >> -- >> Dott. 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:https://urldefense.com/v3/__http://www.iit.cnr.it/mario.loffredo__;!!PtGJab4!5N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXHi7Pt_k$<https://secure-web.cisco.com/1ZCEP_HyrylOVR4YdJz-iaM3ROmDyBACKq7gqB8vu9vlqa8ypl4jGG03eVm4yn63Qx2qd__8-Bzzg33h5RgjjvnwKnU5Ma1pfZaH_jvcEq_Hna_KNvxLNACmADczI-0oPEBo16ixTbavTRRzvMsv7sVGhN7cRLtZF4ShzWJp8snVKVyKb_wiaASLFawcawTKWrsbRrMt-tmc1LQskuleRkQTd5raGHrKyUKgy1P_neEPQdxn6khXl0YwkZ29EqshMm64xQyTJzLlhr5ynyabn4ugltcO__HLy62LXlv9wXww/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo__%3B%21%21PtGJab4%215N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXHi7Pt_k%24> [iit[.]cnr[.]it] >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org<mailto:regext@ietf.org> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!5N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk$<https://secure-web.cisco.com/1-aeNi0LNbOuh6J7-XYSjVlmq3ShwwClBp8_vsIMmXp3olsLWp6vcUQl_Xw6ZfNc4GRfjHu6rWAX4ooDguVztuP64yTD4ge89z0eMuQgvbKHc_l5ux33-4_lrdOeFdRV2FbLOcf0DX_XhYixO5V6vwQvOd7-z5Bq32z7lwu_EaWwzFi0YdHUEDU8DazgXmPZYUo0CeT_bSmwapqqz08Zp8_jnjYc9-7ATFRG6vZic8EQ659MA0sDyRl_SLhtJwYqkG3tWFDZJ-dutoVZ1dREoOAHJevvH0z3feJRjpoBVAQg/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext__%3B%21%21PtGJab4%215N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk%24> [ietf[.]org] -- Dott. 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:https://urldefense.com/v3/__http://www.iit.cnr.it/mario.loffredo__;!!PtGJab4!5N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXHi7Pt_k$<https://secure-web.cisco.com/1ZCEP_HyrylOVR4YdJz-iaM3ROmDyBACKq7gqB8vu9vlqa8ypl4jGG03eVm4yn63Qx2qd__8-Bzzg33h5RgjjvnwKnU5Ma1pfZaH_jvcEq_Hna_KNvxLNACmADczI-0oPEBo16ixTbavTRRzvMsv7sVGhN7cRLtZF4ShzWJp8snVKVyKb_wiaASLFawcawTKWrsbRrMt-tmc1LQskuleRkQTd5raGHrKyUKgy1P_neEPQdxn6khXl0YwkZ29EqshMm64xQyTJzLlhr5ynyabn4ugltcO__HLy62LXlv9wXww/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo__%3B%21%21PtGJab4%215N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXHi7Pt_k%24> [iit[.]cnr[.]it] _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!5N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk$<https://secure-web.cisco.com/1-aeNi0LNbOuh6J7-XYSjVlmq3ShwwClBp8_vsIMmXp3olsLWp6vcUQl_Xw6ZfNc4GRfjHu6rWAX4ooDguVztuP64yTD4ge89z0eMuQgvbKHc_l5ux33-4_lrdOeFdRV2FbLOcf0DX_XhYixO5V6vwQvOd7-z5Bq32z7lwu_EaWwzFi0YdHUEDU8DazgXmPZYUo0CeT_bSmwapqqz08Zp8_jnjYc9-7ATFRG6vZic8EQ659MA0sDyRl_SLhtJwYqkG3tWFDZJ-dutoVZ1dREoOAHJevvH0z3feJRjpoBVAQg/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext__%3B%21%21PtGJab4%215N3BqQl31If-aiYx5yPXyVHPjDH77zp4RtS9qkOulurwO092guED-OaHVVaxya2A828AjwvwWKEY4wQFG2e5NpdMnNuDnSbXj8GLfIk%24> [ietf[.]org] -- Dott. 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<http://secure-web.cisco.com/1hh0eN_BAkbWjP90OaCpwTT7yg3uHN2jLHBy-L-4ZSropNzIP87F9Q6kFuY0_P1Xg6auUwy--5_v6vHTc4Yyigxz62Je2jxdBe2X7ey3B_5FPGInj0lWpVwQCa7aF8peVSEmG7zmEWhYicYoaCvzftcycHORhGR_k3NXky4vhXN_yZpAnoHkSCdycXx2CL-Z-gj1BTCn39bEUufb1lVGOC3C5TXL45bTbUMjcrPmMba95xQdHM_29g3XaMGL_lwwgYDX1GXO3nnCpBGnY8oYZNah_jgHHTnpncEmdCypli8I/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1VJNzul8oOVy0axQAsfGDcaVYfYH61JeeATrCPoiEdB5BlRT8VIgK_X_9pp1m4OFk9Hj8JAW-K_PNLn6zrwoUvuHO-EVNepmIKAzFAtNAGywpvA624Wklg7y8UxAmDuRZ2yb8l5RLOrzqB_kK4jlVZ6DfOKVaA000Z8ekIfBUn9FcZn2IMpHqEVZ9IPixBVoiCEOtZfq8ukkkO7XsgBbF8B3zcd6YYNjHGFjPxBI1ynaUKtaaolHlijJ5fNLtEECBNT3B38Gtqd2EDbZ3xnphXaX6BAI6ClB0WucRfGEy3-0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
- [regext] Redacting JSContact uid in RDAP - Updated Mario Loffredo
- Re: [regext] Redacting JSContact uid in RDAP - Up… Hollenbeck, Scott
- Re: [regext] Redacting JSContact uid in RDAP - Up… Marc Blanchet
- Re: [regext] Redacting JSContact uid in RDAP - Up… Mario Loffredo
- Re: [regext] Redacting JSContact uid in RDAP - Up… Andrew Newton
- Re: [regext] Redacting JSContact uid in RDAP - Up… Mario Loffredo
- Re: [regext] [Ext] Re: Redacting JSContact uid in… Gustavo Lozano Ibarra
- Re: [regext] [Ext] Re: Redacting JSContact uid in… Mario Loffredo
- [regext] Fwd: [Ext] Re: Redacting JSContact uid i… Mario Loffredo
- Re: [regext] Fwd: [Ext] Re: Redacting JSContact u… Gould, James
- Re: [regext] Fwd: [Ext] Re: Redacting JSContact u… Jasdip Singh