[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
I've reviewed the draft again. It's ready to go, +1. Scott > -Original Message- > From: James Galvin > Sent: Friday, July 12, 2024 5:12 PM > To: REGEXT Working Group > Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-rdap-geofeed-05 > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > The document editors have indicated that the following document is ready for > submission to the IESG to be considered for publication as a Proposed > Standard: > > An RDAP Extension for Geofeed Data > https://secure- > web.cisco.com/1BdJOsA4eq9fiLugHUFxhFVg8AaG4hoL9JRKnBcLNlnkk2Cp7w > uWZDJNKSBLS5Zy0pV7CXRaXORlN1AxWCdxoua1FjWCd- > wmEidBeKm5FiZh5zAJ6soJtn- > qW7x1o1aJ1YSjr3bLnXF0niFjv1P0rKG9y3TLe5QpUkl6V9k5cjrNQJgCrd0MChc > j2zpWDooYzmDjkGkGJxdQ5XjUi33lqNGsun-- > v3PNYo7vDSamTkGg6RoomlZNoFlg- > em9fVvG5y80_sCpXSfW1Ewh8KOs02QyD76159BNxEV_4GIj- > 4aM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap- > geofeed%2F > > Please indicate your support or no objection for the publication of this > document by replying to this message on list (a simple “+1” is sufficient). > > If any working group member has questions regarding the publication of this > document please respond on the list with your concerns by close of business > everywhere, Friday, 2 August 2024. This WGLC has been extended to 3 weeks > because of the IETF120 meeting. > > If there are no objections the document will be submitted to the IESG. > > The Document Shepherd for this document is Gavin Brown. > > Thanks, > > Antoin and Jim > REGEXT WG Co-Chairs > > ___ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-rdap-rir-search-09
Hi Scott, On Mon, Jul 15, 2024 at 05:19:07PM +, Hollenbeck, Scott wrote: > A few small things: > > The last call notice refers to the draft as "considered for > publication as a Best Current Practice". The draft describes itself > as a Standards Track candidate. I believe that's just an error in > the last call notice. > > [I-D.ietf-regext-rdap-reverse-search] is now RFC 9536. > > I'd like to see something more in the Security Considerations > section that specifically notes how search functionality increases > the risk of disclosing information that wasn't explicitly requested. > We have this text in RFC 9082: > > "Search functionality also increases the privacy risk of disclosing > object relationships that might not otherwise be obvious. For > example, a search that returns IDN variants [RFC6927] that do not > explicitly match a client-provided search pattern can disclose > information about registered domain names that might not be > otherwise available. Implementers need to consider the policy and > privacy implications of returning information that was not > explicitly requested." > > Maybe just note that the Security Considerations described in RFC > 9082 also apply here. Thanks, updates have been applied per the above (see attached for the current diff from -09). -Tom <<< text/html; charset=us-ascii: Unrecognized >>> ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
Have reviewed this document. Per what is stated in section 3, it's not clear to me what servers should do whenever the geofeed file exposes the location of an individual. Neither Section 7 of [I-D.ietf-opsawg-9092-update] seems to clarify this point as it contains only a generic warning (see below): *... In publishing pointers to geofeed files as described in this document, the operator should be aware of this exposure in geofeed data and be cautious* Should RDAP servers omit to present the geo link or should they remove from the linked geofeed file the information related to the location of individuals ? Does it mean that the geo link can be redacted ? If so, which redaction method should be used? Best, Mario Il 12/07/2024 23:12, James Galvin ha scritto: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: An RDAP Extension for Geofeed Data https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Friday, 2 August 2024. This WGLC has been extended to 3 weeks because of the IETF120 meeting. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Gavin Brown. Thanks, Antoin and Jim REGEXT WG Co-Chairs ___ regext mailing list --regext@ietf.org To unsubscribe send an email toregext-le...@ietf.org -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web:http://www.iit.cnr.it/mario.loffredo ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05
Hi Mario, From: Mario Loffredo Date: Tuesday, July 16, 2024 at 9:56 AM To: regext@ietf.org Subject: [regext] Re: WGLC: draft-ietf-regext-rdap-geofeed-05 Have reviewed this document. Per what is stated in section 3, it's not clear to me what servers should do whenever the geofeed file exposes the location of an individual. Neither Section 7 of [I-D.ietf-opsawg-9092-update] seems to clarify this point as it contains only a generic warning (see below): ... In publishing pointers to geofeed files as described in this document, the operator should be aware of this exposure in geofeed data and be cautious Should RDAP servers omit to present the geo link or should they remove from the linked geofeed file the information related to the location of individuals ? [JS] Since maintaining the public geofeed files from privacy angle, per the guidance from RFC 9092 update, is expected to be the concern of the ISPs, and not the RDAP server operators, we should clarify this in section 3. How about updating the first paragraph in that section as follows? “When including a geofeed file URL in an IP Network object, an RDAP server operator SHOULD follow the guidance from Section 7 of [I-D.ietf-opsawg-9092-update] to not accidentally expose the location of an individual.” > “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 [I-D.ietf-opsawg-9092-update] to not accidentally expose the location of an individual.” Does it mean that the geo link can be redacted ? If so, which redaction method should be used? [JS] IIRC, we discussed this earlier and decided that redaction does not factor here since the geofeed files are public to start with. Please see section 7.3 change history. Thanks for your review, Jasdip ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
