From jjbrzozowski at lucent.com Wed Oct 2 12:43:57 2002 From: jjbrzozowski at lucent.com (John Brzozowski) Date: Wed, 2 Oct 2002 12:43:57 -0400 Subject: [dbwg] SWIP Field Order References: Message-ID: <012201c26a32$e77d68e0$371e640a@quadritek.com> Can anyone tell me whether the order of the fields in SWIP reports matters? Thanks, ============================================ John Jason Brzozowski Lucent Technologies (O) 610-722-7979 (F) 610-725-8559 mailto:jjbrzozowski at lucent.com mailto:jbrzozowski at quadritek.com http://qip.lucent.com/ ============================================ From joe.provo at rcn.com Wed Oct 2 13:36:50 2002 From: joe.provo at rcn.com (Joe Provo) Date: Wed, 2 Oct 2002 13:36:50 -0400 Subject: [dbwg] Portable/non-portable flags gone? Message-ID: <20021002133650.A17698@noc.ultra.net> Seems that in the change over to the new format, "non-portable" flags got dropped, munged or changed to non-displaying. Everything I check that 'should' have the modern equivalent of the old "ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE" don't have anything in the only space I'd expect something ("Comment:"). Recent allocations do appear to properly be tagge; is ARIN going to true up with old data or do delegaees need to re-file portability status with ARIN? Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.486.7610 Network Deployment & Management, RCN From ginny at arin.net Wed Oct 2 14:50:39 2002 From: ginny at arin.net (ginny listman) Date: Wed, 2 Oct 2002 14:50:39 -0400 (EDT) Subject: [dbwg] Portable/non-portable flags gone? In-Reply-To: <20021002133650.A17698@noc.ultra.net> Message-ID: You have found a bug in the registration software. This bug has also been reported by someone from Telus. We have corrected the bug and are working on correcting any records for templates that were processed prior to the fix. You should see the corrected record in tomorrow's WHOIS. Ginny Listman Director of Engineering ARIN On Wed, 2 Oct 2002, Joe Provo wrote: > > Seems that in the change over to the new format, "non-portable" flags > got dropped, munged or changed to non-displaying. Everything I check > that 'should' have the modern equivalent of the old "ADDRESSES WITHIN > THIS BLOCK ARE NON-PORTABLE" don't have anything in the only space > I'd expect something ("Comment:"). Recent allocations do appear to > properly be tagge; is ARIN going to true up with old data or do > delegaees need to re-file portability status with ARIN? > > Cheers, > > Joe > > -- > Joe Provo Voice 508.486.7471 > Director, Internet Planning & Design Fax 508.486.7610 > Network Deployment & Management, RCN > From ginny at arin.net Fri Oct 4 14:48:07 2002 From: ginny at arin.net (ginny listman) Date: Fri, 4 Oct 2002 14:48:07 -0400 (EDT) Subject: [dbwg] SWIP Field Order In-Reply-To: <012201c26a32$e77d68e0$371e640a@quadritek.com> Message-ID: John, Sorry for the delayed response. You cannot change the order of the fields on any of the ARIN templates. However, you may remove any fields that are left blank. Ginny Listman Director of Engineering ARIN On Wed, 2 Oct 2002, John Brzozowski wrote: > Can anyone tell me whether the order of the fields in SWIP reports matters? > > Thanks, > > ============================================ > John Jason Brzozowski > Lucent Technologies > (O) 610-722-7979 > (F) 610-725-8559 > mailto:jjbrzozowski at lucent.com > mailto:jbrzozowski at quadritek.com > http://qip.lucent.com/ > ============================================ > From brmandal at att.com Thu Oct 17 14:28:39 2002 From: brmandal at att.com (Mandal, Barbara R, ALCNS) Date: Thu, 17 Oct 2002 14:28:39 -0400 Subject: [dbwg] problems getting orgID Message-ID: <62DA45D4963FA747BA1B253E266760F9043DFB97@OCCLUST04EVS1.ugd.att.com> We are having a lot of problems getting the orgID by automating whois through a firewall. Can't the orgID be included in the success response to Reassign-Detailed? Barbara Mandal INSTAR Systems Engineering (732) 420-2368 From ginny at arin.net Mon Oct 21 10:10:22 2002 From: ginny at arin.net (ginny listman) Date: Mon, 21 Oct 2002 10:10:22 -0400 (EDT) Subject: [dbwg] ARIN WHOIS Server Definition Message-ID: ARIN staff has been asked to publish the current WHOIS Server Definition to the DBWG mailing list. Listed below is a document that fully defines ARIN WHOIS. Ginny Listman Director of Engineering ARIN ***************** WHOIS SERVER DEFINITION I. Uses of Whois a. As a troubleshooting aid b. For applications that use resource assignment information c. To show address space utilization d. In the future, to display routing objects II. Formats a. The "default" format is displayed when querying Whois without any flags, and there is a single record returned. For ease of use all items will include labels. Any fields that have more than one line of data, for example, Address and Comment, will have only one label with all lines indented accordingly. The five registration types will be displayed as follows: i. Point Of Contact - display all attributes of the POC Name: or Handle: Company: Address: Country: Comment: RegDate: Updated: Phone: () Email: Note: Phone and Email may be repeated for multiple entries. Note: All POC handles end with -ARIN. ii. Organization - list the organization and all associated POCs OrgName: OrgID: Address:
Country: Comment: RegDate: Updated: Handle: Name: Phone: Email: Note: Organization POC functions include Admin, Tech, Abuse and NOC. iii. Autonomous System - list the organization, the autonomous system, POCs for the autonomous system, and POCs for the organization OrgName: OrgID: ASNumber: ASName: ASHandle: Comment: RegDate: Updated: Handle: Name: Phone: Email: Note: All POCs for the AS, if any, will be displayed. Only the organization's Tech, Abuse and NOC POCs will be displayed. iv. Organization Network - list the organization, the network, POCs for the network, POCs for the organization OrgName: OrgID: NetRange: CIDR: NetName: NetHandle: Parent: NetType: NameServer: Comment: RegDate: Updated: Handle: Name: Phone: Email: Note: All POCs for the network, if any, will be displayed. Only the organization's Tech, Abuse and NOC POCs will be displayed. NameServer will be repeated for multiple servers. v. Customer Network - list the customer, the network CustName: Address:
Country: RegDate: Updated: NetRange: CIDR: NetName: NetHandle: Parent: NetType: Comment: RegDate: Updated: Note: Customer records will not contain POCs. Net Types include: Allocated to APNIC Allocated to ARIN Allocated to RIPE NCC Direct Allocation Direct Assignment Early Registrations, Maintained by ARIN Early Registrations, Maintained by APNIC Early Registrations, Maintained by RIPE NCC IANA Reserved IANA Special Use Reallocated Reassigned b. The "list" format is returned when querying Whois without specifying any flags, and there are multiple records returned. Labels are not included. The fields that are displayed are outlined below. i. Point Of Contact - last, first and middle name or role name, handle, one email address, one office phone number ii. Organization - organization name, organization ID iii. Autonomous System - organization name, handle, AS name, AS number iv. Network - organization name, network name, handle, network range III. Query Flags. There are different types of flags that can be used to narrow the search. In general, you may use only one from each category, except where explicitly stated. a. Query by type. To narrow a search, a query can include one of the listed flags (either upper or lower case) to indicate the object type as follows: i. a will return only autonomous systems ii. c will return only customer networks iii. n will return only networks iv. o will return only organizations v. p will return only point-of-contacts b. Query by attribute. To narrow a search, a query can also include a flag as follows: i. ! will return the single match of the unique identifier for a record (Org ID for Organizations, handle for all other records) ii. @ will return the POC[s] with the specified domain- part in the email address iii. . will return the records that match the 'name' field on the record c. Query hierarchy. To display related records, a query can also include a flag as follows: i. < will return the record related up the hierarchy. For a network, display the supernet, or parent network in detailed format. ii. > will return the records related down the hierarchy. For a network, display the subdelegations or subnets, below the network in summary format. For an organization, display the resources registered to that organization in summary format. d. Display flags. To modify the way the query results display, include one of the following flags: i. + will display 'full' output for each match (This command cannot be used with the > flag) ii. - will display 'list', even if single match found IV. Additional features a. ? will display the help screen b. * will show a list of all matches starting with the given string. Note, the * can only be used at the end of a query. c. The maximum number of records output for each record type is limited to 256. From ginny at arin.net Mon Oct 21 16:26:08 2002 From: ginny at arin.net (ginny listman) Date: Mon, 21 Oct 2002 16:26:08 -0400 (EDT) Subject: [dbwg] problems getting orgID In-Reply-To: <62DA45D4963FA747BA1B253E266760F9043DFB97@OCCLUST04EVS1.ugd.att.com> Message-ID: Barbara, If I understand your question correctly, you are unable to determine the downstream Org ID within the confirmation because it only contains the network handle. In the pre-conversion days, ARIN included a WHOIS output on each confirmation, so that all newly created handles would be displayed. This feature was not implemented in the first release of the new software. Engineering has devoted resources to change this, and hope to release it by the end of this week. Ginny Listman Director of Engineering ARIN On Thu, 17 Oct 2002, Mandal, Barbara R, ALCNS wrote: > > We are having a lot of problems getting the orgID by automating whois through a firewall. Can't the orgID be included in the success response to Reassign-Detailed? > > Barbara Mandal > INSTAR Systems Engineering > (732) 420-2368 > From memsvcs at arin.net Mon Oct 28 18:24:00 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 28 Oct 2002 18:24:00 -0500 (EST) Subject: [dbwg] RE: Policy Proposal 2002-1 Message-ID: <200210282324.SAA08270@ops.arin.net> The following information is provided in support of the discussion that will take place this week during the Data Base Working Group session of the ARIN Public Policy Meeting. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) -------------------------------------- This is a summary of some DNS lameness testing run from our Chantilly network location. The main test reads in all of the /8 zones we have under in-addr.arpa and tests each NS RR to see if the name server mentioned is indeed authoritative for the reported zone. One complicating factor is that some name servers have multiple addresses, this is addressed in the testing software. Something to keep in mind about this. The tests can be improved to see if there are transient errors (some lameness is always there, some comes and goes day to day). Even so, a summary of the 6 runs has been performed and found that 36% of the zones delegated were lame (or unreachable) in all of the test runs. How to interpret the numbers and what to do with the numbers are both open questions. But for now, back to the test at hand. There are between 500-600 thousand NS records in the test. The first chart counts the number of NS records that fall into one of the "server health" categories. ("Server" being a name server listing in the DNS, i.e., an NS RR). "Good only" refers to one-address servers that reply favorably and refers to multiply-addressed servers that reply favorable from all of their addresses. "Bad only" means that unfavorable replies were returned, "Down only" means that no replies were received, and "Missing only" means that there were no address records available for the name server. The remaining categories apply to just multiply-addressed servers and shows how many have different results based on which IP address is tested. The value of these counts is that it shows how much per-RR work is needed to clean up the /8 files. The counting data is suspect though, as all testing is done with the DNS UDP (unreliable) protocol from one location. Counting by NS RR's: Date: 07/26/02 07/28/02 07/31/02 08/01/02 08/02/02 08/04/02 Good only: 301418 298909 299528 291934 291073 284762 Bad only: 195828 194508 193536 189221 189276 189265 Down only: 38345 41126 41256 36938 38493 43840 Missing only: 15495 15877 16803 15922 15828 16320 Good and Bad only: 2 2 1 1 1 1 Good and Down only: 167 146 120 271 379 748 Bad and Down only: 126 202 472 386 467 380 Good, Bad and Down only: 0 0 0 0 0 0 (Each of the runs used the then current versions of the zone files, which are generated twice a day. The accounts for some variations in the totals.) All well and good, but the true impact of lameness may lie in what happens when a zone cannot be reached, as opposed to having some difficulty getting there. In other words, as I traverse down the DNS tree, I might find a lame server but there is another server that isn't lame. In this instance, although there was an unnecessary lookup done, the lameness did not result in more load on the root (or upper) DNS servers nor led the resolver into a loop. The following counts are listed in separate tables because the counts are split into /16 and /24 zone delegations. Note that the "No IP address" value differs from the "Missing only" counts above because, e.g., the 2,783 non-addressable delegated zones in the first run used name servers that appeared in a total of 15,495 NS RR's across all of our zone files. This is not unusual. What is more significant is the number of "All broken" zones in the runs. This lists the number if zones that cannot be reached and are likely the ones that are causing an extra load on the root/upper servers. Counting zone by zone: ==> 2002-07-26-0400-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 2783 96 2687 No broken 111889 5878 106011 Some broken 29981 2168 27813 All broken 90381 1986 88395 ==> 2002-07-28-1600-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 2910 101 2809 No broken 109420 5353 104067 Some broken 32329 2678 29651 All broken 90306 2003 88303 ==> 2002-07-31-1600-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 3203 103 3100 No broken 109947 5664 104283 Some broken 31914 2396 29518 All broken 90620 1998 88622 ==> 2002-08-01-1600-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 3041 106 2935 No broken 108322 5436 102886 Some broken 28922 2434 26488 All broken 87385 2018 85367 ==> 2002-08-02-1600-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 3025 101 2924 No broken 108189 5226 102963 Some broken 28315 2588 25727 All broken 88416 2075 86341 ==> 2002-08-04-1600-run <== Count of zone by zone results: Category All /16's /24's -------------- ------ ------ ------ No IP address 3033 107 2926 No broken 101109 5295 95814 Some broken 35816 2591 33225 All broken 88112 2005 86107 BTW, the date designation and time refers to the generation of the zone files. The runs are made just after the new files are available to the testing machine. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis ARIN Research Engineer From joe.provo at rcn.com Thu Oct 31 12:44:44 2002 From: joe.provo at rcn.com (Joe Provo) Date: Thu, 31 Oct 2002 12:44:44 -0500 Subject: [dbwg] Portable/non-portable flags gone? In-Reply-To: ; from ginny@arin.net on Wed, Oct 02, 2002 at 02:50:39PM -0400 References: <20021002133650.A17698@noc.ultra.net> Message-ID: <20021031124444.A14657@noc.ultra.net> On Wed, Oct 02, 2002 at 02:50:39PM -0400, ginny listman wrote: > On Wed, 2 Oct 2002, Joe Provo wrote: > > > > Seems that in the change over to the new format, "non-portable" flags > > got dropped, munged or changed to non-displaying. Everything I check > > that 'should' have the modern equivalent of the old "ADDRESSES WITHIN > > THIS BLOCK ARE NON-PORTABLE" don't have anything in the only space > > I'd expect something ("Comment:"). Recent allocations do appear to > > properly be tagge; is ARIN going to true up with old data or do > > delegaees need to re-file portability status with ARIN? > > You have found a bug in the registration software. This bug has also been > reported by someone from Telus. We have corrected the bug and are working > on correcting any records for templates that were processed prior to the > fix. You should see the corrected record in tomorrow's WHOIS. "Tomorrow never comes". I presume ARIN has the old data somewhere and there actually is interest in correcting this problem? Seems it would be easier to translate the old data than deal with a flood of re-filed requests. Any timeframe? Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.486.7610 Network Deployment & Management, RCN