From ripedenis at gmail.com Thu Aug 4 14:25:16 2022 From: ripedenis at gmail.com (denis walker) Date: Thu, 4 Aug 2022 14:25:16 +0200 Subject: [db-wg] geolocation and current purposes Message-ID: Colleagues I have spent some time thinking about the wording of the current purpose of the RIPE Database in relation to geolocation services. In some ways the purposes are very loosely written. That means they are open to interpretation. I think they can be interpreted to cover the "geofeed:" attribute. Some people have expressed this view but it is not sufficient to just say it, you need to justify the viewpoint. I will attempt to do that. "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" The first point is the 'etc'. That means the example list is not exclusive. It doesn't even define the types or categories of coordination. So basically any coordination between network operators is included. 'Facilitating' means 'to make things easy'. So the database exists to make any coordination activity between network operators easy. So in what ways is "geofeed:" going to make it easy for network operators to coordinate some activity? One of the ways network operators have talked about how they want/need to use "geofeed:" data is to provide content based on location of an IP address. If a content providing network operator wishes to offer this content to anyone in a specific location, that can be seen as a coordination activity. The content provider can coordinate with other network operators to establish that their customers are within this location so they can access this content. If this interpretation is accepted by the community then the context has changed. The legal team can now reassess their advice in the context that the use of the "geofeed:" data is now covered by the existing database purposes. But there are other questions that the legal team also needs to consider. The "geofeed:" attribute references data external to the RIPE Database that neither the RIPE NCC nor the RIPE community has any control, management or perhaps even influence over. This data may contain PII. Although the maintainer of that external data is responsible for its content, does the RIPE NCC have any (joint) accountability or liability as the data controller and facilitator of the RIPE Database? Nic Handles are considered to be PII as they reference objects that contain PII. But these objects are also contained within the RIPE Database. The geofeed csv files are external to the RIPE Database. Do the references to them still constitute PII? Given that we are currently discussing a policy proposal governing the use of personal data in the RIPE Database, here we have a mechanism where resource holders can publish full postal address details of end users who are natural persons and link that published data to the resources in the RIPE Database. Given that these files are published by holders of RIPE resources and referenced by the RIPE Database, should the content of these files follow RIPE policies? (I'm not suggesting any validation of the contents, but perhaps resource holders should be responsible for applying policies to this content.) The T&C is a legal document. In the event of any dispute, lawyers make a lot of money by analysing and interpreting documents like this. Although the loosely written purposes may now be interpreted to cover geolocation data, there are still significant problems with the way the purposes are written. A review would still be beneficial. The T&C are mostly in the background during day to day operations. Just as the terms of an insurance policy can be irrelevant for years. The one time it matters is when you want to make a claim, or in the case of the database if someone ever makes a legal challenge over any aspect of its use or content. At that point, if the purposes can be widely interpreted, then the outcome is uncertain. It would be advantageous to all parties if the purposes were clear and precise with little room for interpretation. Whenever this issue is raised some people make the cynical comments that there has never been any legal challenge and there is no queue of people waiting to do so and common sense has always prevailed (in the past). It only needs one. Other RIRs have been involved in legal actions. Don't wait until your house is flooded before checking your insurance policy to see if you are covered. Another clear issue with this purpose's wording is that use of contact details in the database is only allowed by network operators to contact other network operators ("between network operators"). In this sense the purpose is very precise. Use of contact details by the public, non member organisations, investigators, CSIRT teams (unless they are also operators) and LEAs is not allowed under these T&C. Something to think about... cheers denis co-chair DB-WG From cfriacas at fccn.pt Thu Aug 4 19:24:36 2022 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 4 Aug 2022 18:24:36 +0100 (WEST) Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: Hi, A small comment inline: On Thu, 4 Aug 2022, denis walker via db-wg wrote: (...) > So in what ways is "geofeed:" going to make it easy for network > operators to coordinate some activity? One of the ways network > operators have talked about how they want/need to use "geofeed:" data > is to provide content based on location of an IP address. Yes. Although *some* geolocation providers INSIST that their location assessment is better than the owner's network. They do this by ignoring messages or form data sent by owners. Keeping the attribute in the RIPE database may show ANYONE what is the location the owner says it is the correct location. And hopefully that should be the mandatory source for this information. > If a content providing network operator wishes to offer this content > to anyone in a specific location, that can be seen as a coordination > activity. The content provider can coordinate with other network > operators to establish that their customers are within this location > so they can access this content. If this interpretation is accepted by > the community then the context has changed. The legal team can now > reassess their advice in the context that the use of the "geofeed:" > data is now covered by the existing database purposes. Yes, please :-) Cheers, Carlos From william.sylvester at addrex.net Thu Aug 4 22:49:55 2022 From: william.sylvester at addrex.net (William Sylvester) Date: Thu, 4 Aug 2022 20:49:55 +0000 Subject: [db-wg] 2022-01 Personal data in the RIPE Database Next Steps Message-ID: Dear Database Working Group Members, The four-week discussion phase for the policy proposal "2022-01 Personal data in the RIPE Database" ended on 15 July. In agreement with the proposer, we have decided tomove the proposal into the Review Phase but postponed its start to the end of August. This was done keeping in mind that the upcoming vacation period might prevent participation in the discussion and the timely publication of the RIPE NCC Impact Analysis. Please note that the RIPE Database WG Co-Chair Denis Walker is the author of this policy proposal, hence he is not taking part in the decisions regarding consensus. The RIPE NCC Policy Officer will announce the start of the Review phase together with the publication of the policy draft and impact analysis. For reference, here?s a short summary of the discussion so far: Ronald Guilmette posted many messages strongly opposing the proposal, advocating instead for the accurate verification of WHOIS data and for not publishing personal data for privacy reasons only in special legitimate cases. His main points of disagreement were: a) The transparency of the database would suffer, affecting LEAs? and researchers? work. b) The postal address is managed solely by the resource holder and not by the RIPE NCC. c) The postal address can already be concealed using, e.g., a PO box. d) Only a minority in the community is asking for the postal address not to be published, which doesn?t justify the effort and cost of implementation. e) More contact details might fall under the same new proposed rule in the future. f) Accepting the proposal would change the historical practice of the RIPE Database. g) There is no legal basis for the proposed changes. The proposer addressed the concerns above as follows: a) The transparency achieved is questionable if it's based on unverified data. b) End Users are not always aware that their address has been entered in the RIPE Database by the LIR. c) Addresses like those of PO boxes do not help LEAs orresearchers. d) Implementation could be supported using the existing ARCs. e) There is no mention of further changes in the proposal. f) Historical practice should not be treated as a requirement. g) Legal aspects should be further clarified by the RIPE NCC legal team. Niels Bakker supported the proposal as it would allow the RIPE NCC to offer a way to prevent LIRs from entering End Users? personal data in the RIPE Database. Some ideas for modifying the proposal were posted: - Ronald Guilmette suggested to address the verification of contact details entered in the RIPE Database with a separate proposal that he would support, provided that the implementation challenges, costs, and consequences for non-compliance would be clarified. This would split the existing proposal in two: VERIFICATION and REDACTION. - Sylvain Baya, contributed to the discussion and also postedlinks to RIPE Labs articles published in the past about the proposal?s topics. He supported Ronald?s suggestion of allowing the RIPE NCC to accept the requests of exemption from publication of the Personally Identifiable Information (PII) made by natural persons who need Internet resources and can legally demonstrate their privacy requirement. Sylvain also suggested splitting the subject into a set of proposals: one about the general principles for processing data within the RIPE Database, one about *insertion* of PII within the RIPE Database, one about the *query* of the RIPE Database and one for handling the current PII present into the RIPE Database. - Leo Vegoda suggested clearly separating the sections defining a principle from those defining its implementation. - Cynthia Revstr?m supported the proposal and suggested rewording the proposal clarifying that entering the full home address is never justified and that the default should be no address at all for individuals. The assumption should be that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not. Please let me know if you have any questions. Kind regards, William db-wg Co-Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at gmail.com Mon Aug 8 15:11:20 2022 From: ripedenis at gmail.com (denis walker) Date: Mon, 8 Aug 2022 15:11:20 +0200 Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: Hi Carlos On Thu, 4 Aug 2022 at 19:24, Carlos Fria?as wrote: > > > > Hi, > > A small comment inline: > > > On Thu, 4 Aug 2022, denis walker via db-wg wrote: > > (...) > > So in what ways is "geofeed:" going to make it easy for network > > operators to coordinate some activity? One of the ways network > > operators have talked about how they want/need to use "geofeed:" data > > is to provide content based on location of an IP address. > > Yes. Although *some* geolocation providers INSIST that their location > assessment is better than the owner's network. They do this by ignoring > messages or form data sent by owners. > > Keeping the attribute in the RIPE database may show ANYONE what is the > location the owner says it is the correct location. And hopefully that > should be the mandatory source for this information. I have heard this said before. But this is where the wording of the database purposes and use cases for "geofeed:" are critical. If this was the main reason for "geofeed:" it would not be covered by the current purposes. This is a single operator using the RIPE Database to make an announcement or a statement about some aspect of their resources to anyone. It is not 'coordination between network operators', even though the announced information could be used by other operators as well as anyone else. If you look back at the early docs on the registry, geolocation data is not part of the registration data. So none of the current purposes would cover this aspect. It does seem to be a perfectly reasonable use of the RIPE Database for resource holders to provide information about the resources to a wide variety of people, not only other operators. This is why, as I keep saying, we need to have a wider discussion about how people use the database today and review the old defined purposes. I know the purposes of the RIPE Database are the 'elephant in the room'. No one wants to talk about them, review them, touch them, consider them in any way. But they are critical in so many ways. To review and re-write them is not an easy task. That is why the Database Task Force should have started with such a review, but unfortunately they didn't. I know a lot of people wish I would just shut up about the purposes...but we must have this discussion. The historical purposes written in the 1990s (and partially reviewed in 2010) are perhaps not fit for purpose in the 2020s. Maybe the RIPE Database purposes need to be defined by a RIPE policy. I am considering making a policy proposal on this, which will force the discussion... cheers denis co-chair DB-WG > > > > If a content providing network operator wishes to offer this content > > to anyone in a specific location, that can be seen as a coordination > > activity. The content provider can coordinate with other network > > operators to establish that their customers are within this location > > so they can access this content. If this interpretation is accepted by > > the community then the context has changed. The legal team can now > > reassess their advice in the context that the use of the "geofeed:" > > data is now covered by the existing database purposes. > > Yes, please :-) > > Cheers, > Carlos > > From angel.gonzalez at incibe.es Mon Aug 8 16:01:28 2022 From: angel.gonzalez at incibe.es (=?utf-8?B?w4FuZ2VsIEdvbnrDoWxleiBCZXJkYXNjbw==?=) Date: Mon, 8 Aug 2022 14:01:28 +0000 Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: <23ccac5fa54bb2a929addd5d996107b979800123.camel@incibe.es> denis walker wrote: > If this was the main reason for "geofeed:" it would not be covered by > the current purposes. This is a single operator using the RIPE > Database to make an announcement or a statement about some aspect of > their resources to anyone. It is not 'coordination between network > operators', even though the announced information could be used by > other operators as well as anyone else. If you look back at the early > docs on the registry, geolocation data is not part of the > registration data. So none of the current purposes would cover this > aspect. It does seem to be a perfectly reasonable use of the RIPE > Database for resource holders to provide information about the > resources to a wide variety of people, not only other operators. This > is why, as I keep saying, we need to have a wider discussion about > how people use the database today and review the old defined > purposes. > I know the purposes of the RIPE Database are the 'elephant in the > room'... FWIW adding a purpose for the RIPE DB of "allowing the resource holders a place to make available to the public information related to those resources" seems perfectly reasonable to me. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de R?gimen Jur?dico del Sector P?blico", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de informaci?n" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd at incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de Espa?a, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ==================================================================== From peering-ops at telekom.de Mon Aug 22 08:00:31 2022 From: peering-ops at telekom.de (peering-ops at telekom.de) Date: Mon, 22 Aug 2022 06:00:31 +0000 Subject: [db-wg] NWI-13 Geofeed Legal Analysis In-Reply-To: <17A0C650-5E31-4AF7-95EB-333B6AC4193D@ripe.net> References: <34371.1659058170@segfault.tristatelogic.com> <07B5945F-F4DB-4042-A2F8-1532FFF29FDF@ripe.net> <4EBD397B-F14D-481D-B44E-8BAD60DA7E1C@ripe.net> <17A0C650-5E31-4AF7-95EB-333B6AC4193D@ripe.net> Message-ID: Can someone at RIPE please stop this. This OOO message is spamming everything. ------ Best regards, Daniel Stra?ner Deutsche Telekom Technik GmbH Core Networks & First-Line Maintenance (T-CNF) IP Core (IPC) Daniel Stra?ner Squad Changemanagement Carrier und GK-Connectivity (CMC) Squad Lifecycle Produktionsmodelle Public & Wholesale (PWS) Olgastr. 67, 89073 Ulm +49 731 1003-4775 (Tel.) +49 731 1003-4770 (Hotline) E-Mail: d.strassner at telekom.de www.telekom.de Life IS FOR SHARING. You can find the obligatory information on www.telekom.de/compulsory-statement-dttechnik BIG CHANGES START SMALL - SAVE RESOURCES BY NOT PRINTING EVERY E-MAIL. Von: db-wg Im Auftrag von Alun Davies via db-wg Gesendet: Montag, 22. August 2022 07:55 An: Alun Davies via db-wg Betreff: Re: [db-wg] NWI-13 Geofeed Legal Analysis Hi, I?m out of office till 22 August. Any RIPE Labs related queries can be sent to labs at ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:52, Alun Davies via db-wg wrote: Hi, I?m out of office till 22 August. Any RIPE Labs related queries can be sent to labs at ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:51, Alun Davies via db-wg wrote: Hi, I?m out of office till 22 August. Any RIPE Labs related queries can be sent to labs at ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:42, Alun Davies via db-wg wrote: Hi, I?m out of office till 22 August. Any RIPE Labs related queries can be sent to labs at ripe.net and one of my colleagues will get back to you. Cheers, Alun On 29 Jul 2022, at 14:24, Warren Kumari via db-wg wrote: On Thu, Jul 28, 2022 at 9:50 PM, Cynthia Revstr?m wrote: I am not sure how you came to that conclusion, the way I read Maria's email didn't make me come to a conclusion anything like that. Maria said: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. The RIPE DB T&C and the DBTF report are not the same and the RIPE DB T&C could be amended. Maria also says: If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. I feel like this directly goes against what you are saying, it seems very clear to me that it is possible to change the purposes. I'll also note that Maria's initial email said: "personal data that is not required or necessary for the currently defined purposes of the RIPE Database" with "currently defined" written in big, bold, flashy letters. It then continues with the paragraph you have quoted above: "If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes?" I happen to think that Geofeed could easily fall into: "Publishing routing policies by network operators (IRR)" ? part of my "routing policy" is that 192.0.2.0/24 is in Cologne, and that seems useful for you to know to build your policy as well and / or "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" ? you are seeing long latency to 192.0.2.0/24? Geofeeds tells you that that is in Warsaw, so when you contact me you can say something like "200ms seems like a long time to get from Berlin to Warsaw? perhaps we can not route this through Singapore??"" and / or "Scientific research into network operations and topology" ? you are doing Internet measurements on latency. Why does traceroute to 192.0.2.0/24 take 3ms and 203.0.113.0/24 take 89ms? Well, Geofeeds tells you that one is in Akureyri and the other is in Lisbon. Seems like worth knowing? But, the bolding of "currently defined" and the "If the community's interests have changed since then?" seems to imply that it is at least worth discussing if we can add Denis suggestion of ""The RIPE Database may contain data that an agreed set of external services may use, require or rely on." and if it does actually need "a resolution by the GM to change the T&C", etc. Even if we successfully argue that Geofeeds fits into one of the above examples, it does seem like having the T&C reflect what people want to be able to use the DB for? W -Cynthia On Fri, Jul 29, 2022 at 3:29 AM Ronald F. Guilmette via db-wg wrote: In message =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= wrote: The purposes could change... No, they couldn't. It appears that the RIPE Database Requirements Task Force issued its "final report" sometime late last year, and now the wheels have ground on further to bring us to the point where RIPE legal has issued an official proclamation to the effect that everything that does not comport with the Task Force's final list of defined purposes _must_ be jetisoned and thrown overboard. That would appear to be the short version of where things stand now. Based upon the principal of stare decisis, it would seem to be a bit late in the game to try to roll back any of what has already been adjudicated. Regards, rfg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -------------- next part -------------- An HTML attachment was scrubbed... URL: From horvath.agoston at gmail.com Mon Aug 22 10:12:39 2022 From: horvath.agoston at gmail.com (=?UTF-8?B?SG9ydsOhdGggw4Fnb3N0b24gSsOhbm9z?=) Date: Mon, 22 Aug 2022 10:12:39 +0200 Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: I, for one, with my regular internet user hat on, am strongly against any form of geolocation and consider it an invasion of my privacy. I don't want any random guy on the internet to simply pinpoint the town I'm living in. Is there an opt-out from this? Users will demand that there is for sure. Just my $0.02 Agoston On Thu, Aug 4, 2022 at 7:24 PM Carlos Fria?as via db-wg wrote: > > > Hi, > > A small comment inline: > > > On Thu, 4 Aug 2022, denis walker via db-wg wrote: > > (...) > > So in what ways is "geofeed:" going to make it easy for network > > operators to coordinate some activity? One of the ways network > > operators have talked about how they want/need to use "geofeed:" data > > is to provide content based on location of an IP address. > > Yes. Although *some* geolocation providers INSIST that their location > assessment is better than the owner's network. They do this by ignoring > messages or form data sent by owners. > > Keeping the attribute in the RIPE database may show ANYONE what is the > location the owner says it is the correct location. And hopefully that > should be the mandatory source for this information. > > > > If a content providing network operator wishes to offer this content > > to anyone in a specific location, that can be seen as a coordination > > activity. The content provider can coordinate with other network > > operators to establish that their customers are within this location > > so they can access this content. If this interpretation is accepted by > > the community then the context has changed. The legal team can now > > reassess their advice in the context that the use of the "geofeed:" > > data is now covered by the existing database purposes. > > Yes, please :-) > > Cheers, > Carlos > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at cynthia.re Mon Aug 22 11:30:02 2022 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 22 Aug 2022 11:30:02 +0200 Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: It is an optional attribute and as far as I know it is going to stay that way. -Cynthia On Mon, 22 Aug 2022, 10:13 Horv?th ?goston J?nos via db-wg, wrote: > I, for one, with my regular internet user hat on, am strongly against any > form of geolocation and consider it an invasion of my privacy. > I don't want any random guy on the internet to simply pinpoint the town > I'm living in. > > Is there an opt-out from this? Users will demand that there is for sure. > > Just my $0.02 > > Agoston > > On Thu, Aug 4, 2022 at 7:24 PM Carlos Fria?as via db-wg > wrote: > >> >> >> Hi, >> >> A small comment inline: >> >> >> On Thu, 4 Aug 2022, denis walker via db-wg wrote: >> >> (...) >> > So in what ways is "geofeed:" going to make it easy for network >> > operators to coordinate some activity? One of the ways network >> > operators have talked about how they want/need to use "geofeed:" data >> > is to provide content based on location of an IP address. >> >> Yes. Although *some* geolocation providers INSIST that their location >> assessment is better than the owner's network. They do this by ignoring >> messages or form data sent by owners. >> >> Keeping the attribute in the RIPE database may show ANYONE what is the >> location the owner says it is the correct location. And hopefully that >> should be the mandatory source for this information. >> >> >> > If a content providing network operator wishes to offer this content >> > to anyone in a specific location, that can be seen as a coordination >> > activity. The content provider can coordinate with other network >> > operators to establish that their customers are within this location >> > so they can access this content. If this interpretation is accepted by >> > the community then the context has changed. The legal team can now >> > reassess their advice in the context that the use of the "geofeed:" >> > data is now covered by the existing database purposes. >> >> Yes, please :-) >> >> Cheers, >> Carlos >> >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/db-wg >> > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adavies at ripe.net Mon Aug 22 15:52:12 2022 From: adavies at ripe.net (Alun Davies) Date: Mon, 22 Aug 2022 15:52:12 +0200 Subject: [db-wg] Apologies for spam Message-ID: Hello all, My apologies to everyone who received my out of office response this morning. Just wanted to note that the relevant messages have now been removed from the archives. Again, sorry for the spam! Best regards, Alun Davies RIPE NCC From ripedenis at gmail.com Mon Aug 22 15:52:21 2022 From: ripedenis at gmail.com (denis walker) Date: Mon, 22 Aug 2022 15:52:21 +0200 Subject: [db-wg] geolocation and current purposes In-Reply-To: References: Message-ID: Hi It is optional for the resource holder, not for the end user or customer. For them it is a question of whether or not the contracts they signed permit the publication of this (personal) data. cheers denis co-chair DB-WG On Mon, 22 Aug 2022 at 11:30, Cynthia Revstr?m via db-wg wrote: > > It is an optional attribute and as far as I know it is going to stay that way. > > -Cynthia > > On Mon, 22 Aug 2022, 10:13 Horv?th ?goston J?nos via db-wg, wrote: >> >> I, for one, with my regular internet user hat on, am strongly against any form of geolocation and consider it an invasion of my privacy. >> I don't want any random guy on the internet to simply pinpoint the town I'm living in. >> >> Is there an opt-out from this? Users will demand that there is for sure. >> >> Just my $0.02 >> >> Agoston >> >> On Thu, Aug 4, 2022 at 7:24 PM Carlos Fria?as via db-wg wrote: >>> >>> >>> >>> Hi, >>> >>> A small comment inline: >>> >>> >>> On Thu, 4 Aug 2022, denis walker via db-wg wrote: >>> >>> (...) >>> > So in what ways is "geofeed:" going to make it easy for network >>> > operators to coordinate some activity? One of the ways network >>> > operators have talked about how they want/need to use "geofeed:" data >>> > is to provide content based on location of an IP address. >>> >>> Yes. Although *some* geolocation providers INSIST that their location >>> assessment is better than the owner's network. They do this by ignoring >>> messages or form data sent by owners. >>> >>> Keeping the attribute in the RIPE database may show ANYONE what is the >>> location the owner says it is the correct location. And hopefully that >>> should be the mandatory source for this information. >>> >>> >>> > If a content providing network operator wishes to offer this content >>> > to anyone in a specific location, that can be seen as a coordination >>> > activity. The content provider can coordinate with other network >>> > operators to establish that their customers are within this location >>> > so they can access this content. If this interpretation is accepted by >>> > the community then the context has changed. The legal team can now >>> > reassess their advice in the context that the use of the "geofeed:" >>> > data is now covered by the existing database purposes. >>> >>> Yes, please :-) >>> >>> Cheers, >>> Carlos >>> >>> >>> >>> -- >>> >>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg