Search RPD Archives
[rpd] AFPUB-2019-V4-003-DRAFT02 - Resource Transfer Policy
lucilla fornaro
lucillafornarosawamoto at gmail.com
Mon Sep 28 23:45:52 UTC 2020
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> 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
> ), 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>
> 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> 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>
> 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> 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> 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> wrote:
>
> Hi Ekaterina,
>
>
>
>
>
> El 24/9/20 12:25, "Ekaterina Kalugina" <kay.k.prof at gmail.com> escribió:
>
>
>
> Hey everyone,
>
>
>
> @JORDI PALET MARTINEZ <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>
> 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> 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>
> 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> 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> 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> 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 <anthony.ubah at gloworld.com>.ng
>
>
>
>
>
> On Mon, Sep 21, 2020 at 10:00 AM <rpd-request at afrinic.net> wrote:
>
> Send RPD mailing list submissions to
> rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
> rpd-request at afrinic.net
>
> You can reach the person managing the list at
> 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>
> To: rpd List <rpd at afrinic.net>
> Subject: [rpd] AFPUB-2019-V4-003-DRAFT02 - Resource Transfer Policy
> Message-ID: <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
> 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
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Sep 2020 11:00:01 +0200
> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> To: <rpd at afrinic.net>
> Subject: Re: [rpd] Abuse Contact Policy
> Message-ID: <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> 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> 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> 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>
>
> 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>
>
> 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>
>
> 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>
>
> 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>
>
> 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
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
> **********************************************
>
>
> IPv4 is over
>
>
> Are you ready for the new Internet ?
>
>
> http://www.theipv6company.com
>
>
> The IPv6 Company
>
>
>
>
>
> This electronic message contains
>
> information which may be privileged or
>
> confidential. The information is
>
> intended to be for the exclusive use
>
> of the individual(s) named above and
>
> further non-explicilty authorized
>
> disclosure, copying, distribution or
>
> use of the contents of this
>
> information, even if partially,
>
> including attached files, is strictly
>
> prohibited and will be considered a
>
> criminal offense. If you are not the
>
> intended recipient be aware that any
>
> disclosure, copying, distribution or
>
> use of the contents of this
>
> information, even if partially,
>
> including attached files, is strictly
>
> prohibited, will be considered a
>
> criminal offense, so you must reply to
>
> the original sender to inform about
>
> this communication and delete it.
>
>
>
>
>
> _______________________________________________
>
>
> RPD mailing list
>
>
> RPD at afrinic.net
>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
>
>
>
>
> **********************************************
>
>
>
>
>
> IPv4 is over
>
>
>
>
>
> Are you ready for the new Internet ?
>
>
>
>
>
> http://www.theipv6company.com
>
>
>
>
>
> The IPv6 Company
>
>
>
>
>
>
>
>
>
>
>
> This electronic message contains information
>
> which may be privileged or confidential. The
>
> information is intended to be for the
>
> exclusive use of the individual(s) named above
>
> and further non-explicilty authorized
>
> disclosure, copying, distribution or use of
>
> the contents of this information, even if
>
> partially, including attached files, is
>
> strictly prohibited and will be considered a
>
> criminal offense. If you are not the intended
>
> recipient be aware that any disclosure,
>
> copying, distribution or use of the contents
>
> of this information, even if partially,
>
> including attached files, is strictly
>
> prohibited, will be considered a criminal
>
> offense, so you must reply to the original
>
> sender to inform about this communication and
>
> delete it.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
>
>
> RPD mailing list
>
>
>
>
>
> RPD at afrinic.net
>
>
>
>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le jeu.
>
> 17 sept. 2020 ? 15:49, JORDI PALET MARTINEZ via
>
> RPD <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>
>
> 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>
>
> 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>
>
> 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
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
> **********************************************
>
>
> IPv4 is over
>
>
> Are you ready for the new Internet ?
>
>
> http://www.theipv6company.com
>
>
> The IPv6 Company
>
>
>
>
>
> This electronic message contains
>
> information which may be privileged or
>
> confidential. The information is
>
> intended to be for the exclusive use of
>
> the individual(s) named above and
>
> further non-explicilty authorized
>
> disclosure, copying, distribution or use
>
> of the contents of this information,
>
> even if partially, including attached
>
> files, is strictly prohibited and will
>
> be considered a criminal offense. If you
>
> are not the intended recipient be aware
>
> that any disclosure, copying,
>
> distribution or use of the contents of
>
> this information, even if partially,
>
> including attached files, is strictly
>
> prohibited, will be considered a
>
> criminal offense, so you must reply to
>
> the original sender to inform about this
>
> communication and delete it.
>
>
>
>
>
> _______________________________________________
>
>
> RPD mailing list
>
>
> RPD at afrinic.net
>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
>
>
>
>
> **********************************************
>
>
>
>
>
>
>
>
> IPv4 is over
>
>
>
>
>
>
>
>
> Are you ready for the new Internet ?
>
>
>
>
>
>
>
>
> http://www.theipv6company.com
>
>
>
>
>
>
>
>
> The IPv6 Company
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This electronic message contains information
>
> which may be privileged or confidential. The
>
> information is intended to be for the exclusive
>
> use of the individual(s) named above and further
>
> non-explicilty authorized disclosure, copying,
>
> distribution or use of the contents of this
>
> information, even if partially, including
>
> attached files, is strictly prohibited and will
>
> be considered a criminal offense. If you are not
>
> the intended recipient be aware that any
>
> disclosure, copying, distribution or use of the
>
> contents of this information, even if partially,
>
> including attached files, is strictly
>
> prohibited, will be considered a criminal
>
> offense, so you must reply to the original
>
> sender to inform about this communication and
>
> delete it.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
>
>
> RPD mailing list
>
>
>
>
>
> RPD at afrinic.net
>
>
>
>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Lamiaa
>
> CHNAYTI
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> **********************************************
>
>
> IPv4 is over
>
>
> Are you ready for the new Internet ?
>
>
> http://www.theipv6company.com
>
>
> The IPv6 Company
>
>
>
>
>
> This electronic message contains information which may be
>
> privileged or confidential. The information is intended to
>
> be for the exclusive use of the individual(s) named above
>
> and further non-explicilty authorized disclosure, copying,
>
> distribution or use of the contents of this information,
>
> even if partially, including attached files, is strictly
>
> prohibited and will be considered a criminal offense. If you
>
> are not the intended recipient be aware that any disclosure,
>
> copying, distribution or use of the contents of this
>
> information, even if partially, including attached files, is
>
> strictly prohibited, will be considered a criminal offense,
>
> so you must reply to the original sender to inform about
>
> this communication and delete it.
>
>
>
>
>
>
>
> _______________________________________________
>
>
> RPD mailing list
>
>
> RPD at afrinic.net
>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
>
>
>
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> --
>
> Lamiaa CHNAYTI
>
>
>
> _______________________________________________ RPD mailing list
> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20200921/38d79b2f/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> 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
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________ RPD mailing list
> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________ RPD mailing list
> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200929/a71acbcd/attachment-0001.html>
More information about the RPD
mailing list