[acm-tf] Functionality

Tonias, all,

On Wed, May 04, 2011 at 03:06:19PM +0200, Tobias Knecht wrote:

> I think we all agree on the following Object Functionalities:
> 
> - a good name that is easy to understand (e.g. abuse-c)

we need to distinguish between the name of the object and the name
of the attribute referencing the object.  Primary target audience
here would be the data publisher, so "abuse-c" in the referring object
looks well consistent with "admin-c" and "tech-c". The object name
itself may be "irt" or something different.  For the reader/consumer,
I believe the name of the object and attribute are of less importance.
Either people are trained enough to use port 43 whois, then they are
supposed to read documentation, or they ought to use the web whois
or even a dedicated abuse contact finder tool that should take care
of the necessary abstractions not to expose db level syntactic sugar
to the end user.

> - reference it only once from INET(6)num and AUT-NUM.

Not sure it makes sense for aut-num.  If that's the case, then what
about teh route and route6 object types?
Also, the current abuse finding tool apparently looks for remarks and URLs
in other objects, too.  It might be helpful to understand what objects
these appear in and how to translate that into requirements.

Whether or not it's a singleton attribute is an interesting question.

> - hierarchical design.

Needs clarification: does it mean the querying mechanism should be
able to locate the closest covering reference for inetnum and
inet6num objects?

> - be compatible with actual and future db design.
> - flexible

that's too fuzzy for me.

> - can not be linked by anyone to anywhere

Needs clarification: who should be asked for confirmation for a
reference this "the" object?

> - mandatory or not mandatory object

Assuming you mean the referencing attribute here, making it mandatory
might be in conlict with the hierarchical approach and would also not
too well work with an expected deployment curve.

> On a Content side we have:
> 
> - contains e-mail and abuse-mailbox attribute

What would the difference be?

> - query restriction on all attributes without abuse-mailbox attribute

Could you clarify this?

> - contain url attribute for optional website of abuse team.

I'd almots assume we want a URL for some policy description or report/
report format requirements.

We've had discussions about abuse vs incidents, but i'm split.
If we start going down that path we might end up with an enumeration
of potential abuse scenarios (spam, phish, portscan, ssh scan, dos, ...)
that will never be distinguished enough for some but will soon be large
enough to confuse the potential user.

-Peter