From BDOLAN at optimumlightpath.com  Wed Nov  2 09:22:33 2011
From: BDOLAN at optimumlightpath.com (Bill Dolan)
Date: Wed, 02 Nov 2011 09:22:33 -0400
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <mailman.3.1320163201.17215.arin-tech-discuss@arin.net>
References: <mailman.3.1320163201.17215.arin-tech-discuss@arin.net>
Message-ID: <4EB10BD9020000520013A817@c3gwiaoutvs.cablevision.com>

David,
 
     Does this work in rest-beta.arin.net?  I am getting a 403 error.
 
Here is my request (in xml sorry):
  <?xml version="1.0" encoding="UTF-8"?>
- <httpheaders>
     <uri>/rest/net/NET-63-247-160-0-1/children?apikey=API-XXXX-XXXX-XXXX-XXXX</uri>
     <method>GET</method>
   - <otherHeaders>
      - <headerItem>
           <name>Content-type</name>
           <value>application/xml</value>
        </headerItem>
     </otherHeaders>
  </httpheaders>

Bill

--------------------------------------------------------  
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you've received and all copies thereof. 
--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20111102/a9548a22/attachment.html>

From mysidia at gmail.com  Wed Nov  2 22:17:56 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 2 Nov 2011 21:17:56 -0500
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <4EAF0133.5010204@gameservers.com>
References: <4EAF0133.5010204@gameservers.com>
Message-ID: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>

On Mon, Oct 31, 2011 at 3:12 PM, Brian Rak <brak at gameservers.com> wrote:
> Is there an API call that can be used to list all the reassignments for a
> specific network? ?We have some stale reallocation records that need to be
> cleaned up, but I can't seem to find a list of all the current networks that
> we have assigned.

Isn't there a WHOIS command for that?
something like, er

# telnet whois.arin.net 43
o >   ORGHANDLE


or e.g.
whois -h whois.arin.net   'o > ARIN'



--
-JH


From dhuberma at arin.net  Thu Nov  3 09:55:02 2011
From: dhuberma at arin.net (David Huberman)
Date: Thu, 3 Nov 2011 13:55:02 +0000
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <4EB10BD9020000520013A817@c3gwiaoutvs.cablevision.com>
Message-ID: <CAD814E2.B275%dhuberma@corp.arin.net>

Hi Bill,

The call is meant for http://whois.arin.net. I'm sorry if my earlier
message on the topic did not make this clear. Since the call is directed
to whois.arin.net, it's not authenticated. Accordingly, your uri can just
be formed as:

/rest/net/NET-63-247-160-0-1/children

Hope this helps :)

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 11/2/11 9:22 AM, "Bill Dolan" <BDOLAN at optimumlightpath.com> wrote:

David,
 
     Does this work in rest-beta.arin.net?  I am getting a 403 error.
 
Here is my request (in xml sorry):
  <?xml version="1.0" encoding="UTF-8"?>
- <httpheaders>
     
<uri>/rest/net/NET-63-247-160-0-1/children?apikey=API-XXXX-XXXX-XXXX-XXXX</
uri>
     <method>GET</method>
   - <otherHeaders>
      - <headerItem>
           <name>Content-type</name>
           <value>application/xml</value>
        </headerItem>
     </otherHeaders>
  </httpheaders>

Bill

--------------------------------------------------------
The information transmitted in this email and any of its attachments is
intended only for the person or entity to which it is addressed and may
contain information concerning Cablevision and/or its affiliates and
subsidiaries that is proprietary, privileged, confidential and/or subject
to copyright.   Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient(s) is prohibited and may be
unlawful.  If you received this in error, please contact the sender
immediately and delete and destroy the communication and all of the
attachments you&apos;ve received and all copies thereof.
--------------------------------------------------------___________________
____________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From dhuberma at arin.net  Thu Nov  3 09:58:20 2011
From: dhuberma at arin.net (David Huberman)
Date: Thu, 3 Nov 2011 13:58:20 +0000
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
Message-ID: <CAD8157C.B27A%dhuberma@corp.arin.net>

Hi Jimmy,

If you use port 43 whois, you can use the ! and > operators just like you
specified. A query like:

$ whois -h whois.arin.net '! > NET-99-0-0-0-1'

... would show you reassignments out of NET-99-0-0-0-1.  Please note,
however, that the result set is limited to 256 items. If there are more
than 256 reassignments, the result will truncate.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 11/2/11 10:17 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

On Mon, Oct 31, 2011 at 3:12 PM, Brian Rak <brak at gameservers.com> wrote:
> Is there an API call that can be used to list all the reassignments for a
> specific network?  We have some stale reallocation records that need to
>be
> cleaned up, but I can't seem to find a list of all the current networks
>that
> we have assigned.

Isn't there a WHOIS command for that?
something like, er

# telnet whois.arin.net 43
o >   ORGHANDLE


or e.g.
whois -h whois.arin.net   'o > ARIN'



--
-JH
_______________________________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From tstpierre at iweb.com  Fri Nov 18 14:26:23 2011
From: tstpierre at iweb.com (Thomas St.Pierre)
Date: Fri, 18 Nov 2011 14:26:23 -0500
Subject: [arin-tech-discuss] PHP class to reassign subnets via rest
Message-ID: <4EC6B15F.3070604@iweb.com>

Hi!

I've written a PHP class that sends a simple reassign to Arin. I'm 
releasing it in the hopes others find it useful and that it saves them 
time :) It first checks to see if there's an existing reassign for the 
subnet, and if there is it updates the customer object. Otherwise it 
creates a new Customer, then reassigns the subnet to them. Note there 
are some variables you need to set to get it working (your API-key, etc)

I included an example script that uses the reassign class. This is the 
script I used. It's not documented but it's not that complicated either. 
We had an existing script that pulled customer information out of our 
database and created a separate file for each reassign using the email 
template format. The example script parses the information from these 
files, scrubs any weird characters from the data (Arin really don't like 
accents etc! ) and then does the reassign.

Disclaimer: I'm not a programmer/developer by trade. I did my best to 
document the code I wrote, but the code is probably not the 
cleanest/most portable out there. I got it to the point that it was 
working for what I needed, and stopped there. Also, appologies if I got 
the licensing/copyright stuff wrong, I've never really released code 
before, so this is all new to me. :)

A note to Arin: It would be nice if there was a restful whois interface 
for the beta site. I looked but couldn't see one. :)

Here's the file: http://samoht.ca/reassign.class.tar.gz

Thanks!

-- 

Thomas St.Pierre
Network Administrator
iWeb Technologies
Email : tstpierre at iweb.com
Web : www.iweb.com
Tel : 514-286-4242 ext 2212



From andy at arin.net  Tue Nov 22 13:36:12 2011
From: andy at arin.net (Andy Newton)
Date: Tue, 22 Nov 2011 18:36:12 +0000
Subject: [arin-tech-discuss] PHP class to reassign subnets via rest
In-Reply-To: <4EC6B15F.3070604@iweb.com>
References: <4EC6B15F.3070604@iweb.com>
Message-ID: <28DD6186-1455-42A4-973A-F611F55F6C89@arin.net>

Thomas,

Thanks for the PHP class. We are discussing internally if there is some place we can accumulate these individual contributions. I'll let you know what we find.

I can see how a RESTful Whois system in the beta site would be useful, and we'll see what we can do. However, in the longterm I think we should look at creating the necessary REST methods in registration system to accommodate the needs for understanding which networks can be reassigned.

Andy Newton,
Chief Engineer
ARIN

On Nov 18, 2011, at 2:26 PM, Thomas St.Pierre wrote:

