Hi everyone,
On 4/16/19 05:18, ripedenis--- via address-policy-wg wrote:
Colleagues
Someone has kindly referred me to the conversation you had last
November on this same paragraph 6.2. It's not surprising that there is
some reluctance to discuss it again. BUT this is a different
discussion. Last time you focussed on defining what type of network
needs to be separately registered in the RIPE Database. I want to
discuss the next step from that. Once you have decided a type of
network needs to be separately registered then what information about
that network needs to be entered into the RIPE Database?
Denis, I believe that the first e-mail sent by you was inviting the
community to start a conversation. Furthermore, I believe that NOW is
the right time to have this discussion and clarify what is required by
policy (and maybe look at updating those policies as well) and put it in
writing in a new privacy policy.
While GDPR is already in effect, the RIPE Database contains millions of
contact details of private persons. Some ISPs currently use the RIPE DB
as their customer database and register every single assignment they
make to organisations or people. I doubt any of the people used by the
ISPs as admin-c or tech-c in assignments actually know that their
private data is made public in the RIPE DB. Lastly, and this can be
fixed easily if we all ask for it, the RIPE NCC is creating every month
hundreds of objects that contain personal details with the registration
of new LIRs. The current state requires an update of policies and
processes and can not continue like this much longer.
I doubt that everyone that has a person object (containing personal
details - phone, e-mail, address, etc) in the RIPE Database even knows
about their personal data being public. I also doubt that every person
that registers a new LIR knows that their personal details will be
published in the RIPE Database and made publicly available. There are
several million person objects in the RIPE Database that (I believe)
should have been deleted once GDPR kicked-in _or_ all of those persons
should have been asked to confirm that they accept to have their private
information made public in the RIPE Database.
To quote Peter Hessler "I am *not* happy for that data to be published
widely on the internet, so I have censored them on purpose" - this is
one way to hide personal details, many other companies/people have
chosen to censor or provide less than accurate details.
Jan Ingvoldstad wants to see a better usable abuse contact information.
This is one of the details that we are asking for. We are trying to make
a list of contact information you all would like to see registered in
the RIPE Database for resource holders and the questions in Denis'
initial e-mail were supposed to start and steer the conversation into
finding exactly those details - to then clarify and define where that
information should be stored (role object, org object, maintainer, etc)
Michiel Klaver had an interesting idea "Maybe make more use of the
'role'-objects? Within organisations people come and go, while their
departments responsible for network operations and abuse keep rolling.
Listing a department as role and using a shared e-mail address would
reduce the ever increase of new person-objects in the database." and I
believe that the use of the role objects should trump the use of the
person object.
I personally believe that we should remove the person object from the
RIPE Database and use roles/organizations/maintainers/etc instead.
I will come straight to the point, which should be controversial
enough to start a discussion :) MY interpretation of the wording in
6.2 is that the policy, as written, requires an ORGANISATION object to
be created for these End Users if you register their network in the
RIPE Database.
Let me explain my reasoning for this interpretation. The policy refers
to the End User as either an individual or an organisation. In other
words the End User is the '(legal) entity' that operates the network.
Just as the LIR is the (legal) entity that holds the allocation
resource. So when the policy requires the contact details of the End
User, it is requiring the contact details of this operating entity.
That is not the "xxx-c" attributes in the INETNUM object, it is an
ORGANISATION object details.
I believe that first we need to decide what kind of data must be
published in the RIPE Database and then decide in which objects to store
that data - be it an organisation object, admin-c/tech-c/abuse-c, or a
role object.
Once this is clear, we can amend current policies or propose a privacy
policy and reference it in the other policies.
This takes us back to the long running discussion we had with
"abuse-c:" where many members refused to create separate ORGANISATION
objects for End Users just to add an "abuse-c:" for them. But as it is
currently written, this is exactly what this policy requires. Perhaps
the wording of this paragraph 6.2 doesn't reflect the original intent.
So what we must now do is look again at this situation and answer 3
basic questions about these End Users:
1/ What information do we need/want to store about the End User?
I'll bite and provide my answers:
- we should not store names of people - people come and go and usually
there is one person within a department that creates the objects &
requests the resources and then those objects are inherited for many
years. I believe that roles/department names should be used. RIPE NCC
has always recommended the use of role objects for
admin-c/tech-c/abuse-c. I am not sure when the RIPE NCC changed their
procedures and forms to include registration and publication of personal
data with the registration of every new LIR but I believe they should
revert and create role objects instead.
- I think we should have an e-mail address and a phone number - none of
these should be personal details but the org's contact details instead.
- physical address will come with a lot of questions: should this be the
legal or the mailing address of the org, of their tech dept, of their
outsourced tech dept in an other country, of their lawyer/legal dept, etc...
- fax - who is still using fax, will you even think you will need a fax
sent to a holder of internet resources?
- what else is there? social media contacts? maybe links to forms? how
complicated do we want this to be?
2/ What is the reason for storing this information?
great question. The only reasons I can find are:
- someone is breaking my network (hijacks, ddos, peering issues, etc)
and I want to be able to swiftly contact them and ask them to stop
- someone is sending abuse to my network/customers/contacts and I want
them to stop
- an LEA wants to be able to track the user of a resource swiftly and,
when they need to issue a subpoena, they need to know the country where
it should be sent and the right address
- the RIPE NCC already knows who is authorized to discuss confidential
information, the name should not be public though unless the user really
wants to and opts-in for his personal data to be in the RIPE DB.
There may be other reasons as well, we'll have to wait for other people
to provide their feedback before we can collect it all and do something
with it (make a policy proposal).
3/ Who needs this information?
I think I already answered this question by answering Q2... it would be
a network operator, someone receiving abuse, an LEA or the RIR. In cases
of (independent) assignments, it may be the LIR as well.
If we can answer these basic questions then perhaps the policy needs
to be updated.
either update the IPv4/IPv6/ASN policies or propose a privacy policy and
reference it in the other policies as needed. I believe the second
option is better.
cheers
denis
co-chair DB-WG
cheers,
elvis
On Monday, 15 April 2019, 16:18:33 CEST, ripedenis--- via
address-policy-wg <[email protected]> wrote:
6.2 Network Infrastructure and End User Networks
When an End User has a network using public address space this must be
registered separately with the contact details of the End User. Where
the End User is an individual rather than an organisation, the contact
information of the service provider may be substituted for the End Users.
