[rpd] Policy Compliance Dashboard - AFPUB-2020-GEN-001-DRAFT01

[Gaby Giner]

Hi Jordi,


So I read this particular thread, and I think most of the sentiments here
are somewhat similar to my own reservations. Particularly, there may not be
a human element to the system as the policy wants to "automate as much as
possible". In this particular setup, without a human element to the system,
it would be easy to overlook mistakes that the automation has made, and who
would check it?


You have addressed it in your last paragraph by saying that the policy
solves the *verification* part. However, is there no human element after
the verification or the notification of a violation? Just to confirm that
it is indeed a violation? I know this is splitting hairs already (as you
said there is no perfect proposal, but we do need to start somewhere), but
the more nuanced members of the community may appreciate an answer to this.


Secondly, reading this, a question in my mind has formed. How many times
can a member violate the rules before they are turned out under this
policy? The policy mentioned "repeat offenders" or continuous policy
violators but no specific number. Is it based on the gravity of the
offense? How would the system rate the offenses?


Thank you for your responses.


Sincerely, Gaby.


On Mon, Sep 14, 2020 at 3:34 PM JORDI PALET MARTINEZ via RPD <
rpd at afrinic.net> wrote:


> Hi Ibeanusi,

>

>

>

> I don’t want to repeat myself in the same arguments, so very short. This

> proposal is doing what you ask for “strengthening and improving the actual

> systems”. The policy is clear: nobody needs to check the dashboard, it is

> just a way to visualize it, but note the only one, because automated alerts

> are generated.

>

>

>

> Exceptionalities are required, otherwise, what you do it a country

> suddenly can’t pay the bills because a pandemic or war? According to the

> RSA, the resources will then be recovered, and this can’t be reverted. Do

> you want to add pain to that country closing down the Internet? The board

> is taking those decisions according to this proposal, is the right thing to

> do.

>

>

>

> Everything should be automated as much as possible, but this doesn't mean

> that the relevant actions in case of continuous policy violations are also

> automated. They need to be considered by humans, not automation. So, what

> the policy solves is the “verification” part.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 13/9/20 17:38, "Ibeanusi Elvis" <ibeanusielvis at gmail.com> escribió:

>

>

>

> Hello,

>

>

>

> Concerning this proposal on Policy Compliance Dashboard, I concur to the

> ideology that instead of reinventing or conjuring up a new policy,

> strengthening and improving on what is already in existence and functional

> is a better and affordable alternative. Likewise, there are no guarantees

> that this policy compliance dashboard will be checked regularly. In

> addition, the provision of exceptionalities can become a loophole that

> members can utilize to justify their issues of non-compliance with the

> AFRINIC policies especially in the African region where instability of

> government seems to be a recurrent issue with some countries.

>

>

>

> Also, exceptionalities like civil wars and pandemic are unpredictable.

> Similarly, if everything should be automated as much as possible, why will

> there be an initiation of an exhaustive investigation on the lack of

> compliance when the automation is supposed to handle it. Strengthening the

> staff to carry out this exhaustive investigation from the get go is

> better. I propose we modify and reinforce the functional system than waste

> resources, time and unnecessary workforce on making an automated model of

> what we have.

>

>

>

> Best regards,

>

> Ibeanusi Elvis .C.

>

>

>

> On Sun, Sep 13, 2020 at 5:39 PM JORDI PALET MARTINEZ via RPD <

> rpd at afrinic.net> wrote:

>

> Hi Greg,

>

>

>

> We shall remember that the impact analysis is the initial interpretation

> from the staff, not necessarily the correct one. Sometimes, it becomes

> clear once the policy is presented and reach consensus, either thru new

> versions if there are unrefuted objections, or via editorial changes or

> just clarifications.

>

>

>

> In this specific case, the proposal is not saying anything about “Any new

> policy proposals that will be proposed shall also indicate clearly any

> elements of non-compliance that shall then be incorporated in the

> dashboard”, because this is NOT needed.

>

>

>

> If any text in the CPM says “you can’t do x” and you to otherwise, clearly

> there is a policy violation. The proposed policy indicates to the staff

> “please, whenever possible, try to automate that x is automatically

> verified”. The text is NOT saying at all “every policy should state what

> needs to go into the dashboard”. This is left to the operational decisions

> of the staff, so NO, there is no list to maintain also because in section

> 2, we have this “The dashboard automation will need to be accommodated

> along CPM evolves thru the PDP, in order to display new details.”

>

>

>

> I hope all that is clearer?

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 12/9/20 22:13, "Gregoire EHOUMI" <gregoire.ehoumi at yahoo.fr> escribió:

>

>

>

> Hi Jordi,

>

>

> As you can see in the staff analysis, I quote  “ Any new policy proposals

> that will be proposed shall also indicate clearly any elements of

> non-compliance that shall then be incorporated in the dashboard.”

>

> The “such as” list in Section 3(2) Policy Compliance Dashboard, become a

> list to maintain.

>

> What I meant by “policy context evolution over time” is to not try to

> prescribe the non-compliance scenario the dashboard shall apply to as the

