[db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes

All,

I will discuss this here as I do not accept the Anti-Abuse WG as
a forum for this proposal. For one thing, this proposal affects
every ripedb user - in fact, as this entails changes to how the
NCC provides services, the services-wg would be an even better
venue. For another, given the "population" and culture of
"debate" on the AAWG, any "consensus" reached there would be so
worthless as to be farcical. (If anyone wants amplification on
this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/
provides ample evidence.

To the meat of the proposal:

Firstly, this proposal conflicts somewhat with NWI-7 in this very
WG. (Another reason why it should have gone here in the first
place) With the upcoming possibility of delegating abuse-c: to
(customers') resource objects, who bears any consequences of
these customers not replying to this proposed email? 

>Rationale
>a. Arguments supporting the proposal

>Accurate and validated information in the RIPE Database is
>essential to establish a trusted and transparent environment in
>which all network operators can operate safely.

abuse-c: is a contact object, just as admin-c: or tech-c: and
(correct me if I'm wrong) audited at the same time as the rest of
the contact information. What makes it so unique that this
verification is not enough?

>Accurate and
>validated information helps Internet troubleshooting at all
>levels, 
>but it also helps to attribute malicious online
>activities that undermine this trusted environment.

See above.

>The lack of reliable accurate and validated information in the
>database negatively impacts legitimate uses of the RIPE Database,
>including:

An *email adress* that doesn't reply once a year does NOT equate
to a "lack of reliable accurate and validated information". I
find this statement somewhat insulting to the NCC team who do
make the effort to keep the ripedb data accurate and do audit
resource holders.
There is an issue with the reliability of out-of-region and
legacy resource data but as the NCC has no "enforcement" powers
over these resource holders, in these cases this proposal
snatches at thin air. 

>Assuring the security and reliability of the network by
>identifying points of contact for IP addresses for network
>operators, ISPs, and certified computer incident response teams;

"org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist.

>Ensuring that IP address holders are accountable, so individuals,
>consumers and the public are empowered to resolve abusive
>practices that impact safety and security;
>Assisting businesses, consumer groups, healthcare organisations
>and other organisations that are combating fraud (some of which
>have mandates to electronically save records) to comply with
>relevant legal and public safety safeguards;

The contact object that does (or *should*) stand for the person(s) who
can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role
account in a NOC or even a ticket system unlikely to have any
decision-making power. An attempt to make these roles (perhaps
even personally) responsible for the behaviour of a LIR and its
customers is counter-productive. I for one would flatly refuse to
do any abuse report handling under these circumstances.

>Complying with national, civil and criminal due process laws in
>support of investigations and providing justice for victims.

Would the proposers please amplify exactly which law or due
process is violated by the NCC not sending an email once a year
to an abuse-c:? Myself, and I'm sure the NCC legal team, would be
interested to know.

On a technical note, email is neither a secure nor a reliable
transport for such verification. In the day of blocklists and
large email providers imposing arbitrary restrictions on email
senders it is not guaranteed that a verification email reaches
the intended address or that a reply reaches the sender. The NCC
ARC procedure, however employs both email and personal contact
via telephone to verify the accuracy of the ripedb information.

In toto, this proposal would impose unneccessary work on LIRs and
the NCC, using unsuitable means to rectify a non-existing issue, 
and I therefore oppose it.