Decision on Proposal 2017-02 & Next Steps
Colleagues, We've been thinking about this for some time and attempting to find a way through the various comments and messages in regards to 2017-02. We believe the best option at this point is to extend the review phase of this proposal for a further 4 weeks as we do not believe rough consensus has been reached. However we also do not believe that there has been sufficient clear argument to reject the proposal. We think that during this time it would be useful if those who engaged in the discussion but did not express a preference could do so. It would also be useful if those who commented on the first version of the proposal, especially those who objected, still objected after the second version was published. It should also be noted that the NCC have laid out the method by which they would plan to implement this proposal, so we do not believe that discussion around alternative methods nor additional checks is germane. It is also clear that the ARC will be used in conjunction with the automated checks. It is also clear that this will not require "make work" from any admins to answer. Finally we need to address the objections around the possible implications of organisations *not* following this policy. It is clear that 2017-02 does not attempt to introduce any additional processes nor change how the NCC would act in cases where policies are not followed. We believe this has been clarified. If members of the community have an issue with these procedures then we think that's a separate discussion, rather than a valid reason to object to 2017-02 Other than those listed above, there was a feeling expressed that this will not make any meaningful difference. Both the RIPE NCC and the proposers have said that this work to improve the quality of data will be greatly appreciated. We would also mention that policies can be further amended in the future. So, if everyone could take a look at the latest version of 2017-02 again that would be appreciated. If you have already stated your support there is no need to do so. If you are opposed, then please consider the above and the various discussions and see if you are still opposed to this version of the proposal. If so, can you please state which reasons for opposition have not been clarified nor resolved. Obviously if you haven't stated a preference either way, as I mention above, this is your opportunity to do so! Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270
On 12/03/2018 12:57, Brian Nisbet wrote:
Finally we need to address the objections around the possible implications of organisations *not* following this policy. It is clear that 2017-02 does not attempt to introduce any additional processes nor change how the NCC would act in cases where policies are not followed.
I think that's slightly misleading. If we have an existing rule that non-compliance with RIPE policies can result in withdrawal of resources, then while it is strictly that "this does not change how the NCC would act in cases where policies are not followed", by adding a new policy that must be followed we're still broadening the range of circumstances in which resources can be withdrawn. So I think it is a legitimate objection to this policy proposal to say "If this policy is adopted, resources can be withdrawn merely for failure to maintain this field, and I think that's a disproportionate outcome". I think it's also worth noting that the provision of the rules that non-compliance leads to withdrawal of resources is not something of long standing, proven appropriate by the passage of time: it was only brought in at the GM at the end of last year. Before then, while we did have another version of that rule, it wouldn't have interacted with this policy in the same way. So it is appropriate to be careful about not creating unforeseen interactions. Personally, I do think that it would be disproportionate. If I were convinced compliance with this policy would have a significant impact on the problem, it would be a more difficult call; as it is, the risk/reward balance seems quite unfavourable. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
If 2017-02 is adopted, following sentence will be added to ripe-563: "The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures." In term of RIPE NCC powers, nothing more is added than "current RIPE NCC procedures are in force" Hervé -----Message d'origine----- De : anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Malcolm Hutty Envoyé : lundi 12 mars 2018 11:08 À : anti-abuse-wg@ripe.net Objet : Re: [anti-abuse-wg] Decision on Proposal 2017-02 & Next Steps On 12/03/2018 12:57, Brian Nisbet wrote:
Finally we need to address the objections around the possible
implications of organisations *not* following this policy. It is clear
that 2017-02 does not attempt to introduce any additional processes
nor change how the NCC would act in cases where policies are not
followed.
I think that's slightly misleading. If we have an existing rule that non-compliance with RIPE policies can result in withdrawal of resources, then while it is strictly that "this does not change how the NCC would act in cases where policies are not followed", by adding a new policy that must be followed we're still broadening the range of circumstances in which resources can be withdrawn. So I think it is a legitimate objection to this policy proposal to say "If this policy is adopted, resources can be withdrawn merely for failure to maintain this field, and I think that's a disproportionate outcome". I think it's also worth noting that the provision of the rules that non-compliance leads to withdrawal of resources is not something of long standing, proven appropriate by the passage of time: it was only brought in at the GM at the end of last year. Before then, while we did have another version of that rule, it wouldn't have interacted with this policy in the same way. So it is appropriate to be careful about not creating unforeseen interactions. Personally, I do think that it would be disproportionate. If I were convinced compliance with this policy would have a significant impact on the problem, it would be a more difficult call; as it is, the risk/reward balance seems quite unfavourable. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Dear colleagues, Please allow me to provide some clarification in regards to "relevant RIPE Policies and RIPE NCC procedures" for this proposal, and some details around how these have changed over time. Since 2003, the RIPE IPv4 policy has stated that the RIPE NCC can close LIRs for reasons such as policy violations and unresponsiveness. This wording has not changed in the past 15 years (section 12.0): https://www.ripe.net/publications/docs/ripe-288/at_download/pdf The RIPE Policy "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" contains similar requirements for independent number resources since its creation in February 2009 (section 2.0): https://www.ripe.net/publications/docs/ripe-452 Within this policy framework, the RIPE NCC developed the procedural document: "Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources". The relevant section of this document for members, "1.2.1.1 Violation of RIPE Policies and RIPE NCC Procedures", has been active since March 2011. Over the past seven years, mostly editorial changes have been made to the wording of this section: https://www.ripe.net/publications/docs/ripe-517#a1211 The most recent change to this procedure, in February 2018, was not directly related to the proposed policy change. It was primarily around suspension of the membership (i.e. voting rights) once the closure procedure has been activated. The following link shows the differences between the current document and the previous version. It shows that no significant changes were made to section 1.2.1.1: https://www.ripe.net/publications/docs/ripe-676/@@diff-items?id=ripe-697#a12... As outlined in the impact analysis, the RIPE NCC has been investigating reports of invalid abuse contacts under the current policy framework for several years now. The only difference made by the policy proposal is that it would cause us to proactively undertake this validation rather than waiting for reports. Until today, all of the abuse contact cases we investigated were resolved without ever needing to trigger the closure and deregistration procedure. However, making unresponsive resource holders aware of the possibility of closure as a final resort has helped to ensure their cooperation. Please let me reiterate that the RIPE NCC will not activate the closure procedure simply for failure to maintain the "abuse-mailbox:" attribute. The closure procedure could be activated if the resource holder refuses to provide correct abuse contact information or is unresponsive over a longer period (during which the RIPE NCC will have made several attemps to contact the resource holder via different channels). If the closure and deregistration procedure is triggered, the resource holder will still have an additional three months to resolve the problem. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
On 14/03/2018 13:32, Marco Schmidt wrote:
Please let me reiterate that the RIPE NCC will not activate the closure procedure simply for failure to maintain the "abuse-mailbox:" attribute.
The closure procedure could be activated if the resource holder refuses to provide correct abuse contact information or is unresponsive over a longer period (during which the RIPE NCC will have made several attemps to contact the resource holder via different channels).
Marco, Thank you for your detailed mail. However I do not understand how the two sentences quoted above are consistent with each other. Is it that you won't activate the closure procedure *solely* for failure to maintain abuse-mailbox, but might activate it if this was compounded with some other breach? How would you feel if the policy was amended to say something along the lines of "For the pupose of RIPE-676 paragraph 1.6.2.1.1 (Violation of RIPE Policys and RIPE NCC Procedures), failure to maintain the abuse-mailbox attribute shall not be deemed sufficient reason to terminate the SSA in itself, but may be deemed an aggravating factor contributing towards a decision to terminate the SSA." Kind Regards, Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
Dear Malcolm, On 2018-03-14 14:47:13 CET, Malcolm Hutty wrote:
On 14/03/2018 13:32, Marco Schmidt wrote:
Please let me reiterate that the RIPE NCC will not activate the closure procedure simply for failure to maintain the "abuse-mailbox:" attribute.
The closure procedure could be activated if the resource holder refuses to provide correct abuse contact information or is unresponsive over a longer period (during which the RIPE NCC will have made several attemps to contact the resource holder via different channels).
Marco,
Thank you for your detailed mail. However I do not understand how the two sentences quoted above are consistent with each other. Is it that you won't activate the closure procedure *solely* for failure to maintain abuse-mailbox, but might activate it if this was compounded with some other breach?
How would you feel if the policy was amended to say something along the lines of
"For the pupose of RIPE-676 paragraph 1.6.2.1.1 (Violation of RIPE Policys and RIPE NCC Procedures), failure to maintain the abuse-mailbox attribute shall not be deemed sufficient reason to terminate the SSA in itself, but may be deemed an aggravating factor contributing towards a decision to terminate the SSA."
I see how those two lines can be confusing when taken together - thank you for asking us to clarify. If this policy change reaches consensus, the RIPE NCC will proactively validate whether the "abuse-mailbox:" attribute is valid. If our automated validation indicates that the attribute is technically incorrect, we will contact the resource holder (directly or indirectly via the sponsoring LIR) and ask them to review and correct the "abuse-mailbox:" attribute. This is still outside of the closure and deregistration procedure. It would be the following actions of the resource holder that could lead to us activating the closure procedure - such as refusing to provide correct abuse contact information or remaining unresponsive over a longer period. This is already our current procedure when investigating incorrect contact information and this would not change if the policy change reaches consensus. Regarding potential amendments, it would be up to the Anti-Abuse Working Group to decide if these are worthwhile. But I am happy to provide the RIPE NCC's understanding based on the current version of the policy proposal as well as clarification on the current RIPE policy framework. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC
Kind Regards,
Malcolm.
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/
London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
On Mon, Mar 12, 2018 at 12:57:33PM +0000, Brian Nisbet wrote:
Finally we need to address the objections around the possible implications of organisations *not* following this policy. It is clear that 2017-02 does not attempt to introduce any additional processes nor change how the NCC would act in cases where policies are not followed. We believe this has been clarified. If members of the community have an issue with these procedures then we think that's a separate discussion, rather than a valid reason to object to 2017-02
I disagree with this statement on several points: 1) 2017-02 *does* introduce an additional process, namely that to validate an email address. 2) We only have the statement of the RIPE NCC as to how they intend to implement this process. Once the proposal is approved, this is out of the hands of this community. The NCC can make any changes they wish by simple board decision, they can make it harder, easier, whatever and as long as the contractual rights of a member aren't touched, nobody will be able to exert any influence on this (at least by democratic means). 3) There is no forum for a "separate discussion". Thus, 2017-02 does not stand on its own, the implementation of it is part and parcel of the issue it tries to address and this makes the implementation of it a, if not *the* valid reason to object, or indeed support, it. rgds, Sascha Luck
Dear Brian, colleagues! I would like to remind about one of my objections: This policy will not seriously improve data quality, because it allows to check only one field in database. If one wants really to improve data quality by automated checks, more complicated policy should be developed. Also, may i suggest to run "the method by which they(NCC) would plan to implement this proposal" once, to display current situation with abuse-c in database? Kind regards, Alexander Isavnin Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Alexander, Thanks for this. I'd just like to clarify something, are you objecting wholly to this proposal because you would prefer stronger/more complex checks? In that you feel it doesn't go far enough? Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270
-----Original Message----- From: anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Alexander Isavnin Sent: 27 March 2018 13:46 To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Decision on Proposal 2017-02
Dear Brian, colleagues!
I would like to remind about one of my objections: This policy will not seriously improve data quality, because it allows to check only one field in database. If one wants really to improve data quality by automated checks, more complicated policy should be developed.
Also, may i suggest to run "the method by which they(NCC) would plan to implement this proposal" once, to display current situation with abuse-c in database?
Kind regards, Alexander Isavnin
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Thanks for question, i really forgot to add important clarification paragraph for objection. On 2018-03-27 14:50:13 CET, Brian Nisbet wrote:
Alexander,
Thanks for this.
I'd just like to clarify something, are you objecting wholly to this proposal because you would prefer stronger/more complex checks? In that you feel it doesn't go far enough? I'm objecting wholly to this proposal, because i doesnt' significantly improve data quality of the whole registry and doesn't help to prevent serious abuse. And being IT guy (and sometimes executive) i do not like implementing something, "just because we can". (and i had arguments, that valid abuse-c won't help against really malicious abuse)
If we need such kind of policy, than it should be full scale Automated Registry Checks (probably with all contacts, validity of routing, validity of resource assigments, responsiveness of contacts, etc..) - in a way, which will guarantee some measurable level on quality. (NCC Database SLA) But now, i prefer current situation, with trust to LIRs and light assisted checks. Years ago, talking first time to Rob Blokzijl i'v asked him: "Why information in database is not being checked fully, with all phone numbers/emails checks, submitting confirming papers for each assignment etc, like any activities done in Russia?". He responded something like "It's not in tradition". And i value such traditions. I would like for us to stay in Western European tradition, rather than moving to Police State tradition. But if community decides to move - the move should be done with good and complete approach. Hope you'll get me right. Kind regards, Alexander Isavnin Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Ok, thank you Alexander, I now feel I better understand your objection. Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270
-----Original Message----- From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> On Behalf Of Alexander Isavnin Sent: Tuesday 27 March 2018 14:39 To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Decision on Proposal 2017-02
Thanks for question, i really forgot to add important clarification paragraph for objection.
On 2018-03-27 14:50:13 CET, Brian Nisbet wrote:
Alexander,
Thanks for this.
I'd just like to clarify something, are you objecting wholly to this proposal because you would prefer stronger/more complex checks? In that you feel it doesn't go far enough? I'm objecting wholly to this proposal, because i doesnt' significantly improve data quality of the whole registry and doesn't help to prevent serious abuse. And being IT guy (and sometimes executive) i do not like implementing something, "just because we can". (and i had arguments, that valid abuse-c won't help against really malicious abuse)
If we need such kind of policy, than it should be full scale Automated Registry Checks (probably with all contacts, validity of routing, validity of resource assigments, responsiveness of contacts, etc..) - in a way, which will guarantee some measurable level on quality. (NCC Database SLA)
But now, i prefer current situation, with trust to LIRs and light assisted checks.
Years ago, talking first time to Rob Blokzijl i'v asked him: "Why information in database is not being checked fully, with all phone numbers/emails checks, submitting confirming papers for each assignment etc, like any activities done in Russia?". He responded something like "It's not in tradition". And i value such traditions. I would like for us to stay in Western European tradition, rather than moving to Police State tradition. But if community decides to move - the move should be done with good and complete approach.
Hope you'll get me right.
Kind regards, Alexander Isavnin
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
participants (6)
-
Alexander Isavnin -
Brian Nisbet -
herve.clement＠orange.com -
Malcolm Hutty -
Marco Schmidt -
Sascha Luck [ml]