[OPS-DIR]Re: Opsdir last call review of draft-ietf-regext-rdap-geofeed-09

[Dhruv Dhody <[e-mail]>]

Hi Jasdip,

Thanks for handling my comments!

Regards,
Dhruv

On Thu, Apr 17, 2025 at 12:35 AM Jasdip Singh <[e-mail]> 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 <[e-mail]>
> *Date: *Tuesday, April 1, 2025 at 2:38 PM
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *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 [e-mail]?
>
>
>
> [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.
>
>
>
>