New subject: [db-wg] objection to RIPE policy proposal 2016-01

28 Feb 2016

      Dear colleagues,

I object to passing the policy as proposed.
There is no serious need for the policy,
and at this time and under curent circumstance it would
actually be harmful.
I believe that the supposed good intentions would be better
served by other actions, and the policy focussing on enforcement
is ill advised.

I understand that the current implementation of the RIPE database allows
legacy holders to enter abuse-c attributes for their legacy resources
if that's currently not possible the required extension of the database
should be discussed (in the approprioate wg) and implementation would NOT
require the PDP (as more drastic changes have been done to the database
- and that extension hardly would contradict existing policy).
No PDP is needed to send friendly invitations to legacy holders to populate
their data objects with abuse-c information;
I'm sure asking the RIPE NCC to do this would not create an undue burden
or serious problem.

Enhancing the invitations with some additional information potentially
helpful to the recipients could be considered too:
- some hints/guidance about expected use and support of that mailbox
  (active members of the abuse handling community probably will NOT be the
  typical recipient! and no injuries are expected if any community member sees
  that information:-)
- specific suggestions what to put into the abuse-c field
  (whatever the RIPE NCC might use to extrapolate abuse-c from existing data)
The working group should contribute helpful information to be included.

I'm quite certain running a second invitation campaign would be even less
of a problem and effort for RIPE NCC; I cannot predict how much the information
provided in a later campaign can be improved based on feedback and experience
from an earlier one.

You may argue, that such more friendly approach could have been used also
earlier - and I would very much agree and I certainly complained and
suggested that at least the forced population of missing abuse-c should
be postponed until friendly information was made available.

Now we do NOT HAVE TO repeat past errors...
Specifically with legacy resource holders it would be a good idea 
for RIPE community and NCC to address them with an inviting and
helpful approach; as there is a sad history of seemingly coercive
and unfriendly communications towards legacy holders.

REPEATING the error now - even considering the much lower number of
relevant records - is however actually MORE SERIOUS in DAMAGING
the CREDIBILITY of the working group (and as a consequence the RIPE NCCs
position) because of the accumulated history.
Repeated requests for information on supposed use und handling of abuse-c
has been answered by pointing out that it is required by a policy
that was consciously created without any such information.
The new policy proposal painfully fits into the sad observation that
the anti-abuse working group as a community has constantly
put effort into enforcing creation and population of abuse-c data
but not (even tried) to provide to the rest of the world helpful
explanations on requirements and expected handling at the requested mailboxes.
That observations leads to the question whether the community is not able to
come up with some helpful explanation or whether it does not care... :-(
In both cases asking for enforcement does seem neither appropriate
nor acceptable and means that the request cannot be taken serious
- bad for the perception of RIPE and RIPE NCC activety by parties
that are not heavily involved in the community processes.
Consider the typical person confronted with a request to define abuse-c:
how deeply is he involved with the anti-abuse working group
(where a common understanding might exist - I consider myself only occassional
observer and not a member and don't know)?

Trying to close more quickly and on a more constructive perspective
let me skip to elaborate here on my judgement:
at close inspection the rationale and arguments look quite broken.

The policy content does actually not matter that much - look for a sketch of
a potential harmless implementation approach above in this message.
What matters is appropriate use of the PDP (it can be abused!!!)
and what are good goals of the working group and good ways of achieving them.

The assumed good goals (as I understand it) are
(a) improving quality of abuse-c information in order to
(b) improve abuse reporting and report handling processes and
(c) extending the abuse-c coverage for Internet number resources
    in the RIPE NCC registry

The policy proposal references (a) and (b) quite explicitly;
I took the liberty to interpolate (b) which actually seems to be the
primary goal, and it looks like the working group decided that this will
be helped by means of creating distinctly identified mailbox information
to be put into abuse-c.
The criterium for gauging (a) seems to be whether "improved data" actually 
helps "improve processing" (b) - what else?
Creating abuse-c entries of better/good quality obviously depends on the
recipient being appropriate and informed about expected potential messages
and preparing to deal with them.
Forcing creation of abuse-c in any other way is not going to create
better quality but actually looses information (you loose track of
which entries have the "quality of informed and [potentially]
prepared recipient").

We have to assume that Internet number resource holders requested
to establish abuse-c
- usually are NOT focussed an abuse handling (different core business:-)
- in many cases are not members of the anti-abuse working
  (and unlikely to have insight into undocumented potential consensus views
  of the working group or the larger abuse-c activist community)
- in general willing to cooperate
  (we really should care for those and help them!
  ... yes, there are others - from "don't care" to "evil")

For making a reasoned decision about the recipient for abuse-c and preparing
for handling messages one obviously needs some understanding/explanation
of what is expected.
If no such helpful information is offered at the time of requesting abuse-c
setup, many well intentioned parties will *something* (not really good
"quality") to fill required fields and little motivation to followup
will remain.
If they care to ask for helpful information and the answer stays "this is
required by policy, and it consciously declines to explain", they are likely
to conclude that they have to submit to RIPE policies and the policy
makers+process that cannot be taken serious...

I note that for goal (b) of course some common understanding of expected use 
and handling for the abuse-c mailbox is a prerequisite on BOTH sides
(senders also!)

I do not expect to see formal, precise, and exhaustive definition of 
requirements and intended/expected use of abuse-c use - that would seem
fairly impossible and certainly would not provide a practical answer
to the issue.
The working group needs to followup it previous abuse-c policy
by starting to create practically useful explanations, before considering
more "enforcement" (actually IMHO all enforcement activety should
[have] be[en] postponed - potentially replaced by friendly invitations).
It may take considerable effort to develope consensus on such
documentation - but is it reasonable to rely on all relevant outside parties
to have the first contact figure out completely on his own and explain
to his management, consultants, service providers, etc... what needs to be
done? (what aggregated cost and what "quality" implications do you expect?)

It's ok to have working groups that just have internal fun between some 
birds of a feather. If a working group feels like making demands 
(e.g. policies) to a larger community it should also consider what
support it needs to provide to serve the purposes of that larger community.

Thanks for your attention and consideration.
  Ruediger Volk

P.S.: Sorry, for a painfully long message.
Trust me I had more painful time writing - and making it shorter
would have been worse - with termination not secure:-)

I hope that the painful length does not obscure
- valid concern
- constructive suggestions

objection to RIPE policy proposal 2016-01

Ruediger Volk

Sascha Luck [ml]

andre＠ox.co.za

andre＠ox.co.za

andre＠ox.co.za

Jeffrey Race

andre＠ox.co.za

andre＠ox.co.za

andre＠ox.co.za

Sascha Luck [ml]

andre＠ox.co.za

Sascha Luck [ml]

Sascha Luck [ml]

andre＠ox.co.za

andre＠ox.co.za

andre＠ox.co.za

David Hofstee

tags

participants (13)