Gavin, Upon my first review, I find the extension to be an interesting aggregation concept. I’m not exactly sure why the client wouldn’t just make separate calls to get the same information. With that, I have the following feedback:
1. I don’t see the purpose of the <ro:include> child element of the <ro:info> element, where the child elements can be directly under the <ro:info> element. 2. It would be good to include a mapping of the response elements with the command elements, along with an indication of existence or ability to include the information. Such as including the <ro:registrant>, <ro:contacts>, and <ro:orgs>, <ro:ns>, <ro:hosts>, and <ro:other> elements as children of the <ro:infData> element with some indication of existence or a disclosure issue. The objects can be contained under those ro elements. 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: regext <regext-boun...@ietf.org> on behalf of Rick Wilhelm <rwilh...@pir.org> Date: Thursday, March 30, 2023 at 1:16 AM To: Gavin Brown <gavin.br...@centralnic.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt Hi Gavin, Just gave an initial read. I’m not quite sure of the use-case that would motivate this, other than trying to eliminate round-trips. But maybe that’s the point. :-) One bit of initial feedback: In section 3, I was expecting to see “MUST” in this sentence: “When determining whether to include a related object in the <ro:infData> element, servers SHOULD apply the same access control rules that are used to determine whether a client is authorised to perform an <info> on those objects.” I don’t understand why the protocol would allow the server to use different access rules for the same data accessed via a different path. Thanks Rick From: regext <regext-boun...@ietf.org> on behalf of Gavin Brown <gavin.br...@centralnic.com> Date: Monday, March 27, 2023 at 8:03 PM To: regext@ietf.org <regext@ietf.org> Subject: [EXTERNAL] [regext] Fw: New Version Notification for draft-regext-brown-epp-related-objects-00.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. ________________________________ Hi all, Here is the first draft of an EPP extension designed to allow servers to include information about "related" objects in responses to <info> commands. >From the introduction: "The EPP <info> command allows clients to retrieve information (subject to authorisation) about objects in the repository. Since EPP operates on a strictly per-object basis, and since objects may be related to one another, a client may often need to issue multiple <info> commands in order to retrieve the data it needs to carry out its operation. This document describes an extension to the <info> command that allows clients to request the inclusion of information about related objects in responses. This allows clients to retrieve all the required information about an object in a single round-trip to the server." Feedback welcome! Regards, ________________________________ From: internet-dra...@ietf.org <internet-dra...@ietf.org> Sent: 27 March 2023 11:59 To: Gavin Brown <gavin.br...@centralnic.com> Subject: New Version Notification for draft-regext-brown-epp-related-objects-00.txt A new version of I-D, draft-regext-brown-epp-related-objects-00.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-regext-brown-epp-related-objects Revision: 00 Title: Extensible Provisioning Protocol (EPP) Extension for Related Objects Document date: 2023-03-27 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-regext-brown-epp-related-objects-00.txt<https://secure-web.cisco.com/1UuICI4-LMuT514V2g0vSai9Qy7_F4DXC0Q9Jqg2smogRqFQb0ZiPPgBrB_EbKgrY25n8y8xzb8RwmRSly6__c0Q5ZxLgo4QTpOqtiOu-zZUUBXpdVneDxPJWv7q9zB_rK4-lYduTao5R32TrhJlVNOCQutguavZWGHsXQMeTTOes8aveUrdNglv8pbDMdCEcLSQHfkMpFynP6a1U1oyLtA6NVCwZr1RxA8-7CzP8ioiX2WC55BhRUNBuA3gKzOsvTaZMR8XuB9BH2kzf2zSlGqAqTNWfj_3nx8s9l2zLtA8/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FsdudCXD2y5HM5AXU6-4PX%3Fdomain%3Dietf.org> Status: https://datatracker.ietf.org/doc/draft-regext-brown-epp-related-objects/<https://secure-web.cisco.com/13CqhRV1ujbQc0RAQArF2mOeg3lUh0SFtiaS5zgTly24BcKxWbiKAKOs2iVqsZK8l3pM-UP8SmVFbJNNIKElCQmoXjrf_ANzj6a4HZI4wIn847iGS6ETcqcw7bZMtDfvwb88QZrrez6YZCsbGNhxinXRgiXdKgsBSAm80sDZmasEsG5U-xaVsNK5aKFAgeghgZwggiSg5SPG8nnK5ctJNMWI4gwgMZTuDgv4VC48ciLHKcWnddyGmtZFzVH0lGcXOVLEEhPInvhU2ECC5RBJOfmnmedlxiLPZwNtHA5MmmXg/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F8PTqCYENz5S61YLTGYXV8%3Fdomain%3Ddatatracker.ietf.org%2F> Htmlized: https://datatracker.ietf.org/doc/html/draft-regext-brown-epp-related-objects<https://secure-web.cisco.com/1An-fCwwTvgEtfXH0S2xBl0JNhYIygtaemA-8x0QZskUvXhpsNJ1Vb46OmVows8OJznIDDoBfR88HKjwZSx7W7EiKZO6ERbq4GNPp8YZrxAwjOuZ3nvB2FsvtfQsv7EXCvw7ZaSZ6UQBluFJ5u3Mq7UJtBoh6YoxwJtsbKvQXNh9Cu942Kli2lvbgKXfOpOq7t0kIO8FN-fgvM2p6reow4q8Ru2oe75gjGpfPrb9lNv7C-DDoTdQYGyoUmPQL5QhBxjAydZyZ0zhpOP7rFo-7IlqLieOgptSr33UoWRED_y8/https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FiY-dCZ6NA0io4v5tKoblA%3Fdomain%3Ddatatracker.ietf.org> Abstract: This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to request the inclusion of related objects in responses to <info> commands. The IETF Secretariat
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