> Hi!
> 
> I've written a PHP class that sends a simple reassign to Arin. I'm releasing it in the hopes others find it useful and that it saves them time :) It first checks to see if there's an existing reassign for the subnet, and if there is it updates the customer object. Otherwise it creates a new Customer, then reassigns the subnet to them. Note there are some variables you need to set to get it working (your API-key, etc)
> 
> I included an example script that uses the reassign class. This is the script I used. It's not documented but it's not that complicated either. We had an existing script that pulled customer information out of our database and created a separate file for each reassign using the email template format. The example script parses the information from these files, scrubs any weird characters from the data (Arin really don't like accents etc! ) and then does the reassign.
> 
> Disclaimer: I'm not a programmer/developer by trade. I did my best to document the code I wrote, but the code is probably not the cleanest/most portable out there. I got it to the point that it was working for what I needed, and stopped there. Also, appologies if I got the licensing/copyright stuff wrong, I've never really released code before, so this is all new to me. :)
> 
> A note to Arin: It would be nice if there was a restful whois interface for the beta site. I looked but couldn't see one. :)
> 
> Here's the file: http://samoht.ca/reassign.class.tar.gz
> 
> Thanks!
> 
> -- 
> 
> Thomas St.Pierre
> Network Administrator
> iWeb Technologies
> Email : tstpierre at iweb.com
> Web : www.iweb.com
> Tel : 514-286-4242 ext 2212
> 
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From michael at rancid.berkeley.edu  Tue Nov 22 20:06:57 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 22 Nov 2011 17:06:57 -0800
Subject: [arin-tech-discuss] has the WHOIS CLI behavior reverted?
Message-ID: <4ECC4731.2@rancid.berkeley.edu>

On 10/2/11 ARIN changed the default whois CLI behavior so that the 
parent record of an assignment (belonging to ARIN or "various 
registries") wouldn't be displayed, and you wouldn't need to single out 
the record of the entity you were presumably looking for.  In other 
words, it was designed to _prevent_ this from happening:

%whois 128.32.0.0
#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 128.32.0.0"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# 
http://whois.arin.net/rest/nets;q=128.32.0.0?showDetails=true&showARIN=true&ext=netref2
#

University of California UCB-ETHER (NET-128-32-0-0-1) 128.32.0.0 - 
128.32.255.255
Various Registries (Maintained by ARIN) NET128 (NET-128-0-0-0-0) 
128.0.0.0 - 128.255.255.255


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

As of today, it appears that this behavior has returned.  Was there a 
reason for the reversion?  Or did I merely miss something and/or am 
smoking crack?



From michael at rancid.berkeley.edu  Tue Nov 22 20:54:35 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 22 Nov 2011 17:54:35 -0800
Subject: [arin-tech-discuss] has the WHOIS CLI behavior reverted?
In-Reply-To: <4ECC4731.2@rancid.berkeley.edu>
References: <4ECC4731.2@rancid.berkeley.edu>
Message-ID: <4ECC525B.4090004@rancid.berkeley.edu>

On 11/22/11 17:06, Michael Sinatra wrote:

> As of today, it appears that this behavior has returned. Was there a
> reason for the reversion? Or did I merely miss something and/or am
> smoking crack?

Oh, this is really weird.  Same query, done within 30 seconds of one 
another:

#1:

%whois -a 209.140.73.50
#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 209.140.73.50"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# 
http://whois.arin.net/rest/nets;q=209.140.73.50?showDetails=true&showARIN=false&ext=netref2
#

NetRange:       209.140.64.0 - 209.140.127.255
CIDR:           209.140.64.0/18
OriginAS:       AS6621
NetName:        AIRBORNE-NETWORK
NetHandle:      NET-209-140-64-0-1
Parent:         NET-209-0-0-0-0
NetType:        Direct Allocation
Comment:        www.row44.com
RegDate:        2011-01-21
Updated:        2011-01-24
Ref:            http://whois.arin.net/rest/net/NET-209-140-64-0-1

OrgName:        Row 44, Inc.
OrgId:          ROW44
Address:        31280 Oak Crest Dr.
City:           Westlake Villiage
StateProv:      CA
PostalCode:     91361
Country:        US
RegDate:        2010-02-09
Updated:        2010-08-04
Ref:            http://whois.arin.net/rest/org/ROW44

OrgAbuseHandle: BROWN28-ARIN
OrgAbuseName:   Browne, Chris
OrgAbusePhone:  +1-630-519-3322
OrgAbuseEmail:  noc at row44.com
OrgAbuseRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN

OrgTechHandle: BROWN28-ARIN
OrgTechName:   Browne, Chris
OrgTechPhone:  +1-630-519-3322
OrgTechEmail:  noc at row44.com
OrgTechRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN

OrgNOCHandle: BROWN28-ARIN
OrgNOCName:   Browne, Chris
OrgNOCPhone:  +1-630-519-3322
OrgNOCEmail:  noc at row44.com
OrgNOCRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

#2:

%whois -a 209.140.73.50
#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 209.140.73.50"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# 
http://whois.arin.net/rest/nets;q=209.140.73.50?showDetails=true&showARIN=true&ext=netref2
#

Row 44, Inc. AIRBORNE-NETWORK (NET-209-140-64-0-1) 209.140.64.0 - 
209.140.127.255
American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 
209.0.0.0 - 209.255.255.255


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Either we're load-balancing to a RESTful gateway that Didn't Get The 
Memo, or it's being worked on as we speak...

michael


From andy at arin.net  Tue Nov 22 21:57:19 2011
From: andy at arin.net (Andy Newton)
Date: Wed, 23 Nov 2011 02:57:19 +0000
Subject: [arin-tech-discuss] has the WHOIS CLI behavior reverted?
In-Reply-To: <4ECC525B.4090004@rancid.berkeley.edu>
References: <4ECC4731.2@rancid.berkeley.edu>
	<4ECC525B.4090004@rancid.berkeley.edu>
Message-ID: <F01F2BF1-0616-4C28-8512-08D6D5FC47BE@arin.net>

Michael,

We had to do some unscheduled maintenance on our Whois clusters today, and the setting for the old behavior was accidentally re-enabled. That has now been fixed. Sorry for the inconvenience, and thanks for making us aware of the problem.

Andy Newton,
Chief Engineer, ARIN

On Nov 22, 2011, at 8:54 PM, Michael Sinatra wrote:

> On 11/22/11 17:06, Michael Sinatra wrote:
> 
>> As of today, it appears that this behavior has returned. Was there a
>> reason for the reversion? Or did I merely miss something and/or am
>> smoking crack?
> 
> Oh, this is really weird.  Same query, done within 30 seconds of one another:
> 
> #1:
> 
> %whois -a 209.140.73.50
> #
> # Query terms are ambiguous.  The query is assumed to be:
> #     "n 209.140.73.50"
> #
> # Use "?" to get help.
> #
> 
> #
> # The following results may also be obtained via:
> # http://whois.arin.net/rest/nets;q=209.140.73.50?showDetails=true&showARIN=false&ext=netref2
> #
> 
> NetRange:       209.140.64.0 - 209.140.127.255
> CIDR:           209.140.64.0/18
> OriginAS:       AS6621
> NetName:        AIRBORNE-NETWORK
> NetHandle:      NET-209-140-64-0-1
> Parent:         NET-209-0-0-0-0
> NetType:        Direct Allocation
> Comment:        www.row44.com
> RegDate:        2011-01-21
> Updated:        2011-01-24
> Ref:            http://whois.arin.net/rest/net/NET-209-140-64-0-1
> 
> OrgName:        Row 44, Inc.
> OrgId:          ROW44
> Address:        31280 Oak Crest Dr.
> City:           Westlake Villiage
> StateProv:      CA
> PostalCode:     91361
> Country:        US
> RegDate:        2010-02-09
> Updated:        2010-08-04
> Ref:            http://whois.arin.net/rest/org/ROW44
> 
> OrgAbuseHandle: BROWN28-ARIN
> OrgAbuseName:   Browne, Chris
> OrgAbusePhone:  +1-630-519-3322
> OrgAbuseEmail:  noc at row44.com
> OrgAbuseRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN
> 
> OrgTechHandle: BROWN28-ARIN
> OrgTechName:   Browne, Chris
> OrgTechPhone:  +1-630-519-3322
> OrgTechEmail:  noc at row44.com
> OrgTechRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN
> 
> OrgNOCHandle: BROWN28-ARIN
> OrgNOCName:   Browne, Chris
> OrgNOCPhone:  +1-630-519-3322
> OrgNOCEmail:  noc at row44.com
> OrgNOCRef:    http://whois.arin.net/rest/poc/BROWN28-ARIN
> 
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html
> #
> 
> #2:
> 
> %whois -a 209.140.73.50
> #
> # Query terms are ambiguous.  The query is assumed to be:
> #     "n 209.140.73.50"
> #
> # Use "?" to get help.
> #
> 
> #
> # The following results may also be obtained via:
> # http://whois.arin.net/rest/nets;q=209.140.73.50?showDetails=true&showARIN=true&ext=netref2
> #
> 
> Row 44, Inc. AIRBORNE-NETWORK (NET-209-140-64-0-1) 209.140.64.0 - 209.140.127.255
> American Registry for Internet Numbers NET209 (NET-209-0-0-0-0) 209.0.0.0 - 209.255.255.255
> 
> 
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html
> #
> 
> Either we're load-balancing to a RESTful gateway that Didn't Get The Memo, or it's being worked on as we speak...
> 
> michael
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From brak at gameservers.com  Wed Nov 23 11:07:26 2011
From: brak at gameservers.com (Brian Rak)
Date: Wed, 23 Nov 2011 11:07:26 -0500
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <4ECD1A3E.3080809@gameservers.com>

Yes, they are.  The only way to get the full list is manually doing the 
CSV export via ARIN's site.  I'd love to see that changed in the future 
though, it's pretty tough to automate these updates when you can only 
get a partial list of them.

On 11/23/2011 11:05 AM, Schiller, Heather A wrote:
> Are the results truncated when you make a RESTful query? (apologies if this I the wrong way to say it, I'm really unsure of the grammar cases for "REST")
>
> --Heather
>
> -----Original Message-----
> From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of David Huberman
> Sent: Thursday, November 03, 2011 9:58 AM
> To: Jimmy Hess; Brian Rak
> Cc: arin-tech-discuss at arin.net
> Subject: Re: [arin-tech-discuss] Listing all reassignments?
>
> Hi Jimmy,
>
> If you use port 43 whois, you can use the ! and>  operators just like you specified. A query like:
>
> $ whois -h whois.arin.net '!>  NET-99-0-0-0-1'
>
> ... would show you reassignments out of NET-99-0-0-0-1.  Please note, however, that the result set is limited to 256 items. If there are more than 256 reassignments, the result will truncate.
>
> Regards,
> David
>
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
>
>
>
>
>
>
>
> On 11/2/11 10:17 PM, "Jimmy Hess"<mysidia at gmail.com>  wrote:
>
> On Mon, Oct 31, 2011 at 3:12 PM, Brian Rak<brak at gameservers.com>  wrote:
>> Is there an API call that can be used to list all the reassignments
>> for a  specific network?  We have some stale reallocation records that
>> need to be  cleaned up, but I can't seem to find a list of all the
>> current networks that  we have assigned.
> Isn't there a WHOIS command for that?
> something like, er
>
> # telnet whois.arin.net 43
> o>    ORGHANDLE
>
>
> or e.g.
> whois -h whois.arin.net   'o>  ARIN'
>
>
>
> --
> -JH
> _______________________________________________
> 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


From heather.schiller at verizon.com  Wed Nov 23 11:05:15 2011
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Wed, 23 Nov 2011 11:05:15 -0500
Subject: [arin-tech-discuss] Listing all reassignments?
In-Reply-To: <CAD8157C.B27A%dhuberma@corp.arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>


Are the results truncated when you make a RESTful query? (apologies if this I the wrong way to say it, I'm really unsure of the grammar cases for "REST") 

--Heather

-----Original Message-----
From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of David Huberman
Sent: Thursday, November 03, 2011 9:58 AM
To: Jimmy Hess; Brian Rak
Cc: arin-tech-discuss at arin.net
Subject: Re: [arin-tech-discuss] Listing all reassignments?

Hi Jimmy,

If you use port 43 whois, you can use the ! and > operators just like you specified. A query like:

$ whois -h whois.arin.net '! > NET-99-0-0-0-1'

... would show you reassignments out of NET-99-0-0-0-1.  Please note, however, that the result set is limited to 256 items. If there are more than 256 reassignments, the result will truncate.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 11/2/11 10:17 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

On Mon, Oct 31, 2011 at 3:12 PM, Brian Rak <brak at gameservers.com> wrote:
> Is there an API call that can be used to list all the reassignments 
>for a  specific network?  We have some stale reallocation records that 
>need to be  cleaned up, but I can't seem to find a list of all the 
>current networks that  we have assigned.

Isn't there a WHOIS command for that?
something like, er

# telnet whois.arin.net 43
o >   ORGHANDLE


or e.g.
whois -h whois.arin.net   'o > ARIN'



--
-JH
_______________________________________________
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


From andy at arin.net  Wed Nov 23 13:12:59 2011
From: andy at arin.net (Andy Newton)
Date: Wed, 23 Nov 2011 18:12:59 +0000
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements (was
 Re: Listing all reassignments?)
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>

All,

There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.

We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.

>From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?

There would appear to be two solutions for this use case:

1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.

2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address & end address) that are not already reassigned.

Do either of these solutions address the use case given? Would you solve this another way?

Thanks in advance for your feedback.

Andy Newton,
Chief Engineer, ARIN

From tstpierre at iweb.com  Wed Nov 23 13:49:11 2011
From: tstpierre at iweb.com (Thomas St.Pierre)
Date: Wed, 23 Nov 2011 13:49:11 -0500
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
Message-ID: <4ECD4027.5080105@iweb.com>

Hi!

Here are the use cases I encountered when I wrote a script to do 
reassigns. Maybe I missed some existing method, but the only (easy) way 
I found to do these was to query whois data.

1) For a given IP, (usually the network address of the subnet I'm about 
to reassign) find out what the parent NET HANDLE is. This is required 
for the net payload to do the reassign. (From my understanding of the 
documentation anyways)
2) For a given IP, find what the existing NET HANDLE and customer handle 
are. Useful for updating existing objects.

