Tim, I support your proposal and applaud the efforts to improve this process and improve the overall data within the database. What if anything is being done to make sure that valid emails are being entered? I assume we are doing a check to make sure the email has an ‘@‘ and maybe even some validation that there’s a . and some TLD or ccTLD. But I assume we are not checking through a method like double opt-in or other confirmation method to see that the email exists and the user creating the entries is able to receive that email. Which seems to be a fairly standard method today to valid emails. Has any thought been put into this?
Are we deciding as a community any email is better than no email? I know I continue to find records where I reach out to an abuse contact (or other contacts) and many of them bounce or are stale. Any thoughts on this? Thanks, Billy > On Dec 9, 2015, at 7:49 AM, Tim Bruijnzeels <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 > > >