> context evolves.

> Non-compliance shall follow application policies and RSA

>

>

> Thanks,

> --Greg

>

>

>

>

>

> -------- Original message --------

>

> From: JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

>

> Date: 2020-09-09 6:43 a.m. (GMT-05:00)

>

> To: rpd at afrinic.net

>

> Subject: Re: [rpd] Policy Compliance Dashboard -

> AFPUB-2020-GEN-001-DRAFT01

>

>

>

> Hi Gregoire,

>

>

>

> Let’s see the analysis impact to understand if it is too much

> prescriptive, I don’t think so.

>

>

>

> Policies always have impact on operations, this is normal. We don’t want

> to define up to the last letter of the procedures, just goals, and I think

> the actual text of the proposal is doing well on that direction, and at the

> same time protecting the community against bad practices or to restrictive

> interpretations of the staff of the RSA. Remember that according the RSA,

> if you fail, even by mistake, you lose. This is not right, it must be, in

> general, a persistent failure to comply with policies.

>

>

>

> I don’t understand your last point “allow the compliance to apply to

> policy context evolution over time”. I think this is precisely what we are

> doing with the actual text. May be there is something that needs to be

> reworded to make it more clear?

>

>

>

> Regards,

>

> Jordi

>

>

>

>

>

>

>

> El 27/8/20 6:04, "Gregoire EHOUMI" <gregoire.ehoumi at yahoo.fr> escribió:

>

>

>

> Thanks Jordi for the responses.

>

>

>

> Let not miss the essences of my comments which are :

>

>

>

> - let staff do what fall under operation

>

>

>

> - be less prescriptive to avoid interpretations and give AFRINIC the

> flexibility to take necessary actions when appropriate

>

>

>

> - allow the compliance to apply to policy context evolution over time.

>

>

>

>

>

> —Greg

>

>

>

>

>

> On Aug 26, 2020, at 5:00 PM, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

> wrote:

>

>

>

> Hi Gregoire,

>

>

>

> Sorry, totally missed this email. I could not find it in my inbox, don’t

> know the reason …

>

>

>

> Tks for your inputs and see my responses below, in-line as [Jordi].

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 26/8/20 22:11, "gregoire.ehoumi" <gregoire.ehoumi at yahoo.fr> escribió:

>

>

>

> Hello Jordi and co-authors,

>

>

>

> See my email below, in case you missed it.

>

>

>

> Best regards,

>

> — Greg

>

>

>

> On Aug 12, 2020, at 3:32 PM, Gregoire EHOUMI via RPD <rpd at afrinic.net>

> wrote:

>

>

>

> Jordi and team,

>

> Thanks for putting together this proposal. Review of usage of distributed

> resources is an important instrument to assess how we collectively assume

> the responsibilities associated to the right to use the numbers. It also

> helps assess effectiveness of our policies and ease their evolution.

>

> Below are few questions to help clarify some aspects and improve the

> proposal.

>

> 1- ######

> Section 2 Summary of how this proposal addresses the problem

>

> “Considering the exhaustion of IPv4, recovered/returned IPv4 resources are

> placed at the end of the actual pool. However, other resources are

> quarantined for a period of 2 years. This way, the staff can take measures

> to ensure that all the resources are as clean as possible, before being

> allocated/assigned again.”

> #####

> why no provision for quarantine and clean of v4?

>

> [Jordi] We have no more IPv4 resources. If we set a quarantine period in

> the policy, it will be mandatory and people willing to receive them need to

> wait, or we need to send a policy proposal to change it again. At the

> moment there is already an internal procedure that does that. The internal

> procedure could be modified if needed. The policy text needs more time to

> achieve the same. Why you want to quarantine resources that may be “clean”

> or “needed even if not 100% clean”?

>

>

> 2- ######

> Section 3(2) Policy Compliance Dashboard

>

> “Contractual obligations (such as status of payments or documents).

> Lack of response from the member.

> Unused or unannounced resources (where mandatory).

> Unavailable or outdated Whois information.

> Lack of maintenance of the reverse delegation.

> Forbidden sub-assignments (from PI assignments).

> Unauthorized transfers.

> Tracking of repeated and/or continued policy violations.”

> ######

>

> How is list on compliance measures evolved? Is it that every new policy

> specify dashboard impact and what to measure in order to assess compliance?

>

> [Jordi] The list is “such as”, so just examples of what we believe are the

> starting points. But the dashboard proposal sets only the framework, so the

> staff can do the same with every possible CPM/RSA aspect that can be

> automated.

>

>

> 3- ######

> 3(3) Notifications

>

> “The dashboard will automatically send notifications of the status of

> compliance to members, after each review or dashboard update. “

> ######

> With what periodicity are members reviewed?

>

> [Jordi] Being automated, the idea is that it is “continuously run”. It is

> difficult to set specific periodicity, because it may take just hours to

> check “again” if resources are announced (an example), vs another different

> “test” that may need weeks to re-check the status of all the members. There

> may be operational decisions, such as “even if we can test this every week,

