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

Hi Jan,

On 11/01/24 10:19, Jan Ingvoldstad wrote:

On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore@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