[ARIN-consult] Oppose retiring email templates

[michael.dillon at bt.com]

> If we can tussle this apart a bit. There are two classes of templates.

Good point.

> The first class of templates are those that do not appear to 
> be automated.  
> Those are orgs, pocs, and requests for number resources. 

Nevertheless, these should be retired and since they are not
automated, the schedule for retiring them should be quicker.

At the same time, it is not sufficient to only provide a
human-to-computer interface for these transactions. There should
also be an automated interface to support ISP systems which 
want to automate these transactions for audit purposes, or
in order to control who does what.

Therefore, for first class templates, retire the email interface
and provide an alternative, probably a RESTful web interface.
That way, your interactive web tool is merely your front-end 
to the same RESTful API that others will use, and because you
also use the API, it will be properly maintained.

> The second class of templates are swips - reassign detailed, 
> reassign simple, reallocate, and netmod.  These are heavily automated.

These should also be automated, but on a longer schedule with
more steps, and more interactions with ISPs to avoid breaking
things. First step is to make a RESTful API available. Second 
is to edit all the web pages either removing all references to
the email API, or noting that it is deprecated with a URL to
the up to date site. Third step, is to log all SMTP template
submissions for two months, add all the from addresses to 
a whitelist, and then blacklist every other address. This has
the effect of allowing frequent/heavy users a longer timescale
to switch. Fourth, is to supply a web page which can be used
to submit the same templates by cut-'n'paste. This is only 
for people who submit an email template, and find that the
email service is no longer available. The reply email will
include a copy of their template, redirect them to the right
URL, and also tell them how to use the nice shiny new web api.
Fifth, contact all of the whitelisted organizations and find
out what assistance they need to switch their transaction flow
from email to the web api. Etc.

So, for class two templates, their should be a new RESTful API
that is fast and efficient (or asynchronous), a simple web page
for submitting the old email format templates, and a nice web 
application front end for low volume and occasional users.

In addition, for class two templates, ARIN should be open to
providing additional interfaces. Although SOAP is something
best avoided for efficiency purpose, not using SOAP may
raise all kinds of difficulties in a large corporate user.
XMPP is another interface that might have to be supported.
The details on this can and should be worked out later, once
you have done the two month logging of from addresses.

Early in this process ARIN should post the architecture of
the systems replacing email templates including some easy
to read diagrams. Although it is not necessary to see the
intimate details of ARIN's internals, the architecture
documentation should provide enough detail to be understandable.
For instance "... go into an RDBMS ..." is the sufficient
detail. It is not necessary to say "... go into an
Oracle 10g RDBMS running on a cluster of four OpenSolaris
XEN virtual servers each of which is on a separate physical 
server. The database itself is stored on a zpool which is
exported via iSCSI from a SAN cluster which is similarly
running on multiple physical servers..."

> The discussion leaned towards using a 
> RESTful web interface.  Of course, if we were to do this, 
> there would be ample time to agree to this approach and to 
> cut over. We are not there yet.

I think that the public discussion should be careful not to
get into too much comparison of REST vs SOAP and similar
things. More important is the schema of the data items
to be included in each transaction. If this is clear and
unambiguous, then multiple protocols and formats can easily be
used. For instance JSON over REST, XML over SOAP, XML over XMPP.
Even JSON or XML over SMTP is worth considering, just don't
use the hostmaster email address, and don't even use an SMTP
server that is used for Internet email.

The protocol/format chosen for the main transaction service
should be one that is cheap to develop for, available using
100% open source tools, and is widely used so that it is
likely most people will get their technical support from 
sources other than ARIN. Leave the more complicated stuff 
for dealing with the volume users who are wrestling with
entrenched systems and onerous change management processes.

--Michael Dillon

P.S. Please consider replacing whois/rwhois at the same time
that you do this.