[acm-tf] Functionality

dear tf,

On Sun, May 08, 2011 at 03:50:34PM +0200, Tobias Knecht wrote:

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

maybe, but we need to keep in mind that there are different types of
users.  And there's also the subtle difference between "abuse"
and "anti-abuse", really.

> I think it is more the function of the database people to decide on a
> name for the final object.

The point i was trying to make is that the object and the attribute
referencing it don't need to (an maybe shouldd not) bear the same name.

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

If aut-num was going to allow a link to $object, the expectations for
both publishers and users need to be clearly documented.  Currently
my imagination doesn't help me to link an "abuse" case to an AS rather than
address space (or really, the route).  Of course, announcing a
wrong prefix might fall into this category, but then that would be
an operational matter (read: "tech-c") to start with.

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

I dod not suggest to copy the current strategy.  However, the claim I
heardd in A'dam and before was that publishers (mntners, ISPs) would
have difficulties to find the best, optimal, clear way to specify their
abuse contact information.  So, for us to back our requirements with
some real world observation, looking into the publishers' practices
to reverse engineer their desires isn't as good as direct input, but
lacking that still more valuable than guessing.

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

So, could we start the discussion?

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

This smells a lot like IRT and would raise the same concerns that people
are believed to have with irt today.  I'd agree that some notification
would be helpful, but then again, "copy+link" isn't much more effort than
just "link".

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

Why should someone without intent to connect to the Internet be "forced"
to publish an abuse contact?

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

How would one qualify as an "abuse department", allowing for inter-abuse
communication?  Also, "automatic complaint handling" might set the limits
for what to expect, but woul be need to defined in detail, including
formats and the like.  I think we agreed further down this email that
splitting the contacts is the best avenue into confusion, so i'm not
convinced here.

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

OK, that would be more of a "limited visibility" rather than ACL based or
volume based restrictions on queries.  The experience with "-B" was
split, I guess, since although it was expected to be used by "professionals"
only, it kind of leaked.  It appears to me that the real requirement is
to not confuse the target audience which in turn leads us to the tricky
question of who the target audiences are:

1) professional users with access to and understanding of teh DB documentation
2) semi- or pseudo professionals who are easily confused and tend to act
   as multipliers (e.g. by publishing tools)
3) web centric end users

The case (2) is hopeless. (3) is better addressed by a well designed,
web based user interface than by commandlinbe whois and (1) wouldn't need
this kind of restrictions to visibility.

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

That'd be security by obscurity and, again, experience shows that this
kind of "secret" or "expert mode" switch will be well known rather soon.

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

Agree. This information will not be subject to checking or vetting for
registration.

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

We wouldn't. By offering two (or maybe more) options, we'd just enable
them to communicate the various contact points.  But we _would_ have to
set the expectations an i have so far not seen a crisp definition that
would istinguish the two from the perspective of an end user.

-Peter