Hope this helps!

-- 

Thomas St.Pierre
Network Administrator
iWeb Technologies
Email : tstpierre at iweb.com
Web : www.iweb.com
Tel : 514-286-4242 ext 2212


On 11-11-23 1:12 PM, Andy Newton wrote:
> All,
>
> There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.
>
> We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.
>
> > From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?
>
> There would appear to be two solutions for this use case:
>
> 1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.
>
> 2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address&  end address) that are not already reassigned.
>
> Do either of these solutions address the use case given? Would you solve this another way?
>
> Thanks in advance for your feedback.
>
> Andy Newton,
> Chief Engineer, ARIN
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss


From brak at gameservers.com  Wed Nov 23 14:17:35 2011
From: brak at gameservers.com (Brian Rak)
Date: Wed, 23 Nov 2011 14:17:35 -0500
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
Message-ID: <4ECD46CF.8050805@gameservers.com>

We have our own database of what networks we have, and how they are 
divided.  There's a cron job that runs nightly that gets a list of all 
the reassignments from ARIN, and makes sure that they match what's in 
our database.  API calls for finding an available IP space within our 
allocations wouldn't really help us with this process.

The biggest help to us would be a way to get a list of all the 
reallocations for a specific subnet, rather then just the first 256.

On 11/23/2011 1:12 PM, Andy Newton wrote:
> All,
>
> There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.
>
> We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.
>
>  From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?
>
> There would appear to be two solutions for this use case:
>
> 1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.
>
> 2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address&  end address) that are not already reassigned.
>
> Do either of these solutions address the use case given? Would you solve this another way?
>
> Thanks in advance for your feedback.
>
> Andy Newton,
> Chief Engineer, ARIN


From andy at arin.net  Tue Nov 29 13:23:58 2011
From: andy at arin.net (Andy Newton)
Date: Tue, 29 Nov 2011 18:23:58 +0000
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <4ECD4027.5080105@iweb.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD4027.5080105@iweb.com>
Message-ID: <638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>

Thomas,

My response is inline.

On Nov 23, 2011, at 1:49 PM, Thomas St.Pierre wrote:

> 1) For a given IP, (usually the network address of the subnet I'm about to reassign) find out what the parent NET HANDLE is. This is required for the net payload to do the reassign. (From my understanding of the documentation anyways)

Because many registrants SWiP network blocks to themselves, this isn't as straightforward as one would hope. The logic may need to be "find the parent NET HANDLE for the most specific (or least specific) of my networks". I guess most specific is the proper logic, but I could easily be wrong about that. Another option to help solve that problem might be to return ALL the net handles for each network registered by a registrant given an IP. Because it is possible for a single API Key to have an authorization over multiple organizations, that query would also need to include an ORG Handle.

> 2) For a given IP, find what the existing NET HANDLE and customer handle are. Useful for updating existing objects.

Would the intent be to use this in a batch operation, such as a nightly syncing process, or more for updating objects on the fly? And if it is more of a batch mode, how do you decide which IP address to use?

This has been helpful.

Andy Newton

