[acm-tf] Functionality

Hi everybody,


>> - 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.

I feel very comfotable about the name abuse-c, because everybody
understands that "c" means contact as it does in admin-c and tech-c
already. Publishers and Users.

I think it is more the function of the database people to decide on a
name for the final object. As Denis explained to me, we could use a
special type of object like an IRT Object or database people could
decide to use a role object with special rules around.

>> - 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?

Good point. Need to be discussed.

> 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.

I would avoid doing this. As we have seen and RIPE NCC got the same
feedback by users and publishers, sometimes they went a little bit to
far. The links from one object to another to another maintainer could
lead into complete wrong directions.

> 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?

That has to be discussed as well.

>> - can not be linked by anyone to anywhere
> 
> Needs clarification: who should be asked for confirmation for a
> reference this "the" object?

If somebody references your Abuse Object, you need to acknowledge or at
least be informed about. It should be avoided that everybody can link
his abuse-c attribute to any 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.

Right. We could for example decide that all direct allocations need to
have it and everything beyond will be linked to the highest level. That
way the direct allocation can force his customers as well to create it
or handle it by him self. I think this questions can not be answered
with yes or no, there is a lot of grey between.


>> On a Content side we have:
>>
>> - contains e-mail and abuse-mailbox attribute
> 
> What would the difference be?

e-mail attribute: personal correspondence between abuse departments.
abuse-mailbox attribute: only automatic complaint handling.

>> - query restriction on all attributes without abuse-mailbox attribute
> 
> Could you clarify this?

We could use query restrictions for all attributes, without the
abuse-mailbox attribute as we have it already today. That way we could
query unrestricted for example with the -b option.

That way we could meet the requirements of the community not to publish
email addresses for personal communication to widely.

>> - 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.

Right. That would be the place. And it would really be easy to check if
this URL is still valid after a while a request the maintainer to update
his data if it i not. But this is not a part of this discussion, just an
idea.

> 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.

I would not go down this road. Every organization is different. In some
organizations there are only abuse departments handling all this things.
In other they have just Incident Response Teams. So they should handle
everything as well. The only problem we are facing is a organization
that has both in place. And my experience with such organizations is
that they do not exactly know who is responsible for what, so how should
we be able to decide this.

Let's stay with abuse team, because this easy to understand and $world
does know what an abuse team is, but not necessary know what an incident
response team is. Just my feeling.


Thanks for the feedback. Are there any other functionalities that we
should think of?

Tobias



-------------- 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/20110508/4d0eb20b/attachment.sig>