Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi again Brian,
* Brian Storey
> I'm conscious you've gone to a great deal of effort to respond back
> to me promptly and I've not come back to you sooner. Sorry to keep
> you waiting for at least an acknowledgement.
>
> Firstly, thank you for taking us through this example. I can see
> yourself and Dennis have developed this converdation further.
>
> Rather than tread on that, I'll perhaps offer a slightly different
> spin on this which is neither in support or against your proposal,
> but in respect to how a LIR is supposed to determine what they should
> or shouldn't do. I'll be honest and say that I'm a relative newcomer
> to this having taken on the adminsitrative responisbility and
> compliance here less than 12 months ago.
>
> Whilst there is a degree of "This is the way" (from an internal &
> external perspective) with what I or anyone else takes on, I did want
> to audit and review as many aspects of what we should be doing as per
> policies, terms and conditions, RIPE DB Training, assumed best
> practice etc.
>
> What is apparent to me is that whilst a policy may describe a "must",
> it isn't nessecarily prescriptive on the "how" and is sufficiently
> narrow leaving how the end result is achieved. Certaintly I don't
> think this how the policies are intended to be written but there are
> some leaps you need to make as to what you should perhaps do or not
> do. A policy alone, in the case of RIPE-733 is a good example of
> this, in particular when you also consider clause 3.0 bullet 4.
>
> I know this isn't a unique problem but:-
> - Within quick succession I had two end business customers
> reach out to us to remove their business name from the description of
> the relevant INET ASSIGNED PA entry. Reasons cited were security.
> Whilst I looked at what we could possibly do, on balance we
> determined that it wasn't an option because of policy, other
> obligations and objectives. To also help support this view, we could
> see other LIRs providing service for the same end business who have
> taken the same approach as us, so at least we are collectively
> consistent!
> - On the other side, there was another new end business
> reaching out asking why the assignment with their details hadn't been
> published yet!
>
> Clearly two competing interests!
>
> Where does this lead me?
>
> Well, clearly we want administrative simplicity. Not only that, a
> clear way to explain internally and externally downstream to end
> customers but also up to RIPE NCC why we do it the way we do.
> Referencing clear policies is important to help justify why we take a
> certain approach and explain any limitations we may have. With the
> proposal you have presented, whilst I understand the rationale of it,
> I'm not quite seeing how without some of the discussion being had
> here, someone can read it and proceed as intended or take our
> explanation / interpretation of our obligations and apply them
> consistently. I recognise the latter part is part of the challenge
> now and a goal to be addressed. The path of least resistance starts
> to become very attractive!
>
> Perhaps I'm going down a rabbit hole with this. Ultimately I'm
> looking to make sure I understand how to remain on the right side of
> things! 😊.
>
> With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes,
> it's something which drew some interest when I first started and the
> different approaches. Feels like there is a bit more subtly to this
> though.
You bring up an interesting debate here. Different LIRs have different
policies when it comes to how much and what kind of information should
be injected into the RIPE database, and as you point out, even end
users might have different expectations here.
The actual requirements of the policy is quite clear though - it is
mandatory to register all assignments, and it is mandatory to register
the end user's contact information (the admin-c and tech-c attributes).
However, often the LIR/ISP itself will assume the admin-c/tech-c role
on behalf of the end user (who might not be very tech-savvy and would
therefore prefer to "outsource" this role to the LIR in this manner),
so it is actually not mandatory to identify the assignee by name.
Additionally, the RIPE database inetnum template makes it mandatory to
include one or more country attributes.
Other than these mandatory minimums, each individual LIR is free to set
its own policies on which additional information to publish, if any.
The sky's the limit here - there are not one, but two free-text
attributes (descr and remarks), so anything goes!
For the record, the full inetnum template can be seen here:
https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true…
Coming back to our 2023-04 proposal, we would like to make it clear
that it does not take a position in this larger debate you bring up.
2023-04 does not take away the ability of any LIR to publish any kind
of optional information they would like to, nor does it relax the
mandatory minimums described above. That is: anything that is currently
OK, will be OK after the implementation of 2023-04 too. No LIR will be
forced to change their current policies to register AGGREGATED-BY-LIR
objects instead of what it is that they are currently doing.
Instead, we recognise the current policy for what it is, and see that
it in some situations requires LIRs to register large numbers of small
and essentially identical objects in the database. We see these as both
pointless and labour-intensive to maintain, so our aim is to provide an
optional mechanism that can ease this work load significantly.
Since the IPv6 policy have for a long time contained a tried'n'true
mechanism that does just that, we believe the easiest way is to copy
that into IPv4.
Tore
1 year, 6 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jeroen Lauwers
Hello Denis,
As proposers, we cannot address your objections against the RIPE NCC’s Impact Analysis, as we had no hand in producing it. However, we will try to address your points below that have not already been discussed at length. See inline:
> Policy is made
> by the community. If the RIPE NCC's interpretation of a policy point
> is not correct then the community can require that the RIPE NCC
> re-evaluates their interpretation.
On this, we agree 100%. The question then becomes: is there someone willing to submit a policy proposal that would require that the RIPE NCC re-evaluate their interpretation? If there is, it would be prudent to put 2023-04 on hold, pending the outcome of that proposal.
If not, that essentially amounts to a tacit acceptance by the community that the RIPE NCC’s interpretation of the current policy is correct, and we can proceed with 2023-04.
> There is a lot in this paragraph. The practice of documenting End User
> contact details in the optional "descr:" attributes is already
> widespread. That is likely because so many LIRs do understand the
> current policy. They have delegated the contact details in the
> mandatory attributes. But they realize the policy requires End User
> contact details so they add those details in other attributes. Given
> that you have put so much emphasis on the 'manual effort required to
> create assignment objects in the RIPE Database' I am sure so many LIRs
> have not entered this optional detail without good reason.
The practice differs greatly between LIRs. Some LIRs create database objects that are rife with optional information not mandated by policy (information about BGP communities, for example), while others prefer to create rather minimal objects that contain only the mandatory attributes.
Your assumption that LIRs that include End User contact information in descr: do so because they believe policy compels them to may well be true for some LIRs, but other LIRs might do so out of their own free will. Neither of us can't know with any degree of certainty which is the most common case; trying to quantify the two groups of LIRs would be pure conjecture.
That said, it is very easy to demonstrate that the «out of their own free will» group of LIRs does exist and is significant in size. You can do that by downloading the inet6num database contents from the FTP and looking at the objects with the status ASSIGNED. You will find that there are *many* objects that contain the End User’s name, address, and other information in descr:
None of that information is there because the LIRs in question have interpreted the policy to require them to publish this information, as the sentence «When an End User has a network using public address space this must be registered separately with the contact details of the End User» does not occur in the IPv6 policy. The LIRs could easily have minimized their assignments, removing all descr: attributes, and/or registered them as part of an AGGREGATED-BY-LIR object. They have chosen not to do so, however.
It seems safe to assume, therefore, that at least some of the LIRs that publish the same data in IPv4 inetnum objects do it voluntarily and not because they believe IPv4 policy compels them to.
> Just as with the IA you have the 'person' mindset lock. Contacts
> should be roles, not people. As suggested in the privacy discussion
> last year, the roles can include optional person names if the people
> so wish. We should all stop using the term 'contact person' and refer
> to 'contact role'
The policy needs to apply to assignments made to large enterprises with a dedicated NOC role, and to tiny one-person businesses whose only contact information is the owner’s personal Gmail address and mobile phone number.
It is not feasible to require LIRs to only make assignments to End Users in the first category. It needs to also take into account End Users in the second category, whose contact person does not consent to the publication of their personal information in the RIPE database.
> You have been very selective here in your interpretation of the stated
> goals of the registry system. Firstly it does not state that
> 'uniqueness' and 'troubleshooting' form an exclusive list of the
> reasons for a public registry. Over the years the registry has evolved
> to the needs of other stakeholder groups. But if you want to take this
> wording literally it also says "The provision of a public registry
> documenting address space allocations and assignments must exist." An
> aggregation does not document assignments.
Note that the IPv6 policy (section 3.3) contains very similar wording: «Internet address space must be registered in a registry database accessible to appropriate members of the Internet community.»
The community has decided that AGGREGATED-BY-LIR is compatible with this goal in the context of IPv6 assignments. Is there something unique about IPv4 assignments that makes «The provision of a public registry documenting address space allocations and assignments must exist» not equally compatible with AGGREGATED-BY-LIR?
Best regards,
Tore and Jeroen
1 year, 3 months
Re: [address-policy-wg] RIPE Code of Conduct and discussion on this list
by Sebastian Graf
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
>
1 year, 2 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Brian Storey
Hi Jeroen & Tore,
There is a subtly here which I don't think is fully appreciated.
I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data because it was deemed that this was a requirement and that not doing so could see a breach of policy, therefore leading to Allocated PAs being reclaimed - not good with scarce resources! They did this because they understood they HAD to not because they WANTED to.
If this school of thought no longer applies, then it is reasonable to expect that some will reevaluate how much effort they continue to put in and the consequences of that.
The two questions I previously posed here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… were:-
"For me it comes down to this. As a community & considering the permitted
exceptions (individuals & P2P assignments):-
1) Is the publication of End User entities for an assignment important?
2) Is the publication of a prefix assignment boundary between end users
important?"
A response agreeing with these questions and reflecting surprise at the policy interpretation is also here (apologies Nick, I missed it at the time):-
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…
Now, I've not commented since (for various reasons), however I have followed the discussion of this closely. Internally, I've been highlighting that a Business Risk item based on previous interpretation could evolve and how we manage our exposure changes if this proposal become policy. What this means in reality is that we can choose how much effort we continue to place on updating our Assignments as the end user customer base churns. There are end customers who like their association to a PA Assignment to be published and there are those who don't. It may well be easier for me only publish by exception. I'm still thinking it through pending what happens next with a few other indirect considerations.
I don't believe I'll be the only one doing this.
Many thanks,
Brian
Brian Storey
IP Network Capacity Planning Manager
Tel: 0333 240 3481
Mobile: 07436 101 378
Email: Brian.Storey(a)gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
-----Original Message-----
From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Tore Anderson
Sent: Monday, April 8, 2024 11:42 AM
To: Carlos Friaças <cfriacas(a)fccn.pt>
Cc: address-policy-wg(a)ripe.net
Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
* Carlos Friaças via address-policy-wg:
> So in order to make it clear for the co-chairs, i do oppose this
> proposal, on the grounds that the quality of publicly available
> registration data is likely to decrease if this proposal is approved.
Hi Carlos,
This concern has been addressed at length in the previous phases of the policy development process, so for the full answer we will refer you back to those discussions. We will however summarise our position briefly below:
We do not believe the registration data will degrade as a result of this proposal. It does in no way encourage or compel LIRs to remove any End User registration data currently found in the database, nor does it stop them from adding more End User registration data in the future. In other words, any LIR that today chooses to publish detailed information about their individual End User assignments is free to continue to do so after this proposal is implemented.
Furthermore, there is no reason to expect that the acceptance of this proposal will entice LIRs to replace detailed individual assignments with aggregated assignments en masse. This has not happened with IPv6, where there are currently over twelve times as many ASSIGNED inet6num objects as there are AGGREGATED-BY-LIR objects. Many of those are rife with optional End User details shared voluntarily by the issuing LIRs.
We see no reason to believe that LIRs will use AGGREGATED-BY-LIR for
IPv4 inetnum objects in a materially different way.
Finally, we would like to point out that the proposal explicitly restricts the scope of AGGREGATED-BY-LIR, by stating that «the purpose and the contact details must be consistent throughout the whole assignment». That means that the End User registration data that can be aggregated must be redundant in the first place.
Best regards,
Jeroen & Tore
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
11 months, 3 weeks
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi Jan,
On 11/01/24 10:19, Jan Ingvoldstad wrote:
>
> On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore(a)fud.no> 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
1 year, 2 months
@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel
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 <tore(a)fud.no>
Sent: 15 January 2024 12:08
To: Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu>
Cc: Šileris, Edvardas <Edvardas.Sileris(a)europol.europa.eu>; 'BAUER-BULST Cathrin' <Cathrin.BAUER-BULST(a)ec.europa.eu>; Azofra Martínez, Álvaro <Alvaro.Azofra-Martinez(a)europol.europa.eu>; Frank Breedijk <f.breedijk(a)divd.nl>; Maria Stafyla <mstafyla(a)ripe.net>; Jeroen Lauwers <jlauwers(a)a2b-internet.com>
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(a)fud.no<mailto:tore@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/0139…
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
1 year, 2 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by denis walker
Colleagues
I wasn't going to say anything else on this issue for now. BUT there
has been so much false and mis-information put out today I cannot
leave that unanswered, as the last word on this topic. Also people
need to understand what this discussion over the last 6 months has
done.
On Mon, 8 Apr 2024 at 14:38, Tore Anderson <tore(a)fud.no> wrote:
>
> * Brian Storey:
> > There is a subtly here which I don't think is fully appreciated.
> >
> > I previously highlighted my surprise to the RIPE NNCs interpretation
> > of the existing policy; as have others. Why is that? I think it's very
> > important to recognise that LIRs act and publish certain End User data
> > because it was deemed that this was a requirement and that not doing
> > so could see a breach of policy, therefore leading to Allocated PAs
> > being reclaimed - not good with scarce resources! They did this
> > because they understood they HAD to not because they WANTED to.
> >
You are right Brian. It IS still a requirement, but as we have
learned, it has not been enforced by the RIPE NCC for about 10 years.
The ONLY way the RIPE NCC could enforce this is the nuclear
option...reclaim address space and close an LIR. Could you imagine the
RIPE NCC doing that to a large and powerful LIR? There would be an
immediate legal challenge and ensuing court case. I have often
commented on the state of RIPE documents. Many of them are poorly
written, have contradictions within them and conflicts between
documents in a linked set. So many things are not defined ANYWHERE.
Many of these documents are open to interpretation. That leads to a
litigation nightmare and is great news for lawyers and barristers who
can spend days in court arguing over the precise meaning of a
document. I would not want to go to court building a defence on this
document set. Obviously, neither does the RIPE NCC, as they have
failed to enforce policy, as mandated, for 10 years. If the RIPE NCC
was to lose the first legal challenge that would set a legal
precedent. At that point you can tear up all RIPE policies. (But maybe
you can do that anyway...read on.)
> > If this school of thought no longer applies, then it is reasonable to
> > expect that some will reevaluate how much effort they continue to put
> > in and the consequences of that.
>
> Hi Brian,
>
> We have certainly no difficulty understanding that you and others might
> have not been aware of this before. But now you are, and so is anyone
> else that are following the RIPE policy development process. The cat is
> out of the bag, so to speak. Withdrawing 2023-04 would not undo this,
> because this is not a property of the proposal itself, but knowledge of
> the of the RIPE NCC's interpretation of the *current* address policy.
>
Tore you are absolutely right, the cat is out of the bag...but which
cat? You seem fine about how the RIPE NCC has been mis-interpreting
policy for 10 years and how they have no power to enforce it other
than the nuclear option, which we all know they will not use. The
revelations from this discussion have completely changed the landscape
for RIPE policy. It has been totally undermined. I agree that
wirdrawing 2023-04 now makes no difference. The damage is already done
and there is no way back. The final decision on 2023-04 is now
irrelevant. When the reality of what has been said really sinks in, it
may be devastating for RIPE policy and the RIPE Database as a public
registry. More on that later...
> Or as the working group chairs put it:
>
> «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.»
This is just unbelievable nonsense. One of the chairs, Leo, knows this
for sure as he was responsible for this. Let's consider the real facts
here. Consider that infamous policy 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."
This exact statement was written into the address policy published in
October 2003. The authors were 4 RIPE NCC staff members. These
included Leo, at the time he was the operations manager of
Registration Services (RS), and Paul Rendek, the senior manager
responsible for RS. This statement was a re-write of rules that had
been in place for many years. Now anyone who has written specs or
regulations knows that, if you change the wording of a rule, you need
to understand what it means so you get the new wording correct. So in
2003 we have the RS manager and senior manager writing the address
policy and really understanding what these rules actually mean. There
was no misunderstanding or misinterpretation then. I will not believe
anyone who tries to tell me now that the manager and senior manager
responsible for RS, having just written the address policy containing
this rule, did not enforce it in 2003. In fact I know from talking to
ex RS staff that it was enforced until runout. So it is about 10 years
since the RIPE NCC decided it no longer had any power to enforce
policy. To say the RIPE NCC interpreted the policy wrongly since the
late 1990s is simply NOT TRUE. This gives a very different view on
when the policy was enforced and when and why it stopped being
enforced.
>
> Furthermore, it is clear that this comes as no surprise at all to many
> LIRs, who have done this for a long time. Again quoting the working
> group chairs:
Many LIRs who have been in violation of policy for a long time, who
know they are in violation. Who will all suddenly become policy
compliant again if this proposal is accepted, and they know that.
>
> «…changing this interpretation would be a major departure of many years
> of accepted practice and potentially involve updating thousands of RIPE
> DB objects»
This practice has never been 'accepted'. It has never even been
discussed in detail until now. The RIPE NCC never came to the
community and said they can no longer enforce the current policy, what
should we do?
>
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/0139…
>
>
> > The two questions I previously posed here:
> > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…
> > were:-
> >
> > "For me it comes down to this. As a community & considering the permitted
> > exceptions (individuals & P2P assignments):-
> >
> > 1) Is the publication of End User entities for an assignment important?
>
> Perhaps, perhaps not. That is for the working group to decide. It is
> however outside the scope of 2023-04. Again quoting the working group
> chairs from the previously linked-to message:
>
> «…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».
To approve a policy now that allows End User details to be deleted,
then consider a proposal that requires End User details to be
published, makes no sense. But then none of this makes any sense.
>
> > Now, I've not commented since (for various reasons), however I have
> > followed the discussion of this closely. Internally, I've been
> > highlighting that a Business Risk item based on previous
> > interpretation could evolve and how we manage our exposure changes if
> > this proposal become policy. What this means in reality is that we can
> > choose how much effort we continue to place on updating our
> > Assignments as the end user customer base churns. There are end
> > customers who like their association to a PA Assignment to be
> > published and there are those who don't. It may well be easier for me
> > only publish by exception. I'm still thinking it through pending what
> > happens next with a few other indirect considerations.
> >
> > I don't believe I'll be the only one doing this.
>
> You and everyone else can do this right now. You do not need to wait for
> the possible acceptance of 2023-04. As mentioned above, you have in fact
> been free to do this «since at leas [sic] the late 1990s».
You are not free to do this now and haven't been for a very long time.
But that hasn't stopped many people from doing it in violation of
policy.
On Mon, 8 Apr 2024 at 15:53, Tore Anderson <tore(a)fud.no> wrote:
> Below you will find an example of a complete inetnum object representing an
> assignment to the End User «CarFactory GmbH» by the LIR «SuperLIR GmbH»,
> which RIPE NCC explicitly confirmed to be compliant with current address
> policy (see
Which we all now know is a misinterpretation of current policy and is wrong.
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…):
>
> inetnum: 192.0.2.0 - 192.0.2.128
> netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ
> country: DE
> admin-c: SUPERLIR-NOC-RIPE
> tech-c: SUPERLIR-NOC-RIPE
> status: ASSIGNED PA
> mnt-by: SUPERLIR-MNT
> source: RIPE
>
> If you, or anyone else, want to "minimise" your assignments as shown in
> the above example, you can do so already today. It is already considered
> accepted practice and has been for decades. 2023-04's fate is totally
> irrelevant as to whether or not you or any other LIR can adopt this
> practice, assuming you want to.
Very few people actually consider this to be 'accepted' practice.
On Mon, 8 Apr 2024 at 10:10, Jeroen Lauwers <jlauwers(a)a2b-internet.com> wrote:
>
> Hi Emmanuel,
>
> > The matter is the loss of opportunities of identification that will vanish for investigators...
>
>
> This is a subject that has been covered extensively during the previous two phases of the policy development process and is as such is already addressed, but we will summarise the main points below for your convenience.
addressed by dismissal
>
> During the previous discussion of 2023-04 it has been made adamantly clear by the RIPE NCC that any information inserted into the RIPE database that identifies the End User is inserted voluntarily by the LIR. There exists no policy requirement that compels LIRs to publish the identities of their End Users, this is simply an option that some LIRs avail themselves of.
Totally untrue. Totally false.
Most LIRs actually do understand the current policy. They are aware
that the policy requires an assignment to include contact details of
the End User organisation. In many cases that is taken to mean the
email address referenced via the "admin-c:" attribute. Where the LIR
handles the tech issues for the End User it has become common practice
to replace both the tech-c and admin-c with the LIR's contact details.
When this is done, many LIRs then add the End User name and address
into the optional "descr:" attributes. Just because this is an
optional attribute does not mean the data it contains is optional.
Name and address is one format for contact details. If the LIR has
replaced the tech-c and admin-c in the assignment with their own
details, they remain policy compliant by adding the required End User
contact details (name and address) in the optional descr attributes. I
am sure most LIRs do not do this extra administration because they
enjoy the extra workload of voluntarily providing additional
information that is not required by policy.
>
> It is important to realize that the policy proposed by 2023-04 does not in any way whatsoever restrict or prohibit LIRs from voluntarily publishing the identities of their End Users in the RIPE database. LIRs that have a policy to do so today, will be able to continue to do so in the future in the exact same way after 2023-04 is implemented. Indeed, these LIRs are free to ignore 2023-04 completely – 2023-04 does not deprecate or remove the ASSIGNED PA inetnum status, it may still be used as before.
It DOES remove the policy requirement to provide a contact with the
End User in ALL cases. So even a small LIR has no fear of being in
violation of address policy and the NCC using the nuclear option on
them. NO ONE will be required to provide ANY contact with the End User
within the RIPE Database.
>
> It follows logically that 2023-04 does not cause any loss of End User identification. Investigators may continue to look up IP addresses in the RIPE database, but whether or not it will yield the End User's identity (as opposed to «a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR», as the working group chairs put it) will depend entirely on the issuing LIR's policies and procedures, just as it does under today.
NO NO NO
2023-04 allows for the complete removal of any End User contact
details whether there is an assignment object or not. You are
specifically removing the infamous line that requires a way to contact
the End User. This is a policy violation today, which some LIRs ignore
with impunity.
>
> For a demonstration of this taking place in practice, take a look at the IPv6 part of the RIPE database. The AGGREGATED-BY-LIR status has been available for inet6num objects since forever, but this has not prevented LIRs from to registering their End User assignments using the ASSIGNED status instead, often including the End User's identity, contact information, and other optional details. There is no reason to expect that this will be any different in IPv4 following the implementation of 2023-04, as we see it.
>
Conclusion
Now let's conclude with the more serious aspects of what has happened
in the last 6 months. The co-chairs of the Address Policy Working
Group have declared that address policy is optional. LIRs can choose
if they want to comply with it or they don't want to comply with it.
The chairs said:
"Those LIRs that want to share data are already doing so. Those who
would like to share some data if it were easier to do so will be
accommodated if this proposal becomes policy."
This basically sums up everything regarding policy. ['want' 'like'].
If you don't want, don't like, just don't do. The chairs seem to be
fine with this. The RIPE NCC has shown by it's actions over the last
10 years that it will not use the nuclear option for a policy
violation and they have no other power. So we have shown to LIRs that
they can now do whatever they like with impunity.
The proposers have made lots of references to IPv6 "allocated-by-lir:"
and "assigned:". They talk about how well things work in the IPv6
world. Maybe that is all about to change. If the NCC has no power to
enforce policy then, according to the chairs it is optional. Why is
IPv6 policy any different? If you have a /29 IPv6 block, maybe you
won't need any more for a few years, if ever. Or you can always rent a
block from one of the brokers who have huge stockpiles. So the NCC
still has no power over you. Why bother to register those /48s as
required by policy. Policy is optional, the chairs said. Those LIRs
that enter optional details about the End User in an IPv6 assignment
may simply follow the same process as they do for IPv4. Maybe using
the same script to generate the object. If they change this for IPv4
they may make the same change for IPv6 as well. As many people say,
they want to handle IPv4 and IPv6 the same way.
LIRs may now be looking at all that has been said during this
discussion and thinking how they can use this information to reduce
their workload and costs. Many LIRs also say they don't want to
publish any details of their customers in a public database. They have
only done so in the past because they correctly believed it was a
policy requirement. Now they know it is either no longer a requirement
or not enforceable, why would they do it? Things will probably not
change overnight. But gradually these objects, this data will
disappear. It makes no difference now if 2023-04 is approved or not.
ALL LIRs now know this policy requirement is not enforceable. No
action will be taken against them if they stop entering End User
details or even start removing it.
This is the cat you have let out of the bag. This is the change to the
policy landscape you have made and you cannot go back. Another aspect
is how to change policy. If LIRs decide to ignore some other aspect of
policy, they again know there is no action that can be taken against
them. Over time people will say this is now accepted behaviour. Then
it will be normalised by changing the policy to match the behaviour.
So who is in control now? The 'community' can make any policy it
likes. The LIRs can choose to ignore it because the chairs say it is
optional. The RIPE NCC has no power to do anything. Certainly not
against the bigger LIRs. The operator community that has driven this
proposal through, for their convenience, has shown an indifferent and
uncompromising attitude to anyone outside of their group. I am sure
this has not gone unnoticed. Civil society (ie voters) and law
enforcement have far more influence over politicians than this
operator community has. EU politicians are not averse to making
regulations in this area. Don't be surprised if they write regulations
specifying what a public registry of Internet number resources should
look like (Nis3?). After all, we don't have our own specification. An
industry that has an impact on the lives of just about everyone on the
planet, is critical to government, industry, commerce and society, can
only expect to be self regulating if it is willing to cooperate and
compromise with other groups in society. If you want to live in your
own little bubble, do everything your way as you have for the last 20
years, don't be surprised when change comes and is enforced on you.
cheers
denis
========================================================
DISCLAIMER
Everything I said above is my personal, professional opinion. It is
what I believe to be honest and true to the best of my knowledge. No
one in this industry pays me anything. I have nothing to gain or lose
by any decision. I push for what I believe is for the good of the
Internet, in some small way. Nothing I say is ever intended to be
offensive or a personal attack. Even if I strongly disagree with you
or question your motives. Politicians question each other's motives
all the time. RIPE discussion is often as much about politics and self
interest as it is technical. I have a style of writing that some may
not be familiar with, others sometimes use it against me. I also have
OCD. It makes me see the world slightly differently to others. It
drives my mind's obsessive need for detail. I can not change the way I
express my detailed opinions. People may choose how to interpret them.
========================================================
11 months, 3 weeks
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Hi Tore and others
On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> 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://lists.ripe.net/mailman/listinfo/address-policy-wg
1 year, 2 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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#impac…
"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 <tore(a)fud.no> 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@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-pers…
>
> «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(a)privacy.example, which is a valid email address that is automatically forwarded to e.g. tore+ripe-example(a)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://lists.ripe.net/mailman/listinfo/address-policy-wg
1 year, 2 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara
Dear Denis,
If the proposal 2023-04 is accepted, this would not cause any change in
the way we conduct our audits and evaluate the registration of PA
assignments.
In IPv4, the mandatory contact information for PA assignments is
provided by the “admin-c:” and “tech-c:” attributes; these must allow
the RIPE NCC and other RIPE Database users to contact the End User
regarding technical or administrative issues. The contacts are
registered by the LIR as agreed with the End User.
As 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 is in line with the Database Term and Conditions statement in
“Article 6 - Responsibilities”:
“The Maintainer is responsible for keeping all data maintained by them
accurate and up-to-date, including correct Contact Details. The data
must be good enough to allow the RIPE NCC to contact the Maintainer or
Registrant within a reasonable time without having to get information
from another source.”
Following the discussion in the Database WG the “descr:” attribute
became optional for all object types in 2016. Since then, the RIPE NCC
stopped enforcing the registration of the End User’s organisation name.
LIRs still have the option to add this information in the “descr:
attribute, by adding it to the “remarks:” attribute or in the “org:”
attribute (provided they created an organisation object).
This is reflected in the tutorial and training currently provided by the
RIPE NCC: https://www.youtube.com/watch?v=w6oUf7j4SME.
PA assignments are not maintained by the RIPE NCC. They are very dynamic
elements of the resource registration in the RIPE Database, and we do
not receive any notification about their creation, updates and deletions.
Additionally, the RIPE NCC is not in the position to confirm that the
"admin-c:" contact is registered following the guidelines of the RIPE
Database documentation (which is not a RIPE policy) where it is written
that the “admin-c:” “must be physically located at the site of the
network” or “must be the contact details of an on-site administrative
contact”.
I see that this topic is in the agenda of the APWG session at RIPE 87
and I’m looking forward to follow this interesting discussion.
Kind regards,
Angela
Angela Dall'Ara
Policy Officer
RIPE NCC
On 23/11/2023 07:17, denis walker wrote:
> Colleagues
>
> I am so disappointed by this second version of the proposal and the
> impact analysis.
>
> Let's start with the changes to the proposal. The addition of
> 'Arguments opposing the proposal'. This is completely false and
> misleading information. This summary of the arguments during the
> discussion phase is just unbelievably wrong. No one even made the
> argument that you cannot currently create an object with the mandatory
> contacts delegated to another party. In regard to these mandatory
> contacts I proved that the admin-c must be a contact from the End
> User's enterprise. This is based on the definition of admin-c and the
> clearly expressed, current version of the address policy. In
> particular that well quoted 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." Very clear, not subject to
> interpretation and non negotiable under the current policy and all
> versions of the policy going back over the last 20 years.
>
> In the PDP policy it says "At the end of each phase of the process,
> one of the chairs of the relevant WG will summarise the state of
> discussion on the WG mailing list." This still has not been done.
>
> Then we have this crazy 'counter argument'. Let's break it down.
>
> "It is already possible to create such assignments under the current
> address policy."
> No one has disputed that.
>
> "The RIPE NCC confirmed that they consider these assignments to be
> policy compliant and do not require them to be modified during
> audits."
> During my detailed arguments I proved that this interpretation by the
> RIPE NCC of the current IPv4 address policy, and all the versions over
> the last 20 years, is incorrect. According to the now famous 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 the historic, but still valid, definition of the admin-c, it is
> clear that the admin-c must be someone from the End User enterprise.
> Therefore delegating this to another party is a violation of the
> policy. Many LIRs who create assignment objects in the RIPE Database
> have understood the current and previous address policy. Even though
> they sometimes delegate the admin-c they compensate by adding the name
> and address of the End User in the optional descr attributes. This is
> not strictly compliant but does adhere to the principle of the policy.
> This proposal drops this principle.
>
> Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE
> NCC staff being more involved in RIPE community affairs, no one from
> the RIPE NCC has joined this discussion to explain the NCC's
> interpretation of the current and previous address policy.
>
> "Therefore, the proposed policy change simply leaves the status quo unchanged."
> This is straight out of the Donald Trump fake news instruction manual.
> When you say something that is not true, keep repeating it, over and
> over and over again. Never acknowledge anyone who questions it, never
> discuss any arguments raised against it, just keep repeating it. Over
> time some people will start to believe it.
>
> I have argued in GREAT detail exactly what this proposal does. By
> dropping that famous 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." the proposers fundamentally change address
> policy and the nature of the public registry. I have presented 'walls
> of text' to explain this, which most people probably have not read.
> This change allows ALL End Users to be totally anonymised. Even those
> who technically manage their own network and handle their own abuse
> complaints, they can still be anonymised and have public contact
> details available. For LIRs who do not want to put any details of
> their customers into the public registry, this change allows for this
> complete anonymity. And there are many LIRs who already follow this
> philosophy, despite current policy. This change will reduce the RIPE
> Database public number registry to the same useless level as a domain
> name registry. ALL details of End Users can be hidden behind a court
> order firewall.
>
> Following the Trump instruction manual, the proposers still refuse to
> acknowledge that this proposal changes anything. They still refuse to
> engage with the community in a real discussion on this point. They
> still keep repeating the fake news.
>
> It also says in the PDP policy "In all phases of the RIPE PDP,
> suggestions for changes to the proposal and objections regarding the
> proposal must be justified with supporting arguments and then
> addressed adequately by the proposer or by any supporter of the
> proposal." The proposers will not even acknowledge my objections, will
> not discuss them and therefore have not adequately addressed them.
>
> Then we move on to the impact analysis (IA). This reads as an 'Impact
> on the RIPE NCC Analysis'. There is no mention at all of the impact on
> stakeholders who use the data contained within the RIPE Database. In
> the PDP policy it does say the IA will contain 'Impact on the
> registry'. This is interpretable. I would suggest this covers the
> public registry as well as the RIPE NCC's internal registry databases.
> But this IA does not even mention the fundamental change to address
> policy and the potential consequences to the data contained within the
> public registry or the impact that may have on various stakeholder
> groups using the RIPE Database. It follows the same line as the
> proposers by failing to even acknowledge the severity of the change
> this proposal has on the public registry.
>
> From the Legal Impact section, "the RIPE NCC would like to note that
> it is solely the responsibility of the member to choose which contact
> details to insert in the INETNUM object." Also from the 'RIPE NCC's
> Understanding' it says "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." This is also not true. The policy is very
> clear. "When an End User has a network using public address space this
> must be registered separately with the contact details of the End
> User." So the current policy dictates to the LIR the type of the
> contact details they must enter. Even though the individual contact
> within that type is their choice.
>
> So with the arguments from the discussion phase having not been
> summarised and the objections not having even been acknowledged by the
> proposers, and certainly not addressed by them, I still don't see how
> this proposal can move to the review phase.
>
> cheers
> denis
>
> On Tue, 21 Nov 2023 at 11:13, Angela Dall'Ara <adallara(a)ripe.net> wrote:
>>
>> Dear colleagues,
>>
>> Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA
>> assignments”, is now in the Review Phase.
>>
>> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status
>> for IPv4 PA assignments to reduce LIR efforts in registration and
>> maintenance.
>>
>> This proposal has been updated and it is now at version 2.0. The
>> proposed policy text did not change, the only difference is that the
>> section "Arguments opposing the proposal" includes a reference to the
>> last round of discussion.
>>
>> The RIPE NCC has prepared an impact analysis on this proposal to support
>> the community’s discussion.
>>
>> 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
>>
>> As per the RIPE Policy Development Process (PDP), the purpose of this
>> four-week Review Phase is to continue the discussion of 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.
>>
>> We encourage you to read the proposal, impact analysis and draft
>> document and to send any comments to address-policy-wg(a)ripe.net before
>> 20 December 2023.
>>
>> Kind regards,
>> Angela Dall'Ara
>> Policy Officer
>> RIPE NCC
>>
>> --
>>
>> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
1 year, 4 months