Hi Tom,
Thanks for the follow-up. Thanks also for sharing the ongoing WG efforts on the
extensions.
I also checked 11/13 diff. I agree with your proposed resolution for each point.
We may update the intended usage as follows:
OLD:
* Intended usage: This extension describes a method to access the IP
geolocation feed data through RDAP.
NEW:
* Intended usage: This extension describes version 1 of a method to access
the IP
geolocation feed data through RDAP.
If you are to release a new version, you may fix this nit:
OLD: Fetching and making use of geofeed data is out of scope
NEW: Fetching and making use of geofeed data are out of scope
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Tom Harrison <t...@apnic.net>
> Envoyé : mercredi 4 juin 2025 23:57
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
> Cc : The IESG <i...@ietf.org>; draft-ietf-regext-rdap-
> geof...@ietf.org; regext-cha...@ietf.org; regext@ietf.org;
> gavin.br...@icann.org
> Objet : Re: Mohamed Boucadair's Yes on draft-ietf-regext-rdap-
> geofeed-11: (with COMMENT)
>
>
> Hi Med,
>
> Thanks for your review and feedback.
>
> On Wed, May 21, 2025 at 01:05:59AM -0700, Mohamed Boucadair via
> Datatracker wrote:
> > # Why this spec is needed?
> >
> > ## Position the specification
> >
> > In order to help readers to glue the various pieces in this
> space,
> > including, e.g., text that would mirror the following part from
> RFC9632 would be helpful:
> >
> > At the time of publishing this document, geolocation providers
> have
> > bulk WHOIS data access at all the RIRs. An anonymized version
> of
> > such data is openly available for all RIRs except ARIN, which
> > requires an authorization. However, for users without such
> > authorization, the same result can be achieved with extra RDAP
> > effort.
> >
> > ## Fetching and using data
> >
> > I would add a mention early in the doc to make it explicit
> whether
> > fetching and making use of geofeed is in scope/out of scope.
>
> Updated introduction:
>
> [RFC8805] and [RFC9632] detail the IP geolocation feed
> (commonly
> known as 'geofeed') file format and associated access
> mechanisms.
> While [RFC9632] describes how a registry can make geofeed URLs
> available by way of a Routing Policy Specification Language
> (RPSL)
> [RFC2622] service, the Regional Internet Registries (RIRs) have
> deployed Registration Data Access Protocol (RDAP) ([RFC7480],
> [RFC7481], [RFC9082], [RFC9083]) services as successors for
> RPSL
> for Internet number resource registrations, and maintaining
> feature parity between the two services supports client
> transition
> from RPSL to RDAP in this context. To that end, this document
> specifies how geofeed URLs can be accessed through RDAP. It
> defines a new RDAP extension, "geofeed1", for indicating that
> an
> RDAP server hosts geofeed URLs for its IP network objects, as
> well
> as a new media type and a new link relation type for the
> associated link objects.
>
> Fetching and making use of geofeed data is out of scope for the
> purposes of this document. See [RFC8805] and [RFC9632] for
> further details.
>
> > # Extension name and version
> >
> > CURRENT:
> > Registration Data Access Protocol (RDAP) Extension for Geofeed
> Data
> > draft-ietf-regext-rdap-geofeed-11
> >
> > Abstract
> >
> > This document defines a new Registration Data Access Protocol
> (RDAP)
> > extension, "geofeed1", for indicating that an RDAP server
> hosts
> > geofeed URLs for its IP network objects.
> >
> > ## I noted that the mention of "version 1" was mentioned in a
> previous
> > version but then removed.
> >
> > ## Without that mention, the label of the extension "geofeed1"
> may be
> > intriguing as to why we don't use simply "geofeed"?
> >
> > ## Should "Version 1" be mentioned in the title as the extension
> is
> > expected to cover version 1 of the extension, anyway :-)
>
> The "1" is included in the extension identifier to signal that
> there may be a successor extension in the future. As with
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-rir-
> search%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3502f9d3b
> 7914f02d74208dda3b2cb29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638846710502684344%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> %3D%7C0%7C%7C%7C&sdata=QAyJHConT2V9%2BQiLmZYYkZVVsuq8HC%2ByBBeXntxv
> Wsc%3D&reserved=0,
> we've added text about this being version 1 of the extension, and
> that there may be new versions in the future.
>
> > ## BTW, I checked for guidance on the extension naming & version,
> but
> > didn't find something useful on this. I understand that this is
> > handled as an opaque value and no meaning associated with the
> > extension labels. I noticed however that the registry
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> ww.
> > iana.org%2Fassignments%2Frdap-extensions%2Frdap-
> extensions.xhtml&data=
> >
> 05%7C02%7Cmohamed.boucadair%40orange.com%7C3502f9d3b7914f02d74208dd
> a3b2cb29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388467105027
> 04808%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
> C&sdata=TBBpB4NgjUj3qOJrMVBBMqjFodvImcFgW8UbpIms8fA%3D&reserved=0
> lists extension labels with different patterns (e.g., with or
> without "underscore", and so on).
>
> On this topic, there are ongoing efforts to make things more
> consistent in this space. See
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-
> extensions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3502f
> 9d3b7914f02d74208dda3b2cb29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> 7C0%7C638846710502719007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=%2BwCp5G7vQGpvJjC045%2BRVXQOfQCLLpU6FBBS
> IphbFNc%3D&reserved=0
> and
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-
> versioning%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3502f
> 9d3b7914f02d74208dda3b2cb29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> 7C0%7C638846710502731673%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=bPYdaUKuUi1NWtoH5egxbncxDlbv%2FcVcKIqOlD
> VFnY8%3D&reserved=0.
>
> > # Introduction
> >
> > ## (nit) Please Expand RDAP + add authoritative reference
>
> See earlier updates to introduction.
>
> > ## Normative language
> >
> > CURRENT:
> > Indentation and whitespace in examples are provided only to
> > illustrate element relationships, and are not a REQUIRED
> feature of
> > this specification.
> >
> > I understood this is somehow a convention in RDAP, but I still
> think
> > the use of normative language here is not correct. Combing both
> "not"
> > and "REQUIRED" is making things worse.
>
> "REQUIRED" has been changed to "required".
>
> > # "MUST.except .." construct
> >
> > CURRENT:
> > Except for the multiple-languages scenario, the server MUST
> > NOT return more than one geofeed link object.
> >
> > As this is not an absolute requirement, this use is not
> consistent
> > with 2119, which says;
> >
> > ==
> > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that
> the
> > definition is an absolute prohibition of the specification.
> >
> > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
> that
> > there may exist valid reasons in particular circumstances when
> the
> > particular behavior is acceptable or even useful, but the full
> > implications should be understood and the case carefully
> weighed
> > before implementing any behavior described with this label.
> > ==
> >
> > Please update accordingly.
>
> "MUST NOT" has been changed to "SHOULD NOT". However, see our
> reply to Ketan's comments on this point.
>
> > # Response customization
> >
> > CURRENT:
> > If the server includes "geofeed1" in the "rdapConformance"
> array,
> > then for any response concerning a particular IP network
> object for
> > which the server possesses a geofeed URL and is able to return
> it to
> > the client, the server MUST include a corresponding geofeed
> link
> > object in the response.
> >
> > Are there cases where customized responses may be generated
> (client
> > profiles, or the like)? If so, I think this behavior should be
> > conditioned by absence of policy.
>
> This is an example of what "is able to return it to the client" is
> meant to cover. Given the number of reviewers who have flagged
> this as an issue, we have updated this part to:
>
> If the server includes "geofeed1" in the "rdapConformance"
> array,
> then for any response concerning a particular IP network object
> for which the server possesses a geofeed URL and is able to
> return
> it to the client (i.e. is not compelled to omit it due to
> regulatory constraints or similar), the server MUST include a
> corresponding geofeed link object in the response.
>
> > # (nit) Standard response meaning
> >
> > CURRENT:
> > registered media type or link relation in a standard response
> > (without implementing any particular extension).
> >
> > Is "(without implementing any particular extension)" explaining
> what
> > is meant by "standard response"? Maybe add "i.e." or the like.
>
> The parentheses have now been removed.
>
> > # Operational Considerations
> >
> > ## Fetching ops matters and avoid too frequent queries
> >
> > We may consider add a pointer to rfc9632#section-6 for additional
> > matters, especially this part:
> >
> > To prevent undue load on RPSL and geofeed servers, entity-
> fetching
> > geofeed data using these mechanisms MUST NOT do frequent real-
> time
> > lookups.
>
> Similar text has now been added.
>
> > ## What is meant by "IP network lookup"?
> >
> > OLD:
> > When an RDAP client performs an IP network lookup
> >
> > Maybe
> >
> > NEW:
> > When an RDAP client queries for information about IP networks
>
> The reference that follows this excerpt clarifies the meaning.
>
> > # Privacy: incidents may happen, but the requirement does not
> need to
> > include "accidentally"
>
> This word has been removed.
>
> > # Security considerations
> >
> > ## Maybe point to RFC9632 for fetching/using geofeed
> considerations
>
> A general reference to this document has been added.
>
> > ## HTTPS
> >
> > CURRENT:
> > A geofeed file MUST be referenced with an HTTPS URL, per
> Section 6 of
> > [RFC9632].
> >
> > This is already mandated by 9632. Maybe better to cover
> implications
> > on RDAP clients. For example, can we say that clients MUST ignore
> > geofeeds that are not HTTPS?
>
> This was suggested during an earlier review, and our thinking here
> is that we should not modify the 'base' geofeed specifications in
> this sort of way in a document that is just trying to make the
> geofeed data available via another mechanism. (We could say "RDAP
> clients MUST ignore non-HTTPS geofeed URLs", but if that guidance
> is sensible in the RDAP context, it would be equally sensible in
> the RPSL case, so it would act as a sort of implicit modification
> of those base
> specifications.)
>
> > # Implementation Status: Broken URL
> >
> > Thank you for providing this section.
> >
> > However, I got this error message:
> >
> > ==
> > HTTP ERROR 404 Not Found
> > URI:/STATUS:404MESSAGE:Not FoundSERVLET:default ==
> >
> > Is there any update to the status since then?
>
> The URL is the base RDAP server URL, so it's not intended to be
> called as-is. We've now updated the URL reference to the release
> notes for the server.
>
> -Tom
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
