Hi Andy, You are right; my answer for question #2 was incomplete. Per your input, we added the following to a new “Operational Considerations” section in the to-be-published next version<https://github.com/jasdips/rdap-geofeed/compare/main...wglc> of the draft:
“It is common for a resource holder to maintain a single geofeed file containing the geofeed data for all of their resources. The resource holder then updates each of their network object registrations to refer to that single geofeed file. As with geofeed references in inetnum objects (per [@!RFC9092]), clients who find a geofeed link object within an IP network object MUST ignore geofeed data from that link that is outside the IP network object's address range.” Hope this helps clarify. Thanks, Jasdip From: Andrew Newton (andy) <a...@hxr.us> Date: Monday, July 22, 2024 at 3:30 PM To: Jasdip Singh <jasd...@arin.net> Cc: REGEXT Working Group <regext@ietf.org>, t...@apnic.net <t...@apnic.net> Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05 Hi Jasdip, Can you point to the spot in opsawg-9022-update that states clients are to ignore non-standard data? Also, I see this in the opsawg-9022-update: "When reading data from an unsigned geofeed file, one MUST ignore data outside the referring inetnum: object's address range." That to me indicates that clients should not process any geofeed link found in anything other than an "ip network", but it also means the should not process any geofeed link data in an "ip network" where the geofeed data is outside the network boundary of the "ip network" object. -andy On Sat, Jul 20, 2024 at 9:20 AM Jasdip Singh <jasd...@arin.net> wrote: > > 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
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
