Hi Jasdip, Thanks for handling my comments!
Regards, Dhruv On Thu, Apr 17, 2025 at 12:35 AM Jasdip Singh <jasd...@arin.net> wrote: > Hi Dhruv, > > > > Thank you for your review of this draft. Please find below our comments. > > > > Also, please see [1] for the diffs in the updated draft. > > > > Thanks, > > Jasdip & Tom > > > > [1] > https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10 > > > > > > *From: *Dhruv Dhody via Datatracker <nore...@ietf.org> > *Date: *Tuesday, April 1, 2025 at 2:38 PM > *To: *ops-...@ietf.org <ops-...@ietf.org> > *Cc: *draft-ietf-regext-rdap-geofeed....@ietf.org < > draft-ietf-regext-rdap-geofeed....@ietf.org>, last-c...@ietf.org < > last-c...@ietf.org>, regext@ietf.org <regext@ietf.org> > *Subject: *Opsdir last call review of draft-ietf-regext-rdap-geofeed-09 > > 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. > > > > [JS] Indeed. :) > > > > ## 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. > > > > [JS] Thanks for this observation! Since the RDAP extension ids are > presently opaque with no explicit versioning meaning to be derived, we > would prefer to change the intended usage verbiage in section 6.2 by > removing “version 1 of” as follows: > > > > “Intended usage: This extension describes a method to access the IP > geolocation feed data through RDAP.” > > > > > - Use the boilerplate text verbatim from RFC 8174. > > > > [JS] Thanks, updated. > > > - 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'? > > > > [JS] Mentioning this is a precedent for the recent RDAP related drafts; to > be explicitly clear in case a reader was expecting a more compact JSON. > However, it is a good point about using “this protocol”. We have changed it > to “this specification”. Hope that reads better. > > > > - 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. > > > > [JS] That’s a good point. Removed that expired reference. > > > > - "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'. > > > > [JS] Since the relevant Links section from RFC 9083 is referenced in the > previous paragraph, changed “REQUIRED” to “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? > > > > [JS] Since the multiple-languages scenario is the only one we can think of > where more than one geofeed link objects are possible, in our opinion, it > would be clearer to prohibit more than one geofeed link objects otherwise. > To that effect, updated that paragraph as follows: > > “An IP network object returned by an RDAP server MAY contain zero or more > geofeed link objects, though typically an IP network will have either no > such link objects or only one. The scenario where more than one geofeed > link object could be returned is when the server is able to represent that > data in multiple languages. In such a case, the server SHOULD provide > "hreflang" members for the geofeed link objects. Except for the > multiple-languages scenario, the server MUST NOT return more than one > geofeed link object.” > > Hope this helps clarify. > > > - "...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 :) > > > > [JS] Good point. Updated. > > > - "Person & email address to contact for further information" - should > this be > WG or a...@ietf.org? > > > > [JS] Reviewing some previous media type registrations, it seems to vary > from individuals to the WG. To your suggestion, changed it to the REGEXT WG. > > > > Also, "Author/Change Controller: IETF" should be used for > Sections 6.3 and 6.4 > > > > [JS] OK. Replaced “Change Controller” field with "Author/Change > Controller” in section 6.3 and added "Author/Change Controller” in section > 6.4. > > > > - The formatting of "Fragment Identifier Considerations:" in section 6.4 > is off. > > > > [JS] Thanks, fixed. > > > ## Nits > > - Add reference for rdapConformance (RFC 9083?) > > > > [JS] Indeed. Done as part of addressing feedback from another IESG review. > > > > ## 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 > > > > [JS] Thanks, they are down-referenced now. > > > >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
