Morning,
What we’re discussing right now is the policy as proposed and the NCC’s implementation plan. We’ve had discussion at an earlier point in regards to additional methods of verification, however it was made clear that there would be marked opposition to things that required human interaction in this way.
With this in mind we are proceeding on this basis. Obviously if you would like to propose an alternative, then the WG Co-Chairs and the RIPE Policy Development Office are very happy to assist you with this.
Thanks,
Brian
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(a)heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270
From: anti-abuse-wg <anti-abuse-wg-bounces(a)ripe.net> On Behalf Of Name
Sent: Thursday 15 March 2018 00:40
To: Marco Schmidt <mschmidt(a)ripe.net>; anti-abuse-wg(a)ripe.net
Subject: Re: [anti-abuse-wg] Decision on Proposal 2017-02
"If this policy change reaches consensus, the RIPE NCC will proactively
validate whether the "abuse-mailbox:" attribute is valid."
No it doesn't. How does RIPE loading a system that checks whether a mail server exists even need a change to policy? There is nothing listed in this "policy" that even needs to be implemented as policy.
From what is said, RIPE will not check whether an abuse mailbox is valid, but whether a mail server exists at a domain specified.
Mail server exists ≠ valid abuse mailbox attribute
-------- Original Message --------
Subject: Re: [anti-abuse-wg] Decision on Proposal 2017-02
From: Marco Schmidt <mschmidt(a)ripe.net<mailto:mschmidt@ripe.net>>
Date: Thu, March 15, 2018 2:02 am
To: anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net>
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
And apologies for the subject change, which I meant to edit. We’ve a new email system in work which needs training.
Brian
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(a)heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270
From: Brian Nisbet
Sent: Wednesday 14 March 2018 11:31
To: 'Name' <phishing(a)storey.xxx>; anti-abuse-wg(a)ripe.net
Subject: RE: SPAM-heanet-- RE: [anti-abuse-wg] Decision on Proposal 2017-02 & Next Steps
Hi,
I haven’t given an exhaustive list of all of the emails sent, but they are all in the archive. I believe I have covered some of the main points below. While I don’t feel a number of them are valid, as discussed, they were stated as initial reasons for objection.
Given my statements below I now wish people to either clarify their reasons for objection or say they no longer object or something in between.
We’ll then review this at the end of the current phase.
Thanks,
Brian
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(a)heanet.ie<mailto:brian.nisbet@heanet.ie> www.heanet.ie<http://www.heanet.ie>
Registered in Ireland, No. 275301. CRA No. 20036270
From: Name <phishing(a)storey.xxx<mailto:phishing@storey.xxx>>
Sent: Tuesday 13 March 2018 01:28
To: Brian Nisbet <brian.nisbet(a)heanet.ie<mailto:brian.nisbet@heanet.ie>>; anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net>
Subject: SPAM-heanet-- RE: [anti-abuse-wg] Decision on Proposal 2017-02 & Next Steps
"we do not believe rough consensus has been reached."
Who spoke out against it, and what did they say? I haven't seen anything that says that consensus has not been reached.
What does "consensus" look like?
-------- Original Message --------
Subject: [anti-abuse-wg] Decision on Proposal 2017-02 & Next Steps
From: Brian Nisbet <brian.nisbet(a)heanet.ie<mailto:brian.nisbet@heanet.ie>>
Date: Mon, March 12, 2018 11:57 pm
To: "anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net>" <anti-abuse-wg(a)ripe.net<mailto:anti-abuse-wg@ripe.net>>
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(a)heanet.ie<mailto:brian.nisbet@heanet.ie> www.heanet.ie<http://www.heanet.ie>
Registered in Ireland, No. 275301. CRA No. 20036270
