Hi All When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was:-allowing 6 months to deploy to all members allocations-then 12 months to deploy to all independent resources-then do a cleanup The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database. I think it is time to schedule that cleanup. Can the RIPE NCC confirm that all resources now have an "abuse-c:"? cheersDenis WalkerIndependent Netizen
+1 I’d assume most do at this stage – it would be good to get confirmation of same Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: denis walker Reply-To: denis walker Date: Tuesday 5 May 2015 14:59 To: "anti-abuse-wg@ripe.net<mailto:anti-abuse-wg@ripe.net>" Subject: [anti-abuse-wg] abuse-c cleanup Hi All When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was: -allowing 6 months to deploy to all members allocations -then 12 months to deploy to all independent resources -then do a cleanup The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database. I think it is time to schedule that cleanup. Can the RIPE NCC confirm that all resources now have an "abuse-c:"? cheers Denis Walker Independent Netizen
Dear colleagues,
On 05 May 2015, at 15:59, denis walker <ripedenis@yahoo.co.uk> wrote:
When the original implementation plan was put forward for "abuse-c:", the time line (if I remember correctly) was: -allowing 6 months to deploy to all members allocations -then 12 months to deploy to all independent resources -then do a cleanup
I believe you are referring to this: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011... <https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06>
Can the RIPE NCC confirm that all resources now have an "abuse-c:"?
No, there are still organisations without abuse-c associated with resources. 1 = Some LIRs are still missing abuse-c Once the abuse-c has been set up for an organisation it cannot be removed, although it can be modified. However, "abuse-c:" still needs to be set for some LIRs created after phase-1 was completed. This is due to the fact that until recently new LIRs needed to create their own maintainer, abuse-c role object manually after membership activation. So new cases of LIRs that do not have an abuse-c set up were added every day. We updated the member activation process recently and now a maintainer and abuse-c role are created as part of the activation process. So, going forward we can now contact the remaining LIRs to set the abuse-c, and be sure that no new cases are created. We have not done this yet, because we were focusing on implementing the phase 1 and 2 of deprecating changed first. 2 = Not all organisations have an abuse-c The RIPE NCC only has a policy mandate to enforce abuse-c for organisations associated with resources allocated or assigned through the RIPE NCC. I.e. organisations holding legacy resources or assignments made by LIRs are not covered.
The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.
A schema change like this would need to be discussed in the database working group, and can only be done in case "abuse-c:" can be made mandatory for all organisations - and this would also have to be discussed there. From a technical point of view this change is not necessarily difficult to implement, provided that missing abuse-c roles could be created using either the existing abuse-mailbox or email attribute on organisations - presumably the addresses people would turn to today in the absence of an explicit abuse-c. So, in a way this change should not have a big semantic impact. Consistency would help to reduce complexity in documentation and business rules. It would also make it easier when assigning resources to new non-LIR organisations - now we need to check whether abuse-c has been set, because it's not mandatory and we often find that this makes dealing with requests longer. But that said, the above is only a partial picture of this, and this should in our view be discussed in the database working group. We can implement after consensus is called. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On Wed, May 06, 2015 at 05:18:06PM +0200, Tim Bruijnzeels wrote: Dear WG Members
The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.
A schema change like this would need to be discussed in the database working group, and can only be done in case "abuse-c:" can be made mandatory for all organisations - and this would also have to be discussed there.
From a technical point of view this change is not necessarily difficult to implement, provided that missing abuse-c roles could be created using either the existing abuse-mailbox or email attribute on organisations - presumably the addresses people would turn to today in the absence of an explicit abuse-c. So, in a way this change should not have a big semantic impact. Consistency would help to reduce complexity in documentation and business rules. It would also make it easier when assigning resources to new non-LIR organisations - now we need to check whether abuse-c has been set, because it's not mandatory and we often find that this makes dealing with requests longer.
But that said, the above is only a partial picture of this, and this should in our view be discussed in the database working group. We can implement after consensus is called.
I agree with that. Denis do you want to make a follow-up on DB-WG? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi, On 5/5/2015 15:59 , denis walker wrote:
The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.
I think it is time to schedule that cleanup.
I'd like to have the "cleanup" defined and discussed before doing it. The 'remarks' are obviously not really useful, and the abuse-c seems to replace functionally the abuse-mailbox (except that I still miss a 'more specific' abuse-c). The IRT objects are different though, and have features that the abuse-c lacks. So unless the abuse-c is able to replace the IRT, I'd object to deleting those. (to be specific: I'd hate to lose the signature and encryption fields - I think it was a mistake not to add those to the abuse-c from the start) best, Gilles
Hi Gilles I have just submit a proposal to the DB WG on the cleanup process. There was some discussion a long time ago on converting IRT object into ROLE objects, but that discussion was never brought to any conclusion. I don't propose to include that in this cleanup. cheers Denis Walker Independent Netizen On 07/05/2015 19:06, Gilles Massen wrote:
Hi,
On 5/5/2015 15:59 , denis walker wrote:
The first two steps are done, but the last one seems to have been overlooked. The idea of "abuse-c:" was to create one single place/way of documenting abuse contact details. So far all that has been achieved is to add a fourth way to document it. All the old ways ("abuse-mailbox:" in 5 object types, IRT and remarks) are still littered throughout the database.
I think it is time to schedule that cleanup. I'd like to have the "cleanup" defined and discussed before doing it. The 'remarks' are obviously not really useful, and the abuse-c seems to replace functionally the abuse-mailbox (except that I still miss a 'more specific' abuse-c). The IRT objects are different though, and have features that the abuse-c lacks. So unless the abuse-c is able to replace the IRT, I'd object to deleting those.
(to be specific: I'd hate to lose the signature and encryption fields - I think it was a mistake not to add those to the abuse-c from the start)
best, Gilles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/05/2015 18:06, Gilles Massen wrote:
I'd like to have the "cleanup" defined and discussed before doing it. The 'remarks' are obviously not really useful, and the abuse-c seems to replace functionally the abuse-mailbox (except that I still miss a 'more specific' abuse-c). The IRT objects are different though, and have features that the abuse-c lacks. So unless the abuse-c is able to replace the IRT, I'd object to deleting those.
I've never seen an IRT object in the wild outside of the Trusted Introducer community, and when I encounter them they're usually for people/teams I personally know. Are there any statistics on how many exist? I'm also not sure which of the unique attributes actually get used - I've looked up IRT objects I don't think I've ever used the signature, encryption, or fax-no attributes. The need for all the features should be balanced against the benefits of a simple and consistent approach. I don't attend Trusted Introducer meetings at the moment but the steering committee is represented here :) James - -- James Davis, Information Security Manager +44 1235 822229 Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBAgAGBQJVTIE0AAoJED9R4Wv4u3eiQZoQAIEpjYfAKqjqnY6WlNTwdTN6 Pj/EykdbVJa3k9yXOt9okGuK0zcFJuc8ipz8DGx1OOlC9zlP7VXjWh72Oy0ck50F fVL9WskBEYvW1FlWADe/ykSZTbMCALPiIUo4DaZsGRSS7e+67paCQwDAyIlh314z hXBXZ9EaLyM8YHScbCBPFgw2aEaWfCehWJWCtO5+Wfqo3lZJ1T/6lXB7RuThwytA K48C9vdx3O/4W9CZvfmxPh6eFEyVHG+TULrVXtRZun6VPwTdxDydQ0UIC4o8VpGO y2dqai+fBzadJtGKw/1qF12pJQYYwyQKCvzW1mO6j8la8Sd1U6LbMxmYzuMxBgh8 P2ZyUB3gYsGguTEHdyEdRVe9Z+vWO268jznShRPnq7ir0Qq/S+OX/ssCyfTukXFe FXx/m65ZV5//xUHrGcnew4ih52PCmWjdpw91Icv9+R8b6A2ATMWN4hdDxU6PZDLA QBvNNCJnm13U1L3uMbwCbWGRNGRvHo3EehFxC4hEU+uKdZi5ydrz7QgnVfM9t/eu ubCMhw7nPAPcMMf7xTrKKjdd0CIdvnJz4PoRiQTI/IDy2I5LuFvlIYGlhI/wb0io 8wgF4kbQzTju67wu18q8BnQG2OFwBwJLEaXslAfy4iZcXyN3fLTMij9jgW9k3ZQm y1nJVEKxShTtBIoyxhFb =RrGF -----END PGP SIGNATURE----- Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
participants (7)
-
denis -
denis walker
-
Gilles Massen -
James Davis -
Michele Neylon - Blacknight -
Piotr Strzyzewski -
Tim Bruijnzeels