Inline: On Wed, Jan 29, 2025 at 10:25 AM Jasdip Singh <jasd...@arin.net> wrote:
> 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. > OK. > > > > > ### 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? > yes, perhaps this might read slightly better: “… clients who find a geofeed link object within an IP network object MUST resolve the associated geofeed data and ignore any entry where the entry's IP address range is outside the IP network object's address range.” The MUST is having an awkward interaction with "retrieving" here, not sure if it is your intention to make retrieving (dereferencing) a normative requirement. dereferencing comes with other possible requirements, see: https://datatracker.ietf.org/doc/html/rfc9110#section-4.3.4 / https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.2
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
