Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Hi Piotr, We’re happy to outline some high-level approaches for how we might meet the requirements of the proposal. Please note that details of the actual implementation and potential limitations will need further study and will be covered in the impact analysis. We will seek guidance from the RIPE community on which particular approach it would like us to take — whether this ends up being a variation on one of the approaches mentioned below, or something different altogether. With this in mind, we would like to share the following information to support the WG’s discussion. The RIPE Database currently contains ~70,200 inetnum objects and ~700 aut-num objects with the status LEGACY. Of these, around 11,900 have an organisation object referenced, with around 3,900 of these organisation objects having an abuse-c attribute in place. This means that around 17% of the resource objects have an organisation object and around 5.5% have a reference to an abuse contact. One possible approach could be to add the abuse-c attribute to existing organisation objects. This could be done in a similar way to how it was done for resources that were allocated or assigned by the RIPE NCC. Resources without an organisation object would not have an abuse contact. The mandatory database update that Erik mentioned could be another possible approach. Whenever a resource with the status LEGACY is updated, it must have a reference to an organisation object with the abuse-c attribute to perform this update. Resources that are not updated will not get an abuse contact. A third approach would add abuse-c references to all organisation objects held by legacy holders. The RIPE NCC would need to contact these holders of 67,000 objects, of which 59,000 have no organisation object. Taking into account our experience from implementing 2007-01, “Direct Internet Resource Assignments to End Users from the RIPE NCC”, we would expect a significant amount of manual work with this approach. The RIPE NCC is currently unable to enforce updates on legacy resources. We hope this helps with your discussion of the proposal. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On Thu, Jan 28, 2016 at 18:49:41 +0100, Piotr Strzyzewski wrote:
On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote:
Marco
A new RIPE Policy proposal, "Include Legacy Internet Resource Holders in the Abuse-c Policy", is now available for discussion.
The goal of this proposal is to extend RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database", to Legacy Internet Resource Holders.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-01
We encourage you to review this proposal and send your comments to <anti-abuse-wg at ripe.net> before 26 February 2016.
Would you be so kind and publish possible approaches to deal with the requirements of this proposal. It will be a benefit for the members of this WG to see how NCC perceive this proposal.
Thanks in advance, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
On 29/01/2016 16:02, Marco Schmidt wrote:
Hi Piotr,
We’re happy to outline some high-level approaches for how we might meet the requirements of the proposal. Please note that details of the actual implementation and potential limitations will need further study and will be covered in the impact analysis. We will seek guidance from the RIPE community on which particular approach it would like us to take — whether this ends up being a variation on one of the approaches mentioned below, or something different altogether.
With this in mind, we would like to share the following information to support the WG’s discussion.
The RIPE Database currently contains ~70,200 inetnum objects and ~700 aut-num objects with the status LEGACY. Of these, around 11,900 have an organisation object referenced, with around 3,900 of these organisation objects having an abuse-c attribute in place. This means that around 17% of the resource objects have an organisation object and around 5.5% have a reference to an abuse contact.
How many of these INETNUM objects are top level legacy resources? They are the only ones that need an "abuse-c:" attribute.
One possible approach could be to add the abuse-c attribute to existing organisation objects. This could be done in a similar way to how it was done for resources that were allocated or assigned by the RIPE NCC. Resources without an organisation object would not have an abuse contact.
The mandatory database update that Erik mentioned could be another possible approach. Whenever a resource with the status LEGACY is updated, it must have a reference to an organisation object with the abuse-c attribute to perform this update. Resources that are not updated will not get an abuse contact.
NO!!! Only top level legacy resource need to reference an ORGANISATION object. Keep in mind that every object more specific to the top level legacy resource object also has the same status 'LEGACY'.
A third approach would add abuse-c references to all organisation objects held by legacy holders. The RIPE NCC would need to contact these
Again NO!!! This is the same argument I have had about the new Webupdates. Because "abuse-c:" works in an inherited way within the hierarchy it is fundamentally wrong to add redundant links where they are not needed. cheers denis
holders of 67,000 objects, of which 59,000 have no organisation object. Taking into account our experience from implementing 2007-01, “Direct Internet Resource Assignments to End Users from the RIPE NCC”, we would expect a significant amount of manual work with this approach. The RIPE NCC is currently unable to enforce updates on legacy resources.
We hope this helps with your discussion of the proposal.
Kind regards
Marco Schmidt Policy Development Officer RIPE NCC
On Thu, Jan 28, 2016 at 18:49:41 +0100, Piotr Strzyzewski wrote:
On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote:
Marco
A new RIPE Policy proposal, "Include Legacy Internet Resource Holders in the Abuse-c Policy", is now available for discussion.
The goal of this proposal is to extend RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database", to Legacy Internet Resource Holders.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-01
We encourage you to review this proposal and send your comments to <anti-abuse-wg at ripe.net> before 26 February 2016.
Would you be so kind and publish possible approaches to deal with the requirements of this proposal. It will be a benefit for the members of this WG to see how NCC perceive this proposal.
Thanks in advance, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
Hello Denis, Thank you for your question. There are currently about 4,000 top-level legacy resources registered in the RIPE Database. Some of the organisations, that have received these resources from organisations like InternNIC, have distributed parts of these address blocks further to other parties. The details of this further distribution are often not known to the RIPE NCC. It is possible, that the holder of the top-level legacy resource has no responsibility for the more specific blocks. Therefore it can't be assumed by default that Legacy address space follows the same clear hierarchical structure as address space allocated by the RIPE NCC. It would be part of the implementation to find out if the resource holders of top-level legacy resources want to be responsible for more specific objects. Currently this is only known, when legacy resource holders have entered into a contractual relationship with the RIPE NCC. Details about the challenges to identify the legitimate holder of legacy resources have been outlined in the impact analysis for proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders". https://www.ripe.net/participate/policies/proposals/2012-07 Based on the approach the RIPE community will choose, the RIPE NCC will perform a deeper analysis on the actual impact once this proposal would move to the Review Phase. Hope this answers your question. Regards, Marco Schmidt Policy Development Officer RIPE NCC On 30/01/2016 18:33, denis wrote:
On 29/01/2016 16:02, Marco Schmidt wrote:
Hi Piotr,
We’re happy to outline some high-level approaches for how we might meet the requirements of the proposal. Please note that details of the actual implementation and potential limitations will need further study and will be covered in the impact analysis. We will seek guidance from the RIPE community on which particular approach it would like us to take — whether this ends up being a variation on one of the approaches mentioned below, or something different altogether.
With this in mind, we would like to share the following information to support the WG’s discussion.
The RIPE Database currently contains ~70,200 inetnum objects and ~700 aut-num objects with the status LEGACY. Of these, around 11,900 have an organisation object referenced, with around 3,900 of these organisation objects having an abuse-c attribute in place. This means that around 17% of the resource objects have an organisation object and around 5.5% have a reference to an abuse contact.
How many of these INETNUM objects are top level legacy resources? They are the only ones that need an "abuse-c:" attribute.
One possible approach could be to add the abuse-c attribute to existing organisation objects. This could be done in a similar way to how it was done for resources that were allocated or assigned by the RIPE NCC. Resources without an organisation object would not have an abuse contact.
The mandatory database update that Erik mentioned could be another possible approach. Whenever a resource with the status LEGACY is updated, it must have a reference to an organisation object with the abuse-c attribute to perform this update. Resources that are not updated will not get an abuse contact.
NO!!! Only top level legacy resource need to reference an ORGANISATION object. Keep in mind that every object more specific to the top level legacy resource object also has the same status 'LEGACY'.
A third approach would add abuse-c references to all organisation objects held by legacy holders. The RIPE NCC would need to contact these
Again NO!!! This is the same argument I have had about the new Webupdates. Because "abuse-c:" works in an inherited way within the hierarchy it is fundamentally wrong to add redundant links where they are not needed.
cheers denis
holders of 67,000 objects, of which 59,000 have no organisation object. Taking into account our experience from implementing 2007-01, “Direct Internet Resource Assignments to End Users from the RIPE NCC”, we would expect a significant amount of manual work with this approach. The RIPE NCC is currently unable to enforce updates on legacy resources.
We hope this helps with your discussion of the proposal.
Kind regards
Marco Schmidt Policy Development Officer RIPE NCC
On Thu, Jan 28, 2016 at 18:49:41 +0100, Piotr Strzyzewski wrote:
On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote:
Marco
A new RIPE Policy proposal, "Include Legacy Internet Resource Holders in the Abuse-c Policy", is now available for discussion.
The goal of this proposal is to extend RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database", to Legacy Internet Resource Holders.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-01
We encourage you to review this proposal and send your comments to <anti-abuse-wg at ripe.net> before 26 February 2016.
Would you be so kind and publish possible approaches to deal with the requirements of this proposal. It will be a benefit for the members of this WG to see how NCC perceive this proposal.
Thanks in advance, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
participants (2)
-
denis -
Marco Schmidt