[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

[aziz halim]

Hello,
I felt the obligation to mention a very important element:
AFRINIC is issuing signed statements such as : "I declare that this address
space has not been allocated/assigned to anybody". That is our problem. It
is not at all related to AFRINIC carrying out routing. In fact, similar
statements are made in the registration database, and stakeholders have the
freedom to utilize them to adjust their router without the need of a whole
new policy, it is just useless. Nevertheless, the policy incorporating that
statement into routing tools is the reason why *RIPE dropped this policy
and described it as unnecessary. *

On the other hand, concerning data injection, the issue has nothing to do
with data, instead, injecting it into the routing tool is something that is
out of AFRINIC’s scope. Additionally, although you have the liberty to
choose whether to accept RPKI or reject it, in case the policy gets
ratified, you are clearly *accepting* RPKI with injected data, without an
option to withdraw it.

It is time we stop wasting precious time developing useless policies, while
we can be in the process of implementing coherent, useful policies.
Thank you.


On Mon, Jun 7, 2021, 17:33 aziz halim <azizlfax88 at gmail.com> wrote:


> Hello,

> I felt the obligation to mention a very important element:

> AFRINIC is issuing signed statements such as : "I declare that this

> address space has not been allocated/assigned to anybody". That is our

> problem. It is not at all related to AFRINIC carrying out routing. In fact,

> similar statements are made in the registration database, and stakeholders

> have the freedom to utilize them to adjust their router without the need of

> a whole new policy, it is just useless. Nevertheless, the policy

> incorporating that statement into routing tools is the reason why *RIPE

> dropped this policy and described it as unnecessary. *

> On the other hand, concerning data injection, the issue has nothing to do

> with data, instead, injecting it into the routing tool is something that is

> out of AFRINIC’s scope. Additionally, although you have the liberty to

> choose whether to accept RPKI or reject it, in case the policy gets

> ratified, you are clearly *accepting* RPKI with injected data, without an

> option to withdraw it.

> It is time we stop wasting precious time developing useless policies,

> while we can be in the process of implementing coherent, useful policies.

> Thank you.

>

>

> On Mon, Jun 7, 2021, 14:13 aziz halim <azizlfax88 at gmail.com> wrote:

>

>> Hello,

>>

>> I felt the obligation to mention a very important element:

>>

>> AFRINIC is issuing signed statements such as : "I declare that this

>> address space has not been allocated/assigned to anybody".  That is our

>> problem. It is not at all related to AFRINIC carrying out routing. In fact,

>> similar statements are made in the registration database, and stakeholders

>> have the freedom to utilize them to adjust their router without the need of

>> a whole new policy, it is just useless. Nevertheless, the policy

>> incorporating that statement into routing tools is the reason why *RIPE

>> dropped this policy* *and described it as unnecessary. *

>>

>> On the other hand, concerning data injection, the issue has nothing to do

>> with data, instead, injecting it into the routing tool is something that is

>> out of AFRINIC’s scope. Additionally, although you have the liberty to

>> choose whether to accept RPKI or reject it, in case the policy gets

>> ratified, you are clearly* accepting* RPKI with injected data, without

>> an option to withdraw it.

>>

>> It is time we stop wasting precious time developing useless policies,

>> while we can be in the process of implementing coherent, useful policies.

>>

>> Thank you.

>>

>> On Mon, Jun 7, 2021, 12:27 JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

>> wrote:

>>

>>> Hi Elvis,

>>>

>>>

>>>

>>> You’re confused. It is not up to the members to fix the rules, it is up

>>> to the community. Members are bound to the rules decided by the community

>>> and the members are part of the community so they take part in that

>>> decision.

>>>

>>>

>>>

>>> You also missed the part on the 6 months. AFRINIC will implement it in a

>>> slow-start phased model, so there will be ample time so initially it may be

>>> much more time for each member to have the 1st verification passed, it

>>> will all depend on how AFRINIC implements the phases. It is true that then

>>> the 2nd verification could come after 6 months, again depending on the

>>> slow approach taken by AFRINIC, but then, on the next year, AFRINIC can

>>> inform the community of the status and if necessary, update the timings.

>>>

>>>

>>>

>>> Last, but not least if in case of an abuse report, a member decides not

>>> to reply, they should just have an auto-responder, something like “we don’t

>>> respond to abuse reports” and then the rest of the world decide if they

>>> want to filter this ISP, instead of filtering all the AFRINIC community. I

>>> don’t expect smart members to do so, obviously, but they could, or they

>>> could in fact, simplify their job and automate as much as possible the

>>> handling of the abuse mailbox, so clear cases are processed automatically,

>>> other cases could be diverted to staff to handle it, and even other cases

>>> could be discarded by responding, for example “we will inform our customer,

>>> however spam is not illegal in our country and we don’t include such

>>> provisions in our customers contacts, so if they want to spam you, so be

>>> it”.

>>>

>>>

>>>

>>> Note that some of my quoted text is in irony mode. As said, I will not

>>> think a member will be doing the right thing that way, but it is their

>>> decision and the policy allows it.

>>>

>>>

>>>

>>> If you believe that the community asking to AFRINIC to enforce certain

>>> rules, it is against the Internet (not internet), then you should get

>>> disconnected from Internet, because the self-governance from the community

>>> will not be possible and then the **complete CPM** should be ignored.

>>> Note that the rules of each member internet just don’t care to the members

>>> of the rest of the community, the problem is what you do in Internet.

>>>

>>>

>>>

>>> Once more, all those points have been repeatedly responded during the

>>> discussions in the list and if I got it correctly, chairs understood that

>>> those are invalid objections, so unless there is any new objection or

>>> chairs ask me to repeat again and again the same, I don’t think I should do

>>> that, otherwise, we waste time and resources from all.

>>>

>>>

>>>

>>> Regards,

>>>

>>> Jordi

>>>

>>> @jordipalet

>>>

>>>

>>>

>>>

>>>

>>>

>>>

>>> El 7/6/21 13:06, "Ibeanusi Elvis" <ibeanusielvis at gmail.com> escribió:

>>>

>>>

>>>

>>> Hello community,

>>>

>>>

>>>

>>> I am in opposition with this policy because it is unnecessary as there

>>> is already an existing abuse contact policy that is already sufficient and

>>> functional as well.

>>>

>>> Indeed it is essential to have a mandatory abuse contact policy but

>>> having to put a 6months verification is very unrequited because it is up to

>>> the members to decide if they want to reply or not.

>>>

>>> Hence, members should have the option “not to reply”. Additionally, it

>>> is not in Afrinic’s mandate to decide or dictate how network holders manage

>>> their abuse mailbox. they have the right to determine the type of subjects

>>> they can reply and choose the adequate actions to be taken as earlier

>>> aforementioned. It also contradicts with internet values, making AFRINIC

>>> play the role of the central government.

>>>

>>>

>>>

>>> Elvis

>>>

>>>

>>>

>>> On Jun 4, 2021, at 23:56, PDWG Chair <dacostadarwin at gmail.com> wrote:

>>>

>>>

>>>

>>>

>>>

>>> Dear PDWG,

>>>

>>>

>>>

>>> This is to announce the official start of the last call period for the

>>> following policy proposal (in line with the provisions of the CPM):

>>>

>>>

>>>

>>> Abuse Contact Policy Update

>>>

>>> AFPUB-2018-GEN-001-DRAFT07

>>>

>>> URL: https://afrinic.net/policy/proposals/2018-gen-001-d7

>>>

>>>

>>>

>>> The proposal reached rough consensus at the Public Policy Meeting held

>>> 2-3 June 2021 in online format. This last call period will run for a period

>>> of two weeks as a minimum. The closing date will be communicated to the

>>> mailing list depending on the feedback received.

>>>

>>>

>>>

>>> Regards,

>>>

>>> PDWG Co-Chairs.

>>>

>>>

>>>

>>>

>>>

>>>

>>>

>>>

>>>

>>> _______________________________________________

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

>>>

>>

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