Jasdip, I provide responses embedded below, prefixed with “JG-“.
Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Jasdip Singh <jasd...@arin.net> Date: Monday, June 17, 2024 at 10:14 AM To: James Gould <jgo...@verisign.com>, "mario.loffr...@iit.cnr.it" <mario.loffr...@iit.cnr.it> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt 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 James, Please find my comments below. Thanks, Jasdip From: Gould, James <jgo...@verisign.com> Date: Monday, June 17, 2024 at 7:47 AM To: Jasdip Singh <jasd...@arin.net>, mario.loffr...@iit.cnr.it <mario.loffr...@iit.cnr.it> Cc: regext@ietf.org <regext@ietf.org> Subject: Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt I have option 5, which is to get more implementation experience with RFC 9537. I believe that the ICANN clients can implement RFC 9537 using the required “name” and “method” members in the redacted extension, as I demonstrated with the simple JSON clients. There will be many server implementations leveraging the registered “redacted name” entries by the gTLD registrars and registries. [JS] Curious what your assessment of Option 3 (name-related) is? “Option 3: As for the current name approach in RFC 9537, set the expectation that clients would need to hardcode the redacted name to field name mapping for IANA-registered names, periodically check the IANA registry for newer name registrations, and that mapping unregistered names to field names could be problematic in terms of a client missing some.” IIRC, the hardcoding part was not clear from your Java examples. One promise of JSONPath was to help avoid such hardcoding in clients, no? JG – Clients don’t need to hardcode the name values by simply displaying them to the end user, which was done in both simple JSON clients that I provided. A client may leverage the RDAP JSON Values “redacted name” as well as the “redacted reason” registrations to key off for extra processing. This is the same that is done with using the well-known RDAP JSON Values registrations (e.g., “status”, “notice and remark type”, “event action”, “role”, “domain variant relation”), which can be used in many ways (configuration, code lists, hardcoded). A client needs to consider new RDAP JSON Values for all types, but in general they can either display them or filter them to only values that they recognize. These clients and servers may or may not leverage the optional JSONPath expressions (“prePath”, “postPath”, “replacementPath”). I don’t consider removing support for JSONPath expressions as an issue of correctness of Option 2, since the JSONPath expression members are optional in RFC 9537. [JS] Are we implying that it is ok for incorrectness to lurk in a spec if those portions are optional? IMO, like Andy, other implementors could also end up wasting their time with JSONPath expressions unless they are forewarned somehow in the redaction spec to not try implementing the incorrect portions. Further, AFAIU, except for the removal method, JSONPath seems required for other methods. It would be responsible of us to address the incorrectness in the spec, starting with at least forewarning about it. JG – I don’t understand your reference to “incorrectness”, where my assumption is that a server including the optional JSONPath expressions would somehow be considered incorrect. The JSONPath expressions can be made correct by the server since they have both the unrelated and redacted response. The client may not be able to process the “prePath” JSONPath expression if they don’t have a template unredated response to work from, and in that case they can ignore it. JSONPath members (“prePath”, “postPath”, “replacementPath”) are clearly defined as optional in section 4.2 ““redacted” Member” of the RFC and there is no normative language that conflicts with that in the sections that describe the redaction methods. There are many examples of features defined in other RFCs that had no adoption or had very little adoption (e.g., protocol extension in RFC 5730, data-collection policy in RFC 5733, key data interface in RFC 5910, account balance and credit limit in RFC 8748) over the years. [JS] IMO, we should not conflate lack of adoption with incorrectness. The latter should concern us, no? JG2 – There is no incorrectness from the server-side, but the “prePath” JSONPath expression may be infeasible for the client to render without additional information from the server, such as a template unredacted response. If the servers and the clients decide not to support the JSONPath expressions (“prePath”, “postPath”, “replacementPath) there is no compliance issue with the RFC, but a feature that is not adopted like the other RFC features that I highlighted. There are many more examples to choose from. With implementations starting with RFC 9537, I would first see how those implementations work out. [JS] Since we now know that the portions of the spec are incorrect, IMO, it should help to take a poll of, or discuss, various moving-forward options, to avoid implementation pain down the line. JG – What portions of the spec are incorrect? Andy’s draft references client implementation issues with JSONPath, which is not an issue of correctness but of feasibility. I believe the JSONPath can be leveraged, but time will tell. The JSONPath expressions were made optional based on the consensus process of the working group and is not a showstopper for implementation. From: Jasdip Singh <jasd...@arin.net> Date: Saturday, June 15, 2024 at 2:50 PM To: Mario Loffredo <mario.loffr...@iit.cnr.it> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt 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, Mario, sorry for my late reply. Agree that JSON objects seem more conducive to pinpointing redaction than JSON arrays, and preferring JSONPath over JSONPointer. But, overall, the challenge remains for us to somehow address the JSONPath deficiencies identified in Andy’s paper, to end up with a normative, correct redaction spec for RDAP data. Please allow me to explain how we might be able to move forward here. Imagine a JSON response from an RDAP server as a text document, and with parts of that text redacted. Since such a document would be structured for RDAP, beside human-friendly perception of redacted text (like we cannot see redacted words or lines in a redacted text document), we would need precise pinpointing of fields whose values are fully or partially redacted, especially if one were to build a general-purpose RDAP client serving all industries (be it DNRs, RIRs, space, etc.). We thought JSONPath could but seems deficient, especially for prePath scenarios and wildcard and recursive selectors. IMO, we have few options to help achieve a normative, correct redaction spec: Option 1: Try addressing deficiencies identified in Andy’s paper vis-à-vis the JSONPath and name approaches. Option 2: Gut out the JSONPath approach completely to improve correctness of RFC 9537. Option 3: As for the current name approach in RFC 9537, set the expectation that clients would need to hardcode the redacted name to field name mapping for IANA-registered names, periodically check the IANA registry for newer name registrations, and that mapping unregistered names to field names could be problematic in terms of a client missing some. Option 4: Look for another way to do redaction that guarantees redacted field name pinpointing correctness. We might eventually need a WG poll on these options, or another set of options, but let me try assessing above options: Doesn’t look Option 1 could be fully achieved, especially because of prePath scenarios and wildcard and recursive selectors. Option 2 helps. Option 3 won’t make general-purpose client implementors happy. Option 4 might need to work with some assumptions/constraints, like what JSON types (out of string, number, boolean, array, and object) it guarantees redaction pinpointing accuracy for when it comes to RDAP data. In other words, there does not seem to be a redaction panacea out there. :) Thanks, Jasdip From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Tuesday, June 11, 2024 at 6:27 AM To: Jasdip Singh <jasd...@arin.net>, Andrew Newton (andy) <a...@hxr.us>, regext@ietf.org <regext@ietf.org> Subject: Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Hi Jasdip, I'm inclined to think that the problem lies in how the JSON content is structured rather than the language used to select JSON values. There exist two standard languages to select JSON values, namely JSONPointer and JSONPath. The former is mostly inapplicable to RDAP as the values that are likely redacted are located in the entity object but entities associated to an object are represented through an array where the entity role matters instead of the index. The latter works much better but the selection of values in the RDAP response generates language expressions that are very tricky to process because the jCard format makes use of jagged arrays where items are selected by property name or by index. The additional issue in redacting arrays is that redacting an item by removal results in rearranging the array items. On the contrary, redacting an object member by removal doesn't impact on the other members. Definitely, objects i.e. maps should be preferred to arrays as much as possible because they fits better the redaction process . If you can't avoid arrays, you should consider to redact the entire array whenever the items must be redacted. Sorry if I recall once again the implementation choice Robert and I made when we had to deal with localizations in JSContact but it comes to mind easily. Localization as well as redaction requires to select a JSON value. To facilitate localizations, we decided to use maps to represent almost all collections in JSContact and mandate the localization of the entire array of name and address components. IMO, we should do likewise to best accomplish redaction in RDAP. Here in the following two JSONPath expressions extracted from a redacted domain lookup response using jCard [1] and JSContact [2] respectively: "prePath": "$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]"<mailto:$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]>, "prePath": "$.entities[?(@.roles[0]=='technical')].jscard.phones.voice"<mailto:$.entities[?(@.roles[0]=='technical')].jscard.phones.voice> Please note that in the case of a redacted entity lookup response, the latter would include only the name selector. Obviously, using maps to represent the collections of entities associated to objects would be very helpful but some issues connected with the entity role should be fixed first (i.e multiple entities having the same role and single entites having multiple roles). However, representing the contact data through a fully object-oriented format, no matter if it will be JSContact or something else, would make redaction handling by clients as well as the overall handling of the RDAP response much easier. Best, Mario [1] https://rdap.pubtest.nic.it/domain/meep.it<https://secure-web.cisco.com/1EufMWCq2of7t82pkxPzZQNBqVpR4AIfG9meUSBIYQEAxEQeHDKRlseJ0yEZHTeIhdCDDhPxFDPe5aL0DxGJGSm5q_TUgqIPmWXaLeS85CEEQq7bUmBs1iptcC_-i-GYccOgc34MDRQx1QXOANY_FY6bl6I20OCWAi98tRcLf8tC0vvpxX7-RC7dM_atAM8s1PCqrsLK0zfXroTyAhTvLjkww_MO-vavbiU9P6JCuGj6-gR1W6DlytZje97Om7Z8vTLM_J8iytT0vEbHmpT7KxYspgXWF4A0-sDkQ9L2yZuA/https%3A%2F%2Frdap.pubtest.nic.it%2Fdomain%2Fmeep.it> [2] https://rdap.pubtest.nic.it/domain/meep.it?jscard=1<https://secure-web.cisco.com/1QMvAVm7TYbuUghjwAf9NsvfsNNE1PYTsIqFt4IafWBMjDLEM6CaIf9X7vNB5Hcf6FgQdoexgfVULOVjOMyZD9WV-drlfvb0pfB9x0KSOv3Te-RLYJ0FNm2Y7dsUlvJqIKJ00CODjxqjbIS0oy2XHbNOydxa6iPWcWDc9Y8kRPfThiVGc-KeA5c_UZCzN5961eP_YwRFAIiCdTkEZVw3zauH47uHry9_AUBjpg9ns0xIhX71LiANW6EpoarRWdZ7qpB_3dtQFWdCBNZ1T1ZnJPJMCr2x0Iyv5OscqRcqviOY/https%3A%2F%2Frdap.pubtest.nic.it%2Fdomain%2Fmeep.it%3Fjscard%3D1> Il 11/06/2024 06:28, Jasdip Singh ha scritto: Hi. It is a bit unfortunate for us as a WG that we missed the fundamental shortcomings of the JSONPath usage for redaction, as highlighted in the draft below. Especially, the “prePath” portion where a client would have no idea about how to apply that expression to the response in hand. Though the JSONPath use is optional in RFC 9537, that does not help escape the fact that portions of this extension are inherently incorrect. Not sure what the path forward is from here but IMO it would help to address the highlighted issues; either as RFC 9537 bis, or an entirely new approach that does not depend on JSONPath. Jasdip From: Andrew Newton (andy) <a...@hxr.us><mailto:a...@hxr.us> Date: Wednesday, May 29, 2024 at 6:51 AM To: regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org> Subject: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Hi all, Over the past several months, we have been implementing the RDAP redaction extension, RFC 9537. This I-D describes the issues we have encountered. -andy -------- Forwarded Message -------- Subject: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Date: Wed, 29 May 2024 03:45:43 -0700 From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: Andy Newton <a...@hxr.us><mailto:a...@hxr.us> A new version of Internet-Draft draft-newton-regext-rdap-considerations-on-rfc9537-00.txt has been successfully submitted by Andy Newton and posted to the IETF repository. Name: draft-newton-regext-rdap-considerations-on-rfc9537 Revision: 00 Title: Considerations on RFC 9537 Date: 2024-05-29 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.txt<https://secure-web.cisco.com/1Yq7IPhJZdoiKCZ_ULXyOoBQiSnM6Lkh4-bQx66qxIVq-9F9nP-cVfF26gzOYtNBqr8KYRWc2p2BfnpDXXdUF18b3gRjw6FJ6JYMsoEa7ELfQu9ndOtsunqM4VUUwmixXIaJs1JJuWn5QFdlN7M6hCbut5QgjMRqutshYDijjW-flQusoaqS-Ue4QjzApPfOalMM8uNx18j1e3f6OiXaBHykxdw_r-FRMrUH3i7ToGcWDwf_I7SE7rZoWNbOnqu3g_2YLQJnifcJfko3p37Q3iocY3sYnrVjtGS3aSu3sviM/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00.txt> Status: https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/<https://secure-web.cisco.com/10mmYqlZTaebafgwBBV40W1sYZjhA2AvXsOgXd5xCHF6m5bJkGg7DCP4h5aiIGlE-eU3VJK79gjuOnnMQqQGP73jgNxYLlS8CpmhVKxCa6NxMhLABVULKP6hqO9lvMw1o1ReiVyPjzQjJSzFFi3llvnK8GLolpE03mV9zBPBnmkaqUtThregzKskWM0aVEqLTkqOCyDMUvQ5XZE-HcWf82V2PJl5qmefulcAOfCGKm3JtilCPgx6xhRovnjHfr45UGGOD7pA0JGKkMfqkaOTArw28_4B3sGrFnWN75hUlK40/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-considerations-on-rfc9537%2F> HTML: https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html<https://secure-web.cisco.com/1EecrxubV6KBffnGqMiLBOZ6UVnTMS5rro3w6OX10_KinuBBiCWlowZlkENbIGPim7GjZTM4MYLVdfRwHDrlV-Q-fl_PbKqOs2BQmsWlrtVqYisG0Ra6gCpQy7ioDgYqCQOurevxYhTkiyl7kZXw14HAnNQuekAN4XHAMJsNHBa7K_5hylZWNvYzeX6iNYNHR0EBBliRIUVthZm89SqsbC5DyyID1ZPA-8ehg0zmTMPwFceXz2ju97kP0TxX_RANOe1wf_8bZ_3MMMY7CAIBbV4PQMcFPh8bTirmGFg5MNuA/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00.html> HTMLized: https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537<https://secure-web.cisco.com/1MKjEAxFrjuFhDW0AyQrXERa2geOrjx3XNODFgMi3HABR5Y89_xHSzZ6MmvD2SrzgbH_WfmqOE1nKWC5S8jijbuA9pU7CZOSoxvVNjrTt0UXgn_OEeglqPf1M_4afjxiqF3idcUEGSIr80zRZs6hEbE8HTqZfywvZwZZJqzj2nlU9bDasfq2G5Snf2BOBgJPn75cJRnGBrlvehb2AmeKmNhIdPNwFs_ZTvOK75AF4EPfcvE_hBYjO-o-8GK1EIC4LUseArvPPqi7oW-mZN9AbDAkm6lWBGCRE80d-9o82Ivc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-newton-regext-rdap-considerations-on-rfc9537> Abstract: This document discusses client implementation issues relating to RFC 9537, “Redacted Fields in the Registration Data Access Protocol (RDAP) Response”. The considerations in this document have arisen from problems raised by two separate teams attempting to implement RFC 9537 in both an RDAP web client and an RDAP command line client. Some of these problems may be insurmountable, leaving portions of RFC 9537 non-interoperable between clients and servers, while other problems place a high degree of complexity upon clients. The IETF Secretariat _______________________________________________ regext mailing list -- regext@ietf.org<mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org<mailto:regext-le...@ietf.org> -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1itviCWtpdUa2uLZj1NragR74jOeUd45_NJA292eWkdEVshH3QrKa7DUko0guKQ8nbQs3do15kpBC2UgcV9wfCMNJ_-GXmYvBEuiqRBbNheJ9QCNg1kLpeW2SpF7Ia9MXDFHoap6yfOzWzKLLN9yKq3_a5W4qtQqwhLtekVUuluEWCA7vLmKf68o5dw9IHfyd6h_hqra9x-Gtj0O5yyJKQUR71mjoN0coz5BSCVNGzhjQ2Sc7sm5rtWMCMq5KOrmFm5PTGNvhtf-V0oTEZooJO59CSEinTNWHSmwlePD_ros/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
