From jayb at braeburn.org  Tue Dec 17 12:56:56 2013
From: jayb at braeburn.org (Jay Borkenhagen)
Date: Tue, 17 Dec 2013 12:56:56 -0500
Subject: [arin-tech-discuss] ARIN RPKI hiccup on Saturday
Message-ID: <21168.36968.86059.899120@oz.mt.att.com>

Hi ARIN,

I saw ARIN's announcements of scheduled maintenance for this past
Saturday 14-December-2013, including a statement that RPKI Repository
Services would be available during that outage.  I also saw the 'all
clear' message following the maintenance.

But I have not yet seen any explanation of the hiccup in ARIN's RPKI
that coincided with the maintenance.  Can someone from ARIN please
comment?

Thank you.

						Jay B.




From brak at gameservers.com  Tue Dec 17 15:31:33 2013
From: brak at gameservers.com (Brian Rak)
Date: Tue, 17 Dec 2013 15:31:33 -0500
Subject: [arin-tech-discuss] IPv6 Alternative to Reassignment Report?
In-Reply-To: <CEB535AF.2A2D3%andy@arin.net>
References: <CEB535AF.2A2D3%andy@arin.net>
Message-ID: <52B0B4A5.5050109@gameservers.com>

We're now updating our SWIP scripts to deal with IPv6, and this report 
works perfectly!  Thanks for the help.

On 11/22/2013 4:25 PM, Andy Newton wrote:
> Brian,
>
> This fix will be in our next planned release, which is scheduled for
> December 14.
>
> Andy Newton,
> Chief Engineer, ARIN
>
> On 11/22/13 8:57 AM, "Brian Rak" <brak at gameservers.com> wrote:
>
>> Any progress on implementing this?
>>
>> On 6/12/2013 4:54 PM, Andy Newton wrote:
>>> On 6/12/13 3:53 PM, "Brian Rak" <brak at gameservers.com> wrote:
>>>
>>>> Is there any alternative to the Reassignment Report that works with
>>>> IPv6?
>>>>
>>>> We use this report as part of our SWIP process, as it's the only real
>>>> way to get a list of all the reassignments that ARIN knows about.
>>>> Using
>>>> the whois api with /children is not really something that is useful, as
>>>> it's limited to 256 entries.
>>> Brian,
>>>
>>> Unfortunately the reassignments report doesn't work with IPv6 resources.
>>> We consider this an oversight, and I have entered an issue in our bug
>>> tracking system to have it rectified.
>>>
>>> Sorry for the confusion and the inconvenience.
>>>
>>> Andy Newton,
>>> Chief Engineer, ARIN
>>>
>>
>



From markk at arin.net  Tue Dec 17 16:45:42 2013
From: markk at arin.net (Mark Kosters)
Date: Tue, 17 Dec 2013 21:45:42 +0000
Subject: [arin-tech-discuss] ARIN RPKI hiccup on Saturday
In-Reply-To: <21168.36968.86059.899120@oz.mt.att.com>
References: <21168.36968.86059.899120@oz.mt.att.com>
Message-ID: <CED62B1B.DE520%markk@arin.net>

Hi Jay

Yes - we caught wind of this earlier today. We validate before publishing
to the community and this was a new twist. The manifest certificate on the
repository was invalid from 8:00AM EST until 2:05PM EST on 12/14. The
repository is generated 2x a day each with a 24hr expiry on the manifest
certificate. Unfortunately, we missed the evening run on 12/13 as we were
shutting non-public services down preparing for the database conversion.
It was "refreshed" the afternoon of 12/14 when the database was up and
certified to be healthy post-conversion.

As for RPKI, this was an oversight on our part and we are reevaluating
having such a limited-duration cert. Other RIR's who have the same
characteristics are also looking at changing their manifest certs as well.

Our apologies for any inconvenience that this may have caused.

Regards,
Mark

