<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/26/2014 11:17 AM, Andy Newton
wrote:<br>
</div>
<blockquote cite="mid:27FB8CAD-0C59-4503-A779-9A1C8A13376F@arin.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Nov 25, 2014, at 12:38 PM, Brian Rak <<a
moz-do-not-send="true" href="mailto:brak@gameservers.com">brak@gameservers.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000" style="font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://whois.arin.net/rest/net/NET-65-127-10-168-1/pft"
style="color: purple; text-decoration: underline;">http://whois.arin.net/rest/net/NET-65-127-10-168-1/pft</a><br>
<br>
Checking the start IP and end IP is not sufficient.<br>
<br>
I've been down the path you're going. The best solution I
found is:<br>
<br>
* Use /rest/report/reassignment/ROOT to get a list of all
the reassignments for a particular network (it'll be in xls
format, you need to convert it to something you can parse).<br>
* Go through the list, issue DELETE's for any subnets that
are not in your database<br>
* Wait awhile (5-10 minutes)<br>
* Go through and issue reassignments for any subnets that
are new or that ARIN doesn't know about.<br>
<br>
It's a large pain to get all the logic working correctly
here, but if you don't do it you'll be running into overlaps
and other errors forever.<br>
</div>
</blockquote>
</div>
<br>
<div>Brian,</div>
<div><br>
</div>
<div>I agree. What you have described is painful. And it is not
the first time this has been pointed out.</div>
<div><br>
</div>
<div>Though a few suggestions have been made informally over the
years, they’ve never reached much consensus and there has not
been a request that ARIN implement them.</div>
<div><br>
</div>
<div>So that we can address these issues, here is what I propose.
I will create specification document outlining new methods and
payloads for Reg-RWS, and I will send it to this list for
discussion and to get your collective input. Once we have a
document we agree will address these issues, it can be put
forward as a request for ARIN implementation.</div>
<div><br>
</div>
<div>Does this sound like a workable path forward?</div>
<div><br>
</div>
<div>Andy Newton,</div>
<div>Chief Engineer, ARIN</div>
</blockquote>
<br>
That sounds like it would be a good path forward.<br>
<br>
I'm going to talk with some of our other developers about this, and
see if we can offer any suggestions for API methods or changes that
would make it easier.<br>
<br>
One thing I can immediately think of is giving us the reassignment
report in some easily parsable format. Currently, we convert the
XLS to a CSV and parse that, but that has always seemed kinda hacky
to me. Also, if the reassignment report contained additional
details (such as the ORGID or customer ID/name) this would simplify
things for us (as we wouldn't need to hit the whois API for each
subnet)<br>
<br>
Do you have any statistics about the number of reassignments that
come in via the API, versus the number that come in via the old
email system? I'm curious to know what kind of usage it's seeing.<br>
</body>
</html>