[rpd] Decisions ... Abuse contact

[Lamiaa Chnayti]

Hey Jordi,


What part of the complete solution are you offering? You are making
operational matters into policy, and making AFRINIC check each
member’s reply email is not called a complete solution but simply an
overreach.


Regards,

Lamiaa


Le mar. 6 oct. 2020 à 09:21, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>
a écrit :


> Hi Lamiaa,

>

>

>

> Your proposal is approaching just a tiny part of the problem, that’s why

> you can do in a single sentence.

>

>

>

> Obviously, if I can do something in a single sentence, I will prefer that,

> but it is not the case.

>

>

>

> Mine is approaching the complete problem. It is based on actual facts and

> experience in other RIRs.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 5/10/20 11:11, "Lamiaa Chnayti" <lamiaachnayti at gmail.com> escribió:

>

>

>

> Hi Jordi,

>

>

>

> If we can make the overall policy simpler and easier to understand as well

> as to implement, why shouldn’t we do that?

>

>

>

> If we are able to express our opinion on policy in one short sentence

> precisely (and perhaps deleting the whole CPM), I will prefer to use the

> “one-sentence” version provided that we can achieve the same goal.

>

>

>

> Your policy involves operational matters which should be left to the staff

> to decide. By contrast, my proposal (which I published a few days ago)

> makes abuse-c in line with any

>

> other mandatory contact attribute in the whois database. This makes the

> overall CPM much easier to understand and to implement.

>

>

>

> The entire section 8 is not needed because so far no one has provided the

> reason why we should treat abuse-c different from tech-c and admin-c. The

> current policy text for tech-c and admin-c works well for years, isn’t it

> much easier if we simply let abuse-c follow them?

>

>

>

> Regards,

>

>

>

> Lamiaa

>

>

>

> Le ven. 2 oct. 2020 à 12:45, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

> a écrit :

>

> Hi Lucilla,

>

>

>

> I understand that, but then we also need to reword section 8, so in my

> opinion it is much simpler to touch only one section instead of two.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 2/10/20 13:40, "lucilla fornaro" <lucillafornarosawamoto at gmail.com>

> escribió:

>

>

>

> Dear Jordi,

>

>

>

> I know that the proposal is improving existing section 8, not 7.5. I said

> that, in my opinion, amending the section 7.5.1 to include the mandatory

> abuse-c as part of whois registration would be a better option.

>

>

>

> regards,

>

>

>

> Lucilla

>

>

>

> Il giorno ven 2 ott 2020 alle ore 17:26 JORDI PALET MARTINEZ via RPD <

> rpd at afrinic.net> ha scritto:

>

> Hi Lucilla,

>

>

>

> The proposal is not doing what you say below. Madhvi already confirmed

> that. If the staff is understanding it and the staff will be the one

> implementing it, who come it can be wrong?

>

>

>

> The subject, what is an abuse, what not, is not in scope. You just need to

> have a valid and responsible abuse contact. If you decide to respond

> automatically even without checking the content neither subject, it is just

> fine. It is up to the operator to decide and then the victims can also

> decide.

>

>

>

> Note that the proposal is improving existing section 8, not 7.5.

>

>

>

> I think it is superfluous to explain over and over. You think the proposal

> is wrong, I think is right and I justified it (see the appeal document for

> more exhaustive details, no need to repeat everything again if it is

> already very well documented), and the staff is doing the same

> interpretation as the proposal intent.

>

>

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 1/10/20 14:34, "lucilla fornaro" <lucillafornarosawamoto at gmail.com>

> escribió:

>

>

>

> Dear Jordi, dear all

>

>

>

> as you mentioned several times, the staff don’t need to assess the subject

> line, neither if it is abuse or not. Then, if having a valid contact is

> what you intend to propose, why don't you acknowledge Lamiaa’s proposal

> that aims to include abuse-c as part of whois registration under the

> section 7.5.1 "Registering contact persons" that already covers the other

> mandatory contact - admin-c or tech-c?

>

>

>

> See my comments in line:

>

>

>

>

>

> Il giorno lun 21 set 2020 alle ore 19:34 JORDI PALET MARTINEZ via RPD <

