[anti-abuse-wg] objection to RIPE policy proposal 2016-01

And to add (fire) to that fine article:

Everyone has abuse issues, sooner or later. Not having an abuse-c means you don't want to fix it*. 


Met vriendelijke groet,


David Hofstee

Security Management
MailPlus B.V. Netherlands

* Thus this leaves no room for the 'I was here first'-ideology or 'I am too big to handle all that abuse'-ideology.

-----Oorspronkelijk bericht-----
Van: anti-abuse-wg [mailto:anti-abuse-wg-bounces at ripe.net] Namens denis
Verzonden: dinsdag 1 maart 2016 01:17
Aan: Ruediger Volk; anti-abuse-wg at ripe.net
CC: db-wg at ripe.net
Onderwerp: Re: [anti-abuse-wg] objection to RIPE policy proposal 2016-01

Hi Ruediger

I have to say this was a very long winded way to say, as a legacy resource holder, you don't want to handle abuse complaints.

Which planet have you been living on for the last 20 years (since you got your legacy resources)? RIPE/RIPE NCC have tried so many times over these years to encourage people to do things voluntarily. The caring professionals with a social responsibility will always do the right thing whether it is voluntary or enforced. As for the rest, some will go to any length to avoid doing the right thing (for their own reasons) and the others will not find time to do anything until you threaten them with enforcement. The latter are spending their time running genuine businesses and trying to make profits (which is why you run a business) and just need the enforcement kick to make them prioritise some action.

I am sure some people will be offended by what I am about to say, although it is not my intention to be offensive, but I am going to do a Donald Trump and say what many others are too scared to say. There is nothing special about legacy resources or legacy resource holders. They are IP addresses just like all the others. You just got in early and got massive amounts of address space that is now (stupidly) worth a fortune. 
 From a moral, ethical and community point of view there should be no difference in the way either is treated.

Abuse can come from any IP address. In general 'abuse' does not care about the nature of the address space. But it is useful if the address space is private and the public has no way to contact the holder or user. I am very suspicious of anyone who wants to keep legacy space outside the scope of sensible and responsible IP address management. 
What do you have to hide?

The whole purpose of abuse-c was to provide one standardised method of documenting abuse contacts for ALL address space. If you insist on keeping some address space 'special' and separate from the rest and not engage in responsible management then the whole system breaks down.

Your argument about legacy resource holders not understanding anything about abuse-c is just crazy talk. Are these people so out of touch they have never heard of google? If they know what an IP address is and what to do with it (besides sell it) then they know how to find out about abuse-c. If you google for 'abuse-c' the first 4 hits are RIPE NCC documentation on 'abuse-c'.

The fact that you are going to such lengths to oppose this policy implies to me that you don't want to set up an abuse contact for your legacy address space. That is the reason this policy is needed and enforcement is the only way forward.

cheers
denis


On 28/02/2016 19:38, Ruediger Volk wrote:
> 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
>