> On Jul 14, 2015, at 13:00, Adam Thompson <[email protected]> wrote:
> 
> "... parents own a controlling share" language would cause me to argue 
> against it.
> There are other entities using /28s inside my /24 that I'd like to SWIP just 
> to avoid the abuse@ notifications (one of them has generated a few already!), 
> but although there's a good technical and contractual justification for 
> giving those entities their own distinct subnets, they have nothing more than 
> a contractual relationship with me. Yet I'm still not an ISP as far as I'm 
> concerned.
> 

By policy definition, you are, actually. 

Owen

> At the moment, because I'm an "end-user", I cannot update the registry with 
> factually-correct data. I would hope that the original proposal allows for 
> scenarios like mine. I'm absolutely certain, being personally aware of dozens 
> of similar situations, that there are massive amounts of "stealth" 
> delegations happening under ARIN's radar.
> 
> -Adam
> 
> 
>> On July 14, 2015 10:08:24 AM CDT, "Gary T. Giesen" 
>> <[email protected]> wrote:
>> Andrew,
>> 
>> Is it your intention to create a single class of users (ie. no more End-User 
>> vs ISP), or maintain the distinction? I'd like to see end-users be able to 
>> SWIP, but I'd don't want to see their costs increase because of it. Also, 
>> ISPs will argue if end-users can SWIP (which is probably the biggest 
>> technical distinction between the two right now ) and pay far less, they'll 
>> either argue their fees should be lowered, the end users fees should be 
>> raised, or try to game the system by applying as end-users.
>> 
>> Do we have any indication from ARIN staff as to what the implications in 
>> terms of cost/workload would be if end-users would be allowed to SWIP? 
>> Again, if the impact is minimal (ie no raising of end-user fees) and 
>> sufficient language was put around who they could SWIP to (ie only 
>> organizations in which the parent owns a controlling share, etc) then I 
>> would support this.
>> 
>> Cheers,
>> 
>> GTG 
>> 
>>>  -----Original Message-----
>>>  From: [email protected] [mailto:[email protected]] On
>>>  Behalf Of Andrew Dul
>>>  Sent: July 13, 2015 11:31 AM
>>>  To: [email protected]
>>>  Subject: [arin-ppml] Policy Proposal Idea: Reassignment records for IPv4 
>>> End-
>>>  Users
>>>  
>>>  The AC has been discussing the following ideas on their list and I have 
>>> drafted
>>>  the following policy proposal as an outcome.  We are posting the ideas and
>>>  proposal here to PPML for community discussion.  This draft has not been
>>>  submitted formally to the PDP process at this point.  I believed having 
>>> initial
>>>  feedback from the community before submitting would be a valuable
>>>  addition before going into the formal process.
>>>  
>>>  You comments are welcome.
>>>  
>>>  Thanks,
>>>  Andrew
>>>  
>>>  
>>>  ====
>>>  
>>>  Template:
>>> ARIN-POLICY-PROPOSAL-TEMPLATE-3.0
>>>  
>>>  1.    Policy Proposal Name: Reassignment records for IPv4 End-Users
>>>  
>>>  4.    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)
>>>  -    Ass
>>>  ignment
>>> 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)
>>>  
>>>  
>>>  5.    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.
>>>  
>>>  6.    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.
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> 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.

Reply via email to