[arin-tech-discuss] Multiple simple reassigns to a single customer?

[Aaron Hughes]

On Fri, Sep 16, 2011 at 01:43:56PM -0400, Schiller, Heather A wrote:
> Yuck.. The solution is to either generate multiple reassign simple records with no way to tie the 'organization'/customer to other records - or for everybody to generate separate "Real OrgIDs" and you have the same problem.. Of not being able to easily correlate records for the same company.

+1
 
> Wouldn't it be ideal to have companies obtain a single org id from ARIN - with ARIN doing some checking to see if they already have an ORG ID - and then the company gives that ORG id to their provider.  I don't think this is any more outrageous than requesting companies provide their TIN when they request resources from ARIN.

I don't see this as a viable option. The majority of our customers are not knowledgeable in this area and should not have to be. The onus is on us as LIRs & RIRs to make this easy for them & work to keep the SWIP data as accurate as possible.

We need to either be able to tie multiple resources to a customer record or have makeLink=TRUE work on OrgIDs we create. 

> Process-wise, there are two methods I can think of:
> 
> - if you're using simple reassignments, then you create a customer org record every time you reassign a distinct block of IP addresses.
>
> - if you're planning on multiple assignments to the same customer, you have the option of using the CREATE RECIPIENT ORG method, and doing a detailed reassignment to the OrgID.  Real OrgIDs can have an unlimited number of IP address blocks and AS numbers.

Which one of these two does ARIN prefer? I realize ARIN is working on documenting the process per the e-mail from Andy earlier today, however, for those of us stuck in a place where there is no other method for things such as IPv6 detailed reassigns and no reason to have multiple methods for SWIPing, we could really use some guidance here.

Additionally, I don't want to make the mistake of releasing IPAM software that has coded methods of this process and find out post release that we are not following the preferred method.

Thank you again for your time and help.

Cheers,
Aaron

> 
> Regards,
> 
> 
> David
> 
> 
> ---
> David R Huberman
> ARIN Technical Specialist
> (703) 227-9866
> 
> 
> 
> 
> 
> 
> 
> On 9/16/11 1:25 PM, "Aaron Hughes" <aaronh at bind.com> wrote:
> 
> I thought the process was:
> 1) Create a customer record
> 2) reassign simple
> if additional assignments needed:
> 	1) select stored arin_cust_id
> 	2) reassign to same arin_cust_id
> 
> But.. This is the response I get from the server when I attempt to simple reassign a second block:
> 
> What is the expected behavior and process?
> 
> Cheers,
> Aaron
> 
> (
>     [additionalInfo] => SimpleXMLElement Object
>         (
>         )
> 
>     [code] => E_ENTITY_VALIDATION
>     [components] => SimpleXMLElement Object
>         (
>             [component] => SimpleXMLElement Object
>                 (
>                     [message] => This customer organization already has a network assigned to it. You may only sub-delegate one simple reassignment per customer organization.
>                     [name] => customerHandle
>                 )
> 
>         )
> 
>     [message] => Payload entity failed to validate; see component messages for details.
> )
> 
> -- 
> 
> Aaron Hughes
> aaronh at bind.com
> +1-831-824-4161
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
> 
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss

-- 

Aaron Hughes 
aaronh at bind.com
+1-831-824-4161
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/