From aaronh at bind.com  Tue Nov 29 13:30:03 2011
From: aaronh at bind.com (Aaron Hughes)
Date: Tue, 29 Nov 2011 10:30:03 -0800
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD4027.5080105@iweb.com>
	<638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
Message-ID: <20111129183003.GE8052@trace.bind.com>

On Tue, Nov 29, 2011 at 06:23:58PM +0000, Andy Newton wrote:
> Thomas,
> 
> My response is inline.
> 
> On Nov 23, 2011, at 1:49 PM, Thomas St.Pierre wrote:
> 
> > 1) For a given IP, (usually the network address of the subnet I'm about to reassign) find out what the parent NET HANDLE is. This is required for the net payload to do the reassign. (From my understanding of the documentation anyways)
> 
> Because many registrants SWiP network blocks to themselves, this isn't as straightforward as one would hope. The logic may need to be "find the parent NET HANDLE for the most specific (or least specific) of my networks". I guess most specific is the proper logic, but I could easily be wrong about that. Another option to help solve that problem might be to return ALL the net handles for each network registered by a registrant given an IP. Because it is possible for a single API Key to have an authorization over multiple organizations, that query would also need to include an ORG Handle.

Something like this works just fine, however, if you have DESWIPPED make sure you set a 600 second timer for the whois database to update before you SWIP again otherwise you will match the block that no longer exists while waiting for whois to update.

Cheers,
Aaron
[snip]

  // GET PARENT NETWORK
  // Perform the transaction via cURL
  $ch = curl_init();
  $url = ARIN_WHOIS_URL . "/ip/" . $params['net_block']['address'];
  curl_setopt($ch, CURLOPT_URL, $url);
  curl_setopt($ch, CURLOPT_TIMEOUT, 4);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
  curl_setopt($ch, CURLOPT_HTTPHEADER, 0);
  if (!$debug) curl_setopt($ch, CURLOPT_MUTE, 1);

  $retval = curl_exec($ch);
  if ($debug) echo $retval;

  $info = curl_getinfo($ch);

  $response = "";
  if ($retval == false) {
    $res = "Failure:Get Parent Network:Could not connect. <br />";
    $response .= $res;
  }
  else if ($info['http_code'] != 200) {
    $res = "Failure:Get Parent Network:Return code is " . (int)($info['http_code']) . "<br />";
    $response .= $res;
  }
  else {
    $res = "Success";
    $response .= $res;
    $response .= $retval;
  }

  curl_close($ch);


> 
> > 2) For a given IP, find what the existing NET HANDLE and customer handle are. Useful for updating existing objects.
> 
> Would the intent be to use this in a batch operation, such as a nightly syncing process, or more for updating objects on the fly? And if it is more of a batch mode, how do you decide which IP address to use?
> 
> This has been helpful.
> 
> Andy Newton
> -- 
> 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/


From andy at arin.net  Tue Nov 29 13:30:59 2011
From: andy at arin.net (Andy Newton)
Date: Tue, 29 Nov 2011 18:30:59 +0000
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <4ECD46CF.8050805@gameservers.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD46CF.8050805@gameservers.com>
Message-ID: <8594D0BE-05D4-4471-A229-7E5A196B4B23@arin.net>

Brian,

As you stated previously, we do have reassignment information available in CSV format via reports within ARIN Online. Would a RESTful call for kicking off the reassignment report and subsequent calls for checking the status of it and downloading the report solve your problem?

Andy Newton,
Chief Engineer, ARIN

On Nov 23, 2011, at 2:17 PM, Brian Rak wrote:

> We have our own database of what networks we have, and how they are divided.  There's a cron job that runs nightly that gets a list of all the reassignments from ARIN, and makes sure that they match what's in our database.  API calls for finding an available IP space within our allocations wouldn't really help us with this process.
> 
> The biggest help to us would be a way to get a list of all the reallocations for a specific subnet, rather then just the first 256.
> 
> On 11/23/2011 1:12 PM, Andy Newton wrote:
>> All,
>> 
>> There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.
>> 
>> We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.
>> 
>> From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?
>> 
>> There would appear to be two solutions for this use case:
>> 
>> 1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.
>> 
>> 2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address&  end address) that are not already reassigned.
>> 
>> Do either of these solutions address the use case given? Would you solve this another way?
>> 
>> Thanks in advance for your feedback.
>> 
>> Andy Newton,
>> Chief Engineer, ARIN
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From aaronh at bind.com  Tue Nov 29 13:39:47 2011
From: aaronh at bind.com (Aaron Hughes)
Date: Tue, 29 Nov 2011 10:39:47 -0800
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <8594D0BE-05D4-4471-A229-7E5A196B4B23@arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD46CF.8050805@gameservers.com>
	<8594D0BE-05D4-4471-A229-7E5A196B4B23@arin.net>
Message-ID: <20111129183947.GF8052@trace.bind.com>

On Tue, Nov 29, 2011 at 06:30:59PM +0000, Andy Newton wrote:
> Brian,
> 
> As you stated previously, we do have reassignment information available in CSV format via reports within ARIN Online. Would a RESTful call for kicking off the reassignment report and subsequent calls for checking the status of it and downloading the report solve your problem?
> 
> Andy Newton,
> Chief Engineer, ARIN

This you can also do with a simple REST /nets/ query for a given orgid

  // Step 1: Get the list of net handles owned by this org
  $url = ARIN_WHOIS_URL . "/org/" . $orgid . "/nets";
  $xml_doc = http_get_xml($url);
  $res = Array();

  if ($xml_doc == null) {
    return $res;
  }

Then iterate over it..

  foreach ($xml_doc->children() as $childElem) {
    if (isset($childElem['handle'])) {
      $netRefs[] = $childElem['handle'];
    }
  }

Then nets..
foreach ($netRefs as $netRef) {
    $url = ARIN_WHOIS_URL . "/net/" . $netRef;
    $xml_doc = http_get_xml($url);

Then parse the XML.. etc..

Cheers,
Aaron


> 
> On Nov 23, 2011, at 2:17 PM, Brian Rak wrote:
> 
> > We have our own database of what networks we have, and how they are divided.  There's a cron job that runs nightly that gets a list of all the reassignments from ARIN, and makes sure that they match what's in our database.  API calls for finding an available IP space within our allocations wouldn't really help us with this process.
> > 
> > The biggest help to us would be a way to get a list of all the reallocations for a specific subnet, rather then just the first 256.
> > 
> > On 11/23/2011 1:12 PM, Andy Newton wrote:
> >> All,
> >> 
> >> There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.
> >> 
> >> We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.
> >> 
> >> From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?
> >> 
> >> There would appear to be two solutions for this use case:
> >> 
> >> 1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.
> >> 
> >> 2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address&  end address) that are not already reassigned.
> >> 
> >> Do either of these solutions address the use case given? Would you solve this another way?
> >> 
> >> Thanks in advance for your feedback.
> >> 
> >> Andy Newton,
> >> Chief Engineer, ARIN
> > _______________________________________________
> > 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/


From brak at gameservers.com  Tue Nov 29 13:44:37 2011
From: brak at gameservers.com (Brian Rak)
Date: Tue, 29 Nov 2011 13:44:37 -0500
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <20111129183947.GF8052@trace.bind.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD46CF.8050805@gameservers.com>
	<8594D0BE-05D4-4471-A229-7E5A196B4B23@arin.net>
	<20111129183947.GF8052@trace.bind.com>
Message-ID: <4ED52815.9020501@gameservers.com>

That's not quite what I was looking for.  /nets/ get me a list of the 
assignments we have directly from ARIN, but it does not show the 
reassignments we have made within them.  To clarify, we are using 
/net/HANDLE/children right now.  For example: 
http://whois.arin.net/rest/net/NET-108-61-0-0-1/children

API calls to retrieve the CSV list would likely work, but it does seem 
weird to be requesting a CSV via XML calls.

