From william at elan.net Mon Aug 4 22:36:54 2003 From: william at elan.net (william at elan.net) Date: Mon, 4 Aug 2003 19:36:54 -0700 (PDT) Subject: [dbwg] Referral URL - can this be extended to APNIC, RIPE blocks? Message-ID: I have a suggestion that "Referral URL" be also added for APNIC and RIPE ip blocks referrals from ARIN database (especially blocks being transfered as part of early registration transfer project). I know ARIN has all referral urls start with "rwhois://..." but in this case I believe it should also make an exception and put "whois://whois.apnic.net:43" for apnic for example. If the above is not done, could you at the very least add typical "search at whois.apnic.net" in the comments and not just leave the ip block with no comments and with just "NetType: Early Registrations, Transferred to APNIC" And on the last - ARIN should have reported on this mailing list that it would be adding new "NetType" - some automated software actually have been programmed for "Direct Allocation", "Direct Assignment", "Reassigned", "Reallocated" as only possible nettypes (there is also "IANA Special Use" and "IANA Reserved"), but ARIN seems to be using it as just additional varchar comment field. Besides that, there is already exists special nettype for APNIC ip blocks ("Allocated to APNIC" ) and this was not used either and instead new ip block type was created. In fact - it would be good idea that arin listed all possible "NetType" values somewhere... -- William Leibzon william at elan.net From william at elan.net Tue Aug 19 04:36:39 2003 From: william at elan.net (william at elan.net) Date: Tue, 19 Aug 2003 01:36:39 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs Message-ID: I've noticed that since introduction of ReferralServer as atribute of the ORG, number of ASNs also return ReferralServer as part of the output, for example: ----------------------------------------------------------------------- [william at sokol william]$ whois 16631 at whois.arin.net [whois.arin.net] OrgName: Cogent Communications OrgID: COGC Address: 1015 31st Street, NW City: Washington StateProv: DC PostalCode: 20007 Country: US ReferralServer: rwhois://rwhois.cogentco.com:4321/ ASNumber: 16631 ASName: COGENT-ASN ASHandle: AS16631 Comment: RegDate: 2000-05-30 Updated: 2003-03-14 ---------------------------------------------------------------------- Now as you can guess not one of these rwhois servers actually returns something when asked about ASN (in fact I don't think there is even a schema defined for that, though it can be created and this can be treated similar to domain name). So the question is should this "ReferralServer" for ASNs be considered unfortunete side-effect and bug (i.e. should ARIN possibly modify whois no to display ReferralServer with ASN objects) or should it possibly be considered a "feature"? I'm thinking its not exactly a bad idea to allow ISPs to display information about its ASN and its routing policies (i.e. like route server entry but on the ISP side, rather then directly at radb), but I have reservations about if rwhois can be used for this (and we do have standard RPSL for such routing database and in fact several large ISPs do have their own routedb servers). What do others think should be done in regards to ReferralServer and ASN? -- William Leibzon Elan Networks william at elan.net From ddiller at cogentco.com Tue Aug 19 12:00:02 2003 From: ddiller at cogentco.com (Dave Diller) Date: Tue, 19 Aug 2003 12:00:02 -0400 Subject: [dbwg] ReferralServer and ASNs In-Reply-To: References: Message-ID: <3F424982.1040909@cogentco.com> william at elan.net wrote: > I've noticed that since introduction of ReferralServer as atribute of > the ORG, number of ASNs also return ReferralServer as part of the output, > for example: > > ----------------------------------------------------------------------- > [william at sokol william]$ whois 16631 at whois.arin.net No, we definitely don't have anything implementable for ASN info here, and you're right, I doubt the schema exists currently. ASNs aren't hierarchical like IP blocks so there would be no point to a referral type system. I suspect that, since the tag is attached to the ORG itself, that it displays as part of the 'standard dump' that whois returns when a query is run. IE ask for info on a bit of data and it pulls the ORG info followed by the specifics of the query. ReferralServer is simply included as part of the normal "return this when asked about something belonging to a particular ORG". Most likely *ANY* ORG with a ReferralServer will return it when the ASN is queried. > I'm thinking its not exactly a bad idea to allow ISPs to display information > about its ASN and its routing policies (i.e. like route server entry but > on the ISP side, rather then directly at radb), but I have reservations > about if rwhois can be used for this (and we do have standard RPSL for > such routing database and in fact several large ISPs do have their own > routedb servers). Even if some "routing policy" features were implemented in rwhois, I seriously doubt we'd ever use them. There are enough other implementations out there that are more or less complete that I don't see the need to try and incorporate it into RWHOIS. Neat idea, lot of work, and no real benefit since the functionality already exists in numerous places. > What do others think should be done in regards to ReferralServer and ASN? I don't know what's involved backend in filtering out which fields to send in response to a particular type of query (block vs ASN) but I'm not really bothered by it being there, personally. My ORG uses RWHOIS so that flag might as well show up as often as possible upon a query :-) -dd From william at elan.net Wed Aug 20 18:15:00 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:15:00 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:13:27 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:13:27 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:17:06 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:17:06 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:24:04 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:24:04 -0700 (PDT) Subject: [dbwg] Sorry about the repeat of posts Message-ID: Sorry about the repeat of posts. My directory was out of space and was not writing sent-mail, so I thought the email was never sent.. -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:17:06 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:17:06 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:13:27 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:13:27 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:15:00 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:15:00 -0700 (PDT) Subject: [dbwg] ReferralServer and ASNs In-Reply-To: <3F424982.1040909@cogentco.com> Message-ID: On Tue, 19 Aug 2003, Dave Diller wrote: > I suspect that, since the tag is attached to the ORG itself, that it displays > as part of the 'standard dump' that whois returns when a query is run. IE > ask for info on a bit of data and it pulls the ORG info followed by the > specifics of the query. ReferralServer is simply included as part of > the normal "return this when asked about something belonging to a > particular ORG". Most likely *ANY* ORG with a ReferralServer will > return it when the ASN is queried. That is exactly right, I'm sure it has to do with how ARIN implemented its whois server and as I said this was unexpected accurance. They can probably override it just for ASN output (in fact my own completewhois had similar problem as the code for asn lookups is exactly same as ip blocks and when it began to see this "referralserver" it naturally started doing rwhois lookups, so now I have to override this behavior and/or separate ASN lookup to its own code) This is a part of the problem of which I warned ARIN about (mostly in private emails) especially when I heard they decided to do it with ReferralServer being attribute of only ORG. The problem is that some ISPs may not necessarily want to use rwhois for each and every ip block as they may have difference policies for different parts of organization, (especially if they bought another company and have to integrate it) On the other hand its a lot better if rwhois server (and its name being common to number of nets) could be controlled from the same place for entire isp (or even more then one). The above situation means that when database is normalized a new table needs to be setup for referral server (and since we need way to control access, it would need to have poc contact, but if you look closer at the situation its just easier to actually make a special contact). ARIN has good enough database engineers to know about this all as well, the problem is that they considered that it would take longer to implement it that way and it would be more complex for them as well as for users then just adding field to ORG or NET tables (even if it means database is not normalized) and this leads to problems we have right now. So what happened is when ARIN actually did a conversion if at least one ip block under ORG had listed rwhois server - they used that for ORG, that leads to some blocks that do not have working rwhois server - and that is at the time when we want to setup new policy (see policy proposal 2003-5) to require working rwhois server for any isp that has it listed in whois. What would that do to those isps that did not want it done for particular ip block - there is no way for them to opt out of rwhois now just for one of their blocks (or opt-in and use rwhois just for one block as for example cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for any other blocks listed under PSI orgid)! There are several ways to deal with this database problem now, one is to add ReferralServer field as attribute to NET and decide what to do if both ORG and NET have them (this leads to even less "normalized" database as it would have repeating data), the other is to allow ISPs to move some of their IP blocks into separate ORGs and allow way to know which orgs are connected to which other ones i.e. parent ORG idea I proposed in one of my earlier posts to dbwg (BTW - this would also lead to repeating data and database is also not normalized; it really is that the only way to do it "right" is to have referral server attribute in its own table or POC with references to that from netblocks). I hope people at ARIN read this all and will tell us what they intend to do about the above referenced problem. > > I'm thinking its not exactly a bad idea to allow ISPs to display information > > about its ASN and its routing policies (i.e. like route server entry but > > on the ISP side, rather then directly at radb), but I have reservations > > about if rwhois can be used for this (and we do have standard RPSL for > > such routing database and in fact several large ISPs do have their own > > routedb servers). > > Even if some "routing policy" features were implemented in rwhois, I > seriously doubt we'd ever use them. There are enough other > implementations out there that are more or less complete that I don't > see the need to try and incorporate it into RWHOIS. Neat idea, lot of > work, and no real benefit since the functionality already exists in > numerous places. I don't think its a good idea to use RWHOIS to display ASN routing policies either (in my view rwhois is obsolute protocol anyway, but we still need to wait for CRISP to be formalized before we have any good alternative), luckily for us we do have standard RPSL for whois routing data view. So my question was more general, if its a good idea to allow ISPs to display which routing database server they use as part of the ASN display in ARIN whois. Right now we have situation that different ISPs use different routing servers to display their policies and routing info (some isps like CW and L3 run their own routing servers too). Some of these routing servers are mirrored, i.e. merit radb and arin routing server - but we can not really rely that routing databases would be mirrored forewer (arin and merit may have break in their relationship in the future - lets hope not, though...) nor all of them are as for example altdb is not. So in general I think having ReferralServer display as part of ASN is not bad - but this would be DIFFERENT referralserver then one the used for netblocks, it would not be rwhois, but instead would most likely be whois display to proper radb server isp uses. Of course, with current relationship between ASNs and ORGs this can not be easily implemented either, eventhough its pretty simple. So to summarize my proposal to deal with this particular problem (that referral server listed in ORG is being displayed when queried for ASN) is to add "ReferralServer" field to ASN table and have it blanked out (not NULL, but something else indicating "do not display this atribute" in whois) by default for all ASNs right now. But also inform everybody of existance of this atribute and those ISPs that want should be allowed to enter it (and this should not be restricated to rwhois, but can be regular whois pointing to proper routing database whois server). Similar way should be done netblocks - a ReferralServer attribute should be added there with possible values actual rwhois referral server or NULL (i.e. display whatever it is in the ORG - this would be default), or special "Blank" - i.e. do not display ReferralServer attribute from ORG when somebody does whois on this netblock (this is basicly opt-out). And above would mean ARIN can continue to use substantially the same code for Netblocks and ASNs and everything would also be more or less standard - but it does mean more work for ARIN to actually get things right this time and not hurry up and just do it quickly. P.S. Sorry all for long email. It happens with me... -- William Leibzon Elan Networks william at elan.net From william at elan.net Wed Aug 20 18:24:04 2003 From: william at elan.net (william at elan.net) Date: Wed, 20 Aug 2003 15:24:04 -0700 (PDT) Subject: [dbwg] Sorry about the repeat of posts Message-ID: Sorry about the repeat of posts. My directory was out of space and was not writing sent-mail, so I thought the email was never sent.. -- William Leibzon Elan Networks william at elan.net From william at elan.net Mon Aug 25 13:57:35 2003 From: william at elan.net (william at elan.net) Date: Mon, 25 Aug 2003 10:57:35 -0700 (PDT) Subject: [dbwg] Multiple same swips in whois output, another bug? Message-ID: When doing whois on 207.134.171.2, the query returned the most specific swip twice. Why is this? [IPv4 whois information on 207.134.171.2 ] [Query Origin: Main Whois Query ] [whois.arin.net] TELUS Communications Inc. TELUS-207-134-0-0 (NET-207-134-0-0-1) 207.134.0.0 - 207.134.255.255 Telus Quebec TELUS-QC-207-134-160-0 (NET-207-134-160-0-1) 207.134.160.0 - 207.134.175.255 Blue Rock Dove BRD-8-207-134-170-0 (NET-207-134-171-0-1) 207.134.171.0 - 207.134.171.127 Blue Rock Dove BRD-8-207-134-170-0 (NET-207-134-171-0-2) 207.134.171.0 - 207.134.171.127 From louie at equinix.com Mon Aug 25 17:05:07 2003 From: louie at equinix.com (Louis Lee) Date: Mon, 25 Aug 2003 14:05:07 -0700 Subject: [dbwg] Multiple same swips in whois output, another bug? In-Reply-To: References: Message-ID: <20030825210506.GA13984@nemo.corp.equinix.com> On Mon, Aug 25, 2003 at 10:57:35AM -0700, william at elan.net wrote: > When doing whois on 207.134.171.2, the query returned the > most specific swip twice. Why is this? > > [IPv4 whois information on 207.134.171.2 ] My guess is that since the two reallocations have the same information (even the same date) but different net handles, either that the reallocate form got processed twice, or that the sender mailed in the same form twice on the same day when he didn't get the auto-reply as quick as he expected. Louie ------------------------------------------------------- Louis Lee louie at equinix.com Staff Network Engineer company: 650/513-7000 Equinix, Inc. desk: 650/513-7162 http://www.equinix.com/ fax: 650/513-7903 From william at elan.net Mon Aug 25 14:29:57 2003 From: william at elan.net (william at elan.net) Date: Mon, 25 Aug 2003 11:29:57 -0700 (PDT) Subject: [dbwg] Multiple same swips in whois output, another bug? In-Reply-To: <20030825210506.GA13984@nemo.corp.equinix.com> Message-ID: > On Mon, Aug 25, 2003 at 10:57:35AM -0700, william at elan.net wrote: > > When doing whois on 207.134.171.2, the query returned the > > most specific swip twice. Why is this? > > > > [IPv4 whois information on 207.134.171.2 ] > > My guess is that since the two reallocations have the same > information (even the same date) but different net handles, > either that the reallocate form got processed twice, or that > the sender mailed in the same form twice on the same day > when he didn't get the auto-reply as quick as he expected. Shouldn't it have been impossible to do exactly the same swip? It was my understand that ARIN returns an error when you try. It pretty clear to me that ARIN should not allow swip if another one for the same network is already there ("netrange" is the same) and if existing swip has same orgid as new swip. If arin are not doing this already, it should be fairly simple additional filter to implement... -- William Leibzon Elan Networks william at elan.net From louie at equinix.com Mon Aug 25 18:23:15 2003 From: louie at equinix.com (Louis Lee) Date: Mon, 25 Aug 2003 15:23:15 -0700 Subject: [dbwg] Multiple same swips in whois output, another bug? In-Reply-To: References: <20030825210506.GA13984@nemo.corp.equinix.com> Message-ID: <20030825222315.GA14383@nemo.corp.equinix.com> On Mon, Aug 25, 2003 at 11:29:57AM -0700, william at elan.net wrote: > > Shouldn't it have been impossible to do exactly the same > swip? It was my understand that ARIN returns an error when > you try. > > It pretty clear to me that ARIN should not allow swip > if another one for the same network is already there > ("netrange" is the same) and if existing swip has same > orgid as new swip. If arin are not doing this already, it > should be fairly simple additional filter to implement... 1. I think it is a rare enough occurance that ARIN should not be spinning cycles to develop and test the filter. 2. I would guess that ARIN already disallows multiple *reassignments* for overlapping networks of the same and different sizes. (We have an example of reallocations in this case.) Someone on the ARIN staff can confirm that. 3. I know of at least one valid reason where an organization would reassign themselves the same block that was reallocated to them. (Goes back to the flexibility concern that keeps coming up for a different topic.) 4. There might actually be a reason (however poor it may be) for someone to reallocate to themselves the same network more than once under the same org ID. I can't think of a really good reason, but I can think of at least one poor one. Louie ------------------------------------------------------- Louis Lee louie at equinix.com Staff Network Engineer company: 650/513-7000 Equinix, Inc. desk: 650/513-7162 http://www.equinix.com/ fax: 650/513-7903 From ginny at arin.net Tue Aug 26 13:41:11 2003 From: ginny at arin.net (Ginny Listman) Date: Tue, 26 Aug 2003 13:41:11 -0400 (EDT) Subject: [dbwg] Multiple same swips in whois output, another bug? In-Reply-To: <20030825222315.GA14383@nemo.corp.equinix.com> Message-ID: On Mon, 25 Aug 2003, Louis Lee wrote: > On Mon, Aug 25, 2003 at 11:29:57AM -0700, william at elan.net wrote: > > > > Shouldn't it have been impossible to do exactly the same > > swip? It was my understand that ARIN returns an error when > > you try. As Louie points out below, for reallocations the answer is no. ARIN has always permitted the reallocation of a full netblock. The software would have errored out if they had both been reassignments. > > > > It pretty clear to me that ARIN should not allow swip > > if another one for the same network is already there > > ("netrange" is the same) and if existing swip has same > > orgid as new swip. If arin are not doing this already, it > > should be fairly simple additional filter to implement... > > 1. I think it is a rare enough occurance that ARIN should > not be spinning cycles to develop and test the filter. > It is a rare occurance, but would not be too difficult to implement. However, it should be noted that this behavior existed in the old software, not something that is a result of the new software release last year. > 2. I would guess that ARIN already disallows multiple > *reassignments* for overlapping networks of the same > and different sizes. (We have an example of reallocations > in this case.) Someone on the ARIN staff can confirm > that. > That is correct. Ginny Listman Director of Engineering ARIN From william at elan.net Wed Aug 27 04:35:42 2003 From: william at elan.net (william at elan.net) Date: Wed, 27 Aug 2003 01:35:42 -0700 (PDT) Subject: [dbwg] Multiple same swips in whois output, another bug? In-Reply-To: Message-ID: On Tue, 26 Aug 2003, Ginny Listman wrote: > > > Shouldn't it have been impossible to do exactly the same > > > swip? It was my understand that ARIN returns an error when > > > you try. > > As Louie points out below, for reallocations the answer is no. ARIN has > always permitted the reallocation of a full netblock. The software would > have errored out if they had both been reassignments. I did not originally notice this distinction... > It is a rare occurance, but would not be too difficult to implement. > However, it should be noted that this behavior existed in the old > software, not something that is a result of the new software release last > year. While there maybe legitimate cases for somebody to reallocate entire block to different organization, I really do not see any reason why the organization would reallocate its own ip block to itself (if they want to show its being used internally, this should be done as reassignment). So if its not too difficult to implement to return error if organization is trying to reallocate its own ip block to itself, then go ahead an do it. If you're unsure on what majority want, take this issue to next meeting and do quick poll there. -- William Leibzon Elan Networks william at elan.net