RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
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... 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
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :) Thanks, Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
On Tue, Dec 15, 2015 at 04:58:20PM +0000, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
I support Tim's plan. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Colleagues, There has been some responses to this and some good discussion. The general response has been positive and while I'm not ignoring Denis' comments, I'm not sure the issues are enough to say we shouldn't do this? I'd like to give a little more time for responses or discussion, I think until the end of Monday 11th January. Thanks, Brian Co-Chair, RIPE AA-WG On 15/12/2015 16:58, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
Thanks,
Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
Afternoon(-ish), As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed. Tim, is the date of the 1st of February still possible for the first mailing on this? Thanks, Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/ Brian Nisbet wrote on 05/01/2016 10:29:
Colleagues,
There has been some responses to this and some good discussion. The general response has been positive and while I'm not ignoring Denis' comments, I'm not sure the issues are enough to say we shouldn't do this?
I'd like to give a little more time for responses or discussion, I think until the end of Monday 11th January.
Thanks,
Brian Co-Chair, RIPE AA-WG
On 15/12/2015 16:58, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
Thanks,
Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
Hi Brian A little late, but I was on holiday :) I agree my comments are a separate issue and should not delay the process of adding any missing abuse-c attributes. I am about to write a separate email about how to use abuse-c as I think we are in danger of losing the plot regarding the original goal of abuse-c. cheers denis On 12/01/2016 15:23, Brian Nisbet wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Thanks,
Brian
Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/
Brian Nisbet wrote on 05/01/2016 10:29:
Colleagues,
There has been some responses to this and some good discussion. The general response has been positive and while I'm not ignoring Denis' comments, I'm not sure the issues are enough to say we shouldn't do this?
I'd like to give a little more time for responses or discussion, I think until the end of Monday 11th January.
Thanks,
Brian Co-Chair, RIPE AA-WG
On 15/12/2015 16:58, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
Thanks,
Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
Hi all,
On 12 Jan 2016, at 15:23, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. Regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Thanks,
Brian
Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/
Brian Nisbet wrote on 05/01/2016 10:29:
Colleagues,
There has been some responses to this and some good discussion. The general response has been positive and while I'm not ignoring Denis' comments, I'm not sure the issues are enough to say we shouldn't do this?
I'd like to give a little more time for responses or discussion, I think until the end of Monday 11th January.
Thanks,
Brian Co-Chair, RIPE AA-WG
On 15/12/2015 16:58, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
Thanks,
Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
Tim, Great stuff, thank you. Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 fax: +35316603666 web: http://www.heanet.ie/ On 14/01/2016 14:57, Tim Bruijnzeels wrote:
Hi all,
On 12 Jan 2016, at 15:23, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later.
Regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
Thanks,
Brian
Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/
Brian Nisbet wrote on 05/01/2016 10:29:
Colleagues,
There has been some responses to this and some good discussion. The general response has been positive and while I'm not ignoring Denis' comments, I'm not sure the issues are enough to say we shouldn't do this?
I'd like to give a little more time for responses or discussion, I think until the end of Monday 11th January.
Thanks,
Brian Co-Chair, RIPE AA-WG
On 15/12/2015 16:58, Brian Nisbet wrote:
I know that we're getting near to what for a lot of people will be a well deserved break at the end of the year, but it would be great if there could be some feedback for the NCC on this, even if it's just agreement! :)
Thanks,
Brian Co-Chair, RIPE AA-WG On 09/12/2015 12:49, Tim Bruijnzeels 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...
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
Tim, On 14/01/2016 14:57, Tim Bruijnzeels wrote:
Hi all,
On 12 Jan 2016, at 15:23, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later.
I was just wondering, would you be able to provide an update on this project? Thanks, Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 fax: +35316603666 web: http://www.heanet.ie/
On 19 Feb 2016, at 10:46, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Tim,
On 14/01/2016 14:57, Tim Bruijnzeels wrote:
Hi all,
On 12 Jan 2016, at 15:23, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later.
I was just wondering, would you be able to provide an update on this project?
Thanks,
Brian
Morning Brian, we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email. Regards Ed Shryane RIPE NCC
On 19/02/2016 09:50, Edward Shryane wrote:
On 19 Feb 2016, at 10:46, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Tim,
On 14/01/2016 14:57, Tim Bruijnzeels wrote:
Hi all,
On 12 Jan 2016, at 15:23, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
Afternoon(-ish),
As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed.
Tim, is the date of the 1st of February still possible for the first mailing on this?
Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later.
I was just wondering, would you be able to provide an update on this project?
Thanks,
Brian
Morning Brian,
we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email.
Thanks for the update! Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 fax: +35316603666 web: http://www.heanet.ie/
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-bounces@ripe.net on behalf of tim@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...
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
Hi Michele,
On 15 Dec 2015, at 21:28, Michele Neylon - Blacknight <michele@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
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface. Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow. You just hit the bell icon, enter your abuse email address and we will create a role object for you. The resulting nic-handle is automatically filled in the abuse-c attribute of the organisation object: https://alexband.nl/temp/abuse-c_creator.png https://alexband.nl/temp/abuse-c_modal.png Hopefully this will encourage users to set an abuse contact. We'll keep track of the usage rate. Kind regards, Alex Band Product Manager RIPE NCC
Hi Alex On 16/12/2015 11:32, Alex Band wrote:
Hi Michele,
On 15 Dec 2015, at 21:28, Michele Neylon - Blacknight <michele@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
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference. cheers denis
You just hit the bell icon, enter your abuse email address and we will create a role object for you. The resulting nic-handle is automatically filled in the abuse-c attribute of the organisation object:
https://alexband.nl/temp/abuse-c_creator.png https://alexband.nl/temp/abuse-c_modal.png
Hopefully this will encourage users to set an abuse contact. We'll keep track of the usage rate.
Kind regards,
Alex Band Product Manager RIPE NCC
On Wed, Dec 16, 2015 at 03:34:26PM +0100, denis wrote: Dear Denis,
On 16/12/2015 11:32, Alex Band wrote:
Hi Michele,
On 15 Dec 2015, at 21:28, Michele Neylon - Blacknight <michele@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
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't prevent the creation of the ORGANISATION object. Moreover, during object creation procedure it is unknown what for the ORGANISATION object is created.
All the best, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi,
On 16 Dec 2015, at 15:48, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Wed, Dec 16, 2015 at 03:34:26PM +0100, denis wrote:
Dear Denis,
On 16/12/2015 11:32, Alex Band wrote:
Hi Michele,
On 15 Dec 2015, at 21:28, Michele Neylon - Blacknight <michele@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
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't prevent the creation of the ORGANISATION object.
If you submit the object in the web interface with an empty value for the abuse-c, it will give you the following error: "Please provide an Abuse-c or remove the attribute if you would like to do it later" So you can explicitly remove the attribute if you want, but we try to guide people into adding the abuse-c because it's a good idea to have it in general (even if it's not strictly required), and we often find that organisation objects are created for sponsored PI or ASN resources without this, and this adds unnecessary overhead to request handling because then we will need to ask for this then.
Moreover, during object creation procedure it is unknown what for the ORGANISATION object is created.
Indeed, we don't know this at creation time. Regards, Tim
All the best, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Tim On 16/12/2015 15:58, Tim Bruijnzeels wrote:
Hi,
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't prevent the creation of the ORGANISATION object.
If you submit the object in the web interface with an empty value for the abuse-c, it will give you the following error: "Please provide an Abuse-c or remove the attribute if you would like to do it later"
So you can explicitly remove the attribute if you want, but we try to guide people into adding the abuse-c because it's a good idea to have it in general (even if it's not strictly required),
Sorry but this is just wrong. The whole design of "abuse-c:" attribute was to use hierarchical inheritance in resource objects. You only put it where it is needed and it is inherited by any more specific objects. It should NOT be duplicated where it is not required. That leads to redundant information being stored in the database. This copy can be forgotten about when the authoritative version referenced from a less specific object is changed and leave invalid data in the database which will override the valid data for some resources. and we often find
that organisation objects are created for sponsored PI or ASN resources without this, and this adds unnecessary overhead to request handling because then we will need to ask for this then.
If you know this is why you are creating this ORGANISATION object then it is reasonable to add an "abuse-c:" at this point. But the wording on your new web form should be clear and suggest adding an "abuse-c:" only IF it is needed.
Moreover, during object creation procedure it is unknown what for the ORGANISATION object is created.
You should not be creating objects in the database if you don't know what their immediate use is for. If you do not currently handle any abuse complaints then you should not include an "abuse-c:" attribute in a newly created ORGANISATION object. This is confusing and redundant information and may override the valid contact data. cheers denis
Indeed, we don't know this at creation time.
Regards,
Tim
All the best, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi all, To clarify, we do not create duplicates or overrides.
On 16 Dec 2015, at 16:54, denis <ripedenis@yahoo.co.uk> wrote:
Hi Tim
On 16/12/2015 15:58, Tim Bruijnzeels wrote:
Hi,
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't prevent the creation of the ORGANISATION object.
If you submit the object in the web interface with an empty value for the abuse-c, it will give you the following error: "Please provide an Abuse-c or remove the attribute if you would like to do it later"
So you can explicitly remove the attribute if you want, but we try to guide people into adding the abuse-c because it's a good idea to have it in general (even if it's not strictly required),
Sorry but this is just wrong. The whole design of "abuse-c:" attribute was to use hierarchical inheritance in resource objects. You only put it where it is needed and it is inherited by any more specific objects. It should NOT be duplicated where it is not required. That leads to redundant information being stored in the database. This copy can be forgotten about when the authoritative version referenced from a less specific object is changed and leave invalid data in the database which will override the valid data for some resources.
We are talking here about adding "abuse-c:" to organisation objects, not resource objects. All inet(6)num and aut-num objects allocated or assigned through the RIPE NCC have an "org:" reference. The referenced organisation must have an "abuse-c:" attribute by policy 2011-06. If an LIR creates more specific inet(6)num objects, the default behaviour is that the "org:" object are blank, and is the abuse-c 'inherited' from the covering object's "org:". But they can optionally refer to another organisation object. In that case it is also appropriate to have an explicit "abuse-c" on that organisation. In rare cases it may be that two different organisations should use the same abuse contact - this can easily be achieved by referring to the same role object from both organisation objects' "abuse-c:". In short the duplication that you refer to is not introduced.
and we often find
that organisation objects are created for sponsored PI or ASN resources without this, and this adds unnecessary overhead to request handling because then we will need to ask for this then.
If you know this is why you are creating this ORGANISATION object then it is reasonable to add an "abuse-c:" at this point. But the wording on your new web form should be clear and suggest adding an "abuse-c:" only IF it is needed.
We are not creating the object. The user is.
Moreover, during object creation procedure it is unknown what for the ORGANISATION object is created.
You should not be creating objects in the database if you don't know what their immediate use is for. If you do not currently handle any abuse complaints then you should not include an "abuse-c:" attribute in a newly created ORGANISATION object. This is confusing and redundant information and may override the valid contact data.
Again, we are not creating objects. The user is. We cannot know the users full intent at the time they create an organisation object. The duplication you refer to does not exist. And having a dedicated contact method for abuse related matters is best practice. The trash icon and error message in case the value is left blank is indication enough that this is strictly speaking optional. Cheers Tim
cheers denis
Indeed, we don't know this at creation time.
Regards,
Tim
All the best, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Tim On 17/12/2015 12:01, Tim Bruijnzeels wrote:
Hi all,
To clarify, we do not create duplicates or overrides.
On 16 Dec 2015, at 16:54, denis <ripedenis@yahoo.co.uk> wrote:
Hi Tim
On 16/12/2015 15:58, Tim Bruijnzeels wrote:
Hi,
To expedite the creation of abuse contacts we've just deployed an enhancement to the RIPE Database web interface.
Whenever you create a new organisation object or you edit an existing one that does not have an abuse contact set, we will display a warning and offer a simple abuse-c creation workflow.
An "abuse-c:" attribute is only required in an ORGANISATION object if it is referenced by a resource object. So the wording in this revised web interface may be a bit confusing to users. It would be better if you do a check on the specified ORGANISATION object and only display this warning if this object should have an "abuse-c:" reference.
From what I understood, warning is not an error and doesn't prevent the creation of the ORGANISATION object.
If you submit the object in the web interface with an empty value for the abuse-c, it will give you the following error: "Please provide an Abuse-c or remove the attribute if you would like to do it later"
So you can explicitly remove the attribute if you want, but we try to guide people into adding the abuse-c because it's a good idea to have it in general (even if it's not strictly required),
Sorry but this is just wrong. The whole design of "abuse-c:" attribute was to use hierarchical inheritance in resource objects. You only put it where it is needed and it is inherited by any more specific objects. It should NOT be duplicated where it is not required. That leads to redundant information being stored in the database. This copy can be forgotten about when the authoritative version referenced from a less specific object is changed and leave invalid data in the database which will override the valid data for some resources.
We are talking here about adding "abuse-c:" to organisation objects, not resource objects.
All inet(6)num and aut-num objects allocated or assigned through the RIPE NCC have an "org:" reference. The referenced organisation must have an "abuse-c:" attribute by policy 2011-06.
If an LIR creates more specific inet(6)num objects, the default behaviour is that the "org:" object are blank, and is the abuse-c 'inherited' from the covering object's "org:". But they can optionally refer to another organisation object. In that case it is also appropriate to have an explicit "abuse-c" on that organisation. In rare cases it may be that two different organisations should use the same abuse contact - this can easily be achieved by referring to the same role object from both organisation objects' "abuse-c:".
In short the duplication that you refer to is not introduced.
You said it yourself below you cannot know why a user is creating an ORGANISATION object. It is quite possible an LIR sub allocates part of an allocation to another company but intends to handle all abuse complaints themselves for their allocation. If you now create an ORGANISATION object for the company holding the sub allocation you tell them they should add an "abuse-c:". Now you are assuming they know they should use the same ROLE object of the LIR and should not change that reference. It is quite likely they will follow your instructions and let you create a new ROLE object for them with their email address. It is far better to encourage users to understand what they are doing and why. If your instructions suggested adding an "abuse-c:" IF required, or even told them to check if they need one, then someone needs to find out if they require it. But to tell them it is missing means they will just follow instructions and add one.
and we often find
that organisation objects are created for sponsored PI or ASN resources without this, and this adds unnecessary overhead to request handling because then we will need to ask for this then.
If you know this is why you are creating this ORGANISATION object then it is reasonable to add an "abuse-c:" at this point. But the wording on your new web form should be clear and suggest adding an "abuse-c:" only IF it is needed.
We are not creating the object. The user is.
That is why your instructions should be clear.
Moreover, during object creation procedure it is unknown what for the ORGANISATION object is created.
You should not be creating objects in the database if you don't know what their immediate use is for. If you do not currently handle any abuse complaints then you should not include an "abuse-c:" attribute in a newly created ORGANISATION object. This is confusing and redundant information and may override the valid contact data.
Again, we are not creating objects. The user is. We cannot know the users full intent at the time they create an organisation object. The duplication you refer to does not exist. And having a dedicated contact method for abuse related matters is best practice. The trash icon and error message in case the value is left blank is indication enough that this is strictly speaking optional.
The "You" did not mean 'you' :) I meant whoever is creating the object. They should know why they are creating it. But since the RIPE NCC doesn't know at this point why they are creating an ORGANISATION object you should not be 'encouraging' them to add an "abuse-c:" at this point. If they do add one of their own and later this is referenced by a sub allocation then you may have overridden the LIRs abuse contact details. My point is simple. People should know what they are doing. An "abuse-c:" attribute should be added where and when needed. Telling people to add it regardless, with the possibility of the wrong data being used if the blindly follow your instructions, is not useful. cheers denis
Cheers Tim
cheers denis
Indeed, we don't know this at creation time.
Regards,
Tim
All the best, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
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-bounces@ripe.net on behalf of michele@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-bounces@ripe.net on behalf of tim@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...
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
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 <tim@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...
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
participants (9)
-
Alex Band -
Brian Nisbet -
denis -
Edward Shryane -
James Gannon -
Michele Neylon - Blacknight -
Piotr Strzyzewski -
Tim Bruijnzeels -
William Sylvester