On 11/29/2011 1:39 PM, Aaron Hughes wrote:
> On Tue, Nov 29, 2011 at 06:30:59PM +0000, Andy Newton wrote:
>> Brian,
>>
>> As you stated previously, we do have reassignment information available in CSV format via reports within ARIN Online. Would a RESTful call for kicking off the reassignment report and subsequent calls for checking the status of it and downloading the report solve your problem?
>>
>> Andy Newton,
>> Chief Engineer, ARIN
> This you can also do with a simple REST /nets/ query for a given orgid
>
>    // Step 1: Get the list of net handles owned by this org
>    $url = ARIN_WHOIS_URL . "/org/" . $orgid . "/nets";
>    $xml_doc = http_get_xml($url);
>    $res = Array();
>
>    if ($xml_doc == null) {
>      return $res;
>    }
>
> Then iterate over it..
>
>    foreach ($xml_doc->children() as $childElem) {
>      if (isset($childElem['handle'])) {
>        $netRefs[] = $childElem['handle'];
>      }
>    }
>
> Then nets..
> foreach ($netRefs as $netRef) {
>      $url = ARIN_WHOIS_URL . "/net/" . $netRef;
>      $xml_doc = http_get_xml($url);
>
> Then parse the XML.. etc..
>
> Cheers,
> Aaron
>
>
>> On Nov 23, 2011, at 2:17 PM, Brian Rak wrote:
>>
>>> We have our own database of what networks we have, and how they are divided.  There's a cron job that runs nightly that gets a list of all the reassignments from ARIN, and makes sure that they match what's in our database.  API calls for finding an available IP space within our allocations wouldn't really help us with this process.
>>>
>>> The biggest help to us would be a way to get a list of all the reallocations for a specific subnet, rather then just the first 256.
>>>
>>> On 11/23/2011 1:12 PM, Andy Newton wrote:
>>>> All,
>>>>
>>>> There would appear to be a need for the discovery of assignment/allocation information in the Reg-RWS (RESTful provisioning) system, as there have been questions on this list as to how to obtain this information and there were some private conversations with members about this type of functionality at the Philadelphia meeting. Using Whois-RWS has been proposed as a work around, but it is not optimal as that system is designed for another need.
>>>>
>>>> We had on the drawing board some RESTful methods for providing this information in Reg-RWS but have never moved forward with them in part because we are not confident that we are addressing the need properly. So if you would indulge us, maybe we can tease out the use cases and perhaps formulate solutions here on this list.
>>>>
>>>>  From what I have observed, the use case is that a registration client needs to identify the boundaries of some IP space contained in a particular network (i.e. identified by a NET HANDLE) and of a specified size to be used in a reassignment. Is this correct? Is there another way to characterize this?
>>>>
>>>> There would appear to be two solutions for this use case:
>>>>
>>>> 1) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and the size of the space being sought and returns a start IP address and an end IP address.
>>>>
>>>> 2) A new RESTful method that takes as input the NET HANDLE from where the space is to be taken and returns a list of IP address ranges (start address&   end address) that are not already reassigned.
>>>>
>>>> Do either of these solutions address the use case given? Would you solve this another way?
>>>>
>>>> Thanks in advance for your feedback.
>>>>
>>>> Andy Newton,
>>>> Chief Engineer, ARIN
>>> _______________________________________________
>>> 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


From tstpierre at iweb.com  Tue Nov 29 13:52:24 2011
From: tstpierre at iweb.com (Thomas St.Pierre)
Date: Tue, 29 Nov 2011 13:52:24 -0500
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD4027.5080105@iweb.com>
	<638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
Message-ID: <4ED529E8.2050607@iweb.com>

Hi Andy!

1) I would think in my use case it would be the more specific network. 
There may be uses for the other options though.

2) I used it in a batch update, but I guess with any update it would be 
better to update an existing object rather then delete/recreate? As for 
the IP, I was going with the network IP of the subnet as I was querying 
the whois database. I'd then compare the result to make sure the network 
and subnet masks lined up with I had. It might make more sense querying 
network address and subnet mask you're looking after directly though.

Aaron, That's basically what I did in my code. The big problem I had 
with that is there's no whois interface to the rest-beta site. Therefore 
if you're developing against the beta site it makes it difficult to do 
some things as the data doesn't match up.

Thanks!

Thomas

On 11-11-29 1:23 PM, Andy Newton wrote:
> Thomas,
>
> My response is inline.
>
> On Nov 23, 2011, at 1:49 PM, Thomas St.Pierre wrote:
>
>> 1) For a given IP, (usually the network address of the subnet I'm about to reassign) find out what the parent NET HANDLE is. This is required for the net payload to do the reassign. (From my understanding of the documentation anyways)
> Because many registrants SWiP network blocks to themselves, this isn't as straightforward as one would hope. The logic may need to be "find the parent NET HANDLE for the most specific (or least specific) of my networks". I guess most specific is the proper logic, but I could easily be wrong about that. Another option to help solve that problem might be to return ALL the net handles for each network registered by a registrant given an IP. Because it is possible for a single API Key to have an authorization over multiple organizations, that query would also need to include an ORG Handle.
>
>> 2) For a given IP, find what the existing NET HANDLE and customer handle are. Useful for updating existing objects.
> Would the intent be to use this in a batch operation, such as a nightly syncing process, or more for updating objects on the fly? And if it is more of a batch mode, how do you decide which IP address to use?
>
> This has been helpful.
>
> Andy Newton


From aaronh at bind.com  Tue Nov 29 13:55:16 2011
From: aaronh at bind.com (Aaron Hughes)
Date: Tue, 29 Nov 2011 10:55:16 -0800
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <4ED529E8.2050607@iweb.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD4027.5080105@iweb.com>
	<638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
	<4ED529E8.2050607@iweb.com>
Message-ID: <20111129185516.GG8052@trace.bind.com>

On Tue, Nov 29, 2011 at 01:52:24PM -0500, Thomas St.Pierre wrote:
> Hi Andy!
> 
> 1) I would think in my use case it would be the more specific
> network. There may be uses for the other options though.

Such as import on a non-green field build :)

> 2) I used it in a batch update, but I guess with any update it would
> be better to update an existing object rather then delete/recreate?
> As for the IP, I was going with the network IP of the subnet as I
> was querying the whois database. I'd then compare the result to make
> sure the network and subnet masks lined up with I had. It might make
> more sense querying network address and subnet mask you're looking
> after directly though.
> 
> Aaron, That's basically what I did in my code. The big problem I had
> with that is there's no whois interface to the rest-beta site.
> Therefore if you're developing against the beta site it makes it
> difficult to do some things as the data doesn't match up.

Yup, I don't test my code, but when I do, I do it in production! :D <J>

I used real space and the prod environment to test having run into the same problem.

Cheers,
Aaron

> 
> Thanks!
> 
> Thomas
> 
> On 11-11-29 1:23 PM, Andy Newton wrote:
> >Thomas,
> >
> >My response is inline.
> >
> >On Nov 23, 2011, at 1:49 PM, Thomas St.Pierre wrote:
> >
> >>1) For a given IP, (usually the network address of the subnet I'm about to reassign) find out what the parent NET HANDLE is. This is required for the net payload to do the reassign. (From my understanding of the documentation anyways)
> >Because many registrants SWiP network blocks to themselves, this isn't as straightforward as one would hope. The logic may need to be "find the parent NET HANDLE for the most specific (or least specific) of my networks". I guess most specific is the proper logic, but I could easily be wrong about that. Another option to help solve that problem might be to return ALL the net handles for each network registered by a registrant given an IP. Because it is possible for a single API Key to have an authorization over multiple organizations, that query would also need to include an ORG Handle.
> >
> >>2) For a given IP, find what the existing NET HANDLE and customer handle are. Useful for updating existing objects.
> >Would the intent be to use this in a batch operation, such as a nightly syncing process, or more for updating objects on the fly? And if it is more of a batch mode, how do you decide which IP address to use?
> >
> >This has been helpful.
> >
> >Andy Newton
> -- 
> 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/


From andy at arin.net  Tue Nov 29 14:41:38 2011
From: andy at arin.net (Andy Newton)
Date: Tue, 29 Nov 2011 19:41:38 +0000
Subject: [arin-tech-discuss] Developing Reg-RWS discovery requirements
 (was Re: Listing all reassignments?)
In-Reply-To: <20111129185516.GG8052@trace.bind.com>
References: <CAAAwwbUWO8vq2uUO5Nqc_CTL_by2KGy7GA2FpnxbR=nRb5E7_g@mail.gmail.com>
	<CAD8157C.B27A%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E14F956A01F@FHDP1LUMXC7V43.us.one.verizon.com>
	<A56AD243-4D1F-42F7-B828-8BCA8D57D9E2@arin.net>
	<4ECD4027.5080105@iweb.com>
	<638CD275-BA21-4AA8-AF73-E891B64B171B@arin.net>
	<4ED529E8.2050607@iweb.com> <20111129185516.GG8052@trace.bind.com>
