Reviewer: Dhruv Dhody Review result: Has Nits # OPSDIR Review of draft-ietf-regext-rdap-geofeed-09
I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written to improve the operational aspects of the IETF drafts. Comments that are not addressed in the last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last-call comments. The document includes a dedicated Operational Considerations section. Thanks for including that. ## Minor - Section 6.2 mentions that 1 in "geofeed1" stands for version 1. It would make sense to state that much earlier in the Introduction itself. - Use the boilerplate text verbatim from RFC 8174. - I am unsure why this text is needed - "Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol."; Isn't it a standard JSON practice? Also, does it make sense to call this geofeed extension 'this protocol'? - Is there a need to add a reference for "(Section 3.11 of [I-D.shafranovich-rfc4180-bis])". The I-D is expired, and the section is about common implementation concerns with comments. - "In RDAP, the "value", "rel", and "href" JSON members are REQUIRED for any link object." -> If this is coming from RFC 9083, then rephrase this by including a reference and removing 'REQUIRED'. - I understand that typically you will get one geofeed link object, but you allow for more. In the case of more (and not just the multiple language case), is there any guidance for applications on what to do if they get multiple link objects? - "...it may be useful to define new RDAP extensions..." ; Is it useful or not? The reason given makes sense to me; why not just say that it is useful :) - "Person & email address to contact for further information" - should this be WG or a...@ietf.org? Also, "Author/Change Controller: IETF" should be used for Sections 6.3 and 6.4 - The formatting of "Fragment Identifier Considerations:" in section 6.4 is off. ## Nits - Add reference for rdapConformance (RFC 9083?) ## Downref * Downref: Normative reference to an Informational RFC: RFC 4180 * Downref: Normative reference to an Informational RFC: RFC 7111 * Downref: Normative reference to an Informational RFC: RFC 8805 Thanks! Dhruv _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
