[anti-abuse-wg] anti-abuse-wg Digest, Vol 51, Issue 2

Gentlemen,

Brian Nisbet said
> ...given the lack of further responses..."
> without "disagreements"
> "...with the general feeling of consensus"

You're a joker! That is better than standup comedy. All my complains were 
blocked.

(The RIPE community has an Anti-Abuse Working Group that discusses topics 
relating to Internet abuse and the participation in RIPE Working Groups is 
open to all) All my complains were relating to internet abuse - with 
evidence.

The solution being finalized is proof of the uselessness of this anti-abuse 
working group.

The market is ripe for sc(p)ammers and RIPE is not ripe, is rotten. And the 
population will continue to be raped.

My condolences
Marilson


-----Mensagem Original----- 
From: anti-abuse-wg-request at ripe.net
Sent: Wednesday, January 13, 2016 9:00 AM
To: anti-abuse-wg at ripe.net
Subject: anti-abuse-wg Digest, Vol 51, Issue 2

Send anti-abuse-wg mailing list submissions to
anti-abuse-wg at ripe.net

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ripe.net/mailman/listinfo/anti-abuse-wg
or, via email, send a message with subject or body 'help' to
anti-abuse-wg-request at ripe.net

You can reach the person managing the list at
anti-abuse-wg-owner at ripe.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of anti-abuse-wg digest..."


Today's Topics:

   1. Re: RIPE NCC to set abuse-c for remaining organisation with
      ASNs or other resources allocated or assigned by the RIPE NCC
      (Brian Nisbet)
   2. Re: [db-wg] RIPE NCC to set abuse-c for remaining
      organisation with ASNs or other resources allocated or assigned
      by the RIPE NCC (denis)


----------------------------------------------------------------------