On 12/17/13, 12:56 PM, "Jay Borkenhagen" <jayb at braeburn.org> wrote:

>Hi ARIN,
>
>I saw ARIN's announcements of scheduled maintenance for this past
>Saturday 14-December-2013, including a statement that RPKI Repository
>Services would be available during that outage.  I also saw the 'all
>clear' message following the maintenance.
>
>But I have not yet seen any explanation of the hiccup in ARIN's RPKI
>that coincided with the maintenance.  Can someone from ARIN please
>comment?
>
>Thank you.
>
>						Jay B.
>
>
>_______________________________________________
>arin-tech-discuss mailing list
>arin-tech-discuss at arin.net
>http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From jayb at braeburn.org  Tue Dec 17 19:41:39 2013
From: jayb at braeburn.org (Jay Borkenhagen)
Date: Tue, 17 Dec 2013 19:41:39 -0500
Subject: [arin-tech-discuss] ARIN RPKI hiccup on Saturday
In-Reply-To: <CED62B1B.DE520%markk@arin.net>
References: <21168.36968.86059.899120@oz.mt.att.com>
	<CED62B1B.DE520%markk@arin.net>
Message-ID: <21168.61251.347081.721376@oz.mt.att.com>

Thanks for providing the explanation, Mark.  There are bound to be
some surprises along the way as we all get comfortable with the RPKI.

You're probably already thinking along these lines, but could ARIN put
up some monitoring of its RPKI output, alerting your operations staff
for things like the number of authenticated RPKI objects dropping
sharply?  And to make sure any such monitoring is not taken offline
during general systems maintenance events?


On 17-Dec-2013, Mark Kosters writes:
 > Hi Jay
 > 
 > Yes - we caught wind of this earlier today. We validate before publishing
 > to the community and this was a new twist. The manifest certificate on the
 > repository was invalid from 8:00AM EST until 2:05PM EST on 12/14. The
 > repository is generated 2x a day each with a 24hr expiry on the manifest
 > certificate. Unfortunately, we missed the evening run on 12/13 as we were
 > shutting non-public services down preparing for the database conversion.
 > It was "refreshed" the afternoon of 12/14 when the database was up and
 > certified to be healthy post-conversion.
 > 
 > As for RPKI, this was an oversight on our part and we are reevaluating
 > having such a limited-duration cert. Other RIR's who have the same
 > characteristics are also looking at changing their manifest certs as well.
 > 
 > Our apologies for any inconvenience that this may have caused.
 > 
 > Regards,
 > Mark
 > 
 > On 12/17/13, 12:56 PM, "Jay Borkenhagen" <jayb at braeburn.org> wrote:
 > 
 > >Hi ARIN,
 > >
 > >I saw ARIN's announcements of scheduled maintenance for this past
 > >Saturday 14-December-2013, including a statement that RPKI Repository
 > >Services would be available during that outage.  I also saw the 'all
 > >clear' message following the maintenance.
 > >
 > >But I have not yet seen any explanation of the hiccup in ARIN's RPKI
 > >that coincided with the maintenance.  Can someone from ARIN please
 > >comment?
 > >
 > >Thank you.
 > >
 > >						Jay B.
 > >
 > >
 > >_______________________________________________
 > >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 Dec 18 10:12:00 2013
From: brak at gameservers.com (Brian Rak)
Date: Wed, 18 Dec 2013 10:12:00 -0500
Subject: [arin-tech-discuss] IPv6 Detailed Reassign not automated?
Message-ID: <52B1BB40.6010105@gameservers.com>

Are IPv6 Detailed Reassignments a manual process right now?  I've got 6 
pending where I was reassigning to an existing ORGID rather then a new 
customer.  They all appear to be pending review by ARIN. I've never seen 
any of our IPv4 reassignment requests pending like this, so I'm 
wondering what's going on.

