[arin-ppml] SWIPs & IPv6

[michael.dillon at bt.com]

> I suspect that with such large IPv6 allocations, the need to 
> keep SWIP/(rwhois) data up to date will diminish, severely 
> hindering folks that use SWIP data on a regular basis.  

I think that a good way to counter this would be to provide
an easy to use, standard way, for providers to report this
information. The current SWIP system is not the way forward.

A better architecture would be for every provider to run
their own server which provides an rwhois-like service to
lookup the status of the provider's prefixes. This service
should allow for richer information to be provided than 
just assigned/unassigned. This provides the possibilities
for providers to cooperate under the auspices of some other
organization like MAAWG and agree to provide each other
certain status information. For instance they could flag
an address as a former SPAM source that was dealt with, or
a botnet infestation that was cleaned, or any other status
information that is useful to share.

ARIN's role would be to produce the open-source software 
package to run this service, to define a minimum set of status
to be reported, and to provide a mirroring service. In this
way, the ISP's responsibility is to record the status in
their database and to make sure that their status reporting
server has access to the database. People can then query
the ISP's server directly, or ARIN's mirror, or a 3rd party
mirror at their liberty.

In addition to lookups, the server should provide support for
mirroring, i.e. it should be possible to query for all updates
since a certain time, and get a batch feed of the changes for
the ARIN mirror.

Included in the minimum status information to be reported, 
should be the identity and contact information for the people
who are charged with managing the network which uses
particular address range. This should never be assumed to
be the party to whom the addresses were assigned, but should
by default be the ISP who owns the allocation. Rather than 
overloading the existing whois data with multiple meanings,
this new service should make a serious effort to separate
things so that the current status of an address block is
reported clearly and unambiguously. And the protocol used
for this should be extensible, for instance don't use a
yes/no value for "assigned", but use a 3 digit status code
with value 000 meaning unused, 001 meaning assigned, and
all the rest of the values open for definition in future.
And don't return a single code, but return a list of codes
so that you can have either "001," or "001,202" meaning 
assigned and blocked for non-payment. REST may be the best
protocol to choose for this status reporting.

We have the opportunity here to fix the whois system and
replace it with something that makes sense for the long 
haul, and get rid of the legacy of identifying system 
users to justify DARPA funding.

--Michael Dillon