Message: 1
Date: Tue, 12 Jan 2016 15:23:17 +0100
From: Brian Nisbet <brian.nisbet at heanet.ie>
To: Tim Bruijnzeels <tim at ripe.net>, anti-abuse-wg at ripe.net, Database
WG <db-wg at ripe.net>
Subject: Re: [anti-abuse-wg] RIPE NCC to set abuse-c for remaining
organisation with ASNs or other resources allocated or assigned by the
RIPE NCC
Message-ID: <56950C55.4060802 at heanet.ie>
Content-Type: text/plain; charset=utf-8; format=flowed

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-06
>>>
>>>
>>>
>>> Phase 1 of this plan was completed in December 2013, setting up
>>> abuse-c for then existing LIRs. Phase 2 of this plan was completed for
>>> organisations holding sponsored PI resources in November 2014.
>>> However, since then LIRs and end-users have been responsible for
>>> ensuring that an abuse-c exists for their organisation. In practice it
>>> has proven difficult to enforce this, since abuse-c is not a mandatory
>>> attribute in the RIPE DB schema, and as a result new cases where
>>> organisations do not have an abuse contact have been created.
>>>
>>> There is an important change in the implementation we would like to do
>>> ? based on our experiences thus far ? which would like the community's
>>> mandate on. We propose to use the end-user organisation's email
>>> address instead of the sponsoring LIR email address. We believe there
>>> are valid reasons for this change, but of course if this suggested
>>> change is controversial we would encourage discussing it in the
>>> anti-abuse working group. Ideally, we need to have a decision on this
>>> by early January so that we can prepare the work.
>>>
>>>
>>> 1) Prevent NEW cases
>>>
>>> We want to ensure that no new cases will be created as follows:
>>>
>>> = Since 1 March, the new member application form already provides much
>>> better integration with the RIPE Database
>>>    - because of this an abuse contact is now created whenever a new
>>> LIR is activated
>>>    - it can be modified the LIR, e.g. using web-updates, but not removed
>>>
>>> = We are currently adapting the new create organisation webupdates
>>> form to include abuse-c by default allowing the user to:
>>>    - reference an existing abuse-c role object, or
>>>    - enter an email address to create an abuse-c role for the
>>> organisation (using the same maintainer)
>>>
>>> = We are also adapting the edit organisation webupdates form to always
>>> suggest adding an abuse-c contact if it's not present
>>>
>>> = We plan to extend the new request forms:
>>>    - check that an end-user organisation has abuse-c before it can be
>>> used
>>>    - if not, refer to the edit form for the organisation where it will
>>> be easy to add reference an existing abuse contact, or create a new
>>> object
>>>
>>> 2) Resolve remaining EXISTING cases
>>>
>>> Originally the idea for phase 2 was to use the sponsoring LIR's email
>>> address in case the end-user organisation was unresponsive to requests
>>> to set their own abuse contact. However, since then policy 2012-08 has
>>> been implemented and nowadays the sponsoring LIR, and its abuse
>>> contact, can be found through the sponsoring-org attribute.
>>>
>>> Also, the RIPE NCC found that using the sponsoring organisation's
>>> email address leads to a number of issues:
>>>
>>> - end-users have no incentive to set their own abuse-c, rather then
>>> letting abuse questions go to their sponsor, so the majority remains
>>> unresponsive
>>> - in case an end-user has resources from more than one sponsor it is
>>> ambiguous which sponsor's email should be used
>>> - many LIRs were unpleasantly surprised by finding their email address
>>> in the abuse-c of the organisation they sponsor
>>> - in case LIRs no longer wish to sponsor resources, or when they are
>>> returned, existing references to their email in the end-user abuse-c
>>> are not cleaned up
>>>
>>> We would therefore like to propose a change to the implementation plan
>>> when addressing the remaining cases. Today, in case no abuse contact
>>> is set, users of the database will resort to using the organisation's
>>> default email. Therefore, adding a dedicated abuse-c role object using
>>> this email address, doesn't cause any noticeable new effects on
>>> organisations. It may well be the correct email address to use for an
>>> organisation, and no action would be required. However, it *enables*
>>> an organisation to use a different email address for abuse questions
>>> if appropriate.
>>>
>>> We would like to email remaining LIRs, and end-user organisations and
>>> sponsoring LIRs on Monday 1 February, giving them until Monday 15
>>> February to set their abuse contact. We realise that this means we
>>> would have another delay, but we believe that it would be unwise to do
>>> this change over the end of year holiday period, and to ensure that we
>>> can give proper support to questions we want to avoid doing this at
>>> the same time as the start of the year invoicing.
>>>
>>> Please let us know what you think.
>>>
>>> Kind regards,
>>>
>>> Tim Bruijnzeels
>>> Assistant Manager Software Engineering
>>> RIPE NCC Database Group
>>>
>>>
>>>
>>
>



------------------------------

