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

Joe Baptista baptista at dot-god.com
Tue Jun 10 18:58:07 EDT 2003


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

> 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 hope they can do it because if they can't i think it would bring into
question their competency.

> 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?

thats something i've heard from time to time that some of the data is bad
- portions lost - etc etc.

regards
joe

Joe Baptista - only at www.baptista.god

  4Mozilla http://mozilla.ppp/

>
> 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
> > >> > >
>
>




More information about the ARIN-PPML mailing list