Hi Dale, From: Dale R. Worley <wor...@ariadne.com> Date: Friday, April 18, 2025 at 10:41 AM To: Jasdip Singh <jasd...@arin.net> Cc: gen-...@ietf.org <gen-...@ietf.org>, draft-ietf-regext-rdap-geofeed....@ietf.org <draft-ietf-regext-rdap-geofeed....@ietf.org>, last-c...@ietf.org <last-c...@ietf.org>, regext@ietf.org <regext@ietf.org> Subject: Re: Genart last call review of draft-ietf-regext-rdap-geofeed-09 Jasdip Singh <jasd...@arin.net> writes: > Thank you for your review of this draft. Please find below our comments.
Thanks for considering my comments. On all but one of my comments, having told you of my concerns, I willingly defer to the authors' judgment regarding them. > > 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".) > > [JS] Thanks, per your suggestion to clarify further, we have added the > following paragraph after the first paragraph in section 2.3: > “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.” Pardon me for fixating on this, but "is able to return it to the client" seems to me to be too vague, and allows implementors to not deliver URLs for arbitrary reasons. Thinking about this a bit, I would like to see the statement be "... and is permitted to return it to the client by the privacy requirements ...". That requires implementors to either return the URL or have a privacy consideration explaining why not, and does not allow them to create other reasons for not returning the URL. With that constraint, if the server advertises geofeed1 conformance and the client does not receive a URL for an object, the client can conclude that either the server does not possess a URL or the server is forbidden from delivering the URL to the client by privacy considerations. And thinking about it more, I suspect that is what you mean by "able to". In any case, having stated my concern twice, I leave the matter in the author's hands. [JS] Thanks, we as authors would prefer “able to” to afford implementors unforeseen leeway beyond the privacy considerations. Regards, Jasdip
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
