From memsvcs at arin.net Mon Oct 8 16:19:15 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 8 Oct 2001 16:19:15 -0400 (EDT) Subject: ARIN VIII - Register Today Message-ID: Welcome ARIN Members and All Interested Parties: Join in the numerous policy discussions taking place at the ARIN Public Policy and Members Meeting in Miami, October 28-31. Sign up by October 14 to be eligible for the early bird registration prize drawing. Please note that the hotel room block, guaranteeing an ARIN rate, closes on October 15. For all meeting details please see: http://www.arin.net/meetings/ARIN_VIII/index.html Seven policy topics were recently introduced on the public policy or arin-announce mailing lists. If you are not subscribed to these, please read the mailing list archives for details: http://www.arin.net/meetings/ARIN_VIII/index.html New items will be added to the agenda soon so check back weekly. Now is the perfect opportunity to show your commitment to ARIN and the Internet community. Sponsorships at all levels are currently available, starting at $1,500. Find more information and the sponsorship form off the main ARIN VIII meeting page noted above. Member Services will be happy to answer any questions. Susan Hamlin Director, Member Services American Registry for Internet Numbers From memsvcs at arin.net Fri Oct 12 07:59:30 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 12 Oct 2001 07:59:30 -0400 (EDT) Subject: ARIN VIII Message-ID: Recently there have been a few inquiries regarding the status of the upcoming ARIN meeting. While we all share a concern over the current state of world affairs, it is important to move forward. The biannual Public Policy and Members Meetings are an integral part of ARIN's mission to build consensus-based policies. As there have been many policy discussions on our mailing lists of late, we need to carry that momentum into the public meeting forum. Accordingly, ARIN will hold its biannual meeting as scheduled, October 28 - 31 in Miami, Florida. We look forward to productive discussions and hope that you will make plans to join us. Raymond A. Plzak President & CEO From memsvcs at arin.net Thu Oct 18 16:44:59 2001 From: memsvcs at arin.net (Member Services) Date: Thu, 18 Oct 2001 16:44:59 -0400 (EDT) Subject: ARIN VIII: Expanded Meeting Agenda Posted Message-ID: ARIN VIII Public Policy and Members Meeting is just ten days away. Make your plans to join us in Miami October 28 - 31. Rooms are still available at the hotel, so be sure to register now! The expanded agenda, including Sunday's tutorial offerings are now posted at: http://www.arin.net/meetings/ARIN_VIII/index.html Among the new meeting information you will find the hours of the on-site registration services help desk and a description of the Monday evening social. Sponsorship opportunities are still available, and details can be found on the Sponsor Registration Form link off the main meeting page. We appreciate your attendance and participation in the upcoming policy discussions. Susan Hamlin Director, Member Services From louie at equinix.com Mon Oct 29 11:07:30 2001 From: louie at equinix.com (Louis Lee) Date: Mon, 29 Oct 2001 08:07:30 -0800 Subject: spike in ARIN IP allocation in Jan 2001 Message-ID: <4FA6CECCC8A3D41186F700B0D0784FF40108A762@hq-exchange.corp.equinix.com> Leslie, Thank you for your Joint RIR Statistics presentation at the public policy meeting this morning. I look forward to reviewing slides when they get posted to the ARIN website. I noticed that there was a spike in ARIN IP allocation in January 2001 (and maybe another spike just a couple of months before). While I have a number of guess why this may be, I was wondering if you have any insight for the reasons behind the spike(s). I don't think the other RIRs experienced a similar spike. Thanks, Louie ----------------------------------------------------------------- Louis Lee louie at equinix.com Network Engineer office: 650/316-6162 Equinix, Inc. fax: 650/298-0420 http://www.equinix.com/ From jfleming at anet.com Mon Oct 29 11:37:02 2001 From: jfleming at anet.com (Jim Fleming) Date: Mon, 29 Oct 2001 10:37:02 -0600 Subject: spike in ARIN IP allocation in Jan 2001 References: <4FA6CECCC8A3D41186F700B0D0784FF40108A762@hq-exchange.corp.equinix.com> Message-ID: <0a2301c16097$f1e61340$3e00a8c0@pamela> Could it be from the Charter TLDs ? http://www.in-addr.info CHARTER IN-ADDR.[TLD] ZONES.....in the legacy root... ARPA 0:0 NET 0:1 ORG 0:190 COM 0:201 MS 1:189 VG 1:254 AZ 3:29 DE 3:89 BE 3:132 DK 3:210 INFO 3:219 VA 3:244 TD 5:91 IO 5:161 CX 6:134 CC 6:156 TV 6:171 WS 6:247 NU 6:255 --- Do you use a 2002::0000 prefix ? http://www.dot-arizona.com/IPv8/IPv4/ http://www.ietf.org/mail-archive/ietf/Current/msg12213.html JimFleming at Unir.com http://www.unir.com http://www.unir.com/images/architech.gif http://www.unir.com/images/headers.gif http://www.unir.com/images/address.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html ----- Original Message ----- From: "Louis Lee" To: "'Leslie Nobile'" Cc: "'ARIN Public Policy Mailing List'" Sent: Monday, October 29, 2001 10:07 AM Subject: spike in ARIN IP allocation in Jan 2001 > Leslie, > > Thank you for your Joint RIR Statistics presentation at the public policy > meeting this morning. I look forward to reviewing slides when they get > posted to the ARIN website. > > I noticed that there was a spike in ARIN IP allocation in January 2001 (and > maybe another spike just a couple of months before). While I have a number > of guess why this may be, I was wondering if you have any insight for the > reasons behind the spike(s). I don't think the other RIRs experienced a > similar spike. > > Thanks, > Louie > ----------------------------------------------------------------- > Louis Lee louie at equinix.com > Network Engineer office: 650/316-6162 > Equinix, Inc. fax: 650/298-0420 > http://www.equinix.com/ > > > > From leslien at arin.net Mon Oct 29 16:21:45 2001 From: leslien at arin.net (Leslie Nobile) Date: Mon, 29 Oct 2001 16:21:45 -0500 Subject: spike in ARIN IP allocation in Jan 2001 In-Reply-To: <4FA6CECCC8A3D41186F700B0D0784FF40108A762@hq-exchange.corp.equinix.com> Message-ID: Hi Louie- ARIN periodically sees spikes in the monthly allocation statistics. The spike in Jan 2001 was due to the fact that we issued a larger than usual number of v4 addresses. This was due to the fact that we made several very large allocations within that month which caused this particular spike. Please let me know if you have any further questions. Thanks. Leslie -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Louis Lee Sent: Monday, October 29, 2001 11:08 AM To: 'Leslie Nobile' Cc: 'ARIN Public Policy Mailing List' Subject: spike in ARIN IP allocation in Jan 2001 Leslie, Thank you for your Joint RIR Statistics presentation at the public policy meeting this morning. I look forward to reviewing slides when they get posted to the ARIN website. I noticed that there was a spike in ARIN IP allocation in January 2001 (and maybe another spike just a couple of months before). While I have a number of guess why this may be, I was wondering if you have any insight for the reasons behind the spike(s). I don't think the other RIRs experienced a similar spike. Thanks, Louie ----------------------------------------------------------------- Louis Lee louie at equinix.com Network Engineer office: 650/316-6162 Equinix, Inc. fax: 650/298-0420 http://www.equinix.com/ From richardj at arin.net Tue Oct 30 09:02:04 2001 From: richardj at arin.net (Richard Jimmerson) Date: Tue, 30 Oct 2001 09:02:04 -0500 Subject: Mobile IP addressing IR40 document from GSM Association Message-ID: <003601c1614b$74d8eee0$992e7342@cobalt> The GSM association will give a presentation at the ARIN Public Policy meeting today explaining how GPRS operators will address their network infrastructure and mobile terminals. A copy of GSM association's document proposing how GPRS operators will address their networks and terminals can be found at: http://www.apnic.net/meetings/12/docs/Mobile_IP_addressing_IR40_v3.1.0_19Sep 01.doc Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From louie at equinix.com Tue Oct 30 14:45:41 2001 From: louie at equinix.com (Louis Lee) Date: Tue, 30 Oct 2001 11:45:41 -0800 Subject: Policy Proposal 2001-6 In-Reply-To: <200109281455.KAA04036@ops.arin.net>; from memsvcs@arin.net on Fri, Sep 28, 2001 at 10:55:10AM -0400 References: <200109281455.KAA04036@ops.arin.net> Message-ID: <20011030114541.A14985@nemo.corp.equinix.com> On Fri, Sep 28, 2001 at 10:55:10AM -0400, Member Services wrote: > > **Proposed Allocation Policy for: > > Single organizations with large multi-homed discrete networks > We propose for organizations which meet the following criteria to be > granted the opportunity to request additional address space under the > requirements listed below. > > Criteria for the application of this policy: > * Organizations with 'multiple maintainers' should request that this > policy apply to their accounts, their existing allocations merged, > and additional allocations will fall under this policy. Would the language still be too strong to restate as such: ARIN encourages organizations with 'multiple maintainers' request that: - this policy apply to their accounts, - their existing allocations merged, and - additional allocations will fall under this policy. Thoughts? Louie ----------------------------------------------------------------- Louis Lee louie at equinix.com Network Engineer office: 650/316-6162 Equinix, Inc. fax: 650/316-6903 http://www.equinix.com/ From andrew at internap.com Tue Oct 30 14:44:35 2001 From: andrew at internap.com (Andrew Dul) Date: Tue, 30 Oct 2001 11:44:35 -0800 (PST) Subject: Policy 6 - Single organizations with multiple aggregation points Message-ID: After today's discussion at the ARIN VIII meeting, most believed that more discussion was needed on the mailing list. A full copy of the proposed policy is posted here. http://www.arin.net/announcements/2001_policy_discuss.html#policy6 Here are the following points that were raised in the meeting. ----- ARIN should not be involved in deciding if "[an] organization must have a compelling reason for creating discrete networks." Change "must" to "should"? Remove this requirement? ----- "Organizations with 'multiple maintainers' should request that the policy apply to their accounts" This was intended to be a suggestion not a requirement. Is the language still too strong? Remove this requirement? ----- Is 50% a good number to evaluate over all allocations, when returning to ARIN for additional address space. ----- My apologies if I missed your comments. Andrew From jfleming at anet.com Tue Oct 30 15:19:38 2001 From: jfleming at anet.com (Jim Fleming) Date: Tue, 30 Oct 2001 14:19:38 -0600 Subject: Policy 6 - Single organizations with multiple aggregation points References: Message-ID: <014f01c16180$34862800$3e00a8c0@pamela> ----- Original Message ----- From: "Andrew Dul" To: Sent: Tuesday, October 30, 2001 1:44 PM Subject: Policy 6 - Single organizations with multiple aggregation points > After today's discussion at the ARIN VIII meeting, most believed that more > discussion was needed on the mailing list. > > A full copy of the proposed policy is posted here. > > http://www.arin.net/announcements/2001_policy_discuss.html#policy6 > "ARIN currently has an allocation policy that is 'blind' to route Filtering and global routablity, yet in order for address space to be usable it must be accepted and routed by the community at large." ---- How can the allocation policy be "blind" to route filtering and global routability, when the claim has been made for years that the policies are intended to keep the "routing tables" at a manageable size ? Could it be that the policies were really just designed to protect the interests of the people and companies with large allocations ? http://www.iana.org/assignments/ipv4-address-space ....or, did the policies recently lose their eye-sight.... Jim Fleming http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO From huberman at gblx.net Tue Oct 30 15:08:54 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 30 Oct 2001 13:08:54 -0700 (MST) Subject: Policy Proposal 2001-6 In-Reply-To: <20011030114541.A14985@nemo.corp.equinix.com> Message-ID: Hello Louie, > Would the language still be too strong to restate as such: > > ARIN encourages organizations with 'multiple maintainers' request > that: > - this policy apply to their accounts, > - their existing allocations merged, and > - additional allocations will fall under this policy. Just my $0.02, but yes, it would be too strong. It is not necessary to include any such language in this policy proposal to accomplish the primary goals of this proposal, as I interpret them. /david From billd at cait.wustl.edu Wed Oct 31 08:41:05 2001 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 31 Oct 2001 07:41:05 -0600 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: ----- ARIN should not be involved in deciding if "[an] organization must have a compelling reason for creating discrete networks." Change "must" to "should"? Remove this requirement? I am in favor of removing this section as it is the companies option to choose a single or multiple maintainer strategy and ARIN accomodates that strategy. ----- "Organizations with 'multiple maintainers' should request that the policy apply to their accounts" This was intended to be a suggestion not a requirement. Is the language still too strong? Remove this requirement? I believe that the statement should read that "Organizations may, at their discretion, choose to consolidate multiple maintainers." ----- Is 50% a good number to evaluate over all allocations, when returning to ARIN for additional address space. I believe that the 50% overall hurdle is appropriate. ----- My apologies if I missed your comments. Andrew From andrew at internap.com Wed Oct 31 09:25:19 2001 From: andrew at internap.com (Andrew Dul) Date: Wed, 31 Oct 2001 06:25:19 -0800 (PST) Subject: Policy 6 - Single organizations with multiple aggregation points In-Reply-To: Message-ID: Here is the revised text after discussions yesterday. ------ ARIN VIII - Policy Proposal 6 Single organizations with multi-homed discrete networks Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization should have a compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the current RIR bit boundary (currently /29 for ARIN) and record them in an approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation/reservation. The discrete network allocation information should also be present in a public database (Example: routing registry, rWhois, or SWIP). * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. * The organization must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation and reassignment requests and network utilization documents for audits by the RIR. From John.Sweeting at teleglobe.com Wed Oct 31 10:23:54 2001 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 31 Oct 2001 10:23:54 -0500 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: <170E5E7779BCD3118C2A0008C7F40C1903201190@usresms03.teleglobe.com> Hello to all, I would like to inform the mailing list members of the results of the ARIN Advisory Council's discussion of this policy from our meeting last night, October 30th. The AC has agreed to support and forward this policy to the BOT in principle but would like your input as to the final wording of the proposal. The AC will hold a conference call on 9 November, 1100 AM EST, to finalize the wording and vote on endorsing this proposal to the BOT. Once we have agreed to the final wording, the proposal will be sent out to this list for final comments (IAW the ARIN Policy process it will be posted for 10 working days). Our goal is to have this all completed so that the BOT will be able to finalize this proposal during their December 11th meeting. We would like to have all recommendations and comments sent to this list NLT than 1200 AM (midnight) EST on November 8th. I will send out reminders over the next week to remind you all of this deadline. The AC would like to recognize Andrew for his involvement in the policy process and thank him for his time and commitment. Thank you. John -----Original Message----- From: Andrew Dul To: ppml at arin.net Sent: 10/31/01 9:25 AM Subject: Re: Policy 6 - Single organizations with multiple aggregation points Here is the revised text after discussions yesterday. ------ ARIN VIII - Policy Proposal 6 Single organizations with multi-homed discrete networks Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization should have a compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the current RIR bit boundary (currently /29 for ARIN) and record them in an approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation/reservation. The discrete network allocation information should also be present in a public database (Example: routing registry, rWhois, or SWIP). * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. * The organization must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation and reassignment requests and network utilization documents for audits by the RIR. From mhuff at integratelecom.com Wed Oct 31 13:04:54 2001 From: mhuff at integratelecom.com (Huff, Mark) Date: Wed, 31 Oct 2001 10:04:54 -0800 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. This requirement defeats the purpose. If overall usage is measured then the minimum assignment by the RIR, currently /20 needs to be increased. If I am expected to rob from one network to support address depletion in another the blocks must be globally routable. mark huff integra telecom -----Original Message----- From: Andrew Dul [mailto:andrew at internap.com] Sent: Wednesday, October 31, 2001 6:25 AM To: ppml at arin.net Subject: Re: Policy 6 - Single organizations with multiple aggregation points Here is the revised text after discussions yesterday. ------ ARIN VIII - Policy Proposal 6 Single organizations with multi-homed discrete networks Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization should have a compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * An organization which would like to use this policy must apply for this policy to be applied to their maintainer account. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the current RIR bit boundary (currently /29 for ARIN) and record them in an approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation/reservation. The discrete network allocation information should also be present in a public database (Example: routing registry, rWhois, or SWIP). * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. Any reserved blocks must be allocated to a discrete network before the RIR will grant additional address space. * The organization must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation and reassignment requests and network utilization documents for audits by the RIR. From mborchers at splitrock.net Wed Oct 31 14:17:37 2001 From: mborchers at splitrock.net (Borchers, Mark) Date: Wed, 31 Oct 2001 13:17:37 -0600 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: > This requirement defeats the purpose. If overall usage is > measured then > the minimum assignment by the RIR, currently /20 needs to be > increased. > If I am expected to rob from one network to support address depletion > in another the blocks must be globally routable. > > > mark huff > integra telecom This is a new iteration of the old routability vs. address conservation dilemna. Unfortunately, the above statement implies that ARIN should not only guarantee routability of a block (which it has always stopped short of doing), but also guarantee routability of prefixes deaggregated by the registrant. Probably asking a bit much. From mhuff at integratelecom.com Wed Oct 31 20:07:34 2001 From: mhuff at integratelecom.com (Huff, Mark) Date: Wed, 31 Oct 2001 17:07:34 -0800 Subject: Policy 6 - Single organizations with multiple aggregation poi nts Message-ID: Nor can I guarantee sales in more than one discrete market will keep pace with all others. Under this policy one of my networks would be out of business because it reached 100% before I could accomplish 50% globally. > -----Original Message----- > From: Borchers, Mark [mailto:mborchers at splitrock.net] > Sent: Wednesday, October 31, 2001 11:18 AM > To: ppml at arin.net > Subject: RE: Policy 6 - Single organizations with multiple aggregation > poi nts > > > > This requirement defeats the purpose. If overall usage is > > measured then > > the minimum assignment by the RIR, currently /20 needs to be > > increased. > > If I am expected to rob from one network to support address > depletion > > in another the blocks must be globally routable. > > > > > > mark huff > > integra telecom > > This is a new iteration of the old routability vs. address > conservation dilemna. Unfortunately, the above statement implies > that ARIN should not only guarantee routability of a block (which > it has always stopped short of doing), but also guarantee > routability of prefixes deaggregated by the registrant. Probably > asking a bit much. > >