[Community-Discuss] Call for Comments on a Revision to the RSA

Tue Oct 3 05:29:54 UTC 2017

Hi,

I don't think you can remove all mention of IP address management from the
RSA *before* you have put policies in place to substitute them.

Perhaps you (or others) could propose a set of policies that replace the
"IP address management" intentions set forth in the RSA. When those new
policies are ratified in line with the PDP, removal of IP address
management from the RSA then becomes feasible.

Dewole.

On Mon, 2 Oct 2017 at 9:29 PM Lu Heng <h.lu at anytimechinese.com> wrote:

> Dear colleagues,
>
>
>
> I believe there are still massive amount of IP address management item
> inside the RSA.
>
>
>
> As mentioned by a number of people, the RSA should not contain IP address
> management item. Instead, it shall simply contain legal relationship and
> AFRINIC, and allow member to financially support AFRINIC as the community's
> secretary.
>
>
>
> The example being RIPE NCC's standard service agreement:
>
>
>
> https://www.ripe.net/publications/docs/ripe-673
>
>
>
> There is no single word in this legal document which mentions policy terms
> like "assignment, allocation", or how you should use your IP address. It
> simply refers everything to policy in which it should be.
>
>
>
> Below are the clauses that are directly related to IP address management
> as I have read (please feel free to add if anything is missing):
>
>
>
> *4(c)(i)The Applicant hereby irrevocably:*
>
>
>
> *(i)  Commits itself to using the services solely for the purpose for
> which it was requested. *
>
>
>
> *(If someone wants to transfer space, he/she is surely in valuation of
> committing himself/herself to using the service as it is the original
> purpose).*
>
>
>
> *4(c)(iv)  Hereby binds itself to:*
>
>
>
> *(1)  notify AFRINIC whenever its circumstances so change that it is no
> longer in need of the Internet number resources supplied or being supplied
> to it under a Registration Service Agreement;*
>
>
>
> *(2)  surrender to AFRINIC within 15 days of the service of the notice at
> (iv)(1) above the Internet number resources supplied or being supplied to
> it under a Registration Service Agreement; *
>
>
>
> *(So if someone no longer needs space, they should return it to AFRINIC?
> This is in direct contradiction of the purpose of transfer policy)*
>
>
>
> *6(d)(iii) that it is bestowed with an exclusive right of use of those
> numbering resources within the ambit of the “need” which it has justified
> in its application and for no other purpose during the currency of the
> present agreement;*
>
>
>
> *(What if need base may be removed in the future just as it is in RIPE
> region, should we change RSA again?)*
>
>
>
> *1(a)(ii) requested to facilitate and maintain a meaningful bottom-up
> policy development process that allows the community at large to define
> policies and rules which would govern and regulate the allocation and
> assignment of number resources to its members; such policies are adopted in
> accordance with as defined in its Constitution;*
>
>
>
> *1(a)(v) empowered to ensure equitable, economic and efficient
> assignment/allocation of number resources to its members according to
> adopted number resources management policies;*
>
>
>
> *6(d)(vii)that a transfer of number resources from a source to a recipient
> constitutes an allocation or an assignment to the recipient*
>
>
>
> (It's also an IP management item which should not be mentioned here.
> Rather, it shall be defined in the policy. What if we change the policy and
> there is no more allocation or assignment? Shall we call everything IP
> delegation and update RSA again?)
>
>
>
> *All the above are IP address management-related items which are defined
> by policy and are subject to the change of policy. They shouldn't be
> written inside RSA; rather, they should simply be referred to policy. As
> the one Owen Delong wrote earlier:*
>
>
>
>
>
>
>
>
> *This RSA is subject to the community developed consensus policies
> contained inthe consolidated policy manual which is incorporated here by
> reference. Thisagreement shall be considered amended in accordance to each
> subsequent changeto those policies and the signatories accept in advance
> all such amendmentsas determined appropriate by the consensus of the
> community and ratified bythe AfriNIC board.*
>
>
>
> One more thing, when considering the need of clarity and avoiding legal
> risk for AFRINIC:
>
>
>
> *4(b)(2) within the limits of applicable laws and/or regulations of the
> jurisdiction in which it operates.*
>
>
>
> Should we change the cause like the one in RIPE NCC's agreement:
>
>
>
> *9.4(e)if the Member fails to observe any rule of applicable law, which
> should be adhered to by the Member. The RIPE NCC shall only terminate the
> RIPE NCC Standard Service Agreement for this reason if this is required by
> law or upon receipt of a court order forcing the RIPE NCC to do so.*
>
>
>
> As it is very unclear how AFRINIC will be able to determine if the
> operation is within the limit of legal boundary, such determination is
> always in the hands of court of each jurisdiction, even police cannot
> determine whether someone operates legally or not.
>
>
>
> Kind regards,
>
>
>
> Lu
>
> On 3 October 2017 at 01:04, Adewole Ajao <dewole at tinitop.com> wrote:
>
>> On Mon, Oct 2, 2017 at 5:17 AM, Alan Barrett <alan.barrett at afrinic.net>
>> wrote:
>>
>>>
>>> > On 2 Oct 2017, at 15:29, Sander Steffann <sander at steffann.nl> wrote:
>>> > Just a quick comment on the wording. The notes say:
>>> >
>>> >> - The new 6(d)(vii) says that a transfer is a kind of allocation or
>>> assignment. Because of this, other parts of the RSA that refer to
>>> allocations or assignments will automatically cover transfers as well.
>>> >
>>> > That seems fine. However section 1(c)(i) says:
>>> >
>>> >> - “Services” may include, without limitation, an
>>> allocation/assignment or transfer of number resources.
>>> >
>>> > Depending on how someone wants to read it, that might be interpreted
>>> in a way that sets a precedent that says that transfers are not included in
>>> "allocation/assignment" by default and need to be mentioned explicitly.
>>> >
>>> > I know, I'm picking nits here, but for consistency and to avoid
>>> misinterpretations I think it would be better to either not mention "or
>>> transfers" here, or to explicitly include them in other places as well.
>>>
>>> Thanks.  I think we may be able to move the idea that a transfer is a
>>> kind of allocation or assignment to the definitions in 1(c), instead of a
>>> separate clause in 6(d)(viii).
>>>
>>
>> It appears (today) under the context of application and registration that
>> transfers may be treated the same as allocations and assignments.
>>
>> However, if for some unforeseen reason, it is decided in future (under
>> some unforeseen context) that a transfer is to be treated differently from
>> allocations and assignments, the documentation may become inconsistent. I
>> would favour an explicit mention of transfers everywhere *for now*
>> (given that we do not yet know transfers as well as we know allocations and
>> assignments).
>>
>> Number/Numbering inconsistency persists in 6d (iii):
>> *6d (iii) that it is bestowed with an exclusive right of use of those
>> numbering resources within the ambit of the “need” which it has justified
>> in its application and for no other purpose during the currency of the
>> present agreement;*
>>
>> Consider prefixing "transfer of number resources..." in 6d (v) with the
>> word "unauthorized" or something similar. I don't think we can say
>> something is *strictly* prohibited and in the same breath say it can be
>> done under certain conditions.
>> *(v) that the transfer of number resources is strictly prohibited, except
>> in the event of the Applicant becoming the subject of merger and/or
>> acquisition proceedings, or where such transfer is effected in compliance
>> with adopted policies;*
>>
>> Because a case may involve doing both (1) and (2) in 6d (viii), I believe
>> (1) should read (just for the sake of reducing legal maneuvering space for
>> an offender):
>> (1) remedy the breach, following directions from AFRINIC, *and/or. *
>>
>> *6d (viii) that in the event that it commits a breach in the use of
>> number resources*
>> *allocated or assigned to it, it shall:*
>> *(1) remedy the breach, following directions from AFRINIC, or*
>> *(2) return the affected number resources to AFRINIC.*
>>
>> Dewole.
>>
>> _______________________________________________
>> Community-Discuss mailing list
>> Community-Discuss at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/community-discuss
>>
>>
>
>
> --
> --
> Kind regards.
> Lu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20171003/12400d29/attachment.html>