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

David Huberman dhuberma at arin.net
Fri Sep 16 16:20:13 EDT 2011


Hello Aaron,

Regarding the two processes I posted about, ARIN has no preference.
The design of the system supports both methods equally. My response
was intended to help brainstorm solutions that you might find helpful.

I think that if simple reassigns are preferred by your customers, then
the first method (creating a recipient customer org, then reassigning
a block of IP addresses to that org, and repeating every time you
reassign a distinct block) is best.  It's in-line with what's in Whois
today, as a plurality of the 4+ million Whois objects are simple
reassignment network records and their corresponding customer records.
If consistency in the data is paramount, however, then you might
choose to create an OrgID for a customer with more than one network
assignment, and submit detailed reassignments using that OrgID.

We support whichever works best for you and your customers!

Regards,
David

---
David R Huberman
ARIN Technical Specialist
(703) 227-9866







On 9/16/11 3:47 PM, "Aaron Hughes" <aaronh at bind.com> wrote:

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/




More information about the arin-tech-discuss mailing list