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 ]
Piotr Strzyzewski
Piotr.Strzyzewski at polsl.pl
Thu Jan 28 15:45:29 CET 2016
On Thu, Jan 28, 2016 at 11:18:16AM +0000, Erik Bais wrote: Hi Erik > Thank you for the formal proposal. > > > You can find the full proposal at: > > > 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. ;-) > If a Legacy holder changes his Organization Object to include the > abuse-c object in the RIPE DB and links it to the inet num object .. > it shows the abuse information. > > For instance : > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=144.2.240.0%20-%20144.2.255.255&type=inetnum ( No Abuse contact, because no Org-ID. ) > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=144.2.168.0%20-%20144.2.171.255&type=inetnum ( no Abuse Contact, Org ID present, but no abuse-c in the Org-ID. ) > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=144.2.176.0%20-%20144.2.191.255&type=inetnum ( Abuse contact in the Org-ID. ) > > From what I see is that the Abuse-C contact can be added, but it is > org-id ( the link to the actual legitimate holder ) which holds the > abuse-c, is the issue. > > 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. > 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). > So the mandatory database update needs to be done by the maintainer of > the legacy resource (whenever they change their allocations/make > changes). That could be done by having the Org-ID field mandatory in > the database for all parent inet-nums. > > Or am I missing something here ? Hope I was clear. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
- 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 ]