> rpd at afrinic.net> ha scritto:

>

> Hi Lucilla,

>

>

>

> The policy only needs to state **what the staff should evaluate** and

> thus, what members should do. The staff don’t need to evaluate the subject

> line, neither if it is actually an abuse or not.

>

>

>

> The staff just need to evaluate the abuse mailbox works.

>

> If you do not define or give an input

> of what abuse is, then how can you properly manage people's mailbox's subject line?

> How you define it works? You are asking them to respond to emails in

> a specific way, which is a violation of member’s rights.

>

>

>

> In fact, there is **no obligation** for the victim to know what should he

> put in the subject line. You can just put “abuse case”.

>

>

>

> In fact, if you operate a network, you will know that this is usually

> managed by a ticket system and the ticket system will replace the subject

> with a case number!

>

> It will, but the problem is how this complicated policy is trying to

> achieve something really simple but using a too intrusive method.

>

>

>

> Please, let us know how you do in the networks that you operate, so we can

> understand your perspective.

>

> Yes, if it were me, I would reply to every abuse and deal with even DMCA

> claims, however, we are discussing general policy regarding how internet

> space should be registered, not how to manage an individual network.

>

> You are keeping mixing up “best operation practice” with “internet number

> registration policy”, and you keep telling people what is BOP should be in

> the policy, and that is wrong. The policy is for proper registration only,

> for the accuracy of the database, using BOP into policy is not only

> intrusive but also potential dangers.

>

>

>

> And last, even if this has been responded several times: The proposal

> doesn’t tell AFRINIC that they should judge if it is an abuse or not!

>

>

> But you tell them to judge what email operator should reply to! That is even worse!

>

>

>

>

> And yes, it is in the scope of AFRINIC to have the contacts accurate and

> to manage correctly the resources. Please read the legal documents!

>

>   No, it is not. Legal documents are made by lawyers, and it is for the

> Afrinic limited, not for community. It is the AFRINIC community which

> defines what to do.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 21/9/20 12:00, "lucilla fornaro" <lucillafornarosawamoto at gmail.com>

> escribió:

>

>

>

> If you do not define or give an input of what abuse is, then how can you

> properly manage people's mailbox's subject line?

>

> This is a crucial element, in my opinion.

>

>

>

> More importantly, the proposal aims to supply AFRINIC of something that

> has nothing to do with its scopes. It is not up to AFRINIC to rule like a

> local court or local policy.

>

> As mentioned several times, asking AFRINIC to act as a central government

> goes against the main element that identifies the Internet:

> decentralization. The Internet is controlled by many, no one can own it,

> control it, or switch it off for everyone.

>

>  AFRINIC should not evaluate how I manage MY mailbox.

>

>

>

> Lucilla

>

>

>

> Il giorno lun 21 set 2020 alle ore 14:33 Frank Habicht <geier at geier.ne.tz>

> ha scritto:

>

> Dear chairs,

>

> On 21/09/2020 03:04, ABDULKARIM OLOYEDE wrote:

> > 6.       Abuse Contact Update

> >

> > The proposal makes it mandatory for AFRINIC to include in each resource

> > registration, a contact where network abuse from users of those

> > resources will be reported.  The proposal whois DB attribute (abuse-c)

> > to be used to publish abuse public contact information. There’s also a

> > process to ensure that the recipient must receive abuse report and that

> > contacts are validated by AFRINIC regularly. However, there some

> > opposition to the proposal there are:

> >

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

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

> >

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

> >

> > c.                   Abuse contact email and issues with GDPR concerning

> > the whois database

> >

> > d.                  No proper definition of the term Abuse

> >

> > e.                  To force members to reply to their abuse email is

> > not in the scope of AFRINIC.

> >

> > Chairs Decision: No rough consensus

>

> About d. "No proper definition of the term Abuse"

> yes, this was mentioned several times by members opposing.

> The proposal is about "abuse contacts". it is not about what "abuse" is.

> there is no need for a definition of "abuse".

> In my humble opinion the request for a definition of abuse is off-topic.

>

> Question: if someone makes a proposal about lame DNS servers in domain

