[anti-abuse-wg] 2011-06 Review Phase Extension

Hi,

> While I agree with some of the goals of 2011-06, I object to the
> proposal in its current form.  In fact, I think it is not even ready
> for the Review Phase, even though I understand that was the way to
> invoke the NCC impact analysis.  Here's already one reason to object: the
> proposal itself is hardly comprehensible without said impact analysis
> but since the latter is not part of the proposal it can only be
> considered transient.  Without even remotely suggesting the NCC was driving
> policy here, I must say with both hesitance and regret that I am not
> comfortable with the role the NCC has been dragged into w.r.t 2011-06.

I partly agree with you. This proposal is a bit different than what RIPE 
Community and RIPE NCC is usually looking at, as far as I can remember. 
And it is sometimes tricky to fit it into the existing processes, but 
the real funny thing is that there will be a lot of proposals like this 
in future, promised

But I'm absolutely not agreeing with you about the role RIPE NCC is 
taking here. I think RIPE NCC is at the moment taking their role very 
seriously and is doing exactly what they need to do. They are consulting 
from a technical perspective which makes a lot of sense since RIPE NCC 
has to develop and maintain the system.

It was the TFs and communities wish that I rewrite the proposal and keep 
to deep technical specifications out of it and just define the feature 
set I'm looking for.

But since you have not specified what exactly you do not like at RIPE 
NCCs role at the moment it is hard to answer more specific.

> o The proposal and impact analysis are unclear about the aspects of
>    data protection issues for the "abuse-mailbox:" attribute.  It appears
>    it is intended to "by definition" avoid PII here. How would that work
>    for address space allocated (or, more importantly, assigned) to a natural
>    person?  That said, the proposal is also unclear whether the abuse-c: would
>    apply to PI space, as well.

I'm not sure if I really got your point here, but I will give it a try.

I do not see data protection issues with the "abuse-mailbox:" attribute, 
because it's clearly defined that it is not personal data. And in 
addition to that it is part of an role object, which usually should not 
contain personal data either. This is one point that was wanted by me as 
a proposer and was supported by the TF and the community, that 
information required to report security incidents must be unrestricted.

If IP space is allocated or assigned to a natural person and there is an 
abuse-c, the abuse-c should not contain the information of the natural 
person, because it is a role and not a person.

And I found this part of Denis' explanation very interesting:

"Also the original intention of the database design was to represent
people by PERSON objects and to group people into roles using ROLE
objects. Then only ROLE objects should be referenced in any other data
objects. [...] This methodology is explained in the RIPE Database Update 
Reference Manual, but was never enforced in the database software."

If this original intention would be enforced we would not have this 
conversation here and maybe this is something we should as well think of 
in the near future.


> o The proposal uses unclear language w.r.t. the mandatory nature of the
>    "abuse-c:" attribute:
>
>    ``This policy introduces a new contact attribute named "abuse-c:", that can
>    be included in inetnum, inet6num and aut-num objects. ''
>
>      vs.
>
>    ``The role objects used for abuse contact information
>    will be required to contain a single "abuse-mailbox:" attribute which is
>    intended for receiving automatic and manual reports about abusive behavior
>    originating in the resource holders' networks.''

What are we talking here about? The mandatory need of an "abuse-c:" or 
the mandatory need of an "abuse-mailbox:" attribute within the mandatory 
"abuse-c:"

"The "abuse-c:" will be mandatory for all aut-nums."

This one should be clear.

"Due the hierarchical nature of IP address objects, at least every 
direct allocated inetnum and inet6num needs to have an "abuse-c:". 
Inherited objects might have their own "abuse-c:" attribute or they will 
be covered by the higher level objects."

"abuse-c:" is mandatory for direct allocated inetnums and inet6nums. For 
all the others it is optional.

But if there is an "abuse-c:" object, no matter where it is, it is 
mandatory that it has an "abuse-mailbox:" attribute.

I do not see the confusion here.

> o The second paragraph quoted above expresses an expectation regarding the
>    handling of submitted email reports (what else would it mean to be prepared for
>    "receiving automatic and manual reports"?)

Is that a problem? Asking for an "email:" attribute in any other object 
expresses the expectation to receive mail. If you read the mail or not 
is not part of the policy and can't be forced in any way. This is 
nothing else than transferring a known and used best practice into a 
policy text. This has been done at RIPE, ARIN, ..., IETF a thousand 
times before and is imho the way to go with best practices and common 
used techniques.

> o The purpose of the "e-mail:" attribute is given with "other".  I do not
>    understand that.  I would suggest to separate the targets for 'manual' and
>    'machine readable' reports. It is natural for any object in the RIPE DB to
>    use the 'email:' attribute for email communication. {this is listed for
>    completeness; i have read the longthread on the topic and don't suggest
>    to rehash. The proposal, in summary, has bigger problems.}

The address of the "e-mail:" attribute is for communication between the 
roles and not for receiving reports. It's intended for everything other 
than reports. For example verification emails, communication between 
abuse desk of different institutions. Maybe asking questions about 
reports sent between each other. Maybe exchanging technical information 
about things and stuff.

Just for the completeness: Splitting up into different addresses didn't 
find imho consensus here, so I think this is not an option at all.

> o The proposal is unclear at least about the future of irt: objects.

Right. Because this proposals intent is not to discuss the future of the 
irt object. We mentioned that at the very beginning and in another 
thread about this subject we decided with people from the irt community 
being involved that the irt object is another topic and needs to be 
reviewed. But whatever will happen with the irt object it is not part of 
this proposal.


> o Finally, and most importantly, I object to the mandatory nature of the attribute.

The "abuse-c:" attribute or the "abuse-mailbox: attribute? Or both?

As mentioned above the "abuse-c:" attribute is only mandatory in 
aut-nums and in direct allocated inetnums and inet6nums. And I do not 
see any reason that this might be a problem since some internal 
statistics we have made show that more than 96% of the direct 
allocations have already published an abuse contact in any way and we 
were not even able to catch them all for some of the reasons we have 
discussed here.

Talking about the "abuse-mailbox:" attribute I found the other thread 
about splitting up into automatic and manual report addresses that 
people are comfortable with the idea of a mandatory "abuse-mailbox:" 
attribute. It also makes a lot of sense for me, because the 
"abuse-mailbox:" attribute is already known and used for this purpose, 
just in a little confusing way.

So I'm really interested in hearing more reasons for your objection here 
no matter if you are talking about the "abuse-c:" or the 
"abuse-mailbox:" attribute.


>    Neither the impact analysis nor the counter arguments section assess the impact
>    of presence of an abuse (role) object and the resulting actions on maintainers/...
>    LIRs/NCC members.

We have discussed these things here on the list and as far as I can 
remember we were able to handle counter arguments, such as the mandatory 
"abuse-c:" for "all" inetnums and inet6nums by changing the policy text. 
Same with the irt object, which will be reviewed in another step.

At the moment I can't remember more than these things, but people who 
came up with these concerns have later on agreed that their concerns 
have been heard and solved by changing the policy text, that's why we do 
not have any more concerns that found a majority and have been accepted 
as concerns on this list.

And I would like to stay on this path and rather find solutions to 
objections that make sense and find consensus within the community than 
mentioning them as objections and keep them as objections in the proposal.

Thanks for your input and I hope I was able to clarify some things.

Tobias