From erik at bais.name Tue Jan 2 15:49:16 2024 From: erik at bais.name (Erik Bais) Date: Tue, 2 Jan 2024 14:49:16 +0000 Subject: [address-policy-wg] Minutes of the RIPE87 Rome meeting Message-ID: <0C8B1480-9FBC-4D35-8B13-4B32D7CF30BE@bais.name> Dear WG, I like to wish you all a very healthy and successful 2024, on behalf of myself and the other AP-WG chairs. We?ve received the minutes of the RIPE87 meeting and the RIPE NCC was so kind to publish them already for your review online. And I like to thank the RIPE NCC in creating the minutes for us. Please review the minutes and provide feedback if you think there is something missing or incorrect. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-87-address-policy-working-group-minutes Regards, Erik Bais On behalf of the AP-WG Chairs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Jan 9 10:51:13 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 9 Jan 2024 10:51:13 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> Message-ID: On Sat, Dec 16, 2023 at 7:55?PM Tore Anderson wrote: > Hi Jan, > Hi Tore, thanks for responding, and sorry for the extreme response lag on my part. The second ? alleged ? change is the one that has been discussed the > most on the mailing list. The argument here is that your two ASSIGNED > PA objects above are actually in violation of *current* policy, because > they delegate all the contact information to you (the ISP/LIR). The > claim is that current policy requires non-delegated contact information > for the End User to be published in the object (not necessarily in > admin-c/tech-c, but ?somewhere?). > > If 2023-04 passes, your two ASSIGNED PA assignments above will > definitely be policy compliant (even before they are possibly replaced > with an AGGREGATED-BY-LIR object). There is no disagreement about this, > as far as we know. > > So the question is whether or not your two ASSIGNED PA objects are > permitted under *current* policy. If they are, then 2023-04 does not > change anything in this regard; the ?legal status? of your objects will > remain the same ? i.e., they are not violating policy ? after 2023-04 > passes (or fails) as it is under current policy. > > We believe your two objects are not in violation of today?s policy, > which means 2023-04 will exact no change to their ?legal status?. We > have elaborated on why in this message, under the heading ?Does 2023-04 > change the contact registration requirements for assignments??: > > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > > We hope this provides the clarification you requested. > Regrettably it does not, and it also raises the question of whether you have forgotten the definition of "end user" and confused it with "private person". 4. > An obligation to publish the End User?s contact information in the RIPE > database will constitute a violation of Article 6(3) of the RIPE Database > Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End > User?s contact person has not given explicit consent to such publication. > We believe that the RIPE policy cannot reasonably be interpreted to require > LIRs to break EU law (and even if it explicitly did require that, EU law > would still take precedence). This is misleading, as posting the contact details of an end user **does not necessarily require that you post PII** (person identifying information). You can use a company role and a company role's email address. This is also quite common in the RIPE database today, as far as I can tell. Additionally, this is what we in the registrar business consider a solved problem. In the event that the end user is a private person, you instead by default post anonymized information and e-mail addresses. In the case of e-mail addresses, the typical solution is to post a randomized e-mail address that acts as a forwarding address, and that this address is rotated according to the registrar's internal criteria. In the case of RIPE, it would be the LIR's responsibility, I guess. So this argument regarding publication of PII is void. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Jan 9 13:23:48 2024 From: tore at fud.no (Tore Anderson) Date: Tue, 9 Jan 2024 13:23:48 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> Message-ID: <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> Hi Jan, On 09/01/24 10:51, Jan Ingvoldstad wrote: > On Sat, Dec 16, 2023 at 7:55?PM Tore Anderson wrote: > > The second ? alleged ? change is the one that has been discussed the > most on the mailing list. The argument here is that your two ASSIGNED > PA objects above are actually in violation of *current* policy, > because > they delegate all the contact information to you (the ISP/LIR). The > claim is that current policy requires non-delegated contact > information > for the End User to be published in the object (not necessarily in > admin-c/tech-c, but ?somewhere?). > > If 2023-04 passes, your two ASSIGNED PA assignments above will > definitely be policy compliant (even before they are possibly replaced > with an AGGREGATED-BY-LIR object). There is no disagreement about > this, > as far as we know. > > So the question is whether or not your two ASSIGNED PA objects are > permitted under *current* policy. If they are, then 2023-04 does not > change anything in this regard; the ?legal status? of your objects > will > remain the same ? i.e., they are not violating policy ? after 2023-04 > passes (or fails) as it is under current policy. > > We believe your two objects are not in violation of today?s policy, > which means 2023-04 will exact no change to their ?legal status?. We > have elaborated on why in this message, under the heading ?Does > 2023-04 > change the contact registration requirements for assignments??: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > > We hope this provides the clarification you requested. > > > Regrettably it does not, and it also raises the question of whether > you have forgotten the definition of "end user" and confused it with > "private person". > > 4. > An obligation to publish the End User?s contact information in the > RIPE database will constitute a violation of Article 6(3) of the > RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the > GDPR[6], if the End User?s contact person has not given explicit > consent to such publication. We believe that the RIPE policy > cannot reasonably be interpreted to require LIRs to break EU law > (and even if it explicitly did require that, EU law would still > take precedence). > > > This is misleading, as posting the contact details of an end user > **does not necessarily require that you post PII** (person identifying > information). You can use a company role and a company role's email > address. This is also quite common in the RIPE database today, as far > as I can tell. It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses. Consider for example a small one-person business, let's say a farm owned by ?Farmer Fred?. This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway). The e-mail address might well be farmer.fred at gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR. Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer). > Additionally, this is what we in the registrar business consider a > solved problem. In the event that the end user is a private person, > you instead by default post anonymized information and e-mail > addresses. In the case of e-mail addresses, the typical solution is to > post a randomized e-mail address that acts as a forwarding address, > and that this address is rotated according to the registrar's internal > criteria. In the case of RIPE, it would be the LIR's responsibility, I > guess. Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users. This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change ? it ain't broken, and we're not fixing it. The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change. We hope this clarifies the clarification. :-) Tore & Jeroen From frettled at gmail.com Tue Jan 9 13:38:06 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 9 Jan 2024 13:38:06 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> Message-ID: On Tue, Jan 9, 2024 at 1:23?PM Tore Anderson wrote: > Hi Jan, > Hi Tore and thanks for coming back so quickly. > > On 09/01/24 10:51, Jan Ingvoldstad wrote: > > On Sat, Dec 16, 2023 at 7:55?PM Tore Anderson wrote: > > > > The second ? alleged ? change is the one that has been discussed the > > most on the mailing list. The argument here is that your two ASSIGNED > > PA objects above are actually in violation of *current* policy, > > because > > they delegate all the contact information to you (the ISP/LIR). The > > claim is that current policy requires non-delegated contact > > information > > for the End User to be published in the object (not necessarily in > > admin-c/tech-c, but ?somewhere?). > > > > If 2023-04 passes, your two ASSIGNED PA assignments above will > > definitely be policy compliant (even before they are possibly > replaced > > with an AGGREGATED-BY-LIR object). There is no disagreement about > > this, > > as far as we know. > > > > So the question is whether or not your two ASSIGNED PA objects are > > permitted under *current* policy. If they are, then 2023-04 does not > > change anything in this regard; the ?legal status? of your objects > > will > > remain the same ? i.e., they are not violating policy ? after 2023-04 > > passes (or fails) as it is under current policy. > > > > We believe your two objects are not in violation of today?s policy, > > which means 2023-04 will exact no change to their ?legal status?. We > > have elaborated on why in this message, under the heading ?Does > > 2023-04 > > change the contact registration requirements for assignments??: > > > > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > > > > We hope this provides the clarification you requested. > > > > > > Regrettably it does not, and it also raises the question of whether > > you have forgotten the definition of "end user" and confused it with > > "private person". > > > > 4. > > An obligation to publish the End User?s contact information in the > > RIPE database will constitute a violation of Article 6(3) of the > > RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the > > GDPR[6], if the End User?s contact person has not given explicit > > consent to such publication. We believe that the RIPE policy > > cannot reasonably be interpreted to require LIRs to break EU law > > (and even if it explicitly did require that, EU law would still > > take precedence). > > > > > > This is misleading, as posting the contact details of an end user > > **does not necessarily require that you post PII** (person identifying > > information). You can use a company role and a company role's email > > address. This is also quite common in the RIPE database today, as far > > as I can tell. > > It is important to also consider the cases where the End Users are > organisations that do not have non-PII role addresses. > > Consider for example a small one-person business, let's say a farm owned > by ?Farmer Fred?. This End User would be a company, not an individual, > yet the company is often given the same name as the person owning it (at > least here in Norway). > > The e-mail address might well be farmer.fred at gmail and the phone number > might be the Farmer Fred's personal mobile. This would mean that both > the name and the contact information for this End User *is* PII and is > in scope of the GDPR. > The current interpretation of this part of the GDPR is that "Farmer Fred" is permissible to publish. > > Therefore, if Farmer Fred exercises his rights under the GDPR to object > against / not give consent to the publishing of his PII in the RIPE DB, > you (the LIR) have a problem. Proceeding to publish this contact > information over Farmer Fred's objections opens you up to legal risk > (not to mention souring the relationship with your customer). > The solution here would be to not publish (and not require the publication of) personal phone numbers (or personal addresses), and to clearly make this a requirement in the policy regarding what End User information is published. Similarly, that requirement must be there for *any* contact object, not just End Users. You cannot know if the LIR's phone numbers are personal or not, or can you? > > > > Additionally, this is what we in the registrar business consider a > > solved problem. In the event that the end user is a private person, > > you instead by default post anonymized information and e-mail > > addresses. In the case of e-mail addresses, the typical solution is to > > post a randomized e-mail address that acts as a forwarding address, > > and that this address is rotated according to the registrar's internal > > criteria. In the case of RIPE, it would be the LIR's responsibility, I > > guess. > > Precisely. The LIR, like a domain name registrar, can simply serve as a > proxy between the wider Internet community and its End Users. No, that is not what I wrote. This is about an automatic email forwarding scheme, not about a registration by proxy scheme. E.g. you register the domainname ripe-example.shop with a registrar within the EEA, your email address is published (for EEA-based domainnames, anyway) as e.g. qaobuaidbvsas at privacy.example, which is a valid email address that is automatically forwarded to e.g. tore+ripe-example at fud.no. > This voids > any policy requirement to (possibly illegally) publish Farmer Fred's PII > in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the > opinion that this (already widespread) practice is permitted by current > policy, and will continue to be permitted after 2023-04 is implemented. > In other words, just like in the registrar business, this is an already > solved problem, which will continue to be solved after 2023-04 is > implemented. It is in this respect that we say that 2023-04 will not > bring about any change ? it ain't broken, and we're not fixing it. > > The claim that has been made is that *current* policy does not allow > LIRs to serve as proxies in this manner, and that the RIPE NCC has not > been implementing current policy correctly by allowing it. It is further > claimed that 2023-04 will bring about an (undesired) change in that it > will allow LIRs to serve as proxies. However, for the reasons already > discussed we are of the opinion the premise this argument rests on is > incorrect, hence we do not believe 2023-04 will effect any change. > > We hope this clarifies the clarification. :-) > I was kindof trying to avoid that argument again. But sure, as you bring it up again. This opinion is obviously a logical impossibility. There is no way that you can change something and at the same way legitimately claim that the change is not a change. If it is true that the current practice is both widespread and accepted, then *no change is necessary*. If a change is necessary, it is logically because there is a widespread and accepted practice of publishing End Users' contact information. The argument is therefore nonsensical, sorry. You have not actually addressed this concern and objection, you have merely restated claims and opinions that do not actually do so. I therefore again urge you to resubmit the proposal *without* this removal. Then, if this part of the policy change is of importance, resubmit it as a separate proposal, and preferably clearing up the PII mess a bit more. I have no beef with clearing that up. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Jan 9 15:12:56 2024 From: tore at fud.no (Tore Anderson) Date: Tue, 9 Jan 2024 15:12:56 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> Message-ID: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> Hi again Jan, On 09/01/24 13:38, Jan Ingvoldstad wrote: > > It is important to also consider the cases where the End Users are > organisations that do not have non-PII role addresses. > > Consider for example a small one-person business, let's say a farm > owned > by ?Farmer Fred?. This End User would be a company, not an > individual, > yet the company is often given the same name as the person owning > it (at > least here in Norway). > > The e-mail address might well be farmer.fred at gmail and the phone > number > might be the Farmer Fred's personal mobile. This would mean that both > the name and the contact information for this End User *is* PII > and is > in scope of the GDPR. > > > The current interpretation of this part of the GDPR is that "Farmer > Fred" is permissible to publish. Whose interpretation? According to the EU Commission: ?Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.? https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en ?Farmer Fred? ? the name of an individual ? clearly falls within this definition. So does his e-mail address and telephone number. Publishing this information requires a lawful basis, e.g., consent. If consent was refused, it is not permissible to publish. This is presumably the reason why the RIPE NCC states the following in the 2023-04 Impact Analysis: ?Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member?s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person?s informed and expressed consent and ensure this data is kept accurate and up-to-date.? https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > Therefore, if Farmer Fred exercises his rights under the GDPR to > object > against / not give consent to the publishing of his PII in the > RIPE DB, > you (the LIR) have a problem. Proceeding to publish this contact > information over Farmer Fred's objections opens you up to legal risk > (not to mention souring the relationship with your customer). > > > The solution here would be to not publish (and not require the > publication of) personal phone numbers (or personal addresses), and to > clearly make this a requirement in the policy regarding what End User > information is published. Indeed, and it is our opinion that this solution is already available today, as the RIPE NCC has confirmed that according to their current policy interpretation and procedures, not publishing Farmer Fred's PII in the RIPE DB is compliant with today's policy. This will continue to be the case after 2023-04 is implemented, so no change there. > Similarly, that requirement must be there for *any* contact object, > not just End Users. > > You cannot know if the LIR's phone numbers are personal or not, or can > you? LIRs' contact information is definitively out of scope of 2023-04. 2023-04 only concerns itself with *assignments* (made by LIRs to End Users), not *allocations* (made by the RIPE NCC to LIRs). (That said, LIRs' contact information is also subject to the RIPE Database Terms and Conditions.) > Precisely. The LIR, like a domain name registrar, can simply serve > as a > proxy between the wider Internet community and its End Users. > > > No, that is not what I wrote. > > This is about an automatic email forwarding scheme, not about a > registration by proxy scheme. > > E.g. you register the domainname ripe-example.shop with a registrar > within the EEA, your email address is published (for EEA-based > domainnames, anyway) as e.g. qaobuaidbvsas at privacy.example, which is a > valid email address that is automatically forwarded to e.g. > tore+ripe-example at fud.no . The policy is technology agnostic in this respect. An automatic e-mail forwarding scheme such as the one you describe is one example of a policy- (and presumably GDPR-) compliant way to do it, but that's not the only possible option. The LIR could instead opt for operating a human-staffed help desk that receives and forwards messages to End Users as appropriate. > This voids > any policy requirement to (possibly illegally) publish Farmer > Fred's PII > in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is > of the > opinion that this (already widespread) practice is permitted by > current > policy, and will continue to be permitted after 2023-04 is > implemented. > In other words, just like in the registrar business, this is an > already > solved problem, which will continue to be solved after 2023-04 is > implemented. It is in this respect that we say that 2023-04 will not > bring about any change ? it ain't broken, and we're not fixing it. > > The claim that has been made is that *current* policy does not allow > LIRs to serve as proxies in this manner, and that the RIPE NCC has > not > been implementing current policy correctly by allowing it. It is > further > claimed that 2023-04 will bring about an (undesired) change in > that it > will allow LIRs to serve as proxies. However, for the reasons already > discussed we are of the opinion the premise this argument rests on is > incorrect, hence we do not believe 2023-04 will effect any change. > > We hope this clarifies the clarification. :-) > > > I was kindof trying to avoid that argument again. > > But sure, as you bring it up again. > > This opinion is obviously a logical impossibility. > > There is no way that you can change something and at the same way > legitimately claim that the change is not a change. > > If it is true that the current practice is both widespread and > accepted, then *no change is necessary*. > > If a change is necessary, it is logically because there is a > widespread and accepted practice of publishing End Users' contact > information. > > The argument is therefore nonsensical, sorry. I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things: 1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6. 2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either. In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today ? intentionally so. So maybe we could discuss 1) instead of 2) going forward? :-) > You have not actually addressed this concern and objection, you have > merely restated claims and opinions that do not actually do so. > > I therefore again urge you to resubmit the proposal *without* this > removal. As noted in 2) above, the proposal in its current form does not cause any ?removal? of any End User contact information publishing requirement compared to current policy. It merely upholds the status quo, which has been confirmed by the RIPE NCC on multiple occasions. However, if you are dismissing the RIPE NCC's clarifications on this subject in the Impact Analysis and elsewhere as not factual, then there is not much more to discuss and we would simply have to agree to disagree. > Then, if this part of the policy change is of importance, resubmit it > as a separate proposal, and preferably clearing up the PII mess a bit > more. I have no beef with clearing that up. Any effort to ?clearing up the PII mess? has always been outside the scope of this proposal. This proposal is simply not about PII or contact information. That could be a subject for another policy proposal, of course, but one thing at a time. Tore & Jeroen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogus@does.not.exist.com Tue Jan 9 17:53:17 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:53:17 +0000 Subject: [address-policy-wg] [Moderated] Message-ID: A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 2 bytes Desc: not available URL: From bogus@does.not.exist.com Tue Jan 9 17:54:02 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:54:02 +0000 Subject: [Moderated] Message-ID: From bogus@does.not.exist.com Tue Jan 9 17:54:47 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:54:47 +0000 Subject: [Moderated] Message-ID: From bogus@does.not.exist.com Tue Jan 9 17:55:17 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:55:17 +0000 Subject: [address-policy-wg] [Moderated] Message-ID: From bogus@does.not.exist.com Tue Jan 9 17:56:13 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:56:13 +0000 Subject: [address-policy-wg] [Moderated] Message-ID: From bogus@does.not.exist.com Tue Jan 9 17:57:27 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:57:27 +0000 Subject: [address-policy-wg] [Moderated] Message-ID: From bogus@does.not.exist.com Tue Jan 9 17:58:56 2024 From: bogus@does.not.exist.com () Date: Tue, 9 Jan 2024 16:58:56 +0000 Subject: [Moderated] Message-ID: A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 2292 bytes Desc: not available URL: From rgori at wirem.net Wed Jan 10 10:11:02 2024 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 10 Jan 2024 10:11:02 +0100 Subject: [address-policy-wg] Extend Review Phase for 2023-04 - "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" In-Reply-To: References: Message-ID: Good morning, +1 support. Regards, Riccardo Il 21/12/2023 19:36, Leo Vegoda ha scritto: > Dear colleagues, > > There's still an active discussion on 2023-04 - "Add AGGREGATED-BY-LIR > status for IPv4 PA assignments". We'll extend the Review Phase until > 18 January 2024. > > You can find the policy proposal, the draft RIPE document, and the > RIPE NCC's Impact Analysis here: > https://www.ripe.net/participate/policies/proposals/2023-04 > > The RIPE NCC will update the proposal web page with the new dates soon. > > Kind regards, > > Leo Vegoda, for the Address Policy WG co-chairs > -- Riccardo Gori e-mail:rgori at wirem.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Wed Jan 10 11:25:27 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 10 Jan 2024 11:25:27 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> Message-ID: On Tue, Jan 9, 2024 at 3:12?PM Tore Anderson wrote: > Hi again Jan, > > Hello again, Tore, and thanks yet again! > On 09/01/24 13:38, Jan Ingvoldstad wrote: > > It is important to also consider the cases where the End Users are >> organisations that do not have non-PII role addresses. >> >> Consider for example a small one-person business, let's say a farm owned >> by ?Farmer Fred?. This End User would be a company, not an individual, >> yet the company is often given the same name as the person owning it (at >> least here in Norway). >> >> The e-mail address might well be farmer.fred at gmail and the phone number >> might be the Farmer Fred's personal mobile. This would mean that both >> the name and the contact information for this End User *is* PII and is >> in scope of the GDPR. >> > > The current interpretation of this part of the GDPR is that "Farmer Fred" > is permissible to publish. > > Whose interpretation? According to the EU Commission: ?Personal data is > any information that relates to an identified or identifiable living > individual. Different pieces of information, which collected together can > lead to the identification of a particular person, also constitute personal > data.? > > > https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en > > ?Farmer Fred? ? the name of an individual ? clearly falls within this > definition. So does his e-mail address and telephone number. Publishing > this information requires a lawful basis, e.g., consent. If consent was > refused, it is not permissible to publish. This is presumably the reason > why the RIPE NCC states the following in the 2023-04 Impact Analysis: > > ?Inserting any personal data in the RIPE Database must be in compliance > with the RIPE Database Terms and Conditions, even when it relates to the > contact details of the member?s own contact person(s). In particular, > before anyone updates the RIPE Database with personal data, they must > obtain the contact person?s informed and expressed consent and ensure this > data is kept accurate and up-to-date.? > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > This is a fairly radical view of how GDPR regulates publishing of personal data, IMHO erring far to the side of misunderstood caution: https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/do-data-protection-rules-apply-data-about-company_en Does "Farmer Fred" alone "allow the identification of a natural person"? IMHO it does not, and this seems to be the accepted view in various publicly databases publishing data regarding companies containing parts of the name of natural persons. Basically, any public company register would be illegal according to the interpretation you lean on here. > Precisely. The LIR, like a domain name registrar, can simply serve as a >> proxy between the wider Internet community and its End Users. > > > No, that is not what I wrote. > > This is about an automatic email forwarding scheme, not about a > registration by proxy scheme. > > E.g. you register the domainname ripe-example.shop with a registrar within > the EEA, your email address is published (for EEA-based domainnames, > anyway) as e.g. qaobuaidbvsas at privacy.example, which is a valid email > address that is automatically forwarded to e.g. tore+ripe-example at fud.no. > > The policy is technology agnostic in this respect. An automatic e-mail > forwarding scheme such as the one you describe is one example of a policy- > (and presumably GDPR-) compliant way to do it, but that's not the only > possible option. The LIR could instead opt for operating a human-staffed > help desk that receives and forwards messages to End Users as appropriate. > The policy should be technology agnostic, and when requiring the publication of contact details for end users, require that such publication by a LIR conforms to regulations. Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not. The current stance is just not logical. > > I think that because the WG discussion has almost exclusively revolved > around this alleged changing of policy requirements to publish End User > contact information (which may or may not be PII), it is easy to lose track > of what this proposal is *actually* all about. We are talking about two > different things: > > 1) The actual intention behind the proposal: Making it possible to > aggregate multiple IPv4 End User assignments that have consistent contact > information and purpose into a single database object. This is not possible > today, and that is what we want to make that possible, in the same way it > is already possible in IPv6. > > 2) The *alleged* change to what kind of End User contact information is > required to be published in the RIPE database. We have never had any > intention of changing this in any way, and the Impact Analysis and other > statements from the RIPE NCC confirm that the proposal does not change it > either. > > In short: 1) is an intentional and desired change from today, while 2) is > *not* a change from today ? intentionally so. > This (regarding item 2) is simply not true. Any change in text *is a change*. > So maybe we could discuss 1) instead of 2) going forward? :-) > I have no problem with 1), as already stated. I do agree with you that this is distracting from the proper meat of your proposal. Which is why I suggest that you drop this part of it. > > You have not actually addressed this concern and objection, you have > merely restated claims and opinions that do not actually do so. > > I therefore again urge you to resubmit the proposal *without* this removal. > > As noted in 2) above, the proposal in its current form does not cause any > ?removal? of any End User contact information publishing requirement > compared to current policy. > It is a removal of the text in question. > It merely upholds the status quo, which has been confirmed by the RIPE NCC > on multiple occasions. However, if you are dismissing the RIPE NCC's > clarifications on this subject in the Impact Analysis and elsewhere as not > factual, then there is not much more to discuss and we would simply have to > agree to disagree. > I disagree that removing a piece of text is not removing a piece of text. You can "agree to disagree" all you want, but this is starting to look dishonest. > > Then, if this part of the policy change is of importance, resubmit it as a > separate proposal, and preferably clearing up the PII mess a bit more. I > have no beef with clearing that up. > > Any effort to ?clearing up the PII mess? has always been outside the scope > of this proposal. This proposal is simply not about PII or contact > information. That could be a subject for another policy proposal, of > course, but one thing at a time. > Again, drop the part of the proposal that people have a beef with. Don't make the change that you claim is not a change. That is all, and I believe you will not only have rough consensus, but near 100% consensus. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Jan 10 13:02:02 2024 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Jan 2024 13:02:02 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> Message-ID: <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> Hello again Jan, On 10/01/24 11:25, Jan Ingvoldstad wrote: > Basically, any public company register would be illegal according to > the interpretation you lean on here. Public company registries also need a lawful basis for processing. The Norwegian public company registry, for example, uses the lawful basis ?exercise of official authority? ? Article 6(1)(e) GDPR ? as its lawful basis, see https://www.brreg.no/en/privacy-statement/. I would assume that to be the case in most other countries as well. (Most) LIRs are not official authorities, so unlike public company registries LIRs cannot use this lawful basis for publishing PII in the RIPE Database. In any case, all of this is rather off-topic. 2023-04 does not change the legal obligations on the LIRs relating to the publication of End User contact information, nor does it change the RIPE Database Terms and Conditions. If you want to publish PII in the RIPE Database, you need a lawful basis. That's true today, and that will continue to be true if 2023-04 passes. > Or you could take the other stance and stop publishing *any* contact > details regarding an object, because you cannot know whether the > information is personal data or not. Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy. It will continue to be compliant with the policy after 2023-04 passes, as well. Thus, 2023-04 effects no change on the LIRs' obligations in this regard. > I think that because the WG discussion has almost exclusively revolved > around this alleged changing of policy requirements to publish End > User contact information (which may or may not be PII), it is easy to > lose track of what this proposal is *actually* all about. We are > talking about two different things: > > 1) The actual intention behind the proposal: Making it possible to > aggregate multiple IPv4 End User assignments that have consistent > contact information and purpose into a single database object. > This is not possible today, and that is what we want to make that > possible, in the same way it is already possible in IPv6. > > 2) The *alleged* change to what kind of End User contact > information is required to be published in the RIPE database. We > have never had any intention of changing this in any way, and the > Impact Analysis and other statements from the RIPE NCC confirm > that the proposal does not change it either. > > In short: 1) is an intentional and desired change from today, > while 2) is *not* a change from today ? intentionally so. > > This (regarding item 2) is simply not true. Any change in text *is a > change*. We are not making the claim that the policy text does not change. That it clearly does ? in order to achieve the desired change described in item 1 above. We are however claiming that the *meanings* of the old and the new policy texts are exactly the same, with regards to how they translate into operational procedures and requirements for the publication of End User contact information (item 2). As the RIPE NCC writes in the Impact Analysis (emphasis added): ??? ?Acceptance of this proposal **will not change** the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this **will remain** their decision.? So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > So maybe we could discuss 1) instead of 2) going forward? :-) > > I have no problem with 1), as already stated. We're happy to hear that! > I do agree with you that this is distracting from the proper meat of > your proposal. Which is why I suggest that you drop this part of it. > Again, drop the part of the proposal that people have a beef with. > > Don't make the change that you claim is not a change. This ?beef? is based on reading current policy to mean that which End User contact details LIRs publish in the database (if any) is *not* the LIRs' decision today. But the RIPE NCC has repeatedly clarified that that is simply not the case: it *is* the LIRs' decision today, and it will continue to be LIRs' decision should 2023-04 pass. Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Tore & Jeroen From ripedenis at gmail.com Thu Jan 11 01:40:33 2024 From: ripedenis at gmail.com (denis walker) Date: Thu, 11 Jan 2024 01:40:33 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> Message-ID: Hi Tore and others New year, but same old story. So much miss information, endlessly repeated. Selective quotes from other documents to support your argument where a full quote might show a different picture. Carefully chosen examples to again support your argument, where other examples will negate it. But I won't give up. I put forward a proposal on privacy 1 1/2 years ago, 2022-01. In the end I withdrew it for two main reasons. It became apparent that my proposal would significantly change the basis under which personal data is entered into the RIPE Database. Secondly it was suggested that my proposal covered multiple areas that should have been proposed separately. Your proposal has the same two issues. Firstly it will also make changes to the way personal (contact) data is used in the database. Secondly it is claimed to be about aggregating End User assignments but as a side issue 'slips in' the biggest change to address policy in 20 years. In your own words you have repeatedly said this policy is all about aggregation. So keep it strictly about aggregating assignment objects that have the same contact details. Again, in your own words you have repeatedly said this will not make any practical change to the current practise of defining contact details. So take that out. That is where the contentious arguments exist. If you really believe what you are saying over and over again, that there will be no material change in this area, then drop it. Make this proposal about what the title suggests, aggregation. Drop every other change. It will probably then get support without objections. The other changes, that you repeatedly claim are not material changes, can be the subject of a separate proposal. I and some others in this community do not believe these other changes are incidental. In fact I believe that is the real goal of this proposal. I suspect it is the aggregation that is incidental. A means to achieve the goal of dropping the mandatory requirement to document assignments with End User contact details. That is without doubt the bigger change being pushed by this proposal. As it is, this proposal should not, and must not, be approved with such a big change slipped in and complete denial that it is even a change. Separate the two then we can have a full and open discussion on the other change, if you want to put that forward as a proposal. Working on the assumption that you have no intention of doing that, I will continue to argue against your mis-information below, again. You have referenced GDPR so many times in this discussion. Let's look at that in more detail. Article 6 Lawfulness of processing 1. Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Note in the opening sentence it says "at least one of the following applies". So personal data does not always need consent of the data subject. But you only ever refer to (a) consent. If you look back at the discussion on 2022-01 my privacy proposal you will see this was heavily discussed: https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html I also discussed it a lot privately with the RIPE NCC legal team. Frank Breedijk from divd.nl was very concerned about the loss of contact data as my proposal was suggesting we move to a full consent model. (I have CCed Frank as he may not be aware of this proposal that may lead to the removal of a lot of contact information from the database.) This was one of the final points that led me to drop my proposal. It was concluded that much of the personal data is entered into the RIPE Database on the basis of 6.1 (e) - public interest. Especially as so much of this data is used by LEAs and other investigators looking into cyber crime, security incidents and abuse. Then if we look at the legal impact analysis (IA) for 2022-01 https://www.ripe.net/participate/policies/proposals/2022-01?version=3#impact-analysis "Currently, the processing of personal data relating to resource holders is necessary for the performance of registry function. This function is carried out in the legitimate interest of the RIPE community and supports the smooth operation of the Internet globally (and is therefore in accordance with Article 6.1.f of the GDPR)." Then if we look at the legal impact analysis for 2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis "In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person?s informed and expressed consent and ensure this data is kept accurate and up-to-date." So the RIPE NCC legal team, at different times, has said that we process PII for resource holders on the basis of 6.1 (f), End Users on the basis of 6.1 (e), but now they say ALL PII is on the basis of 6.1 (a), ie consent. This is total confusion!!! The RIPE NCC legal team now needs to explain what the basis is for entering PII into the RIPE Database for at least the following situations: -Resource Holders -End Users -admin and tech contacts -abuse contacts If we take the latest revelation in the IA on 2023-04, ALL PII needs consent, this has HUGE implications for the RIPE NCC and RIPE policy generally. We MUST have a good understanding of the legal basis for entering PII into the RIPE Database. Consent cannot be conditional. So if a resource holder who is a natural person withdraws their consent to have their PII in the database, it MUST be removed. That may leave an allocation and organisation with no identity or contacts. That would be a policy violation. BUT the resource cannot be reclaimed as that would have made the consent conditional. Also we have an abuse policy that requires all resources to have an abuse contact. If that contact is a natural person and they withdraw their consent their details must be deleted. Again that creates a policy violation. But the resource cannot be reclaimed again as that would have made the contact details consent conditional. There is also the question of 2 million person objects in the database. It says in the IA for 2022-01 "Although the resource holders themselves are responsible for the registration details they add to the RIPE Database, the RIPE NCC is responsible for operating it. Under GDPR, that creates shared responsibilities on the RIPE NCC?s side with regards to the personal data added and processed in the RIPE Database." So the RIPE NCC is jointly responsible for the consent given (and maybe withdrawn) by these 2m people. This is a separate can of worms but related to this proposal 2023-04. The legal team has to sort this out. On Tue, 9 Jan 2024 at 15:12, Tore Anderson wrote: > > Hi again Jan, > > On 09/01/24 13:38, Jan Ingvoldstad wrote: >> >> It is important to also consider the cases where the End Users are >> organisations that do not have non-PII role addresses. >> >> Consider for example a small one-person business, let's say a farm owned >> by ?Farmer Fred?. This End User would be a company, not an individual, >> yet the company is often given the same name as the person owning it (at >> least here in Norway). >> >> The e-mail address might well be farmer.fred at gmail and the phone number >> might be the Farmer Fred's personal mobile. This would mean that both >> the name and the contact information for this End User *is* PII and is >> in scope of the GDPR. > > > The current interpretation of this part of the GDPR is that "Farmer Fred" is permissible to publish. > > Whose interpretation? According to the EU Commission: ?Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.? > > https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en > > ?Farmer Fred? ? the name of an individual ? clearly falls within this definition. So does his e-mail address and telephone number. Publishing this information requires a lawful basis, e.g., consent. If consent was refused, it is not permissible to publish. This is presumably the reason why the RIPE NCC states the following in the 2023-04 Impact Analysis: Again you have selected just one example that can support your argument, Farmer Fred. I could have used KPN or Apple Inc as an example which would negate your argument. We have no statistics on how many contacts in the database have corporate data or personal data and there is no way to determine this from the data. Even Farmer Fred may be a clever guy. He may have set up a separate business email and phone number for business purposes. You don't know that. Also as I said above, consent is not the only option for a lawful basis to enter personal data. > > ?Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member?s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person?s informed and expressed consent and ensure this data is kept accurate and up-to-date.? > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > > >> Therefore, if Farmer Fred exercises his rights under the GDPR to object >> against / not give consent to the publishing of his PII in the RIPE DB, >> you (the LIR) have a problem. Proceeding to publish this contact >> information over Farmer Fred's objections opens you up to legal risk >> (not to mention souring the relationship with your customer). This depends on the legal team's answer to what basis the PII is entered into the database. > > > The solution here would be to not publish (and not require the publication of) personal phone numbers (or personal addresses), and to clearly make this a requirement in the policy regarding what End User information is published. > > Indeed, and it is our opinion that this solution is already available today, as the RIPE NCC has confirmed that according to their current policy interpretation and procedures, not publishing Farmer Fred's PII in the RIPE DB is compliant with today's policy. This will continue to be the case after 2023-04 is implemented, so no change there. And I have provided a mountain of evidence that this interpretation by the RIPE NCC is so clearly wrong. So your proposal makes a significant change in this area, no matter how many times you claim it doesn't. > > > Similarly, that requirement must be there for *any* contact object, not just End Users. > > You cannot know if the LIR's phone numbers are personal or not, or can you? > > LIRs' contact information is definitively out of scope of 2023-04. 2023-04 only concerns itself with *assignments* (made by LIRs to End Users), not *allocations* (made by the RIPE NCC to LIRs). > > (That said, LIRs' contact information is also subject to the RIPE Database Terms and Conditions.) and subject to the legal team's answer to the basis on which it is entered into the database. > > >> Precisely. The LIR, like a domain name registrar, can simply serve as a >> proxy between the wider Internet community and its End Users. In other words hide the End User data so it doesn't comply with current policy and requires a court order to obtain by the wider internet community. > > > No, that is not what I wrote. > > This is about an automatic email forwarding scheme, not about a registration by proxy scheme. > > E.g. you register the domainname ripe-example.shop with a registrar within the EEA, your email address is published (for EEA-based domainnames, anyway) as e.g. qaobuaidbvsas at privacy.example, which is a valid email address that is automatically forwarded to e.g. tore+ripe-example at fud.no. > > The policy is technology agnostic in this respect. An automatic e-mail forwarding scheme such as the one you describe is one example of a policy- (and presumably GDPR-) compliant way to do it, but that's not the only possible option. The LIR could instead opt for operating a human-staffed help desk that receives and forwards messages to End Users as appropriate. > > >> This voids >> any policy requirement to (possibly illegally) publish Farmer Fred's PII >> in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the >> opinion that this (already widespread) practice is permitted by current >> policy, and will continue to be permitted after 2023-04 is implemented. >> In other words, just like in the registrar business, this is an already >> solved problem, which will continue to be solved after 2023-04 is >> implemented. It is in this respect that we say that 2023-04 will not >> bring about any change ? it ain't broken, and we're not fixing it. >> >> The claim that has been made is that *current* policy does not allow >> LIRs to serve as proxies in this manner, and that the RIPE NCC has not >> been implementing current policy correctly by allowing it. It is further >> claimed that 2023-04 will bring about an (undesired) change in that it >> will allow LIRs to serve as proxies. However, for the reasons already >> discussed we are of the opinion the premise this argument rests on is >> incorrect, hence we do not believe 2023-04 will effect any change. >> >> We hope this clarifies the clarification. :-) > > > I was kindof trying to avoid that argument again. > > But sure, as you bring it up again. > > This opinion is obviously a logical impossibility. > > There is no way that you can change something and at the same way legitimately claim that the change is not a change. > > If it is true that the current practice is both widespread and accepted, then *no change is necessary*. > > If a change is necessary, it is logically because there is a widespread and accepted practice of publishing End Users' contact information. > > The argument is therefore nonsensical, sorry. > > I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things: There is nothing alleged here. Jan is correct. You ARE removing that infamous statement "When an End User has a network using public address space this must be registered separately with the contact details of the End User." You cannot describe this as anything other than the fact that you ARE changing the policy requirements to publish End User contact information. > > 1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6. If this is the actual intention then keep the proposal to this. DO NOT make other changes to the policy on the side. > > 2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either. Then don't change it. SIMPLE!!! The IA does NOT say it doesn't change this. > > In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today ? intentionally so. > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > You have not actually addressed this concern and objection, you have merely restated claims and opinions that do not actually do so. > > I therefore again urge you to resubmit the proposal *without* this removal. > > As noted in 2) above, the proposal in its current form does not cause any ?removal? of any End User contact information publishing requirement compared to current policy. You are removing this line "When an End User has a network using public address space this must be registered separately with the contact details of the End User." This is a 'publishing requirement'. You ARE removing it. To keep saying you are NOT changing anything is not a joke anymore. >It merely upholds the status quo, which has been confirmed by the RIPE NCC on multiple occasions. However, if you are dismissing the RIPE NCC's clarifications on this subject in the Impact Analysis and elsewhere as not factual, then there is not much more to discuss and we would simply have to agree to disagree. It has been said once by the RIPE NCC and disputed. It is YOU who is repeating it on multiple occasions. > > > Then, if this part of the policy change is of importance, resubmit it as a separate proposal, and preferably clearing up the PII mess a bit more. I have no beef with clearing that up. > > Any effort to ?clearing up the PII mess? has always been outside the scope of this proposal. This proposal is simply not about PII or contact information. That could be a subject for another policy proposal, of course, but one thing at a time. > cheers denis > > Tore & Jeroen > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From ripedenis at gmail.com Thu Jan 11 03:20:58 2024 From: ripedenis at gmail.com (denis walker) Date: Thu, 11 Jan 2024 03:20:58 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> Message-ID: Hi Tore and others On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > Hello again Jan, > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > Basically, any public company register would be illegal according to > > the interpretation you lean on here. > > Public company registries also need a lawful basis for processing. The > Norwegian public company registry, for example, uses the lawful basis > ?exercise of official authority? ? Article 6(1)(e) GDPR ? as its lawful > basis, see https://www.brreg.no/en/privacy-statement/. I would assume > that to be the case in most other countries as well. > > (Most) LIRs are not official authorities, so unlike public company > registries LIRs cannot use this lawful basis for publishing PII in the > RIPE Database. As I explained in the previous email, you only quoted half the GDPR condition here. It actually says, (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; As I also pointed out, during the discussion of 2022-01 (privacy) https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html it was accepted that there is a 'public interest' basis here. > > In any case, all of this is rather off-topic. 2023-04 does not change > the legal obligations on the LIRs relating to the publication of End > User contact information, It does not matter how many times you repeat this, it is still NOT true. You remove the line When an End User has a network using public address space this must be registered separately with the contact details of the End User. Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. nor does it change the RIPE Database Terms and > Conditions. If you want to publish PII in the RIPE Database, you need a > lawful basis. That's true today, and that will continue to be true if > 2023-04 passes. > > > > Or you could take the other stance and stop publishing *any* contact > > details regarding an object, because you cannot know whether the > > information is personal data or not. > > Exactly. LIRs may (but are not required to) chose this approach already > *today*. This is a common and long-standing practice which the RIPE NCC > has repeatedly clarified as compliant with today's policy. This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > It will continue to be compliant with the policy after 2023-04 passes, > as well. Thus, 2023-04 effects no change on the LIRs' obligations in > this regard. It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > I think that because the WG discussion has almost exclusively revolved > > around this alleged changing of policy requirements to publish End > > User contact information (which may or may not be PII), it is easy to > > lose track of what this proposal is *actually* all about. We are > > talking about two different things: > > > > 1) The actual intention behind the proposal: Making it possible to > > aggregate multiple IPv4 End User assignments that have consistent > > contact information and purpose into a single database object. > > This is not possible today, and that is what we want to make that > > possible, in the same way it is already possible in IPv6. Then limit the proposal to exactly this!!! > > > > 2) The *alleged* change to what kind of End User contact > > information is required to be published in the RIPE database. We > > have never had any intention of changing this in any way, and the > > Impact Analysis and other statements from the RIPE NCC confirm > > that the proposal does not change it either. This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > In short: 1) is an intentional and desired change from today, > > while 2) is *not* a change from today ? intentionally so. > > > > This (regarding item 2) is simply not true. Any change in text *is a > > change*. > > We are not making the claim that the policy text does not change. That > it clearly does ? in order to achieve the desired change described in > item 1 above. > > We are however claiming that the *meanings* of the old and the new > policy texts are exactly the same, with regards to how they translate > into operational procedures and requirements for the publication of End > User contact information (item 2). You must think that WE are the crazy people. You cannot remove the line 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > ?Acceptance of this proposal **will not change** the fact that the > RIPE NCC cannot enforce which contact details members add to their IPv4 > PA assignments in the RIPE Database; this **will remain** their decision.? > > So, once again: which End User contact details LIRs publish (if any) is > their decision today, and it will be continue to be their decision if > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > I have no problem with 1), as already stated. > > We're happy to hear that! > > > > I do agree with you that this is distracting from the proper meat of > > your proposal. Which is why I suggest that you drop this part of it. > > Again, drop the part of the proposal that people have a beef with. > > > > Don't make the change that you claim is not a change. > > This ?beef? is based on reading current policy to mean that which End > User contact details LIRs publish in the database (if any) is *not* the > LIRs' decision today. It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > But the RIPE NCC has repeatedly clarified that that is simply not the > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > decision should 2023-04 pass. You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > Given that, it is hard to see how we could possibly amend the proposal > to change this particular point to an even lesser extent than what is > already the case? Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. cheers denis > > > Tore & Jeroen > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Thu Jan 11 09:40:16 2024 From: tore at fud.no (Tore Anderson) Date: Thu, 11 Jan 2024 09:40:16 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> Message-ID: <1dd4f8f9-087b-4ae5-b176-b01948f56be0@fud.no> Hello Denis, On 11/01/24 01:40, denis walker wrote: > So personal data does not always need consent of the data > subject. But you only ever refer to (a) consent. There are indeed other possible lawful bases than consent, and this fact is precisely why I wrote (emphasis added): ?Publishing this information requires *a* lawful basis, *e.g.*, consent.? Consent is however the only lawful basis singled out by the RIPE NCC in the RIPE Database Terms and Conditions and in the 2023-04 Impact Analysis, so it seems reasonable to assume that some LIRs will seek consent. Therefore we need to examine what that actually means in practice. You sum it up quite accurately below: > If we take the latest revelation in the IA on 2023-04, ALL PII needs > consent, this has HUGE implications for the RIPE NCC and RIPE policy > generally. We MUST have a good understanding of the legal basis for > entering PII into the RIPE Database. Consent cannot be conditional. So > if a resource holder who is a natural person withdraws their consent > to have their PII in the database, it MUST be removed. That may leave > an allocation and organisation with no identity or contacts. That > would be a policy violation. BUT the resource cannot be reclaimed as > that would have made the consent conditional. Also we have an abuse > policy that requires all resources to have an abuse contact. If that > contact is a natural person and they withdraw their consent their > details must be deleted. Again that creates a policy violation. But > the resource cannot be reclaimed again as that would have made the > contact details consent conditional. Your conclusion that this situation results in a policy violation, is however entirely contingent on your interpretation of the current policy as mandating the publication of the End User's (non-delegated) contact information. Under the RIPE NCC's interpretation of the current policy, on the other hand, this situation is entirely unproblematic. Under their interpretation, the LIR has, quote, ?freedom to take over the responsibility as the point of contact for their End User?. No PII, no GDPR, no problem. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > Again you have selected just one example that can support your > argument, Farmer Fred. I could have used KPN or Apple Inc as an > example which would negate your argument. KPN or Apple would not be relevant examples, as they (presumably) would use non-personal NOC roles which are not PII, and thus out of scope of the GDPR. There are certainly many End Users whose contact information is not PII, but that does not ?negate? the fact that there are also many End Users whose contact information *is* PII. Both types of End Users must be catered to by the address policy. Tore & Jeroen From tore at fud.no Thu Jan 11 09:45:33 2024 From: tore at fud.no (Tore Anderson) Date: Thu, 11 Jan 2024 09:45:33 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> Message-ID: Hi Denis, On 11/01/24 03:20, denis walker wrote: > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: >> >> On 10/01/24 11:25, Jan Ingvoldstad wrote: >>> Or you could take the other stance and stop publishing *any* contact >>> details regarding an object, because you cannot know whether the >>> information is personal data or not. >> Exactly. LIRs may (but are not required to) chose this approach already >> *today*. This is a common and long-standing practice which the RIPE NCC >> has repeatedly clarified as compliant with today's policy. > This is one of your biggest false statements. The ONLY person > repeatedly saying this is YOU. Let's do a fact check here. Yes, let us indeed do a fact check: Exhibit 1: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 (specifically the ?counter-argument?, which the RIPE NCC Policy Officer confirmed to the proposers and the WG chairs as correctly representing the RIPE NCC's interpretation) Exhibit 3: https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis Exhibit 4: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html Four repetitions so far, all saying the same thing. How many more do you need? We note that you have requested further clarifications from the RIPE NCC tonight, which we of course look forward to. > This is total madness. You keep saying you have no intention of > changing anything else. You keep saying the wording change actually > changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has > nothing to do with aggregation and everyone is happy. The fact that > you are pushing so hard to make this wording change, you refuse to > back down or compromise, you insist on changing wording that changes > nothing and has nothing to do with aggregation...proves that you don't > believe that yourself. The fact is, I suspect that this is the real > change you want. You want to drop the current policy requirement to > define assignments with End User contacts. It is the aggregation that > is the side issue here. There is no other explanation for why you are > insisting so strongly on changing wording that changes nothing. Here we find ourselves in conspiracy theory land, frankly. It makes zero sense, too: If our ulterior goal was to remove the End User contacts from our own assignments we can just go ahead and do so, right now. The RIPE NCC is already on the record saying that's totally OK, and we would be following in the footsteps of many other LIRs who have already done so. Why on Earth would we waste our time on a policy proposal? If our ulterior goal was to remove the End User contacts from other LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because it conveys no requirement on LIRs to remove anything from the database whatsoever. The RIPE NCC has not identified any unintended or ulterior side effect caused by 2023-04 either, does that mean they are a part of the conspiracy too? >> As the RIPE NCC writes in the Impact Analysis (emphasis added): >> >> ?Acceptance of this proposal **will not change** the fact that the >> RIPE NCC cannot enforce which contact details members add to their IPv4 >> PA assignments in the RIPE Database; this **will remain** their decision.? >> >> So, once again: which End User contact details LIRs publish (if any) is >> their decision today, and it will be continue to be their decision if >> 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > This really does make me cry. The wording in the IA is poor. You have > applied an interpretation to this which I do not believe is what was > meant. Then the RIPE NCC legal team has remained silent. So I am > asking the RIPE NCC legal team to clearly explain what they meant by > this wording. The explanation you request was posted two days after the Impact Analysis was: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html ?LIRs are free to choose how to provide services and to who, this includes their freedom to take over the responsibility as the point of contact for their End User as well as having their maintainer in the IPv4 PA assignments they register.? This explanation aligns perfectly with our interpretation of the statement in the Impact Analysis. >> Given that, it is hard to see how we could possibly amend the proposal >> to change this particular point to an even lesser extent than what is >> already the case? > Let me help you. Do NOT remove a sentence that has nothing to do with > the stated goal of the proposal to aggregate assignments and that you > claim does not change anything. This sentence also has a lot to do with the stated goal of aggregating assignments, because it mandates that assignments must be ?registered separately?. That is clearly incompatible with aggregation. It would of course be possible to retain the old sentence as-is by combining it with the new one copied from the IPv6 policy by using an either/or construct, e.g.: ?When an End User has a network using public address space this must be registered separately with the contact details of the End User or by inserting an object with a status value of 'AGGREGATED-BY-LIR'?. That said, the actual policy outcome would as far as we can tell be exactly the same as 2023-04 in its current form, so we assume you would object to this language as well? Tore & Jeroen From frettled at gmail.com Thu Jan 11 09:46:41 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 11 Jan 2024 09:46:41 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <1dd4f8f9-087b-4ae5-b176-b01948f56be0@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <1dd4f8f9-087b-4ae5-b176-b01948f56be0@fud.no> Message-ID: On Thu, Jan 11, 2024 at 9:40?AM Tore Anderson wrote: > > Your conclusion that this situation results in a policy violation, is > however entirely contingent on your interpretation of the current policy > as mandating the publication of the End User's (non-delegated) contact > information. > Please stop misrepresenting this argument. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Thu Jan 11 10:19:51 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 11 Jan 2024 10:19:51 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> Message-ID: On Thu, Jan 11, 2024 at 9:45?AM Tore Anderson wrote: > Hi Denis, > > On 11/01/24 03:20, denis walker wrote: > > > This is total madness. You keep saying you have no intention of > > changing anything else. You keep saying the wording change actually > > changes nothing in practice. Some other people don't agree with you. > > Just don't change wording that you claim changes NOTHING and has > > nothing to do with aggregation and everyone is happy. The fact that > > you are pushing so hard to make this wording change, you refuse to > > back down or compromise, you insist on changing wording that changes > > nothing and has nothing to do with aggregation...proves that you don't > > believe that yourself. The fact is, I suspect that this is the real > > change you want. You want to drop the current policy requirement to > > define assignments with End User contacts. It is the aggregation that > > is the side issue here. There is no other explanation for why you are > > insisting so strongly on changing wording that changes nothing. > > Here we find ourselves in conspiracy theory land, frankly. Uh. While questioning your motives is perhaps a bit rude, this is WAY over the top, Tore. Please retract this weird accusation, I really don't understand your motives for trying to label this as having to do with a conspiracy theory. It tarnishes the discussion. > It makes zero > sense, too: > > If our ulterior goal was to remove the End User contacts from our own > assignments we can just go ahead and do so, right now. The RIPE NCC is > already on the record saying that's totally OK, and we would be > following in the footsteps of many other LIRs who have already done so. > Why on Earth would we waste our time on a policy proposal? > > If our ulterior goal was to remove the End User contacts from other > LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because > it conveys no requirement on LIRs to remove anything from the database > whatsoever. > > The RIPE NCC has not identified any unintended or ulterior side effect > caused by 2023-04 either, does that mean they are a part of the > conspiracy too? > While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy. I simply think that the RIPE NCC and you are mistaken. Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing. It undermines the community drive behind policies. If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Thu Jan 11 12:05:50 2024 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 11 Jan 2024 12:05:50 +0100 Subject: [address-policy-wg] Reducing IXP IPv4 assignment default size to a /26 In-Reply-To: References: Message-ID: On Tue, Sep 5, 2023, at 15:43, Viacheslav Adamanov wrote: > The problem with ipv4 network speculation for IXP is exaggerated. RIPE > NCC forbids transferring this networks to another company. > > Have there been cases of transmission of such networks? Late to the show, but yes, there are such cases ("transmission" of an IXP, blocks included). -- Radu-Adrian FEURDEAN From tore at fud.no Thu Jan 11 13:11:38 2024 From: tore at fud.no (Tore Anderson) Date: Thu, 11 Jan 2024 13:11:38 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> Message-ID: <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Hi Jan, On 11/01/24 10:19, Jan Ingvoldstad wrote: > > On Thu, Jan 11, 2024 at 9:45?AM Tore Anderson wrote: > > On 11/01/24 03:20, denis walker wrote: > > > This is total madness. You keep saying you have no intention of > > changing anything else. You keep saying the wording change actually > > changes nothing in practice. Some other people don't agree with you. > > Just don't change wording that you claim changes NOTHING and has > > nothing to do with aggregation and everyone is happy. The fact that > > you are pushing so hard to make this wording change, you refuse to > > back down or compromise, you insist on changing wording that changes > > nothing and has nothing to do with aggregation...proves that you > don't > > believe that yourself. The fact is, I suspect that this is the real > > change you want. You want to drop the current policy requirement to > > define assignments with End User contacts. It is the aggregation > that > > is the side issue here. There is no other explanation for why > you are > > insisting so strongly on changing wording that changes nothing. > > Here we find ourselves in conspiracy theory land, frankly. > > > Uh. While questioning your motives is perhaps a bit rude, this is WAY > over the top, Tore. > > Please retract this weird accusation, I really don't understand your > motives for trying to label this as having to do with a conspiracy > theory. It tarnishes the discussion. This goes far beyond ?questioning our motives?. There is an assertion of "proof" that Jeroen deliberately make statements that we do not believe ourselves, in other words that we are lying to the working group. It is suggested that we are maliciously attempting to deceive the working group as to our true motives for submitting the policy proposal and what changes it will effect, and that the stated motive ? introducing AGGREGATED-BY-LIR ? is a mere "side issue" which is not our true, hidden, motive. Presumably the RIPE NCC must also be actively participating in this deception, or at the very least turn a blind eye to it. This ticks all the boxes in the Wikipedia definition of a conspiracy theory, with the possible exception that Jeroen and I could not reasonably be classified as a ?powerful group?. That said, labels are unimportant, so consider the statement retracted. Let us instead say that we vehemently disagree with the allegation that there are any ulterior motives behind 2023-04 and that we are actively attempting to deceive the working group in any way. > While you seem to argue that the RIPE NCC is both omniscient and > omnicompetent, I do not think it is that easy. > > I simply think that the RIPE NCC and you are mistaken. That is fair enough. We note your disagreement with the RIPE NCC as well, which we take to mean you do not allege that we are actively and intentionally misrepresenting the RIPE NCC's position in our messages. That is something, at least. > Continously appealing to RIPE NCC as the authority of policy and > policy interpretation is not a good thing. The RIPE NCC is the secretariat of the RIPE Community and is delegated the task of implementing and enforcing the RIPE Community policies, as well as to providing training to the LIRs on how to operationalise said policies. If that is not an authority worth paying attention to, I do not know what is. After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy ? mistaken or not ? ends up becoming the (de facto) way the policy is implemented anyway. Tore & Jeroen From frettled at gmail.com Thu Jan 11 13:27:46 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 11 Jan 2024 13:27:46 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: On Thu, Jan 11, 2024 at 1:11?PM Tore Anderson wrote: > Hi Jan, > Hi Tore, skipping your blatant misconception of what constitutes a "conspiracy theory" ... > > Continously appealing to RIPE NCC as the authority of policy and > > policy interpretation is not a good thing. > > The RIPE NCC is the secretariat of the RIPE Community and is delegated > the task of implementing and enforcing the RIPE Community policies, as > well as to providing training to the LIRs on how to operationalise said > policies. If that is not an authority worth paying attention to, I do > not know what is. > > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. > This statement basically renders the point of a policy working group moot. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Thu Jan 11 14:11:02 2024 From: tore at fud.no (Tore Anderson) Date: Thu, 11 Jan 2024 14:11:02 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: Hi Jan, On 11/01/24 13:27, Jan Ingvoldstad wrote: > On Thu, Jan 11, 2024 at 1:11?PM Tore Anderson wrote: > > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's > interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way > the > policy is implemented anyway. > > This statement basically renders the point of a policy working group moot. Not at all. Any working group member who is of the opinion that the RIPE NCC is interpreting a RIPE Community policy incorrectly, is free to at any point submit a policy proposal that clarifies the allegedly misinterpreted policy text with the aim to make the RIPE NCC change its procedures accordingly. The RIPE NCC's Impact Analysis will then reveal whether or not the proposed new policy text does attain its goal and that the RIPE NCC will change its procedures as desired, should the proposal pass. Finally, the proposal will need to reach (rough) consensus in order to confirm that the RIPE Community does indeed concur with the proposer's opinion that the old policy was interpreted incorrectly, and that the RIPE NCC's procedures ought to change. Absent this, the RIPE NCC's operationalisation of the policy will stay as-is. Tore & Jeroen From ripe-lists at sebastian-graf.at Thu Jan 11 14:35:01 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Thu, 11 Jan 2024 14:35:01 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: Dear Tore/Denis: If we are looking at the Policy Language, then i'm not certain we are reading the same things into it. Or maybe i missed something. Feel free to point out the corresponding section of the policy to me. I'm more than happy to update my views if strong evidence is presented. As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed. Lets look at the actual language in the policy: > "All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations." The way i read it, this point is filled both with the current state of things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it. So lets look at what needs to be documented: > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it. If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party. In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling. > "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." The other thing that i do not read from the statement is where it asks to put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....). ANYWAY.... I still do not feel anything of significance would be lost, if something could be lost at all. My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now. This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information.". If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.". If we consider the usefulnes of data entered into the ripe-db for this purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend. If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a *duty of confidentiality to their registrants*. Information passed to an IR must be securely stored and *must not be distributed wider than necessary within the IR*.". So i am not certain why you are trying to force more data than actually required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's. During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss.... Regards Sebastian On 1/11/24 13:11, Tore Anderson wrote: > Hi Jan, > > On 11/01/24 10:19, Jan Ingvoldstad wrote: >> >> On Thu, Jan 11, 2024 at 9:45?AM Tore Anderson wrote: >> >> ??? On 11/01/24 03:20, denis walker wrote: >> >> ??? > This is total madness. You keep saying you have no intention of >> ??? > changing anything else. You keep saying the wording change >> actually >> ??? > changes nothing in practice. Some other people don't agree with >> you. >> ??? > Just don't change wording that you claim changes NOTHING and has >> ??? > nothing to do with aggregation and everyone is happy. The fact >> that >> ??? > you are pushing so hard to make this wording change, you refuse to >> ??? > back down or compromise, you insist on changing wording that >> changes >> ??? > nothing and has nothing to do with aggregation...proves that you >> ??? don't >> ??? > believe that yourself. The fact is, I suspect that this is the >> real >> ??? > change you want. You want to drop the current policy >> requirement to >> ??? > define assignments with End User contacts. It is the aggregation >> ??? that >> ??? > is the side issue here. There is no other explanation for why >> ??? you are >> ??? > insisting so strongly on changing wording that changes nothing. >> >> ??? Here we find ourselves in conspiracy theory land, frankly. >> >> >> Uh. While questioning your motives is perhaps a bit rude, this is WAY >> over the top, Tore. >> >> Please retract this weird accusation, I really don't understand your >> motives for trying to label this as having to do with a conspiracy >> theory. It tarnishes the discussion. > > This goes far beyond ?questioning our motives?. There is an assertion > of "proof" that Jeroen deliberately make statements that we do not > believe ourselves, in other words that we are lying to the working > group. It is suggested that we are maliciously attempting to deceive > the working group as to our true motives for submitting the policy > proposal and what changes it will effect, and that the stated motive ? > introducing AGGREGATED-BY-LIR ? is a mere "side issue" which is not > our true, hidden, motive. > > Presumably the RIPE NCC must also be actively participating in this > deception, or at the very least turn a blind eye to it. > > This ticks all the boxes in the Wikipedia definition of a conspiracy > theory, with the possible exception that Jeroen and I could not > reasonably be classified as a ?powerful group?. > > That said, labels are unimportant, so consider the statement > retracted. Let us instead say that we vehemently disagree with the > allegation that there are any ulterior motives behind 2023-04 and that > we are actively attempting to deceive the working group in any way. > > >> While you seem to argue that the RIPE NCC is both omniscient and >> omnicompetent, I do not think it is that easy. >> >> I simply think that the RIPE NCC and you are mistaken. > > That is fair enough. We note your disagreement with the RIPE NCC as > well, which we take to mean you do not allege that we are actively and > intentionally misrepresenting the RIPE NCC's position in our messages. > That is something, at least. > > >> Continously appealing to RIPE NCC as the authority of policy and >> policy interpretation is not a good thing. > > The RIPE NCC is the secretariat of the RIPE Community and is delegated > the task of implementing and enforcing the RIPE Community policies, as > well as to providing training to the LIRs on how to operationalise > said policies. If that is not an authority worth paying attention to, > I do not know what is. > > After all, any LIR which prefers the RIPE NCC interpretation of the > policy in this regard is may simply adhere to it and act accordingly, > and this is commonly done today. Thus the RIPE NCC's interpretation of > the policy ? mistaken or not ? ends up becoming the (de facto) way the > policy is implemented anyway. > > > Tore & Jeroen > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Thu Jan 11 14:42:43 2024 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 11 Jan 2024 05:42:43 -0800 Subject: [address-policy-wg] RIPE Code of Conduct and discussion on this list Message-ID: Dear Working Group, Earlier, Denis sent a message that contained multiple ad-hominem attacks on the proposers of 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments). This is in conflict with our Code of Conduct. We will not tolerate breaches of the Code of conduct. As a reminder, our Code of Conduct urges us to "be open, considerate, and respectful." Further, "Aggressive communication" such as "Calling people offensive names" is not allowed. Denis has previously had a private warning. As this is his second breach in a discussion of this proposal, we will instruct the RIPE NCC to stop him from posting to the list for 30 days. Also, as the discussion has derailed, we will extend the Review Phase by four weeks. We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs From ripe-lists at sebastian-graf.at Thu Jan 11 15:22:49 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Thu, 11 Jan 2024 15:22:49 +0100 Subject: [address-policy-wg] RIPE Code of Conduct and discussion on this list In-Reply-To: References: Message-ID: <9a09cfc1-d3f0-4cdd-8b37-637dcb3e2f83@sebastian-graf.at> Dear Leo Vegoda/ List Members! I can only speak to my perception of the situation, however i would ask you to please consider the content of this email: While the communication from dennis was certainly not in line with the code of conduct, i do see that he is very passionate about the topic. I am not sure if the proposers of 2023-04 would agree, but i do belive there is currently a very important discussion going on. This is about how the policy/language in it is interpreted and the resulting implications. Certainly, discussions can be heated, and i would also like denis to understand that there are acceptable and non-acceptable ways to communicate. At the same time, it feels very wrong to "cut" him out of the discussion at this point, by suspending his ability to post. Please note that i hold opposing views to his, but i would still like to hear/read his inputs, if he can manage to communicate it in a more constructive way going forward. So is there any alternative course of action that allows this discussion to move forward with dennis being able to participate at the current stage? That said,? I fully agree and support the descision to extend the disucssion deadline by 4 Weeks! Kind Regards Sebastian On 1/11/24 14:42, Leo Vegoda wrote: > Dear Working Group, > > Earlier, Denis sent a message that contained multiple ad-hominem > attacks on the proposers of 2023-04 (Add AGGREGATED-BY-LIR status for > IPv4 PA assignments). This is in conflict with our Code of Conduct. We > will not tolerate breaches of the Code of conduct. > > As a reminder, our Code of Conduct urges us to "be open, considerate, > and respectful." Further, "Aggressive communication" such as "Calling > people offensive names" is not allowed. > > Denis has previously had a private warning. As this is his second > breach in a discussion of this proposal, we will instruct the RIPE NCC > to stop him from posting to the list for 30 days. > > Also, as the discussion has derailed, we will extend the Review Phase > by four weeks. We encourage everyone to focus comments on the proposal > and its potential impact. Do not comment on individuals, their > characteristics, or motivations. > > Kind regards, > > Leo Vegoda, for the Address Policy WG co-chairs > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB3F9792B5ACD96C.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ripe-wgs.cs at schiefner.de Thu Jan 11 16:05:22 2024 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 11 Jan 2024 16:05:22 +0100 Subject: [address-policy-wg] RIPE Code of Conduct and discussion on this list In-Reply-To: References: Message-ID: Hi Leo and AP WG co-chairs, On 11.01.2024 14:42, Leo Vegoda wrote: > Earlier, Denis sent a message I'd assume that you refer to one of these two most recent emails from Denis of the "[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)" thread: * Date: Thu, 11 Jan 2024 01:40:33 +0100 * Date: Thu, 11 Jan 2024 03:20:58 +0100 These two emails most certainly bear a quite robust style of writing. Also wrt. content they - taking Tore's emails also into account for a full picture - are heavily going in circles. However, having just re-read them carefully again, I fail to see multiple ad-hominem attacks and/or "Aggressive communication" such as "Calling people offensive names" as you line out here: > that contained multiple ad-hominem > attacks on the proposers of 2023-04 (Add AGGREGATED-BY-LIR status for > IPv4 PA assignments). This is in conflict with our Code of Conduct. We > will not tolerate breaches of the Code of conduct. > > As a reminder, our Code of Conduct urges us to "be open, considerate, > and respectful." Further, "Aggressive communication" such as "Calling > people offensive names" is not allowed. Certainly, different people will come to different judgements in their respective assessments of third parties' communications styles - that is why would like to share mine: I truly believe that Denis' communication style is heavily "passionate" (thanks, Sebastian! ;-) but IMHO still fully within the boundaries set by the Code of Conduct. Therefore... > Denis has previously had a private warning. As this is his second > breach in a discussion of this proposal, we will instruct the RIPE NCC > to stop him from posting to the list for 30 days. ... I'd like to ask you as the AP WG co-chairs collective to reconsider your decision to temporarily revoke Denis' posting rights. Thank you! > Also, as the discussion has derailed, we will extend the Review Phase > by four weeks. This makes all the sense to me. Thanks again! > We encourage everyone to focus comments on the proposal > and its potential impact. Do not comment on individuals, their > characteristics, or motivations. Strictly separating comments on the proposal and its potential impact from those of perceived motivations can be tricky at times - even more so as the proposals themselves bear their respective motivation. Or reasoning. Or whatever you want to call it. Doubting the motivation of the proposal and instead assuming another one should IMHO still be considered as part of a fruitful discussion. Yes, the line can get very thin very quickly. But we're not - see above - yet there and across it, I believe. All the best, -C. From frettled at gmail.com Fri Jan 12 07:25:05 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 12 Jan 2024 07:25:05 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: On Thu, Jan 11, 2024 at 2:11?PM Tore Anderson wrote: > Hi Jan, > > Hi Tore, > On 11/01/24 13:27, Jan Ingvoldstad wrote: > > On Thu, Jan 11, 2024 at 1:11?PM Tore Anderson wrote: > > > > After all, any LIR which prefers the RIPE NCC interpretation of the > > policy in this regard is may simply adhere to it and act accordingly, > > and this is commonly done today. Thus the RIPE NCC's > > interpretation of > > the policy ? mistaken or not ? ends up becoming the (de facto) way > > the > > policy is implemented anyway. > > > > This statement basically renders the point of a policy working group > moot. > > Not at all. Any working group member who is of the opinion that the RIPE > NCC is interpreting a RIPE Community policy incorrectly, is free to at > any point submit a policy proposal that clarifies the allegedly > misinterpreted policy text with the aim to make the RIPE NCC change its > procedures accordingly. > > The RIPE NCC's Impact Analysis will then reveal whether or not the > proposed new policy text does attain its goal and that the RIPE NCC will > change its procedures as desired, should the proposal pass. > > Finally, the proposal will need to reach (rough) consensus in order to > confirm that the RIPE Community does indeed concur with the proposer's > opinion that the old policy was interpreted incorrectly, and that the > RIPE NCC's procedures ought to change. > > Absent this, the RIPE NCC's operationalisation of the policy will stay > as-is. > > This would make sense if the argument was not so circular. I also do not understand what makes it so hard to say that: "Yes, the current policy does state something else than NCC's interpretation of it does, and therefore current practice contradicts (or appears to contradict) policy. However, we, the proposers, believe that the current practice makes for the best policy, and therefore propose amending the policy to reflect practice." -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Jan 12 08:12:02 2024 From: tore at fud.no (Tore Anderson) Date: Fri, 12 Jan 2024 08:12:02 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: <9725c7fa-dc51-47e9-8ddb-17ffd8fdfeb1@fud.no> Good morning Jan, On 12/01/24 07:25, Jan Ingvoldstad wrote: > I also do not understand what makes it so hard to say that: "Yes, the > current policy does state something else than NCC's interpretation of > it does, (?) We do not make statements that we do not believe to be true. In our opinion, the RIPE NCC implements current policy correctly. Tore & Jeroen From alexlh at funk.org Fri Jan 12 08:56:48 2024 From: alexlh at funk.org (Alex Le Heux) Date: Fri, 12 Jan 2024 08:56:48 +0100 Subject: [address-policy-wg] 2023-04 Discussion scope Message-ID: Dear Working Group, During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. We would like to point out the following: From the RIPE NCC Impact Analysis: [...] Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. [...] As well as: It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. Kind regards, Alex Le Heux, for the Address Policy WG co-chairs From ripe-lists at sebastian-graf.at Fri Jan 12 08:57:13 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Fri, 12 Jan 2024 08:57:13 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> Message-ID: <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> Dear Jan! As mentioned in my previous e-mail: Would you please post the section of the policy that you belive has the NCC's interpretation differ from the actual wording/language used? Because i have yet to find a section that states explicitly what is considered valid vs invalid contact information (other than being out of date or information that does not provide a contact to the user in a timely manner). Or a section that restricts what kind of data is permissable for "contact information". Kind Regards On 1/12/24 07:25, Jan Ingvoldstad wrote: > I also do not understand what makes it so hard to say that: "Yes, the > current policy does state something else than NCC's interpretation of > it does, and therefore current practice contradicts (or appears to > contradict) policy. However, we, the proposers, believe that the > current practice makes for the best policy, and therefore propose > amending the policy to reflect practice." From ripe-lists at sebastian-graf.at Fri Jan 12 09:08:25 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Fri, 12 Jan 2024 09:08:25 +0100 Subject: [address-policy-wg] Best Operatonal Practices Registration/Contact Information - WAS:: 2023-04 Discussion scope In-Reply-To: References: Message-ID: <4e96b332-3357-45f8-aeb8-f742fc965d28@sebastian-graf.at> Dear WG! I would like to propose that we start working on *a "Best current operational Practices" Document for "Registration Information/Contact Information".* The idea is that the document is done in a similar manner to the "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users"(https://www.ripe.net/publications/docs/ripe-690). Why do it this way, instead of alter the policy? I do not belive we would ever be able to accuratly cover every possible scenario (without introducing a lot of annoyance/complexity/overhead). However..having a guide/idea to help community members with common scenarios/inspiration for the own documentation - makes a lot of sense. Kind regards, Sebastian On 1/12/24 08:56, Alex Le Heux wrote: > Dear Working Group, > > During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. > > We would like to point out the following: > > From the RIPE NCC Impact Analysis: > > [...] > > Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. > > [...] > > As well as: > > It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. > > > > In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. > > It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. > > However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. > > Kind regards, > > Alex Le Heux, for the Address Policy WG co-chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB3F9792B5ACD96C.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From frettled at gmail.com Fri Jan 12 09:21:14 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 12 Jan 2024 09:21:14 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> References: <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> Message-ID: On Fri, Jan 12, 2024 at 8:57?AM Sebastian Graf wrote: > Dear Jan! > Dear Sebastian, thanks for chiming in! > > As mentioned in my previous e-mail: Would you please post the section of > the policy that you belive has the NCC's interpretation differ from the > actual wording/language used? > https://www.ripe.net/participate/policies/proposals/2023-04 6.2 Network Infrastructure and End User Networks ? "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users." The removal of this text has seen many strange arguments, such as GDPR (which is already covered by the text being removed). Because i have yet to find a section that states explicitly what is > considered valid vs invalid contact information (other than being out of > date or information that does not provide a contact to the user in a > timely manner). Or a section that restricts what kind of data is > permissable for "contact information". As I understand it, the RIPE NCC's interpretation, and the one that Tore leans on, is that the text does not mean that organisation End User contact details must be published, even though they are not individual users. The argument therefore appears to be that the text "When an End User has a network using public address space this must be registered separately with the contact details of the End User." should be read as "" in the current policy document, and that changing "When an End User has a network using public address space this must be registered separately with the contact details of the End User." to "" changes nothing in the policy. My stance is that this changes the policy, but that it changes the policy to be in line with current practice. (As a side note, 10-15 years ago, my employer received quite a lot of flak for NOT publishing contact details for every single customer that had the use of single, dedicated IP addresses, as part of web hosting or colocation services, with rerference to this very policy. How times change.) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-lists at sebastian-graf.at Fri Jan 12 09:28:06 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Fri, 12 Jan 2024 09:28:06 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> Message-ID: Dear Jan! Thank you for your reply. But you have not answerred my question. We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information). We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation. Unless i missed something? Regards On 1/12/24 09:21, Jan Ingvoldstad wrote: > > On Fri, Jan 12, 2024 at 8:57?AM Sebastian Graf > wrote: > > Dear Jan! > > > Dear Sebastian, thanks for chiming in! > > > As mentioned in my previous e-mail: Would you please post the > section of > the policy that you belive has the NCC's interpretation differ > from the > actual wording/language used? > > > https://www.ripe.net/participate/policies/proposals/2023-04 > > > 6.2 Network Infrastructure and End User Networks > > ? > > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User. > Where the End User is an individual rather than an organisation, the > contact information of the service provider may be substituted for the > End Users." > > > The removal of this text has seen many strange arguments, such as GDPR > (which is already covered by the text being removed). > > > Because i have yet to find a section that states explicitly what is > considered valid vs invalid contact information (other than being > out of > date or information that does not provide a contact to the user in a > timely manner). Or a section that restricts what kind of data is > permissable for "contact information". > > > As I understand it, the RIPE NCC's interpretation, and the one that > Tore leans on, is that the text does not mean that organisation End > User contact details must be published, even though they are not > individual users. > > The argument therefore appears to be that the text "When an End User > has a network using public address space this must be registered > separately with the contact details of the End User." should be read > as "" in the current policy document, and that changing "When an End > User has a network using public address space this must be registered > separately with the contact details of the End User." to "" changes > nothing in the policy. > > > My stance is that this changes the policy, but that it changes the > policy to be in line with current practice. > > (As a side note, 10-15 years ago, my employer received quite a lot of > flak for NOT publishing contact details for every single customer that > had the use of single, dedicated IP addresses, as part of web hosting > or colocation services, with rerference to this very policy. How times > change.) > > -- > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB3F9792B5ACD96C.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From frettled at gmail.com Fri Jan 12 09:40:41 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 12 Jan 2024 09:40:41 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <0427f84f-2e21-4665-a85d-ea7903cbee13@fud.no> <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> Message-ID: On Fri, Jan 12, 2024 at 9:28?AM Sebastian Graf wrote: > Dear Jan! > Dear Sebastian, > Thank you for your reply. But you have not answerred my question. > I answered your question, but I did not understand that you intended your ancillary comment as an additional question. Sorry about that. > We are all clear/well aware on the fact that the policy states > (paraphrasing here: resources need to be registered and the registions need > to have contact information). > > We are looking for the DEFINITION of "contact details of the End User.". > This is not directly defined (as far as i can tell) and is therefore open > for interpretation. > > Unless i missed something? > > > As I understand it, this comes from how contact objects are defined in the database, and this is what RIPE-804 references. Denis has provided more detailed context. RIPE-705 sets specific requirements regarding abuse contact details. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-lists at sebastian-graf.at Fri Jan 12 10:35:36 2024 From: ripe-lists at sebastian-graf.at (Sebastian Graf) Date: Fri, 12 Jan 2024 10:35:36 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <4b9516ff-21e7-45b5-90d1-6e17387bb52d@fud.no> <5c457b41-b9f4-4942-8e27-181e73726001@fud.no> <8a01f7df-390b-4928-bf7c-6584c80587dd@fud.no> <0358e4da-f314-4eaa-8c84-56bea25ff5f0@sebastian-graf.at> Message-ID: <4aefc5f8-1109-4cef-a6e0-7efd28fd6a00@sebastian-graf.at> Dear Jan! You and Denis are arguing that registration/user data needs to include certain (sometimes? sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement. When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer. I have read every single of denis replies/comments. When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details". According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion). The relationship is policy -to- database. Not Database -to- Policy. And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is permissable. Just that it needs to be maintained (meaning "if it works" -> OK). In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts). I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else. Regards On 1/12/24 09:40, Jan Ingvoldstad wrote: > On Fri, Jan 12, 2024 at 9:28?AM Sebastian Graf > wrote: > > Dear Jan! > > > Dear Sebastian, > > Thank you for your reply. But you have not answerred my question. > > I answered your question, but I did not understand that you intended > your ancillary comment as an additional question. Sorry about that. > > We are all clear/well aware on the fact that the policy states > (paraphrasing here: resources need to be registered and the > registions need to have contact information). > > We are looking for the DEFINITION of "contact details of the End > User.". This is not directly defined (as far as i can tell) and is > therefore open for interpretation. > > Unless i missed something? > > > As I understand it, this comes from how contact objects are defined in > the database, and this is what RIPE-804 references. > > Denis has provided more detailed context. > > RIPE-705 sets specific requirements regarding abuse contact details. > > -- > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Jan 12 11:38:59 2024 From: gert at space.net (Gert Doering) Date: Fri, 12 Jan 2024 11:38:59 +0100 Subject: [address-policy-wg] 2023-04 Discussion scope In-Reply-To: References: Message-ID: Hi, On Fri, Jan 12, 2024 at 08:56:48AM +0100, Alex Le Heux wrote: > However, is has been argued that this interpretation is wrong and > that PA Assignments in the RIPE DB must include the actual end-user > details. And even though this is out of scope for the 2023-04 > discussion, it is still something that is worth resolving. As > changing this interpretation would be a major departure of many > years of accepted practice and potentially involve updating thousands > of RIPE DB objects, we feel this discussion would be best served > by an independent policy proposal that clarifies the issue and would > like to invite the working group to enter one. This. I personally feel that the way this is currently handled "by all parties involved" is reasonable middle ground - documentation is available, and the level of end-user detail depends on local agreements and also requirements. I am aware that Dennis found text in the policy documents that require doing something different, namely having admin-c "on site", whatever that may mean in a context where the "ASSIGNED PA" inetnum is in a datacenter somewhere (so, nobody "on site", in particularily not "working for the customer"). So formally there is a conflict. But this is all outside of 2023-04, so if we think that the current way of "getting things done" is in conflict to (very very old) policy text, it sounds as if we need to adjust that old text, because "overtaken by history". I'm not actively volunteering, just supporting Alex' point :-) Gert Doering -- LIR contact since 1995 or so... -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Emmanuel.Kessler at europol.europa.eu Mon Jan 15 11:31:59 2024 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Mon, 15 Jan 2024 10:31:59 +0000 Subject: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: Dear all, we keep analysing the possible consequences of the measure on our LEA capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. We still identify two issues in the measure - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. it is also linked with internal practices in the companies that remain various...we know that. Situation with IPV4 is different than the one with IPV6. Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. Thank you for your exchange and cooperation Regards Emmanuel Kessler European Cybercrime centre EUROPOL -----Original Message----- From: denis walker Sent: 11 January 2024 03:21 To: Tore Anderson ; Maria Stafyla Cc: Jan Ingvoldstad ; address-policy-wg at ripe.net; Frank Breedijk ; Kessler, Emmanuel Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: denis1 at gmail.com Hi Tore and others On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > Hello again Jan, > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > Basically, any public company register would be illegal according to > > the interpretation you lean on here. > > Public company registries also need a lawful basis for processing. The > Norwegian public company registry, for example, uses the lawful basis > ?exercise of official authority? ? Article 6(1)(e) GDPR ? as its > lawful basis, see https://www.brreg.no/en/privacy-statement/. I would > assume that to be the case in most other countries as well. > > (Most) LIRs are not official authorities, so unlike public company > registries LIRs cannot use this lawful basis for publishing PII in the > RIPE Database. As I explained in the previous email, you only quoted half the GDPR condition here. It actually says, (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; As I also pointed out, during the discussion of 2022-01 (privacy) https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html it was accepted that there is a 'public interest' basis here. > > In any case, all of this is rather off-topic. 2023-04 does not change > the legal obligations on the LIRs relating to the publication of End > User contact information, It does not matter how many times you repeat this, it is still NOT true. You remove the line When an End User has a network using public address space this must be registered separately with the contact details of the End User. Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. nor does it change the RIPE Database Terms and > Conditions. If you want to publish PII in the RIPE Database, you need > a lawful basis. That's true today, and that will continue to be true > if > 2023-04 passes. > > > > Or you could take the other stance and stop publishing *any* contact > > details regarding an object, because you cannot know whether the > > information is personal data or not. > > Exactly. LIRs may (but are not required to) chose this approach > already *today*. This is a common and long-standing practice which the > RIPE NCC has repeatedly clarified as compliant with today's policy. This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > It will continue to be compliant with the policy after 2023-04 passes, > as well. Thus, 2023-04 effects no change on the LIRs' obligations in > this regard. It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > I think that because the WG discussion has almost exclusively > > revolved around this alleged changing of policy requirements to > > publish End User contact information (which may or may not be PII), > > it is easy to lose track of what this proposal is *actually* all > > about. We are talking about two different things: > > > > 1) The actual intention behind the proposal: Making it possible to > > aggregate multiple IPv4 End User assignments that have consistent > > contact information and purpose into a single database object. > > This is not possible today, and that is what we want to make that > > possible, in the same way it is already possible in IPv6. Then limit the proposal to exactly this!!! > > > > 2) The *alleged* change to what kind of End User contact > > information is required to be published in the RIPE database. We > > have never had any intention of changing this in any way, and the > > Impact Analysis and other statements from the RIPE NCC confirm > > that the proposal does not change it either. This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > In short: 1) is an intentional and desired change from today, > > while 2) is *not* a change from today ? intentionally so. > > > > This (regarding item 2) is simply not true. Any change in text *is a > > change*. > > We are not making the claim that the policy text does not change. That > it clearly does ? in order to achieve the desired change described in > item 1 above. > > We are however claiming that the *meanings* of the old and the new > policy texts are exactly the same, with regards to how they translate > into operational procedures and requirements for the publication of > End User contact information (item 2). You must think that WE are the crazy people. You cannot remove the line 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > ?Acceptance of this proposal **will not change** the fact that > the RIPE NCC cannot enforce which contact details members add to their > IPv4 PA assignments in the RIPE Database; this **will remain** their > decision.? > > So, once again: which End User contact details LIRs publish (if any) > is their decision today, and it will be continue to be their decision > if > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > I have no problem with 1), as already stated. > > We're happy to hear that! > > > > I do agree with you that this is distracting from the proper meat of > > your proposal. Which is why I suggest that you drop this part of it. > > Again, drop the part of the proposal that people have a beef with. > > > > Don't make the change that you claim is not a change. > > This ?beef? is based on reading current policy to mean that which End > User contact details LIRs publish in the database (if any) is *not* > the LIRs' decision today. It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > But the RIPE NCC has repeatedly clarified that that is simply not the > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > decision should 2023-04 pass. You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > Given that, it is hard to see how we could possibly amend the proposal > to change this particular point to an even lesser extent than what is > already the case? Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. cheers denis > > > Tore & Jeroen > > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ From Emmanuel.Kessler at europol.europa.eu Tue Jan 16 09:00:54 2024 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Tue, 16 Jan 2024 08:00:54 +0000 Subject: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: <819044898b6346fe8ac52a47c67fc7cb@europol.europa.eu> Hello, Tore Thanks for your message, I dare keep my message in the loop as there is for us a fundamental point here, I take note of yours, and may understand your wish to advance in the debate? However,? excluding this matter from the discussion should still depend on the certainty that there are no consequences on the way the data will be processed? ?As I read the various inputs, I observe that the below statement (?no impact on end user data available?) and the relevancy of still discussing this point (or not), is not a matter of consensus in the group? some of our investigators, assessing the proposal, also observe a risk of future losses of information that are highly considered on EU side, to be honest? I remember that the loss of granularity was also acknowledged by another member of the group (who seemed to consider it as a collateral damage), in the chat I had during the latest RIPE session on November Considering the challenges for companies on processing IPV4, any simplification will damage identification effort. in the content your quote below, a possible option is mentioned about a separate policy proposal to clarify the internal aggregation processes at company level,? so as to ensure a right process, achieving this one would then ideally be a pre-condition before considering the current one we discuss. from our views, we need to check precisely the extend of the reality of ?no impact on the end user data available? as it will fully condition our views on the measure?and could have a real impact on the way to grant security matters for citizens. Here a fair debate with all, using the necessary time, would really help, so as to fully clarify it.. in the past, on various occasion, new measures have been taken in various international groups,?identification capacities got weakened and we observed increasingly more obstacles (identification gaps) in our investigation, but it was then too late, once the measure implemented, ?and what disappears is by definition harder to precisely measure and fully prove,?!! it does not mean the damage does not exist. Thanks for your understanding of my position, as the matter also interests various services and authorities at EU level (Law enforcement, Justice, and also digital matters) Best regards Emmanuel Kessler Europol From: Tore Anderson Sent: 15 January 2024 12:08 To: Kessler, Emmanuel Cc: ?ileris, Edvardas ; 'BAUER-BULST Cathrin' ; Azofra Mart?nez, ?lvaro ; Frank Breedijk ; Maria Stafyla ; Jeroen Lauwers Subject: Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: tore at fud.no Hello Emmanuel, I removed the AP-WG mailing list from the CC list here, because the Working Group chairs have declared the subject of end user contact details as being out of scope for this proposal. The chairs state: ?It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments? Please see: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/013982.html We hope you will take this into consideration as you continue your evaluation of this policy proposal. Best regards, Tore & Jeroen On 15/01/24 11:31, Kessler, Emmanuel wrote: Dear all, we keep analysing the possible consequences of the measure on our LEA capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. We still identify two issues in the measure - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. it is also linked with internal practices in the companies that remain various...we know that. Situation with IPV4 is different than the one with IPV6. Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. Thank you for your exchange and cooperation Regards Emmanuel Kessler European Cybercrime centre EUROPOL -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Jan 16 10:44:35 2024 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 16 Jan 2024 10:44:35 +0100 Subject: [address-policy-wg] RIPE Code of Conduct and discussion on this list In-Reply-To: References: Message-ID: Dear Working Group, It is with a heavy heart that I now unsubscribe from this working group. The discussion climate combined with double standards from the WG co-chairs regarding the Code of Conduct means that spending effort here leaves a bad taste in my mouth. I wish you the best of luck in trying to resolve matters to the best of the Internet community. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Wed Jan 17 18:01:01 2024 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 17 Jan 2024 09:01:01 -0800 Subject: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Dear Emmanuel Kessler, It would help the co-chairs tremendously if your arguments gave some specific numbers or other details. We are aware of your concerns but phrases like "large potential impact" are vague. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Mon, 15 Jan 2024 at 02:32, Kessler, Emmanuel wrote: > > Dear all, > > we keep analysing the possible consequences of the measure on our LEA capacity to identify IPV4 > It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. > > We still identify two issues in the measure > > - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. > > - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. > > As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. > we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. > it is also linked with internal practices in the companies that remain various...we know that. > Situation with IPV4 is different than the one with IPV6. > Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. > > We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... > However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... > As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... > > We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. > > Thank you for your exchange and cooperation > > Regards > > Emmanuel Kessler > European Cybercrime centre > EUROPOL > > -----Original Message----- > From: denis walker > Sent: 11 January 2024 03:21 > To: Tore Anderson ; Maria Stafyla > Cc: Jan Ingvoldstad ; address-policy-wg at ripe.net; Frank Breedijk ; Kessler, Emmanuel > Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) > > > > This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. > The external address that sent the message is: denis1 at gmail.com > > > Hi Tore and others > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > > > Hello again Jan, > > > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > > Basically, any public company register would be illegal according to > > > the interpretation you lean on here. > > > > Public company registries also need a lawful basis for processing. The > > Norwegian public company registry, for example, uses the lawful basis > > ?exercise of official authority? ? Article 6(1)(e) GDPR ? as its > > lawful basis, see https://www.brreg.no/en/privacy-statement/. I would > > assume that to be the case in most other countries as well. > > > > (Most) LIRs are not official authorities, so unlike public company > > registries LIRs cannot use this lawful basis for publishing PII in the > > RIPE Database. > > As I explained in the previous email, you only quoted half the GDPR condition here. It actually says, > (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; As I also pointed out, during the discussion of 2022-01 (privacy) https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html > it was accepted that there is a 'public interest' basis here. > > > > > In any case, all of this is rather off-topic. 2023-04 does not change > > the legal obligations on the LIRs relating to the publication of End > > User contact information, > > It does not matter how many times you repeat this, it is still NOT true. You remove the line When an End User has a network using public address space this must be registered separately with the contact details of the End User. > Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. > > > nor does it change the RIPE Database Terms and > > Conditions. If you want to publish PII in the RIPE Database, you need > > a lawful basis. That's true today, and that will continue to be true > > if > > 2023-04 passes. > > > > > > > Or you could take the other stance and stop publishing *any* contact > > > details regarding an object, because you cannot know whether the > > > information is personal data or not. > > > > Exactly. LIRs may (but are not required to) chose this approach > > already *today*. This is a common and long-standing practice which the > > RIPE NCC has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): > 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > > > > It will continue to be compliant with the policy after 2023-04 passes, > > as well. Thus, 2023-04 effects no change on the LIRs' obligations in > > this regard. > > It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > > > > > I think that because the WG discussion has almost exclusively > > > revolved around this alleged changing of policy requirements to > > > publish End User contact information (which may or may not be PII), > > > it is easy to lose track of what this proposal is *actually* all > > > about. We are talking about two different things: > > > > > > 1) The actual intention behind the proposal: Making it possible to > > > aggregate multiple IPv4 End User assignments that have consistent > > > contact information and purpose into a single database object. > > > This is not possible today, and that is what we want to make that > > > possible, in the same way it is already possible in IPv6. > > Then limit the proposal to exactly this!!! > > > > > > > 2) The *alleged* change to what kind of End User contact > > > information is required to be published in the RIPE database. We > > > have never had any intention of changing this in any way, and the > > > Impact Analysis and other statements from the RIPE NCC confirm > > > that the proposal does not change it either. > > This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > > > > In short: 1) is an intentional and desired change from today, > > > while 2) is *not* a change from today ? intentionally so. > > > > > > This (regarding item 2) is simply not true. Any change in text *is a > > > change*. > > > > We are not making the claim that the policy text does not change. That > > it clearly does ? in order to achieve the desired change described in > > item 1 above. > > > > We are however claiming that the *meanings* of the old and the new > > policy texts are exactly the same, with regards to how they translate > > into operational procedures and requirements for the publication of > > End User contact information (item 2). > > You must think that WE are the crazy people. You cannot remove the line 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > > > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > > > ?Acceptance of this proposal **will not change** the fact that > > the RIPE NCC cannot enforce which contact details members add to their > > IPv4 PA assignments in the RIPE Database; this **will remain** their > > decision.? > > > > So, once again: which End User contact details LIRs publish (if any) > > is their decision today, and it will be continue to be their decision > > if > > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > > This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' > of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > > > I have no problem with 1), as already stated. > > > > We're happy to hear that! > > > > > > > I do agree with you that this is distracting from the proper meat of > > > your proposal. Which is why I suggest that you drop this part of it. > > > Again, drop the part of the proposal that people have a beef with. > > > > > > Don't make the change that you claim is not a change. > > > > This ?beef? is based on reading current policy to mean that which End > > User contact details LIRs publish in the database (if any) is *not* > > the LIRs' decision today. > > It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > > > > But the RIPE NCC has repeatedly clarified that that is simply not the > > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > > decision should 2023-04 pass. > > You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > > > > Given that, it is hard to see how we could possibly amend the proposal > > to change this particular point to an even lesser extent than what is > > already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. > > cheers > denis > > > > > > > Tore & Jeroen > > > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > > change your subscription options, please visit: > > https://mailman.ripe.net/ > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From Emmanuel.Kessler at europol.europa.eu Thu Jan 18 08:35:10 2024 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Thu, 18 Jan 2024 07:35:10 +0000 Subject: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: Dear Leo Vedoga, Thanks for your interest and constructive mind, statistics are sometimes a challenge in our activities however I consult my experts so as to provide you, a better idea of the impact. Kind regards Emmanuel Kessler Cybercrime centre-EUROPOL -----Original Message----- From: Leo Vegoda Sent: mercredi 17 janvier 2024 18:01 To: Kessler, Emmanuel Cc: address-policy-wg at ripe.net; ?ileris, Edvardas ; BAUER-BULST Cathrin ; Tore Anderson ; Azofra Mart?nez, ?lvaro ; Frank Breedijk ; Maria Stafyla Subject: Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: leo at vegoda.org Dear Emmanuel Kessler, It would help the co-chairs tremendously if your arguments gave some specific numbers or other details. We are aware of your concerns but phrases like "large potential impact" are vague. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Mon, 15 Jan 2024 at 02:32, Kessler, Emmanuel wrote: > > Dear all, > > we keep analysing the possible consequences of the measure on our LEA > capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. > > We still identify two issues in the measure > > - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. > > - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. > > As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. > we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. > it is also linked with internal practices in the companies that remain various...we know that. > Situation with IPV4 is different than the one with IPV6. > Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. > > We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... > However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... > As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... > > We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. > > Thank you for your exchange and cooperation > > Regards > > Emmanuel Kessler > European Cybercrime centre > EUROPOL > > -----Original Message----- > From: denis walker > Sent: 11 January 2024 03:21 > To: Tore Anderson ; Maria Stafyla > Cc: Jan Ingvoldstad ; address-policy-wg at ripe.net; > Frank Breedijk ; Kessler, Emmanuel > > Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add > AGGREGATED-BY-LIR status for IPv4 PA assignments) > > > > This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. > The external address that sent the message is: denis1 at gmail.com > > > Hi Tore and others > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: > > > > Hello again Jan, > > > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > > Basically, any public company register would be illegal according > > > to the interpretation you lean on here. > > > > Public company registries also need a lawful basis for processing. > > The Norwegian public company registry, for example, uses the lawful > > basis ?exercise of official authority? ? Article 6(1)(e) GDPR ? as > > its lawful basis, see https://www.brreg.no/en/privacy-statement/. I > > would assume that to be the case in most other countries as well. > > > > (Most) LIRs are not official authorities, so unlike public company > > registries LIRs cannot use this lawful basis for publishing PII in > > the RIPE Database. > > As I explained in the previous email, you only quoted half the GDPR > condition here. It actually says, > (e) processing is necessary for the performance of a task carried out > in the public interest or in the exercise of official authority vested > in the controller; As I also pointed out, during the discussion of > 2022-01 (privacy) > https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html > it was accepted that there is a 'public interest' basis here. > > > > > In any case, all of this is rather off-topic. 2023-04 does not > > change the legal obligations on the LIRs relating to the publication > > of End User contact information, > > It does not matter how many times you repeat this, it is still NOT true. You remove the line When an End User has a network using public address space this must be registered separately with the contact details of the End User. > Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. > > > nor does it change the RIPE Database Terms and > > Conditions. If you want to publish PII in the RIPE Database, you > > need a lawful basis. That's true today, and that will continue to be > > true if > > 2023-04 passes. > > > > > > > Or you could take the other stance and stop publishing *any* > > > contact details regarding an object, because you cannot know > > > whether the information is personal data or not. > > > > Exactly. LIRs may (but are not required to) chose this approach > > already *today*. This is a common and long-standing practice which > > the RIPE NCC has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): > 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > > > > It will continue to be compliant with the policy after 2023-04 > > passes, as well. Thus, 2023-04 effects no change on the LIRs' > > obligations in this regard. > > It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > > > > > I think that because the WG discussion has almost exclusively > > > revolved around this alleged changing of policy requirements to > > > publish End User contact information (which may or may not be > > > PII), it is easy to lose track of what this proposal is *actually* > > > all about. We are talking about two different things: > > > > > > 1) The actual intention behind the proposal: Making it possible to > > > aggregate multiple IPv4 End User assignments that have consistent > > > contact information and purpose into a single database object. > > > This is not possible today, and that is what we want to make that > > > possible, in the same way it is already possible in IPv6. > > Then limit the proposal to exactly this!!! > > > > > > > 2) The *alleged* change to what kind of End User contact > > > information is required to be published in the RIPE database. We > > > have never had any intention of changing this in any way, and the > > > Impact Analysis and other statements from the RIPE NCC confirm > > > that the proposal does not change it either. > > This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > > > > In short: 1) is an intentional and desired change from today, > > > while 2) is *not* a change from today ? intentionally so. > > > > > > This (regarding item 2) is simply not true. Any change in text *is > > > a change*. > > > > We are not making the claim that the policy text does not change. > > That it clearly does ? in order to achieve the desired change > > described in item 1 above. > > > > We are however claiming that the *meanings* of the old and the new > > policy texts are exactly the same, with regards to how they > > translate into operational procedures and requirements for the > > publication of End User contact information (item 2). > > You must think that WE are the crazy people. You cannot remove the line 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > > > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > > > ?Acceptance of this proposal **will not change** the fact that > > the RIPE NCC cannot enforce which contact details members add to > > their > > IPv4 PA assignments in the RIPE Database; this **will remain** their > > decision.? > > > > So, once again: which End User contact details LIRs publish (if any) > > is their decision today, and it will be continue to be their > > decision if > > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > > This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' > of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > > > I have no problem with 1), as already stated. > > > > We're happy to hear that! > > > > > > > I do agree with you that this is distracting from the proper meat > > > of your proposal. Which is why I suggest that you drop this part of it. > > > Again, drop the part of the proposal that people have a beef with. > > > > > > Don't make the change that you claim is not a change. > > > > This ?beef? is based on reading current policy to mean that which > > End User contact details LIRs publish in the database (if any) is > > *not* the LIRs' decision today. > > It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > > > > But the RIPE NCC has repeatedly clarified that that is simply not > > the > > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > > decision should 2023-04 pass. > > You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > > > > Given that, it is hard to see how we could possibly amend the > > proposal to change this particular point to an even lesser extent > > than what is already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. > > cheers > denis > > > > > > > Tore & Jeroen > > > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > > change your subscription options, please visit: > > https://mailman.ripe.net/ > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ From adallara at ripe.net Thu Jan 18 09:14:56 2024 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 18 Jan 2024 09:14:56 +0100 Subject: [address-policy-wg] 2023-04 Review Phase further extended (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: Dear colleagues, The Address Policy WG Co-Chairs decided to extend by four more weeks the Review Phase for policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?. As per the RIPE Policy Development Process (PDP), the purpose of this Review Phase extension is to continue discussing the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. If you support the proposal, please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/draft We encourage you to read the proposal, impact analysis and draft document and to send any comments to?address-policy-wg at ripe.net?before 15 February 2024. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From adavies at ripe.net Thu Jan 18 15:05:23 2024 From: adavies at ripe.net (Alun Davies) Date: Thu, 18 Jan 2024 15:05:23 +0100 Subject: [address-policy-wg] New on RIPE Labs: 10 Years of Legacy Policy Message-ID: Dear colleagues, Ten years after the publication of 'RIPE NCC Services to Legacy Internet Resource Holders', we take a look at what's changed through a decade of implementing the RIPE legacy policy: https://labs.ripe.net/author/xavier/10-years-of-legacy-policy/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC From hank at interall.co.il Wed Jan 24 13:48:46 2024 From: hank at interall.co.il (Hank Nussbacher) Date: Wed, 24 Jan 2024 14:48:46 +0200 Subject: [address-policy-wg] .cz says bye-bye to IPv4 Message-ID: https://konecipv4.cz/en/?is=e583f1196868df2304ff1140184b103346ee70b72851338b99ab8ec03065ae3b Regards, Hank From nick at foobar.org Wed Jan 24 14:06:04 2024 From: nick at foobar.org (Nick Hilliard) Date: Wed, 24 Jan 2024 13:06:04 +0000 Subject: [address-policy-wg] .cz says bye-bye to IPv4 In-Reply-To: References: Message-ID: <9b99d86f-d98b-8920-c17e-32283e77ddd4@foobar.org> Hank Nussbacher wrote on 24/01/2024 12:48: > https://konecipv4.cz/en/?is=e583f1196868df2304ff1140184b103346ee70b72851338b99ab8ec03065ae3b Whatever about the intention, I would question the wisdom of this move. The purpose of the internet is to serve its users, not the other way around. Nick From danny at danysek.cz Wed Jan 24 14:46:51 2024 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 24 Jan 2024 14:46:51 +0100 Subject: [address-policy-wg] .cz says bye-bye to IPv4 In-Reply-To: <9b99d86f-d98b-8920-c17e-32283e77ddd4@foobar.org> References: <9b99d86f-d98b-8920-c17e-32283e77ddd4@foobar.org> Message-ID: <79c3b1e0-2632-4e29-ba10-81832c7aa6d4@danysek.cz> At the government level in Czechia, a regulation was already issued in 2009, which mandated the mandatory deployment of IPv6 on all services by the end of 2010. it was followed by others in 2013, 2015... In 2024, the same government which announces the end of IPv6 in 2032 launches new eGov services that lacks IPv6 support... they simply don't follow that old regulations either. It's only PR. The actions of Czech government do not match their words. - Daniel On 1/24/24 14:06, Nick Hilliard wrote: > Hank Nussbacher wrote on 24/01/2024 12:48: >> https://konecipv4.cz/en/?is=e583f1196868df2304ff1140184b103346ee70b72851338b99ab8ec03065ae3b > > Whatever about the intention, I would question the wisdom of this move. > The purpose of the internet is to serve its users, not the other way > around. > > Nick > > From mschmidt at ripe.net Thu Jan 25 15:54:32 2024 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 25 Jan 2024 15:54:32 +0100 Subject: [address-policy-wg] AS Number Assignments - Transitioning to Policy Compliance Completed In-Reply-To: References: Message-ID: Dear colleagues, In November 2023, I shared with you during the RIPE meeting and on this mailing list that the RIPE NCC intends to assign Autonomous System Numbers (ASNs) from an undifferentiated 32-bit AS Number pool, as defined in the Autonomous System (AS) Number Assignment Policies. I am pleased to inform you that this change has been successfully implemented. The option to choose between a 16-bit or 32-bit AS Number as been removed. When submitting a request, the RIPE NCC will assign the next available AS Number from the undifferentiated allocation pool. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 30/11/2023 16:40, Marco Schmidt wrote: > Dear colleagues, > > During the RIPE 87 Address Policy working group session yesterday, I > presented the topic of AS Number assignments, specifically addressing > a policy in place since 2010. According to this policy, assignments > should be made from an undifferentiated 32-bit AS Number allocation pool. > https://www.ripe.net/publications/docs/ripe-679#ASnumbers > > Before this policy became active in 2010, the Address Policy WG > recognized that many providers were not ready to exclusively work with > 32-bit ASNs, mostly due to technical constraints. A verbal consensus > in 2009 suggested that the RIPE NCC would temporarily continue using > two pools of 16-bit and 32-bit AS Numbers. The plan was to attempt to > extend the global policy by 12 months, but this effort was never > undertaken. To date, the RIPE NCC remains the only Regional Internet > Registry (RIR) employing this temporary approach. > > Observing that other RIRs have successfully issued AS Numbers from an > undifferentiated pool for many years without technical challenges for > operators, the RIPE NCC plans to phase out the current temporary > approach. The intention is to align with the policy and issue AS > Numbers accordingly. > > No objections were raised during the working group session. However, > for transparency, we want to inform working group members who couldn't > attend the RIPE meeting. The presentation can be viewed here: > https://youtu.be/Zoq4PpqlaK4?t=1797 > > Kind regards, > Marco Schmidt > Manager Registration Services > RIPE NCC > From swmike at swm.pp.se Thu Jan 25 16:07:23 2024 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 25 Jan 2024 16:07:23 +0100 (CET) Subject: [address-policy-wg] AS Number Assignments - Transitioning to Policy Compliance Completed In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024, Marco Schmidt wrote: > Dear colleagues, > > In November 2023, I shared with you during the RIPE meeting and on this > mailing list that the RIPE NCC intends to assign Autonomous System Numbers > (ASNs) from an undifferentiated 32-bit AS Number pool, as defined in the > Autonomous System (AS) Number Assignment Policies. > > I am pleased to inform you that this change has been successfully > implemented. The option to choose between a 16-bit or 32-bit AS Number as > been removed. When submitting a request, the RIPE NCC will assign the next > available AS Number from the undifferentiated allocation pool. Hi, could you please elaborate on what this "undifferentiated 32-bit AS Number pool" is? I'm mainly curious if it means we'll deplete 16 bit ASNs (allocate from the lowest available number)? Thanks. -- Mikael Abrahamsson email: swmike at swm.pp.se From mschmidt at ripe.net Fri Jan 26 08:55:52 2024 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 26 Jan 2024 08:55:52 +0100 Subject: [address-policy-wg] AS Number Assignments - Transitioning to Policy Compliance Completed In-Reply-To: References: Message-ID: Hello Mikael and colleagues, Thank you for the question, and I'm happy to provide clarification. At present, we assign the highest available ASN from our undifferentiated pool, but we are planning to adopt a more randomized approach in the future. As a result, there will be no depletion of the lower digit (16-bit) ASNs anytime soon. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 25/01/2024 16:07, Mikael Abrahamsson wrote: > On Thu, 25 Jan 2024, Marco Schmidt wrote: > >> Dear colleagues, >> >> In November 2023, I shared with you during the RIPE meeting and on >> this mailing list that the RIPE NCC intends to assign Autonomous >> System Numbers (ASNs) from an undifferentiated 32-bit AS Number pool, >> as defined in the Autonomous System (AS) Number Assignment Policies. >> >> I am pleased to inform you that this change has been successfully >> implemented. The option to choose between a 16-bit or 32-bit AS >> Number as been removed. When submitting a request, the RIPE NCC will >> assign the next available AS Number from the undifferentiated >> allocation pool. > > Hi, > > could you please elaborate on what this "undifferentiated 32-bit AS > Number pool" is? > > I'm mainly curious if it means we'll deplete 16 bit ASNs (allocate > from the lowest available number)? > > Thanks. >