arin-tech-discuss Message

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

David,

Thank you again for the continued clarity into how the ARIN DB schema and process work. While I am always happy to discuss ideas on modifying the process and/or implementation tools, my Eye Of Sauron is focused on a working product. That being said, I had no intention of stepping on a brainstorm solutions discussion and do believe it will be helpful. Once my team and I complete our implementation, I will be more than happy to share our experience and suggestions.

For now, I will simply move the ARIN_Customer_ID association to the IP/IPv6 block rather than the customer record and create a new ARIN_Customer_ID per block for simple reassigns.

Cheers,
Aaron


On Fri, Sep 16, 2011 at 08:20:13PM +0000, David Huberman wrote:
> 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/

-- 

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/