Submitted Date: 12-17-2013 15:45:27
Request Type: IPv6 Detailed Reassign
Status: Pending Review
Last Updated Date: 12-17-2013 15:45:27
Action Needed By: ARIN

Or, is there something that I'm doing wrong that's leading to tickets 
being created rather then this happening automatically?


From jonw at arin.net  Wed Dec 18 16:32:36 2013
From: jonw at arin.net (Jon Worley)
Date: Wed, 18 Dec 2013 21:32:36 +0000
Subject: [arin-tech-discuss] IPv6 Detailed Reassign not automated?
In-Reply-To: <52B1BB40.6010105@gameservers.com>
Message-ID: <CED72BC4.515CA%jonw@arin.net>

Hello Brian,

Our software currently tickets IPv6 reassignments/reallocations for review
when they either:

1) are for more than a /48, or
2) are for an Org ID that already has an IPv6 block (whether it's directly
registered or a reassignment/reallocation)

At the time the software was developed, there was a policy requirement
that when a single end site requires an additional /48, it must provide
documentation or materials that justify the request.  You can find the
relevant policy in section 6.5.4.2 of NRPM version 2011.3:

	https://www.arin.net/policy/archive/nrpm_20110727.pdf

Ticketing these requests was necessary to ensure compliance with that
policy.

When policy 2011-3 ("Better IPv6 Allocations For ISPs") was implemented in
January 2012, the requirement to supply documentation for multiple /48s
was removed.  It appears we overlooked this change at the time the new
policy was implemented and didn't adjust our software to stop ticketing
these for review.  We'll report the problem to our engineering staff.

If you have any further questions, comments, or concerns please respond to
this message or contact me directly.

Regards,

Jon Worley
Senior Resource Analyst
ARIN Registration Services
https://www.arin.net/
hostmaster at arin.net
703.227.0660


On 12/18/13 10:12 AM, "Brian Rak" <brak at gameservers.com> wrote:

>Are IPv6 Detailed Reassignments a manual process right now?  I've got 6
>pending where I was reassigning to an existing ORGID rather then a new
>customer.  They all appear to be pending review by ARIN. I've never seen
>any of our IPv4 reassignment requests pending like this, so I'm
>wondering what's going on.
>
>Submitted Date: 12-17-2013 15:45:27
>Request Type: IPv6 Detailed Reassign
>Status: Pending Review
>Last Updated Date: 12-17-2013 15:45:27
>Action Needed By: ARIN
>
>Or, is there something that I'm doing wrong that's leading to tickets
>being created rather then this happening automatically?
>_______________________________________________
>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 Dec 18 16:57:59 2013
From: brak at gameservers.com (Brian Rak)
Date: Wed, 18 Dec 2013 16:57:59 -0500
Subject: [arin-tech-discuss] IPv6 Detailed Reassign not automated?
In-Reply-To: <CED72BC4.515CA%jonw@arin.net>
References: <CED72BC4.515CA%jonw@arin.net>
Message-ID: <52B21A67.2080006@gameservers.com>

Ah those conditions make sense (as some of our requests went through ok, 
and others were ticketed).

Do you have any sort of ETA as to when this will be corrected?

On 12/18/2013 4:32 PM, Jon Worley wrote:
> Hello Brian,
>
> Our software currently tickets IPv6 reassignments/reallocations for review
> when they either:
>
> 1) are for more than a /48, or
> 2) are for an Org ID that already has an IPv6 block (whether it's directly
> registered or a reassignment/reallocation)
>
> At the time the software was developed, there was a policy requirement
> that when a single end site requires an additional /48, it must provide
> documentation or materials that justify the request.  You can find the
> relevant policy in section 6.5.4.2 of NRPM version 2011.3:
>
> 	https://www.arin.net/policy/archive/nrpm_20110727.pdf
>
> Ticketing these requests was necessary to ensure compliance with that
> policy.
>
> When policy 2011-3 ("Better IPv6 Allocations For ISPs") was implemented in
> January 2012, the requirement to supply documentation for multiple /48s
> was removed.  It appears we overlooked this change at the time the new
> policy was implemented and didn't adjust our software to stop ticketing
> these for review.  We'll report the problem to our engineering staff.
>
> If you have any further questions, comments, or concerns please respond to
> this message or contact me directly.
>
> Regards,
>
> Jon Worley
> Senior Resource Analyst
> ARIN Registration Services
> https://www.arin.net/
> hostmaster at arin.net
> 703.227.0660
>
>
> On 12/18/13 10:12 AM, "Brian Rak" <brak at gameservers.com> wrote:
>
>> Are IPv6 Detailed Reassignments a manual process right now?  I've got 6
>> pending where I was reassigning to an existing ORGID rather then a new
>> customer.  They all appear to be pending review by ARIN. I've never seen
>> any of our IPv4 reassignment requests pending like this, so I'm
>> wondering what's going on.
>>
>> Submitted Date: 12-17-2013 15:45:27
>> Request Type: IPv6 Detailed Reassign
>> Status: Pending Review
>> Last Updated Date: 12-17-2013 15:45:27
>> Action Needed By: ARIN
>>
>> Or, is there something that I'm doing wrong that's leading to tickets
>> being created rather then this happening automatically?
>> _______________________________________________
>> arin-tech-discuss mailing list
>> arin-tech-discuss at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From ecsd at transbay.net  Tue Dec 31 11:54:30 2013
From: ecsd at transbay.net (Eric Dynamic)
Date: Tue, 31 Dec 2013 08:54:30 -0800
Subject: [arin-tech-discuss] (1) Some serious issues with the REST service
 and (2) Strange inconsistencies in the database mappings
Message-ID: <52C2F6C6.1090803@transbay.net>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20131231/d3615b6f/attachment.html>

From andy at arin.net  Tue Dec 31 14:42:08 2013
From: andy at arin.net (Andy Newton)
Date: Tue, 31 Dec 2013 19:42:08 +0000
Subject: [arin-tech-discuss] (1) Some serious issues with the REST
 service and (2) Strange inconsistencies in the database mappings
In-Reply-To: <52C2F6C6.1090803@transbay.net>
Message-ID: <CEE880EE.2B411%andy@arin.net>

Eric,

Thanks for your message and sorry about the confusion.

First let me address your primary need, which is to gather data based on an IP address. While /ip/XXXX/orgs is not a supported query, /ip/XXXX/pft is and it will return the information you seek on both the organization and the POCs. Using the example address you gave, http://whois.arin.net/rest/ip/209.144.225.62/pft.txt will return the network registration, the associated organization, and the abuse contact you seek all in one query. Hopefully that will reduce the complexity of your code and address the bulk of your frustration.

With regard to the issue of HTML being returned when JSON, TXT, or XML are requested, this is a known bug in the REST library upon which we rely. However, under these conditions our REST service does produce a proper HTTP status code of 404. When using curl, the ?f flag will produce a 404 and suppress the output, which should ease the burden on your script.

Finally, our current plans for Whois information over HTTP/REST include the adoption of the RDAP protocol under development in the IETF. It is currently envisioned that all 5 RIRs and many domain registrars will deploy this service. When that time comes, programmatically retrieving data should be simpler and more uniform and thus reduce the complexity of your codebase.

I hope this helps.
Happy New Year!
Andy Newton,
Chief Engineer, ARIN

From: Eric Dynamic <ecsd at transbay.net<mailto:ecsd at transbay.net>>
Date: Tuesday, December 31, 2013 11:54 AM
To: "arin-tech-discuss at arin.net<mailto:arin-tech-discuss at arin.net>" <arin-tech-discuss at arin.net<mailto:arin-tech-discuss at arin.net>>
Subject: [arin-tech-discuss] (1) Some serious issues with the REST service and (2) Strange inconsistencies in the database mappings

