[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05

["Andrew Newton (andy)" <[e-mail]>]

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 <[e-mail]> 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) <[e-mail]>
> Date: Thursday, July 18, 2024 at 3:19 PM
> To: REGEXT Working Group <[e-mail]>, Jasdip Singh <[e-mail]>, [e-mail] <[e-mail]>
> 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
>
>
>
>