[rpd] Implementation of transfer policy AFPUB-2016-V4-003

[Lu Heng]

On Thu, Sep 7, 2017 at 20:53 Owen DeLong <owen at delong.com> wrote:

> Wouldn’t it make the most sense for the RSA to eliminate all language
> referencing
> resource management directly and instead include language to the effect of:
>
> This RSA is subject to the community developed consensus policies
> contained in
> the consolidated policy manual which is incorporated here by reference.
> This
> agreement shall be considered amended in accordance to each subsequent
> change
> to those policies and the signatories accept in advance all such amendments
> as determined appropriate by the consensus of the community and ratified by
> the AfriNIC board.
>
> Please feel free to word-smith or improve upon the general idea above, but
> I believe
> this would create a long-term solution to the issues of the RSA while
> still preserving
> the policy supremacy and keeping the policy control in the hands of the
> current process.
>
> Owen


+1

>
>
> > On Aug 31, 2017, at 20:10 , David Hilario <
> d.hilario at laruscloudservice.net> wrote:
> >
> > On 31 August 2017 at 23:18, Noah <noah at neo.co.tz> wrote:
> >>
> >>
> >> On Thu, Aug 31, 2017 at 12:39 PM, Alan Barrett <
> alan.barrett at afrinic.net>
> >> wrote:
> >>>
> >>>
> >>>> On 25 Aug 2017, at 16:02, Noah <noah at neo.co.tz> wrote:
> >>>> We should  get the Legal Counsel to also look at the matter and
> advise.
> >>>> Too sensitive.
> >>>
> >>> The legal adviser has provided advice to me on many occasions.  When I
> try
> >>> to summarise his advice, I may make mistakes in minor details, but I
> am not
> >>> making a mistake about the main point: The current RSA prohibits
> transfers
> >>> (except for mergers and acquisitions), and removing that prohibition
> will
> >>> require changing the RSA.
> >>
> >>
> >>
> >> Remove the prohibitions to transfers to allow only specific transfers
> which
> >> are "IPv4 Resources transfer within the AFRINIC Region".
> >>
> >>
> >>
> >>>
> >>>> RSA is the contractual agreement which introduce and enforce  policies
> >>>> and  has clearly solved cases of conflict between itself and policies.
> >>>> What I  am trying to say is that we have to be mindful of the fact
> that
> >>>> the policies supersede the RSA which depends on them and as much as we
> >>>> members are subjected to the RSA, policies reign supreme.
> >>>
> >>> The policies express the will of the community.  The RSA is a legal
> >>> agreement.  If the will of the community conflicts with the RSA, then
> the
> >>> community will expext the RSA to be changed.  That’s what’s about to
> happen.
> >>
> >>
> >>
> >> The changes have to be specific to the will of the community in this
> case
> >> "IPv4 Resources transfer within the AFRINIC Region" and not generic
> transfer
> >> or any other transfers.
> >>
> >>
> >>>
> >>>>> The RSA also has a clause that says "except in the event of The
> >>>>> Applicant becoming the subject of merger and/or acquisition
> proceedings, the
> >>>>> transfer of number resources is strictly prohibited”.   Even if
> there’s a
> >>>>> policy that allows transfers, the RSA prohibits transfers, and the
> member
> >>>>> has agreed to follow the RSA, so the member may not make a transfer.
> >>>>
> >>>> This is not valid if the RSA is subject to policies.   If policies say
> >>>> member can transfer, then policy overrides any provisions of the  RSA
> with
> >>>> regards to this aspect.
> >>>
> >>> “This agreement is subject to policies” means “policies can add
> additional
> >>> restrictions”; it does not mean that policies can remove restrictions.
> >>
> >>
> >>
> >> I am not sure I understood your statement above and disclaimer: 'as
> much as
> >> am not a lawyer',  and others in the community could advice but
> "subject to"
> >> means... conditional and being dependent upon something... see [1] [2]
> >>
> >> Therefore IMHO, RSA is subject to policies and that would mean in this
> case,
> >> subject to specifically the ratified policies only,  and for this case
> the
> >> AFPUB-2016-V4-003 "IPv4 Resources transfer within the AFRINIC Region".
> >>
> >> So the modification and wording of the updated RSA, ref: transfers ,
> should
> >> be specific to this policy to avoid creating loopholes using the word
> >> "transfer" as the only tranfers allowed per policy will be
> >> Intra/within/inside Afrinic service region and nothing else.
> >>
> >>
> >
> > Using this logic, we would still be using the RSA as a resource
> > management document and Policy enforcement.
> > We would basically never get rid of the initial problem.
> >
> > The RSA being a legal document and not a community document, it should
> > only describe the legal premise of signing up with the AFRINIC and not
> > get involved into the resource management.
> >
> > Implying that removing this restriction would allow inter-RIR transfer
> > is a bit far fetched, plus as far as I know, all RIRs have something
> > in the lines that they can only do inter-RIR transfers with RIR who
> > have a compatible inter-RIR transfer policy, no policy at AFRINIC,
> > means no transfers to or from other RIR.
> >
> > Don't manage resources through the RSA, that would even be
> > incompatible with other RIR, manage resources through policies.
> >
> > Following your logic, we would remain in a perpetual problem, and the
> > RSA will be in need of updates at any future policy update that
> > touches any resource topics that are in the RSA.
> >
> >>>
> >>>> In fact, how is this different from the current situation?
> >>>>
> >>>> 1. RSA set default rules ( prohibits transfers) and bind members to
> >>>> policies
> >>>> 2. Members sign RSA
> >>>> 3. RSA states Policies supremacy
> >>>> 4. Policy allows  certain transfer (intra region only) and states
> rules
> >>>> and conditions
> >>>
> >>> But your point 3 does not apply.  Perhaps it might be useful to say
> >>> something like that in a future version of the RSA, but it’s not in the
> >>> current RSA.
> >>>
> >>
> >> Why future versions of RSA. If current is being updated to reflect other
> >> changes, then add that there.
> >>
> >> Cheers,
> >> Noah
> >>
> >> [1] https://definitions.uslegal.com/s/subject-to/
> >>
> >> [2] http://thelawdictionary.org/subject-to/
> >>
> >>
> >> _______________________________________________
> >> RPD mailing list
> >> RPD at afrinic.net
> >> https://lists.afrinic.net/mailman/listinfo/rpd
> >>
> > David Hilario
> >
> > IP Manager
> >
> > Larus Cloud Service Limited
> >
> > p: +852 29888918  m: +359 89 764 1784
> > f: +852 29888068
> > a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
> > w: laruscloudservice.net
> > e: d.hilario at laruscloudservice.net
> >
> > _______________________________________________
> > 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
>
-- 
--
Kind regards.
Lu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170908/8f359bb1/attachment-0001.html>