> do we really need to do at that speed” (AFRINIC DC bandwidth, members

> bandwidth, computational and power resources, etc.).

>

>

> 4- ######

> 3(4) Lack of Compliance

>

> “AFRINIC will be able to initiate a more exhaustive investigation and take

> further actions, according to the RSA, when there is evidence suggesting

> that there is a lack of compliance. “

> ######

>

> This should not overrule Afrinic right to investigate and take action

> under RSA at anytime

>

> [Jordi] And is not the case. RSA is **on top** of CPM when relates to

> member obligations. However, the CPM can reinforce the compliance with the

> RSA.

>

>

> 5- ######

> 3(5) Service Withholding, Revocation or Member Closure

>

> “Unauthorized transfers, lack of payment or document fraud, once

> confirmed, will be cause of the revocation of the services and member

> closure. “

> ######

>

> Are these the only conditions for revocation? What about other provisions

> in RSA eg fraud, misrepresentation, abuse or other acts contrary to RSA etc?

>

> [Jordi] As said above. RSA is **on top**. This is not changing the RSA.

> We, considered that those are key aspects that should be protected by the

> community (via the CPM) in case the RSA is not doing that already.

>

>

> 6- ######

>

> “f. All other provisions specified in the RSA and Bylaws will apply.”

>

> ######

> Why other provisions only? Should be all provisions apply as Afrinic

> should not loose any of its powers in RSA and bylaws

>

> [Jordi] This is an informative/clarifying text, we could even omit it and

> the result is the same. Even if we don’t say that, when a member signs the

> RSA, is being obligated by the bylaws, and the RSA, and **anything**

> indicated in those documents. Those “other documents”, can changed over the

> time, as that is a board/membership decision and the CPM is not affected by

> that. If we have an explicit mention of other document in the policy, it

> may become “broken” if “other documents” change.

>

>

> 7- ######

> 3(9) Use of Recovered or Returned Resources

>

> “IPv4 resources will be incorporated at the “end” of the pool in force at

> the time of the recovery or return, for use in the order in which they have

> been added to that pool. “

> ######

>

> Why treating v4 resources differently and prescribing a queuing policy? Is

> this not better to leave to staff to manage?

>

> [Jordi] As said before, this leaves to the staff to manage it, but I

> think, it is obvious that it should be re-used, as they are recovered (you

> recover, clean if needed, quarantine if needed, put them back into the

> appropriate pool). See the mention of RFC7020 which allows that staff to

> adapt this if needed.

>

>

> 8- ######

> “The IPv6 and ASN resources will be incorporated into their respective

> pools, after 2 years of their recovery or return. “

> ######

>

> Why 2 years quarantine for v6 and a queuing policy for v4?

>

> [Jordi] Because there is no lack of ASN and IPv6 resources. So, it is the

> easier way to handle it. However see the mention of RFC7020 section 2, that

> allows the staff  …

>

>

> 9- ######

> section 3(6)..

> "When the revocation of resources involves essential strategic

> infrastructure that is necessary for the operation of the Internet in the

> region, or in exceptional situations such as natural disasters or political

> instability, the AFRINIC Board may extend the resource revocation period"

> ######

>

> What is the definition of “essential strategic infrastructure” ? How long

> may the board extend the revocation period?  And what actions the parties

> must take during this period?

>

> As for the exceptional situations, can we leave them to be handled by

> staff as they deal with in normal operation?

>

> [Jordi] I understand that those strategic infrastructures are well defined

> (ccTLDs, IXPs, etc.). We believe that is better not to try to redefine it,

> and leave to the board. Otherwise we enter into a discussion nightmare

> about how much time, what is strategic and what not, etc. In every

> exceptional situation, because it is exceptional, need to be considered by

> the board. The staff will suggest the board what to do, but it should be up

> to the membership representation (the board) to formally decide on that.

>

>

> HTH

>

> - Greg

>

>

>

>

>

> -------- Original message --------

>

> From: JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

>

> Date: 2020-08-05 5:58 a.m. (GMT-05:00)

>

> To: rpd at afrinic.net

>

> Subject: [rpd] Policy Compliance Dashboard - AFPUB-2020-GEN-001-DRAFT01

>

>

>

> Hi all,

>

> I will like to know if anyone has any inputs for the proposal "Policy

> Compliance Dashboard" (Draft1) - AFPUB-2020-GEN-001-DRAFT01.

>

> https://www.afrinic.net/policy/proposals/2020-gen-001-d1#proposal

>

> It will be also good to get at least, a draft impact analysis from the

> staff. Even if it is not a complete/formal one it will be fine, just the

> key points/issues that they want to consider, if any.

>

> It is not nice to get issues presented the same day that we should reach

> consensus, when we have the opportunity, several weeks ahead, to resolve

> them!

>

> Those inputs, could be used to improve this version if we get them during

> this week or early next one, so we have an updated version to be presented

> in the on-line PPM.

>

> So please, provide your comments.

>

> Tks!

>

> Regards,

> Jordi

> @jordipalet

>

>

>

>

>

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

> 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

>

> _______________________________________________

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

>

>

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

> 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

>

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