2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Dear colleagues, 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@ripe.net> before 26 February 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC
Hi Piotr, Thank you for the formal proposal.
You can find the full proposal at:
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 ? ... 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. ? 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.. 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 ? Regards, Erik Bais
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:
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@polsl.pl
Hi Piotr,
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
On Thu, Jan 28, 2016 at 04:53:57PM +0000, Erik Bais wrote: Hi Erik
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 ...
"An option" as you said is the answer to the question. I hope that Marco will send some numbers tomorrow and it will be more clear that the option is sadly not enough.
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..
Noted.
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
And/or business rule in the database.
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 ...
Again. Let's wait for the numbers. From my opinion this could be a very long term process.
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 ...
Well. Not all. Not every LRH have had registered its resources in the RIPE Whois DB. But I get your point. And probably the answer is yes. If and only if the community will decide to follow this approach.
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.
That is the question from Pandora's box. I don't want to start a debate why NCC should serve those LRHs without contracts and invite them to register resources in the DB. I believe I know the arguments of both sides.
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.
I'm glad that you propose that. This is one of the possible choices I'm aware of. And it seems that this is one which has a good balance of compromise, effectiveness and cost.
And don't under estimate the number of Legacy changes, especially with all transfers currently.. so that might actually go quite fast..
Good point. Regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote:
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.
There goes my new year's resolution to not bother with RIPE policy this year. Why in all hells is this proposal in AAWG? This belongs in ncc-services or db-wg! (to be fair, Marco promulgated its existence on the relevant lists but why is everyone subjected to the ordeal of being subscribed to this list?) As for the proposal, I can't see how the NCC could enforce the correctness of this for all legacy resource holders, so it doesn't serve the intended purpose. rgds, Sascha Luck
On Thu, Jan 28, 2016 at 02:29:48PM +0000, Sascha Luck [ml] wrote:
On Thu, Jan 28, 2016 at 10:06:50AM +0100, Marco Schmidt wrote:
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.
There goes my new year's resolution to not bother with RIPE policy this year.
Why in all hells is this proposal in AAWG? This belongs in ncc-services or db-wg! (to be fair, Marco promulgated its existence on the relevant lists but why is everyone subjected to the ordeal of being subscribed to this list?)
It was agreed with the Chairs that it should be posted where the original abuse-c proposal was discussed.
As for the proposal, I can't see how the NCC could enforce the correctness of this for all legacy resource holders, so it doesn't serve the intended purpose.
It was briefly discussed with the NCC and there are some sort of solutions for that. Besides, it was done in the past. Some "lazy" LIRs did not updated the organisation objects on time and NCC have had to resolve this inconvenience. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
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@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@polsl.pl
Hello, Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy. regards, Gilles
On Thu, Jan 28, 2016 at 07:18:38PM +0100, Gilles Massen wrote: Dear Gilles
Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy.
Let's make a proposal for a DB-WG to deal with that and will see what is the community's point of view for that. Is it ok for You? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Gilles Yes it is possible to do this. I know I keep saying this and I know no one wants to even talk about it but the current data model does impose some limitations. However, even with these limitations it is all about how you perceive certain objects functions. An organisation that holds resources must have an ORGANISATION object if they are not legacy resources and may have one if they are legacy resources. There is nothing stopping that organisation creating multiple ORGANISATION objects and using them to represent departments within the same organisation or representing some sub characteristic of the organisation. Whatever it represents can be made clear in "descr:" and "remarks:" attributes within the other ORGANISATION objects. These ORGANISATION objects can be referenced from any more specific INETNUM object and contain an "abuse-c:" attribute. I know this is a bit clumsy, but it IS easy to do and can be clearly documented and can accommodate any arrangement of abuse handling you wish to represent. cheersdenis From: Gilles Massen <gilles.massen@restena.lu> To: anti-abuse-wg@ripe.net Sent: Thursday, 28 January 2016, 19:18 Subject: Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy) Hello, Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy. regards, Gilles
Hi Denis, IIRC, when I looked into this your proposed workaround was not possible for a maintainer/legacy reason, but since we brought the LEGACY assignments properly under the RIPE roof, it should work know. BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So instead of the hypothetical problems of keeping the fundamental logic of 'more specific', a tool only to be used by those who'd need it, the workaround makes them a certainty. 'Clumsy' does not quite describe it. In our specific case, I'd stay the slightly worse abuse-c, rather than duplicating ORG objects. Unfortunately enough, the loss (as small as it might be) is not mine... best regards, Gilles On 28/01/16 21:10, ripedenis@yahoo.co.uk wrote:
Hi Gilles
Yes it is possible to do this. I know I keep saying this and I know no one wants to even talk about it but the current data model does impose some limitations. However, even with these limitations it is all about how you perceive certain objects functions. An organisation that holds resources must have an ORGANISATION object if they are not legacy resources and may have one if they are legacy resources. There is nothing stopping that organisation creating multiple ORGANISATION objects and using them to represent departments within the same organisation or representing some sub characteristic of the organisation. Whatever it represents can be made clear in "descr:" and "remarks:" attributes within the other ORGANISATION objects. These ORGANISATION objects can be referenced from any more specific INETNUM object and contain an "abuse-c:" attribute.
I know this is a bit clumsy, but it IS easy to do and can be clearly documented and can accommodate any arrangement of abuse handling you wish to represent.
cheers denis
------------------------------------------------------------------------ *From:* Gilles Massen <gilles.massen@restena.lu> *To:* anti-abuse-wg@ripe.net *Sent:* Thursday, 28 January 2016, 19:18 *Subject:* Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Hello,
Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy.
regards, Gilles
-- Fondation RESTENA - DNS-LU 2, avenue de l'Université LU-4365 Esch-sur-Alzette tel: +352.4244091 fax: +352.422473
Hi Giles Unfortunately it is not easy to accommodate every possible arrangement and keep it tightly controlled. Before "abuse-c:" was introduced the "abuse-mailbox:" attribute was allowed in 5 object types and it became unmanageable. (It still is in 5 object types as the clean-up has not yet been done.) On 29/01/2016 17:21, Gilles Massen wrote:
Hi Denis,
IIRC, when I looked into this your proposed workaround was not possible for a maintainer/legacy reason, but since we brought the LEGACY assignments properly under the RIPE roof, it should work know.
BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So
Strictly speaking it is not exactly a 'duplicate' ORGANISATION object. Something is different at this point in your network (abuse handler). But we don't have any other way of noting a difference except by using the ORGANISATION object. I really wish people were willing to at least talk about a data model review. So much could be improved. cheers denis
instead of the hypothetical problems of keeping the fundamental logic of 'more specific', a tool only to be used by those who'd need it, the workaround makes them a certainty. 'Clumsy' does not quite describe it.
In our specific case, I'd stay the slightly worse abuse-c, rather than duplicating ORG objects. Unfortunately enough, the loss (as small as it might be) is not mine...
best regards, Gilles
On 28/01/16 21:10, ripedenis@yahoo.co.uk wrote:
Hi Gilles
Yes it is possible to do this. I know I keep saying this and I know no one wants to even talk about it but the current data model does impose some limitations. However, even with these limitations it is all about how you perceive certain objects functions. An organisation that holds resources must have an ORGANISATION object if they are not legacy resources and may have one if they are legacy resources. There is nothing stopping that organisation creating multiple ORGANISATION objects and using them to represent departments within the same organisation or representing some sub characteristic of the organisation. Whatever it represents can be made clear in "descr:" and "remarks:" attributes within the other ORGANISATION objects. These ORGANISATION objects can be referenced from any more specific INETNUM object and contain an "abuse-c:" attribute.
I know this is a bit clumsy, but it IS easy to do and can be clearly documented and can accommodate any arrangement of abuse handling you wish to represent.
cheers denis
------------------------------------------------------------------------ *From:* Gilles Massen <gilles.massen@restena.lu> *To:* anti-abuse-wg@ripe.net *Sent:* Thursday, 28 January 2016, 19:18 *Subject:* Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Hello,
Since the rationale mentions the "better quality of abuse contact data", I'd like to point out that it is still not possible to have a different abuse-c for different inetnums, if they belong to the same ORG. The impossibility to have a "more specific" is the ONLY thing that prevents me to have accurate abuse contact data for our LEGACY addresses, not the absence of a specific policy.
regards, Gilles
Hi Denis,
Unfortunately it is not easy to accommodate every possible arrangement and keep it tightly controlled.
Agreed. I think we have a different opinion on where to put the cursor between control and flexibility. Most of the time I'd grant more liberty, simply because it make the life of well behaving people easier. And the others will find workarounds, no matter what the corols are.
Before "abuse-c:" was introduced the "abuse-mailbox:" attribute was allowed in 5 object types and it became unmanageable. (It still is in 5 object types as the clean-up has not yet been done.)
Yes, and I think the inheritance part of the abuse-c is a big step forward. But even the abuse-mailbox could have worked if there was a clear query path, so that the producer of the information knew what request produced what result.
BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So
Strictly speaking it is not exactly a 'duplicate' ORGANISATION object.
Strictly speaking, you are right. For all practical purposes, you are not :)
Something is different at this point in your network (abuse handler).
Correct. It is a difference in the network (or management of a certain part), not in the organisation. As I said, I can live with the current restriction, even if it frustrates me. It is the consumers of abuse-c that should be annoyed.
I really wish people were willing to at least talk about a data model review.
Why not? best, Gilles -- Fondation RESTENA - DNS-LU 2, avenue de l'université LU-4365 Esch-sur-Alzette
participants (7)
-
denis -
Erik Bais -
Gilles Massen -
Marco Schmidt -
Piotr Strzyzewski -
ripedenis＠yahoo.co.uk
-
Sascha Luck [ml]