I'd suggest something like this to define which entities reassignments can be performed to:
1) A business department, division or sector which is not legally distinct from address space holder 2) A subsidiary of the address space holder, where the parent has a controlling interest 3) A sister company of the address space holder, where the parent company of the address space holder holds a controlling interest in both daughter companies Of course, since I am neither a lawyer nor an expert in corporate structures this should be reviewed by legal, but my basic intention is that there be a single, common ownership between the address holder and the reassignees. I included #3 because there may be a subsidiary which handles IT/network services for its sister companies. Cheers, GTG > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Andrew Dul > Sent: August 27, 2015 12:38 PM > To: Gary T. Giesen; [email protected] > Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for > IPv4 End-Users > > > On 8/26/2015 12:08 PM, Gary T. Giesen wrote: > > Andrew, > > > > If that's your approach, why not create policy to create one class of > > user, and remove the distinction altogether? > I have contemplated such an approach and even drafted, about 2 years ago, > a post-IPV4-exhaustion policy rewrite, which collapsed the distinction > between ISPs and end-users. In discussing this idea within the AC and other > community members, they believed at that time that was too much for the > community to handle. The community in the past has noted that omnibus > style policy rewrites are generally not accepted by the larger community. > > This policy proposal is a way to start the discussion between the ISP / end- > user differences. If the wider community support the idea of fully collapsing > the two categories, we can continue that direction. If not, that is OK, too. > > > > ISPs pay more because they receive > > more in services, and because they make money "leasing" IPs. If you > > make it so that ISPs can get the same set of services as end users > > (and start applying as end-users), then end-user fees will have to > > increase appropriately, in order to avoid decreasing ARIN's overall > > revenues. A lot of end-users will not want that, to satisfy the wants > > of a few very large orgs, for a service which they may even not know > > exists (and have no desire to use it) > > > > All I'm talking about is putting in some language to guard against > > obvious fraud, and keep costs down for end-users (since they > > presumably won't have anywhere near the ratio of SWIPs/block). It's > > not going to stop an ISP determined to go the end-user route, but will > > hopefully steer the well-meaning ISPs down the correct path and could > > make it easier to revoke blocks for blatent fraud. > > Do you have any language that you'd like to see added to the draft such that > you could support it? > > > A lot of what's in the NRPM already is hard to enforce, but that > > doesn't stop us from trying to create policies for fair > > allocations/assignments, with reasonable controls. I think some plain > > language about what is and is not an acceptable SWIP for an end-user > > is appropriate. What I don't want to see if the ISP/end-user classes > > merging by being back-doored through a policy with no limits. > > Some of the examples of what I thought were acceptable reassignments I > put in the problem statement. Would you support those types of > reassignment records being allowed for end-users? > > Andrew > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > >> On Behalf Of Andrew Dul > >> Sent: August 26, 2015 2:34 PM > >> To: [email protected] > >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment > >> records > > for > >> IPv4 End-Users > >> > >> Shouldn't operators get to decide and be responsible for what records > >> they put in the database? I understand that the potential for > >> mis-use of > > additional > >> reassignments, but there is already that potential for ISPs. Do you > >> feel > > that > >> we need to address mis-use with ISP reassignments too? > >> > >> One could create all sorts of "schemes" to limit the ability of ISP > >> users > > to > >> "game" the system as end users. Fee per reassignment record, or 10 > >> reassignments per end-user w/ additional records costing more... > >> > >> Or maybe we just need to think about if the differences between ISPs > >> and end-users matter as much in a IPv4 depleted world. > >> > >> While this policy likely has downstream fee implications, it is not > > designed to > >> map to any particular fee structure. I haven't seen any details on > >> any proposed fee changes so I could not take that into account when > >> drafting > > this > >> policy. > >> > >> Andrew > >> > >> On 8/26/2015 10:18 AM, Gary T. Giesen wrote: > >>> I am opposed to the policy as written. > >>> > >>> There are few to no controls on who the end user can SWIP to, which > >>> I think will either result in ISPs applying as end-users to game the > >>> system, raise the cost for end users, or both. > >>> > >>> I assume this is trying to align the NRPM to ARIN's new fee > >>> structure which I believe is due in September? > >>> > >>> Cheers, > >>> > >>> GTG > >>> > >>>> -----Original Message----- > >>>> From: [email protected] > >>>> [mailto:[email protected]] > >>>> On Behalf Of ARIN > >>>> Sent: August 25, 2015 3:12 PM > >>>> To: [email protected] > >>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records > >>>> for > >>> IPv4 > >>>> End-Users > >>>> > >>>> Draft Policy ARIN-2015-8 > >>>> Reassignment records for IPv4 End-Users > >>>> > >>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted > >>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft > >> Policy. > >>>> Draft Policy ARIN-2015-8 is below and can be found at: > >>>> https://www.arin.net/policy/proposals/2015_8.html > >>>> > >>>> You are encouraged to discuss the merits and your concerns of Draft > >>>> Policy > >>>> 2015-8 on the Public Policy Mailing List. > >>>> > >>>> The AC will evaluate the discussion in order to assess the > >>>> conformance of > >>> this > >>>> draft policy with ARIN's Principles of Internet Number Resource > >>>> Policy as stated in the PDP. Specifically, these principles are: > >>>> > >>>> * Enabling Fair and Impartial Number Resource Administration > >>>> * Technically Sound > >>>> * Supported by the Community > >>>> > >>>> The ARIN Policy Development Process (PDP) can be found at: > >>>> https://www.arin.net/policy/pdp.html > >>>> > >>>> Draft Policies and Proposals under discussion can be found at: > >>>> https://www.arin.net/policy/proposals/index.html > >>>> > >>>> Regards, > >>>> > >>>> Communications and Member Services > >>>> American Registry for Internet Numbers (ARIN) > >>>> > >>>> > >>>> ## * ## > >>>> > >>>> > >>>> Draft Policy ARIN-2015-8 > >>>> Reassignment records for IPv4 End-Users > >>>> > >>>> Date: 25 August 2015 > >>>> > >>>> Problem statement: > >>>> > >>>> End-User Organizations do not have the ability to create > >>>> reassignment records in the number resource database. > >>>> > >>>> Reassignment records can be used for a number of different > >>>> functions which could benefit the overall desire to increase > >>>> database accuracy by allowing organizations to add additional details in > the database. > >>>> > >>>> The following reasons have been noted as positive reasons to allow > >>>> the creation of additional records. > >>>> - Geolocation (allows an organization to specify a different > >>>> location > >>> within the > >>>> database which is used by organizations creating geo-location by IP > >>> address > >>>> databases) > >>>> - Subsidiary reassignment (allows an organization to note that a > >>>> portion > >>> of > >>>> their netblock is in use by a different subsidiary entity) > >>>> - Assignment to contracted parties (some organizations have > >>>> contracts with other organizations which are operating networks > >>>> under agreements with the registrant, this allows the top-level > >>>> organizations to accurately > >>> specify the > >>>> organization operating the network in the number resource database) > >>>> - More specific contact information (some organizations operate > >>>> large networks which don't necessarily have the same technical or > >>>> abuse contact > >>>> information) > >>>> > >>>> Policy statement: > >>>> > >>>> Create new section 4.3.x > >>>> > >>>> End-user organizations which have an active registration services > >>> agreement > >>>> shall be permitted to create reassignment records in the number > >>>> resource database. Organizations shall use the guidelines outlined > >>>> in section 4.2.3 when creating reassignment records. > >>>> > >>>> Comments: > >>>> a. Timetable for implementation: immediately b. Anything else: > >>>> > >>>> It is noted by the author of this policy proposal that one of the > >>> distinctions in > >>>> the service between ISPs and End-Users has been the ability for an > >>>> organization to create reassignment records. > >>>> > >>>> This policy proposal stretches across responsibilities areas as it > >>>> impacts number policy, ARIN operational practice, and fees. > >>>> > >>>> Below we have noted the three areas and the different > responsibilities: > >>>> > >>>> A) Providing reassignment support for end-user assignments, for > >>>> those who wish to use it > >>>> > >>>> This is an ARIN Service issue - could be an suggestion/consultation > >>> process, > >>>> so long as any implied additional workload/cost can be accommodated > >>>> in budget and the community supports > >>>> > >>>> B) New requirement on end-users to provide reassignment > information > >>>> in certain circumstances so that ARIN will treat their usage > >>>> assertion > >>> credibly > >>>> This is a policy issue. These requirements should be vetted through > >>>> the > >>> policy > >>>> development process. > >>>> > >>>> C) Fee Implications of ISPs moving to end-user category > >>>> > >>>> This is Board issue, but first requires a community discussion or > >>> consultation > >>>> to be held to solicit community input on desired outcome. > >>>> _______________________________________________ > >>>> PPML > >>>> You are receiving this message because you are subscribed to the > >>>> ARIN Public Policy Mailing List ([email protected]). > >>>> Unsubscribe or manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> Please contact [email protected] if you experience any issues. > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to the > >>> ARIN Public Policy Mailing List ([email protected]). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact [email protected] if you experience any issues. > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List ([email protected]). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact [email protected] if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
