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 <noreply@xxxxxxxx>
Date: Tuesday, April 1, 2025 at 2:38 PM
To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>
Cc: draft-ietf-regext-rdap-geofeed.all@xxxxxxxx <draft-ietf-regext-rdap-geofeed.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, regext@xxxxxxxx <regext@xxxxxxxx>
Subject: Opsdir last call review of draft-ietf-regext-rdap-geofeed-09Reviewer: 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 art@xxxxxxxx?
[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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
