[arin-discuss] Bringing back IP resource Request Templates

[Alec Ginsberg]

Only a single interface should be maintained.

Something such as ServiceMix where you create a backend service.  This
service can listen on SMTP, JMS, or any Web Service protocol you would
like.  You submit the XML to this service.

The web front end would submit the same data structure, just as it were
using the XML service as well.

This way there is one unified development effort for the entire thing.
You could then, if you wanted write a simple parser so that

<xml>
<attrib1>value4</attrib1>
<attrib2>value3</attrib2>
</xml>

Is processed the same as

attrib1: value4
attrib2: value3

(thus users can continue to use their template, or XML) and ARIN only
needs to maintain one codebase.  Very simple.

Hence the web template can work, with zero additional development effort.

On 4/2/12 3:55 PM, "John Curran" <jcurran at arin.net> wrote:

>On Apr 2, 2012, at 3:52 PM, Morizot Timothy S wrote:
>
>> My organization isn't an ISP and makes changes infrequently enough that
>>they are done manually whether by email template or via the web
>>interface. So that aspect of it makes little difference to us. However,
>>I can certainly see why those who make frequent changes and have put
>>automated tools in place to make those changes might have an issue.
>> 
>> And as someone with a couple of decades of application development
>>experience, I have a hard time with the "expensive" argument in this
>>situation. An email template or a web form are just two different
>>front-end interfaces. You might need a different parser for each, but
>>once the resource request is parsed the code handling the actual request
>>processing should be the same for both front-ends. Even if the web
>>front-end had additional options, those would just be additional
>>requests to process and wouldn't change the ones shared with the email
>>templates.
>> 
>> I guess I don't see why a system that accepts requests through two (or
>>more) front-end interfaces should be hard or expensive to maintain --
>>especially when the range of available requests is relatively limited,
>>as it is with ARIN.
>
>We are maintaining two interfaces at present (ARIN Online for humans,
>RESTful for programmatic access)   We can add more programmatic
>interfaces 
>(such as xml, java, etc.) or additional semi-programmatic ones (email
>templates, telnet or ftp interfaces, rje over tcp, ... :-)
>
>In any case, the maintenance expense (for an organization of our size) is
>increases with each access method because the front-end parsers need to
>be 
>updated with policy changes.  If number resource policy changes less over
>time (e.g. with increasing movement to IPv6) then it is not as
>significant, 
>but that particular timeline remains uncertain.
>
>FYI,
>/John
>
>John Curran
>President and CEO
>ARIN
>
>_______________________________________________
>ARIN-Discuss
>You are receiving this message because you are subscribed to
>the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-discuss
>Please contact info at arin.net if you experience any issues.