Search RPD Archives
[rpd] AFPUB-2019-V4-003-DRAFT02 - Resource Transfer Policy
Fernando Frediani
fhfrediani at gmail.com
Tue Sep 29 01:43:30 UTC 2020
If it is like what you are saying and there is nothing being swept under
that carpet then why the author just don't change the text back to what
it was originally and concentrate on other main points ? Otherwise it
will still be clear it was changed at the last minute on propose and
without much explanation reason why there is so much going on about
something that you call "out of scope". If it's out of scope then leave
as it was originally.
It is inexplainable, strange and really concerning and suddenly people
saying "please don't touch this". Doesn't make sense at all.
On 28/09/2020 22:36, Ibeanusi Elvis wrote:
> @Fernando,
>
> The scope of this proposal is to deal with the issue of Inter-RIR
> Resource Transfer and as outlined by various people in the community
> on some concerns and complications which has been duely addressed and
> revised by the authors @Taiwo and @Anthony for the greater good of the
> AFRINIC community and region.
> There is nothing like sweeping this under the carpet but rather this
> legacy status dilemma should have a dedicated legacy policy of its own
> or to resolve this legacy status barrier, having a service level for
> the legacy holders at numerous levels based on the fees paid for
> services is another way to solve the issue. Either way, the legacy
> status dilemma won’t be forgotten or swept under the carpet.
>
> Elvis.
>> On Sep 29, 2020, at 10:14, Fernando Frediani <fhfrediani at gmail.com
>> <mailto:fhfrediani at gmail.com>> wrote:
>>
>> How can the legacy status be out of the scope if this proposal is
>> exactly changing the opposite way it has been so far and is in
>> several other places.
>> We cannot sweep it under the carpet and try to hide from this topic.
>> If this keeps the way was changed at the last minute it must be
>> brought back to discussion as it was a major change that cannot be
>> simply ignored and "left for later".
>> Fernando
>>
>> On 28/09/2020 21:20, Ibeanusi Elvis wrote:
>>> Dear Taiwo and everyone,
>>>
>>> I believe your revision with the proposal and also the ejection of
>>> the section 5.7.5 will resolve the complications that the proposal
>>> might have brought about as pointed out by some in the RDP Community.
>>>
>>> Likewise, the revision of section 5.7.3.1 from "the compliance with
>>> the policies of receiving RIR” to “in compliance with the relevant
>>> policies”, hence, making the Inter-RIR transfer of resources smooth
>>> and efficient. And as pointed out the legacy status management is
>>> out of the scope of this policy proposal. The proposal to formulate
>>> a service level for legacy holders at various levels in accordance
>>> with the fees paid is a tremendous idea.
>>>
>>> Thanks.
>>> ELVIS.
>>>
>>>> Dear Taiwo,
>>>>
>>>> Thank you for your revision, I think that removing section 5.7.5
>>>> solves most of the issues claimed by some members, it would be
>>>> better to leave operational matters to the staff.
>>>>
>>>> Also, I agree that the legacy status management is out of the scope
>>>> of this policy proposal, it would be appropriate to discuss it on a
>>>> different proposal and/or take the RIPE NCC as evidence/source.
>>>>
>>>> Regards,
>>>>
>>>> Lucilla
>>>>
>>>> Il giorno mar 29 set 2020 alle ore 04:42 Taiwo Oyewande
>>>> <taiwo.oyewande88 at gmail.com <mailto:taiwo.oyewande88 at gmail.com>> ha
>>>> scritto:
>>>>
>>>> Dear Jordi:
>>>>
>>>> Thank you for your feedback, and both of us have been taking it
>>>> seriously.
>>>>
>>>> Please see our reply to your point:
>>>>
>>>> We agree with your point that we should make an editorial
>>>> change for the following:
>>>>
>>>> Firstly, for 5.7.3.1, from
>>>> The source must be the current rightful holder of the IPv4
>>>> address resources registered with any RIR, and shall be in
>>>> compliance with the policies of the receiving RIR, and shall
>>>> not be involved in any disputes as to the status of those
>>>> resources.
>>>>
>>>> To
>>>>
>>>> The source must be the current and rightful holder of the IPv4
>>>> address resources registered with any RIR, in compliance with
>>>> the relevant policies, and shall not be involved in any
>>>> disputes as to those resources' status.
>>>>
>>>> And for 5.7.4.1, from
>>>>
>>>> A transfer from another RIR to AFRINIC requires a need-based
>>>> evaluation. AFRINIC must approve the recipient's need for the
>>>> IPv4 number resources. In order for an organization to qualify
>>>> for receiving a transfer, it must first go through the process
>>>> of justifying its IPv4 resource needs before AFRINIC. That is
>>>> to say, the organization must justify and demonstrate before
>>>> AFRINIC its initial/additional allocation/assignment usage, as
>>>> applicable, according to the policies in force.
>>>> A transfer from AFRINIC to another RIR must follow the policy
>>>> of the receiving RIR.
>>>>
>>>> To:
>>>>
>>>> A transfer from another RIR to AFRINIC requires a need-based
>>>> evaluation. AFRINIC must approve the recipient's need for the
>>>> IPv4 number resources. In order for an organization to qualify
>>>> for receiving a transfer, it must first go through the process
>>>> of justifying its IPv4 resource needs before AFRINIC. That is
>>>> to say, the organization must justify and demonstrate before
>>>> AFRINIC its initial/additional allocation/assignment usage, as
>>>> applicable, according to the policies in force.
>>>> A transfer from AFRINIC to another RIR must follow the relevant
>>>> policies.
>>>>
>>>> As for 5.7.3.3 and 5.7.4.2, we do not see the necessity to
>>>> remove them, and we believe it actually makes the policy clearer.
>>>>
>>>> We agree in removing section 5.7.5, as we recognize that this
>>>> is out of the policy's scope, and operational matters should be
>>>> left to the staff.
>>>>
>>>> And we will also correct the grammar mistake of 5.7.3.2.
>>>>
>>>> 5.7.3.2 Source entities are not eligible to receive any further
>>>> IPv4 allocations or assignments from AFRINIC for a period of
>>>> twelve (12) months after a transfer is approved.
>>>>
>>>> As for the legacy space part, we believe that at this moment,
>>>> compatibility is the most essential aspect since both ARIN and
>>>> RIPE have a transfer policy that indicates legacy space remains
>>>> legacy.
>>>>
>>>> We consider legacy status management as out of the scope of
>>>> this policy proposal. We suggest you to (or anyone who feels
>>>> the need) propose a service level to legacy holders at
>>>> different levels regarding the fees they have been paying.
>>>>
>>>> If you think this’s necessary, perhaps you can take reference
>>>> from RIPE NCC’s legacy policy: (see
>>>> https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders
>>>> <https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders>
>>>> ), and we hope that you recognize that this is a minor
>>>> objection. We have addressed it by inviting you to propose a
>>>> more comprehensive legacy solution to the community but not
>>>> forcefully done in the transfer policy, just like the other
>>>> regions did not.
>>>>
>>>> Should the Chair allow, we would address the above point raised
>>>> by you before passing the last call.
>>>>
>>>> Kind regards
>>>>
>>>>> On 28 Sep 2020, at 12:37, JORDI PALET MARTINEZ via RPD
>>>>> <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> I don’t disagree that we need one. That’s why I was the first
>>>>> one to work on this matter. And as said, I will be happy to
>>>>> support this **one** or **any** proposal **if** it is
>>>>> functional, not if will make us waste our time because other
>>>>> RIRs will say “I’m not going to use your procedure, we, the 4
>>>>> other RIRs have already one in place. Are you going to cover
>>>>> our cost for developing a special procedure with you?”, not to
>>>>> say that the text has some wording that is not coherent. I
>>>>> just don’t want to keep repeating my points. I think they are
>>>>> very objective.
>>>>>
>>>>>
>>>>> You said it, and this is the wrong part: “chosen”. By the
>>>>> cochairs, with mistakes that make it non-functional, which
>>>>> changes that should not be done at this time in the process.
>>>>> Without giving the other proposals the same opportunity to
>>>>> change things. May be then we could have chosen a different one?
>>>>>
>>>>>
>>>>> The PDP is not about choosing, is about reaching consensus.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 28/9/20 13:26, "Gaby Giner" <gabyginernetwork at gmail.com
>>>>> <mailto:gabyginernetwork at gmail.com>> escribió:
>>>>>
>>>>>
>>>>> Hi Jordi,
>>>>>
>>>>>
>>>>> I think that we need to funnel our discussion to the relevant
>>>>> subject for this proposal. The region NEEDS an inter RIR
>>>>> transfer policy, and since one has already been chosen, we
>>>>> need to support it and not distract it with policies that
>>>>> could be better off being a separate policy.
>>>>>
>>>>>
>>>>> As far as I know, AFRINIC is a registration entity. That's it.
>>>>> What members/clients do with the resources is not AFRINIC's
>>>>> business, and neither is how members route them. As Lamiaa has
>>>>> pointed out, once a member terminates their contract and
>>>>> changed their registration, it is out of the area of
>>>>> responsibility of AFRINIC how they route/do with their
>>>>> resources anymore. I don't think it's fair to burden AFRINIC
>>>>> with these "difficulties" since it's not in the job
>>>>> description anymore.
>>>>>
>>>>>
>>>>> Thanks, Gaby
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2020 at 7:01 PM Lamiaa Chnayti
>>>>> <lamiaachnayti at gmail.com <mailto:lamiaachnayti at gmail.com>> wrote:
>>>>>
>>>>> Hello Jordi,
>>>>>
>>>>> The salient point here is that AFRINIC only manages
>>>>> registration, not routing. We can make policies about
>>>>> registration of space, but not routing of the space.
>>>>>
>>>>> If their upstream decides to route a space that wasn't
>>>>> registered to them, it is entirely in their upstream's
>>>>> right to do so. If the operator chooses to route space
>>>>> that doesn't belong to them and their upstream is okay
>>>>> with it, it is entirely out of the AFRINIC community's
>>>>> scope - just like any hijacking is out of the scope for
>>>>> the AFRINIC community (the same reason many have told you
>>>>> that the hijacking as policy violation is out of scope).
>>>>>
>>>>> From AFRINIC's point of view, they have terminated the
>>>>> contract; they have changed the registration. What happens
>>>>> at the routing table isn't really AFRINIC's business nor
>>>>> their concern anymore.
>>>>>
>>>>> They do not need to get anything back; those spaces can be
>>>>> allocated to a different member. It is entirely up to the
>>>>> one holding the space to have other operators recognize
>>>>> it. Please do remember, AFRINIC is wholly based on the
>>>>> voluntary cooperation of operators; if someone does not
>>>>> recognize AFRINIC's database as the "right" registration
>>>>> database and then start one of their own, they can
>>>>> definitely do it as it is entirely within their rights to
>>>>> do so. So the difficulty you were talking about is really
>>>>> out of the scope of AFRINIC.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>> Le lun. 28 sept. 2020 à 10:03, JORDI PALET MARTINEZ via
>>>>> RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> a écrit :
>>>>>
>>>>> Hi Ekaterina,
>>>>>
>>>>>
>>>>> The termination of the contract is easy, but what
>>>>> happens if the operator keeps using those resources?
>>>>> How you enforce it to stop? What happens if the case
>>>>> is brought to the courts by any of the parties? How
>>>>> much time it takes? Meanwhile AFRINIC doesn’t get the
>>>>> resources back, so it is not able to redistribute
>>>>> them. This is not fantasy: we have a real case for
>>>>> millions of IP addresses right now in AFRINIC!
>>>>>
>>>>>
>>>>> How much is the cost in terms of lawyers and wait
>>>>> time? Who is using meanwhile the resources? The bad guys.
>>>>>
>>>>>
>>>>> **Partially** that may be resolved if we have the AS0
>>>>> proposal, but even in that case, that only works for
>>>>> the operators using the AS0 TAL!
>>>>>
>>>>>
>>>>> Even if the resources are recovered, do you understand
>>>>> that AFRINIC procedure is to quarantine them for 12
>>>>> months before coming back to the pool?
>>>>>
>>>>>
>>>>> So, what is the gain vs having 12 months hold time?
>>>>> Easy, with the 12 months hold time the cost is much
>>>>> lower. I’m not talking only about money cost for
>>>>> AFRINIC in case of disputes, human resources to tackle
>>>>> them, etc., but also the cost of not being able to use
>>>>> those resources during the recovery time + the
>>>>> quarantine period.
>>>>>
>>>>>
>>>>> Again, that will be resolved, allowing to reduce the
>>>>> quarantine period, if we have the “policy compliance
>>>>> dashboard”.
>>>>>
>>>>>
>>>>> A /22 can be obtained in AFRINIC just with a cost of
>>>>> 2.900 USD (justifying an end-site, for example). You
>>>>> can easily sell this for 10 times more! So, it is a
>>>>> very small investment for a huge margin. Just think if
>>>>> you can repeat that every year, or actually many times
>>>>> per year, just creating a company for “only that”. How
>>>>> much it cost in the cheaper country in AFRICA to
>>>>> create a company? You don’t need offices, or anything
>>>>> like that, you can make a “fake” DC in your home.
>>>>>
>>>>>
>>>>> I don’t think it is a matter of the most “flexible and
>>>>> open” proposal. It is about that one that **really
>>>>> works** and is **safer**. If you followed the
>>>>> discussion on the first proposal (the one that I’ve
>>>>> presented in 2018, with two approaches and several
>>>>> versions), across that discussion **the community**
>>>>> asked me to have a “security seat belt”, so if
>>>>> something goes wrong, it can be put in hold. I said it
>>>>> was not needed, but the community insisted, so I did.
>>>>> Now the community don’t want that. This only shows
>>>>> that the problem in developing policies, is that
>>>>> depending “who” is speaking, the authors get crazy at
>>>>> every version. However, if the chairs really consider
>>>>> only what are valid-objections this will not be an
>>>>> issue. But the problem is that consensus is being
>>>>> decided even considering invalid and refuted objections.
>>>>>
>>>>>
>>>>> May be some folks now understand better that when you
>>>>> do policy proposals, you need to look **at a very
>>>>> broad context** and not only in that specific RIR!
>>>>>
>>>>>
>>>>> It is impossible for an author to explain **all this**
>>>>> in each policy proposal. It is impossible for an
>>>>> author to explain all this in a **8 minutes**
>>>>> presentation. There are **many** other aspects that
>>>>> you can’t realize if you’re not operating networks and
>>>>> participating in all the RIRs. Internet is global and
>>>>> you really need to consider everything. A specific
>>>>> region business and cultural details, are very
>>>>> important for the policy making process, but not
>>>>> forgetting the others!
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 25/9/20 19:58, "Ekaterina Kalugina"
>>>>> <kay.k.prof at gmail.com <mailto:kay.k.prof at gmail.com>>
>>>>> escribió:
>>>>>
>>>>>
>>>>> Dear Jordi, dear all,
>>>>>
>>>>>
>>>>> Jordi, could you please elaborate a bit more on your
>>>>> statement: "the cost of “not-being-able to use those
>>>>> resources” for any number of providers is actually
>>>>> *lower* than the cost of a single recovery case!"
>>>>>
>>>>> As far as I understood, the recovery is be achieved
>>>>> though the termination of the contract. So what
>>>>> exactly is included in the recovery costs?
>>>>>
>>>>>
>>>>> In regard to your argument on the history of fraud in
>>>>> all the RIRs, I do not believe it is very relevant to
>>>>> the current discussion for a simple reason that the
>>>>> maximum allocation space is currently /22. Proving the
>>>>> need that is required for the allocation would cost
>>>>> thousands of dollars, so there is simply no incentive
>>>>> for businesses to commit such fraud. It would cost
>>>>> them way too
>>>>>
>>>>> much and bring way to little.
>>>>>
>>>>>
>>>>> In addition, I believe that our focus should be on
>>>>> passing the most flexible and open transfer policy to
>>>>> incentivise the free flow of resources in and out of
>>>>> the region that is necessary for a steady economic
>>>>> development.
>>>>>
>>>>>
>>>>> If there are so many concerns concerning potential
>>>>> resource abuse and fraud, perhaps a separate policy on
>>>>> fraud prevention ought to be introduced. Let us not
>>>>> try to kill all the possible birds with one stone and
>>>>> instead focus on solving one problem per policy. In my
>>>>> view, this is they only way to ameliorate the duties
>>>>> of AFRINIC staff and ensure the proper practical
>>>>> application of each policy.
>>>>>
>>>>>
>>>>> Best wishes,
>>>>>
>>>>>
>>>>> Kay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 24 Sep 2020, 13:14 JORDI PALET MARTINEZ
>>>>> <jordi.palet at consulintel.es
>>>>> <mailto:jordi.palet at consulintel.es>> wrote:
>>>>>
>>>>> Hi Ekaterina,
>>>>>
>>>>>
>>>>>
>>>>> El 24/9/20 12:25, "Ekaterina Kalugina"
>>>>> <kay.k.prof at gmail.com
>>>>> <mailto:kay.k.prof at gmail.com>> escribió:
>>>>>
>>>>>
>>>>> Hey everyone,
>>>>>
>>>>>
>>>>> @JORDI PALET MARTINEZ
>>>>> <mailto:jordi.palet at consulintel.es> you said, and
>>>>> I quote:
>>>>>
>>>>> >"An ISP will not need to return even a /22 because he
>>>>> loses 1.024 customers as he can get them back,
>>>>> this is very common customer churn in a matter of
>>>>> weeks (even days or hours for big ISPs)."
>>>>>
>>>>> In this case, ISP would not need to bother with
>>>>> resource transfer.
>>>>>
>>>>>
>>>>> [Jordi] At the beginning of the transfers in other
>>>>> regions, I was **against** that. In my opinion
>>>>> when operators don’t need the resources, they
>>>>> should return them back to the RIR. BUT we all
>>>>> know, that people is not so honest, and this will
>>>>> only happen in an utopic and idealistic world and
>>>>> moreover, this will still need some “agreement”
>>>>> between different RIRs to allow those resources
>>>>> that are returned to be “transferred” among RIRs.
>>>>> Due to facts, afterwards I realized that this is a
>>>>> need for the global community and that’s why I
>>>>> agreed with those policies, and even started to
>>>>> work on them as an author.
>>>>>
>>>>>
>>>>>
>>>>> However, I believe a situation may occur when the
>>>>> ISP is unable to distribute the allocated
>>>>> resources for whatever reason. Even if we cannot
>>>>> predict the reason we must still account for such
>>>>> contingency. And, in such case, it does not make
>>>>> sense to block these resources for 12 months from
>>>>> being transferred to a place where they are
>>>>> actually needed. This would be detrimental to
>>>>> everyone involved.
>>>>>
>>>>> [Jordi] I don’t agree. A transfer may take several
>>>>> weeks or even months. It depends on many factors,
>>>>> like the justification time among the RIRs,
>>>>> providing documents, etc. Even if you discover
>>>>> that in month 3 after you have received a /22, you
>>>>> no longer need it (which I doubt it can be true),
>>>>> this means that the resources will be “unused”
>>>>> during other 6-7 months. I could agree that the
>>>>> hold time is just 6-8 months instead of 12, but
>>>>> non zero is difficult, because the cost of
>>>>> “not-being-able to use those resources” for any
>>>>> number of providers is actually **lower** than the
>>>>> cost of a single recovery case!
>>>>>
>>>>>
>>>>> In regard to your statement:
>>>>> "However, a “bad guy” will easily use that as an
>>>>> excuse to transfer the resources in days or weeks."
>>>>> Like Anthony and Lucilla mentioned before, such
>>>>> action would be a clear act of fraud.I do not see
>>>>> any reason why anyone would willingly commit such
>>>>> a violation. "Bad guys" are not stupid, and if
>>>>> someone wants to take an advantage of AFRINIC,
>>>>> they will, and I do not think the 12 months cap
>>>>> would prevent that in any way.
>>>>>
>>>>> [Jordi] Just look at the histories of frauds in
>>>>> all the RIRs! This is real life. Holding the
>>>>> resources for 12 months, breaks their business
>>>>> model. It makes sense because it is quick money
>>>>> and you can do it with a very tiny fraction of
>>>>> money, once and again and again, rotating among
>>>>> different RIRs, etc.
>>>>>
>>>>>
>>>>> The only thing it would achieve, in my view, is
>>>>> slow down the flow of resources and create
>>>>> stagnations that could be more costly than any
>>>>> retrieval procedures in case of fraud.
>>>>>
>>>>> [Jordi] To be objective, we will need to get
>>>>> statistics of “speed” of transfers among different
>>>>> RIRs, number of frauds or fraud attempts, etc.,
>>>>> etc., etc. and many of those details probably are
>>>>> sensitive and the RIRs will not recognize that,
>>>>> even if anonymized. There have been fraud cases in
>>>>> RIPE, which everybody knows by word of mouth, but
>>>>> it has never published …
>>>>>
>>>>>
>>>>> But of course, staff assessment is needed to have
>>>>> full clarity of this issue.
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>> Kay
>>>>>
>>>>>
>>>>> On Thu, Sep 24, 2020 at 9:05 AM Gaby Giner
>>>>> <gabyginernetwork at gmail.com
>>>>> <mailto:gabyginernetwork at gmail.com>> wrote:
>>>>>
>>>>>
>>>>> Hello guys,
>>>>>
>>>>>
>>>>> This discussion is very interesting seeing
>>>>> that it deals with the most probable or likely
>>>>> outcome with those that would want to take
>>>>> advantage of the system. We can only wish that
>>>>> the clients would be completely honest with
>>>>> their need, but of course, if they are
>>>>> inclined to lie, there is no mechanism that
>>>>> would stop them from doing so. I would suggest
>>>>> that the proposal include a means or a way to
>>>>> authenticate the need but that would be more
>>>>> trouble than it is worth and would not be
>>>>> entirely foolproof.
>>>>>
>>>>>
>>>>> Since we are dealing with finite and scarce
>>>>> resources, it's important that the way they
>>>>> are doled out should be systematic and
>>>>> measured and not just "I need this. I need
>>>>> this, give me this". Having said that, I think
>>>>> having a time limit would also cause traffic
>>>>> for the "need". Regardless, as Lucilla said,
>>>>> these are hypothetical scenarios and questions
>>>>> but they may be worth getting into.
>>>>>
>>>>>
>>>>> I'm interested in what the staff/authors would
>>>>> have to say on this matter.
>>>>>
>>>>>
>>>>> Thanks, Gaby.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 24, 2020, 2:59 PM JORDI PALET
>>>>> MARTINEZ via RPD, <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>> wrote:
>>>>>
>>>>> I mean a non-realistic situation. An ISP
>>>>> will not need to return even a /22 because
>>>>> he loses 1.024 customers as he can get
>>>>> them back, this is very common customer
>>>>> churn in a matter of weeks (even days or
>>>>> hours for big ISPs).
>>>>>
>>>>>
>>>>> However, a “bad guy” will easily use that
>>>>> as an excuse to transfer the resources in
>>>>> days or weeks.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 24/9/20 8:29, "JORDI PALET MARTINEZ via
>>>>> RPD" <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>> escribió:
>>>>>
>>>>>
>>>>> Exactly, if you really have that situation
>>>>> you can return them and be fair.
>>>>>
>>>>>
>>>>> Anyway, the example that I’ve presented is
>>>>> a non-realistic suggestion. It is not
>>>>> frequent that an operator loses customers
>>>>> in such way. It is just the perfect excuse
>>>>> for “bad guys” to get resources and resell
>>>>> them.
>>>>>
>>>>>
>>>>> Remember also that in the actual
>>>>> exhaustion phase, they can only get a
>>>>> maximum of a /22.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 24/9/20 4:03, "Fernando Frediani"
>>>>> <fhfrediani at gmail.com
>>>>> <mailto:fhfrediani at gmail.com>> escribió:
>>>>>
>>>>>
>>>>> We can make in another way: if someone
>>>>> justifies and receives resources from
>>>>> AfriNic but afterwards realizes something
>>>>> changed and doesn't need those addresses
>>>>> anymore it must give the addresses back to
>>>>> AfriNic so it can re-distribute it in the
>>>>> most fair way to any other organization
>>>>> who goes though the same justification
>>>>> process. Why is it difficult to think
>>>>> about this fairness with all others in the
>>>>> region ?
>>>>>
>>>>> Fernando
>>>>>
>>>>> On 23/09/2020 22:22, lucilla fornaro wrote:
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>>
>>>>> I agree with what concerns the problem
>>>>> of the time limit. Companies will
>>>>> refrain from such behavior because it
>>>>> is too risky and indicative of
>>>>> possible fraud.
>>>>>
>>>>>
>>>>> Jordi, Considering your example
>>>>> related to the customers' loss, I
>>>>> think that it is adverse for the
>>>>> operator to wait 12 months before
>>>>> transferring the addresses. What is
>>>>> the point in holding addresses that
>>>>> they will not be able to use and
>>>>> deprive someone else of further
>>>>> resources? What if they don’t get new
>>>>> customers? What if they lose even more
>>>>> customers? Too many hypothetical
>>>>> questions, that is why I believe it is
>>>>> more straightforward and more
>>>>> convenient for everyone to facilitate
>>>>> the process.
>>>>>
>>>>>
>>>>> I agree that recovery processes are
>>>>> expensive and time-consuming, but we
>>>>> can say the same for those unused
>>>>> resources.
>>>>>
>>>>>
>>>>> As well as you, I would like to know
>>>>> the staff’s view on this.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Lucilla
>>>>>
>>>>>
>>>>> Il giorno mer 23 set 2020 alle ore
>>>>> 21:14 JORDI PALET MARTINEZ via RPD
>>>>> <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>> ha scritto:
>>>>>
>>>>> Hi Anthony,
>>>>>
>>>>>
>>>>> I think **somehow** you’re right,
>>>>> clearly I overlooked this.
>>>>>
>>>>>
>>>>> We don’t need a time limit to
>>>>> transfer resrources because that
>>>>> will be a demonstration of the
>>>>> “the need was not justified”.
>>>>>
>>>>>
>>>>> However, the problem of this
>>>>> approach is that if it happens,
>>>>> the staff **will need to start a
>>>>> recovery process** which is long,
>>>>> costly and a big trouble.
>>>>>
>>>>>
>>>>> What happens if the **false**
>>>>> justification for the transfer is:
>>>>> I had the need 6 months ago, but
>>>>> then I lost customers and now I
>>>>> don’t need anymore the space, so
>>>>> I’m transfering it.
>>>>>
>>>>>
>>>>> What happens if the same operator,
>>>>> repeat that after another 6
>>>>> months? There are ways to one and
>>>>> again **justify the need** and it
>>>>> is, instead, very dificult for the
>>>>> staff to act on the RSA for
>>>>> recovery and member closure in
>>>>> those cases.
>>>>>
>>>>>
>>>>> On the other way around, what is
>>>>> the “objection” if we have that
>>>>> hold time? I can only see one: If
>>>>> the example above (I lost
>>>>> customers) happens, the operator
>>>>> need to wait until month 12 before
>>>>> transfering the addresses. Is that
>>>>> really so bad? Or it is good
>>>>> because he may get new customers
>>>>> again?
>>>>>
>>>>>
>>>>> I think the trade-off is to have a
>>>>> good balance and ensure that we
>>>>> avoid this happening and requiring
>>>>> the staff to invest resources in
>>>>> an investigation and recovery.
>>>>>
>>>>>
>>>>> Could the staff provide a view on
>>>>> this?
>>>>>
>>>>>
>>>>> Regarding the legacy. Yes, ARIN
>>>>> and RIPE don’t have it (I think
>>>>> APNIC has it, LACNIC definitively
>>>>> has it). AFRINIC has it right now.
>>>>> We are removing a very good thing.
>>>>>
>>>>>
>>>>> Why it is so good? Because legacy
>>>>> holders aren’t bound to the RIRs
>>>>> RSAs, so that’s extremely bad for
>>>>> the overall community. They don’t
>>>>> pay for **services** that all the
>>>>> RIRs are doing for them, so all
>>>>> the members are covering that part
>>>>> of the cost. They’re not bound to
>>>>> RIR policies, so they can break
>>>>> the rules of the community all the
>>>>> time and we have no way to react
>>>>> on that.
>>>>>
>>>>>
>>>>> I don’t agree on the point of the
>>>>> disputed resources, I’ve the
>>>>> feeling that somehow in the
>>>>> process of editing the v2, it was
>>>>> removed by mistake and we should
>>>>> have it back. The difference in
>>>>> between rightful holder and having
>>>>> a dispute, is depending on who is
>>>>> saying that, in case of a dispute.
>>>>> I will love also to have the staff
>>>>> opinion on that.
>>>>>
>>>>>
>>>>> As well, can the impact analysis
>>>>> be made clear? Is that all fine
>>>>> for the staff after having checked
>>>>> with authors each point?
>>>>>
>>>>>
>>>>> Please, let’s make this happen!
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 21/9/20 18:10, "Anthony Ubah"
>>>>> <ubah.tonyiyke at gmail.com
>>>>> <mailto:ubah.tonyiyke at gmail.com>>
>>>>> escribió:
>>>>>
>>>>>
>>>>> Hello Jordi,
>>>>>
>>>>> We can sight an instance with
>>>>> APNIC as a case study. APNIC has a
>>>>> transfer policy that doesn’t have
>>>>> a time limit for retransferring
>>>>> resources and time proves to us
>>>>> that it works.
>>>>>
>>>>> According to APNIC, the act of
>>>>> buying space and reselling it
>>>>> right after the purchase seems to
>>>>> be highly unlikely because of two
>>>>> reasons.
>>>>>
>>>>> First of all, most companies buy
>>>>> space for their own use, and hence
>>>>> a commodity trading type of
>>>>> business doesn’t exist in the IP
>>>>> space involved.
>>>>>
>>>>> Secondly, since the buyer is
>>>>> required to justify the need of a
>>>>> 12-month usage, if he/she engages
>>>>> in an activity such as buying the
>>>>> space and then reselling it right
>>>>> after, this indicative of fraud
>>>>> because it contravenes the “NEED”
>>>>> which is a prerequisite for
>>>>> receiving such space. This simply
>>>>> implies that the so-called “NEED”
>>>>> which they provided was fake.
>>>>> Hence, companies will refrain from
>>>>> engaging in such behaviour.
>>>>>
>>>>> As for the legacy transfer, I
>>>>> believe both ARIN and RIPE have
>>>>> the cases of a transferred legacy
>>>>> space remained as a legacy. APNIC
>>>>> may be different, but I think this
>>>>> is just a different sort of
>>>>> opinion and should not be read as
>>>>> an objection. Also, what matters
>>>>> the most is that if we follow
>>>>> ARIN, we can receive space from
>>>>> them. Definitely this is a
>>>>> significant advantage.
>>>>>
>>>>> As for the disputed resources,
>>>>> since AFRINIC have to know who the
>>>>> rightful holder of the spaces are
>>>>> before transferring them. I don’t
>>>>> think this would be a concern
>>>>> because AFRINIC is not able to
>>>>> initiate a transfer for space that
>>>>> is under dispute. However, this is
>>>>> a legal matter and is already out
>>>>> of the scope of the policy.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> *Anthony Ubah*
>>>>>
>>>>> E-mail: anthony.ubah at goldspine.com
>>>>> <mailto:anthony.ubah at gloworld.com>.ng
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 21, 2020 at 10:00 AM
>>>>> <rpd-request at afrinic.net
>>>>> <mailto:rpd-request at afrinic.net>>
>>>>> wrote:
>>>>>
>>>>> Send RPD mailing list
>>>>> submissions to
>>>>> rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>
>>>>>
>>>>> To subscribe or unsubscribe
>>>>> via the World Wide Web, visit
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>> or, via email, send a message
>>>>> with subject or body 'help' to
>>>>> rpd-request at afrinic.net
>>>>> <mailto:rpd-request at afrinic.net>
>>>>>
>>>>> You can reach the person
>>>>> managing the list at
>>>>> rpd-owner at afrinic.net
>>>>> <mailto:rpd-owner at afrinic.net>
>>>>>
>>>>> When replying, please edit
>>>>> your Subject line so it is
>>>>> more specific
>>>>> than "Re: Contents of RPD
>>>>> digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>>>> 1.
>>>>> AFPUB-2019-V4-003-DRAFT02 -
>>>>> Resource Transfer Policy
>>>>> (JORDI PALET MARTINEZ)
>>>>> 2. Re: Abuse Contact Policy
>>>>> (JORDI PALET MARTINEZ)
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Mon, 21 Sep 2020
>>>>> 10:34:13 +0200
>>>>> From: JORDI PALET MARTINEZ
>>>>> <jordi.palet at consulintel.es
>>>>> <mailto:jordi.palet at consulintel.es>>
>>>>> To: rpd List <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>> Subject: [rpd]
>>>>> AFPUB-2019-V4-003-DRAFT02 -
>>>>> Resource Transfer Policy
>>>>> Message-ID:
>>>>> <8873E491-A0A7-4506-A490-13C6B6E67A7D at consulintel.es
>>>>> <mailto:8873E491-A0A7-4506-A490-13C6B6E67A7D at consulintel.es>>
>>>>> Content-Type: text/plain;
>>>>> charset="utf-8"
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I will be happy to support
>>>>> this proposal and withdraw my
>>>>> own one, but *before* I?ve
>>>>> some questions about this
>>>>> decision that need to be
>>>>> addressed first (see below,
>>>>> in-line).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 10. Resource Transfer Policy
>>>>>
>>>>> This proposal aims to
>>>>> introduce Inter RIR transfer.
>>>>> However, it has the following
>>>>> opposition
>>>>>
>>>>> a. Issues with Legacy
>>>>> holder transfer is potentially
>>>>> considered none-reciprocal by ARIN
>>>>>
>>>>> b. Potential abuse of AFRINIC
>>>>> free pool without the time
>>>>> limit of receiving an
>>>>> allocation from AFRINIC.
>>>>>
>>>>> Chairs Decision: The proposal
>>>>> is the least contested of all
>>>>> the 3 competing proposals.
>>>>> However because of the
>>>>> community?s desire and clear
>>>>> expression for the need for
>>>>> an Inter RIR transfer, we, the
>>>>> Co-chairs, believe that in the
>>>>> interest of the community we
>>>>> should focus on a proposal
>>>>> rather than several similar
>>>>> ones. This desire was clearly
>>>>> expressed at the AFRINIC 31
>>>>> meeting in Angola. Therefore,
>>>>> We suggest that the authors of
>>>>> this proposal make the
>>>>> following amendments:
>>>>>
>>>>> ? 5.7.3.2 Source entities are
>>>>> not eligible to receive
>>>>> further IPv4 allocations or
>>>>> assignments from AFRINIC for
>>>>> 12 months period after the
>>>>> transfer.
>>>>>
>>>>>
>>>>>
>>>>> [Jordi] This is perfect, and
>>>>> in fact is what I?ve. Just
>>>>> different timing to match
>>>>> phase 2 window x 2, but not a
>>>>> big issue. However, we are
>>>>> missing something that was
>>>>> also objected by the community
>>>>> and I think is key to avoid
>>>>> abuse. Actual text in the CPM
>>>>> ?5.7.3.3 Source entities must
>>>>> not have received a transfer,
>>>>> allocation, or assignment of
>>>>> IPv4 number resources from
>>>>> AFRINIC for the 12 months
>>>>> prior to the approval of
>>>>> transfer request. This
>>>>> restriction excludes mergers
>>>>> and acquisitions transfers.?.
>>>>> This is no longer considered
>>>>> by this proposal, and in my
>>>>> opinion it is a MUST. Doesn?t
>>>>> make any sense that someone is
>>>>> getting resources from AFRINIC
>>>>> and being able to transfer
>>>>> them immediately! Can please
>>>>> the chairs also address this
>>>>> point.
>>>>>
>>>>> [Jordi] Can the staff explain
>>>>> the consequences from their
>>>>> perspective if we don?t have
>>>>> such text or something
>>>>> similar? Is even possible that
>>>>> the board will not ratify the
>>>>> policy because that, and we
>>>>> are wasting a previous time?
>>>>>
>>>>>
>>>>>
>>>>> ? 5.7.4.3. Transferred legacy
>>>>> resources will still be
>>>>> regarded as legacy resources.
>>>>>
>>>>> [Jordi] This is also a major
>>>>> issue. I?m not sure if the
>>>>> chairs have understood what
>>>>> was the point about lack of
>>>>> reciprocity. We can?t enforce
>>>>> ARIN to accept that outgoing
>>>>> (to ARIN from AFRINIC)
>>>>> resources will no longer be
>>>>> legacy. However the actual CPM
>>>>> states ?5.7.4.3 Transferred
>>>>> IPv4 legacy resources will no
>>>>> longer be regarded as legacy
>>>>> resources.?. We must keep
>>>>> that, because we should avoid
>>>>> legacy resources to keep being
>>>>> legacy as much as possible,
>>>>> because they are NOT BIND to
>>>>> the CPM. If we accept the
>>>>> chairs proposal, we are going
>>>>> *backwards* not forward and we
>>>>> may be creating a
>>>>> discrimination with already
>>>>> done transfers within AFRINIC
>>>>> (Intra-RIR, according to the
>>>>> current policy). The right
>>>>> text here must be ?Transferred
>>>>> incoming or within AFRINIC
>>>>> IPv4 legacy resources will no
>>>>> longer be regarded as legacy
>>>>> resources?.
>>>>>
>>>>>
>>>>>
>>>>> [Jordi] Finally, there were
>>>>> several severe comments from
>>>>> the staff that need to be
>>>>> addressed. For example,
>>>>> resources under dispute.
>>>>> That?s a big issue! There are
>>>>> a few others. I think here we
>>>>> need to see if the staff got
>>>>> everything clear from the
>>>>> authors inputs and if the
>>>>> policy can be implemented or
>>>>> there will be open questions
>>>>> that will not allow to be a
>>>>> functional policy and again,
>>>>> even disallow the board to
>>>>> ratify it.
>>>>>
>>>>>
>>>>>
>>>>> Chairs Decision: Provided that
>>>>> the above are amended, the
>>>>> decisions is Rough Consensus
>>>>> is achieved
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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.
>>>>>
>>>>> -------------- next part
>>>>> --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL:
>>>>> <https://lists.afrinic.net/pipermail/rpd/attachments/20200921/81bf3b81/attachment-0001.html
>>>>> <https://lists.afrinic.net/pipermail/rpd/attachments/20200921/81bf3b81/attachment-0001.html>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 2
>>>>> Date: Mon, 21 Sep 2020
>>>>> 11:00:01 +0200
>>>>> From: JORDI PALET MARTINEZ
>>>>> <jordi.palet at consulintel.es
>>>>> <mailto:jordi.palet at consulintel.es>>
>>>>> To: <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>> Subject: Re: [rpd] Abuse
>>>>> Contact Policy
>>>>> Message-ID:
>>>>> <491C1297-8C2D-4939-B339-EDAA80334B24 at consulintel.es
>>>>> <mailto:491C1297-8C2D-4939-B339-EDAA80334B24 at consulintel.es>>
>>>>> Content-Type: text/plain;
>>>>> charset="utf-8"
>>>>>
>>>>> Hi Lamiaa,
>>>>>
>>>>>
>>>>>
>>>>> 8.3 and 8.4 are making sure
>>>>> that you respond to an abuse
>>>>> case, *not* that you
>>>>> *recognize* it as an abuse. It
>>>>> is your choice to tell the
>>>>> ?victim ISP?, look for me this
>>>>> is not an abuse, so I will not
>>>>> do anything about it.
>>>>>
>>>>>
>>>>>
>>>>> AFRINIC can?t verify this
>>>>> automatically, because it
>>>>> doesn?t make sense that
>>>>> AFRINIC is ?sending? fake
>>>>> abuse reports to see if they
>>>>> get a response.
>>>>>
>>>>>
>>>>>
>>>>> AFRINIC can only send an email
>>>>> for the validation of the
>>>>> mailbox. It is an existing
>>>>> mailbox? I?m getting a
>>>>> response (for example, have
>>>>> they, once I send the
>>>>> validation email, clicked the
>>>>> link or went into MyAfrinic to
>>>>> input the validation code?).
>>>>>
>>>>>
>>>>>
>>>>> 8.4 also states the timing for
>>>>> the validation.
>>>>>
>>>>>
>>>>>
>>>>> 8.5 is the validation itself,
>>>>> so I guess, according to your
>>>>> response, that you?re ok with
>>>>> this specific point. If we
>>>>> don?t have it, AFRINIC can?t
>>>>> do a periodic validation.
>>>>>
>>>>>
>>>>>
>>>>> 8.6. is making sure that you
>>>>> don?t try to fake the
>>>>> validation. For instance, you
>>>>> could respond only to AFRINIC
>>>>> validations and then discard
>>>>> all the other emails. If we
>>>>> don?t have that, the policy
>>>>> may become useless. Note also
>>>>> that in fact, if you follow
>>>>> the RSA, *anyone* could
>>>>> escalate *any* lack of CPM
>>>>> compliance. So this is making
>>>>> sure that the policy text is
>>>>> honest and transparent.
>>>>>
>>>>>
>>>>>
>>>>> Or do you prefer to be
>>>>> filtered because you don?t
>>>>> respond?
>>>>>
>>>>>
>>>>>
>>>>> Clearly this proposal is not
>>>>> asking AFRINIC to be a police.
>>>>> Is only making sure that the
>>>>> parties *can talk*. Again:
>>>>> AFRINIC will not be involved
>>>>> in ?how you handle the case?,
>>>>> but I least you should be able
>>>>> to be contacted and respond.
>>>>>
>>>>>
>>>>>
>>>>> See this example:
>>>>>
>>>>> If AK or Moses customers are
>>>>> sending me spam, or trying to
>>>>> intrude my network, and they
>>>>> have abuse contacts, I will be
>>>>> able to complain to them. Then
>>>>> we have two cases:
>>>>>
>>>>> 1. Moses responds to me and
>>>>> say ?you?re right, this is
>>>>> against our AUP? (is
>>>>> irrelevant what the law in
>>>>> Moses country say, it is the
>>>>> contract with customers what
>>>>> says what is allowed or not).
>>>>> Let?s fix it. I will warn the
>>>>> customer, and if they don?t
>>>>> stop, we will filter their
>>>>> email port, or even cancel the
>>>>> contract (just examples, only
>>>>> Moses can decide what they do).
>>>>>
>>>>> 2. AK instead doesn?t care,
>>>>> or the mailbox is full or
>>>>> bouncing emails or respond
>>>>> ?sorry in our network we allow
>>>>> that?. Then I can take my own
>>>>> decision, filter only that IP
>>>>> address, or the complete AK
>>>>> network. I can even see if
>>>>> this is allowed in his country
>>>>> and take legal actions (which
>>>>> usually you don?t do because
>>>>> is costly and more of the
>>>>> regulations don?t know
>>>>> ?anything? about abuse or even
>>>>> Internet!).
>>>>>
>>>>> AFRINIC will not take any
>>>>> measure if AK decides that is
>>>>> not an abuse. It is our
>>>>> problem not AFRINIC problem.
>>>>> However, if the email is
>>>>> bouncing, AFRINIC will
>>>>> revalidate the abuse-c and
>>>>> make sure that it works.
>>>>>
>>>>>
>>>>>
>>>>> Is like a phone book. You have
>>>>> there the phones and they must
>>>>> be correct, or you need to
>>>>> update them every ?n? months.
>>>>> The phone book doesn?t tell
>>>>> the purpose of each phone. If
>>>>> you don?t want to accept calls
>>>>> related to ?ordering pizzas?,
>>>>> you tell the caller ?this
>>>>> number is not for that?, but
>>>>> at least you must pick up the
>>>>> phone otherwise, you don?t
>>>>> know if it is somebody calling
>>>>> by error or someone that you
>>>>> really want to talk. And this
>>>>> is true for *every* whois contact.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Can you let us know how do you
>>>>> handle it in the networks that
>>>>> you operate?
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 21/9/20 10:00, "Lamiaa
>>>>> Chnayti"
>>>>> <lamiaachnayti at gmail.com
>>>>> <mailto:lamiaachnayti at gmail.com>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>> Hi Fernando,
>>>>>
>>>>>
>>>>>
>>>>> I think you are very confused.
>>>>> I never said I have a problem
>>>>> with people completing their
>>>>> registration. Keep
>>>>> registration---having an abuse
>>>>> contact Email in the whois,
>>>>> just like tech contact or
>>>>> admin contact--I am perfectly
>>>>> fine with it, and I think the
>>>>> current policy achieves 99%
>>>>> it, if you want to add this
>>>>> contact as mandatory field I
>>>>> am fine with it as well.
>>>>>
>>>>>
>>>>>
>>>>> But the problem of this
>>>>> policy in 8.3-8.6, is that it
>>>>> requires AFRINIC to monitor
>>>>> the members HOW to manage
>>>>> their abuse mailbox down to
>>>>> the subject line, and that is
>>>>> out of the scope of AFRINIC,
>>>>> just read my last email with
>>>>> logic in mind and you will
>>>>> understand. I suggest this
>>>>> policy should be very simple,
>>>>> adding one line to the current
>>>>> policy-- abuse contact is
>>>>> mandatory, and it's done,
>>>>> everything else should be deleted.
>>>>>
>>>>>
>>>>>
>>>>> And again, you are trying to
>>>>> use AFRINIC for something that
>>>>> is not in its scope, how
>>>>> someone manages their mailbox
>>>>> is not in the scope of
>>>>> AFRINIC, it is like you go to
>>>>> your local church to ask them
>>>>> to arrest your neighbour who
>>>>> plays loud music at night when
>>>>> you should go to police
>>>>> instead. Same thing for
>>>>> someone running an abusive
>>>>> network, as many already
>>>>> stated, it is up to a local
>>>>> Jury to decide if it is simply
>>>>> at an annoying level or a
>>>>> criminal offense, but either
>>>>> way please do go to your local
>>>>> police to report it.
>>>>>
>>>>>
>>>>>
>>>>> As for the internet, we never
>>>>> tell you how to behave--you
>>>>> are entirely at your rights in
>>>>> the internet to behave
>>>>> abusively, but it is also
>>>>> entirely in everyone's rights
>>>>> to block you, that's how
>>>>> de-centralizing works, no
>>>>> central governing, everyone
>>>>> plays nice because that's the
>>>>> only way for everyone else to
>>>>> play with you, and this policy
>>>>> here asks AFRINIC to act like
>>>>> a central government even down
>>>>> to manage people's mailbox's
>>>>> subject line and that is way
>>>>> beyond what internet meant to be.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>>
>>>>> Le dim. 20 sept. 2020 ? 23:42,
>>>>> Fernando Frediani
>>>>> <fhfrediani at gmail.com
>>>>> <mailto:fhfrediani at gmail.com>>
>>>>> a ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 19/09/2020 13:19, Lamiaa
>>>>> Chnayti wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <clip>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> How is it in the scope of
>>>>> AFRINIC to decide how I manage
>>>>> my abuse mailbox? If I want to
>>>>> reply only to a specific
>>>>> subject line of my abuse box,
>>>>> it is entirely in my right to
>>>>> do. Even if I don't want to
>>>>> reply at the abuse mailbox at
>>>>> all, that is my right to do so
>>>>> and if I think no action in my
>>>>> network would be considered
>>>>> abuse (although unlikely), but
>>>>> it is still from the internet
>>>>> community point of view,
>>>>> entirely in my right to do so.
>>>>> You might choose to block me
>>>>> as a network, but that is also
>>>>> your right.
>>>>>
>>>>>
>>>>>
>>>>> The reason internet is called
>>>>> INTER-NET is because of its
>>>>> decentralized nature, you have
>>>>> to play nice for others to
>>>>> play with you, but this
>>>>> community never forces anyone
>>>>> to play nice, it is not in the
>>>>> scope of AFRINIC to decide how
>>>>> members reply to their abuse
>>>>> mailbox, so if 8.3,8.4, 8.5
>>>>> and 8.6 are deleted in its
>>>>> entirety, I might consider
>>>>> supporting it. Also Jordi, I
>>>>> feel you always have this
>>>>> central management type of
>>>>> thinking, and that is so not
>>>>> internet.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It is not in the scope of any
>>>>> RIR how anyone manage people's
>>>>>
>>>>> mailboxes.
>>>>>
>>>>>
>>>>> Nobody exists alone in the
>>>>> Internet. If an organization
>>>>>
>>>>> hypothetically doesn't care at
>>>>> all and refuses to respond to
>>>>> abuse
>>>>>
>>>>> emails it probably should
>>>>> re-think its existence in the
>>>>> Internet
>>>>>
>>>>> business.
>>>>>
>>>>>
>>>>>
>>>>> The Internet is what is among
>>>>> many reasons because of the
>>>>>
>>>>> cooperation among its
>>>>> organizations, and there are
>>>>> certain rules
>>>>>
>>>>> that are agreed cooperatively
>>>>> and must be observed by everyone
>>>>>
>>>>> willing remain on it,
>>>>> otherwise it may in many cases
>>>>> cause serious
>>>>>
>>>>> damage to those willing to
>>>>> operate in serious manner and
>>>>> keep it a
>>>>>
>>>>> healthy place to most people
>>>>> who depend on it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This forum is about setting
>>>>> rules on how registration
>>>>> information
>>>>>
>>>>> about resources are kept and
>>>>> it may be of the wish of the
>>>>>
>>>>> community to refuse keep
>>>>> registration for those who
>>>>> repetitively
>>>>>
>>>>> abuse of their individual rights.
>>>>>
>>>>>
>>>>>
>>>>> Fernando
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le ven. 18 sept. 2020 ? 09:23,
>>>>>
>>>>> JORDI PALET MARTINEZ via RPD
>>>>> <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>> a
>>>>> ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Lamiaa,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I don?t agree. Internet
>>>>> doesn't depend on
>>>>>
>>>>> any jurisdiction; abuse is
>>>>> about what I (the victim
>>>>>
>>>>> operator) consider abuse. The
>>>>> RFC is clear about that,
>>>>>
>>>>> in short ?Inappropriate public
>>>>> behaviour? (is a
>>>>>
>>>>> mailbox so to be able to
>>>>> contact in case there is a
>>>>>
>>>>> possible inappropriate
>>>>> behaviour in the public
>>>>>
>>>>> Internet). If you want a
>>>>> clearer definition, abuse is
>>>>>
>>>>> *anything* that I don?t want
>>>>> to accept in my
>>>>>
>>>>> network because is in any way
>>>>> damaging it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If I don?t want to accept a
>>>>> DoS, or spam,
>>>>>
>>>>> or phising, DMCA, or whatever,
>>>>> this is abuse *for
>>>>>
>>>>> me*. I?ve the right to tell
>>>>> you because that
>>>>>
>>>>> abuse is coming from your
>>>>> network. If you believe that
>>>>>
>>>>> is not abuse (and here is your
>>>>> jurisdiction in some
>>>>>
>>>>> cases, in other just doesn?t
>>>>> exist, but it may be also
>>>>>
>>>>> your ?business? decision ?
>>>>> like operators that don?t
>>>>>
>>>>> care if their customers do
>>>>> spam or intrusion
>>>>>
>>>>> attempts), you?ve the right to
>>>>> tell me ?sorry, this is
>>>>>
>>>>> not abuse for us?, and then
>>>>> I?ve the right to decide
>>>>>
>>>>> if I should filter your
>>>>> network based on your
>>>>>
>>>>> response.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not having an abuse contact,
>>>>> means that
>>>>>
>>>>> I?m not able to contact you,
>>>>> so we can?t talk, we
>>>>>
>>>>> can?t investigate or agree if
>>>>> it is an abuse or not,
>>>>>
>>>>> so you (the offender operator)
>>>>> don?t have the chance
>>>>>
>>>>> to decide about it! Is bad for
>>>>> you, is bad for me. In
>>>>>
>>>>> those cases, my best choice is
>>>>> to filter you. This
>>>>>
>>>>> create problems for your
>>>>> customers and my customers.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> We can?t depend on
>>>>> jurisdictions, because
>>>>>
>>>>> then the policy will need to
>>>>> consider inter-relations
>>>>>
>>>>> among every possible ?pairs?
>>>>> of country worlds, and we
>>>>>
>>>>> will need to update the policy
>>>>> based on any
>>>>>
>>>>> jurisdiction change. The
>>>>> policy is not about that, is
>>>>>
>>>>> about having a valid
>>>>> responsible contact, not about
>>>>>
>>>>> deciding what is an abuse,
>>>>> which is among the two
>>>>>
>>>>> parties.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tell me what is different from
>>>>> AFRINIC
>>>>>
>>>>> than the rest of the world,
>>>>> because none of the RIRs
>>>>>
>>>>> have defined abuse in their
>>>>> policies. I even don?t
>>>>>
>>>>> recall that having appeared in
>>>>> the discussions!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If
>>>>>
>>>>> you want, I?m happy to change
>>>>> the title of the
>>>>>
>>>>> proposal to ?supposed abuse
>>>>> contact?, that may be
>>>>>
>>>>> clearing your point?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Again,
>>>>>
>>>>> this is not about defining
>>>>> what is abuse, this is
>>>>>
>>>>> among the parties. It is about
>>>>> making sure that
>>>>>
>>>>> there is a valid responsible
>>>>> contact in case of
>>>>>
>>>>> anyone needs to report what he
>>>>> considers an abuse.
>>>>>
>>>>> AFRINIC will not punish anyone
>>>>> that believes that
>>>>>
>>>>> his customer is not doing an
>>>>> abuse because in his
>>>>>
>>>>> country is not an abuse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Jordi
>>>>>
>>>>>
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El
>>>>>
>>>>> 18/9/20 9:59, "Lamiaa Chnayti"
>>>>> <lamiaachnayti at gmail.com
>>>>> <mailto:lamiaachnayti at gmail.com>>
>>>>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hello
>>>>>
>>>>> Jordi,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RFC2142
>>>>>
>>>>> only defines a tiny portion of
>>>>> the network abuse. In
>>>>>
>>>>> real world operation, abuse
>>>>> consists of a much
>>>>>
>>>>> boarder range : DMCA(copy
>>>>> rights) claims,
>>>>>
>>>>> unsolicited emails , phishing
>>>>> websites , trade mark
>>>>>
>>>>> disputes etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> All
>>>>>
>>>>> those are legal issues that
>>>>> vary vastly across
>>>>>
>>>>> different juridictions in
>>>>> which no one but each of
>>>>>
>>>>> the juridiction?s judges can
>>>>> decide if it is an
>>>>>
>>>>> abuse or an illegal activity.
>>>>> Claiming that RFC2142
>>>>>
>>>>> defines not even 1% of real
>>>>> world abuse is
>>>>>
>>>>> laughable.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le jeu.
>>>>>
>>>>> 17 sept. 2020 ? 15:51, JORDI
>>>>> PALET MARTINEZ via
>>>>>
>>>>> RPD <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>>
>>>>> a ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>> Lamiaa,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I?ve
>>>>>
>>>>> said this already. This policy
>>>>> doesn?t
>>>>>
>>>>> enforce abuse, it enforces
>>>>> that the abuse
>>>>>
>>>>> contact is there, and works.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Today
>>>>>
>>>>> AFRINIC is paying for the cost
>>>>> of the
>>>>>
>>>>> abuse handling because only a tiny
>>>>>
>>>>> fraction of the members has
>>>>> the abuse
>>>>>
>>>>> contacts in place.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If
>>>>>
>>>>> the contacts in the RIR
>>>>> database aren?t
>>>>>
>>>>> actual and accurate, this is a
>>>>> clear
>>>>>
>>>>> violation of the RSA. So what is
>>>>>
>>>>> unacceptable is not having the
>>>>> contacts,
>>>>>
>>>>> not on the other way around.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Abuse
>>>>>
>>>>> is not defined by the RIRs,
>>>>> everybody
>>>>>
>>>>> knows it and this is the
>>>>> reason why NONE
>>>>>
>>>>> of the RIRs have re-defined
>>>>> it, because it
>>>>>
>>>>> is already stated in RFC2142.
>>>>> Can you
>>>>>
>>>>> justify why AFRINIC is
>>>>> different and need
>>>>>
>>>>> a definition?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> How
>>>>>
>>>>> you define it in the networks
>>>>> that you
>>>>>
>>>>> operate?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Jordi
>>>>>
>>>>>
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 17/9/20
>>>>>
>>>>> 10:49, "Lamiaa Chnayti"
>>>>> <lamiaachnayti at gmail.com
>>>>> <mailto:lamiaachnayti at gmail.com>>
>>>>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I
>>>>>
>>>>> will have to agree with
>>>>> Lucilla on what
>>>>>
>>>>> she said and would like to add
>>>>> to it
>>>>>
>>>>> that :
>>>>>
>>>>>
>>>>>
>>>>> Firstly, Abuse
>>>>>
>>>>> enforcement is out of scope
>>>>> for RIRs.
>>>>>
>>>>>
>>>>>
>>>>> Secondly, RIRs
>>>>>
>>>>> have no ability to define what is
>>>>>
>>>>> ?abuse?, one abuse or even
>>>>> criminal
>>>>>
>>>>> activity could be entirely a legal
>>>>>
>>>>> operation in a different
>>>>> jurisdiction.
>>>>>
>>>>>
>>>>>
>>>>> Finally, making
>>>>>
>>>>> a member forcefully reply to abuse
>>>>>
>>>>> contact Emails are a waste of
>>>>> resources
>>>>>
>>>>> and totally pointless, it is
>>>>> entirely up
>>>>>
>>>>> to the member to define what
>>>>> they think
>>>>>
>>>>> is acceptable in their network
>>>>> operation
>>>>>
>>>>> and how they react to it.
>>>>> AFRINIC has no
>>>>>
>>>>> mandate to force any member to
>>>>> reply to
>>>>>
>>>>> an ?abuse?, since AFRINIC
>>>>> doesn?t even
>>>>>
>>>>> have the ability to identify
>>>>> what is
>>>>>
>>>>> considered an abuse.
>>>>>
>>>>>
>>>>>
>>>>> Therefore the
>>>>>
>>>>> entire policy is out of scope
>>>>> for the
>>>>>
>>>>> RIR operation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le jeu. 17
>>>>>
>>>>> sept. 2020 ? 07:42, JORDI
>>>>> PALET MARTINEZ
>>>>>
>>>>> via RPD <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>>
>>>>> a ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Lucilla,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Today we already have
>>>>>
>>>>> mnt-IRT, and everybody who operate
>>>>>
>>>>> networks understand what it is an
>>>>>
>>>>> abuse. If you operate networks you
>>>>>
>>>>> know that *anything* which
>>>>>
>>>>> is a non-authorized use of a
>>>>>
>>>>> network is an abuse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If you send spam,
>>>>>
>>>>> attack networks, try to intrude
>>>>>
>>>>> networks, etc., all those are
>>>>>
>>>>> abuse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What the policy ask
>>>>>
>>>>> is to make sure that in AFRINIC
>>>>>
>>>>> everybody has an abuse contact
>>>>>
>>>>> (today we have mnt-IRT, but is not
>>>>>
>>>>> mandatory, and as a results many
>>>>>
>>>>> African networks are filtered
>>>>>
>>>>> because lack of that ? and
>>>>>
>>>>> consequently they do not respond
>>>>>
>>>>> to abuse cases -, which exist in
>>>>>
>>>>> all the other regions of the
>>>>>
>>>>> world).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not having an abuse
>>>>>
>>>>> means more chances of legal
>>>>>
>>>>> actions, more cost, for both the
>>>>>
>>>>> victims and the ISPs. Having
>>>>>
>>>>> that means that you have more
>>>>>
>>>>> chances to resolve it in
>>>>>
>>>>> goodfaith.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> One of the *most
>>>>>
>>>>> important* Afrinic
>>>>>
>>>>> missions is to have accuracy on
>>>>>
>>>>> the database, which includes
>>>>>
>>>>> accuracy on the contacts. We are
>>>>>
>>>>> not fulfilling that in this
>>>>>
>>>>> situation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Remember that *all*
>>>>>
>>>>> the other RIRs have already this
>>>>>
>>>>> kind of policy. This one is like
>>>>>
>>>>> the one that has been
>>>>>
>>>>> implemented in APNIC, and the
>>>>>
>>>>> accuracy of the contacts is now
>>>>>
>>>>> 87.5% as reported this month in
>>>>>
>>>>> the last APNIC meeting. In that
>>>>>
>>>>> report *none* of the
>>>>>
>>>>> members indicated any of the
>>>>>
>>>>> issues that you indicated
>>>>>
>>>>> (didn't happened as well in the
>>>>>
>>>>> other regions).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You know who is
>>>>>
>>>>> interested in not having abuse
>>>>>
>>>>> contacts? Those that use their
>>>>>
>>>>> networks for doing abuse
>>>>>
>>>>> (hijacking, spam, DoS,
>>>>>
>>>>> intrusions, etc.).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Can you explain if
>>>>>
>>>>> the network that you operate has
>>>>>
>>>>> an abuse contact an how if one
>>>>>
>>>>> of your customes is trying to
>>>>>
>>>>> penetrate my network or do a
>>>>>
>>>>> DoS, I will be able to contact
>>>>>
>>>>> you and if you will do anything
>>>>>
>>>>> or just ignore it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Jordi
>>>>>
>>>>>
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El
>>>>>
>>>>> 17/9/20 2:21, "lucilla fornaro"
>>>>>
>>>>> <lucillafornarosawamoto at gmail.com
>>>>> <mailto:lucillafornarosawamoto at gmail.com>>
>>>>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Dear
>>>>>
>>>>> all,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I
>>>>>
>>>>> have some concerns about the
>>>>>
>>>>> ?Abuse Contact Policy?.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> First
>>>>>
>>>>> of all, it does not offer a
>>>>>
>>>>> specific and regulated
>>>>>
>>>>> description of the term
>>>>>
>>>>> ?abuse? and this opens the
>>>>>
>>>>> door to potentially bigger
>>>>>
>>>>> problems: a surplus of
>>>>>
>>>>> reports, discrimination/legal
>>>>>
>>>>> issues, and a waste of
>>>>>
>>>>> resources. Around the world,
>>>>>
>>>>> we can perceive what abuse is
>>>>>
>>>>> in very different ways.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Afrinic
>>>>>
>>>>> is not entitled to force
>>>>>
>>>>> members to report abuses and
>>>>>
>>>>> most importantly, this
>>>>>
>>>>> proposal does not represent
>>>>>
>>>>> Afrinic?s purpose.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I,
>>>>>
>>>>> therefore, oppose this policy.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thank
>>>>>
>>>>> you,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lucilla
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>>
>>>>>
>>>>> IPv4 is over
>>>>>
>>>>>
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>>
>>>>>
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> IPv4 is over
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le jeu.
>>>>>
>>>>> 17 sept. 2020 ? 15:49, JORDI
>>>>> PALET MARTINEZ via
>>>>>
>>>>> RPD <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>>
>>>>> a ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>> Lamiaa,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I?ve
>>>>>
>>>>> said this already. This policy
>>>>> doesn?t
>>>>>
>>>>> enforce abuse, it enforces
>>>>> that the abuse
>>>>>
>>>>> contact is there, and works.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Today
>>>>>
>>>>> AFRINIC is paying for the cost
>>>>> of the abuse
>>>>>
>>>>> handling because only a tiny
>>>>> fraction of the
>>>>>
>>>>> members has the abuse contacts
>>>>> in place.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If the
>>>>>
>>>>> contacts in the RIR database
>>>>> aren?t actual
>>>>>
>>>>> and accurate, this is a clear
>>>>> violation of
>>>>>
>>>>> the RSA. So what is
>>>>> unacceptable is not
>>>>>
>>>>> having the contacts, not on
>>>>> the other way
>>>>>
>>>>> around.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Abuse is
>>>>>
>>>>> not defined by the RIRs,
>>>>> everybody knows it
>>>>>
>>>>> and this is the reason why
>>>>> NONE of the RIRs
>>>>>
>>>>> have re-defined it, because it
>>>>> is already
>>>>>
>>>>> stated in RFC2142. Can you
>>>>> justify why
>>>>>
>>>>> AFRINIC is different and need
>>>>> a definition?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> How you
>>>>>
>>>>> define it in the networks that
>>>>> you operate?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Jordi
>>>>>
>>>>>
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El 17/9/20
>>>>>
>>>>> 10:49, "Lamiaa Chnayti"
>>>>> <lamiaachnayti at gmail.com
>>>>> <mailto:lamiaachnayti at gmail.com>>
>>>>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I
>>>>>
>>>>> will have to agree with
>>>>> Lucilla on what
>>>>>
>>>>> she said and would like to add
>>>>> to it that
>>>>>
>>>>> :
>>>>>
>>>>>
>>>>>
>>>>> Firstly, Abuse
>>>>>
>>>>> enforcement is out of scope
>>>>> for RIRs.
>>>>>
>>>>>
>>>>>
>>>>> Secondly, RIRs
>>>>>
>>>>> have no ability to define what
>>>>> is ?abuse?,
>>>>>
>>>>> one abuse or even criminal
>>>>> activity could
>>>>>
>>>>> be entirely a legal operation in a
>>>>>
>>>>> different jurisdiction.
>>>>>
>>>>>
>>>>>
>>>>> Finally, making
>>>>>
>>>>> a member forcefully reply to
>>>>> abuse contact
>>>>>
>>>>> Emails are a waste of
>>>>> resources and
>>>>>
>>>>> totally pointless, it is
>>>>> entirely up to
>>>>>
>>>>> the member to define what they
>>>>> think is
>>>>>
>>>>> acceptable in their network
>>>>> operation and
>>>>>
>>>>> how they react to it. AFRINIC
>>>>> has no
>>>>>
>>>>> mandate to force any member to
>>>>> reply to an
>>>>>
>>>>> ?abuse?, since AFRINIC doesn?t
>>>>> even have
>>>>>
>>>>> the ability to identify what
>>>>> is considered
>>>>>
>>>>> an abuse.
>>>>>
>>>>>
>>>>>
>>>>> Therefore the
>>>>>
>>>>> entire policy is out of scope
>>>>> for the RIR
>>>>>
>>>>> operation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le jeu. 17
>>>>>
>>>>> sept. 2020 ? 07:42, JORDI
>>>>> PALET MARTINEZ
>>>>>
>>>>> via RPD <rpd at afrinic.net
>>>>> <mailto:rpd at afrinic.net>>
>>>>>
>>>>> a ?crit :
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>> Lucilla,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Today
>>>>>
>>>>> we already have mnt-IRT, and
>>>>>
>>>>> everybody who operate networks
>>>>>
>>>>> understand what it is an abuse. If
>>>>>
>>>>> you operate networks you know
>>>>> that *anything*
>>>>>
>>>>> which is a non-authorized use of a
>>>>>
>>>>> network is an abuse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If
>>>>>
>>>>> you send spam, attack
>>>>> networks, try
>>>>>
>>>>> to intrude networks, etc., all
>>>>> those
>>>>>
>>>>> are abuse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What
>>>>>
>>>>> the policy ask is to make sure
>>>>> that
>>>>>
>>>>> in AFRINIC everybody has an abuse
>>>>>
>>>>> contact (today we have
>>>>> mnt-IRT, but
>>>>>
>>>>> is not mandatory, and as a results
>>>>>
>>>>> many African networks are filtered
>>>>>
>>>>> because lack of that ? and
>>>>>
>>>>> consequently they do not
>>>>> respond to
>>>>>
>>>>> abuse cases -, which exist in all
>>>>>
>>>>> the other regions of the world).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not having an abuse
>>>>>
>>>>> means more chances of legal
>>>>>
>>>>> actions, more cost, for both the
>>>>>
>>>>> victims and the ISPs. Having that
>>>>>
>>>>> means that you have more chances
>>>>>
>>>>> to resolve it in goodfaith.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> One of the *most
>>>>>
>>>>> important* Afrinic missions
>>>>>
>>>>> is to have accuracy on the
>>>>>
>>>>> database, which includes accuracy
>>>>>
>>>>> on the contacts. We are not
>>>>>
>>>>> fulfilling that in this situation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Remember that *all*
>>>>>
>>>>> the other RIRs have already this
>>>>>
>>>>> kind of policy. This one is like
>>>>>
>>>>> the one that has been implemented
>>>>>
>>>>> in APNIC, and the accuracy of the
>>>>>
>>>>> contacts is now 87.5% as reported
>>>>>
>>>>> this month in the last APNIC
>>>>>
>>>>> meeting. In that report *none*
>>>>>
>>>>> of the members indicated any of
>>>>>
>>>>> the issues that you indicated
>>>>>
>>>>> (didn't happened as well in the
>>>>>
>>>>> other regions).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You know who is
>>>>>
>>>>> interested in not having abuse
>>>>>
>>>>> contacts? Those that use their
>>>>>
>>>>> networks for doing abuse
>>>>>
>>>>> (hijacking, spam, DoS, intrusions,
>>>>>
>>>>> etc.).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Can you explain if
>>>>>
>>>>> the network that you operate has
>>>>>
>>>>> an abuse contact an how if one of
>>>>>
>>>>> your customes is trying to
>>>>>
>>>>> penetrate my network or do a DoS,
>>>>>
>>>>> I will be able to contact you and
>>>>>
>>>>> if you will do anything or just
>>>>>
>>>>> ignore it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Jordi
>>>>>
>>>>>
>>>>>
>>>>> @jordipalet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El
>>>>>
>>>>> 17/9/20 2:21, "lucilla fornaro"
>>>>>
>>>>> <lucillafornarosawamoto at gmail.com
>>>>> <mailto:lucillafornarosawamoto at gmail.com>>
>>>>>
>>>>> escribi?:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Dear
>>>>>
>>>>> all,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I
>>>>>
>>>>> have some concerns about the
>>>>>
>>>>> ?Abuse Contact Policy?.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> First
>>>>>
>>>>> of all, it does not offer a
>>>>>
>>>>> specific and regulated
>>>>>
>>>>> description of the term ?abuse?
>>>>>
>>>>> and this opens the door to
>>>>>
>>>>> potentially bigger problems: a
>>>>>
>>>>> surplus of reports,
>>>>>
>>>>> discrimination/legal issues, and
>>>>>
>>>>> a waste of resources. Around the
>>>>>
>>>>> world, we can perceive what
>>>>>
>>>>> abuse is in very different ways.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Afrinic
>>>>>
>>>>> is not entitled to force members
>>>>>
>>>>> to report abuses and most
>>>>>
>>>>> importantly, this proposal does
>>>>>
>>>>> not represent Afrinic?s purpose.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I,
>>>>>
>>>>> therefore, oppose this policy.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thank
>>>>>
>>>>> you,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lucilla
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>>
>>>>>
>>>>> IPv4 is over
>>>>>
>>>>>
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>>
>>>>>
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> IPv4 is over
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lamiaa
>>>>>
>>>>> CHNAYTI
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>>
>>>>>
>>>>> IPv4 is over
>>>>>
>>>>>
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>>
>>>>>
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> RPD mailing list
>>>>>
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> RPD mailing list
>>>>>
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>> --
>>>>>
>>>>> Lamiaa CHNAYTI
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new
>>>>> Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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.
>>>>>
>>>>> -------------- next part
>>>>> --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL:
>>>>> <https://lists.afrinic.net/pipermail/rpd/attachments/20200921/38d79b2f/attachment.html
>>>>> <https://lists.afrinic.net/pipermail/rpd/attachments/20200921/38d79b2f/attachment.html>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Subject: Digest Footer
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> End of RPD Digest, Vol 168,
>>>>> Issue 143
>>>>> *************************************
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> RPD mailing list
>>>>>
>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list RPD at afrinic.net
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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 <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com
>>>>> <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
>>>>> <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 <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>> _______________________________________________
>>>>> RPD mailing list
>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>>
>>>>>
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com <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 <mailto:RPD at afrinic.net>
>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>> _______________________________________________
>>>> RPD mailing list
>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>> <https://lists.afrinic.net/mailman/listinfo/rpd>
>>>>
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net <mailto: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/20200928/a1256650/attachment-0001.html>
More information about the RPD
mailing list