I’ll add my +1 here, it seems like a well reasoned proposal. James
On 15/12/2015, 8:28 p.m., "anti-abuse-wg on behalf of Michele Neylon - Blacknight" <anti-abuse-wg-boun...@ripe.net on behalf of mich...@blacknight.com> wrote: >Tim > >I support this plan > >It makes a lot of sense on two fronts: >1 - making sure there are abuse-c contacts for all resources >2 - making sure that it’s the correct / appropriate contact > >Regards > >Michele > >-- >Mr Michele Neylon >Blacknight Solutions >Hosting, Colocation & Domains >http://www.blacknight.host/ >http://blog.blacknight.com/ >http://ceo.hosting/ >Intl. +353 (0) 59 9183072 >Direct Dial: +353 (0)59 9183090 >------------------------------- >Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty >Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > > > > > >On 09/12/2015, 12:49, "anti-abuse-wg on behalf of Tim Bruijnzeels" ><anti-abuse-wg-boun...@ripe.net on behalf of t...@ripe.net> wrote: > >>Dear working groups, >> >>As you know all organisations that have internet number resources allocated >>or assigned by the RIPE NCC need to have an abuse-c attribute according to >>policy 2011-06. The following implementation plan was communicated for this >>policy: >> >>https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 >> >>Phase 1 of this plan was completed in December 2013, setting up abuse-c for >>then existing LIRs. Phase 2 of this plan was completed for organisations >>holding sponsored PI resources in November 2014. However, since then LIRs and >>end-users have been responsible for ensuring that an abuse-c exists for their >>organisation. In practice it has proven difficult to enforce this, since >>abuse-c is not a mandatory attribute in the RIPE DB schema, and as a result >>new cases where organisations do not have an abuse contact have been created. >> >>There is an important change in the implementation we would like to do – >>based on our experiences thus far – which would like the community's mandate >>on. We propose to use the end-user organisation's email address instead of >>the sponsoring LIR email address. We believe there are valid reasons for this >>change, but of course if this suggested change is controversial we would >>encourage discussing it in the anti-abuse working group. Ideally, we need to >>have a decision on this by early January so that we can prepare the work. >> >> >>1) Prevent NEW cases >> >>We want to ensure that no new cases will be created as follows: >> >>= Since 1 March, the new member application form already provides much better >>integration with the RIPE Database >> - because of this an abuse contact is now created whenever a new LIR is >> activated >> - it can be modified the LIR, e.g. using web-updates, but not removed >> >>= We are currently adapting the new create organisation webupdates form to >>include abuse-c by default allowing the user to: >> - reference an existing abuse-c role object, or >> - enter an email address to create an abuse-c role for the organisation >> (using the same maintainer) >> >>= We are also adapting the edit organisation webupdates form to always >>suggest adding an abuse-c contact if it's not present >> >>= We plan to extend the new request forms: >> - check that an end-user organisation has abuse-c before it can be used >> - if not, refer to the edit form for the organisation where it will be easy >> to add reference an existing abuse contact, or create a new object >> >>2) Resolve remaining EXISTING cases >> >>Originally the idea for phase 2 was to use the sponsoring LIR's email address >>in case the end-user organisation was unresponsive to requests to set their >>own abuse contact. However, since then policy 2012-08 has been implemented >>and nowadays the sponsoring LIR, and its abuse contact, can be found through >>the sponsoring-org attribute. >> >>Also, the RIPE NCC found that using the sponsoring organisation's email >>address leads to a number of issues: >> >>- end-users have no incentive to set their own abuse-c, rather then letting >>abuse questions go to their sponsor, so the majority remains unresponsive >>- in case an end-user has resources from more than one sponsor it is >>ambiguous which sponsor's email should be used >>- many LIRs were unpleasantly surprised by finding their email address in the >>abuse-c of the organisation they sponsor >>- in case LIRs no longer wish to sponsor resources, or when they are >>returned, existing references to their email in the end-user abuse-c are not >>cleaned up >> >>We would therefore like to propose a change to the implementation plan when >>addressing the remaining cases. Today, in case no abuse contact is set, users >>of the database will resort to using the organisation's default email. >>Therefore, adding a dedicated abuse-c role object using this email address, >>doesn't cause any noticeable new effects on organisations. It may well be the >>correct email address to use for an organisation, and no action would be >>required. However, it *enables* an organisation to use a different email >>address for abuse questions if appropriate. >> >>We would like to email remaining LIRs, and end-user organisations and >>sponsoring LIRs on Monday 1 February, giving them until Monday 15 February to >>set their abuse contact. We realise that this means we would have another >>delay, but we believe that it would be unwise to do this change over the end >>of year holiday period, and to ensure that we can give proper support to >>questions we want to avoid doing this at the same time as the start of the >>year invoicing. >> >>Please let us know what you think. >> >>Kind regards, >> >>Tim Bruijnzeels >>Assistant Manager Software Engineering >>RIPE NCC Database Group >> >> >>
