[arin-tech-discuss] Multiple simple reassigns to a single customer?
Aaron Hughes
aaronh at bind.com
Fri Sep 16 17:33:01 EDT 2011
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/
More information about the arin-tech-discuss
mailing list