[rpd] Decisions ... Abuse contact

[Jaco Kroon]

Hi,

Please refer my summary/take on the situation inline below.

On 2020/09/30 16:13, Gaby Giner wrote:

> Hi Noah, Jordi, everyone,

>

> I am confused. Everyone is raising the claim that there are "invalid"

> objections and though I do not reject that statement, it seems like

> it's being used here to automatically dismiss the objections raised by

> the community as for this policy. It was kindly summarized for us by

> the Co-chairs, and just to get everyone up to speed, here are THE

> objections to this policy:

>

> 6.       Abuse Contact Update

>

> a. /Staff analysis on how it affects legacy holder not conclusive 

> (not sure why this should affect legacy holders)/

>

Legacy holders aren't held to the CPM, and nothing in the CPM is binding
on them.  This is a problem as explained in the transfer policy thread
too.  Effectively, we cannot prescribe anything to legacy holders in any
way, and as such, legacy holders cannot be bound by this in any way.

My conclusion:  invalid.


> /b. The proposal doesn’t state what will be the consequences of one

> member fails to comply. Why are we creating the abuse contact when

> there is no consequence for not providing the abuse contact/

>

I just rechecked, I don't believe the CPM specifies consequences for any
other failures to comply, and as far as I know basically refusal to
comply can result in membership begin revoked, along with issued
resources, I may be wrong in this matter.

My conclusion: invalid.


> /c. Abuse contact email and issues with GDPR concerning the whois

> database./

>

jkroon at plastiekpoot ~ $ whois AS327767

...

this already contains a fair number of infomation covered by the GDPR
... so please explain how an abuce-c is any different?

Please note:  not saying this isn't valid, take for example whois on the
domain database where mostly everything is saying redacted nowadays
making any form of meaningful exchanges highly problematic.

Conclusion:  I don't think there is a problem here, but I'm not a
lawyer, not even in SA, never mind Mauritius where Afrinic is incorporated.


> /d. No proper definition of the term Abuse/

>

If I publish support contact details for my company - do I need to
publish a definition of the word support?

My understanding is that we've all agreed that the general definition of
what's abuse to me and to someone else will always differ.  We consider
you running a port scan against our servers abusive - yet we tolerate ~
20 of those per day currently (some of which we can link with so called
penetration testing companies who most definitely do not have the
required permission).  If someone wants to raise to us that one of our
customers is sending them spam, sure, I'll take the complaint, I'll even
acknowledge to you and I'll pass it on to my customer.  They can choose
to react to you or not, and if not, you're free to take them to court
over the matter (probably, you'll have to unfortunately issue a summons
against us to release those details to you if it's not easily deducible
from your side because else I run into POPIA / GDPR issues on my
end).  Specific example would be a violation of our AUP so we would take
more direct action.

Point is, no, I don't think the definition of the word abuse is
important, you would not think twice about publishing a definition for
support in order to publish a support contact to your customers.  You'd
simply reply to them telling them that this is outside the scope of the
support rendered to them, so in this case you can either choose to
ignore, or to respond similar.

The problem I see with defining abuse is that we end up condoning any
action initiated from any of the Afrinic member's network that's not
specifically set as abuse in whatever definition we come up with.  Let's
go very extreme, hacking into a military network for the purposes of
launching a nuke.  Obviously that'll be under "unlawful actions", which
will probably be listed as abuse in any definition of the word.  But
what if a specific country has no laws against hacking?

My conclusion:  I understand the sticky point, but I don't think it
makes one bit of difference whether such a definition is published or
not.  As such, I don't understand what relation of the word *abuse* has
when dealing whether an abuse *contact* should be published.  It's about
the contact, not the abuse.


> /e. To force members to reply to their abuse email is not in the scope

> of AFRINIC./

>

I don't believe that anybody said that  (we would like you to respond,
even if at least to tell me off for sending you an abuse complaint for
something that you don't consider abuse).  I believe that what is stated
is that Afrinic should validate that the mailbox is valid/active,
specifically, comply with proposed 8.4, so in 8.5:

AFRINIC will validate compliance with the items above, both when the
"abuse-c" and/or "abuse-mailbox" attributes are created or updated, as
well as periodically, not less than once every 6 months, and whenever
AFRINIC sees fit.

I suspect your concern is 8.4, point 2 (bullet number 4) "abuse reports
receive a response." - this doesn't preclude an auto responder.  Perhaps
some rewording of 8.4 might be in order to clarify the point, but I do
believe that a validation of the mailbox to confirm it's at least
operational is in order.

