[regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08

[Jasdip Singh <[e-mail]>]

Hi Orie,

Version 09 of this draft now submitted.

Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-09

Thanks,
Jasdip

From: Jasdip Singh <[e-mail]>
Date: Monday, February 3, 2025 at 10:36 AM
To: Orie <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
Hi Orie,

Thanks. We have incorporated your feedback [1].

We’d next update the media type registration based on the following feedback from Alexey Melnikov on the media-types mailing list:


“As text/csv has "charset" as an optional parameter and has the following text associated with it:
      In accordance with RFC 6657<https://datatracker.ietf.org/doc/html/rfc6657> [RFC6657<https://datatracker.ietf.org/doc/html/rfc6657>] the charset
      parameter SHOULD be used, and if it is not present, UTF-8 SHOULD
      be assumed as the default (this implies that US- ASCII CSV will
      work, even when not specifying the "charset" parameter).
it would be good to state explicitly in the media type registration template that it is not used, because content is always in UTF-8.”
And, then submit the next version of this draft.

Jasdip

[1] https://github.com/jasdips/rdap-geofeed/blob/main/draft-ietf-regext-rdap-geofeed.md

From: Orie <[e-mail]>
Date: Saturday, February 1, 2025 at 4:18 PM
To: Jasdip Singh <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
Hi Jasdip,

That text works for me.

Regards,

OS

On Sat, Feb 1, 2025 at 11:06 AM Jasdip Singh <[e-mail]<mailto:[e-mail]>> wrote:


From: Orie <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 31, 2025 at 9:42 AM
To: Jasdip Singh <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
<snip>


## 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

No, retrieving is not a normative requirement. Will the following work?
  “... clients who find a geofeed link object within an IP network object and opt to retrieve the data from the associated link MUST ignore any entry where the entry's IP address range is outside the IP network object's address range.”
Jasdip