<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi again Jan,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 09/01/24 13:38, Jan Ingvoldstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It is important to also consider the cases where the End
Users are <br>
organisations that do not have non-PII role addresses.<br>
<br>
Consider for example a small one-person business, let's say
a farm owned <br>
by «Farmer Fred». This End User would be a company, not an
individual, <br>
yet the company is often given the same name as the person
owning it (at <br>
least here in Norway).<br>
<br>
The e-mail address might well be farmer.fred@gmail and the
phone number <br>
might be the Farmer Fred's personal mobile. This would mean
that both <br>
the name and the contact information for this End User *is*
PII and is <br>
in scope of the GDPR.<br>
</blockquote>
<div><br>
</div>
<div>The current interpretation of this part of the GDPR is
that "Farmer Fred" is permissible to publish.</div>
</div>
</div>
</blockquote>
<p>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.»</p>
<p><a class="moz-txt-link-freetext" href="https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en">https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en</a><br>
</p>
<p>«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:</p>
<p>«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.»</p>
<p><a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis">https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis</a></p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Therefore, if Farmer Fred exercises his rights under the
GDPR to object <br>
against / not give consent to the publishing of his PII in
the RIPE DB, <br>
you (the LIR) have a problem. Proceeding to publish this
contact <br>
information over Farmer Fred's objections opens you up to
legal risk <br>
(not to mention souring the relationship with your
customer).<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>Similarly, that requirement must be there for *any*
contact object, not just End Users.<br>
</div>
<div><br>
</div>
<div>You cannot know if the LIR's phone numbers are personal
or not, or can you?<br>
</div>
</div>
</div>
</blockquote>
<p>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).</p>
<p>(That said, LIRs' contact information is also subject to the RIPE
Database Terms and Conditions.)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Precisely. The LIR, like a domain name registrar, can simply
serve as a <br>
proxy between the wider Internet community and its End
Users.</blockquote>
<div><br>
</div>
<div>No, that is not what I wrote.</div>
<div><br>
</div>
<div>This is about an automatic email forwarding scheme, not
about a registration by proxy scheme.</div>
<div><br>
</div>
<div>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.
<a class="moz-txt-link-abbreviated" href="mailto:qaobuaidbvsas@privacy.example">qaobuaidbvsas@privacy.example</a>, which is a valid email
address that is automatically forwarded to e.g. <a
href="mailto:tore%2Bripe-example@fud.no" target="_blank"
moz-do-not-send="true">tore+ripe-example@fud.no</a>.</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p> <br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This voids <br>
any policy requirement to (possibly illegally) publish
Farmer Fred's PII <br>
in the RIPE DB. As stated in the Impact Analysis, the RIPE
NCC is of the <br>
opinion that this (already widespread) practice is permitted
by current <br>
policy, and will continue to be permitted after 2023-04 is
implemented. <br>
In other words, just like in the registrar business, this is
an already <br>
solved problem, which will continue to be solved after
2023-04 is <br>
implemented. It is in this respect that we say that 2023-04
will not <br>
bring about any change – it ain't broken, and we're not
fixing it.<br>
<br>
The claim that has been made is that *current* policy does
not allow <br>
LIRs to serve as proxies in this manner, and that the RIPE
NCC has not <br>
been implementing current policy correctly by allowing it.
It is further <br>
claimed that 2023-04 will bring about an (undesired) change
in that it <br>
will allow LIRs to serve as proxies. However, for the
reasons already <br>
discussed we are of the opinion the premise this argument
rests on is <br>
incorrect, hence we do not believe 2023-04 will effect any
change.<br>
<br>
We hope this clarifies the clarification. :-)<br>
</blockquote>
<div><br>
</div>
<div>
<div>I was kindof trying to avoid that argument again.</div>
<div><br>
</div>
<div>But sure, as you bring it up again.</div>
<div><br>
</div>
<div>This opinion is obviously a logical impossibility.<br>
</div>
<div><br>
</div>
<div>There is no way that you can change something and at
the same way legitimately claim that the change is not a
change.</div>
<div><br>
</div>
<div>If it is true that the current practice is both
widespread and accepted, then *no change is necessary*.</div>
<div><br>
</div>
<div>If a change is necessary, it is logically because there
is a widespread and accepted practice of publishing End
Users' contact information.<br>
</div>
<div><br>
</div>
</div>
</div>
<div>The argument is therefore nonsensical, sorry.</div>
</div>
</blockquote>
<p>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:</p>
<p>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.</p>
<p>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.</p>
<p>In short: 1) is an intentional and desired change from today,
while 2) is *not* a change from today – intentionally so.</p>
<p>So maybe we could discuss 1) instead of 2) going forward? :-)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div>You have not actually addressed this concern and objection,
you have merely restated claims and opinions that do not
actually do so.</div>
<div><br>
</div>
<div>I therefore again urge you to resubmit the proposal
*without* this removal.</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEffzkxRTt-4akM4rhMNPdZYfT0oByGStCa9K09uY9F7M_+wBA@mail.gmail.com">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p><br>
</p>
<p>Tore & Jeroen<br>
</p>
</body>
</html>