[rpd] RPD Digest, Vol 181, Issue 10

Sun Oct 10 21:40:04 UTC 2021

On Sun, 10 Oct 2021 at 21:06, <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. Re: New version of policy Proposal - IPv4 Inter-RIR Resource
>       Transfers. (Owen DeLong)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Oct 2021 13:05:00 -0700
> From: Owen DeLong <owen at delong.com>
> To: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> Cc: rpd at afrinic.net
> Subject: Re: [rpd] New version of policy Proposal - IPv4 Inter-RIR
>         Resource Transfers.
> Message-ID: <C5001B90-0AB7-450B-940E-944CD821117B at delong.com>
> Content-Type: text/plain; charset="utf-8"
>
> Works for me. I now support.
>
> Owen
>
>
> > On Oct 10, 2021, at 00:39 , JORDI PALET MARTINEZ via RPD <
> rpd at afrinic.net> wrote:
> >
> > Hi Owen,
> >
> > So, 5.7:
> >
> > The resources to be transferred must be from an existing Resource Holder
> (including Legacy Resource Holders) in the AFRINIC service region/other
> RIRs.
> >
> > Note that the explicit mention to legacy resource holders is to avoid
> questioning about that in the impact analysis, or objections during the
> discussion because it is not sufficiently clear. Anyway, if the staff
> believes that this mention is not needed, I?m happy to remove it.
> > 5.7.1. I agree that it shouldn?t be an internal procedure but a policy.
> I proposed a policy about that, same as I did in other regions. In the case
> of AFRINIC it was not supported 2-3 years ago. I think is something to
> tackle once we have sorted out the transfers. Trying to do it at once, will
> create more obstacles for a possible consensus.
> >
> > 5.7.5.  I?m fine with your proposal:
> > ?All the transfers where the source is an AFRINIC resource member will
> be required to pass a pre-check in order to verify that the resources being
> transferred were allocated/assigned and used in accordance with the
> requirements in section 5.7.2.1?.
> > However, note that this doesn?t precludes AFRINIC doing other checks
> never mind you consider them as part of the pre-check or not. They can, as
> it is their obligation, review if the resources holders are following the
> RSA and CPM *at any time*. My wish to include ?RSA? in that sentence is to
> make sure that anyone reading the policy is transparently aware of that.
> Note also that what you see as possible RSA violation is precisely what I?m
> avoiding with the possible transfer failure in the next paragraph:
> > ?It can happen that a transfer fails due to the recipient failing to be
> compliant because the lack of proper documentation or non-compliance of the
> relevant rules, while the source passed the transfer pre-check. This
> proposal allows the successful transfer pre-check to be valid for up to 12
> months after the failed transfer; i.e AFRINIC will not initiate a
> recovery/reclamation process in this period.?
> >
> > So, it is clear that the act of making the resources available for
> transfer can NOT be construed as a violation of the usage requirements.
> >
> > Of course, if you declare ?I don?t need any more those resources, so I?m
> transferring them?, the transfer fails because the recipient can?t
> demonstrate the need, then you either actively search for another valid
> recipient or your network grows so you don?t need any more to transfer the
> resources and you are NOT violating the RSA/CPM.
> >
> > Is that clear or there is something broken in my rationale that I?m
> missing?
> >
> >
> > El 10/10/21 0:26, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>>
> escribi?:
> >
> >
> >
> >
> >> On Oct 9, 2021, at 02:10 , JORDI PALET MARTINEZ via RPD <
> rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
> >>
> >> Hi Owen,
> >>
> >>
> >> Below in-line.
> >>
> >>
> >> Regards,
> >> Jordi
> >>
> >> @jordipalet
> >>
> >>
> >>
> >>
> >>
> >> El 8/10/21 22:51, "Owen DeLong" <owen at delong.com <mailto:
> owen at delong.com>> escribi?:
> >>
> >>
> >>
> >>
> >>
> >>> On Oct 8, 2021, at 1:07 PM, JORDI PALET MARTINEZ via RPD <
> rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
> >>>
> >>> ?Hi Owen,
> >>>
> >>> The modification of 5.7 was done to add clarity to the text. I don?t
> understand where you see the problem, if there was no problem about
> reciprocity in the previous versions.
> >>>
> >>> This is the new text:
> >>> The resources to be transferred must be from an existing RIR member?s
> account or from a Legacy Resource Holder in the AFRINIC service
> region/other RIRs.
> >>
> >> There are lots of resource holders in other RIRs (at least in ARIN) who
> are not RIR members.
> >>
> >> The current wording precludes those resource holders from participating
> in said transfers.
> >>
> >>> It clearly says AFRINIC/other RIRs, so what I?m missing?
> >>
> >> That not all RIRs require membership to have resources. IIRC, this is
> the case with sponsored PI in RIPE as well.
> >>
> >>
> >> [Jordi] I should have noticed that, as I was the author of the IPv6 PI
> in RIPE, which resulted in the ?sponsored PI?. So, we have two choices here:
> >> 1.       Maybe this text is redundant. I don?t see an equivalent text
> in other RIRs, and trying to clarify was worse than not having it. Can the
> staff confirm if they really need this text or it has no impact to remove
> it, as it was in the previous versions? I don?t recall previous analysis
> impact requiring a clarification on that. In fact, these conditions are
> already somehow expressed with the text in 5.7.1.b) and 5.7.2.1. May be the
> only ?excluded case? is if a legacy holder has no registration of the
> resources in none of the RIRs ? is that happening or actually possible?
> >> 2.       Use the text that you proposed. In principle I?m fine with
> that. I will like to see inputs from others, and specially from the staff.
> We need to make sure that they don?t have any misunderstanding/issue with
> that. I know they will check with the analysis impact, but it should be
> possible to have a preliminary view on that?
> >
> > Why not just refer to ?resource holders? instead of ?members?
> >
> >>> Regarding 5.7.1, the M&A today is not a policy, but an internal
> procedure (as it happens in RIPE, for example). I don?t agree this should
> be an internal procedure, but that?s what we have today. My plan is to,
> once we have fixed this, make a proposal for that, but I think it is better
> to go step by step, so adding a reference will be breaking it in the future
> (or requiring one more change in this part of the text). It is not needed.
> If you look at the existing text for intra-RIR that it is in the policy
> manual today, there is no such reference.
> >>
> >> OK? Ugly, but ok.
> >>
> >> [Jordi] I don?t think it is ugly, there are other similar situations in
> the CPM. We could also just remove that text, as it was in previous
> versions. I think it is fine keeping it, may be as a foot note and not
> ?policy text? (such as ?note Mergers and Acquisitions (inter or intra) are
> not covered by this policy?. The idea was to ensure that the analysis
> impact doesn?t ?complain? about that. Will be that fine for the staff?
> >
> > There are many defects in the CPM. I consider them ugly.
> >
> > I was referring to the situation, not the text.
> >
> >
> >>
> >>
> >>
> >>> 5.7.5 is to make explicit something that was already there. When you
> attempt an intra-RIR transfer, *all* the parties are verified. This is the
> same in other RIRs. However, I?m also adding a ?protection? to the failed
> transfers, because today, if AFRINIC strictly follows the intra-RIR
> transfer and it fails because, for example, the destination doesn?t meet
> the policies, then the source will lose the resources, as he clearly
> demonstrated that doesn't need them and that?s the reason, he is willing to
> transfer.
> >>>
> >>> What your text for 5.7.5 is proposing seems to be a restriction of
> some of the RSA and CPM text. I don?t think that?s right, otherwise, each
> proposal or part of the CPM can actually ?change? what is already written
> in the RSA and/or CPM and create a mess.
> >>
> >> I am proposing not allowing staff to block a transfer because they
> decide they don?t like a registrant.
> >>
> >> I am not proposing limitations on other sections of the CPM, but
> limitations on the excuses staff can use to block a transfer to the
> criteria that can be measured objectively and without subjecting transfer
> participants (receive or supply) to arbitrary and capricious
> misinterpretations of the CPM by a staff which has shown a clear propensity
> to engage in same.
> >>
> >>
> >>
> >>> I?m happy to accept suggestions from anyone, as usual, but they should
> be reasonable and consistent.
> >>
> >> I believe that my suggestions were both reasonable and consistent, with
> the exception of the 5.7.1 as noted.
> >>
> >> [Jordi] I feel that you?re being too much suspicious about the staff
> and I understand the situation. However, we should not over-micro-manage.
> In my opinion the pre-check must be done based on the RSA mainly. If there
> is a problem with the RSA, let?s fix it there. Have you noticed that what
> you?re asking is already in 5.7.2? Do you think anything is missed there?
> Would you be ok if we just do something like:
> >>
> >> Actual:
> >> ?All the transfers where the source is an AFRINIC resource member, will
> be required to pass a pre-check in order verify that the resources being
> transferred were allocated/assigned and used following the RSA/CPM
> provisions.?
> >>
> >> Proposed:
> >> ?All the transfers where the source is an AFRINIC resource member, will
> be required to pass a pre-check in order verify that the resources being
> transferred were allocated/assigned and used following the RSA provisions
> and 5.7.2.1.?
> >
> > If we could make that slightly stronger, then yes?
> >
> > Altenrate proposal:
> >
> > ?All the transfers where the source is an AFRINIC resource member will
> be required to pass a pre-check in order to verify that the resources being
> transferred were allocated/assigned and used in accordance with the
> requirements in section 5.7.2.1?.
> >
> > Otherwise, the mere act of making the resources available for transfer
> can be construed as a violation of the usage requirements as currently
> written in the RSA. I think 5.7.2.1 is perfectly fine and adequately
> comprehensive if the pre-check scope is limited accordingly.
> >
> > Owen
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> > _______________________________________________
> > RPD mailing list
> > RPD at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo/rpd
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20211010/7b797fe7/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 181, Issue 10
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20211010/77d2dd73/attachment-0001.html>