Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-regext-rdap-geofeed-09 Reviewer: Dale R. Worley Review Date: 2025-03-28 IETF LC End Date: 2025-04-02 IESG Telechat date: [not known] Summary: This draft is on the right track but has open issues, described in the review. Major issues: In some cases, there are deficiencies of exposition that amount to technical issues. Specifically: There are no requirements placed on a server that lists "geofeed1" in the "rdapConformance", rendering the list item indicative but not something that allows the recipient to reliably deduce any particular information. The privacy considerations are stated tepidly, so one could not assert that an RDAP server is out-of-conformance to this document not matter how poor its privacy practices are. At the least, RFC9632's privacy considerations need to be imported explicitly. The document says that the geofeed URL must be HTTPS, which allows the requester to obtain the geofeed document with encryption-in-transit. But it seems to be that this document should require that the geofeed document MUST NOT be obtainable using the parallel HTTP URL. (Having completely parallel HTTP and HTTPS URLs is the default configuration for most HTTP/S servers.) Minor issues: Nits/editorial comments: Various aspects of the exposition could be improved, as noted below. ---------------------------------------------------------------------- 1.1. Requirements Language Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol. "..." in examples is used as shorthand for elements defined outside of this document. These seem to me to better belong at the head of section 2.4. They are really notes about the examples, and presumably the reader knows that an example isn't specificational. (Or is there a practical problem with people considering examples to be specificational, so we have to insert a warning in "Requirements Language" for them to understand that point?) 2.2. Geofeed Link An example scenario where more than one geofeed link object would be returned is when the server is able to represent that data in multiple languages (see the "hreflang" member of a link object). This is awkwardly phrased, as the hreflang member is not a document which one can go "see". Perhaps something like An example scenario where more than one geofeed link object would be returned is when the server is able to represent that data in multiple languages. (In such a case, the server SHOULD provide "hreflang" members for the link objects.) 2.3. Extension Identifier This section needs to clarify some points. RDAP servers are free to use any registered media type or link relation in a standard response (without implementing any particular extension). Given that, what is the distinction between using geo links in responses and "using/implementing the geofeed1 extension"? A server that uses this extension identifier MUST include it in the "rdapConformance" array for any lookup or search response containing an IP network object, as well as in the help response. The text says The additional value of the extension identifier here is that it signals to the client that the server hosts geofeed URLs for its IP network objects. This is useful where a client receives an IP network object without a geofeed link object, because in that case the client can infer that no geofeed data is available for that object, since the server would have provided it if it were available. Strictly, "The additional value of the extension identifier" should be "The additional value of including the extension identifier in the rdapConformance array". But more treacherously, there doesn't seem to be a requirement that if (1) the server lists "geofeed1" and (2) the server has a geofeed1 document for a network object, then (3) it MUST include a link to the document in all responses concerning that object. That requirement is required to support "the client can infer that no geofeed data is available for that object". I think the desired meaning is that the presence of the extension identifier in rdapConformance means the server WILL return geofeed1 links whenever it has that information. But in that case, document needs is to state in section 2.3 just before the second paragraph: If the server includes "geofeed1" in the rdapConformance list, it MUST, in any response concerning a particular IP network object for which the server possesses a geofeed1 object, provide a geofeed1 link to that geofeed1 object. (Or maybe that should be "posses a URL for a geofeed1 object".) Note that an RDAP server may make use of the "application/geofeed+csv" media type and the "geo" link relation defined in this specification in its responses without including the "geofeed1" extension identifier in those responses, because RDAP servers are free to use any registered media type or link relation in a standard response (without listing any particular extension). But the use of the extension identifier signals to the client that the server host provides geofeed URLs for any of its IP network objects for which it possesses one. In that case if the server provides none the client can infer that no geofeed data is available for that object, since the server would have provided it if it were available. 2.4. Example The following is an elided example of an IP network object with a geofeed link object: "elided" isn't quite right, as "elide" means "to remove". I think you want "abbreviated" but check with the Editor. It might be interesting and useful to include a second link for information in another language, demonstrating the use of "hreflang". 4. Privacy Considerations When including a geofeed file URL in an IP network object, it is expected that the service provider publishing the geofeed file has followed the guidance from Section 7 of [RFC9632] to not accidentally expose the location of an individual. Many jurisdictions have laws or regulations that restrict the use of "personal data", per the definition in [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document. This needs to be considered more carefully. Certainly "it is expected" is too vague and permissive. For instance, the existence of an HTTPS URL for the geofeed file means that there is an HTTPS server that will deliver the file to a requester, meaning that the HTTPS server publishes the file. The RDAP server *itself* does not publish the file by distributing the URL. However, in practice, implementing this document in an RDAP server may usually be done in parallel with implementing a server that distributes geofeed documents, and all of these privacy considerations apply to the latter. It seems to me that the reference to RFC 9632 should be made stronger, perhaps changing the first paragraph to All of the privacy considerations of section 7 of RFC 9632 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. 5. Security Considerations [RFC9632] requires an HTTPS URL for a geofeed file. The geofeed file may also contain an RPKI signature. Besides that, this document does not introduce any new security considerations past those already discussed in the RDAP protocol specifications. It seems to me you want to add that the geofeed file MUST NOT be retrievable via an HTTP URL, in order to minimize eavesdropping of its contents. (This seems to be stricter than the requirements of RFC 9632 sec 6 para 2.) 6.4. Structured Syntax Suffixes Registry For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified in +csv. I don't like the phrasing "as specified in +csv", as that sounds like "+csv" is a document. That phrase does seem to be a common slang abbreviation of "as specified in the document that specifies +csv", but I think we should use the more formal phrasing "as specified for +csv". I also don't like that these sentences do not explicitly name RFC 7111, which is the document that specifies text/csv. By comparison, a number of other entries do, in a sense, name the relevant documents, in an oddly implicit way. E.g., "The syntax and semantics of fragment identifiers specified for +cbor-seq SHOULD be as specified for "application/cbor-seq". (At publication of [RFC8742], there is no fragment identification syntax defined for "application/cbor-seq".)" Although in a peculiar way, it doesn't really point to RFC 8742 (as it says, 8742 contains no such thing), but implicitly to "every document that updates 8742", which is the needed reference. But the phrasing "as specified for +csv" does mean "go look at the entry for +csv", which points to "References: [RFC4180], [RFC7111]" and implicitly to "RFC 4180, RFC 7111, and all RFCs that update those", which is sufficient. 7. Implementation Status NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC. IMO better to phrase it "the reference to RFC 7942 in section 10.2". For a few minutes, I was wondering why the reference to 7942 given 3 lines below this note was specifically mentioned for removal when the removal of section 7 implicitly includes that. Or probably better, perhaps have a separate note in section 10.2, so that note is near the place that modification needs to be done. Comparing this note to the RFC Editor with the similar note for section 9: (Remove this section before publication.) It seems to me that in any one draft, all notes to the Editor should be introduced by exactly the same marking, so the Editor can trivially scan the document to find all such notes (and to eventually verify that they have all been removed). [END] _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
