From cathym at arin.net Tue Sep 4 10:45:28 2001 From: cathym at arin.net (Cathy Murphy) Date: Tue, 4 Sep 2001 10:45:28 -0400 (EDT) Subject: authorizing changes in the new registration database In-Reply-To: <20010821014458.A8697@mars.lab.time-travellers.org> Message-ID: On Tue, 21 Aug 2001, Shane Kerr wrote: > [ Warning: long, strange trip follows. ] My favorite kind. Say hello to Hari for me. :) [ Warning: an equally long, though less eloquent, response. ] After trying to formulate a coherent response to your philosophical musings (which raised some intriguing technical issues), I decided to postpone that discussion and, for now, respond to your comments to our specific questions. > > Question 1 - Who should be authorized to create an organization record > > for a reallocation or reassignment? > > > > Option A: The upstream ISP creates an organization record on behalf of > > the organization receiving a reallocation or reassignment. > > Option B: The customer organization creates its own organization record. > > Option C: Either the customer or the upstream ISP may create the > > record. [2] > > Option C makes sense to me, IFF there is a mechanism for the upstream > ISP to be notified of changes to the organization record, with the > contents of the original record. This will allow ISP's some degree of > certainty that the information will not be changed without their notice, Notification is possible, but let's consider: one of the benefits of allowing a downstream customer organization to create and maintain its own org record is to accommodate the multi-homed customer. If the customer record is being used on registrations from different providers, the logical action would be to notify all upstream providers about the change. I question whether this is something we really want to do. Either the upstream ISP controls the downstream's org info, or it doesn't. Does the notification really provide any value to the upstream provider? > and if they don't like the new information that they can create a new > organization with the necessary info. Yikes! This is exactly what we are trying to discourage. While this might be necessary, it leads to the situation we face today: two, three ... ten records for a single entity, all with slightly different company names and addresses. The only reason to permit option B in the first place is to reduce the likelihood of this happening. In this case, I worry that the change notification might actually lead to more org records being created than if we just say from the start that multi-homed downstream customers are going to have as many org records as they have upstream providers. > > Question 2 - When should this organization record be created? > > > > Option A: The record should be created before the reallocation or > > reassignment is made via a separate "Organization Template." > > One potential problem with option A is cruft building in up in the > database. If random folks (like me!) on the Internet can create > organization records without having received any allocations, then > you're going to have people doing this. Even if it restricted to > members only, you're still going to see unreferenced records due to > mistakes, confusion, or other problems. We considered this, but we plan on having functionality in place that will track if and when these records become "resource-less". After "N" number of days of remaining resource-less, a record would be automatically deleted. Yes, some useless records are going to get created and they might reside in the database (and get displayed in Whois) for a little while, but they will not become permanent cruft. This is the same situation we are likely to have with POC's. When deciding to suggest this, we balanced the potential for garbage-in data collection against the ease of making the registration. If we implement this, and we find it is being abused more than it has proven useful, we can always disable the functionality. It is definitely a concern we'll need to monitor over the long term. The question at this point remains: is it something we should even try, given these concerns? > > Question 3 - Should the customer organization record be permitted to > > have the POC of their upstream ISP or must the POC be > > from their own organization? > > > > Option A: The POC is the upstream ISP. The upstream ISP > > would have control over reassignment data since the > > customer organization would not be able to update its > > own organization data. > > > > Option B: The customer organization must have their own POC. If they > > directly apply for address space in the future, ARIN will be > > able to identify how they have managed space in the > > past. ARIN can maintain a more accurate database and reduce > > duplicate responses to a whois query for a common name. > > > > Option C: The customer organization may have their own POC, but the > > upstream ISP might alternately specify its own POC for the > > reallocation. > > Is each allocation not going to have its own POC, independent of any > organizational POC? No, quite the reverse. [We probably should have been more specific in our POC terminology while explaining this.] Each allocation may have a technical POC, which will allow them to do things like provide reassignment information. However, an organization's administrative POC is normally a superset of the technical POC's authority. Question 3 relates to this administrative POC on the downstream customer. Must it be different from the upstream, or may the upstream maintain administrative control of the org info, even though it might be turning over administrative control of the allocation to the downstream customer? > This would allow an ISP to specify either their > organizational POC, their downstream's POC, or even a different POC, > while still allowing the downstream to update its organization > information in all cases. I believe that this is what we were trying to get at in Option C. In this case, the admin POC on customer organizations does not represent a superset of authority. Rather, authority would be limited to updating organization information only. > > Shane > Hope this clarifies things a bit. Cathy From ginny at arin.net Thu Sep 6 15:25:31 2001 From: ginny at arin.net (ginny listman) Date: Thu, 6 Sep 2001 15:25:31 -0400 (EDT) Subject: RWhois Beta Testers Needed Message-ID: The Engineering Department at ARIN has release a BETA version of the Referral Whois (RWhois) server software. rwhoisd-1.5.8 is a release version that is being distributed by ARIN for testing purposes only. It can be retrieved from ftp://ftp.arin.net/pub/rwhois/rwhoisd-1.5.8.tgz in tar-gzip format. It does have a dependency that will need to be installed beforehand. The str library from Ralph Engelschall (rse at engelschall.com) can be obtain from either ftp://ftp.arin.net/pub/rwhois/str-0.9.5.tar.gz or http://www.engelschall.com/sw/str/str-0.9.5.tar.gz This RWhois version incorporates the server retrieving the link referrals data from the remote server and sending record back to the client. For this to be enabled it must be specified on the command line with the -R flag. There is a known bug that ARIN will be working to resolve in a later version. The data returned from the remote server has not been stripped of its etc. flags. Therefore, the client will get a "double dose" of flags. Comments and questions can be directed to this list, or sent directly to the developer, Adam Guyot at adamg at arin.net. Ginny Listman Director of Engineering ARIN From cathym at arin.net Tue Sep 18 11:10:49 2001 From: cathym at arin.net (Cathy Murphy) Date: Tue, 18 Sep 2001 11:10:49 -0400 (EDT) Subject: RWhois update Message-ID: While I'm at it, a plug for the home team: ARIN released a beta version of an updated RWhois server software with working referrals. Interested parties can find further details at: http://www.arin.net/mailinglists/dbwg/0153.html Please direct further discussion of this topic to ARIN's Database Working Group mailing list. --- Cathy Murphy American Registry for Internet Numbers (ARIN) From ginny at arin.net Wed Sep 26 11:36:08 2001 From: ginny at arin.net (ginny listman) Date: Wed, 26 Sep 2001 11:36:08 -0400 (EDT) Subject: RWHOIS Update Message-ID: At the ARIN Open Policy and Member Meeting in San Francisco (2-4 Apr 2001) there was consensus that RWHOIS was in dire need of repair. This echoed similar sentiments that had been raised on various mail lists. In response to this desire, work begun on "fixing" RWHOIS. On September 6, ARIN's Engineering Department announced the release of a beta version of the RWHOIS software. Details are at: http://www.arin.net/mailinglist/dbwg/0153.html Since that time, there has been approximately 30 downloads from our ftp site. I have receive only one comment from someone who had problems compiling the software. My questions to the community are: 1. Is RWHOIS an option for your company to replace SWIP? 2. If you haven't download it yet, do you plan on downloading at a later time? Are you busy establishing a test site? 3. If you have downloaded it, have you done any testing? Have you found any bugs? Can you make any recommendations for improvement? 4. Is investing in RWHOIS development a good allocation of ARIN Engineering resources? These issues will be discussed at the ARIN Member Meeting scheduled for late October in Miami. However, discussing these questions now will help facilitate that discussion. Please send all responses to dbwg at arin.net. Ginny Listman Director of Engineering American Registry for Internet Numbers (ARIN) From huberman at gblx.net Wed Sep 26 12:03:26 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 26 Sep 2001 09:03:26 -0700 (MST) Subject: RWHOIS Update In-Reply-To: Message-ID: > 4. Is investing in RWHOIS development a good allocation of ARIN > Engineering resources? I think we formed consensus in San Francisco - RWHOIS is a legitimate method of demonstrating customer reassignments which should be supported by ARIN Engineering for the community. Until the day comes when ARIN's database is redesigned *and* available for everyone to use, RWHOIS is much preferable than SWIP for many organizations. /david From markk at netsol.com Wed Sep 26 13:03:47 2001 From: markk at netsol.com (Mark Kosters) Date: Wed, 26 Sep 2001 13:03:47 -0400 Subject: RWHOIS Update In-Reply-To: ; from ginny@arin.net on Wed, Sep 26, 2001 at 11:36:08AM -0400 References: Message-ID: <20010926130347.F1105@slam.admin.cto.netsol.com> Ginny Techincally, I think ARIN can best help its members use RWHOIS is to provide RWHOIS with a better backend that allows for an easier way for members to maintain their own data. mkdb is way too complicated for most people to use. Additionally on the support side, it would be helpful if howtos and registration interfaces where clearly documented and supported for people to link in their servers. Since the documentation is lacking, there are lots of howto questions on the rwhois mailing list from those members who setup their servers. I feel their pain. Mark On Wed, Sep 26, 2001 at 11:36:08AM -0400, ginny listman wrote: > > At the ARIN Open Policy and Member Meeting in San Francisco (2-4 Apr 2001) > there was consensus that RWHOIS was in dire need of repair. This echoed > similar sentiments that had been raised on various mail lists. In > response to this desire, work begun on "fixing" RWHOIS. > > On September 6, ARIN's Engineering Department announced the release of a > beta version of the RWHOIS software. Details are at: > > http://www.arin.net/mailinglist/dbwg/0153.html > > Since that time, there has been approximately 30 downloads from our ftp > site. I have receive only one comment from someone who had problems > compiling the software. > > My questions to the community are: > > 1. Is RWHOIS an option for your company to replace SWIP? > 2. If you haven't download it yet, do you plan on downloading at a later > time? Are you busy establishing a test site? > 3. If you have downloaded it, have you done any testing? Have you found > any bugs? Can you make any recommendations for improvement? > 4. Is investing in RWHOIS development a good allocation of ARIN > Engineering resources? > > These issues will be discussed at the ARIN Member Meeting scheduled for > late October in Miami. However, discussing these questions now will help > facilitate that discussion. Please send all responses to dbwg at arin.net. From ginny at arin.net Wed Sep 26 13:01:44 2001 From: ginny at arin.net (ginny listman) Date: Wed, 26 Sep 2001 13:01:44 -0400 (EDT) Subject: RWHOIS Update In-Reply-To: Message-ID: > > > http://www.arin.net/mailinglist/dbwg/0153.html > > > > Bad URL :) > Sorry. Make that: http://www.arin.net/mailinglists/dbwg/0153.html Ginny From aditya at grot.org Wed Sep 26 14:02:00 2001 From: aditya at grot.org (R.P. Aditya) Date: Wed, 26 Sep 2001 11:02:00 -0700 Subject: RWHOIS Update In-Reply-To: <20010926130347.F1105@slam.admin.cto.netsol.com>; from markk@netsol.com on Wed, Sep 26, 2001 at 01:03:47PM -0400 References: <20010926130347.F1105@slam.admin.cto.netsol.com> Message-ID: <20010926110200.C84875@mighty.grot.org> I second Mark's comment. I also want to mention a few specific things that might help or warrant discussion: On Wed, Sep 26, 2001 at 01:03:47PM -0400, Mark Kosters wrote: > Additionally on the support side, it would be helpful if howtos and > registration interfaces where clearly documented and supported for people to > link in their servers. Since the documentation is lacking, there are lots of > howto questions on the rwhois mailing list from those members who setup > their servers. I feel their pain. The most difficult thing about setting up a rwhois server that I faced was trying to figure out the minimum amount of information ARIN needed on a per-allocation basis. It would be ideal if ARIN had a note about which fields were required in an rwhois record. My "schema", if it helps, was as follows (The ID field was a rowid from the SQL table this data was kept): network:Class-Name:network network:ID:DNAI-BLK-2-1395 network:Auth-Area:216.15.0.0/17 network:Handle:DNAI-BLK-2-1395 network:Network-Name:DNAI-BLK-2-1395 network:IP-Network:216.15.97.5/32 network:In-Addr-Server:207.181.194.14 network:In-Addr-Server:207.181.193.2 network:IP-Network-Block:216.15.97.5 - 216.15.97.5 network:Organization;I:R.P. Aditya network:State:CA network:Country-Code:US network:Tech-Contact;I:blah at grot.org network:Created:1999-04-20 10:46:56 network:Updated:2001-08-25 14:59:19 ARIN did subsequently use the data presented in this format for a new block, so I guess it was good enough. It would be nice for those setting up new rwhois servers to know definitively. > Techincally, I think ARIN can best help its members use RWHOIS is to provide > RWHOIS with a better backend that allows for an easier way for members to > maintain their own data. mkdb is way too complicated for most people to use. I addressed this by writing a few perl scripts that took the output of the SQL data we collected and transformed it into a form suitable for mkdb on a nightly basis. Since then (2 odd years), I'm starting to think that a better direction to move is toward making rwhois more like LDAP, or better yet having rwhois replaced by LDAP. I am still a LDAP newbie and would welcome knowing the difficulties of making that transition. The main "problem" I see with LDAP is to define an attribute "IP-Network" that can be searched in more than a purely regexp fashion... However, even v1.5.3 of rwhoisd that is still running as of 2+ years ago worked far, far better than SWIP ever did or will. Thanks, Adi > > Mark > > On Wed, Sep 26, 2001 at 11:36:08AM -0400, ginny listman wrote: > > > > At the ARIN Open Policy and Member Meeting in San Francisco (2-4 Apr 2001) > > there was consensus that RWHOIS was in dire need of repair. This echoed > > similar sentiments that had been raised on various mail lists. In > > response to this desire, work begun on "fixing" RWHOIS. > > > > On September 6, ARIN's Engineering Department announced the release of a > > beta version of the RWHOIS software. Details are at: > > > > http://www.arin.net/mailinglist/dbwg/0153.html > > > > Since that time, there has been approximately 30 downloads from our ftp > > site. I have receive only one comment from someone who had problems > > compiling the software. > > > > My questions to the community are: > > > > 1. Is RWHOIS an option for your company to replace SWIP? > > 2. If you haven't download it yet, do you plan on downloading at a later > > time? Are you busy establishing a test site? > > 3. If you have downloaded it, have you done any testing? Have you found > > any bugs? Can you make any recommendations for improvement? > > 4. Is investing in RWHOIS development a good allocation of ARIN > > Engineering resources? > > > > These issues will be discussed at the ARIN Member Meeting scheduled for > > late October in Miami. However, discussing these questions now will help > > facilitate that discussion. Please send all responses to dbwg at arin.net. From jiml at mrtg.noc.adelphia.net Wed Sep 26 15:45:07 2001 From: jiml at mrtg.noc.adelphia.net (James W. Laferriere) Date: Wed, 26 Sep 2001 15:45:07 -0400 (Eastern Daylight Time) Subject: RWhois Beta , Url: Please . Message-ID: Hello All , The last Url: I had for the info on how to acquire the beta appears to be nolonger valid . Could someone please refresh ? Also what small bit of searching I did at the arin webpage porved useless . Prolly because I didn't know where to look . Tia , JimL James W. Laferriere Research Engineer jlaferriere at adelphia.net 814.260.3697 Voice 814.260.3760 Fax From memsvcs at arin.net Fri Sep 28 13:16:32 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 28 Sep 2001 13:16:32 -0400 (EDT) Subject: Policy Proposal 2001-7 Message-ID: <200109281716.NAA20688@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. ARIN currently provides a bulk copy of WHOIS output only to organizations that will use the data for technical research purposes and sign an acceptable use policy. Point of contact information is excluded from these bulk copies. APNIC and RIPE NCC provide bulk copies of their WHOIS output on their FTP sites for any organization that wishes to obtain the data providing they agree to the acceptable use policy that accompanies the data. Proposal: It is proposed ARIN provide a bulk copy of WHOIS output, minus point of contact information, on the ARIN FTP site for download by any organization that wishes to obtain the data providing they agree to ARIN's acceptable use policy that would accompany the data. This policy proposal discussion will take place on the database working group mailing list (dbwg at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers