[ppml] Policy Proposal 2007-3 - Staff Assessment

[michael.dillon at bt.com]

>      4.	At this time, ARIN's functionality covers only 
> e-mail based
> communication. The policy uses the general term, 
> "communication", which
> may be interpreted to cover other forms of electronic interaction such
> as web-based communication. The only other "communication" that is
> directly tied into a specific POC is voting. Should the 
> Election System
> need to be modified to allow x.509 authentication, assuming 
> we could use
> parts of the existing system, a ballpark estimate on implementation
> would be 3-4 months.

This is the kind of rathole you get into when you put too many details
into a policy. Policy is not a process document. Policy is a general
framework that defines limits, mandates, etc. 

>      5.	We recommend that a new NRPM section be created, "12.
> Communications" and that 12.1 be "Authentication". The subsequent
> numbering would change appropriately.

This is a good idea, but the details still need to be kept out of
policy. For instance:
----------
12.1 Authentication - ARIN will maintain and support a variety of
mechanisms to authenticate communication. The mechanisms will meet the
following principles:

a) Organizations can implement the authentication using software which
is in the public domain or is licenced by one of the open-source
licences accepted by the Open Source Initiative.

b) The mechanism is reviewed by someone certified by GIAC and if
deficiencies are found, these are published and a more secure mechanism
is also made available.

c) The ARIN membership is polled on a regular basis to ensure that the
mechanisms available meet their needs.

d) Any suggestions made under the ASCP which indicate issues with the
security of a mechanism are dealt with promptly in consultation with a
GIAC-certified expert.
-------------

Note that I never mentioned PGP or X.509 because these are irrelevant to
policy. I did mention GIAC certification but this can be achieved by
training ARIN staff, hiring new staff, or hiring a consultant as needed.
I also mentioned polling the members to ensure that if there is demand
for a new mechanism (RESTful API over HTTPS) it will get implemented and
if there is demand to keep the insecure mail-from, it will be kept as
one of a number of options. I also included the open-source comment
because I believe that it is consistent with ARIN's nature as an open
organization and with the history of RIR support software development.

If that policy had been in place, and the ASCP had been in place, I
suspect that the submitters of 2007-1, 2, 3 would never have bothered to
submit these policy proposals.

--Michael Dillon