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

Lu Heng h.lu at anytimechinese.com
Tue Oct 3 04:28:43 UTC 2017


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/88ef8f1b/attachment.html>


More information about the Community-Discuss mailing list