This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Previous message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Next message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Erik Bais
erik at bais.name
Thu Jan 28 17:53:57 CET 2016
Hi Piotr, >> > https://www.ripe.net/participate/policies/proposals/2016-01 >> >> I've read the proposal and I have a question on it. >> > >You propose that you want to extend the Abuse-C Contact management in > >the RIPE Database policy towards Legacy Internet Resource Holders. > > > >However ... > > > >That is already the case ... isn't it ? ... >I don't think so. ;-) Can you explain what you are missing ? Because there is already an option for Legacy holder to correctly register the Org-ID in their Legacy resources .. And the Org-ID already has the (currently non-mandatory) optional field : Abuse-C ... >> So the question that would come to my mind is, do you want to enforce >> the inclusion of the Org-ID into the legacy ( or any type of inet-num) >> object .. and have the abuse-c as a mandatory field in the org-id. ? >Yes and no. Yes, I do want to enforce the inclusion of the Org-ID into >the legacy objects. No, I do not want to have the abuse-c as a mandatory >field in organisation object. One of the reasons for the latter is that >there is no need for mandatory abuse-c for assignments within >allocation, due to the hierarchical nature of the abuse-c itself. So you don't want to enforce through the database (at an update by the LRH ) to make sure that all parent objects will have an Org-ID.. which will fix the database accuracy things you speak of.. That you don't want it enforced for more specific objects, is something to debate about.. but it should at least be possible at that level.. >> As for Legacy resource holders, that might be an issue to enforce, as >> the RIPE NCC can't reach out to all legacy holders that are >> 'incompliant' as we can't ask them to start guessing who are the >> actual legitimate holders.. > True. But even for some of them, who sign the contract it is not > possible to enforce that. Even considering the fact that those LRHs have > to "maintain accurate data in the registry in respect of each resource > identified" (see RIPE-639, Section 3.0, bullet 4). I think our view of enforcing is different here.. I see a mandatory field in a database as a way to 'gently push' users into the envisioned direction ... Without the requirement for the RIPE NCC to call them up or make the change for them, based on guessing who the actual LRH is ... I think that you are looking for a stronger mandate here.. ( Please correct me if I'm wrong on this ..) and do a new 2007-01 kind of effort and start calling all Legacy holders .. with or without a contract to make sure they are going to update their legacy inet-nums. Where the Legacy holders may not have a contractual relationship with the RIPE NCC and the RIPE NCC doesn't have a contact point into a certain company who might have receive IP space in 1993 ... I would not be in favor of such an effort ... I don't see how the RIPE NCC could ever do or complete such a task as it is asking the (almost) impossible .. and there is no financial / contractual relation between the LRH and the RIPE NCC, so why would the LRH do it at all. Doing a more light touch approach in a database schema, will not ask for an impossible task and it will not cost X amount of men years of work ... and get similar results.. Those that will update / change their info in the RIPE DB, will need to update the resources with the Org-ID including an Abuse-C. And don't under estimate the number of Legacy changes, especially with all transfers currently.. so that might actually go quite fast.. Regards, Erik Bais
- Previous message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Next message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]