Message-ID: <38D80B7A-3C08-4278-8012-6540B64D6107@arin.net>


On Nov 29, 2011, at 1:55 PM, Aaron Hughes wrote:

>> Aaron, That's basically what I did in my code. The big problem I had
>> with that is there's no whois interface to the rest-beta site.
>> Therefore if you're developing against the beta site it makes it
>> difficult to do some things as the data doesn't match up.
> 
> Yup, I don't test my code, but when I do, I do it in production! :D <J>
> 
> I used real space and the prod environment to test having run into the same problem.

The process we use to migrate data out of the registration database into the Whois clusters can be extremely I/O intensive. And our beta environment is virtualized, which means this migration process would be SLOW SLOW SLOW since virtual systems don't handle disk I/O very well. However, it would appear adding Whois-RWS to the beta site would be useful even if a more comprehensive solution is needed, so we will look into finding the necessary real hardware to accomplish this goal.

Andy Newton

From david.ramage at chartercom.com  Wed Nov 30 13:27:35 2011
From: david.ramage at chartercom.com (Ramage, David)
Date: Wed, 30 Nov 2011 12:27:35 -0600
Subject: [arin-tech-discuss] 403 Errors when trying to create a customer
Message-ID: <6D32C57B73284D45B48A7F2E79320E070CD0545D@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>

Hey folks,
I'm running across some 403 errors when I try to hit rest-beta.arin.net.  I'm probably missing something obvious here, but I'm not seeing it.

In this particular case I'm trying to POST to https://rest-beta.arin.net/rest/net/[my net handle]/customer?apikey=[my api key].  It looks like the XML is being sent, but I'm getting the 403 back.  

Here's a sanitized Data::Dumper of my packet:

$VAR1 = bless( {
  '_protocol' => 'HTTP/1.1',
  '_content' => '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don\'t have permission to access /rest/net/NET-66-0-0-0-0/customer
on this server.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
</body></html>
',
  '_rc' => '403',
  '_headers' => bless( {
    'connection' => 'close',
    'client-response-num' => 1,
    'date' => 'Wed, 30 Nov 2011 18:13:44 GMT',
    'client-ssl-cert-issuer' => '/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287',
    'client-ssl-cipher' => 'DHE-RSA-AES256-SHA',
    'client-peer' => '192.149.252.16:443',
    'content-length' => '318',
    'client-date' => 'Wed, 30 Nov 2011 18:12:45 GMT',
    'client-ssl-warning' => 'Peer certificate not verified',
    'content-type' => 'text/html; charset=iso-8859-1',
    'client-ssl-cert-subject' => '/O=*.arin.net/OU=Domain Control Validated/CN=*.arin.net',
    'title' => '403 Forbidden'
  }, 'HTTP::Headers' ),
  '_msg' => 'Forbidden',
  '_request' => bless( {
    '_content' => '<customer xmlns="http://www.arin.net/regrws/core/v1"><customerName>Test Customer</customerName><iso3166-1><name>UNITED STATES</name><code2>US</code2><code3>USA</code3><e164>1</e164></iso3166-1><streetAddress><line number = "1">123 Test Ave</line></streetAddress><city>Testville</city><iso3166-2>Mo</iso3166-2><postalCode>12345</postalCode><comment><line number = "1">This is a test customer</line></comment><parentOrgHandle>CC04</parentOrgHandle><privateCustomer>false</privateCustomer></customer>',
    '_uri' => bless( do{\(my $o = 'https://rest-beta.arin.net/rest/net/[network id]/customer?apikey=[api key]')}, 'URI::https' ),
    '_headers' => bless( {
      'user-agent' => [in house middleware system],
      'content-type' => 'text/xml',
      'accept' => 'text/xml',
      'content-length' => 497,
      'authorization' => 'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
    }, 'HTTP::Headers' ),
    '_method' => 'POST',
    '_uri_canonical' => $VAR1->{'_request'}{'_uri'}
  }, 'HTTP::Request' )
}, 'HTTP::Response' );
403Force to success: 0 is success: 
this is a rest request
$VAR1 = '<status>failure</status>';
Results
$VAR1 = 'failure';


Thanks,
David


From tstpierre at iweb.com  Wed Nov 30 13:30:29 2011
From: tstpierre at iweb.com (Thomas St.Pierre)
Date: Wed, 30 Nov 2011 13:30:29 -0500
Subject: [arin-tech-discuss] 403 Errors when trying to create a customer
In-Reply-To: <6D32C57B73284D45B48A7F2E79320E070CD0545D@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <6D32C57B73284D45B48A7F2E79320E070CD0545D@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <4ED67645.40602@iweb.com>

Try using Content-Type: application/xml in your request

in PHP:
      curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: 
application/xml'));

Thanks,

Thomas



On 11-11-30 1:27 PM, Ramage, David wrote:
> Hey folks,
> I'm running across some 403 errors when I try to hit rest-beta.arin.net.  I'm probably missing something obvious here, but I'm not seeing it.
>
> In this particular case I'm trying to POST to https://rest-beta.arin.net/rest/net/[my net handle]/customer?apikey=[my api key].  It looks like the XML is being sent, but I'm getting the 403 back.
>
> Here's a sanitized Data::Dumper of my packet:
>
> $VAR1 = bless( {
>    '_protocol' =>  'HTTP/1.1',
>    '_content' =>  '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>403 Forbidden</title>
> </head><body>
> <h1>Forbidden</h1>
> <p>You don\'t have permission to access /rest/net/NET-66-0-0-0-0/customer
> on this server.</p>
> <hr>
> <address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
> </body></html>
> ',
>    '_rc' =>  '403',
>    '_headers' =>  bless( {
>      'connection' =>  'close',
>      'client-response-num' =>  1,
>      'date' =>  'Wed, 30 Nov 2011 18:13:44 GMT',
>      'client-ssl-cert-issuer' =>  '/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287',
>      'client-ssl-cipher' =>  'DHE-RSA-AES256-SHA',
>      'client-peer' =>  '192.149.252.16:443',
>      'content-length' =>  '318',
>      'client-date' =>  'Wed, 30 Nov 2011 18:12:45 GMT',
>      'client-ssl-warning' =>  'Peer certificate not verified',
>      'content-type' =>  'text/html; charset=iso-8859-1',
>      'client-ssl-cert-subject' =>  '/O=*.arin.net/OU=Domain Control Validated/CN=*.arin.net',
>      'title' =>  '403 Forbidden'
>    }, 'HTTP::Headers' ),
>    '_msg' =>  'Forbidden',
>    '_request' =>  bless( {
>      '_content' =>  '<customer xmlns="http://www.arin.net/regrws/core/v1"><customerName>Test Customer</customerName><iso3166-1><name>UNITED STATES</name><code2>US</code2><code3>USA</code3><e164>1</e164></iso3166-1><streetAddress><line number = "1">123 Test Ave</line></streetAddress><city>Testville</city><iso3166-2>Mo</iso3166-2><postalCode>12345</postalCode><comment><line number = "1">This is a test customer</line></comment><parentOrgHandle>CC04</parentOrgHandle><privateCustomer>false</privateCustomer></customer>',
>      '_uri' =>  bless( do{\(my $o = 'https://rest-beta.arin.net/rest/net/[network id]/customer?apikey=[api key]')}, 'URI::https' ),
>      '_headers' =>  bless( {
>        'user-agent' =>  [in house middleware system],
>        'content-type' =>  'text/xml',
>        'accept' =>  'text/xml',
>        'content-length' =>  497,
>        'authorization' =>  'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>      }, 'HTTP::Headers' ),
>      '_method' =>  'POST',
>      '_uri_canonical' =>  $VAR1->{'_request'}{'_uri'}
>    }, 'HTTP::Request' )
> }, 'HTTP::Response' );
> 403Force to success: 0 is success:
> this is a rest request
> $VAR1 = '<status>failure</status>';
> Results
> $VAR1 = 'failure';
>
>
> Thanks,
> David
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss


From david.ramage at chartercom.com  Wed Nov 30 13:37:45 2011
From: david.ramage at chartercom.com (Ramage, David)
Date: Wed, 30 Nov 2011 12:37:45 -0600
Subject: [arin-tech-discuss] 403 Errors when trying to create a customer
In-Reply-To: <4ED67645.40602@iweb.com>
References: <6D32C57B73284D45B48A7F2E79320E070CD0545D@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<4ED67645.40602@iweb.com>
Message-ID: <6D32C57B73284D45B48A7F2E79320E070CD05486@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>

I gave that a go, but unfortunately I'm still getting a 403:

VAR1 = bless( {
  '_protocol' => 'HTTP/1.1',
  '_content' => '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don\'t have permission to access /rest/net/[net handle]/customer
on this server.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
</body></html>
',
  '_rc' => '403',
  '_headers' => bless( {
    'connection' => 'close',
    ...
      'content-type' => 'application/xml',
      'accept' => 'text/xml',
      'content-length' => 497,
      'authorization' => 'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
    }, 'HTTP::Headers' ),
    '_method' => 'POST',
    '_uri_canonical' => $VAR1->{'_request'}{'_uri'}
  }, 'HTTP::Request' )
}, 'HTTP::Response' );



