[acm-tf] suggestion

Hello,

thanks Denis for writing down the ideas of our talk this morning.

I absolutely like this idea.

It lets us start soon. Almost now!
It already offers a lot functionality that is needed.
We still have time to adjust small things until RIPE 63.
We can "refurbish" the good design of the IRT for a greater audience.
And the probably biggest thing is, that we can ask community to start
creating the object and give us feedback what will be needed.


Something that came into my mind while talking to Denis was, that we
should avoid the mistake of creating and developing an extremely nice
object and forget about documentation as it has happend with the IRT
Object.

Thanks,

Tobias



Am 03.05.11 15:43, schrieb Denis Walker:
> HI
> 
> Something for you to think about and feel free to grab me any time this
> week if you want any more information.
> 
> I was talking to Tobias this morning about some design ideas I have had
> over the last year for handling abuse POC information. While talking
> another idea came to mind. It would be quite easy for us to rename the
> "mnt-irt:" attribute to "abuse-c:". This would virtually implement the
> whole requirement for an abuse POC, without affecting its use for
> Incident Response Teams. It would still require authentication to add a
> reference to the IRT.
> 
> It will be obvious to any user that this "new" attribute references a
> contact as it ends with '-c'. An IRT object IS a contact object, similar
> to PERSON and ROLE. It does not really matter that "abuse-c:" does not
> reference a NIC Handle. As long as we have good documentation. At the
> moment "mnt-irt:" does not reference a maintainer object which can be
> confusing to users. The IRT already includes "abuse-mailbox:" and
> "e-mail:". (We can change the optional/mandatory status of these
> attributes.) We can reference it from INET(6)num and AUT-NUM. Of course
> any name change may mean users have to change some of their software.
> 
> This could be done in a phased manner. First rename the attribute and
> make it optional in the appropriate objects. Leave the existing
> "abuse-mailbox:" for a while to allow users to move them to the more
> appropriate place.
> 
> Then deprecate "abuse-mailbox:" from the other objects.
> 
> This implements the basic requirement of (moving towards) a single place
> to store abuse POC in a way that is more intuitive. While that is being
> rolled out and users start to adjust their data, the Task Force could
> move on to consider the implications of yesterdays discussion about
> hierarchies and what needs to be mandatory by syntax or required by
> business rules and formalising a policy to wrap around the whole issue.
> 
> Hope the suggestion is helpful.
> 
> regards
> Denis
> Business Analyst
> RIPE NCC Database Group
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20110503/4fe1031c/attachment.sig>