The REST info page:
4.3.3. MIME Types and File Extensions

The following table lists the data types and their associated MIME types and file extensions:

Data type       Current Version MIME Type       Version 1 MIME Type     File Extension
XML     application/xml application/arin.whoisrws-v1+xml        xml
JSON    application/json        application/arin.whoisrws-v1+json       json
plain text      text/plain              txt
HTML    text/html               html

Problems:

(1) formatting issue.

http://whois.arin.net/rest/org/ATL-83/pocs.txt

returns


http://whois.arin.net/rest/poc/NOC3056-ARINhttp://whois.arin.net/rest/poc/NOC3056-ARINhttp://whois.arin.net/rest/poc/JCL171-ARINhttp://whois.arin.net/rest/poc/NOC3056-ARIN

As opposed to what one can "swipe" from the web page:

Abuse   NOC3056-ARIN (NOC3056-ARIN<http://whois.arin.net/rest/poc/NOC3056-ARIN.html>)
NOC     NOC3056-ARIN (NOC3056-ARIN<http://whois.arin.net/rest/poc/NOC3056-ARIN.html>)
Tech    NOC3056-ARIN (NOC3056-ARIN<http://whois.arin.net/rest/poc/NOC3056-ARIN.html>)
Admin   JCL171-ARIN (JCL171-ARIN<http://whois.arin.net/rest/poc/JCL171-ARIN.html>)

So, the TXT output in this case has no line breaks and omits the function descriptions. Other similar TXT output more closely resembles what the web page shows.

(2) missing information.

Via the web, the URL http://whois.arin.net/rest/ip/209.144.225.62/orgs returns:

NetRange        209.144.225.0 - 209.144.225.255
CIDR    209.144.225.0/24

Name    SAVV-S218155-6
Handle  NET-209-144-225-0-1
Parent  SAVVIS4 (NET-209-144-0-0-1<http://whois.arin.net/rest/net/NET-209-144-0-0-1.html>)
Net Type        Reallocated
Origin AS

Organization    AppServe Technologies, LLC (ATL-83<http://whois.arin.net/rest/org/ATL-83.html>)
Registration Date       2007-09-20
Last Updated    2007-09-20
Comments

RESTful Link    http://whois.arin.net/rest/net/NET-209-144-225-0-1
See Also        Related POC records.<http://whois.arin.net/rest/net/NET-209-144-225-0-1/pocs>
See Also        Related organization's POC records.<http://whois.arin.net/rest/org/ATL-83/pocs>
See Also        Related delegations.<http://whois.arin.net/rest/net/NET-209-144-225-0-1/rdns>

However, from the Unix command line

curl -H "Accept: text/plain" http://whois.arin.net/rest/ip/209.144.225.62.txt

returns this data:

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

NetRange:       209.144.225.0 - 209.144.225.255
CIDR:           209.144.225.0/24
OriginAS:
NetName:        SAVV-S218155-6
NetHandle:      NET-209-144-225-0-1
Parent:         NET-209-144-0-0-1
NetType:        Reallocated
RegDate:        2007-09-20
Updated:        2007-09-20
Ref:            http://whois.arin.net/rest/net/NET-209-144-225-0-1

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

Notice that there is no Organization Name. Ouch! for my purposes.

(3A) Incorrect formats returned;
(4A)Dead-end maze to get Organization Name due to apparent database mapping inconsistencies:

I am trying to write a program which, given an IP address, returns
* the associated NetRange, e.g. "209.144.225.0 - 209.144.225.255"
* the Abuse POC associated with that netrange.

Not getting the Organization Name in the command line call is making this a maze to accomplish, a dead-end as we'll see:

If I do this:

# curl -H "Accept: text/plain" http://whois.arin.net/rest/ip/209.144.225.62.txt

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

NetRange:       209.144.225.0 - 209.144.225.255
CIDR:           209.144.225.0/24
OriginAS:
NetName:        SAVV-S218155-6
NetHandle:      NET-209-144-225-0-1
Parent:         NET-209-144-0-0-1
NetType:        Reallocated
RegDate:        2007-09-20
Updated:        2007-09-20
Ref:            http://whois.arin.net/rest/net/NET-209-144-225-0-1

And then this:

# curl -H "Accept: text/plain" http://whois.arin.net/rest/net/NET-209-144-225-0-1/pocs.txt

http://whois.arin.net/rest/poc/JJ772-ARIN

And then this:

curl -H "Accept: text/plain" http://whois.arin.net/rest/poc/JJ772-ARIN/orgs.txt

This is the output I get:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"<http://www.w3.org/TR/html4/strict.dtd>>
<html xmlns:rdns="http://www.arin.net/whoisrws/rdns/v1"<http://www.arin.net/whoisrws/rdns/v1> xmlns:pft="http://www.arin.net/whoisrws/pft/v1"<http://www.arin.net/whoisrws/pft/v1> xmlns:whois="http://www.arin.net/whoisrws/core/v1"<http://www.arin.net/whoisrws/core/v1>>
<head>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Whois-RWS</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta content="Virginia" name="geo.placename">
<meta content="USA" name="geo.country">
<meta name="viewport" content="width=990">
<meta name="Keywords" content="">
<meta name="Description" content="">
<style type="text/css">
... VERY MUCH HTML SUPPRESSED ...
<div id="content">
<h2 class="noauth">Whois-RWS </h2>
<div id="maincontent">
<p style="margin:0;padding:0;">
<table>
<tr>
<th>No Related Resources</th>
</tr>
<tr>
<td>No related resources were found for the handle provided.</td>
</tr>
</table>
... MORE HTML SUPPRESSED ...

As you can see: I ASKED FOR TEXT and got HTML;

and despite NET-209-144-225-0-1 belonging to "AppServe Technologies, LLC (ATL-83<http://whois.arin.net/rest/org/ATL-83.html>)"and having POC JJ772-ARIN,
asking for the organization associated with JJ772-ARIN says "AIN'T NO SUCH THING." --> ?????

So trying to get the organization from the command line, I am screwed.

So I wonder if other formats can help ...

(3B) Incorrect formats returned

Asking for ip/#.#.#.#.txt did not return the ORGANIZATION NAME, as I pointed out above.

However, asking for ip/#.#.#.#.json does.

However!

All of these calls

curl http://whois.arin.net/rest/poc/JJ772-ARIN/orgs.json > org.json

and

curl -H "Accept: application/json" http://whois.arin.net/rest/poc/JJ772-ARIN/orgs.json > org.json

and

curl -H "Accept: application/xml" http://whois.arin.net/rest/poc/JJ772-ARIN/orgs.xml > org.xml

Return HTML.

Remember that "no information" was returned for JJ772-ARIN; maybe that has something to do with this bug.

(4B) Apparent database mapping inconsistencies:

There is this oddness with the database, that although

NET=X ----> ORG=Y

and

NET=X ----> POC=Z

we get

POC=Z ----> ORG="NO RESULT", which is inconsistent.

You would think that the information would be transitive and reflexive; that

NET=X <----> ORG=Y is bidirectional,

NET=X <----> POC=Z is bidirectional,

and therefore

POC=Z ----> NET=X ----> ORG=Y

and not ORG = "NO RESULT", as demonstrated above.

(5) In summary:

It would appear you have not debugged your "format matrix" properly;
1. Different requested formats selectively omit various information.
2. Requests for specific formats are in various cases ignored.
    May or may not depend on whether a query returned a result.

and
3. There may well be more going on underneath than meets my eye, but it seems
    the database mapping paths are not fully developed properly, since if
    A relates to B and A relates to C; then B relates to C; but you say it does not!

(6) Suggested changes in offerings and documentation

1. The documentation is a little misleading. It says
4.4. ARIN's RESTful Resources

In the examples from the previous sections, the resources being queried had the URL http://whois.arin.net/rest/poc/KOSTE-ARIN. Conceptually, this can be broken into a base URL and the resource identifier:

  *   base URL = http://whois.arin.net/rest
  *   resource = /poc/KOSTE-ARIN

The base URL is just where ARIN is hosting the service. The real interesting parts are the bits that identify the resources:

  *   /poc - this indicates the resource is a Point of Contact.
  *   /KOSTE-ARIN - this is the unique identifier for the Point of Contact, or the POC Handle.

ARIN's data model has six types of addressable resources. These are reflected in Whois-RWS in the following way:

  1.  /poc - point of contact.
  2.  /org - organization
  3.  /net - a network
  4.  /asn - autonomous system number(s)
  5.  /customer - a customer of an organization
  6.  /rdns - delegation

(underlining mine to call attention to a claim, bolding below mine to call attention to the rebuttal.)

But this is not a complete list, because below you go on to say
4.4.3. IP Addresses and Networks

In the ARIN data model, an IP "network" is a set of associated IP address blocks and the information related to these IP address blocks and the set as a whole. A network can be composed of one IP address block or of multiple IP address blocks. Networks are also hierarchical, meaning that a network can have a parent and can have children. An IP address or range of IP addresses can therefore fall within the IP address block of multiple networks.

To get the networks that a particular IP address may fall within, one can use the /ip/XX.XX.XX.XX resource, where XX.XX.XX.XX signifies the IP address.

(and)

Networks may be looked up as well by supplying the full CIDR notation of a range. To use the full CIDR notation, the resource looks like /cidr/XX.XX.XX.XX/YY where XX.XX.XX.XX is the IP address prefix and YY is the CIDR length.
So you actually have EIGHT resources, not SIX. And since you DO have the "ip" and "cidr" resources, why not expand this list:
4.4.1. Resources Related To Resources

In the ARIN Whois data model, resources have relationships to other resources. Getting references to these resources can be accomplished by addressing the resource in question and applying a resource type qualifier.

...

Here is the list of relationships (where "XXXX" signifies a handle):

  *   /poc/XXXX
     *   /orgs ==> /poc/XXXX/orgs - lists the organizations associated with a given POC.
     *   /asns ==> /poc/XXXX/asns - lists the ASNs associated with a given POC.
     *   /nets ==> /poc/XXXX/nets - lists the networks associated with a given POC.
  *   /org/XXXX
     *   /pocs ==> /org/XXXX/pocs - lists the POCs associate with a given organization.
     *   /asns ==> /org/XXXX/asns - lists the ASNs associated with a given organization.
     *   /nets ==> /org/XXXX/nets - lists the networks associated with a given organization.
  *   /asn/XXXX
     *   /pocs ==> /asn/XXXX/pocs - lists the POCs associated with a given ASN.
  *   /net/XXXX
     *   /pocs ==> /net/XXXX/pocs - lists the POCs associated with a given network.
     *   /parent ==> /net/XXXX/parent - lists the parent network of a given network.
     *   /children ==> /net/XXXX/children - lists the child networks of a given network.
     *   /rdns ==> /net/XXXX/rdns ? lists the delegations of a given network.
  *   /rdns/DELEGATION_NAME
     *   /nets ==> /rdns/DELEGATION_NAME/nets - lists networks related to a give delegation.

I had wished to be able to do

/ip/XXXX/orgs

directly. Seems obvious; why not?

I suggest making that (and similar extensions) possible; and I suggest including the "ip" and "cidr" as named resources that can be used along with the other six - that is largely a documentation fix.

Thanks for your time and attention.
Eric Dynamic (ED244-ARIN @ org/UCTELE-2)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20131231/0fa4105a/attachment.html>