Message: 2
Date: Wed, 13 Jan 2016 11:48:49 +0100
From: denis <ripedenis at yahoo.co.uk>
To: Brian Nisbet <brian.nisbet at heanet.ie>, Tim Bruijnzeels
<tim at ripe.net>, anti-abuse-wg at ripe.net, Database WG <db-wg at ripe.net>
Subject: Re: [anti-abuse-wg] [db-wg] RIPE NCC to set abuse-c for
remaining organisation with ASNs or other resources allocated or
assigned by the RIPE NCC
Message-ID: <56962B91.20800 at yahoo.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

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-06
>>>>
>>>>
>>>>
>>>>
>>>> Phase 1 of this plan was completed in December 2013, setting up
>>>> abuse-c for then existing LIRs. Phase 2 of this plan was completed for
>>>> organisations holding sponsored PI resources in November 2014.
>>>> However, since then LIRs and end-users have been responsible for
>>>> ensuring that an abuse-c exists for their organisation. In practice it
>>>> has proven difficult to enforce this, since abuse-c is not a mandatory
>>>> attribute in the RIPE DB schema, and as a result new cases where
>>>> organisations do not have an abuse contact have been created.
>>>>
>>>> There is an important change in the implementation we would like to do
>>>> ? based on our experiences thus far ? which would like the community's
>>>> mandate on. We propose to use the end-user organisation's email
>>>> address instead of the sponsoring LIR email address. We believe there
>>>> are valid reasons for this change, but of course if this suggested
>>>> change is controversial we would encourage discussing it in the
>>>> anti-abuse working group. Ideally, we need to have a decision on this
>>>> by early January so that we can prepare the work.
>>>>
>>>>
>>>> 1) Prevent NEW cases
>>>>
>>>> We want to ensure that no new cases will be created as follows:
>>>>
>>>> = Since 1 March, the new member application form already provides much
>>>> better integration with the RIPE Database
>>>>    - because of this an abuse contact is now created whenever a new
>>>> LIR is activated
>>>>    - it can be modified the LIR, e.g. using web-updates, but not
>>>> removed
>>>>
>>>> = We are currently adapting the new create organisation webupdates
>>>> form to include abuse-c by default allowing the user to:
>>>>    - reference an existing abuse-c role object, or
>>>>    - enter an email address to create an abuse-c role for the
>>>> organisation (using the same maintainer)
>>>>
>>>> = We are also adapting the edit organisation webupdates form to always
>>>> suggest adding an abuse-c contact if it's not present
>>>>
>>>> = We plan to extend the new request forms:
>>>>    - check that an end-user organisation has abuse-c before it can be
>>>> used
>>>>    - if not, refer to the edit form for the organisation where it will
>>>> be easy to add reference an existing abuse contact, or create a new
>>>> object
>>>>
>>>> 2) Resolve remaining EXISTING cases
>>>>
>>>> Originally the idea for phase 2 was to use the sponsoring LIR's email
>>>> address in case the end-user organisation was unresponsive to requests
>>>> to set their own abuse contact. However, since then policy 2012-08 has
>>>> been implemented and nowadays the sponsoring LIR, and its abuse
>>>> contact, can be found through the sponsoring-org attribute.
>>>>
>>>> Also, the RIPE NCC found that using the sponsoring organisation's
>>>> email address leads to a number of issues:
>>>>
>>>> - end-users have no incentive to set their own abuse-c, rather then
>>>> letting abuse questions go to their sponsor, so the majority remains
>>>> unresponsive
>>>> - in case an end-user has resources from more than one sponsor it is
>>>> ambiguous which sponsor's email should be used
>>>> - many LIRs were unpleasantly surprised by finding their email address
>>>> in the abuse-c of the organisation they sponsor
>>>> - in case LIRs no longer wish to sponsor resources, or when they are
>>>> returned, existing references to their email in the end-user abuse-c
>>>> are not cleaned up
>>>>
>>>> We would therefore like to propose a change to the implementation plan
>>>> when addressing the remaining cases. Today, in case no abuse contact
>>>> is set, users of the database will resort to using the organisation's
>>>> default email. Therefore, adding a dedicated abuse-c role object using
>>>> this email address, doesn't cause any noticeable new effects on
>>>> organisations. It may well be the correct email address to use for an
>>>> organisation, and no action would be required. However, it *enables*
>>>> an organisation to use a different email address for abuse questions
>>>> if appropriate.
>>>>
>>>> We would like to email remaining LIRs, and end-user organisations and
>>>> sponsoring LIRs on Monday 1 February, giving them until Monday 15
>>>> February to set their abuse contact. We realise that this means we
>>>> would have another delay, but we believe that it would be unwise to do
>>>> this change over the end of year holiday period, and to ensure that we
>>>> can give proper support to questions we want to avoid doing this at
>>>> the same time as the start of the year invoicing.
>>>>
>>>> Please let us know what you think.
>>>>
>>>> Kind regards,
>>>>
>>>> Tim Bruijnzeels
>>>> Assistant Manager Software Engineering
>>>> RIPE NCC Database Group
>>>>
>>>>
>>>>
>>>
>>
>



End of anti-abuse-wg Digest, Vol 51, Issue 2
********************************************