Mohamed Boucadair has entered the following ballot position for draft-ietf-regext-rdap-geofeed-11: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Jasdip, Tom, Thank you for the effort put into this specification. Thanks also for supplying an operational considerations section. Thanks to Dhruv Dhody for the OPSDIR review and the authors for engaging and converging. Unless I’m mistaken, I don’t remember this draft was shared with OSPAWG, where RFC9092 and RFC9632 were developed. Nothing blocking, though. # 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. # 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 :-) ## 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://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml lists extension labels with different patterns (e.g., with or without “underscore”, and so on). # Introduction ## (nit) Please Expand RDAP + add authoritative reference CURRENT: [RFC8805] and [RFC9632] detail the IP geolocation feed (commonly known as 'geofeed') file format and associated access mechanisms. This document specifies how geofeed URLs can be accessed through RDAP. ## 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. # “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. # 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. # (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. # 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. ## 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 # Privacy: incidents may happen, but the requirement does not need to include “accidentally” OLD: All the privacy considerations from Section 7 of [RFC9632] apply to this document. In particular, the service provider publishing the geofeed file MUST take care to not accidentally expose the location of any individual. NEW: All the privacy considerations from Section 7 of [RFC9632] apply to this document. In particular, the service provider publishing the geofeed file MUST take care to not expose the location of any individual. # Security considerations ## Maybe point to RFC9632 for fetching/using geofeed considerations ## 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? # 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? Cheers, Med _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
