From william at elan.net Mon Mar 3 09:57:46 2003 From: william at elan.net (william at elan.net) Date: Mon, 3 Mar 2003 06:57:46 -0800 (PST) Subject: [dbwg] Draft for proposal for Whois AUP Message-ID: I have draft read for my last proposal - this is to change current bulk whois data only AUP to general Whois AUP. It requires for all whois queries (no matter what protocol - which is meant to include rwhois, ldap, protocol developed by crisp WG or any other protocal that ARIN may want to use) to include a link to whois aup and for those that need access to entire data (including through ftp but also including other means such as cdrom, etc) to have to sign bulk whois aup agreement (as is done already) but does allow that once signed same access can be used more then one time with new agreement having to be signed after one month. The draft is available at: http://www.elan.net/~william/arin_proposal_whois_aup.htm Please comment what needs to be included in AUP, what needs to be changed in the draft, etc. etc. I'll submit this as actual proposal no later then Friday and if no substantial comments are received then on Wednesday. Here is a text version of the current draft: --------------------------------------------------------------------- This proposal changes current Bulk Whois Acceptable Use Policy to become general Whois Acceptable Use policy that would apply to all whois queries. In particular: 1. A new acceptable use policy called "Whois Acceptable Use Policy" is to be published on ARIN website as follows: "The ARIN Whois Data is for Internet operations and technical research purposes pertaining to Internet Operations only. It may not be used for advertising, direct marketing, marketing research or similar purposes. Use of ARIN whois date for these activities is explicitly forbidden. ARIN requests to be notified of any such activities or suspicions thereof. ARIN reserves the right to restrict access to the whois database in its sole discretion to ensure operational stability. ARIN may may restrict or terminate your access to the whois database for failure to abide by these terms of use." 2. Access to whois data with individual queries (such as by using whois protocol) must in the output either include entire 'ARIN Whois Acceptable Use Policy' in the comments or provide a one-line statement that data is provided and can only be used according to 'ARIN Whois Acceptable Use Policy' with a link to where the policy is published on ARIN website. 3. High frequency individual query access and access to either entire whois database or large portion of it must be provided with authentication to persons and organizations authorized by ARIN. These organizations must sign 'Acceptable Use Policy for Bulk Copies of ARIN Whois Data' agreement which shall include 'Whois Acceptable Use Policy' and additional statement that "Redistributing bulk ARIN Whois Data is explicitly forbidden. It is permissible to publish data on an individual query or small number of queries at a time basis as long as reasonable precautions are taken to prevent automated querying by database harvesters" Organizations that need access to ARIN whois data on regular basis maybe required to resubmit the agreement on monthly basis at which time authentication settings may need to be changed. From william at elan.net Wed Mar 5 10:55:50 2003 From: william at elan.net (william at elan.net) Date: Wed, 5 Mar 2003 07:55:50 -0800 (PST) Subject: [dbwg] Displaying Rwhois information as separate field in whois output Message-ID: As some of you know ARIN setup "rwhois design group" in January to find ways to improve ISP-maintained reassigments which is currently done through rwhois. About 10 persons participated in that and problems and possible solutions were discussed. While no agreement on futher actions was reached, it did provide some important feedback to ARIN on what they could do and yesterday I was asked to write down futher on idea I had and ARIN has reported that it would not be too difficult to do (can be done in 60-90 days). I do want to mention thogh that while there were disagreements on several issues, there was also clear agreement on one particular issue - this is to FIX RWHOIS ROOT SERVER. While its not the kind of issue that can be put in the proposal, I'm hoping that since ARIN staff has listened to what has been discussed, they understand that this is something that everybody thinks must be done to improve rwhois. Now my original idea was as follows: > 4. Convert current comments into special reassigment contact and make it > easy for automated software to determine where to get rwhois information > as well as provide clear text indicating that reassigment info is coming > out of database not maintained by ARIN There are several ways to do it with various degree of complexity. One would be to simply add a "reassignment" field into either NETWORK or ORG and make modifications to ARIN whois server so it is displaying it as separate note regarding reassignments. I believe if its done this way, we may need to make an exception and allow "TECH" contact to be responsible for maintaining this particular field (especially for ORG). There is also somewhat of a problem as I see it that there is no way to do special reassignment-only comments (but we could add additional "reassignment comment" field as well) and these I think are important in many cases for example to advertise about custom schema or to tell non-technical viewers of whois how to find reassignment contact through web interface (in reality > 50% of those accessing ARIN data have no idea what rwhois is!). Another way is to do it as actual contact, which may require a little more time for ARIN to do and in the beginning (on actual conversion) may end up with multiple reassignment contacts in place where should have been only one (for networks that have many ip blocks with rwhois server reference) but hopefully this would be fixed by the ISP itself and extra contacts removed. For this option I actually create a proposal which is located at: http://www.elan.net/~william/arin_proposal_rwhois_contact.htm Except for part#6, this is mostly database-related and thus non-policy issue and does not necessarily need to be in a proposal (and for #6 somebody else may already be working on a similar proposal). So if you are an ISP that maintains rwhois, please think about what you think would be best way to do it (as listed above) and post your comments to this list or otherwise be ready to have it discussed on Memphis meeting. Below follows my actual proposal from url above in text format, it is more complicated that what ARIN itself would like to do, but I personally think this is better. ------------------------------------------------------------------------- Reassignment (Rwhois) Whois Contact Proposal This proposal is trying to better address an issue with ISP-maintained reassignment information (rwhois servers). Currently information on rwhois is displayed as comments in the whois and there are no standards on how these comments are entered which makes it difficult to futher parse the information. In addition it is often important to know who to contact regarding technical issues with ISP-maintained rwhois server and such information is difficult to obtain. There also no procedure that would allow for rwhois maintainer to modify information on rwhois and it can only be done through ISP main administrative contact which is sometimes an issue for large ISP with many ip blocks. So to address the above it is proposed that: 1. ARIN establish new "reassignment" contact. This contact should include same fields as other ARIN whois contacts and should be the contact of the person or technical group at the ISP that is responsible for maintaining rwhois server is other similar reassignment server. 2. In addition to standard whois fields, new contact should include additional special reassignment field which should provide URN to the server that provides futher reassignment information. An example of this would be: rwhois://rwhois.someisp.net:4321 3. Whois should display a note when reassignment contact is present that makes it clear that reassignment information is maintained by the ISP and can be found through its listed rwhois server or similar service. 4. ISP may also use optional comments fields to provide additional information such as information on additional features of its reassignment server or pointer to schema used. It is recommended that comments at least include URL with link to website which can provide reassignment information so that it can be used by those who do not have direct access to rwhois or other appropriate reassignment client program. 5. ARIN should attempt to convert all current rwhois comments into new reassignment contact. In this effort ARIN should contact all ISPs that have listed rwhois or other reassignment server in comments and try to obtain information on who is the correct contact responsible for maintaining such server. If ARIN is unable to get the exact information from the ISP, ARIN may substitute information from current technical or administrative contact when creating new reassignment contact. 6. In the future when ARIN receives reports of reassignment server not answering to queries, ARIN may do its own tests for at least a month with at least 10 non-sequential queries and if there higher then 75% failure rate, ARIN should attempt to contact person or group as listed in the reassignment contact (first by email and then by phone) and if no response is received, ARIN should attempt to contact technical contact listed for the ip block to try to find resolution to the problem. If ARIN is unable to make proper contact with ISP or find resolution to a problem, ARIN may add a comment to reassignment contact indicating that listed reassignment server is "lame" similar to the way this is done for lame DNS servers. From ginny at arin.net Thu Mar 6 13:09:15 2003 From: ginny at arin.net (ginny listman) Date: Thu, 6 Mar 2003 13:09:15 -0500 (EST) Subject: [dbwg] Notification Process Message-ID: NOTIFICATION PROCESS ==================== To provide a measure of accountability, ARIN would like to implement the use of notification under two different methods. FOR ASN, NET, & ORG =================== ARIN will create three new POC types as follows: - Notify (NT): When a submitted template is processed whether successfully or not, the email address of any applicable Notify POCs, where on the Org or its resources, will be cc'ed on the confirmation or returned mail. - Notify Accept (NA): When a submitted template is processed successfully that modifies or removes an org or one its resources, the email addresses of any applicable Notify-Accept POCs, whether on the Org or its resources, will be cc'ed on the confirmation. - Notify Reject (NR): When a submitted template is reject due to failed authorization or errors in the template, the email address of any applicable Notify-Reject POCs, whether on the Org or its resources, will be cc'ed on the returned mail. ------------------------------------------------------------------------ If ARIN proceeds with this, the following issues need to be resolved. 1. For those of you who would implement this, is 3 new POCs overkill? Would a single Notify POC suffice? Or two {Notify-Accept, Notify- Reject} work better? 2. How should the POCs be displayed in WHOIS? A. Never show them. (Con: Maintainability issues) B. Always show both resource and org notify contacts (Con: Verbose output, not really needed for troubleshooting) C. On resource queries, only show resource-notify contacts, for org queries only show org-notify contacts. (Con: Still somewhat verbose) D. Display only POC's handle and email address (Con: New display type, whereas parsers are already used to manipulating contact info) ---------------------------------------------------------------------- FOR POC ONLY ============ If the mailbox is deleted/modified for an existing POC, the deleted/ modified mailbox is cc'ed. From william at elan.net Thu Mar 6 16:26:50 2003 From: william at elan.net (william at elan.net) Date: Thu, 6 Mar 2003 13:26:50 -0800 (PST) Subject: [dbwg] Notification Process In-Reply-To: Message-ID: These POC should not be displayed in whois, public really has no interest in knowing who are NT, NA, NR contacts. I think we should have "hidden" flag setup for all POCs and had default values set for different POCs, for example Abuse POC should be public default, while these 3 can be private (unless somebody wants to make it public!), I'd like to see Administrative POC private default as well. Regarding actual POCs, 3 may very well be an overkill. I'd like to ask first if this was to be used by humans for notifiactions of failure or for autmated software? In either case I don't think there is much interest in this being full POC, rather only email is really what is important, so why not just create special contact with 3 email fields for NT, NA, NR? On Thu, 6 Mar 2003, ginny listman wrote: > > NOTIFICATION PROCESS > ==================== > To provide a measure of accountability, ARIN would like to implement the > use of notification under two different methods. > > FOR ASN, NET, & ORG > =================== > ARIN will create three new POC types as follows: > > - Notify (NT): When a submitted template is processed whether > successfully or not, the email address of any applicable Notify > POCs, where on the Org or its resources, will be cc'ed on the > confirmation or returned mail. > - Notify Accept (NA): When a submitted template is processed > successfully that modifies or removes an org or one its resources, > the email addresses of any applicable Notify-Accept POCs, whether on > the Org or its resources, will be cc'ed on the confirmation. > - Notify Reject (NR): When a submitted template is reject due to > failed authorization or errors in the template, the email address of > any applicable Notify-Reject POCs, whether on the Org or its > resources, will be cc'ed on the returned mail. > > ------------------------------------------------------------------------ > If ARIN proceeds with this, the following issues need to be resolved. > > 1. For those of you who would implement this, is 3 new POCs overkill? > Would a single Notify POC suffice? Or two {Notify-Accept, Notify- > Reject} work better? > 2. How should the POCs be displayed in WHOIS? > A. Never show them. (Con: Maintainability issues) > B. Always show both resource and org notify contacts (Con: Verbose > output, not really needed for troubleshooting) > C. On resource queries, only show resource-notify contacts, for org > queries only show org-notify contacts. (Con: Still somewhat verbose) > D. Display only POC's handle and email address (Con: New display type, > whereas parsers are already used to manipulating contact info) > > ---------------------------------------------------------------------- > > FOR POC ONLY > ============ > If the mailbox is deleted/modified for an existing POC, the deleted/ > modified mailbox is cc'ed. > From ginny at arin.net Fri Mar 7 09:27:45 2003 From: ginny at arin.net (ginny listman) Date: Fri, 7 Mar 2003 09:27:45 -0500 (EST) Subject: [dbwg] Notification Process In-Reply-To: Message-ID: On Thu, 6 Mar 2003 william at elan.net wrote: > In either case I don't think there is much interest in > this being full POC, rather only email is really what is important, so why > not just create special contact with 3 email fields for NT, NA, NR? > We looked at providing notification with a new email attribute as well as defining the new POC types outlined. The new email attribute would require: 1. Major changes to all but the POC template 2. Changes in the database schema 3. Major changes in the registration software 4. If displayed in WHOIS, major changes to WHOIS If we use the newly defined POC types, it would require: 1. Instructional changes to the templates to define the new POC types 2. No changes in the database schema 3. Minor changes in the registration software 4. If displayed in WHOIS, minor changes to WHOIS This comes down to whether to implement within 30 days or 180 days. Ginny