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 > > >
