In the problem statement, I think it would be a good idea to address the existence of the "abuse-mailbox:" attribute as well. This is causing a lot of confusion over the proper usage of "abuse-c:". With the right implementation, we should end up in a position to remove "abuse-mailbox:" altogether.
Kind regards, Alex Band > On 8 Nov 2016, at 18:01, Tim Bruijnzeels <[email protected]> wrote: > > Dear WG, > >> On 03 Nov 2016, at 10:31, Sebastian Wiesinger <[email protected]> wrote: >> >> * denis <[email protected]> [2016-11-03 00:30]: >>> Hi William >>> >>> If we are going to follow the NWI then lets define the problem and then look >>> at available options to fix it. There are other ways to fix it and each >>> option has pros and cons. >> >> I just requested a NWI for this. > > I would just like to echo that at RIPE NCC we agree that there is a problem > to address here. > > And although this thread already shows shared understanding of the problem > space and some great suggestions, I still believe that defining the problem > statement a bit more formally, and including related issues, will help to > make the discussion on solutions more structured and will help to weigh pros > and cons. > > So, I hope that the WG doesn't mind if I take a shot at formulating one. > Obviously it can and should be discussed further, refined or even replaced > altogether as part of the 1st phase of the NWI process. > > > Problem statement: > ================== > > It is currently not possible to specify alternative abuse contacts for > different resources held by the same organisation in the RIPE Database. This > can be problematic. > > For example for abuse contact management for big organisations which want > multiple abuse contacts for different parts of the organisation. The org is > using a lot of PI resources, some of them legacy. Currently they all use the > same ORGANISATION object which is inextricably linked to the same abuse-c > mailbox. [example taken from Sebastian's first email] > > Another example applies to different allocations held by a single LIR. The > reference to the LIR's ORGANISATION object is maintained as part of the > registry managed by RIPE NCC, and therefore all allocations will have the > same abuse-c mailbox. There may however be good operational reasons for > having different contacts. [same issue, slightly different example also > mentioned by David] > > It should be noted however that it is considered useful that in cases where > there is no need to have a different abuse-c mailbox, the abuse-c can be > defined on an ORGANISATION object that is referenced from an INET(6)NUM > object, and have it apply to more specific INET(6)NUM objects through > inheritance. This avoids data duplication, and makes it easier to manage this > information. > > But on the other hand it should also be noted that for a lot of less > experienced users of the RIPE database it has proven to be difficult to find > the applicable abuse contact for a resource, following this hierarchy. For > this reason the abuse contact is now mentioned as a comment in whois output, > and is highlighted explicitly on the web query results. > > As a somewhat related issue I would also mention the following: > > Management of administrative and technical contacts in the RIPE Database is > done differently, and the challenges of maintaining that data is somewhat > different. While here it is possible, or even mandatory, to have explicit > references to admin-c or tech-c contacts for each resource object that may > differ from the objects, it is *not* possible here to inherit these contacts > from a covering INET(6)NUM or ORGANISATION object. This results in an > increase in maintenance burden for this data and therefore makes it more > difficult to maintain accurate data. > > >> Do you have other (better) ways in >> mind already? > > We have had some discussions about this as well, and I have some ideas as > well. It's pretty close to "option b" that David mentioned, but with some > tweaks that we believe will make it easy to apply a consistent approach for > abuse-c, admin-c and tech-c management, lowering maintenance for > organisations that have no need to use different contacts, whilst allowing > more complex organisations to override where necessary. At the same time we > can keep the impact and burden on clients of the RIPE Database minimal. > > I would love to discuss in more detail, but before I I go further do I would > like to ask the chairs if I should do so now, or wait until we have a defined > problem statement. > > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC Database Group > > > > > >> >> Regards >> >> Sebastian >> >> -- >> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) >> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE >> SCYTHE. >> -- Terry Pratchett, The Fifth Elephant > > >
