I don’t understand the confusion regarding the text in 9083. It might not include BCP 14 key words, but I believe the intention is clear. Looking at the two sentences:
“A response to a "help" request will include identifiers for all of the specifications supported by the server.” *will include* isn’t a BCP 14 MUST, but I don’t think it’s ambiguous. “A response to any other request will include only identifiers for the specifications used in the construction of the response.” Similarly, *will include only identifiers for the specifications used in the construction of the response* describes the identifiers that are to be included in any other response. If a client needs to implement something other than 9083 to correctly interpret and process a response, any identifier that describes a specification that’s needed to “understand” the response will be included. If that’s not clear, what am I missing? Scott From: regext <regext-boun...@ietf.org> On Behalf Of Antoin Verschuren Sent: Monday, February 19, 2024 10:42 AM To: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> Cc: regext <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search 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. So, if I understand this correctly, the chairs asked the document shepherd to declare that there were no substantial changes made during WGLC between versions 05 and 07 and all raised issues were addressed. The answer below I interpret as: We would like the permission from the WG to not only substantially change draft-ietf-regext-rdap-rir-search in a next version that we want to send to the IESG, but on top of that also clarify or even change the interpretation of RFC 9083. If this is the question, then we need to have a discussion what this will mean to other documents and it’s interpretation of RFC 9083 first, and perhaps even write this clarification down in a separate document if that is needed. When that is done and consensus is reached, we must issue a new WGLC for the next version of draft-ietf-regext-rdap-rir-search if that will contain these substantial changes suggested by the WG. In order to reach consensus, all comments and support during a complete WGLC must be for a stable document. Otherwise we don’t know if people agree with what version of the document and which interpretation of RFC 9083. Regards, Antoin Op 19 feb. 2024, om 13:07 heeft Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org<mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org>> het volgende geschreven: Hi Antoin, after a private discussion between James, Tom, Jasdip and me, we agreed on the following: 1) Some minor edits that don't substantially change the draft but clarify the meaning of some sentences will be done in next version 2) We would like the WG members express their own opinions on the substantial matter below. RFC 9083 states the following for rdapConformance included in non-“help” RDAP responses: · The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response. · A response to any other request will include only identifiers for the specifications used in the construction of the response. There is no normative language that specifies exactly what identifiers are included in the response, where there is the language of “hints” and “used in construction of the response”. Below are options for what identifiers are included in the “rdapConformance” array that could be captured in the RDAP Extensions draft: Option 1) only the extension identifiers used to build the response with regard to the fields Option 2) all of the extension identifiers that impact the build of the response, hence with regard to fields, values, and query members / query parameters used for the response (i.e. Option 1 + extension query identifiers and extension identifiers impacting response values) Option 3) all of the extension identifiers defined by specs used to build the response (i.e. Option 2 + any extension identifier defined by referenced specs) Option 1 corresponds to a literal interpretation of normative language in RFC 9083, while Option 2 extends its meaning. Option 3 is further extensive and corresponds to the interpretation used in rir-search. To better explain their position, the authors asked me to add the following note (please Tom and Jasdip elaborate, if you think I missed something or didn't present correctly your point of view): "documents may mandate specific behaviour around identifiers for the purposes of signalling, and it's fine for this sort of thing to override the requirement above. (nro_rdap_profile_asn_flat_0 and nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document itself requires implementations to pick one or the other, and that's fine.)" Best, Mario Il 05/02/2024 15:35, Antoin Verschuren ha scritto: Hi All, After some prolonged discussion, the chairs will now close this working group last call that should have ended 11 December 2023. We have had comments and approval during WGLC from 4 working group participants and the document shepherd and no objections. That has lead to 2 new versions of the document during WGLC that started with version 05. The document shepherd for this document is Mario Loffredo. In order for the document to progress and sent to the IESG, the document shepherd will need to do a final review of the following: 1. Please confirm all suggested changes have been addressed in version 07. 2. Please ask James Gould to confirm his changes have been addressed as he promised to do another review. 3. Make sure the Nits are addressed. 4. Confirm that all changes between version 05 and version 07 are editorial and not substantive. 5. When all the above concerns are addressed, please write the document shepherd writeup. Thanks to everyone that contributed to this review! Regards, Jim and Antoin REGEXT WG Co-Chairs Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org><mailto:ietf=40antoin...@dmarc.ietf.org> het volgende geschreven: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: RDAP RIR Search https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/<https://secure-web.cisco.com/1y-DXafGi3NUAj9-2hq2-lsBB688_gQa7CF1EPBaBpih9b2Pg6XsKr9n5kBClMYetINGykPnWC1x1F1ZWllxRAmXzG19hie5dJbS0rT3MaP-F0hDGLx0LR7IZkSVZrVcvkM_OZ3dy58dRlHKVq2Z-ZRFlmRA80Fii3vythjOCDjHM5frYBwREl6DfIaa9bHqkliVY5JNqBAkLOJ_srbn53DlaFSNAqt9K5JOW4CAROanmYZJizF59IyZnrf-cmAjX2E8GQM6v56nPNGvgFbhrbHS7UvFELkX17wiC0P9vPTI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-search%2F05%2F> Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 11 December 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Mario Loffredo. Thanks, Jim and Antoin REGEXT WG Co-Chairs _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1RSSt_L5NVeXUHSTSkUmcwdjQ33EbPolQC0K1-mCrSDJV_Jxxku1hLXyShI2-Fok-v_cpHXouyBE2vT_zJW5vSH2E9lDi1CxsykHXStSpr0JFQjrY8lGPfbPS5l4Ps6h1AyrHfzL8VgUUtd-QPPZbE1cp0o2hRWdsTtSO9wEgsBGAu1QonXjmBydTuAo5k2kO_bF3yny9-SczynfGcD8iFjWJ0dWVOs2uQfO-Nl71Mxm85hrDArUXiNCLECv5mdPqatFjKPbZCZI8hRRIgaGdSk_73Z_CVvIuRMuYKeNeXeU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1RSSt_L5NVeXUHSTSkUmcwdjQ33EbPolQC0K1-mCrSDJV_Jxxku1hLXyShI2-Fok-v_cpHXouyBE2vT_zJW5vSH2E9lDi1CxsykHXStSpr0JFQjrY8lGPfbPS5l4Ps6h1AyrHfzL8VgUUtd-QPPZbE1cp0o2hRWdsTtSO9wEgsBGAu1QonXjmBydTuAo5k2kO_bF3yny9-SczynfGcD8iFjWJ0dWVOs2uQfO-Nl71Mxm85hrDArUXiNCLECv5mdPqatFjKPbZCZI8hRRIgaGdSk_73Z_CVvIuRMuYKeNeXeU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> -- Dott. Mario Loffredo Senior Technologist 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/1NSQ6r7HnJIV2wMkbBxmV5FVeqBHgxcq-R5HKO7pxGUe42WWVmHCFTmtiUQ6LEK4TImLvYnNgSHyk-kHjAtsserWuNGXcE0J3_HeUTTFhr_fxIDtGFTqPve0lZs4ttEc7dqjGhGUUONEE1ts7kmyBB61C6ymeCcKjZzxEMym7UxXt77WRSLQwpl6v6ccZJlXAHR-wmlmDWF-YR0LzaNwt8n2lMtqy5iN_CgSsM5xlYLu181YgvMGO2zlSoNQuL-xdTJdHCQLRFWBe__cUl_aD347jvK0GvrNcdKeXj8zTAiw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