> objects for Reverse-DNS, and I object arguing that a definition of RPKI

> is needed - what would you do with this argument?

> Q2: can arguments about a proposal be irrelevant to this proposal?

> Q3: was that the case here? were arguments, that a definition for abuse

>     is required, irrelevant?

>

> I request chairs' response to Q2 and Q3.

>

>

> About e. "To force members to reply to their abuse email is not in the

> scope of AFRINIC."

> Yes, that was mentioned several times.

> And also this is something the proposal does not do and does not attempt.

> And all the comments about (d.) above apply.

>

>

> If irrelevant objections are taken as valid arguments, please note that

> I foresee that any future proposal can get rejected and the PDP will be

> stuck.

>

>

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

> database"

> - I didn't see that on the mailing list, can you remind us, or was that

> only during the live session?

> - there are other contact information in whois. can staff confirm

> whether AfriNIC are GDPR compliant?

> - would that status change if abuse contacts would be added?

>

>

> About 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 can imagine that AfriNIC would include in their meeting

> presentations information regarding how big (in measurable terms) this

> problem is.

> - from that the WG can discuss and decide if more actions are necessary.

>

>

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

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

> I didn't see that before, but as is tradition in my part of the world,

> let me respond to the question with a question:

> Are legacy holders subject to any for the PDWG's policies?

>

>

> Thanks,

> Frank

>

> _______________________________________________

> RPD mailing list

> 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

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com

> The IPv6 Company

>

> This electronic message contains information which may be privileged or

> confidential. The information is intended to be for the exclusive use of

> the individual(s) named above and further non-explicilty authorized

> disclosure, copying, distribution or use of the contents of this

> information, even if partially, including attached files, is strictly

> prohibited and will be considered a criminal offense. If you are not the

> intended recipient be aware that any disclosure, copying, distribution or

> use of the contents of this information, even if partially, including

> attached files, is strictly prohibited, will be considered a criminal

> offense, so you must reply to the original sender to inform about this

> communication and delete it.

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com

> The IPv6 Company

>

> This electronic message contains information which may be privileged or

> confidential. The information is intended to be for the exclusive use of

> the individual(s) named above and further non-explicilty authorized

> disclosure, copying, distribution or use of the contents of this

> information, even if partially, including attached files, is strictly

> prohibited and will be considered a criminal offense. If you are not the

> intended recipient be aware that any disclosure, copying, distribution or

> use of the contents of this information, even if partially, including

> attached files, is strictly prohibited, will be considered a criminal

> offense, so you must reply to the original sender to inform about this

> communication and delete it.

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>

>

> **********************************************

>

>

> IPv4 is over

>

>

> Are you ready for the new Internet ?

>

>

> http://www.theipv6company.com

>

>

> The IPv6 Company

>

>

>

>

>

> This electronic message contains information which may be privileged or

> confidential. The information is intended to be for the exclusive use of

> the individual(s) named above and further non-explicilty authorized

> disclosure, copying, distribution or use of the contents of this

> information, even if partially, including attached files, is strictly

> prohibited and will be considered a criminal offense. If you are not the

> intended recipient be aware that any disclosure, copying, distribution or

> use of the contents of this information, even if partially, including

> attached files, is strictly prohibited, will be considered a criminal

> offense, so you must reply to the original sender to inform about this

> communication and delete it.

>

>

>

>

>

>

> _______________________________________________

>

> RPD mailing list

>

> RPD at afrinic.net

>

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

>

> --

>

> Lamiaa CHNAYTI

>

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com

> The IPv6 Company

>

> This electronic message contains information which may be privileged or

> confidential. The information is intended to be for the exclusive use of

> the individual(s) named above and further non-explicilty authorized

> disclosure, copying, distribution or use of the contents of this

> information, even if partially, including attached files, is strictly

> prohibited and will be considered a criminal offense. If you are not the

> intended recipient be aware that any disclosure, copying, distribution or

> use of the contents of this information, even if partially, including

> attached files, is strictly prohibited, will be considered a criminal

> offense, so you must reply to the original sender to inform about this

> communication and delete it.

>

> _______________________________________________

> 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/20201007/d449e516/attachment-0001.html>