-----Original Message-----
From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of Thomas St.Pierre
Sent: Wednesday, November 30, 2011 10:30 AM
To: arin-tech-discuss at arin.net
Subject: Re: [arin-tech-discuss] 403 Errors when trying to create a customer

Try using Content-Type: application/xml in your request

in PHP:
      curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: 
application/xml'));

Thanks,

Thomas



On 11-11-30 1:27 PM, Ramage, David wrote:
> Hey folks,
> I'm running across some 403 errors when I try to hit rest-beta.arin.net.  I'm probably missing something obvious here, but I'm not seeing it.
>
> In this particular case I'm trying to POST to https://rest-beta.arin.net/rest/net/[my net handle]/customer?apikey=[my api key].  It looks like the XML is being sent, but I'm getting the 403 back.
>
> Here's a sanitized Data::Dumper of my packet:
>
> $VAR1 = bless( {
>    '_protocol' =>  'HTTP/1.1',
>    '_content' =>  '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>403 Forbidden</title>
> </head><body>
> <h1>Forbidden</h1>
> <p>You don\'t have permission to access /rest/net/[net handle]/customer
> on this server.</p>
> <hr>
> <address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
> </body></html>
> ',
>    '_rc' =>  '403',
>    '_headers' =>  bless( {
>      'connection' =>  'close',
>      'client-response-num' =>  1,
>      'date' =>  'Wed, 30 Nov 2011 18:13:44 GMT',
>      'client-ssl-cert-issuer' =>  '/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287',
>      'client-ssl-cipher' =>  'DHE-RSA-AES256-SHA',
>      'client-peer' =>  '192.149.252.16:443',
>      'content-length' =>  '318',
>      'client-date' =>  'Wed, 30 Nov 2011 18:12:45 GMT',
>      'client-ssl-warning' =>  'Peer certificate not verified',
>      'content-type' =>  'text/html; charset=iso-8859-1',
>      'client-ssl-cert-subject' =>  '/O=*.arin.net/OU=Domain Control Validated/CN=*.arin.net',
>      'title' =>  '403 Forbidden'
>    }, 'HTTP::Headers' ),
>    '_msg' =>  'Forbidden',
>    '_request' =>  bless( {
>      '_content' =>  '<customer xmlns="http://www.arin.net/regrws/core/v1"><customerName>Test Customer</customerName><iso3166-1><name>UNITED STATES</name><code2>US</code2><code3>USA</code3><e164>1</e164></iso3166-1><streetAddress><line number = "1">123 Test Ave</line></streetAddress><city>Testville</city><iso3166-2>Mo</iso3166-2><postalCode>12345</postalCode><comment><line number = "1">This is a test customer</line></comment><parentOrgHandle>CC04</parentOrgHandle><privateCustomer>false</privateCustomer></customer>',
>      '_uri' =>  bless( do{\(my $o = 'https://rest-beta.arin.net/rest/net/[network id]/customer?apikey=[api key]')}, 'URI::https' ),
>      '_headers' =>  bless( {
>        'user-agent' =>  [in house middleware system],
>        'content-type' =>  'text/xml',
>        'accept' =>  'text/xml',
>        'content-length' =>  497,
>        'authorization' =>  'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>      }, 'HTTP::Headers' ),
>      '_method' =>  'POST',
>      '_uri_canonical' =>  $VAR1->{'_request'}{'_uri'}
>    }, 'HTTP::Request' )
> }, 'HTTP::Response' );
> 403Force to success: 0 is success:
> this is a rest request
> $VAR1 = '<status>failure</status>';
> Results
> $VAR1 = 'failure';
>
>
> Thanks,
> David
> _______________________________________________
> 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


From tstpierre at iweb.com  Wed Nov 30 14:37:14 2011
From: tstpierre at iweb.com (Thomas St.Pierre)
Date: Wed, 30 Nov 2011 14:37:14 -0500
Subject: [arin-tech-discuss] 403 Errors when trying to create a customer
In-Reply-To: <6D32C57B73284D45B48A7F2E79320E070CD05486@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
References: <6D32C57B73284D45B48A7F2E79320E070CD0545D@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
	<4ED67645.40602@iweb.com>
	<6D32C57B73284D45B48A7F2E79320E070CD05486@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <4ED685EA.9070800@iweb.com>

Can you set accept to */*?

I know I had problems with this, though looking back at my emails I was 
getting a 404 response when I had the wrong content type.

Also is it possible you haven't registered for the beta program? When I 
try to access the rest-beta site from a non authorized IP I get back a 403.

If it's not that then we'll have to wait for someone from Arin to respond :)

Thomas

On 11-11-30 1:37 PM, Ramage, David wrote:
> I gave that a go, but unfortunately I'm still getting a 403:
>
> VAR1 = bless( {
>    '_protocol' =>  'HTTP/1.1',
>    '_content' =>  '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>403 Forbidden</title>
> </head><body>
> <h1>Forbidden</h1>
> <p>You don\'t have permission to access /rest/net/[net handle]/customer
> on this server.</p>
> <hr>
> <address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
> </body></html>
> ',
>    '_rc' =>  '403',
>    '_headers' =>  bless( {
>      'connection' =>  'close',
>      ...
>        'content-type' =>  'application/xml',
>        'accept' =>  'text/xml',
>        'content-length' =>  497,
>        'authorization' =>  'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>      }, 'HTTP::Headers' ),
>      '_method' =>  'POST',
>      '_uri_canonical' =>  $VAR1->{'_request'}{'_uri'}
>    }, 'HTTP::Request' )
> }, 'HTTP::Response' );
>
>
>
> -----Original Message-----
> From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of Thomas St.Pierre
> Sent: Wednesday, November 30, 2011 10:30 AM
> To: arin-tech-discuss at arin.net
> Subject: Re: [arin-tech-discuss] 403 Errors when trying to create a customer
>
> Try using Content-Type: application/xml in your request
>
> in PHP:
>        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type:
> application/xml'));
>
> Thanks,
>
> Thomas
>
>
>
> On 11-11-30 1:27 PM, Ramage, David wrote:
>> Hey folks,
>> I'm running across some 403 errors when I try to hit rest-beta.arin.net.  I'm probably missing something obvious here, but I'm not seeing it.
>>
>> In this particular case I'm trying to POST to https://rest-beta.arin.net/rest/net/[my net handle]/customer?apikey=[my api key].  It looks like the XML is being sent, but I'm getting the 403 back.
>>
>> Here's a sanitized Data::Dumper of my packet:
>>
>> $VAR1 = bless( {
>>     '_protocol' =>   'HTTP/1.1',
>>     '_content' =>   '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <html><head>
>> <title>403 Forbidden</title>
>> </head><body>
>> <h1>Forbidden</h1>
>> <p>You don\'t have permission to access /rest/net/[net handle]/customer
>> on this server.</p>
>> <hr>
>> <address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port 443</address>
>> </body></html>
>> ',
>>     '_rc' =>   '403',
>>     '_headers' =>   bless( {
>>       'connection' =>   'close',
>>       'client-response-num' =>   1,
>>       'date' =>   'Wed, 30 Nov 2011 18:13:44 GMT',
>>       'client-ssl-cert-issuer' =>   '/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287',
>>       'client-ssl-cipher' =>   'DHE-RSA-AES256-SHA',
>>       'client-peer' =>   '192.149.252.16:443',
>>       'content-length' =>   '318',
>>       'client-date' =>   'Wed, 30 Nov 2011 18:12:45 GMT',
>>       'client-ssl-warning' =>   'Peer certificate not verified',
>>       'content-type' =>   'text/html; charset=iso-8859-1',
>>       'client-ssl-cert-subject' =>   '/O=*.arin.net/OU=Domain Control Validated/CN=*.arin.net',
>>       'title' =>   '403 Forbidden'
>>     }, 'HTTP::Headers' ),
>>     '_msg' =>   'Forbidden',
>>     '_request' =>   bless( {
>>       '_content' =>   '<customer xmlns="http://www.arin.net/regrws/core/v1"><customerName>Test Customer</customerName><iso3166-1><name>UNITED STATES</name><code2>US</code2><code3>USA</code3><e164>1</e164></iso3166-1><streetAddress><line number = "1">123 Test Ave</line></streetAddress><city>Testville</city><iso3166-2>Mo</iso3166-2><postalCode>12345</postalCode><comment><line number = "1">This is a test customer</line></comment><parentOrgHandle>CC04</parentOrgHandle><privateCustomer>false</privateCustomer></customer>',
>>       '_uri' =>   bless( do{\(my $o = 'https://rest-beta.arin.net/rest/net/[network id]/customer?apikey=[api key]')}, 'URI::https' ),
>>       '_headers' =>   bless( {
>>         'user-agent' =>   [in house middleware system],
>>         'content-type' =>   'text/xml',
>>         'accept' =>   'text/xml',
>>         'content-length' =>   497,
>>         'authorization' =>   'Basic cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>>       }, 'HTTP::Headers' ),
>>       '_method' =>   'POST',
>>       '_uri_canonical' =>   $VAR1->{'_request'}{'_uri'}
>>     }, 'HTTP::Request' )
>> }, 'HTTP::Response' );
>> 403Force to success: 0 is success:
>> this is a rest request
>> $VAR1 = '<status>failure</status>';
>> Results
>> $VAR1 = 'failure';
>>
>>
>> Thanks,
>> David
>> _______________________________________________
>> 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
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss


From erikag at arin.net  Wed Nov 30 18:37:21 2011
From: erikag at arin.net (Erika Goedrich)
Date: Wed, 30 Nov 2011 23:37:21 +0000
Subject: [arin-tech-discuss] 403 Errors when trying to create a customer
In-Reply-To: <6D32C57B73284D45B48A7F2E79320E070CD05486@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Message-ID: <CAFC26AD.10CB0%erikag@corp.arin.net>

Hi David,

I show that you do not have an API Key tied to your account in our OT&E
environment. We are scheduled to do a backwash from production on
Thursday, Dec. 1, which would put your production API Key into the OT&E
environment. You also have the option of creating a separate API Key in
the beta environment by going to https://rest-beta.arin.net/public/ and
logging into the OT&E ARIN Online.

Also, please make sure you are sending your requests from the IP addresses
that you provided to us when requesting access to the beta environment.

If you have additional questions, please let us know.

Regards,
Erika Goedrich
ARIN Project Manager
 

On 11/30/11 1:37 PM, "Ramage, David" <david.ramage at chartercom.com> wrote:

>I gave that a go, but unfortunately I'm still getting a 403:
>
>VAR1 = bless( {
>  '_protocol' => 'HTTP/1.1',
>  '_content' => '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
><html><head>
><title>403 Forbidden</title>
></head><body>
><h1>Forbidden</h1>
><p>You don\'t have permission to access /rest/net/[net handle]/customer
>on this server.</p>
><hr>
><address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port
>443</address>
></body></html>
>',
>  '_rc' => '403',
>  '_headers' => bless( {
>    'connection' => 'close',
>    ...
>      'content-type' => 'application/xml',
>      'accept' => 'text/xml',
>      'content-length' => 497,
>      'authorization' => 'Basic
>cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>    }, 'HTTP::Headers' ),
>    '_method' => 'POST',
>    '_uri_canonical' => $VAR1->{'_request'}{'_uri'}
>  }, 'HTTP::Request' )
>}, 'HTTP::Response' );
>
>
>
>-----Original Message-----
>From: arin-tech-discuss-bounces at arin.net
>[mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of Thomas St.Pierre
>Sent: Wednesday, November 30, 2011 10:30 AM
>To: arin-tech-discuss at arin.net
>Subject: Re: [arin-tech-discuss] 403 Errors when trying to create a
>customer
>
>Try using Content-Type: application/xml in your request
>
>in PHP:
>      curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type:
>application/xml'));
>
>Thanks,
>
>Thomas
>
>
>
>On 11-11-30 1:27 PM, Ramage, David wrote:
>> Hey folks,
>> I'm running across some 403 errors when I try to hit
>>rest-beta.arin.net.  I'm probably missing something obvious here, but
>>I'm not seeing it.
>>
>> In this particular case I'm trying to POST to
>>https://rest-beta.arin.net/rest/net/[my net handle]/customer?apikey=[my
>>api key].  It looks like the XML is being sent, but I'm getting the 403
>>back.
>>
>> Here's a sanitized Data::Dumper of my packet:
>>
>> $VAR1 = bless( {
>>    '_protocol' =>  'HTTP/1.1',
>>    '_content' =>  '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <html><head>
>> <title>403 Forbidden</title>
>> </head><body>
>> <h1>Forbidden</h1>
>> <p>You don\'t have permission to access /rest/net/[net handle]/customer
>> on this server.</p>
>> <hr>
>> <address>Apache/2.2.3 (CentOS) Server at rest-beta.arin.net Port
>>443</address>
>> </body></html>
>> ',
>>    '_rc' =>  '403',
>>    '_headers' =>  bless( {
>>      'connection' =>  'close',
>>      'client-response-num' =>  1,
>>      'date' =>  'Wed, 30 Nov 2011 18:13:44 GMT',
>>      'client-ssl-cert-issuer' =>
>>'/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
>>Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
>>Certification Authority/serialNumber=07969287',
>>      'client-ssl-cipher' =>  'DHE-RSA-AES256-SHA',
>>      'client-peer' =>  '192.149.252.16:443',
>>      'content-length' =>  '318',
>>      'client-date' =>  'Wed, 30 Nov 2011 18:12:45 GMT',
>>      'client-ssl-warning' =>  'Peer certificate not verified',
>>      'content-type' =>  'text/html; charset=iso-8859-1',
>>      'client-ssl-cert-subject' =>  '/O=*.arin.net/OU=Domain Control
>>Validated/CN=*.arin.net',
>>      'title' =>  '403 Forbidden'
>>    }, 'HTTP::Headers' ),
>>    '_msg' =>  'Forbidden',
>>    '_request' =>  bless( {
>>      '_content' =>  '<customer
>>xmlns="http://www.arin.net/regrws/core/v1"><customerName>Test
>>Customer</customerName><iso3166-1><name>UNITED
>>STATES</name><code2>US</code2><code3>USA</code3><e164>1</e164></iso3166-1
>>><streetAddress><line number = "1">123 Test
>>>Ave</line></streetAddress><city>Testville</city><iso3166-2>Mo</iso3166-2
>>>><postalCode>12345</postalCode><comment><line number = "1">This is a
>>>>test 
>>>>customer</line></comment><parentOrgHandle>CC04</parentOrgHandle><privat
>>>>eCustomer>false</privateCustomer></customer>',
>>      '_uri' =>  bless( do{\(my $o =
>>'https://rest-beta.arin.net/rest/net/[network id]/customer?apikey=[api
>>key]')}, 'URI::https' ),
>>      '_headers' =>  bless( {
>>        'user-agent' =>  [in house middleware system],
>>        'content-type' =>  'text/xml',
>>        'accept' =>  'text/xml',
>>        'content-length' =>  497,
>>        'authorization' =>  'Basic
>>cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q6cmVzdC1iZXRhLmFyaW4ubmV0L3Jlc3Q='
>>      }, 'HTTP::Headers' ),
>>      '_method' =>  'POST',
>>      '_uri_canonical' =>  $VAR1->{'_request'}{'_uri'}
>>    }, 'HTTP::Request' )
>> }, 'HTTP::Response' );
>> 403Force to success: 0 is success:
>> this is a rest request
>> $VAR1 = '<status>failure</status>';
>> Results
>> $VAR1 = 'failure';
>>
>>
>> Thanks,
>> David
>> _______________________________________________
>> 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
>_______________________________________________
>arin-tech-discuss mailing list
>arin-tech-discuss at arin.net
>http://lists.arin.net/mailman/listinfo/arin-tech-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.xml
Type: application/xml
Size: 3222 bytes
Desc: default.xml
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20111130/e51df661/attachment.wsdl>