[arin-ppml] Policy Proposal: Whois Integrity Policy Proposal

Leo Bicknell bicknell at ufp.org
Tue Aug 19 20:59:53 EDT 2008


In a message written on Tue, Aug 19, 2008 at 05:06:16PM -0600, Eric Westbrook wrote:
> > The other issue is how to keep these records up to date over time.
> > One of the tools ARIN uses is yearly billing contact; if someone
> > fails to pay the bills the information ARIN has to track down the
> > owner should be at most 18 months old.  There is a much greater
> > chance of things like postal mail forwarding continuing to work,
> > old records being available, etc.  Since I believe billing requires
> > a contract, the LRSA is the appropriate contact in this place.
>
> This point does nothing to support the suggestion that an RSA improves 
> whois integrity.  Furthermore, it fails to be a compelling reason for 
> RSA conversion in any case, since without a contract, there is no 
> "tracking down" at all required for billing, as there is no billing.

I disagree.  When people or businesses relocate there is often a
period of around a year of mail forwarding.  If ARIN sends a paper
bill and it is received with a forward sticker on it that serves
as a reminder to the resource holder to privide ARIN updated address
information for BOTH billing and whois.  If there is no billing,
there is no reminder.

I am a firm believer that to have a billing relationship there must
be a contract. I do not necessarily believe that contract must be
the legacy RSA; ARIN could develop another type of contract if the
community felt that was necessary.  However the legacy RSA does
fill the role of a contract, and is available right now.

I would be happy to discuss changes to the legacy RSA or an entirely
different contract, but having no contract is unacceptable to me.

> > The alternative is for ARIN to do the complete re-authentication
> > on every request, which could be costly, time consuming, and annoying
> > for both parties.
>
> I think this is a key point of confusion -- personally, I fail to see a 
> difference in effort (or confidence) between authenticating that someone 
> is the resource holder of record, and that someone is the contract 
> holder of record.

There is no difference in making that determination /one time/.

Consider two scenarios:

1) Bob works for XYZ corp and processes an update to a legacy record.
   Bob provides proof he works for xyz, xyz's letter where they received
   the space, and a copy of his passport to authenticate.

2) Bob gets hit by a bus.

3) Ted goes to update XYZ corps information, and must toally
   reauthenticate.  Ted supplies all the same paperwork again,
   which is reviewed again by ARIN staff.

-vrs-

A) Bob works for XYZ corp and processes an update to a legacy record.
   Bob provides proof he works for xyz, xyz's letter where they received
   the space, and a copy of his passport to authenticate. Bob requests 
   a digital certificate from ARIN for the companies role account.
   (http://www.arin.net/CA/)  Bob places it in a lockbox at work.

B) Bob gets hit by a bus.

C) Ted gets the certificate from the lock box, sends an update to ARIN,
   which is authenticated by the certificate automatically by machine
   with no human intervention.

Step 3 is a manual, staff intensive step (that's likely to also be
intensive for Ted).  Step C is a fully machine automated process.
For update #1 you are totally correct, there is no difference, for
updates 2..N, there is possibly a large difference.  The goal here
is to make it easier for BOTH sides to update information, with a
goal to keep the information more up to date.  It is stale information
that attracks the hijackers and allows them to be most successful.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080819/bc978567/attachment-0001.sig>


More information about the ARIN-PPML mailing list