Hi Andy, Thanks for these insightful questions. Tom and I discussed them. Let me try answering. :)
Tom, please add/subtract if needed. Jasdip From: Andrew Newton (andy) <a...@hxr.us> Date: Thursday, July 18, 2024 at 3:19 PM To: REGEXT Working Group <regext@ietf.org>, Jasdip Singh <jasd...@arin.net>, t...@apnic.net <t...@apnic.net> Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05 Hi Jasdip and Tom, I like this draft, but I do have a couple of questions. 1. This draft mentions the ip network object class but none of the other object classes. Are those not allowed by this extension? What happens if a server uses a geofeed link in a domain object? Should that be covered under a different extension? What if bigisp.com wants to allow other network operators to find their geofeeds just by looking up bigisp.com in RDAP? That seems like it might be a useful thing. If not, are clients to ignore processing the link if found any object other than an ip network? [JS] Since the goal of this extension has been to complement the RFC 9092 Update [1] semantics by providing a point of presence in RDAP, we’d like to keep the spec limited to IP network objects, given some of the RIRs are already enabling geofeed link additions as part of network registrations. The bigisp.com domain scenario is interesting, and some verbiage could have been added to allow geofeed links for other object classes if the authority of the holder of these non-network objects extended over the networks in question. That might be possible for reverse domains in the RIRs but not sure how that authority could be ascertained for forward domains in the DNRs when the network data is in another registry. We think that a more focused, new extension for such a scenario would do a better job from spec angle. To your “If not, are clients to ignore processing the link if found any object other than an ip network?”, we think yes since clients are expected to ignore non-standard data. [1] https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-9092-update-11 2. Do the IPs in the geofeed file have to be in the IP boundaries of the ip network object class where the link is found? That doesn't look to be a requirement, but perhaps this should be explicitly stated. [JS] From what we are noticing at the RIR level is that the service providers generally create a geofeed file with a one-to-many relationship with multiple networks. Requiring IP boundaries would impede how it is presently done. 3. What is a client to do if it finds the geofeed link in a response without a "geofeed1" extension? Is it suppose to treat the link as if the response had a "geofeed1" extension? The expectation of client processing should be more explicit in this allowable corner case. [JS] Glad you noted this edge case. After seeing James’ feedback on replacing RECOMMENDED with MUST for the extension id inclusion, we think MUST would be better since it 1) helps eliminate any confusion on RECOMMENDED being misconstrued as optional, and 2) brings this extension more in line with the new “marker” extension definition from the RDAP Extensions draft [2]. If MUST is acceptable, that still leaves the scenario of a server returning a geofeed link without this extension id in the response but that would not be in line with this spec and the client is free to proceed as it would for any non-standard data in a response; most likely, ignore. [2] https://github.com/anewton1998/draft-regext-rdap-extensions/blob/main/draft-regext-rdap-extensions.md
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
