Hi Orie, Thanks for your review! Tom and I discussed it. Please see our comments below.
Regards, Jasdip From: Orie <o...@or13.io> Date: Tuesday, January 28, 2025 at 12:37 PM To: regext@ietf.org <regext@ietf.org> Subject: [regext] AD Evaluation: draft-ietf-regext-rdap-geofeed-08 # Orie Steele, ART AD, comments for draft-ietf-regext-rdap-geofeed-08 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-rdap-geofeed-08.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md ## Comments ### geofeed1 ``` 13 This document defines a new Registration Data Access Protocol (RDAP) 14 extension, "geofeed1", for indicating that an RDAP server hosts ``` Are we expecting geofeed2 ? If space is not a huge concern, a more qualified name would seem advisable. rdap_geofeed_v1? [JS] There could be “geofeed2” in the future but not for any foreseeable time. As for using “rdap_geofeed_v1”, we would prefer sticking with “geofeed1”. Please allow us to explain. If we were to use something like “rdap_geofeed_v1”, we would have preferred “rdapGeofeed1” instead for the following reasons: * Typically, RDAP extensions don’t start with “rdap” [1] since they are generally used to prevent naming collision in RDAP requests and responses and adding “rdap” in front would seem extraneous when naming new URI segments, JSON members, and object classes for an RDAP extension. However, since “geofeed1” is more of a “marker” extension [2] for geofeed web links, it could be ok to start with “rdap”. * Since the Extensions draft is now not recommending using underscore character [3], it would be better to camel-case, as in “rdapGeofeed1”. * Typically, we have avoided “v” in front of versions [1]. [1] https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml [2] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-04.html#name-profile-and-marker-extensio [3] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-04.html#name-syntax However, having a more qualified name like “rdapGeofeed1” here is not useful, primarily for the reasons set out in the first bullet point above. Generally, in the places where it is used, it appears to give additional clarity around the meaning: e.g., there might be other NRO profiles, so saying that the RDAP response is using the "nro_rdap_profile" could be helpful. We also think the consistency aspect here with existing extension ids is important. ### MAY contain zero or more? ``` 154 An IP network object returned by an RDAP server may contain zero, 155 one, or multiple geofeed link objects. An example scenario where ``` Consider making this normative: An IP network object returned by an RDAP server MAY contain zero or more geofeed link objects. [JS] Thanks, will do. ## Nits ### Reads awkwardly ``` 249 inetnum objects (per [RFC9632]), clients who find a geofeed link 250 object within an IP network object MUST ignore geofeed data from that 251 link that is outside the IP network object's address range. ``` that link that -> any link that ? [JS] Since “that link” points to “a geofeed link object within an IP network object”, using “any link” instead would not be correct. We would like to propose the following text to remove any ambiguity: “… clients who find a geofeed link object within an IP network object MUST, after retrieving the geofeed data from that link, ignore any entry where the entry's IP address range is outside the IP network object's address range.” Will that work?
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
