From ginny at arin.net Wed Jan 3 11:09:57 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 11:09:57 -0500 (EST) Subject: SWIP netblocks Message-ID: In reviewing what is currently stored in the database, there are a number of SWIPed netblocks that are not on the bit boundary. For example, instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the future, we will be operating in a cidr world, including displaying cidr blocks in whois. For a block that is 1 to 254, the display will include 2 /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole lot cleaner to display 1 /24. How do people feel about enforcing allocations/assignments based on a single cidr block? I could see an occasion where someone may want to assign 2-4 cidr blocks at a single time, but can we enforce, or strongly encouraging, a policy like this? SWIP on the bit boundary. Ginny From huberman at gblx.net Wed Jan 3 11:50:09 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 3 Jan 2001 09:50:09 -0700 (MST) Subject: SWIP netblocks In-Reply-To: Message-ID: > How do people feel about enforcing allocations/assignments based on a > single cidr block? I could see an occasion where someone may want to > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > encouraging, a policy like this? SWIP on the bit boundary. Though we can certainly find a considerable number of older SWIPed blocks which are not on CIDR boundaries, have you found evidence that a statistically significant number of blocks SWIPed in the last two-three years are off the bit boundaries? /david From linda at sat-tel.com Wed Jan 3 11:56:47 2001 From: linda at sat-tel.com (Linda) Date: Wed, 03 Jan 2001 11:56:47 -0500 Subject: SWIP netblocks References: Message-ID: <3A5359CE.BD1B712D@sat-tel.com> Satellite Communications (NETBLK-UU-63-65-12) UU-63-65-12 63.65.12.0 - 63.65.12.255 Cotas LTDA. (NETBLK-SCSI-COTAS-2) SCSI-COTAS-2 63.65.12.0 - 63.65.12.254 We have one /24 that was allocated by UUNET to SCSI, who allocated it to COTAS. Our swip template was submitted with .0 to .255, and COTAS's was also submitted with a .0 to .255. I called the ARIN help desk regarding this matter and I was told that the only way to correctly show the parent child relationship was if the child was listed in the database as .254. The database was changed by ARIN because after we allocated the /24 to COTAS the db initially listed the order as UUNET to COTAS to SCSI. Linda ginny listman wrote: > In reviewing what is currently stored in the database, there are a number > of SWIPed netblocks that are not on the bit boundary. For example, > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > future, we will be operating in a cidr world, including displaying cidr > blocks in whois. For a block that is 1 to 254, the display will include 2 > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > lot cleaner to display 1 /24. > > How do people feel about enforcing allocations/assignments based on a > single cidr block? I could see an occasion where someone may want to > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > encouraging, a policy like this? SWIP on the bit boundary. > > Ginny From ginny at arin.net Wed Jan 3 12:10:51 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 12:10:51 -0500 (EST) Subject: SWIP netblocks In-Reply-To: Message-ID: Although there is not a tremendous amount, the fact is that there are still some people who SWIP off the bit boundaries. Whether this is due to a lack of cidr knowledge, or some Network Admin using an old book as a tool for networking, or that they truely know about cidr, but choose to ignore it, I can't say. If cidr is strongly encouraged, it may require some education by ARIN. Ginny On Wed, 3 Jan 2001, David R Huberman wrote: > > How do people feel about enforcing allocations/assignments based on a > > single cidr block? I could see an occasion where someone may want to > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > > encouraging, a policy like this? SWIP on the bit boundary. > > Though we can certainly find a considerable number of older SWIPed blocks > which are not on CIDR boundaries, have you found evidence that a > statistically significant number of blocks SWIPed in the last two-three > years are off the bit boundaries? > > /david > From ginny at arin.net Wed Jan 3 12:16:09 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 12:16:09 -0500 (EST) Subject: SWIP netblocks In-Reply-To: Message-ID: You are correct in your belief that not everyone understands CIDR. If it requires ARIN to do some education, then that is what we would like to do. Yes, there may be more SWIP rejections, but that shouldn't prevent us from doing what should be done. As far as old blocks, we would not change what is currently in the database without permission from the POC. I would be wrong of us to assume that the lack of CIDR bit boundary is due to a lack of knowledge. It may be necessary for ARIN to address each SWIPed netblock that is in question. Ginny On Wed, 3 Jan 2001, Tanya Hinman wrote: > It sounds like a good idea to enforce SWIP on the bit boundary, but I > believe many times SWIPs that are not on the bit boundary are completed by > individuals that do not completely understand CIDR. This may cause more SWIP > rejections for ARIN. Also, how will this affect the old blocks that are > SWIPped incorrectly? Will ARIN require that they all be reswipped or will > the old blocks be left as is? > > Tanya > > -----Original Message----- > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of > ginny listman > Sent: Wednesday, January 03, 2001 11:10 AM > To: dbwg at arin.net > Subject: SWIP netblocks > > > In reviewing what is currently stored in the database, there are a number > of SWIPed netblocks that are not on the bit boundary. For example, > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > future, we will be operating in a cidr world, including displaying cidr > blocks in whois. For a block that is 1 to 254, the display will include 2 > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > lot cleaner to display 1 /24. > > How do people feel about enforcing allocations/assignments based on a > single cidr block? I could see an occasion where someone may want to > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > encouraging, a policy like this? SWIP on the bit boundary. > > Ginny > From Mike.Gogulski at dsl.net Wed Jan 3 12:17:00 2001 From: Mike.Gogulski at dsl.net (Gogulski, Mike) Date: Wed, 3 Jan 2001 09:17:00 -0800 Subject: SWIP netblocks Message-ID: <1357BE464D4BD41193CD00508BDCB49C209A5D@scca06.tycho.net> Ginny, I'd say "no", and provide one example to support my position. Many ISPs are deploying DSL services using bridged networking models. Typically, the ISP allocates a large block (/24 or so) at a time to an integrated routing and bridging interface, and then assigns customer addresses from this block one at a time as customers come online. If a customer requires more than one IP address, these can be assigned, and they do not have to be assigned on CIDR boundaries at all. If the assignment is larger than a /29, ARIN policy requires that the reassignment be documented via SWIP or RWhois. Implementing this policy would force an ISP who needed to assign a customer (for example) 9 IP addresses for a bridged DSL service 16 addresses instead, a net waste of 7 addresses. This would be in conflict with one of ARIN's other stated policy goals, namely the conservation of IPv4 address space. Peace, Mike Gogulski Chief Engineer DSL.net, Inc. -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Wednesday, January 03, 2001 11:10 AM To: dbwg at arin.net Subject: SWIP netblocks In reviewing what is currently stored in the database, there are a number of SWIPed netblocks that are not on the bit boundary. For example, instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the future, we will be operating in a cidr world, including displaying cidr blocks in whois. For a block that is 1 to 254, the display will include 2 /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole lot cleaner to display 1 /24. How do people feel about enforcing allocations/assignments based on a single cidr block? I could see an occasion where someone may want to assign 2-4 cidr blocks at a single time, but can we enforce, or strongly encouraging, a policy like this? SWIP on the bit boundary. Ginny From alexk at tugger.net Wed Jan 3 12:23:07 2001 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 3 Jan 2001 12:23:07 -0500 (EST) Subject: SWIP netblocks In-Reply-To: Message-ID: This may sound a little extreme, but if you don't understand CIDR boundaries, than you should not be in the business of assigning address space. However, as you point out, there may be instances where you cannot swip along the boundary. Is the last line in your message suggesting that ARIN will examine each non-CIDR boundary SWIP that comes in, or will it reject them all unless the SWIPer can justify why they need to swip along non-CIDR boundaries? On Wed, 3 Jan 2001, ginny listman wrote: > You are correct in your belief that not everyone understands CIDR. If it > requires ARIN to do some education, then that is what we would like to do. > Yes, there may be more SWIP rejections, but that shouldn't prevent us > from doing what should be done. As far as old blocks, we would not change > what is currently in the database without permission from the POC. I > would be wrong of us to assume that the lack of CIDR bit boundary is due > to a lack of knowledge. It may be necessary for ARIN to address each > SWIPed netblock that is in question. > > Ginny > > On Wed, 3 Jan 2001, Tanya Hinman wrote: > > > It sounds like a good idea to enforce SWIP on the bit boundary, but I > > believe many times SWIPs that are not on the bit boundary are completed by > > individuals that do not completely understand CIDR. This may cause more SWIP > > rejections for ARIN. Also, how will this affect the old blocks that are > > SWIPped incorrectly? Will ARIN require that they all be reswipped or will > > the old blocks be left as is? > > > > Tanya > > > > -----Original Message----- > > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of > > ginny listman > > Sent: Wednesday, January 03, 2001 11:10 AM > > To: dbwg at arin.net > > Subject: SWIP netblocks > > > > > > In reviewing what is currently stored in the database, there are a number > > of SWIPed netblocks that are not on the bit boundary. For example, > > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > > future, we will be operating in a cidr world, including displaying cidr > > blocks in whois. For a block that is 1 to 254, the display will include 2 > > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > > lot cleaner to display 1 /24. > > > > How do people feel about enforcing allocations/assignments based on a > > single cidr block? I could see an occasion where someone may want to > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > > encouraging, a policy like this? SWIP on the bit boundary. > > > > Ginny > > > -- Alex Kamantauskas alexk at tugger.net From alexk at tugger.net Wed Jan 3 12:40:00 2001 From: alexk at tugger.net (Alex Kamantauskas) Date: Wed, 3 Jan 2001 12:40:00 -0500 (EST) Subject: SWIP netblocks In-Reply-To: Message-ID: I hear ya.. Do we have a working idea on the process to educate end users? On Wed, 3 Jan 2001, Tanya Hinman wrote: > Alex, > > Although we understand CIDR, there are customers who do not. Regardless of > what we think they should know, they don't always know and education by ARIN > and other ISP's will be necessary. > > Tanya > -- Alex Kamantauskas alexk at tugger.net From ginny at arin.net Wed Jan 3 12:44:37 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 12:44:37 -0500 (EST) Subject: SWIP netblocks In-Reply-To: <3A5359CE.BD1B712D@sat-tel.com> Message-ID: In the future, child/parent relationship will be tracked by a separate table, not by the size of the network. Therefore once we convert the database, you may (we will) change COTAS to 255. My question to you, and the others, is how frequently do you allocate the entire netblock? Why wouldn't COTA go directly to UUNET, if the are getting the same size of allocation that SCSI is getting? Is this based on previous relationships and/or possible language? Ginny On Wed, 3 Jan 2001, Linda wrote: > Satellite Communications (NETBLK-UU-63-65-12) UU-63-65-12 > 63.65.12.0 - > 63.65.12.255 > Cotas LTDA. (NETBLK-SCSI-COTAS-2) SCSI-COTAS-2 63.65.12.0 - > 63.65.12.254 > > We have one /24 that was allocated by UUNET to SCSI, who allocated it to > COTAS. Our swip template was submitted with .0 to .255, and COTAS's was also > submitted with a .0 to .255. I called the ARIN help desk regarding this > matter and I was told that the only way to correctly show the parent child > relationship was if the child was listed in the database as .254. The > database was changed by ARIN because after we allocated the /24 to COTAS the > db initially listed the order as UUNET to COTAS to SCSI. > > Linda > > ginny listman wrote: > > > In reviewing what is currently stored in the database, there are a number > > of SWIPed netblocks that are not on the bit boundary. For example, > > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > > future, we will be operating in a cidr world, including displaying cidr > > blocks in whois. For a block that is 1 to 254, the display will include 2 > > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > > lot cleaner to display 1 /24. > > > > How do people feel about enforcing allocations/assignments based on a > > single cidr block? I could see an occasion where someone may want to > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > > encouraging, a policy like this? SWIP on the bit boundary. > > > > Ginny > From ginny at arin.net Wed Jan 3 12:56:07 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 12:56:07 -0500 (EST) Subject: SWIP netblocks In-Reply-To: <1357BE464D4BD41193CD00508BDCB49C209A5D@scca06.tycho.net> Message-ID: Mike, If you were allocating 9 ip addresses, my recommendation would be to allocate the smallest amount of cidr blocks, ie 1 /29 plus 1 /32. This would be far better that starting with .1 and winding up with 1 /32, 2 /31 and 1 /30. I just want to limit the total number of cidr blocks per SWIP. Although assigning 254 addresses, .1 through .254, conserves 2 addresses, I'd rather save the room on a routing table and sacrifice the 2 addresses and not allocate 16 cidr blocks. Ginny On Wed, 3 Jan 2001, Gogulski, Mike wrote: > Ginny, > > I'd say "no", and provide one example to support my position. > > Many ISPs are deploying DSL services using bridged networking models. > Typically, the ISP allocates a large block (/24 or so) at a time to an > integrated routing and bridging interface, and then assigns customer > addresses from this block one at a time as customers come online. If a > customer requires more than one IP address, these can be assigned, and they > do not have to be assigned on CIDR boundaries at all. > > If the assignment is larger than a /29, ARIN policy requires that the > reassignment be documented via SWIP or RWhois. Implementing this policy > would force an ISP who needed to assign a customer (for example) 9 IP > addresses for a bridged DSL service 16 addresses instead, a net waste of 7 > addresses. This would be in conflict with one of ARIN's other stated policy > goals, namely the conservation of IPv4 address space. > > Peace, > Mike Gogulski > Chief Engineer > DSL.net, Inc. > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Wednesday, January 03, 2001 11:10 AM > To: dbwg at arin.net > Subject: SWIP netblocks > > > In reviewing what is currently stored in the database, there are a number > of SWIPed netblocks that are not on the bit boundary. For example, > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > future, we will be operating in a cidr world, including displaying cidr > blocks in whois. For a block that is 1 to 254, the display will include 2 > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > lot cleaner to display 1 /24. > > How do people feel about enforcing allocations/assignments based on a > single cidr block? I could see an occasion where someone may want to > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > encouraging, a policy like this? SWIP on the bit boundary. > > Ginny > From ginny at arin.net Wed Jan 3 12:57:57 2001 From: ginny at arin.net (ginny listman) Date: Wed, 3 Jan 2001 12:57:57 -0500 (EST) Subject: SWIP netblocks In-Reply-To: Message-ID: How about the suggestion of limiting a SWIP to no more than 4 cidr blocks? This should eliminate possible errors, but still leave you with enough flexibility to not have to assign a single cidr block. Ginny On Wed, 3 Jan 2001, Alex Kamantauskas wrote: > > This may sound a little extreme, but if you don't understand CIDR > boundaries, than you should not be in the business of assigning address > space. However, as you point out, there may be instances where you > cannot swip along the boundary. > > Is the last line in your message suggesting that ARIN will examine each > non-CIDR boundary SWIP that comes in, or will it reject them all unless > the SWIPer can justify why they need to swip along non-CIDR boundaries? > > On Wed, 3 Jan 2001, ginny listman wrote: > > > You are correct in your belief that not everyone understands CIDR. If it > > requires ARIN to do some education, then that is what we would like to do. > > Yes, there may be more SWIP rejections, but that shouldn't prevent us > > from doing what should be done. As far as old blocks, we would not change > > what is currently in the database without permission from the POC. I > > would be wrong of us to assume that the lack of CIDR bit boundary is due > > to a lack of knowledge. It may be necessary for ARIN to address each > > SWIPed netblock that is in question. > > > > Ginny > > > > On Wed, 3 Jan 2001, Tanya Hinman wrote: > > > > > It sounds like a good idea to enforce SWIP on the bit boundary, but I > > > believe many times SWIPs that are not on the bit boundary are completed by > > > individuals that do not completely understand CIDR. This may cause more SWIP > > > rejections for ARIN. Also, how will this affect the old blocks that are > > > SWIPped incorrectly? Will ARIN require that they all be reswipped or will > > > the old blocks be left as is? > > > > > > Tanya > > > > > > -----Original Message----- > > > From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of > > > ginny listman > > > Sent: Wednesday, January 03, 2001 11:10 AM > > > To: dbwg at arin.net > > > Subject: SWIP netblocks > > > > > > > > > In reviewing what is currently stored in the database, there are a number > > > of SWIPed netblocks that are not on the bit boundary. For example, > > > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > > > future, we will be operating in a cidr world, including displaying cidr > > > blocks in whois. For a block that is 1 to 254, the display will include 2 > > > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > > > lot cleaner to display 1 /24. > > > > > > How do people feel about enforcing allocations/assignments based on a > > > single cidr block? I could see an occasion where someone may want to > > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > > > encouraging, a policy like this? SWIP on the bit boundary. > > > > > > Ginny > > > > > > > -- > Alex Kamantauskas > alexk at tugger.net > From linda at sat-tel.com Wed Jan 3 13:59:22 2001 From: linda at sat-tel.com (Linda) Date: Wed, 03 Jan 2001 13:59:22 -0500 Subject: SWIP netblocks References: Message-ID: <3A53768A.38307D70@sat-tel.com> Yes it is based on a previous relationships as well as language. I was merely replying to your statement that many blocks were not swip(ed) on the bit boundary and in this case it was ARIN not SCSI that stored .254 in the db. I was not sure if this was an exception to the rule or if ARIN has done this on other swip information? In the future as you stated below this will not be an issue. Linda ginny listman wrote: > In the future, child/parent relationship will be tracked by a separate > table, not by the size of the network. Therefore once we convert the > database, you may (we will) change COTAS to 255. My question to you, and > the others, is how frequently do you allocate the entire netblock? Why > wouldn't COTA go directly to UUNET, if the are getting the same size of > allocation that SCSI is getting? Is this based on previous relationships > and/or possible language? > > Ginny > > On Wed, 3 Jan 2001, Linda wrote: > > > Satellite Communications (NETBLK-UU-63-65-12) UU-63-65-12 > > 63.65.12.0 - > > 63.65.12.255 > > Cotas LTDA. (NETBLK-SCSI-COTAS-2) SCSI-COTAS-2 63.65.12.0 - > > 63.65.12.254 > > > > We have one /24 that was allocated by UUNET to SCSI, who allocated it to > > COTAS. Our swip template was submitted with .0 to .255, and COTAS's was also > > submitted with a .0 to .255. I called the ARIN help desk regarding this > > matter and I was told that the only way to correctly show the parent child > > relationship was if the child was listed in the database as .254. The > > database was changed by ARIN because after we allocated the /24 to COTAS the > > db initially listed the order as UUNET to COTAS to SCSI. > > > > Linda > > > > ginny listman wrote: > > > > > In reviewing what is currently stored in the database, there are a number > > > of SWIPed netblocks that are not on the bit boundary. For example, > > > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > > > future, we will be operating in a cidr world, including displaying cidr > > > blocks in whois. For a block that is 1 to 254, the display will include 2 > > > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > > > lot cleaner to display 1 /24. > > > > > > How do people feel about enforcing allocations/assignments based on a > > > single cidr block? I could see an occasion where someone may want to > > > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > > > encouraging, a policy like this? SWIP on the bit boundary. > > > > > > Ginny > > From danny at ambernetworks.com Wed Jan 3 15:59:56 2001 From: danny at ambernetworks.com (Danny McPherson) Date: Wed, 03 Jan 2001 13:59:56 -0700 Subject: SWIP netblocks Message-ID: <200101032059.NAA10353@tcb.net> I agree with Mike. There are lots of ways that IP addresses can be allocated with non-contiguous masks. For example, allocation mechanisms such as those defined in ftp://ftp.ietf.org/internet-drafts/draft-mcpherson-vlan-ipagg-01.txt, which could similarly be employed in DSL, cable, or lots of other environments. -danny > Ginny, > > I'd say "no", and provide one example to support my position. > > Many ISPs are deploying DSL services using bridged networking models. > Typically, the ISP allocates a large block (/24 or so) at a time to an > integrated routing and bridging interface, and then assigns customer > addresses from this block one at a time as customers come online. If a > customer requires more than one IP address, these can be assigned, and they > do not have to be assigned on CIDR boundaries at all. > > If the assignment is larger than a /29, ARIN policy requires that the > reassignment be documented via SWIP or RWhois. Implementing this policy > would force an ISP who needed to assign a customer (for example) 9 IP > addresses for a bridged DSL service 16 addresses instead, a net waste of 7 > addresses. This would be in conflict with one of ARIN's other stated policy > goals, namely the conservation of IPv4 address space. > > Peace, > Mike Gogulski > Chief Engineer > DSL.net, Inc. > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Wednesday, January 03, 2001 11:10 AM > To: dbwg at arin.net > Subject: SWIP netblocks > > > In reviewing what is currently stored in the database, there are a number > of SWIPed netblocks that are not on the bit boundary. For example, > instead of SWIPing 0 to 255, an entire /24, 1 to 254 was SWIPed. In the > future, we will be operating in a cidr world, including displaying cidr > blocks in whois. For a block that is 1 to 254, the display will include 2 > /32, 2 /31, 2 /30, 2 /29, 2 /28, 2 /27, and 2 /26. It would be a whole > lot cleaner to display 1 /24. > > How do people feel about enforcing allocations/assignments based on a > single cidr block? I could see an occasion where someone may want to > assign 2-4 cidr blocks at a single time, but can we enforce, or strongly > encouraging, a policy like this? SWIP on the bit boundary. > > Ginny From smarcus at genuity.com Wed Jan 3 19:10:12 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Wed, 03 Jan 2001 19:10:12 -0500 Subject: phone types] In-Reply-To: <000401c070ef$baffe100$847fd840@a> References: <3A4B6EC8.4ECC39BD@sat-tel.com> Message-ID: <3.0.5.32.20010103191012.00a5d100@pobox3.genuity.com> At 11:00 12/28/2000 -0600, Bruce wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I agree It should be the responsibility of the person submitting the >contact information to include either the 1 or 011 contact number. >ARIN should not have to >take time to figure out if the number lies within the NANP or if the >number is an international number... I guess I'm confused by this... 011 is a convention commonly used when dialing out FROM the U.S. or Canada; it's not relevant elsewhere. Thus, when you dial the U.S. from, say, England, you use a country code of 1, typically preceded by 00. Not 011. Dialing France from the U.K. might entail dialing 00 to signal a connection outside of the U.K., followed by the 33 country code for France. Country codes in Europe also have the bizarre tendency to vary (SLIGHTLY) based on the country from which you are calling. That is, the country code for France _might_ be different when calling France from Germany than it is when calling France from, say, Poland (no, I did not check this particular one). Does not happen much, as I recall, but it does happen. A quick conversation with your counterparts at RIPE or APNIC might be a wise investment of time -- they most likely have already dealt with all of these issues. My two francs, - Scott From woeber at cc.univie.ac.at Thu Jan 4 05:25:05 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 04 Jan 2001 11:25:05 +0100 Subject: phone types] Message-ID: <009F59C9.734ED10E.23@cc.univie.ac.at> >Country codes in Europe also have the bizarre tendency to vary (SLIGHTLY) >based on the country from which you are calling. Not really, but... > That is, the country code >for France _might_ be different when calling France from Germany than it is >when calling France from, say, Poland (no, I did not check this particular >one). some PSTN operators offered "shortcuts" to dial into neighbouor countries' nets, i.e. the full string to dial into DE (+49) from AT (+43) is 00 49 ...., the shortcut was 05 (or was it 06?), but those have mostly been phased out. >Does not happen much, as I recall, but it does happen. what does happen, though, is changes within the countries' handling or regional codes. Some do not allow the regional code indication digit (most of the time this 0 or 9), others ignore it, and others require it (e.g. Spain) >A quick conversation with your counterparts at RIPE or APNIC might be a >wise investment of time -- they most likely have already dealt with all of >these issues. That is the reason why we try to motivate people to use the canonical form of +countryregional-codesubscriber-numberextension +99 1234 11223344 9999 An example for AT: +43 1 4277 14033 (POTS, Vienna) or +43 664 1234567 (mobile) An example for ES: +34 93 1234567 (POTS, Barcelona) >My two francs, >- Scott Btw, I've asked the RIPE NCC DB Group's manager to get in touch with ARIN staff, to try to align the formats as much as possible. Cheers, (my 2 Euro cents) Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From andrei at ripe.net Thu Jan 4 05:32:27 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 04 Jan 2001 11:32:27 +0100 Subject: phone types References: Message-ID: <3A54513B.E3BC18FA@ripe.net> Hello Ginny, ginny listman wrote: > > On Wed, 27 Dec 2000, Wilfried Woeber, UniVie/ACOnet wrote: > > > >I'm looking to clean-up the database, and one thing I would like to > > >enforce is that phone numbers consist of the following: 01234567890+-() > > > > That is probably a good idea. Whatever it is, the characterset should be > > uniform across the IP (and routing) registries! > > Are there any other characters we should include that would take into > consideration non-US, non-CA phone numbers? > > > > > >In the future, if you fill out the phone line with something like: > > >1-543.433.8765 (this is my pager) > > >what gets store in the database, and displayed in whois: > > >(543) 433-8765 > > > > This does not sound like a good idea to me. > > Throwing info away and/or re-writing user-supplied info can get you into > > trouble - unless you know *very* well what you are doing (e.g. by > > looking at very well-defined semantics). > > > > As I look at what is currently stored in the phone fields of the current > database, making the above assumption/conversion seems reasonable. A > phone number should be a phone number, and not have other info stored with > it. It is my intention to define this semantics in our registration > software - both web based and internal tools. Do you have a problem with > the format? With or without ()? If there is another format that is more > socially accepted, let me know. This format is not a definite, just an > idea. > In the RIPE Database the following syntax is accepted for phone numbers: + followed by numbers separated by the whitespace, "-" or ".". "()" are also accepted. The number may be followed by the keyword "ext." and another number (for extension). The database software does not change the phone field in the submission and just reports syntax error if the number does not comply to the above rule. Preserving data in user's submission proved to be a good idea. The RIPE community uses this syntax for several years. > > > >Ginny > > > > Wilfried. > > Regards, Andrei -- Andrei Robachevsky DB Group Manager RIPE NCC From shane at time-travellers.org Thu Jan 4 06:57:47 2001 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 4 Jan 2001 12:57:47 +0100 Subject: DB schema Message-ID: <20010104125747.B18244@mars.lab.time-travellers.org> All, I've had a quick look over the proposed DB schema, and have the following comments/suggestions/questions: o Please please please don't use HANDLE to represent the key for the objects. You should really think about using an internal identifier as the key. You can/should still make HANDLE a unique field, but users use this to encode information (company name, network city location, whatever), and as such want to change it. This process is much simplier with a distinct, internal-only, key. o Why isn't address stored in a seperate table like phone, mailbox, and so on? o Can an organization or network have multiple parents? If not, perhaps it might make more sense to include a "parent" attribute in the tables rather than use a seperate link table. o You'll need to add an "ordering" attribute to the tables, to allow for stable sorting on the output. For example, inaddr servers should appear in the order the user specifies, and contacts should probably also work this way. o Why use start and number of AS rather than start-end for AS numbers? o What's a "resource link"? o What's a maintainer? Please just kill this beast, or at least define it in a meaningful way. :( o What are you going to do about the gazillion non-CIDR networks that exist today? There are a lot of networks in the ARIN database that are (for example) a /24 and the subsequent /25. I suggest that you should store networks as start-end in the database, even if you remove this from the templates and/or web forms. On output, you can convert to between 1 to 31 CIDR networks, but it's probably simplier to just store start-end ranges when storing the addresses. o Am I the only one who hates templates? ;) Shane From smarcus at genuity.com Thu Jan 4 09:27:40 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Thu, 04 Jan 2001 09:27:40 -0500 Subject: phone types] In-Reply-To: <009F59C9.734ED10E.23@cc.univie.ac.at> Message-ID: <3.0.5.32.20010104092740.00890900@pobox3.genuity.com> At 11:25 01/04/2001 +0100, Wilfried Woeber, UniVie/ACOnet wrote: > ... > That is the reason why we try to motivate people to use the canonical > form of > > +countryregional-codesubscriber-numberextension > +99 1234 11223344 9999 > > An example for AT: +43 1 4277 14033 (POTS, Vienna) or > +43 664 1234567 (mobile) > An example for ES: +34 93 1234567 (POTS, Barcelona) Looks good. And under this system, am I correct in thinking that my U.S. number would be encoded as: +1 781 2623075 ? Thanks, - Scott ----------- J. Scott Marcus Phone: +1 781.262.3075 Chief Technology Officer (CTO) FAX: +1 781.262.4882 Genuity Inc. 3 Van de Graaff Drive, P.O. Box 3073, room 25/2046A Burlington, MA 01803 E-mail: smarcus at genuity.com U.S.A. WWW: http://www.genuity.com/index.htm "There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things." -- Niccolo Machiavelli (The Prince, 1513) From shane at time-travellers.org Thu Jan 4 10:48:30 2001 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 4 Jan 2001 16:48:30 +0100 Subject: phone types] In-Reply-To: <3.0.5.32.20010104092740.00890900@pobox3.genuity.com>; from smarcus@genuity.com on Thu, Jan 04, 2001 at 09:27:40AM -0500 References: <009F59C9.734ED10E.23@cc.univie.ac.at> <3.0.5.32.20010104092740.00890900@pobox3.genuity.com> Message-ID: <20010104164830.A19828@mars.lab.time-travellers.org> On Thu, Jan 04, 2001 at 09:27:40AM -0500, J. Scott Marcus wrote: > At 11:25 01/04/2001 +0100, Wilfried Woeber, UniVie/ACOnet wrote: > > > ... > > That is the reason why we try to motivate people to use the canonical > > form of > > > > +countryregional-codesubscriber-numberextension > > +99 1234 11223344 9999 > > > > An example for AT: +43 1 4277 14033 (POTS, Vienna) or > > +43 664 1234567 (mobile) > > An example for ES: +34 93 1234567 (POTS, Barcelona) > > > Looks good. And under this system, am I correct in thinking that my U.S. > number would be encoded as: > > +1 781 2623075 ? (I missed the beginning of this thread, so apologies if this was mentioned...) One possible problem is there's no way for me to know if the person entering the phone number is using this form or not. In such a case, I don't know whether the number after the last space is part of the number of the extension. +31 20 535 4444 Does this person sit at extension 4444, or are they merely using one of the the local Dutch method? Unless you can *enforce* the canonical form, then perhaps it's not so bad to diferentiate the extension somehow? +31 20 535 4444 +31 20 535 4444 x427 In case you were wondering. :) Shane From ginny at arin.net Thu Jan 4 11:16:52 2001 From: ginny at arin.net (ginny listman) Date: Thu, 4 Jan 2001 11:16:52 -0500 (EST) Subject: DB schema In-Reply-To: <20010104125747.B18244@mars.lab.time-travellers.org> Message-ID: Thanks for your comments. We've had some additional meetings here to discuss some of the exact things you brought up... On Thu, 4 Jan 2001, Shane Kerr wrote: > All, > > I've had a quick look over the proposed DB schema, and have the > following comments/suggestions/questions: > > o Please please please don't use HANDLE to represent the key for the > objects. You should really think about using an internal identifier > as the key. You can/should still make HANDLE a unique field, but > users use this to encode information (company name, network city > location, whatever), and as such want to change it. This process is > much simplier with a distinct, internal-only, key. > By this, I'm assuming that you would like to be able to change your netname or as name. If this is what you are asking, I would expect that the Net/AS Name could NOT be changed via a template, but would have to be a special request. The only reason I would enforce this, is to avoid the potential typo. I believe the Net/AS Name is yours to change whenever you feel it appropriate, but would like to have basic checks built into the software. > o Why isn't address stored in a seperate table like phone, mailbox, and > so on? > We discussed the possibility of separating address, but in reality most of the time we retrieve the individual/organization we also want the address. One change that is not in the current conversion plan, but was discuss on the list is the flexibility of multiple phones and mailboxes. For this reason, they will continue to be separate tables. > o Can an organization or network have multiple parents? If not, perhaps > it might make more sense to include a "parent" attribute in the tables > rather than use a seperate link table. Good point, and will be incorporated. > > o You'll need to add an "ordering" attribute to the tables, to allow for > stable sorting on the output. For example, inaddr servers should > appear in the order the user specifies, and contacts should probably > also work this way. > Another good point. I didn't realize that order matter that much. Adding a sequence_no to the table should handle this issue. As long as there are no objections, it will be added. > o Why use start and number of AS rather than start-end for AS numbers? > Since this was Cathy's idea, Cathy do you want to answer this, or discuss doing the start-end rather that number? > o What's a "resource link"? A resource is either a address space or AS. This table has been eliminated, and an org_handle be included in the neetwork and as_number tables. > > o What's a maintainer? Please just kill this beast, or at least define > it in a meaningful way. :( > This is another one for Cathy to answer. > o What are you going to do about the gazillion non-CIDR networks that > exist today? There are a lot of networks in the ARIN database that > are (for example) a /24 and the subsequent /25. I suggest that you > should store networks as start-end in the database, even if you remove > this from the templates and/or web forms. On output, you can convert > to between 1 to 31 CIDR networks, but it's probably simplier to just > store start-end ranges when storing the addresses. > Storing in cidr or range has been discussed in depth here at ARIN. CIDR has become the way of the world. RSG works in CIDR. If an allocation is more than one cidr block, that's okay, it will be represented as multiple cidr blocks. > o Am I the only one who hates templates? ;) > In my research, I'd have to say, no... > Shane > From woeber at cc.univie.ac.at Thu Jan 4 11:22:52 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 04 Jan 2001 17:22:52 +0100 Subject: phone types] Message-ID: <009F59FB.6EF6399E.14@cc.univie.ac.at> => Looks good. And under this system, am I correct in thinking that my U.S. => number would be encoded as: => => +1 781 2623075 ? Yes. =One possible problem is there's no way for me to know if the person =entering the phone number is using this form or not. In such a case, I =don't know whether the number after the last space is part of the number =of the extension. = = +31 20 535 4444 True, but you can never deal with that properly anyway, because someone might prefer to not include an extension - for whatever reason. =Does this person sit at extension 4444, or are they merely using one of =the the local Dutch method? Unless you can *enforce* the canonical =form, then perhaps it's not so bad to diferentiate the extension =somehow? = = +31 20 535 4444 = +31 20 535 4444 x427 = =In case you were wondering. :) Should I ? :-) =Shane Actually that's the reason why I asked Andrei to cross-check against the RIPE-DB definition, which is: >Date: Thu, 04 Jan 2001 11:32:27 +0100 >From: Andrei Robachevsky > [ ... ] >In the RIPE Database the following syntax is accepted for phone numbers: > >+ followed by numbers separated by the whitespace, "-" or ".". "()" are >also accepted. The number may be followed by the keyword "ext." and >another number (for extension). So, all of the 3 possibilites +31 20 535 4444 +31 20 535 4444 427 +31 20 535 4444 ext. 427 as well as +31.20.535.4444 +31-20-535-4444-427 +31 (20) 535 4444 ext.427 +31 (20) 535 4444-427 would be acceptable. I guess we would even be prepared to extend "our" format to allow "x" as well if that is what the "+1 region" prefers.... Wilfried. From ginny at arin.net Thu Jan 4 11:28:40 2001 From: ginny at arin.net (ginny listman) Date: Thu, 4 Jan 2001 11:28:40 -0500 (EST) Subject: phone types] In-Reply-To: <20010104164830.A19828@mars.lab.time-travellers.org> Message-ID: Just a repeat of what I said earlier: We (ARIN) would like to format US/CA phone number in the format of +1-999-999-9999. In other words, drop all initial 0's and 1's, and then there should be 10 digits. Then format it. If there is non-digits, they are lost. If there are not exactly 10 digits, it's an error. I should also mention, extensions would be included on a separate line. This would be a free-form line to include up to 10 chars. As far as non-US/CA numbers, we haven't gotten that far. (But we will get there.) There was some brief discussion as to whether is should be ".", "-" or " " to separate the numbers. Do we need to revisit? Ginny On Thu, 4 Jan 2001, Shane Kerr wrote: > On Thu, Jan 04, 2001 at 09:27:40AM -0500, J. Scott Marcus wrote: > > At 11:25 01/04/2001 +0100, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > ... > > > That is the reason why we try to motivate people to use the canonical > > > form of > > > > > > +countryregional-codesubscriber-numberextension > > > +99 1234 11223344 9999 > > > > > > An example for AT: +43 1 4277 14033 (POTS, Vienna) or > > > +43 664 1234567 (mobile) > > > An example for ES: +34 93 1234567 (POTS, Barcelona) > > > > > > Looks good. And under this system, am I correct in thinking that my U.S. > > number would be encoded as: > > > > +1 781 2623075 ? > > (I missed the beginning of this thread, so apologies if this was > mentioned...) > > One possible problem is there's no way for me to know if the person > entering the phone number is using this form or not. In such a case, I > don't know whether the number after the last space is part of the number > of the extension. > > +31 20 535 4444 > > Does this person sit at extension 4444, or are they merely using one of > the the local Dutch method? Unless you can *enforce* the canonical > form, then perhaps it's not so bad to diferentiate the extension > somehow? > > +31 20 535 4444 > +31 20 535 4444 x427 > > In case you were wondering. :) > > Shane > From woeber at cc.univie.ac.at Thu Jan 4 11:35:49 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 04 Jan 2001 17:35:49 +0100 Subject: DB schema Message-ID: <009F59FD.3DC0CDCE.1@cc.univie.ac.at> => o What are you going to do about the gazillion non-CIDR networks that => exist today? There are a lot of networks in the ARIN database that => are (for example) a /24 and the subsequent /25. I suggest that you => should store networks as start-end in the database, even if you remove => this from the templates and/or web forms. On output, you can convert => to between 1 to 31 CIDR networks, but it's probably simplier to just => store start-end ranges when storing the addresses. => =Storing in cidr or range has been discussed in depth here at ARIN. CIDR =has become the way of the world. RSG works in CIDR. If an allocation is =more than one cidr block, that's okay, it will be represented as multiple =cidr blocks. I'm Just curious because "we" use the range notation... What is the benefit/advantage of going CIDR _for the DB_, and thus ending up with more than 1 object for the same net (e.g. 1 /26 plus 1 /27 and maybe 1 /28) and all the potential DB inconsistencies (different net names, different contacts, multiple answers for 1 query) as compared to a more "traditional" approach? => o Am I the only one who hates templates? ;) => = =In my research, I'd have to say, no... I tend to agree :-) => Shane => Wilfried. From smarcus at genuity.com Thu Jan 4 11:39:24 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Thu, 04 Jan 2001 11:39:24 -0500 Subject: phone types] In-Reply-To: References: <20010104164830.A19828@mars.lab.time-travellers.org> Message-ID: <3.0.5.32.20010104113924.00b361d0@pobox3.genuity.com> At 11:28 01/04/2001 -0500, ginny listman wrote: >Just a repeat of what I said earlier: > >We (ARIN) would like to format US/CA phone number in the format of >+1-999-999-9999. In other words, drop all initial 0's and 1's, and then >there should be 10 digits. Then format it. If there is non-digits, they >are lost. If there are not exactly 10 digits, it's an error. I should >also mention, extensions would be included on a separate line. This would >be a free-form line to include up to 10 chars. > >As far as non-US/CA numbers, we haven't gotten that far. (But we will get >there.) > >There was some brief discussion as to whether is should be ".", "-" or " " >to separate the numbers. Do we need to revisit? I would argue that the format should be consistent with that used by the other RIRs, unless there is a compelling reason to do otherwise. We just heard that RIPE accepts whitespace, dash or period within numbers. Thus, your proposed format of +1-999-999-9999 appears to satisfy that criterion. Cheers, - Scott From cathym at arin.net Thu Jan 4 11:53:42 2001 From: cathym at arin.net (Catherine Murphy) Date: Thu, 4 Jan 2001 11:53:42 -0500 (EST) Subject: DB schema In-Reply-To: Message-ID: > shane> o Why use start and number of AS rather than start-end for AS > shane> numbers? ginny> Since this was Cathy's idea, Cathy do you want to answer this, or ginny> discuss doing the start-end rather that number? I proposed to use start+number of AS's in order to be consistent with the proposed method to store networks, i.e., network + CIDR. However, upon reflection, I agree that start-end is the better way to store the information -- it eliminates the need for calculations to find an AS. > shane> o What's a maintainer? Please just kill this beast, or at least > shane> define it in a meaningful way. :( ginny> This is another one for Cathy to answer. You're right. Why have a separate table? I think we should just have a flag in the org table to indicate whether they are permitted to "allocate" or not. No maintainer; no separate table; just a maintainer_flag in the organization information. Cathy From michaelo at arin.net Thu Jan 4 15:04:58 2001 From: michaelo at arin.net (Michael O'Neill) Date: Thu, 4 Jan 2001 15:04:58 -0500 (EST) Subject: Administrative contacts | "one" or "one or many"? Message-ID: <200101042004.PAA08918@ops.arin.net> Hello! So far no comments on this list have addressed the singular administrative contact: | From: ginny listman | Date: Wed, 27 Dec 2000 16:08:54 -0500 (EST) | There will be the following types of POCs, with the following | requirements: | Administrative Contact (AD) - one and only one, mandatory for an | Organization, optional for AS or Network Does this mean that people agree that an organization like "EXAMPLE.COM" would have or need only one Administrative Contact? Administrative Contact: Smith, Jo jsmith at example.com EXAMPLE.COM 100 Pine Street Melvindale, CA 90292 US +1-415-823-9358 or Administrative Contact: Example administrators managers at example.com EXAMPLE.COM 100 Pine Street Melvindale, CA 90292 US +1-415-823-9333 ....or would some organizations make use of an administration contact specification as "Administrative Contact (AD) - one or many, mandatory for an Organization, mandatory for ASes or Network w/o an Organization AD, optional otherwise" Would some ARIN registrants want to be able to specify (instead of blend into one role account) a subset of their employees as the administrative contacts? Example.com could then optionally set the administration information to: Administrative Contact: Smith, Jo jsmith at example.com EXAMPLE.COM Melvindale, CA 90292 US +1-415-823-9358 Administrative Contact: Jones, Pat pj at example.com 100 Pine Street Melvindale, CA 90292 US +1-415-823-9330 Administrative Contact: Baker, Chris chrisb at example.com 100 Pine Street Melvindale, CA 90292 US +1-415-823-9331 In case Jo Smith left EXAMPLE.COM under suspicious circumstances, Pat Jones and Chris Baker could make any necessary ARIN database modifications on behalf of EXAMPLE.COM. For an AS, would registered organizations want bgp at example.com to respond to one subset of administrative requests and peering at example.com to reply to peering requests? Some entries in the ftp://ftp.arin.net/pub/rr/arin.db file have specified more than one "admin-c" so these organizations may feel restricted if converted and forced to make a change to one administrative contact. I would guess--since no one has mentioned anything on the list--that most organizations would maintain a managers at example.com or admin at example.com e-mail list and add and substract administrative contact(s) as necessary. Would registrants make use of the other options if Administrative Contacts could be set as "one or many, mandatory for an Organization, mandatory for ASes or Network w/o an Organization AD, optional otherwise"? --Michael J. O'Neill From huberman at gblx.net Thu Jan 4 16:26:45 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 4 Jan 2001 14:26:45 -0700 (MST) Subject: Administrative contacts | "one" or "one or many"? In-Reply-To: <200101042004.PAA08918@ops.arin.net> Message-ID: Hello Michael, Ginny, et al., ARIN *absolutely* must allow member-organizations to have multiple administrative contacts - with no ceiling. Large and small providers alike must be allowed to plan for future turnover without jeopardizing future communication between themselves and ARIN. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From ginny at arin.net Thu Jan 4 16:36:48 2001 From: ginny at arin.net (ginny listman) Date: Thu, 4 Jan 2001 16:36:48 -0500 (EST) Subject: Administrative contacts | "one" or "one or many"? In-Reply-To: Message-ID: consider it done. ;) On Thu, 4 Jan 2001, David R Huberman wrote: > Hello Michael, Ginny, et al., > > ARIN *absolutely* must allow member-organizations to have multiple > administrative contacts - with no ceiling. Large and small providers alike > must be allowed to plan for future turnover without jeopardizing future > communication between themselves and ARIN. > > /david > > *--------------------------------* > | Global Crossing IP Engineering | > | Manager, Global IP Addressing | > | TEL: (908) 720-6182 | > | FAX: (703) 464-0802 | > *--------------------------------* > From jkd at cyberspace.org Thu Jan 4 23:28:48 2001 From: jkd at cyberspace.org (John K. Doyle, Jr.) Date: Thu, 4 Jan 2001 23:28:48 -0500 (EST) Subject: phone types] In-Reply-To: Message-ID: Ginny, I don't think my original post ever made it to the list. To reiterate: You should probably take a look at the ITU (formerly CCITT) standard for "directory numbers." The last time I ever looked at it, it was known as "E.163" but that's evidently been superseded. So visit http:/www.itu.int/ (See, the .int domain DOES exist :)) and search on "E.164" . That will return a link to an abstract of the 15-page document on the subject. One thing to worry about that nobody here has mentioned is possible changes to the U.S. NPA-NXX standard. We shouldn't get into that here. Battles on the subject rage regularly in Telecom Digest and other places. They make "RFC1918 Wars" look tame by comparison. However, the possibility exists that the "10 digit" U.S. standard might change in the not too distant future. John On Thu, 4 Jan 2001, ginny listman wrote: > Just a repeat of what I said earlier: > > We (ARIN) would like to format US/CA phone number in the format of > +1-999-999-9999. In other words, drop all initial 0's and 1's, and then > there should be 10 digits. Then format it. If there is non-digits, they > are lost. If there are not exactly 10 digits, it's an error. I should > also mention, extensions would be included on a separate line. This would > be a free-form line to include up to 10 chars. > > As far as non-US/CA numbers, we haven't gotten that far. (But we will get > there.) > > There was some brief discussion as to whether is should be ".", "-" or " " > to separate the numbers. Do we need to revisit? > > Ginny From ginny at arin.net Thu Jan 11 08:30:50 2001 From: ginny at arin.net (ginny listman) Date: Thu, 11 Jan 2001 08:30:50 -0500 (EST) Subject: Another design question Message-ID: I have another design question to ask the working group. Is there a need to associate a mailbox and/or phone with an Organization, Network or AS? This mailbox and/or phone will not be associated with a POC, and change as the POC changes, but associated with the entity itself. Ginny From Greg.Sanche at attcanada.com Thu Jan 11 08:40:34 2001 From: Greg.Sanche at attcanada.com (Sanche, Greg) Date: Thu, 11 Jan 2001 06:40:34 -0700 Subject: Another design question Message-ID: A Mailbox... I'm not sure, but the Main Phone number, address, dept name, and proper business/company registration number would be important. Greg Sanche AT&T Canada Corp. Senior Manager, Advanced Enterprise & Technology -----Original Message----- From: ginny listman [mailto:ginny at arin.net] Sent: Thursday, January 11, 2001 8:31 AM To: dbwg at arin.net Subject: Another design question I have another design question to ask the working group. Is there a need to associate a mailbox and/or phone with an Organization, Network or AS? This mailbox and/or phone will not be associated with a POC, and change as the POC changes, but associated with the entity itself. Ginny From shane at time-travellers.org Thu Jan 11 16:09:24 2001 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 11 Jan 2001 22:09:24 +0100 Subject: Another design question In-Reply-To: ; from Greg.Sanche@attcanada.com at 2001-01-11 06:40:34 +0000 References: Message-ID: <20010111220922.A19786@mars.lab.time-travellers.org> IP number ranges and AS numbers do not have snail-mail addresses, phone numbers, or e-mail addresses. A network, including both network numbers and AS numbers, can span any number of possibly disjoint geographic areas. IP is designed to separate physical topology from logical topology, and does a pretty good job of it. The networks or ASN's should have the name of a person or role (help desk, whatever) to contact in the case of operational problems (network unreachable, spam, whatever). This point of contact (POC) will necessarily have at least one of snail-mail address, phone number, or e-mail address. ARIN also needs the name of a person or role that is responsible for administrative changes to the network which will likewise have contact inforamtion, but that doesn't really need to be public. Since the US Supreme Court gave corportations the same legal standing as individuals in 1886, I suppose it makes sense that they should also have address, phone number, and e-mail attributes in the database. :) And since each network or ASN presumably belongs to an organization, that contact information will be available as well, again possibly only to ARIN. Shane On 2001-01-11 06:40:34 +0000, Sanche, Greg wrote: > > A Mailbox... I'm not sure, but the Main Phone number, address, dept name, > and proper > business/company registration number would be important. > > Greg Sanche > AT&T Canada Corp. > Senior Manager, Advanced Enterprise & Technology > > > > -----Original Message----- > From: ginny listman [mailto:ginny at arin.net] > Sent: Thursday, January 11, 2001 8:31 AM > To: dbwg at arin.net > Subject: Another design question > > > I have another design question to ask the working group. Is there a need > to associate a mailbox and/or phone with an Organization, Network or AS? > This mailbox and/or phone will not be associated with a POC, and change > as the POC changes, but associated with the entity itself. > > Ginny From huberman at gblx.net Wed Jan 24 05:52:08 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 24 Jan 2001 03:52:08 -0700 (MST) Subject: Authorization and Authentication Message-ID: Hello Ginny, When you have a moment, can you please summarize for the dbwg mailing list ARIN's plans for implementing authorization and authentication methods for database records in the new ARIN WHOIS? This issue has been discussed many times in the past, but nothing has ever been implemented in this area, and I think it may be worthwhile to resume the discussion of this topic. Thanks /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From ginny at arin.net Wed Jan 24 13:07:00 2001 From: ginny at arin.net (ginny listman) Date: Wed, 24 Jan 2001 13:07:00 -0500 (EST) Subject: Authorization and Authentication In-Reply-To: Message-ID: Thank you for bringing this issue to the dbwg mailing list, David. This is one of many topics on our agenda to be discussed on this list. We would like to reopen this discussion and identify any preferences our members may have regarding the method of authorization and authentication to be used with our new database interface. This topic could also be further discussed during the dbwg at the Member Meeting in April. Do you, the users of the ARIN database, have a preference of authorization and authentication methods or general comments you would like to make as we define the requirements of this feature to our new database interface? Options discussed in the past have included PGP, certificates, and SSL-based passwords. All comments made to this list are appreciated, as your feedback is very important to the process of developing the new ARIN registration software. One final note is that one of ARIN's top priorities is the database redesign to improve performance. Although we may discuss authorization and authentication concerns/methods, realistically, ARIN will not be implementing them until next year. Ginny On Wed, 24 Jan 2001, David R Huberman wrote: > Hello Ginny, > > When you have a moment, can you please summarize for the dbwg mailing list > ARIN's plans for implementing authorization and authentication methods for > database records in the new ARIN WHOIS? > > This issue has been discussed many times in the past, but nothing has ever > been implemented in this area, and I think it may be worthwhile to resume > the discussion of this topic. > > Thanks > > /david > > *--------------------------------* > | Global Crossing IP Engineering | > | Manager, Global IP Addressing | > | TEL: (908) 720-6182 | > | FAX: (703) 464-0802 | > *--------------------------------* > From ginny at arin.net Mon Jan 29 11:30:52 2001 From: ginny at arin.net (ginny listman) Date: Mon, 29 Jan 2001 11:30:52 -0500 (EST) Subject: Name Servers/IP Addresses Message-ID: For the purpose of delegating sub-domains in the in-addr.arpa domain ARIN currently collects both the name and the IP address of the Name Servers. This information is stored in the ARIN database and is displayed in whois. Only the name of Name Server is needed for the NS RR. The IP address is not used for anything but the whois display. Proposed Change: As part of the new schema, ARIN would no longer collect the IP Address. Pros: This would require one less piece of information that would have to be collected and maintained. Con: This information will no longer be displayed in whois. Questions: 1. Does anyone rely on the IP Address associated with Name Servers displayed in ARIN's whois database? 2. Is the order of Name Servers important? Whether the Name Server is the primary or secondary is technically irrelevant for the purpose of delegation. Does the order matter for the whois display? Should the servers be identified as primary and secondary either specically by annotation or inferred by the order of display? Ginny Listman Director of Engineering ARIN From dploher at level3.net Mon Jan 29 12:11:55 2001 From: dploher at level3.net (Darren Loher) Date: Mon, 29 Jan 2001 10:11:55 -0700 Subject: Name Servers/IP Addresses In-Reply-To: ; from ginny@arin.net on Mon, Jan 29, 2001 at 11:30:52AM -0500 References: Message-ID: <20010129101155.C22768@mail1.idc1.oss.level3.com> Hi, Removing the IP address for nameservers in whois should not be a problem, as anyone who needs it can obtain an accurate IP address for that zone by doing a DNS lookup. That's a much better method as the IP address in DNS is what is actually used, not whois. The order of nameservers in the whois database should also not be important, strictly speaking. In DNS, an NS record is an NS record. There is no distintion regarding NS records between master and slave name servers. -- Darren Loher Level 3 Communications dploher at level3.net Global Data Architecture 720-888-2847 (office) "Sed quis custodiet ipsos custodes?" On Mon, Jan 29, 2001 at 11:30:52AM -0500, ginny listman wrote: > For the purpose of delegating sub-domains in the in-addr.arpa domain ARIN > currently collects both the name and the IP address of the Name Servers. > This information is stored in the ARIN database and is displayed in whois. > Only the name of Name Server is needed for the NS RR. The IP address is > not used for anything but the whois display. > > Proposed Change: As part of the new schema, ARIN would no longer collect > the IP Address. > > Pros: This would require one less piece of information that would have to > be collected and maintained. > > Con: This information will no longer be displayed in whois. > > > Questions: > 1. Does anyone rely on the IP Address associated with Name Servers > displayed in ARIN's whois database? > > 2. Is the order of Name Servers important? Whether the Name Server is the > primary or secondary is technically irrelevant for the purpose of > delegation. Does the order matter for the whois display? Should the > servers be identified as primary and secondary either specically by > annotation or inferred by the order of display? > > > Ginny Listman > Director of Engineering > ARIN -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From shane at time-travellers.org Mon Jan 29 15:37:22 2001 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 29 Jan 2001 21:37:22 +0100 Subject: Name Servers/IP Addresses In-Reply-To: <20010129101155.C22768@mail1.idc1.oss.level3.com>; from dploher@level3.net at 2001-01-29 10:11:55 +0000 References: <20010129101155.C22768@mail1.idc1.oss.level3.com> Message-ID: <20010129213722.A2063@mars.lab.time-travellers.org> On 2001-01-29 10:11:55 +0000, Darren Loher wrote: > > Removing the IP address for nameservers in whois should not be a > problem, as anyone who needs it can obtain an accurate IP address for > that zone by doing a DNS lookup. That's a much better method as the > IP address in DNS is what is actually used, not whois. There is one advantage of ARIN tracking the IP of IN-ADDR servers. In that case, the ARIN DNS servers can provide glue records for the clients performing the query. These records provide information so the client doesn't have to perform the additional DNS lookup(s), saving time and network traffic. Of course, this means that changes in server IP addresses have to be updated in both the zones where they're delegated as well as the ARIN database, an administrative overhead many organizations will wish to avoid. If anything, it might be nice to provide an option to allow members to set the IP address of their servers, as long as the explaination of the benefit (faster queries for clients) and drawback (possible mismatch between the name to address and address-to-name DNS mapping if records are not kept in sync) is made clear. > The order of nameservers in the whois database should also not be > important, strictly speaking. In DNS, an NS record is an NS record. > There is no distintion regarding NS records between master and slave > name servers. True to a degree. As you probably know, in the DNS system the orders are typically shuffled in a random fashion, and the clients use the Round Trip Time algorithm to direct their queries. But if the Whois server returns the same output for the same record every time, then it makes life a lot easier on anyone who has, say, and automated tool to compare the contents of Whois records. If name servers are consistently ordered, then all that you need to do is compare the text of the records. If they are not, then you actually have to parse the NS records out of the Whois reply, and compare the list of NS entries seperately. Not rocket science, but it does make life harder on the users. I humbly suggest that this is a Bad Thing. Shane From ginny at arin.net Wed Jan 31 12:49:55 2001 From: ginny at arin.net (ginny listman) Date: Wed, 31 Jan 2001 12:49:55 -0500 (EST) Subject: The future of SWIP Message-ID: Does anyone comment on which option you prefer? Definitions, as they pertain to this document: Assignment - When address space is provided to and utilized by the End User. Allocation - When address space is provided to an entity, who further allocates and/or assigns the space. Upstream - Entity who received address space directly from ARIN. Downstream - Entity who received address space from an Upstream. Assumptions: 1. Changes to the SWIP template are required in either option. These changes will be minor, and due to SWIPs being critical, ARIN will accept both old and new templates for an extended period. 2. If an entity wishes to allocate/re-allocate, they are required to register basic Organization information to include: organization name, address, and points of contact. 3. This policy is in regard to allocations. For assignments, all Org information will still be required and provided from the Upstream. Option 1 - The Upstream registers the Downstream's Organization Information Considerations: 1. This is the current method of processing SWIP templates. 2. There would be 1 additional field on SWIP template, to allow submitter to enter the Maintainer ID along with, or to replace all other Organization information. Pros: 1. Will allow the submitter to enter either an existing Maintainer ID, OR the required address and POC information. May reduce required input for customer. Cons: 1. Potential to have multiple Maintainer ID for a single entity. 2. May result in multiple POC handles for same POCs. Option 2 - The Downstream registers the Downstream's Organization Information Considerations: 1. A single field, Maintainer ID, will replace the Organization information including POCs, on the SWIP template. 2. There will be a reallocation flag in the database for each organization. When an organization is registered, by default it will be set to 'N'. Upon receiving its first allocation, it will be changed to 'Y'. 3. ARIN will reserve the right to delete from the database, an Organization that has not had any networks associated with it, i.e. a reallocation flag of 'N'. ARIN will send out notification at n number of days, and delete in n+30 number of days. Pros: 1. Maintainer ID is controlled by Downstream, allowing Downstream to update pertainent information. 2. Cleaner data. 3. Facilitates managing multi-homed companies, in the whois database. 4. Organizations that are currently registered via an AS, will have a Maintainer ID. It will not be necessary to get any additional information. Cons: 1. Maintainer ID is required to process SWIP template. 2. Requires additional registration from Downstream, and education from Upstream on ARIN registration procedures. 3. May lead to many Organizations being processed through the registration/deletion cycle without associated resources. Other things to consider: 1. The Upstream still owns the resources, and will still have the authority to give and remove the networks associated with a Downstream. If a Downstream winds up with multiple Maintainer IDs, they must go through the Upstream to change. Ginny Listman Director of Engineering From huberman at gblx.net Wed Jan 31 16:38:54 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 31 Jan 2001 14:38:54 -0700 (MST) Subject: The future of SWIP In-Reply-To: Message-ID: Hello Ginny, I can't say I see the merits of either approach, to be honest. I am 100% against Option 2, in its current form. Education of downstream customers on using ARIN tools is not a viable option for larger providers with significant customer bases. The advantages of Option 1 seem far outweighed by the disadvantages as you have articulated them. A messier database, with multiple overlapping objects, is not what we're aiming for. Personally, I don't see any major problems with SWIP as it is now conceptually - it simply needs full automation to allow templates to be processed with immediacy. Comments/flames welcome. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From martind at uu.net Wed Jan 31 18:12:18 2001 From: martind at uu.net (Dawn Martin) Date: Wed, 31 Jan 2001 18:12:18 -0500 Subject: The future of SWIP In-Reply-To: ; from David R Huberman on Jan 31, 2001 at 02:38:54PM References: Message-ID: <20010131181218.B6744@uu.net> I agree, SWIP should be more automated. I don't see why there is a need for upstreams to be the only ones to be able to change an assignment to an allocation. I would think it is a common enough change and if the downstream wants to SWIP their reassignments, why make it a longer process? In the past the downstream could contact ARIN an have them put a maintainer ID on the block. -Dawn Quoth David R Huberman (huberman at gblx.net): > Hello Ginny, > > I can't say I see the merits of either approach, to be honest. > > I am 100% against Option 2, in its current form. Education of > downstream customers on using ARIN tools is not a viable option > for larger providers with significant customer bases. > > The advantages of Option 1 seem far outweighed by the disadvantages > as you have articulated them. A messier database, with multiple > overlapping objects, is not what we're aiming for. > > Personally, I don't see any major problems with SWIP as it is now > conceptually - it simply needs full automation to allow templates > to be processed with immediacy. > > Comments/flames welcome. > > /david > > *--------------------------------* > | Global Crossing IP Engineering | > | Manager, Global IP Addressing | > | TEL: (908) 720-6182 | > | FAX: (703) 464-0802 | > *--------------------------------* >