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

[McBurnett, Jim]

William, 
My point is: 
Pretend I am ARIN saying this: Why should I do anything unless 
the entire community agrees that I do it?
Now to push that farther--- What does it take for the "COMMUNITY"
to agree-- Policy...
Hence They are trying to stop something from becoming work...
I know it takes just a cron... But can they do it?
I have seen on here in the past about how easy many of us say it 
is to create an automated engine for IP assignment, and they can't do that...

And yes I agree.. There is some kind of reason to prevent all of it from
going on the net.. 
And yes they are hiding behind policy-- or so it seems to me......
Whether is be a skeleton, or they are afraid it will create lots of work after
everyone tells them the data is so bad thay have to clean it up there has to be 
a reason... 

But now the question of the hour--- Alec, Richard--- Et al... WHAT IS IT?

J

-----Original Message-----
From: william at elan.net [mailto:william at elan.net]
Sent: Tuesday, June 10, 2003 1:42 PM
To: ppml at arin.net
Subject: RE: [ppml] A proposal to modify proposal 2003-9 (WHOIS and
INADDR access)


On Tue, 10 Jun 2003, McBurnett, Jim wrote:

> And finally, Policies? if ARIN needs a Policy for everything, 
> then how will they every get anything done...
> But honestly, I think this whole topic is about justifing 
> workload or preventing workload. let's get the label right.....

What workload??? They already have these zone files as they use them in 
the dns server. The "workload" involves setting a cron to copy them 
daily to publicly available ftp or web server...

I simply do not understand why ARIN makes some zone files publicly 
available already and not others. There seems to be some kind of other 
reason (not "workload") behind them not putting the rest of the 
zone files 
up and I'd like to know what it is.

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, June 10, 2003 12:09 PM
> To: ppml at arin.net
> Subject: Re: [ppml] A proposal to modify proposal 2003-9 (WHOIS and
> INADDR access)
> 
> 
> OK... I guess I'll throw my hat in the ring here...
> 
> I think that the IN-ADDR data should be provided.  If ARIN staff feels
> a policy is needed, then I think two things have happened...
> 
> 	1.	ARIN staff has become too policy focused.  IN-ADDR can
> 		be easily mapped by repeatedly hitting the DNS servers
> 		and there are no privacy issues with it.  The 
> data should
> 		simply be made available.  As such, I hope this 
> will provide
> 		the impetus for RichardJ to get whatever approvals are
> 		necessary from ARIN Management/BOD to make this 
> happen without
> 		policy.
> 
> 	2.	We have discovered the need for additional 
> clarification to
> 		the ARIN staff of what should and should not require
> 		formal public policies to accomplish.
> 
> Personally, I think that the ARIN IN-ADDR zone file(s) should be made 
> available
> via FTP and/or HTTP and that should be the end of it.
> 
> However, I am not diametrically opposed to applying the same 
> AUP to WHOIS
> and IN-ADDR.  I think it is policy overkill, but, it's 
certainly better
> than not having the IN-ADDR information available at all.
> 
> Owen
> 
> 
> --On Tuesday, June 10, 2003 4:39 AM -0600 John Brown 
<john at chagres.net> 
> wrote:
> 
> > 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
> >> > >