What I would be more concerned about is the definition of regularly -
does this mean daily?  weekly?  monthly?  hourly? It's fairly much
implied at least once in two weeks considering that the validation
period is 15 days (and there might be some ambiguity here in the text
now that I re-read it again, my interpretation is that from the point
where the validation email is sent, there is a period of 15 days in
order to respond and thus validate the aliveness of the mailbox, it may
be possible to interpret this as Afrinic could require you to validate
in an arbitrary time as long as said arbitrary time is less than 15
days, say 15 minutes, this clearly isn't the intent though).

As I understand, our lack of publishing of this currently results in the
behaviour described in 8.6 anyway.  In other words - Afrinic staff
currently has to deal with the lack of abuse-c in our objects.  This
just gives Afrinic something to slap members on the wrist with if
someone escalates to them anyway, an action outside of our control. 
This just gives Afrinic a response towards the member ("hey, does your
mailbox work?") and the complainer ("We have verified the contact is in
working order, plainly they don't consider your issues abuse, thank you,
good bye"), whereas currently they need to actually deal with this (I'm
sure there will still be cases they do need to deal with).

I'm inclined to ask what's the point of having an abuse contact that's
completely non-responsive?

My conclusion:  This might be a wording issue more than a fundamental
objection, maybe not.

Obviously we want validation of contact addresses, so could you please
propose alternate text/concepts that can be used here then for 8.4
through 8.6 that would be better suited?


> Okay, people have addressed several concerns such as A, C, D but I

> think B and E deserve to be raised up as well because (and maybe it is

> just me being overwhelmed with the barrage of emails lately) I haven't

> read enough rebuttal for these points. Even if one were to consider

> that they are not valid objections, one could not steamroll the policy

> into last call immediately without addressing the entirety of the

> summarized objections from the community discussion by saying that

> every objection is invalid.

>

> Gaby

>

>

> On Wed, Sep 30, 2020 at 9:23 PM Noah <noah at neo.co.tz

> <mailto:noah at neo.co.tz>> wrote:

>

>

>     On Wed, Sep 30, 2020 at 9:20 AM Madhvi Gokool <madhvi at afrinic.net

>     <mailto:madhvi at afrinic.net>> wrote:

>

>         Dear Frank/Community members

>

>

>         a) In the Impact Assessment, staff assumed that the policy

>         will not impact the legacy resources in the AFRINIC whois

>         database and requested the authors to confirm that this is

>         so.  AFRINIC staff needs to keep this in consideration at the

>         time of implementation(myafrinic and whois business rules) -

>         abuse-c mandatory for non-legacy resources. Staff were

>         therefore satisfied with this confirmation and had not

>         indicated otherwise to the co-chairs and community in the session.

>

>         b) "AFRINIC is bound by the Mauritian Data Protection Act 2017

>         (inspired by GDPR). For more information on AFRINIC's Privacy

>         Policy, click on the following link -

>         https://www.afrinic.net/privacy. Thus, implementation of the

>         abuse-c will not impact negatively on AFRINIC's data

>         protection obligations."

>

>         c) The only policy that affects the legacy resource holders is

>         documented in Section 5.7 of the CPM  - and it regards

>         transfers of legacy resources.  Legacy Holders are not bound

>         by any other resource policies.

>

>         Staff therefore will confirm with the authors that their

>         policies do not affect legacy resources , especially when

>         implementation will be done on the whois database.  This is 

>         to ensure that the implementation does not negatively impact 

>         how the legacy resource holders manage their resources on the

>         whois database.

>

>         d) In the Policy Implementation Experience Report during

>         AFRINIC-32/AIS'20 , staff have pointed out that Section 8 of

>         the CPM does not enforce a mandatory abuse contact . They also

>         mentioned that they are having to respond to an increase in

>         complaints regarding missing abuse contacts in the number

>         resources in the AFRINIC whois database and that operators

>         have warned that they will filter the resources with no abuse

>         contacts.  Staff are therefore doing the work for the members

>         , as they are bound to respond to any queries that are logged

>         with the AFRINIC service desk.  This situation is not scalable

>         in the long term & AFRINIC invites the community to also

>         ponder on this feedback.

>

>

>     Madhvi thanks for all the clarifications beyond the staff assessment.

>

>     Clearly this proposal had no valid objections, yet it was tossed

>     back to the list based on invalid definitions arguments as though

>     we are all not internet folk to understand what *abuse-c* really

>     means.

>

>     Can we move forward to the last call now.

>

>     Cheers,

>     Noah

>     _______________________________________________

>     RPD mailing list

>     RPD at afrinic.net <mailto:RPD at afrinic.net>

>     https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200930/e180ff76/attachment-0001.html>