[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Dear Tore/Denis:

If we are looking at the Policy Language, then i'm not certain we are 
reading the same things into it.
Or maybe i missed something. Feel free to point out the corresponding 
section of the policy to me. I'm more than happy to update my views if 
strong evidence is presented.
As a small LIR ... I may not see all edge cases.... but...... So feel 
free to point out anything important that i may have missed.

Lets look at the actual language in the policy:

 > "All assignments and allocations must be registered in the RIPE 
Database. This is necessary to ensure uniqueness and to support network 
operations."

The way i read it, this point is filled both with the current state of 
things, and also if we have an aggregated status. Space would still be 
registered. So the question is what kind of data needs to accompany it.

So lets look at what needs to be documented:

 > "Registration data (range, contact information, status etc.) must be 
correct at all times (i.e. they have to be maintained)."

I think you are arguing what both of you are considering "contact 
information". It does NOT say we state to put personally identifyable 
information into it.

If we read the text literally, then only putting enough information to 
establish a contact (ie: contact information) would theoretically be 
sufficient.
So theoretically, a "proxy" type of setup for email/postal mail/... 
could be permissiable as long as any communication/... is forwarded to 
the the actual responisble party.

In fact i would argue for most businesses (End-User or ISP) this is 
already the case if they make use of "role" contacts for their 
admin/noc/abuse/... handling.

 > "Registration data (range, contact information, status etc.) must be 
correct at all times (i.e. they have to be maintained)."

The other thing that i do not read from the statement is where it asks 
to put "contact information" for the End-User. It simply reads contact 
information (one could theoretically interpret this as "contact 
information for the party that is responsible for managing the space....).

ANYWAY....

I still do not feel anything of significance would be lost, if something 
could be lost at all. My personal opinion goes the other way.....I 
suspect, if anything aggregated status could potentially lead to more 
accurate data. Let me explain: With the aggregation we gain better 
understanding of the network usage. PLUS the ability to create more 
specific assignments (under the aggregated). So This way, i feel more 
usable data would be int the database, compared to now.

This would also be in line with the goals in Section 3.0 - Point 2 
"Agregation: Distributing IPv4 addresses in an hierarchical manner 
permits the aggregation of routing information.".

If we look at the goal for registration: "Registration: The provision of 
a public registry documenting address space allocations and assignments 
must exist. This is necessary to ensure uniqueness and to provide 
information for Internet troubleshooting at all levels.".

If we consider the usefulnes of data entered into the ripe-db for this 
purpose, then most useful will be the ISP contact information. Contact 
information for End-Users (could be an ISP as well) would also be useful 
in some cases. Personal Information for "individual" type end users (ie: 
Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a 
lesser extend.

If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a 
*duty of confidentiality to their registrants*. Information passed to an 
IR must be securely stored and *must not be distributed wider than 
necessary within the IR*.".

So i am not certain why you are trying to force more data than actually 
required/useful into the db. And yes in this context i would consider 
LIR's in this to be part of this as some type of "local" IR's.

During the writing of this email, i realised that you (denis/tore) may 
consider the need/usecase for adding a "restricted" flag into the DB, 
that would allow adding information, that is only shown to a select 
audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could 
be used to publish PII data. HOWEVER doing something like that would 
"extend" the existing usecase(s) of the DB and dataentry required - as 
such this should be in a different Policy Proposal/wg-discussion. Feel 
free to put one forward, that we can discuss....

Regards

Sebastian


On 1/11/24 13:11, Tore Anderson wrote:
> Hi Jan,
>
> On 11/01/24 10:19, Jan Ingvoldstad wrote:
>>
>> On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20240111/2ce1d7f2/attachment.html>