Last Call Review of draft-ietf-regext-rdap-geofeed-09
review-ietf-regext-rdap-geofeed-09-opsdir-lc-dhody-2025-04-01-00

# 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 art@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