[ppml] A proposal to modify proposal 2003-9 (WHOIS and INADDR access)

[John Brown]

On Tue, Jun 10, 2003 at 12:44:26AM -0700, william at elan.net wrote:
> 
> Fine, lets get ARIN to listen and provide the data for all other /8 blocks!

I think that is an over statment, and certainly not something I'm asking for.
ARIN was clearly specifide and not the other RIR's.  For them they each
have their proper venue, and its not here.


> 
> Still the question is do we need a policy for this? If we do should it 
> actually require authentication similar to bulk whois to get the data or 
> is current system of getting it by ftp enough?

Based on email from ARIN staff last fall, they used to provide the data
upon request, but started refusing the data until there was a policy in
place.  

The ARIN AC (post my resignation) did not feel it was something in their
scope as defined by the board.  THe board has said that the AC is to 
deal with clear and crisp IP allocation policies only.   I think even
the whois is not within their view based on the direction from the board.


> 
> In my opinion adding in-addr to bulk-whois proposal is both not approriate
> as whois data is a lot more complex and has rather specific privacy issues,
> its unnecessory and it sounds bad as far as you wrote it (i.e. what you 
> proposed - "arin whois inaddr aup"). 

I agree, WHOIS is more complex and has privacy issues.  Hence the IN-ADDR
should be an easy issue to deal with.

I don't believe I used those words you are attributing to me.  Please
correct or quote correctly....

What I stated is that access to the whois  OR  inaddr carried with it the
same level of restrictions and conditions.  This would be more protection
for the IN-ADDR and continue to protect the whois data.


 
> First I think we need to ask ARIN if they are willing to get all the 
> inaddr data out on their ftp site on their own based on current polices 
> and procedures (they do after all provide entire ASN list including all
> those ASNs they inherited from Internic, so why is it so different for 
> inaddr?). If they do not want to do it, then propose a simple policy:
> "ARIN will provide public access to complete INADDR data for all ip 
> blocks in its database for public download by ftp"

Well todate ARIN has refused to provide IN-ADDR lacking a policy.  I can
dig up the email from ARIN staff issued last fall, if needed.

Agreed they have the ASN data, the IN-ADDR seems easy as well since they
have to gen the zone for their NS set anyway.

Personally I believe that ARIN should have an AUP for this data.

John Brown

> 
> > > -----Original Message-----
> > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> > > Behalf Of william at elan.net
> > > Sent: Monday, June 09, 2003 11:44 PM
> > > To: John M. Brown
> > > Cc: ppml at arin.net
> > > Subject: Re: [ppml] A proposal to modify proposal 2003-9 
> > > (WHOIS and INADDR access)
> > > 
> > > 
> > > Why do you need policy for providing in-addr data as bulk? I 
> > > think ARIN 
> > > already provides this all publicly as it, see 
> > > ftp://ftp.arin.net/pub/zones
> > > 
> > > Do you need something more then 
> > > that?
> > > 
> > > On Mon, 9 Jun 2003, John M. Brown wrote:
> > > 
> > > > 3. A policy for bulk WHOIS and or ARIN INADDR access will 
> > > be published 
> > > > on
> > > >    ARIN website as follows:
> > > > 
> > > > "Access to the entire WHOIS or ARIN INADDR database or 
> > > large portion 
> > > > of
> > > > it may be obtained by any organization or individual 
> > > provided that this 
> > > > organization or individual agrees in writing to ARIN WHOIS/INADDR
> > > > Acceptable 
> > > > Use Policy. WHOIS or ARIN INADDR data provided under bulk 
> > > WHOIS access 
> > > > will not include any information that is marked as private.
> > > > 
> > > > Access to WHOIS/INADDR data may be by way of:
> > > > 
> > > > Individual WHOIS/DNS queries
> > > > 
> > > > FTP or other type of download
> > > > 
> > > > Hard media distribution (such as CDROM)
> > > > 
> > > > 
> > > > -----
> > > > 
> > > > Given that ARIN now has policy  2002-1 Lame In-addr, 
> > > providing access 
> > > > to the in-addr view that ARIN has would be useful for the internet 
> > > > operational and research community, and help reduce lame 
> > > issues.  This 
> > > > access would allow service providers access to the IN-ADDR tree and 
> > > > allow them to self verify what deligations they are listed as 
> > > > authoritative for.  It would allow the research community a better 
> > > > source of data for research and other activities.
> > > > 
> > > > 
> > > > respectfully,
> > > > 
> > > > john brown
> > > 
>