[rpd] AFPUB-2019-V4-003-DRAFT02 - Resource Transfer Policy

[Paschal Ochang]

Hello Fernando,
please find below my comments in line.

On Thursday, September 24, 2020, Fernando Frediani <fhfrediani at gmail.com>
wrote:


> +1

>

> It is so obvious how much damage not having a minimum wait time can make

> to the resources in the region versus the 'benefits' that I find it really

> hard to understand how people keep defending not having any waiting period

> and let things loose.

>

I think the effect of not having  a minimum waiting time can be negated by
the justication of the need. Having a large waiting time can starve
processes of resources as justified by various  scheduling and allocation
algorithms.


> I think it is enough the fraud cases regarding resources, specially the

> one that happened in the region to say having these breaks is something

> positive to majority of organizations and make sure resources go to those

> who really justify them to get people connected to the internet, not just

> to speculate from them.

>

 the current cases of fraud does  not eliminate the need for this proposal.
The current cases of fraud also exist under the nose of an existing
Intra-RIR proposal. The fact that you have the police force does not mean
they will no longer be thieves.
Secondly I think the proposal caters for need justification which was a
major concern in Angola.


> Regards

> Fernando

> On 24/09/2020 08:14, JORDI PALET MARTINEZ via RPD 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

>

>


-- 
Kind regards,

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