[acm-tf] Functionality

Hi,

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

That is probably true, but never the less I do not see to figure out the
true desire of what people need by looking at remark fields,
abuse-mailbox attributes and IRT Objects. The information that can be
published over these ways is exactly what we would like to improve and
not "copy" them.
Or did I get something wrong?

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

Sure. ;-)

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

Yes this smell really a lot like IRT, even if my feeling tells me at the
moment there is another better ways of doing it.

The other questions with this would be. Is this not something we would
like to see with all existing objects and not only with the
$abuse_object? If we do, we should keep exactly this out of this
discussion and bring up another proposal for all $objects in the database.


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

Is this the majority? Or are there any numbers on how many organizations
do not have the intent to connect to the Internet? If this is the
Majority this might be not the right idea.

We could as well decide that the hole ip space has to be covered with
abuse contact information. If the the direct allocations do not want to
offer it they have to force their sub allocations to publish it.

Whatever idea we will come up with, there will always be space for
discussions. So please lets keep it pragmatic and not to being to
scientific.

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

Okay lets rephrase it:

e-mail attribute: human correspondence between members of abuse dep.
abuse-mailbox: complaint mailbox

We are not splitting the contacts here. We offer the opportunity to
route communication into different channels. You do not want to receive
all the complaints and personal and/or transactional mail in one
mailbox. That does not work. That was one reason to create the
abuse-mailbox attribute a few years ago.

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

Absolutely right. Offering the -B option was just an example for people
in group 1.

"-B" is there it works and it could be reused to avoid to much code
changes in the world of abuse reporting tools.

Having a fancy webform as we already have with the abuse finder will
hopefully help groups 2 and 3. Offering a REST API as already
implemented will help people to change with the next release from "whois
-B" to REST.


At the end we will face the same problem as we do with all person or
role objects. We do not want to allow bulk queries that just look out
for email addresses that are used for human correspondence.

If we restrict the the queries for the e-mail address attributes as we
do for the hole object without the abuse-mailbox attribute. This came up
on a discussion on this topic about abuse contact information on the
mailinglist. I can not find where at the moment. Sorry.

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

The expert mode switch is not existing here. There will be no switch.
Everybody can access abuse-mailbox attributes without any restrictions.
Everybody can access all other attributes with restrictions.

No switch, no security by obscurity. Easy to understand for publishers
and users.

And we should not get into any trouble with EU legal things since we
could define the abuse-mailbox attribute as a non personal role-account.

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

Right, because imho there is none. Abuse Department, Abuse Desk,
Incident Response Team are all names for imho one and the same thing.


But to be honest I think we could keep the IRT Object plus the new
$object for a while and see how the IRT Object is doing. IMHO I think we
will not see a drastic increase of users there.

I think it would help to have Wilfrieds opinion on that, since he is
very involved into IRT using organizations as far as I understood.

I think abuse-c is from a historical view easier to understand because
of admin-c, tech-c. Every domain owner has at least once heard these
things.

The other reason for the name abuse-c is just easy to not use th already
"burned" name of IRT. When people hear about IRT, they have already
feelings about it. Most of these feelings are at the end not really
positive otherwise we would have much more than 211 IRT Objects.


Thanks for the feedback.

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/20110509/e936c4ba/attachment.sig>