From owner-ire Mon Aug 19 18:33:20 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id SAA13540 for ire-outgoing; Mon, 19 Aug 1996 18:33:20 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id SAA13535 for ; Mon, 19 Aug 1996 18:33:00 +0900 (JST) Received: by dragon.jp.apnic.net; id SAA24860; Mon, 19 Aug 1996 18:18:19 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma024856; Mon, 19 Aug 96 18:18:06 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id SAA04075; Mon, 19 Aug 1996 18:25:01 +0900 (JST) Message-Id: <199608190925.SAA04075@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: ire@apnic.net cc: cidrd@iepg.org reply-to: fix@me.or.bounce Subject: *draft* IRE charter Date: Mon, 19 Aug 1996 18:25:00 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Hi, I received quite a few suggestions of content and requests for a draft of the IRE-WG charter. I've included the draft incorporating some of those suggestions below and instead of replying individually to all requestor/suggestors and then trying to merge all the subsequent changes, I figured a better way would be to throw it out and see what happens. Note that the dates in the goals/milestones section were scientifically chosen using a dartboard. Please send comments/flames/etc. to ire@apnic.net. I've included cidrd@iepg.org on the cc as I was requested to by several people, however I don't think it is an appropriate forum as its a zombie (I'm reminded of the "Bring out yer dead" scene of Monty Python's Holy Grail). I've mucked up the reply-to line just to annoy people into changing the address for followup. Regards, -drc -------- Draft Charter ------------- Internet Registry Evolution --------------------------- Charter Current status: Chairs: David Conrad Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Mailing lists: General Discussion:ire@apnic.net To Subscribe: ire-request@apnic.net Archive: ftp://ftp.apnic.net/mailing-lists/ire Description of Working Group: IRE will focus on the future direction the Internet Registry system should take. There will be four major thrusts of IRE, namely: - creation of a document defining the Internet registry goals, specifically what role(s) the Internet registry system should be performing, can perform, and what functions are best performed by other organizations. - creation of a document which will be used as a skeleton for future Internet registry policies, particularly those to be used in dealing with increasing IPv4 scarcity and commercialization. - creation of a document detailing the administrative structure of the Internet registry system. - development of documents describing architecture and protocols of the next generation Internet registry database system capable of supporting the registration and querying and updating of all types of registry database objects for IPv4 objects including (but not limited to) IPv4 addresses, AS numbers, domain names, authentication objects, routing objects, and contact information, across multiple geographically distributed databases. Depending on developments with respect to IPv6 addressing, IRE may document an architecture for registration of IPv6 related objects where they differ from IPv4 objects. With respect to the last objective, liaison with existing WHOIS related database working groups (RWHOIS, WHOIS++, etc) and incorporation of technologies developed in those working groups is assumed. It is expected that all four objectives of the IRE working group will result in documents which will be used in the operational functions of the Internet Registry system. Goals and Milestones: Dec 31, 1996: First draft of registry goals document First draft of database requirements document Apr 1, 1997: Revision of goals document Revision of DB requirements document First draft of policy document First draft of administrative structure document First draft of database exchange format document Jul 1, 1997: Final draft of goals document Final draft of DB requirements document Revision of policy document Revision of administrative structure document Revision of database exchange format document Dec 31, 1997: Final draft of policy document Final draft of administrative structure document Final draft of database exchange format document From owner-ire Tue Aug 27 12:20:04 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id MAA10643 for ire-outgoing; Tue, 27 Aug 1996 12:20:04 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id MAA10638 for ; Tue, 27 Aug 1996 12:19:57 +0900 (JST) Received: by dragon.jp.apnic.net; id MAA15625; Tue, 27 Aug 1996 12:10:27 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma015623; Tue, 27 Aug 96 12:10:10 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id MAA12432 for ; Tue, 27 Aug 1996 12:17:29 +0900 (JST) Message-Id: <199608270317.MAA12432@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: ire@apnic.net Subject: a simple question... Date: Tue, 27 Aug 1996 12:17:29 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Hi, Is Internet address space a scarce resource that should be conserved? Thanks, -drc From owner-ire Tue Aug 27 12:54:07 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id MAA10858 for ire-outgoing; Tue, 27 Aug 1996 12:54:07 +0900 (JST) Received: from smtp1.interramp.com (smtp1.interramp.com [38.8.45.2]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id MAA10852; Tue, 27 Aug 1996 12:54:00 +0900 (JST) Received: from kb2blxHome by smtp1.interramp.com (8.6.12/SMI-4.1.3-PSI-irsmtp) id XAA09859; Mon, 26 Aug 1996 23:56:58 -0400 Message-ID: <3222720C.4AE0@interramp.com> Date: Mon, 26 Aug 1996 23:57:00 -0400 From: Ted Wolf Jr Reply-To: ted@usa.net Organization: Dun & Bradstreet Information Services NA X-Mailer: Mozilla 3.0b6Gold (WinNT; I) MIME-Version: 1.0 To: "David R. Conrad" CC: ire@apnic.net Subject: Re: a simple question... References: <199608270317.MAA12432@moonsky.jp.apnic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk David R. Conrad wrote: > > Hi, > > Is Internet address space a scarce resource that should be conserved? > > Thanks, > -drc I would put it that the remaining space needs to be managed not conserved. I would hope that we all want to see growth continue, not being held up by conserving space "for a better future use". To some degree this implies that we need to more closely look at whta has been issued todate for its efecient use. Ted Wolf Jr From owner-ire Tue Aug 27 13:33:26 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id NAA11099 for ire-outgoing; Tue, 27 Aug 1996 13:33:26 +0900 (JST) Received: from seeker.ar.com (host2.ar.com [166.90.205.35]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id NAA11091; Tue, 27 Aug 1996 13:33:23 +0900 (JST) Received: (from wessorh@localhost) by seeker.ar.com (8.7.5/8.7.3) id VAA03003; Mon, 26 Aug 1996 21:36:09 -0700 (PDT) From: "Rick H. Wesson" Message-Id: <9608262136.ZM3001@seeker.ar.com.> Date: Mon, 26 Aug 1996 21:36:08 -0700 In-Reply-To: "David R. Conrad" "a simple question..." (Aug 27, 12:17pm) References: <199608270317.MAA12432@moonsky.jp.apnic.net> X-Mailer: Z-Mail (3.2.1 10oct95) To: "David R. Conrad" , ire@apnic.net Subject: Re: a simple question... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ire@apnic.net Precedence: bulk On Aug 27, 12:17pm, David R. Conrad wrote: > Subject: a simple question... > Hi, > > Is Internet address space a scarce resource that should be conserved? It is not so much the address 'space' but the available memory in core internet routers. If there are 42K routes and I have 5 BGP sessions (peers) I need a router with 128Meg of memory. If I want to do more perring or add more routes I will need more memory. If the InterNic doles out more CIDER (routes) blocks I need more memory. I dont know what a Cisco 7513 tops out in memory but I think it is close to 128Meg. -Rick -- Rick H. Wesson From owner-ire Tue Aug 27 14:20:32 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA11518 for ire-outgoing; Tue, 27 Aug 1996 14:20:32 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id OAA11513; Tue, 27 Aug 1996 14:20:27 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id BAA21456; Tue, 27 Aug 1996 01:21:37 -0400 (EDT) Message-Id: <199608270521.BAA21456@brookfield.ans.net> To: "David R. Conrad" cc: ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 12:17:29 +0900." <199608270317.MAA12432@moonsky.jp.apnic.net> Date: Tue, 27 Aug 1996 01:21:37 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608270317.MAA12432@moonsky.jp.apnic.net>, "David R. Conrad" writ es: > Hi, > > Is Internet address space a scarce resource that should be conserved? > > Thanks, > -drc Souds to me like a loaded question. Or maybe I'm just anticipating the worst. IMHO Current conservation measures have been working, though less than perfectly, well enough to avert anything remotely resembling a true shortage. We are dealing with a finite resource though and if we were to abandon those measures (ie: stuff like tight CIDR allocation and aggregation) then we'd be headed toward a shortage much sooner. Perhaps a good question is "How can we further improve the situation without creating artificial panic, causing undue hardship or unfair conditions for users or smaller organizations, or engaging in practices that undermine the growth or usefullness of the Internet?" Can you answer that for us David? Curtis ps - Or shall we invent a crisis as an excuse to change everything? Haven't done that since the ROAD group called for a switch to OSI. From owner-ire Tue Aug 27 14:47:31 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA11700 for ire-outgoing; Tue, 27 Aug 1996 14:47:31 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id OAA11695; Tue, 27 Aug 1996 14:47:22 +0900 (JST) Received: by dragon.jp.apnic.net; id OAA16415; Tue, 27 Aug 1996 14:37:58 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma016411; Tue, 27 Aug 96 14:37:56 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id OAA13033; Tue, 27 Aug 1996 14:45:16 +0900 (JST) Message-Id: <199608270545.OAA13033@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: curtis@ans.net cc: "David R. Conrad" , ire@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 01:21:37 -0400." <199608270521.BAA21456@brookfield.ans.net> Date: Tue, 27 Aug 1996 14:45:15 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Curtis, >> Is Internet address space a scarce resource that should be conserved? >Souds to me like a loaded question. Or maybe I'm just anticipating >the worst. Getting cynical in your old age, eh Curtis? :-). Actually, it wasn't a loaded question at all -- I am simply trying to get a feeling for the perceptions of other people with respect to address space conservation efforts. Working in a registry tends to give one a biased viewpoint. >IMHO Current conservation measures have been working, though less than >perfectly, well enough to avert anything remotely resembling a true >shortage. Agreed, however my concern is that what I feel are the underlying assumptions that the current measures use, namely trust and "enlightened self-interest", seem (from my perspective as a person who deals with address requests daily) to be breaking down under the onslaught of increased concern over routing system load and competition among providers. >We are dealing with a finite resource though and if we were >to abandon those measures (ie: stuff like tight CIDR allocation and >aggregation) then we'd be headed toward a shortage much sooner. True, however it has been noted by several people in various forums that address conservation tends to adversely affect routing space conservation. >Perhaps a good question is "How can we further improve the situation >without creating artificial panic, causing undue hardship or unfair >conditions for users or smaller organizations, or engaging in >practices that undermine the growth or usefullness of the Internet?" Probably best to first define what "the situation" is. >Can you answer that for us David? Nope -- that's why I've asked to have IRE created. >ps - Or shall we invent a crisis as an excuse to change everything? >Haven't done that since the ROAD group called for a switch to OSI. While I personally would not recommend such an approach, I would note that crises do tend to result in something being done about a problem rather than people just talking about various possible solutions... :-) Regards, -drc From owner-ire Tue Aug 27 14:49:43 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA11729 for ire-outgoing; Tue, 27 Aug 1996 14:49:43 +0900 (JST) Received: from doorstep.unety.net ([206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id OAA11719; Tue, 27 Aug 1996 14:49:26 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id AAA10504; Tue, 27 Aug 1996 00:42:03 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB93B1.94C2A7E0@webster.unety.net>; Tue, 27 Aug 1996 00:49:19 -0500 Message-ID: <01BB93B1.94C2A7E0@webster.unety.net> From: Jim Fleming To: "'David R. Conrad'" , "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 00:49:18 -0500 Encoding: 25 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Monday, August 26, 1996 10:17 PM, David R. Conrad[SMTP:davidc@apnic.net] wrote: @ Hi, @ @ Is Internet address space a scarce resource that should be conserved? @ @ Thanks, @ -drc @ @ Are you asking about... IPv4 IPv6 or IPv8 ...??? -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Tue Aug 27 14:54:09 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA11770 for ire-outgoing; Tue, 27 Aug 1996 14:54:09 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id OAA11760; Tue, 27 Aug 1996 14:53:15 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id BAA21646; Tue, 27 Aug 1996 01:53:58 -0400 (EDT) Message-Id: <199608270553.BAA21646@brookfield.ans.net> To: "Rick H. Wesson" cc: "David R. Conrad" , ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Mon, 26 Aug 1996 21:36:08 PDT." <9608262136.ZM3001@seeker.ar.com.> Date: Tue, 27 Aug 1996 01:53:58 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <9608262136.ZM3001@seeker.ar.com.>, "Rick H. Wesson" writes: > On Aug 27, 12:17pm, David R. Conrad wrote: > > Subject: a simple question... > > Hi, > > > > Is Internet address space a scarce resource that should be conserved? > > It is not so much the address 'space' but the available memory > in core internet routers. If there are 42K routes and I have 5 > BGP sessions (peers) I need a router with 128Meg of memory. If I > want to do more perring or add more routes I will need more memory. > If the InterNic doles out more CIDER (routes) blocks I need more memory. This is not so if providers do a good job of aggregation. Its up to the registries to allocate well at the toplevel. Larger providers can also either shoot themselves in the foot by allocating haphazardly within their own topology or allocate chunks to regions or major POPs. Providers can also be either a burden on the global Internet by aggregating poorly or be a good citizen by aggregating very well. > I dont know what a Cisco 7513 tops out in memory but I think it is > close to 128Meg. > > -Rick Unless I'm mistaken 42K and 5 peers is doable in 64MB. (And CIDR has no "E"). :-) Curtis ps - just joining in - what's this group doing beside this light chat? Perhaps someone could point me to a charter and archives? From owner-ire Tue Aug 27 15:10:19 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA11899 for ire-outgoing; Tue, 27 Aug 1996 15:10:19 +0900 (JST) Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id PAA11893; Tue, 27 Aug 1996 15:10:14 +0900 (JST) Received: (from gih@localhost) by nico.aarnet.edu.au (8.6.10/8.6.10) id QAA06194; Tue, 27 Aug 1996 16:11:50 +1000 Date: Tue, 27 Aug 1996 16:11:50 +1000 From: Geoff Huston Message-Id: <199608270611.QAA06194@nico.aarnet.edu.au> To: ire@apnic.net, davidc@apnic.net Subject: Re: a simple question... Sender: owner-ire@apnic.net Precedence: bulk To quote from a few CIDRD meetings ago: - processor cycles in non-default routers is a scarce resource today. - classless routing environments are not scarce, but nowhere near as abundant as current circumstances would dictate. - the size of the unallocated address space pool is not a bottleneck problem today - the absolute size of the address routing tables is not a bottleneck problem today I think I'm really saying a qualified "NO"in response to your question in all that. but why are you posing the question? Geoff >From owner-ire@apnic.net Tue Aug 27 13:25:10 1996 >X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs >To: ire@apnic.net >Subject: a simple question... >Date: Tue, 27 Aug 1996 12:17:29 +0900 >From: "David R. Conrad" > >Hi, > >Is Internet address space a scarce resource that should be conserved? > >Thanks, >-drc > From owner-ire Tue Aug 27 15:12:19 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA11944 for ire-outgoing; Tue, 27 Aug 1996 15:12:19 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id PAA11938 for ; Tue, 27 Aug 1996 15:12:02 +0900 (JST) Received: by dragon.jp.apnic.net; id PAA16619; Tue, 27 Aug 1996 15:02:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma016615; Tue, 27 Aug 96 15:02:01 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id PAA13254; Tue, 27 Aug 1996 15:09:21 +0900 (JST) Message-Id: <199608270609.PAA13254@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: curtis@ans.net cc: ire@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 01:53:58 -0400." <199608270553.BAA21646@brookfield.ans.net> Date: Tue, 27 Aug 1996 15:09:21 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Curtis, >Larger providers can >also either shoot themselves in the foot by allocating haphazardly >within their own topology or allocate chunks to regions or major POPs. This points out an area where current registry policies conflict with provider's interests -- current policies state that address space is not allocated for "administrative convenience" which chunks allocated to regions would likely be interpreted as (which also points out what I see as another problem, namely subjectivity on the part of the registries). >ps - just joining in - what's this group doing beside this light chat? Consider this the calm before the storm... :-) >Perhaps someone could point me to a charter and archives? See below. Suggestions/comments/etc on the draft charter are (more than) welcome. In particular, suggestions for co-chair(s) would be deeply appreciated. It have had two suggestions to date: a) co-chairs should be Kim Hubbard of InterNIC and Daniel Karrenberg of RIPE-NCC, thereby representing all 3 regional registries b) co-chair should be a non-registry person (but no one was suggested). What do people think? (Note that I'd be willing to give up my self-nomination for co-chair if this is felt inappropriate or if someone else feels strongly on this issue). Thanks, -drc ------- To: ire@apnic.net cc: cidrd@iepg.org Subject: *draft* IRE charter Date: Mon, 19 Aug 1996 18:25:00 +0900 From: "David R. Conrad" Hi, I received quite a few suggestions of content and requests for a draft of the IRE-WG charter. I've included the draft incorporating some of those suggestions below and instead of replying individually to all requestor/suggestors and then trying to merge all the subsequent changes, I figured a better way would be to throw it out and see what happens. Note that the dates in the goals/milestones section were scientifically chosen using a dartboard. Please send comments/flames/etc. to ire@apnic.net. I've included cidrd@iepg.org on the cc as I was requested to by several people, however I don't think it is an appropriate forum as its a zombie (I'm reminded of the "Bring out yer dead" scene of Monty Python's Holy Grail). I've mucked up the reply-to line just to annoy people into changing the address for followup. Regards, -drc -------- Draft Charter ------------- Internet Registry Evolution --------------------------- Charter Current status: Chairs: David Conrad Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Mailing lists: General Discussion:ire@apnic.net To Subscribe: ire-request@apnic.net Archive: ftp://ftp.apnic.net/mailing-lists/ire Description of Working Group: IRE will focus on the future direction the Internet Registry system should take. There will be four major thrusts of IRE, namely: - creation of a document defining the Internet registry goals, specifically what role(s) the Internet registry system should be performing, can perform, and what functions are best performed by other organizations. - creation of a document which will be used as a skeleton for future Internet registry policies, particularly those to be used in dealing with increasing IPv4 scarcity and commercialization. - creation of a document detailing the administrative structure of the Internet registry system. - development of documents describing architecture and protocols of the next generation Internet registry database system capable of supporting the registration and querying and updating of all types of registry database objects for IPv4 objects including (but not limited to) IPv4 addresses, AS numbers, domain names, authentication objects, routing objects, and contact information, across multiple geographically distributed databases. Depending on developments with respect to IPv6 addressing, IRE may document an architecture for registration of IPv6 related objects where they differ from IPv4 objects. With respect to the last objective, liaison with existing WHOIS related database working groups (RWHOIS, WHOIS++, etc) and incorporation of technologies developed in those working groups is assumed. It is expected that all four objectives of the IRE working group will result in documents which will be used in the operational functions of the Internet Registry system. Goals and Milestones: Dec 31, 1996: First draft of registry goals document First draft of database requirements document Apr 1, 1997: Revision of goals document Revision of DB requirements document First draft of policy document First draft of administrative structure document First draft of database exchange format document Jul 1, 1997: Final draft of goals document Final draft of DB requirements document Revision of policy document Revision of administrative structure document Revision of database exchange format document Dec 31, 1997: Final draft of policy document Final draft of administrative structure document Final draft of database exchange format document From owner-ire Tue Aug 27 15:13:57 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA11975 for ire-outgoing; Tue, 27 Aug 1996 15:13:57 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id PAA11969; Tue, 27 Aug 1996 15:13:52 +0900 (JST) Received: by dragon.jp.apnic.net; id PAA16647; Tue, 27 Aug 1996 15:04:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma016639; Tue, 27 Aug 96 15:03:57 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id PAA13292; Tue, 27 Aug 1996 15:11:17 +0900 (JST) Message-Id: <199608270611.PAA13292@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Jim Fleming cc: "'David R. Conrad'" , "ire@apnic.net" Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 00:49:18 EST." <01BB93B1.94C2A7E0@webster.unety.net> Date: Tue, 27 Aug 1996 15:11:17 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Jim, >Are you asking about... > >IPv4 >IPv6 >or >IPv8 IPv4 and, only if necessary, IPv6. Regards, -drc From owner-ire Tue Aug 27 15:18:27 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA12055 for ire-outgoing; Tue, 27 Aug 1996 15:18:27 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id PAA12045; Tue, 27 Aug 1996 15:18:21 +0900 (JST) Received: by dragon.jp.apnic.net; id PAA16699; Tue, 27 Aug 1996 15:08:58 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma016695; Tue, 27 Aug 96 15:08:56 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id PAA13339; Tue, 27 Aug 1996 15:16:11 +0900 (JST) Message-Id: <199608270616.PAA13339@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Geoff Huston cc: ire@apnic.net, davidc@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 16:11:50 +1000." <199608270611.QAA06194@nico.aarnet.edu.au> Date: Tue, 27 Aug 1996 15:16:11 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Geoff, >>Is Internet address space a scarce resource that should be conserved? >I think I'm really saying a qualified "NO" in response to your >question in all that. > >but why are you posing the question? The current registry guidelines list conservation of address space as a specific goal. Working in a registry tends to give you a particular point of view. Consider this a reality check of sorts... Regards, -drc From owner-ire Tue Aug 27 15:23:04 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA12103 for ire-outgoing; Tue, 27 Aug 1996 15:23:04 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id PAA12097 for ; Tue, 27 Aug 1996 15:22:57 +0900 (JST) Received: by dragon.jp.apnic.net; id PAA16745; Tue, 27 Aug 1996 15:13:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma016741; Tue, 27 Aug 96 15:13:23 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id PAA13440; Tue, 27 Aug 1996 15:20:39 +0900 (JST) Message-Id: <199608270620.PAA13440@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: ted@usa.net cc: ire@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Mon, 26 Aug 1996 23:57:00 -0400." <3222720C.4AE0@interramp.com> Date: Tue, 27 Aug 1996 15:20:39 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Ted, > I would put it that the remaining space needs to be managed not >conserved. Please explain the difference. >To some >degree this implies that we need to more closely look at whta has been >issued todate for its efecient use. How does one determine whether address space is used efficiently? Thanks, -drc From owner-ire Tue Aug 27 15:39:16 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA12278 for ire-outgoing; Tue, 27 Aug 1996 15:39:16 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id PAA12273; Tue, 27 Aug 1996 15:39:11 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id CAA23527; Tue, 27 Aug 1996 02:40:23 -0400 (EDT) Message-Id: <199608270640.CAA23527@brookfield.ans.net> To: "David R. Conrad" cc: curtis@ans.net, ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 14:45:15 +0900." <199608270545.OAA13033@moonsky.jp.apnic.net> Date: Tue, 27 Aug 1996 02:40:23 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608270545.OAA13033@moonsky.jp.apnic.net>, "David R. Conrad" writ es: > > Agreed, however my concern is that what I feel are the underlying > assumptions that the current measures use, namely trust and > "enlightened self-interest", seem (from my perspective as a person who > deals with address requests daily) to be breaking down under the > onslaught of increased concern over routing system load and > competition among providers. Lets get down to reality here. The registries are doing their jobs in allocating responsibly at the top levels. The major Internet service providers, and I'll include ANS here too, have not been aggregating very well and have created an environment in which allocation outside of a topologic block is not an unreasonable thing to do from a standpoint of pure self interest. The latter situation (the desire for independent numbers) has been fueled by the renumbering fiasco in CIDR that started as address lending. One problem has been just plain failure to aggregate. Another has been a strict enforcement by some intended to keep CIDR blocks intact without provisions for a renumbering grace period. If thisd didn't occur, you'd get less requests for provider independent addresses (and therefore far less direct requests). > >We are dealing with a finite resource though and if we were > >to abandon those measures (ie: stuff like tight CIDR allocation and > >aggregation) then we'd be headed toward a shortage much sooner. > > True, however it has been noted by several people in various forums > that address conservation tends to adversely affect routing space > conservation. I disagree. We've only fairly recently started to implement new procesdures for internal allocation as a provider with an older /16, a /13 and new /14. Our new allocations are very well aggregated, with that /14 broken into /19-/21 per POP, chunks of /24 per POP reserved for DMZs (as needed) for customers willing to use RFC1957 space and the whole thing aggregated back to /14 to the outside world. The newest one only has 2 more specific for dual homed customers. We now have someone working on getting our older address space aggregated. The way we do things is to confirm thing with customers so this is largely a matter of doing our homework and then customer contact logistics. We want to encourage customers numbered in the swamp to renumber into an aggregate to improve their own connectivity since aggregates flap much less and get dampenned much less than swamp /24s. We haven't started shooting notes off to customers. Of course, renumbering is being suggested, not force upon anyone. > >Perhaps a good question is "How can we further improve the situation > >without creating artificial panic, causing undue hardship or unfair > >conditions for users or smaller organizations, or engaging in > >practices that undermine the growth or usefullness of the Internet?" > > Probably best to first define what "the situation" is. I suppose we're starting to do this. > >Can you answer that for us David? > > Nope -- that's why I've asked to have IRE created. Oh... You mean this isn't my virtual encounter group. I gotta check the Cc more carefully. ;-) Curtis From owner-ire Tue Aug 27 16:12:44 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id QAA12591 for ire-outgoing; Tue, 27 Aug 1996 16:12:44 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id QAA12586 for ; Tue, 27 Aug 1996 16:12:29 +0900 (JST) Received: by dragon.jp.apnic.net; id QAA17117; Tue, 27 Aug 1996 16:02:58 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma017113; Tue, 27 Aug 96 16:02:48 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id QAA13841; Tue, 27 Aug 1996 16:10:08 +0900 (JST) Message-Id: <199608270710.QAA13841@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: curtis@ans.net cc: ire@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 02:40:23 -0400." <199608270640.CAA23527@brookfield.ans.net> Date: Tue, 27 Aug 1996 16:10:08 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Curtis, >One problem has been just plain failure to aggregate. Another has >been a strict enforcement by some intended to keep CIDR blocks intact >without provisions for a renumbering grace period. If thisd didn't >occur, you'd get less requests for provider independent addresses (and >therefore far less direct requests). Regardless of why we are where we are, the current situation is that "provider independent" addresses are considered more desirable than "provider aggregatable" addresses. As a result, the registries receive a significant number of requests for PI space, which if the requestor insists, the registry policy (as defined in RFC 1814) is to allocate. Further, *if* Internet address space is considered a scarce resource, high school economics would seem to encourage people to obtain "their own" addresses as address "value" would tend to increase as the remaining free pool is depleted. >> True, however it has been noted by several people in various forums >> that address conservation tends to adversely affect routing space >> conservation. >I disagree. [heartening discussion of ANS's efforts to reduce routing entries] My statement was based on the observation that the smaller the block, the more likely it is to be used efficiently in terms of address conservation (down to assigning discontiguous "blocks" of /32s for justified interfaces) whereas for router table efficiency, the larger the block the more addresses can be aggregated. While ANS should be congradulated for its efforts at reducing the number of routing entries it generates, I would note that if ANS were able to obtain the block that covers all its routing entires regardless of address space utilization or justifying it to the registries, it would only announce one route (barring multi-homes). Regards, -drc From owner-ire Tue Aug 27 16:52:42 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id QAA12927 for ire-outgoing; Tue, 27 Aug 1996 16:52:42 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id QAA12922; Tue, 27 Aug 1996 16:52:40 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id DAA23565; Tue, 27 Aug 1996 03:55:36 -0400 (EDT) Date: Tue, 27 Aug 1996 03:55:36 -0400 (EDT) From: "Dorian R. Kim" To: Curtis Villamizar cc: "David R. Conrad" , ire@apnic.net Subject: Re: a simple question... In-Reply-To: <199608270640.CAA23527@brookfield.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ire@apnic.net Precedence: bulk On Tue, 27 Aug 1996, Curtis Villamizar wrote: > In message <199608270545.OAA13033@moonsky.jp.apnic.net>, "David R. Conrad" writ > es: > been a strict enforcement by some intended to keep CIDR blocks intact > without provisions for a renumbering grace period. If thisd didn't > occur, you'd get less requests for provider independent addresses (and > therefore far less direct requests). Curtis, IMO, I don't think even universal application of reasonable renumbering grace periods will make much dent in requests for provider independent addresses. In my experience, there are two kinds of folks who go to the Internic for provider independent addresses. 1) Folks who don't like the fact that we ask them to justify their address requests, and will give only what they can justify. Mind you that all we are asking folks to justify is planned address utilization according to guidelines set in Hubbard draft before we assign addresses. 2) Folks who think that any kind of renumbering is unacceptable, no matter how reasonable the grace period. (we've given sites over 12 months to renumber on various occasions) I don't think either one of these folks stop asking for provider independent addresses because of renumbeing grace periods. -dorian From owner-ire Tue Aug 27 17:14:06 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id RAA13101 for ire-outgoing; Tue, 27 Aug 1996 17:14:06 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id RAA13096; Tue, 27 Aug 1996 17:14:02 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id EAA23862; Tue, 27 Aug 1996 04:15:15 -0400 (EDT) Message-Id: <199608270815.EAA23862@brookfield.ans.net> To: "David R. Conrad" cc: curtis@ans.net, ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 15:09:21 +0900." <199608270609.PAA13254@moonsky.jp.apnic.net> Date: Tue, 27 Aug 1996 04:15:15 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608270609.PAA13254@moonsky.jp.apnic.net>, "David R. Conrad" writ es: > Curtis, > > >Larger providers can > >also either shoot themselves in the foot by allocating haphazardly > >within their own topology or allocate chunks to regions or major POPs. > > This points out an area where current registry policies conflict with > provider's interests -- current policies state that address space is > not allocated for "administrative convenience" which chunks allocated > to regions would likely be interpreted as (which also points out what > I see as another problem, namely subjectivity on the part of the > registries). The chunks should not be allocated for "administrative convenience" but according to where the space is needed. The space still has to end up quite densely filled. We've allocated and then decided a city didn't grow as fast as we thought, so we took the top half and gave it to another city and given larger allocations to larger cities and still had to allocate second blocks when the first filled completely. This is so your (very large) network is carrying mostly /19s through /21s internally, not /24s through /28s, and of course advertising /13-/16 externally. What I'm saying is it is just as stupid for a provider to allocate the next sequential /24 to the next small customer needing a /24 is it is for registries to allocate without consideration for topology and for binary number boundaries. > >ps - just joining in - what's this group doing beside this light chat? > > Consider this the calm before the storm... :-) :-) > >Perhaps someone could point me to a charter and archives? > > See below. Suggestions/comments/etc on the draft charter are (more > than) welcome. In particular, suggestions for co-chair(s) would be > deeply appreciated. It have had two suggestions to date: If I think of anyone who has the time I'll let you know. :-) The charter looks good. Curtis > - creation of a document defining the Internet registry goals, > specifically what role(s) the Internet registry system should be > performing, can perform, and what functions are best performed by > other organizations. Scope the job first. Good idea. > - creation of a document which will be used as a skeleton for future > Internet registry policies, particularly those to be used in dealing > with increasing IPv4 scarcity and commercialization. This seems to be the heart of the work. > - creation of a document detailing the administrative structure of > the Internet registry system. I don't see why this is needed. > - development of documents describing architecture and protocols of > the next generation Internet registry database system capable of > supporting the registration and querying and updating of all types > of registry database objects for IPv4 objects including (but not > limited to) IPv4 addresses, AS numbers, domain names, authentication > objects, routing objects, and contact information, across multiple > geographically distributed databases. Depending on developments > with respect to IPv6 addressing, IRE may document an architecture > for registration of IPv6 related objects where they differ from IPv4 > objects. Any thoughts on coordinating this activity with RPSL activity? After all, the RIPE database serves as both address assignment and routing database. A minimal coupling would allow an RPSL database to authenticate requestsd based on the registry allocation. > With respect to the last objective, liaison with existing WHOIS > related database working groups (RWHOIS, WHOIS++, etc) and > incorporation of technologies developed in those working groups is > assumed. Why just WHOIS? From owner-ire Tue Aug 27 17:40:01 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id RAA13294 for ire-outgoing; Tue, 27 Aug 1996 17:40:01 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id RAA13287 for ; Tue, 27 Aug 1996 17:39:52 +0900 (JST) Received: by dragon.jp.apnic.net; id RAA17640; Tue, 27 Aug 1996 17:30:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma017635; Tue, 27 Aug 96 17:30:20 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id RAA14419; Tue, 27 Aug 1996 17:37:40 +0900 (JST) Message-Id: <199608270837.RAA14419@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: curtis@ans.net cc: ire@apnic.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 04:15:15 -0400." <199608270815.EAA23862@brookfield.ans.net> Date: Tue, 27 Aug 1996 17:37:40 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Curtis, >The chunks should not be allocated for "administrative convenience" >but according to where the space is needed. How is a registry supposed to know *objectively* what is "needed"? >The space still has to end up quite densely filled. How is the registry supposed to *objectively* determine the space is densely filled? >We've allocated and then decided a city didn't grow as fast as we >thought, so we took the top half and gave it to another city and given >larger allocations to larger cities and still had to allocate second >blocks when the first filled completely. You (ANS) have the distinct advantage that you had a block large enough to take half and give to another city. For ISPs that are now starting out under the constraints of slow-start, it is unlikely they would have the address space to do this. In order for them to do so, they would likely need to convince their registry their plans were justifiable and not just attempting to make things easier for themselves. This requires both extensive documentation on the part of the requestor as well as a subjective analysis on the part of the registry. Slow start is, at least from my perspective, one of the more successful registry policies, but it does have drawbacks and situations such as this illustrate. >> - creation of a document defining the Internet registry goals, >> specifically what role(s) the Internet registry system should be >> performing, can perform, and what functions are best performed by >> other organizations. >Scope the job first. Good idea. Consider the original question as the first tentative step in this direction. >> - creation of a document which will be used as a skeleton for future >> Internet registry policies, particularly those to be used in dealing >> with increasing IPv4 scarcity and commercialization. >This seems to be the heart of the work. >> - creation of a document detailing the administrative structure of >> the Internet registry system. >I don't see why this is needed. I felt it would help answer questions of "authority" and appeal that will almost assuredly result from the definition of the policies referenced in the preceding bullet. >Any thoughts on coordinating this activity with RPSL activity? Hadn't considered it, but it would seem to make sense to loosely couple the two as you mention. >> With respect to the last objective, liaison with existing WHOIS >> related database working groups (RWHOIS, WHOIS++, etc) and >> incorporation of technologies developed in those working groups is >> assumed. >Why just WHOIS? Shorthand for "registry" that probably gives the wrong impression, how about: With respect to the last objective, liaison with existing registry related database working groups (RWHOIS, WHOIS++, RPSL, RIPE DB-WG, etc) and incorporation of technologies developed in those working groups is assumed. Thanks, -drc From owner-ire Tue Aug 27 21:56:06 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id VAA15538 for ire-outgoing; Tue, 27 Aug 1996 21:56:06 +0900 (JST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id VAA15533; Tue, 27 Aug 1996 21:56:03 +0900 (JST) From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 27 Aug 1996 05:59:04 -0700 Posted-Date: Tue, 27 Aug 1996 05:57:32 -0700 (PDT) Message-Id: <199608271257.AA26933@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 27 Aug 1996 05:57:32 -0700 Subject: Re: a simple question... To: davidc@apnic.net (David R. Conrad) Date: Tue, 27 Aug 1996 05:57:32 -0700 (PDT) Cc: ire@apnic.net In-Reply-To: <199608270317.MAA12432@moonsky.jp.apnic.net> from "David R. Conrad" at Aug 27, 96 12:17:29 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > > Hi, > > Is Internet address space a scarce resource that should be conserved? > > Thanks, > -drc > Drop "scarce" and I agree. -- --bill From owner-ire Tue Aug 27 22:41:35 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id WAA16086 for ire-outgoing; Tue, 27 Aug 1996 22:41:35 +0900 (JST) Received: from jazz.internic.net (jazz.internic.net [198.41.0.134]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id WAA16081; Tue, 27 Aug 1996 22:41:32 +0900 (JST) Received: (kimh@localhost) by jazz.internic.net (8.7.4/SLAM-1) id JAA01244; Tue, 27 Aug 1996 09:49:03 -0400 (EDT) From: Kim Hubbard Message-Id: <199608271349.JAA01244@jazz.internic.net> Subject: Re: a simple question... To: davidc@apnic.net (David R. Conrad) Date: Tue, 27 Aug 1996 09:49:03 -0400 (EDT) Cc: curtis@ans.net, ire@apnic.net In-Reply-To: <199608270609.PAA13254@moonsky.jp.apnic.net> from "David R. Conrad" at Aug 27, 96 03:09:21 pm X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > David, > > >Larger providers can > >also either shoot themselves in the foot by allocating haphazardly > >within their own topology or allocate chunks to regions or major POPs. > > This points out an area where current registry policies conflict with > provider's interests -- current policies state that address space is > not allocated for "administrative convenience" which chunks allocated > to regions would likely be interpreted as (which also points out what > I see as another problem, namely subjectivity on the part of the > registries). The InterNIC does not view the addresses allocated to regions as administrative ease. Many of the ISPs that deal with the InterNIC use the address space in this fashion. The point is to make sure the address space is used efficiently once it's distributed. If (as Curtis said) one or more cities is not using the address space than part of that block is moved to a city that needs it. The smaller ISPs can do this also, they just use smaller blocks until they have a requirement to put the /19s or /20s at their POPs. > > >ps - just joining in - what's this group doing beside this light chat? > > Consider this the calm before the storm... :-) > > >Perhaps someone could point me to a charter and archives? > > See below. Suggestions/comments/etc on the draft charter are (more > than) welcome. In particular, suggestions for co-chair(s) would be > deeply appreciated. It have had two suggestions to date: > > a) co-chairs should be Kim Hubbard of InterNIC and Daniel > Karrenberg of RIPE-NCC, thereby representing all 3 regional > registries Actually, a non-registry chair should be included in option a) also. Kim > > b) co-chair should be a non-registry person (but no one was > suggested). > > What do people think? (Note that I'd be willing to give up my > self-nomination for co-chair if this is felt inappropriate or if > someone else feels strongly on this issue). > > Thanks, > -drc > ------- > To: ire@apnic.net > cc: cidrd@iepg.org > Subject: *draft* IRE charter > Date: Mon, 19 Aug 1996 18:25:00 +0900 > From: "David R. Conrad" > > Hi, > > I received quite a few suggestions of content and requests for a draft > of the IRE-WG charter. I've included the draft incorporating some of > those suggestions below and instead of replying individually to all > requestor/suggestors and then trying to merge all the subsequent > changes, I figured a better way would be to throw it out and see what > happens. Note that the dates in the goals/milestones section were > scientifically chosen using a dartboard. > > Please send comments/flames/etc. to ire@apnic.net. I've included > cidrd@iepg.org on the cc as I was requested to by several people, > however I don't think it is an appropriate forum as its a zombie (I'm > reminded of the "Bring out yer dead" scene of Monty Python's Holy > Grail). I've mucked up the reply-to line just to annoy people into > changing the address for followup. > > Regards, > -drc > -------- > > Draft Charter > ------------- > > Internet Registry Evolution > --------------------------- > > Charter > > Current status: > > Chairs: > David Conrad > > > > Operational Requirements Area Director(s): > Scott Bradner > Michael O'Dell > > Mailing lists: > General Discussion:ire@apnic.net > To Subscribe: ire-request@apnic.net > Archive: ftp://ftp.apnic.net/mailing-lists/ire > > Description of Working Group: > > IRE will focus on the future direction the Internet Registry system > should take. There will be four major thrusts of IRE, namely: > > - creation of a document defining the Internet registry goals, > specifically what role(s) the Internet registry system should be > performing, can perform, and what functions are best performed by > other organizations. > > - creation of a document which will be used as a skeleton for future > Internet registry policies, particularly those to be used in dealing > with increasing IPv4 scarcity and commercialization. > > - creation of a document detailing the administrative structure of > the Internet registry system. > > - development of documents describing architecture and protocols of > the next generation Internet registry database system capable of > supporting the registration and querying and updating of all types > of registry database objects for IPv4 objects including (but not > limited to) IPv4 addresses, AS numbers, domain names, authentication > objects, routing objects, and contact information, across multiple > geographically distributed databases. Depending on developments > with respect to IPv6 addressing, IRE may document an architecture > for registration of IPv6 related objects where they differ from IPv4 > objects. > > With respect to the last objective, liaison with existing WHOIS > related database working groups (RWHOIS, WHOIS++, etc) and > incorporation of technologies developed in those working groups is > assumed. > > It is expected that all four objectives of the IRE working group will > result in documents which will be used in the operational functions of > the Internet Registry system. > > Goals and Milestones: > > Dec 31, 1996: First draft of registry goals document > First draft of database requirements document > > Apr 1, 1997: Revision of goals document > Revision of DB requirements document > First draft of policy document > First draft of administrative structure document > First draft of database exchange format document > > Jul 1, 1997: Final draft of goals document > Final draft of DB requirements document > Revision of policy document > Revision of administrative structure document > Revision of database exchange format document > > Dec 31, 1997: Final draft of policy document > Final draft of administrative structure document > Final draft of database exchange format document > From owner-ire Wed Aug 28 00:57:04 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id AAA17146 for ire-outgoing; Wed, 28 Aug 1996 00:57:04 +0900 (JST) Received: from doorstep.unety.net (root@[206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id AAA17141; Wed, 28 Aug 1996 00:56:59 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id KAA12628; Tue, 27 Aug 1996 10:49:59 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9406.828528A0@webster.unety.net>; Tue, 27 Aug 1996 10:57:16 -0500 Message-ID: <01BB9406.828528A0@webster.unety.net> From: Jim Fleming To: "David R. Conrad" , "'Kim Hubbard'" Cc: "curtis@ans.net" , "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 10:57:14 -0500 Encoding: 52 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 4:49 AM, Kim Hubbard[SMTP:kimh@internic.net] wrote: @ @ The InterNIC does not view the addresses allocated to regions as @ administrative ease. Many of the ISPs that deal with the InterNIC @ use the address space in this fashion. The point is to make sure the @ address space is used efficiently once it's distributed. This is true, the InterNIC does not create "administrative ease", instead the policies it dreams up and enforces cause ISPs administrative headaches. For some reason the InterNIC views the IPv4 address space as the "top" of the heap. IF the InterNIC viewed the IPv4 address space as a very small part of the 128 bit IPv6 space then they might see that a higher authority will eventually pass judgement on how efficiently THEY have used the space. Efficient use of an address space does NOT mean the following... 1. Giving addresses to friends and neighbors 2. Giving addresses to the "right" people 3. Assigning the smallest possible block in sequence to put an ISP in their place 4. Assigning the smallest number of addresses in a calendar year 5. Assigning non-routable addresses to people that complain 6. Making ISPs grovel and beg 7. Lording power over ISPs and making it clear that they will die without IP addresses 8. Fragmenting the address space into as many blocks as possible 9. Investigating ISPs to see how the addresses are used 10. Policies which cause registries to collapse and return authority to the InterNIC In my opinion, efficient use of the address space should include... 1. Assignment policies that are open and fair 2. Assignment policies that anticipate growing needs and aggregation opportunities 3. Active recycling of IP addresses. 4. Assignment policies which minimize router tables 5. Assignment policies which improve packet transport efficiency 5. Delegation policies which encourage MORE registries not less Some day people will look back on the IPv4 address space and realize how poorly it was/is managed. Unfortunately, like many aspects of the computer industry, the people responsible for that management will not likely be around. Hopefully, other efforts like IPv6 and IPv8 will help to provide society with a place to go to escape the mess. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 01:11:27 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17232 for ire-outgoing; Wed, 28 Aug 1996 01:11:27 +0900 (JST) Received: from doorstep.unety.net (root@[206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id BAA17227; Wed, 28 Aug 1996 01:11:21 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA12660; Tue, 27 Aug 1996 11:04:27 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9408.87D12320@webster.unety.net>; Tue, 27 Aug 1996 11:11:44 -0500 Message-ID: <01BB9408.87D12320@webster.unety.net> From: Jim Fleming To: "curtis@ans.net" , "'David R. Conrad'" Cc: "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 11:11:42 -0500 Encoding: 31 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 2:10 AM, David R. Conrad[SMTP:davidc@apnic.net] wrote: @ @ My statement was based on the observation that the smaller the block, @ the more likely it is to be used efficiently in terms of address @ conservation (down to assigning discontiguous "blocks" of /32s for @ justified interfaces) whereas for router table efficiency, the larger @ the block the more addresses can be aggregated. While ANS should be @ congradulated for its efforts at reducing the number of routing @ entries it generates, I would note that if ANS were able to obtain the @ block that covers all its routing entires regardless of address space @ utilization or justifying it to the registries, it would only announce @ one route (barring multi-homes). @ I think that many of these discussions will boil down to how one defines the word "efficient". Small does not mean efficient.... I prefer the term, "balanced delegation and allocation" policies... ...we should be seeking balance... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 01:14:07 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17258 for ire-outgoing; Wed, 28 Aug 1996 01:14:07 +0900 (JST) Received: from doorstep.unety.net (root@[206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id BAA17253; Wed, 28 Aug 1996 01:14:03 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA12677; Tue, 27 Aug 1996 11:07:11 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9408.E9B4A580@webster.unety.net>; Tue, 27 Aug 1996 11:14:28 -0500 Message-ID: <01BB9408.E9B4A580@webster.unety.net> From: Jim Fleming To: "curtis@ans.net" , "'David R. Conrad'" Cc: "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 11:14:27 -0500 Encoding: 25 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 3:37 AM, David R. Conrad[SMTP:davidc@apnic.net] wrote: @ Curtis, @ @ >The chunks should not be allocated for "administrative convenience" @ >but according to where the space is needed. @ @ How is a registry supposed to know *objectively* what is "needed"? @ That is easy...they launch a CIA-like investigation.... @ >The space still has to end up quite densely filled. @ @ How is the registry supposed to *objectively* determine the space is @ densely filled? @ Again...teams of "agents" and investigators...calling, probing, etc... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 01:24:03 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17350 for ire-outgoing; Wed, 28 Aug 1996 01:24:03 +0900 (JST) Received: from doorstep.unety.net (root@[206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id BAA17345; Wed, 28 Aug 1996 01:23:59 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA12695; Tue, 27 Aug 1996 11:17:04 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB940A.4AD9EB80@webster.unety.net>; Tue, 27 Aug 1996 11:24:20 -0500 Message-ID: <01BB940A.4AD9EB80@webster.unety.net> From: Jim Fleming To: "David R. Conrad" Cc: "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 11:24:19 -0500 Encoding: 24 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 3:15 AM, Curtis Villamizar[SMTP:curtis@ans.net] wrote: @ @ @ What I'm saying is it is just as stupid for a provider to allocate the @ next sequential /24 to the next small customer needing a /24 is it is @ for registries to allocate without consideration for topology and for @ binary number boundaries. @ Why does the IANA and InterNIC use sequential methods...? >From an IPv6 (and IPv8) point of view, the entire IPv4 address space is one large block. Should not policies be the same for all delegates that handle blocks...? ...or is this one of those cases where the "experts" get to be wasteful... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 01:31:53 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17412 for ire-outgoing; Wed, 28 Aug 1996 01:31:53 +0900 (JST) Received: from doorstep.unety.net (root@[206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id BAA17407; Wed, 28 Aug 1996 01:31:50 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA12707; Tue, 27 Aug 1996 11:24:37 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB940B.59458520@webster.unety.net>; Tue, 27 Aug 1996 11:31:54 -0500 Message-ID: <01BB940B.59458520@webster.unety.net> From: Jim Fleming To: Curtis Villamizar , "'Dorian R. Kim'" Cc: "David R. Conrad" , "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 11:31:53 -0500 Encoding: 16 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Monday, August 26, 1996 10:55 PM, Dorian R. Kim[SMTP:dorian@cic.net] wrote: @ In my experience, there are two kinds of folks who go to the Internic for @ provider independent addresses. @ In my opinion, it is much simpler...there are "two kinds of folks"... Those that *have* IP addresses...and those that do not have them... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 01:41:07 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17470 for ire-outgoing; Wed, 28 Aug 1996 01:41:07 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id BAA17462; Wed, 28 Aug 1996 01:40:54 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id MAA24743; Tue, 27 Aug 1996 12:41:57 -0400 (EDT) Message-Id: <199608271641.MAA24743@brookfield.ans.net> To: "David R. Conrad" cc: curtis@ans.net, ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 16:10:08 +0900." <199608270710.QAA13841@moonsky.jp.apnic.net> Date: Tue, 27 Aug 1996 12:41:57 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608270710.QAA13841@moonsky.jp.apnic.net>, "David R. Conrad" writ es: > > >One problem has been just plain failure to aggregate. Another has > >been a strict enforcement by some intended to keep CIDR blocks intact > >without provisions for a renumbering grace period. If thisd didn't > >occur, you'd get less requests for provider independent addresses (and > >therefore far less direct requests). > > Regardless of why we are where we are, the current situation is that > "provider independent" addresses are considered more desirable than > "provider aggregatable" addresses. As a result, the registries > receive a significant number of requests for PI space, which if the > requestor insists, the registry policy (as defined in RFC 1814) is to > allocate. This is a matter of educating the public in some cases. For example, very few ANS customers today ask for PI addresses. We tell them the whole spiel about route flap, providers aggresively damping or blocking long prefixes, and offer a very generous grace period should they not like our service and all out leave (never happens:). We encourage them to stay with our CIDR block if dual homed. Its taken a long time for this to message to make its way through the organization, and may not have sunk in everywhere, but I think install engineering has the story and its making its way to sales. In other cases I've heard of providers: 1) offering no renumbering grace period at all, 2) offering an absurdly short token period such as 2 weeks, 3) offering a grace period to renumbering but then failing to configure routers to take the more specific routes and in doing so providing blocking connectivity. If a customer is astute and sees that down the road they may be faced with a situation in which they will have to almost instantly renumber, PI address space looks attractive. These ISPs need to change policies. Perhaps a condition of obtaining further address space, in addition to allocating efficiently and aggregating, could be providing a renumbering grace period and routing correctly during that period. A registry policy to this effect would go a long way toward correcting the situation were PI addresses are attractive to some. I personally think the minimum should be 6 months and 1 year is reasonable. > Further, *if* Internet address space is considered a scarce resource, > high school economics would seem to encourage people to obtain "their > own" addresses as address "value" would tend to increase as the > remaining free pool is depleted. This is under the assumption that PI are irrevokable and provider addresses are revokable. More likely PI will become unroutable and of no value. > >> True, however it has been noted by several people in various forums > >> that address conservation tends to adversely affect routing space > >> conservation. > >I disagree. > [heartening discussion of ANS's efforts to reduce routing entries] :-) > My statement was based on the observation that the smaller the block, > the more likely it is to be used efficiently in terms of address > conservation (down to assigning discontiguous "blocks" of /32s for > justified interfaces) whereas for router table efficiency, the larger > the block the more addresses can be aggregated. While ANS should be > congradulated for its efforts at reducing the number of routing > entries it generates, I would note that if ANS were able to obtain the > block that covers all its routing entires regardless of address space > utilization or justifying it to the registries, it would only announce > one route (barring multi-homes). You need at least a /30 for a serial interface. That's a consequence of how router vendors build things. Renumbering our infrastructure is planned for sometime after we finish building our new backbone. Allocating a /19-/21 seems quite reasonable. A /19 at NY or DC will fill up in a reasonable amount of time. If a /19 or even a /21 is less than half full and shows no sign of becoming half full, our policy is to split it when we need space elsewhere. And we have done numerous splits sich as this in the prefix we used to test this whole set of procedures and the config generation code. Efficient usage of address space is definitely a goal. Our newest allocation is 207.24/14. We announce one prefix plus two more specifics that are multihomed to other providers. We to go back through previous allocations to determine who is dual homed so we can do the same thing. Announcing only one prefix per allocation, except for dual homed prefixes is also a goal. If I can serve any purpose to this WG it might be to dispell any claims that "it can't be done" wrt efficient allocation, efficient aggregation, or granting renumbering grace periods. > Regards, > -drc Curtis From owner-ire Wed Aug 28 01:47:36 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA17520 for ire-outgoing; Wed, 28 Aug 1996 01:47:36 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id BAA17515; Wed, 28 Aug 1996 01:47:31 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id MAA24780; Tue, 27 Aug 1996 12:48:34 -0400 (EDT) Message-Id: <199608271648.MAA24780@brookfield.ans.net> To: "Dorian R. Kim" cc: Curtis Villamizar , "David R. Conrad" , ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 03:55:36 EDT." Date: Tue, 27 Aug 1996 12:48:34 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message , "Dorian R . Kim" writes: > > 2) Folks who think that any kind of renumbering is unacceptable, no matter ho > w > reasonable the grace period. (we've given sites over 12 months to renumber on > various occasions) I think 6 months should be the NIC mandated minimum and 1 year is a reasonable period. I would further advocate ANS granting extensions with justification (for example, a justification might be "we beat up the vendor for the past year and they still won't fix their license server to allow us to move the licenses"). Curtis From owner-ire Wed Aug 28 02:15:20 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id CAA17671 for ire-outgoing; Wed, 28 Aug 1996 02:15:20 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id CAA17656; Wed, 28 Aug 1996 02:14:59 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id NAA24849; Tue, 27 Aug 1996 13:16:10 -0400 (EDT) Message-Id: <199608271716.NAA24849@brookfield.ans.net> To: "David R. Conrad" cc: curtis@ans.net, ire@apnic.net Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 17:37:40 +0900." <199608270837.RAA14419@moonsky.jp.apnic.net> Date: Tue, 27 Aug 1996 13:16:10 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608270837.RAA14419@moonsky.jp.apnic.net>, "David R. Conrad" writ es: > Curtis, > > >The chunks should not be allocated for "administrative convenience" > >but according to where the space is needed. > > How is a registry supposed to know *objectively* what is "needed"? The provider asks for one block. When the provider returns for a second block the registry looks to see 1) how efficiently the first block was allocated, 2) how well it was aggregated, 3) whether there have been complaints about renumbering grace periods or breaking routing for prefixes that dual home or move. To get another allocation, all three need to be satisfied to within some criteria (ie: some minimum efficiency according to block size, some measure of aggregation, elimination of outstanding broken routing complaints). I suppose you could throw in route flap as another criteria. The registry doesn't see the suballocation until its time for another request. Then if there are lots of partially filled blocks resulting in efficiency minimums not being met the request is denied and the blocks less than half full need to be split. Once the prior allocation is sufficiently used a new one can be granted. > >The space still has to end up quite densely filled. > > How is the registry supposed to *objectively* determine the space is > densely filled? Start by asking for internal routing tables from the provider. See what's in them. First clue is large unused stretches of number space. A fudged routing table would be a clear case of fraud. Then ask what crieria providers use to justify suballocations from their block and how they determine how efficiently the allocation is being used. If the answer is "we don't ask, we just give them what they want", reject the next request pending documentation. If the provider can't meet requirements they must go and ask that unused addresses be returned. You can start out with a long delay in the next allocation, requiring the provider to send letters and then granting the allocation if they've made a real effort being stricter on second offense. > >We've allocated and then decided a city didn't grow as fast as we > >thought, so we took the top half and gave it to another city and given > >larger allocations to larger cities and still had to allocate second > >blocks when the first filled completely. > > You (ANS) have the distinct advantage that you had a block large > enough to take half and give to another city. For ISPs that are now > starting out under the constraints of slow-start, it is unlikely they > would have the address space to do this. In order for them to do so, > they would likely need to convince their registry their plans were > justifiable and not just attempting to make things easier for > themselves. This requires both extensive documentation on the part of > the requestor as well as a subjective analysis on the part of the > registry. Slow start is, at least from my perspective, one of the > more successful registry policies, but it does have drawbacks and > situations such as this illustrate. Our allocations are large compared to a startup but they are a small percentage (less than 20%) of the number space we have already been allocated and for the most part quite tightly filled. Previous blocks were mostly sequential allocated internally and so were completely filled. Infrastructure allocations are an exception that we plan to correct renumbering so we can reuse that space. (Anyone want a 140.222 or 140.223 prefix?). Small providers get N times their current size. Large providers get 1/N of our current size. This has been brought up many times before wrt large providers. > >Any thoughts on coordinating this activity with RPSL activity? > > Hadn't considered it, but it would seem to make sense to loosely > couple the two as you mention. Its bothers me that people sometimes take unallocated space and just use it. If they couldn't get it in the IRR, they could use it but a number of providers wouldn't route it. So far the clueless also don't bother to add route objects. > Shorthand for "registry" that probably gives the wrong impression, how > about: > > With respect to the last objective, liaison with existing registry > related database working groups (RWHOIS, WHOIS++, RPSL, RIPE DB-WG, > etc) and incorporation of technologies developed in those working > groups is assumed. What a guy. Now get together with Cengiz and tie the IRR to the registries. (Actually I can't complain about RIPE - nice work in heirarchical authorization by Daniel and David). Can we get Cengiz, Bill Manning and Brian Renauld talking to Mark and Kim? ;-) > Thanks, > -drc Curtis From owner-ire Wed Aug 28 07:28:18 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id HAA19285 for ire-outgoing; Wed, 28 Aug 1996 07:28:18 +0900 (JST) Received: from core.atmnet.net (core.atmnet.net [207.67.247.4]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id HAA19280 for ; Wed, 28 Aug 1996 07:28:12 +0900 (JST) Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id PAA11992 for ; Tue, 27 Aug 1996 15:29:38 -0700 (PDT) Received: by jfbb.atmnet.net with Microsoft Mail id <01BB942C.C1B72DE0@jfbb.atmnet.net>; Tue, 27 Aug 1996 15:31:03 -0700 Message-ID: <01BB942C.C1B72DE0@jfbb.atmnet.net> From: Jim Browning To: "ire@apnic.net" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 15:31:02 -0700 Encoding: 24 TEXT Sender: owner-ire@apnic.net Precedence: bulk >From: David R. Conrad[SMTP:davidc@apnic.net] >Sent: Monday, August 26, 1996 8:17 PM > >Is Internet address space a scarce resource that should be conserved? I agree with Bill Manning in that I believe this is a compound question, which could be broken into: Is Internet Address Space a scarce resource? No. However there is lots of it out there not being used, and this could create scarcity in the future. Should Internet Address Space be Conserved? Yes, _but_: A. Not at the expense of route table growth and complexity (call me Yosarian ;) B. And not in a manner that influences the competitive marketplace (Another Catch-22?) -- Jim Browning From owner-ire Wed Aug 28 10:52:07 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id KAA20392 for ire-outgoing; Wed, 28 Aug 1996 10:52:07 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id KAA20387 for ; Wed, 28 Aug 1996 10:52:01 +0900 (JST) Received: by dragon.jp.apnic.net; id KAA23319; Wed, 28 Aug 1996 10:42:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma023315; Wed, 28 Aug 96 10:42:14 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id KAA19287; Wed, 28 Aug 1996 10:49:36 +0900 (JST) Message-Id: <199608280149.KAA19287@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Jim Fleming cc: "ire@apnic.net" Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 10:57:14 EST." <01BB9406.828528A0@webster.unety.net> Date: Wed, 28 Aug 1996 10:49:36 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Jim, First of all, I just want to make clear that the goal of IRE is to look at ways of evolving current registry procedures *not* to bash the registry system or a particular registry. Undoubtedly, everyone has there own pet peeve about what the registries do or don't do -- it can be constructive to point these issues out as possible areas for discussion. It is not constructive to throw around baseless accusations and innuendo. Forebearance will be appreciated. Now, to address your specific points: >This is true, the InterNIC does not create "administrative ease", instead >the policies it dreams up and enforces cause ISPs administrative headaches. All the registries implement policy as defined by the IANA, the IAB, and the Internet community at large. One particular registry does not "dream up" policies. >For some reason the InterNIC views the IPv4 address space as the "top" >of the heap. All the registries allocate IPv4 space currently, as such treating it as "top of the heap" would seem logical. When the time comes and should it be necessary, the registries will also allocate IPv6 space as well. >Efficient use of an address space does NOT mean the following... >1. Giving addresses to friends and neighbors >2. Giving addresses to the "right" people >3. Assigning the smallest possible block in sequence to put an ISP in their place >4. Assigning the smallest number of addresses in a calendar year >5. Assigning non-routable addresses to people that complain >6. Making ISPs grovel and beg >7. Lording power over ISPs and making it clear that they will die without IP addresses >8. Fragmenting the address space into as many blocks as possible >9. Investigating ISPs to see how the addresses are used >10. Policies which cause registries to collapse and return authority to the InterNIC With the exception of 9, no registry does any of this list currently and it is unlikely they will do so in the future. With respect to 9, how would you propose registries determine address utilization? >In my opinion, efficient use of the address space should include... > >1. Assignment policies that are open and fair Please define "fair", specifically, please define who we should be "fair" to. >2. Assignment policies that anticipate growing needs and aggregation opportunities >3. Active recycling of IP addresses. >4. Assignment policies which minimize router tables >5. Assignment policies which improve packet transport efficiency >5. Delegation policies which encourage MORE registries not less How would the creation of additional registries result in more efficient address space use? Regards, -drc From owner-ire Wed Aug 28 11:38:36 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id LAA20679 for ire-outgoing; Wed, 28 Aug 1996 11:38:36 +0900 (JST) Received: from doorstep.unety.net (root@DM-02-DS.unety.net [206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id LAA20673; Wed, 28 Aug 1996 11:38:32 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id VAA13926; Tue, 27 Aug 1996 21:31:40 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9460.27249220@webster.unety.net>; Tue, 27 Aug 1996 21:38:57 -0500 Message-ID: <01BB9460.27249220@webster.unety.net> From: Jim Fleming To: "'David R. Conrad'" Cc: "ire@apnic.net" , "'New Domains'" Subject: RE: a simple question... Date: Tue, 27 Aug 1996 21:38:56 -0500 Encoding: 96 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 8:49 PM, David R. Conrad[SMTP:davidc@apnic.net] wrote: /**/ @ @ >This is true, the InterNIC does not create "administrative ease", instead @ >the policies it dreams up and enforces cause ISPs administrative headaches. @ @ All the registries implement policy as defined by the IANA, the IAB, @ and the Internet community at large. One particular registry does not @ "dream up" policies. @ Ah yes...back to the old circular game of the IANA, the IAB, the IETF, etc... Hasn't anyone told you...that game is over...everyone sees right through it... @ >For some reason the InterNIC views the IPv4 address space as the "top" @ >of the heap. @ @ All the registries allocate IPv4 space currently, as such treating it @ as "top of the heap" would seem logical. When the time comes and @ should it be necessary, the registries will also allocate IPv6 space @ as well. @ What gives the registries the "automatic" right to have blocks delegated from the IPv6 address space? Maybe registries should be required to justify their requests. Maybe the same rules that apply to ISPs should be applied to registries. Just because you run a registry, you should not assume you have some God given right to dictate the future. @ >Efficient use of an address space does NOT mean the following... @ >9. Investigating ISPs to see how the addresses are used @ @ With the exception of 9, no registry does any of this list currently @ and it is unlikely they will do so in the future. With respect to 9, @ how would you propose registries determine address utilization? @ I am amazed that you admit that registries "investigate" ISPs.... It is not clear to me that ISPs and other netizens want their $50 annual fees spent on a new group of CIA-like agents running around policing the Internet... @ >In my opinion, efficient use of the address space should include... @ > @ >1. Assignment policies that are open and fair @ @ Please define "fair", specifically, please define who we should be @ "fair" to. @ No system will ever be completely fair. Each person has their own definition of fair. That definition changes over time. As people experience other cultures, systems, and approaches they modify what they view to be fair. Many people on planet Earth have grown accustomed to the fairness of democracies. Other people might consider fair to require an "open" and public process. Still others might expect some strict rules to be followed and the rules have to be endorsed by a majority of people. The key to fairness is to have *many* people involved in the process. This ensures checks and balances. By having many people involved, power is not concentrated in a few people's hands and everyone has many avenues to pursue the allocation of Internet resources. I can not imagine that anyone experiencing the existing system first hand would conclude that it is fair. @ How would the creation of additional registries result in more @ efficient address space use? @ My bottom line...get *more* people involved...not less... ...more registries will bring new viewpoints...and fair allocations Maybe additional registries will "listen" to outside opinions and not treat people like they are some lower from of life...this will allow them to benefit from other people's ideas... The Internet is not a place for a few people to play God... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 13:18:52 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id NAA21231 for ire-outgoing; Wed, 28 Aug 1996 13:18:52 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id NAA21223; Wed, 28 Aug 1996 13:18:34 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id AAA26848; Wed, 28 Aug 1996 00:19:38 -0400 (EDT) Message-Id: <199608280419.AAA26848@brookfield.ans.net> To: Jim Fleming cc: "David R. Conrad" , "ire@apnic.net" Reply-To: curtis@ans.net Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 11:24:19 CDT." <01BB940A.4AD9EB80@webster.unety.net> Date: Wed, 28 Aug 1996 00:19:38 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk Jim, The policies of the registries should not be by design or in practice providing advantage to the large ISPs. There are two possible roles the registries can play. They can give out addresses to anyone who asks regardless of how responsibly or irresponsibly the address space is used. Or they can try to more generously provide addresses to those who use the address space in ways that better promote further scaling of the Internet through responsible suballocation and promote further scaling of Internet routing. If the registries take the latter role, I can see 4 criteria that in an ideal world a registry might consider when making an allocation (not in any order): 1. efficiency of the use of the space. a any new allocation should be held accountable for maintaining an agreed to level of efficiency. b if providers successfully encourage use of RFC1597 this should be taken into consideration. c progress should be made in better utilizing existing blocks used for infrastructure. 2. aggregation of routing information a any new block allocated from a registry should appear as one prefix. Any additional prefixes advertised from the block should must be documented as being multihomed or as being in a finite renumbering transition. b progress should be made in better aggregating existing blocks if further aggregregation is possible. 3. routing stability providers with very high contributions of routing instability to global routing should be required to correct these problems before being allowed to expand further 4. routing integrity and fair play a providers should be required to provide reasonable and effective renumbering grace periods b providers should correctly route prefixes during a grace period I've outlined some very stringent criteria. With very strict enforcement of these criteria, the registries would be giving out address blocks to very few organizations. There would certainly be an uproar. Endorsing such an enforcement would be an extreme position. Note that even this extreme position does not bias things in favor of large or small providers. ISP on the other hand may choose to refuse to route long prefixes unless those prefixes are multihomed. ISPs may also choose some intermediate policy such as not accepting long prefixes from another continent. If someone goes to the registry and requests a small prefix outside of any aggregate and then advertises that small prefix to the world they may find that quite a few providers will not route it. If they are dual homed and use one provider's aggregate, they may still have full connectivity through the aggregate. This is not an issue for the registries who have simply provided an allocation that someone insisted they provide against the advice of the registry. Moving forward (I hope) a real question either this WG or the registires have to wrestle with is if the registries should give out addresses to anyone who asks or more generously provide addresses to those who use the address space in ways that better promote further scaling of the Internet. If so what are the criteria for "responsible use" of the address space, how strict should enforcement be, and to what extent should the WG decide this vs the registry deciding. Randy, Kim, Daniel - Have fun. That said I think I'll unsubscribe before the flames hit. :-) Curtis From owner-ire Wed Aug 28 13:50:02 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id NAA21461 for ire-outgoing; Wed, 28 Aug 1996 13:50:02 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id NAA21456 for ; Wed, 28 Aug 1996 13:49:49 +0900 (JST) Received: by dragon.jp.apnic.net; id NAA24144; Wed, 28 Aug 1996 13:34:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma024140; Wed, 28 Aug 96 13:34:11 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id NAA21140; Wed, 28 Aug 1996 13:41:33 +0900 (JST) Message-Id: <199608280441.NAA21140@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Jim Fleming cc: "ire@apnic.net" Subject: Re: a simple question... In-reply-to: Your message of "Tue, 27 Aug 1996 21:38:56 EST." <01BB9460.27249220@webster.unety.net> Date: Wed, 28 Aug 1996 13:41:33 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Jim, After your last couple of mail items, I've been told by several people that attempting to have a rational discussion with you is like trying to explain calculus to a howler monkey -- it is pointless, generates a lot of noise, and likely frustrates all parties involved. As a general rule, though, I prefer to give people the benefit of the doubt and will disregard the private suggestions of people who are perhaps more experienced in dealing with you to ignore you and hope you go away. I would however respectfully request you desist from the ad hominem attacks and the wild accusations. It would probably be beneficial for all concerned if you could try to be constructive in your comments instead of simply flaming away at anything you don't like. In any event, please note that I will *NOT* allow the IRE mailing list to degrade into what newdom became. You may take this any way you like. >What gives the registries the "automatic" right to have blocks >delegated from the IPv6 address space? The fact that they have acted in the capacity of allocating Internet resources in the past, have some experience performing this function, are felt to be acting in a reasonable manner given the constraints placed upon them, and perhaps most importantly, because the people who came up with the addressing plan for v6 thought it would be a good idea? If you do not like this, I'd suggest contacting the authors of the appropriate drafts and raising the issue with them. You will note that with the exception of Jon Postel, there were no registry people involved in the writing of the drafts. But this is somewhat beside the point. IRE is primarily focused on registry evolution from the perspective of the current Internet, i.e., the IPv4 Internet. If necessary, IRE will also look at issues related to IPv6, but I personally hope that won't be required (I'm still hoping for automagic assignment). >Maybe registries should be required to justify their requests. The registries do. When we run out of space, we must go to the IANA and ask for additional space showing we have sub-delegated at least 80% of the existing space. >I am amazed that you admit that registries "investigate" ISPs.... Again, I would ask: how would you propose registries determine address utilization? >@ How would the creation of additional registries result in more >@ efficient address space use? >My bottom line...get *more* people involved...not less... >...more registries will bring new viewpoints...and fair allocations The statement you made was that having additional registries would result in "more efficient address space use". Efficiency and fairness are not necessarily related, thus you have not answered the question. To date, it can be argued that multiple registries have resulted in less efficient allocations due to varying evaluations of needs of requestors. Why do you feel additional registries would result in more efficient allocations? Regards, -drc From owner-ire Wed Aug 28 14:11:55 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA21602 for ire-outgoing; Wed, 28 Aug 1996 14:11:55 +0900 (JST) Received: from doorstep.unety.net (root@DM-02-DS.unety.net [206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id OAA21597; Wed, 28 Aug 1996 14:11:52 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id AAA14305; Wed, 28 Aug 1996 00:05:00 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9475.92E9C920@webster.unety.net>; Wed, 28 Aug 1996 00:12:17 -0500 Message-ID: <01BB9475.92E9C920@webster.unety.net> From: Jim Fleming To: "'David R. Conrad'" , Jim Fleming Cc: "ire@apnic.net" Subject: A simple answer Date: Wed, 28 Aug 1996 00:12:16 -0500 Encoding: 36 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Tuesday, August 27, 1996 11:41 PM, David R. Conrad[SMTP:davidc@apnic.net] wrote: @ The statement you made was that having additional registries would @ result in "more efficient address space use". Efficiency and fairness @ are not necessarily related, thus you have not answered the question. @ To date, it can be argued that multiple registries have resulted in @ less efficient allocations due to varying evaluations of needs of @ requestors. Why do you feel additional registries would result in @ more efficient allocations? @ With more registries, there will be *more* people involved. With more people involved there will be more attention given to... 1. Address utilization studies and ecology programs 2. Topology understanding and agreements 3. Peer review and pressure 4. Conservation, sharing, transfer, etc. A couple of people can not manage a large address space and pay attention to the above areas. Also, if a registry competes with the registrants and costs the registrants undue time, energy, money, etc. then gaining cooperation in the above areas will not occur. With more registries, people can pick a registry that they feel is a partner. People can be encouraged to work together to make the most efficient use of the IPv4 address space. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 14:30:08 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA21746 for ire-outgoing; Wed, 28 Aug 1996 14:30:08 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id OAA21739 for ; Wed, 28 Aug 1996 14:30:00 +0900 (JST) Received: by dragon.jp.apnic.net; id OAA24435; Wed, 28 Aug 1996 14:20:28 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma024431; Wed, 28 Aug 96 14:20:03 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id OAA21612; Wed, 28 Aug 1996 14:27:26 +0900 (JST) Message-Id: <199608280527.OAA21612@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Jim Fleming cc: ire@apnic.net Subject: Re: A simple answer In-reply-to: Your message of "Wed, 28 Aug 1996 00:12:16 EST." <01BB9475.92E9C920@webster.unety.net> Date: Wed, 28 Aug 1996 14:27:26 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Jim, Thank you for being constructive (well, except for: >) >With more registries, people can pick a registry that they >feel is a partner. The concern that has been expressed in the past is that if you have multiple registries, what will end up happening is the registries will compete with each other (presuming that the registries are self-funded). As such, given the base resource of the registries (IP addresses) are free, a given registry will have an incentive to relax the allocation guidelines in order to obtain more customers. Thus, instead of allocating addresses more efficiently, the opposite happens. One proposal for resolving this problem was to have an independent audit board that goes out and audits registries to determine appropriate address allocation procedures with the audit board funded by fees paid by the registries. Alternatively, the IANA could hire a large number of additional staff and do the audit itself when the registry comes back for additional space. However, in either case, the logistics of performing the audit would be daunting -- to be effective, the audit board would need to contact the customers of the ISPs of the registry to determine their address usage. In essence, you have very little change from the existing system, other than increasing likelihood, given the increased number of registries, that people will be "creative" in their estimates. Regards, -drc From owner-ire Wed Aug 28 14:42:13 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id OAA21824 for ire-outgoing; Wed, 28 Aug 1996 14:42:13 +0900 (JST) Received: from doorstep.unety.net (root@DM-02-DS.unety.net [206.31.203.202]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id OAA21819; Wed, 28 Aug 1996 14:42:10 +0900 (JST) Received: from webster.unety.net (webster.unety.net [206.31.202.8]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id AAA14382; Wed, 28 Aug 1996 00:35:18 -0500 Received: by webster.unety.net with Microsoft Mail id <01BB9479.CE8384E0@webster.unety.net>; Wed, 28 Aug 1996 00:42:35 -0500 Message-ID: <01BB9479.CE8384E0@webster.unety.net> From: Jim Fleming To: "'David R. Conrad'" , Jim Fleming Cc: "ire@apnic.net" Subject: RE: A simple answer Date: Wed, 28 Aug 1996 00:42:34 -0500 Encoding: 62 TEXT Sender: owner-ire@apnic.net Precedence: bulk On Wednesday, August 28, 1996 12:27 AM, David R. Conrad[SMTP:davidc@apnic.net] wrote: @ Jim, @ @ Thank you for being constructive (well, except for: @ >) @ @ >With more registries, people can pick a registry that they @ >feel is a partner. @ @ The concern that has been expressed in the past is that if you have @ multiple registries, what will end up happening is the registries will @ compete with each other (presuming that the registries are @ self-funded). As such, given the base resource of the registries (IP @ addresses) are free, a given registry will have an incentive to relax @ the allocation guidelines in order to obtain more customers. Thus, @ instead of allocating addresses more efficiently, the opposite happens. @ @ One proposal for resolving this problem was to have an independent @ audit board that goes out and audits registries to determine @ appropriate address allocation procedures with the audit board funded @ by fees paid by the registries. Alternatively, the IANA could hire a @ large number of additional staff and do the audit itself when the @ registry comes back for additional space. @ @ However, in either case, the logistics of performing the audit would @ be daunting -- to be effective, the audit board would need to contact @ the customers of the ISPs of the registry to determine their address @ usage. In essence, you have very little change from the existing @ system, other than increasing likelihood, given the increased number @ of registries, that people will be "creative" in their estimates. @ While I agree this is the conclusion that some could draw IF they assume that all humans are resource-wasting-pigs with dollar signs in their eyes.... ...I like to give the Internet community the benefit of the doubt... ...imagine if God had taken your attitude before placing humans on Earth...we would probably not be here... I suggest that we give people a chance, give many registries a chance, and then let society steer those registries via peer pressure, awards, audits, etc. IF society allows the registries to trash the Internet, then the responsibility rests on society... ...if people that run registries keep standing back saying, "we can't let the masses on the planet...they will trash it"...then I can tell you...the masses will create another planet... while a limited number of registries might be able to preserve the IPv4 address space...this might end up being like preserving Mars...the unwashed masses will be on Earth...where they can find the resources they need... -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net From owner-ire Wed Aug 28 20:16:34 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id UAA23576 for ire-outgoing; Wed, 28 Aug 1996 20:16:34 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id UAA23571 for ; Wed, 28 Aug 1996 20:16:27 +0900 (JST) Received: by dragon.jp.apnic.net; id UAA25916; Wed, 28 Aug 1996 20:06:59 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma025910; Wed, 28 Aug 96 20:06:52 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id UAA25824; Wed, 28 Aug 1996 20:14:16 +0900 (JST) Message-Id: <199608281114.UAA25824@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: bmanning@ISI.EDU cc: ire@apnic.net Subject: a possible answer... In-reply-to: Your message of "Tue, 27 Aug 1996 05:57:32 MST." <199608271257.AA26933@zed.isi.edu> Date: Wed, 28 Aug 1996 20:14:16 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk >> Is Internet address space a scarce resource that should be conserved? >Drop "scarce" and I agree. OK, would the following (long) sentence summarize how people feel about the original question? While Internet addresses are not a scarce resource at this time, the lack of addresses has the potential of becoming a factor constraining Internet growth, and as such the entire Internet address space should be managed in such a way as to increase address utilization efficiency and opportunities for aggregation while minimizing the impact such managment has on continued Internet expansion. Thanks, -drc From owner-ire Wed Aug 28 20:31:35 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id UAA23681 for ire-outgoing; Wed, 28 Aug 1996 20:31:35 +0900 (JST) Received: from Killiney.hea.ie (Killiney.hea.ie [193.1.193.194]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id UAA23676; Wed, 28 Aug 1996 20:31:31 +0900 (JST) Received: from dalkey.hea.ie by Killiney.hea.ie via smap (V1.3) id sma030551; Wed Aug 28 12:33:56 1996 Received: from localhost (localhost [127.0.0.1]) by dalkey.hea.ie (8.7.5/8.7.3) with SMTP id MAA11706; Wed, 28 Aug 1996 12:33:33 +0100 Message-Id: <199608281133.MAA11706@dalkey.hea.ie> X-Authentication-Warning: dalkey.hea.ie: Host localhost [127.0.0.1] didn't use HELO protocol To: "David R. Conrad" cc: bmanning@ISI.EDU, ire@apnic.net, mnorris@dalkey.hea.ie Subject: Re: a possible answer... In-reply-to: Your message of "Wed, 28 Aug 96 20:14:16 +0900." <199608281114.UAA25824@moonsky.jp.apnic.net> Date: Wed, 28 Aug 96 12:33:32 +0100 From: "Mike Norris" X-Mts: smtp Sender: owner-ire@apnic.net Precedence: bulk >OK, would the following (long) sentence summarize how people feel >about the original question? > >While Internet addresses are not a scarce resource at this time, the >lack of addresses has the potential of becoming a factor constraining >Internet growth, and as such the entire Internet address space should >be managed in such a way as to increase address utilization efficiency >and opportunities for aggregation while minimizing the impact such >managment has on continued Internet expansion. Good answer, David. Mike Norris From owner-ire Thu Aug 29 00:53:47 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id AAA25703 for ire-outgoing; Thu, 29 Aug 1996 00:53:47 +0900 (JST) Received: from smtp1.interramp.com (smtp1.interramp.com [38.8.45.2]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id AAA25698; Thu, 29 Aug 1996 00:53:42 +0900 (JST) Received: from kb2blxHome by smtp1.interramp.com (8.6.12/SMI-4.1.3-PSI-irsmtp) id LAA21113; Wed, 28 Aug 1996 11:56:41 -0400 Message-ID: <32246C41.3EC1@interramp.com> Date: Wed, 28 Aug 1996 11:56:49 -0400 From: Ted Wolf Jr Reply-To: ted@usa.net Organization: Dun & Bradstreet Information Services NA X-Mailer: Mozilla 3.0b6Gold (WinNT; I) MIME-Version: 1.0 To: "David R. Conrad" CC: bmanning@ISI.EDU, ire@apnic.net Subject: Re: a possible answer... References: <199608281114.UAA25824@moonsky.jp.apnic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk David R. Conrad wrote: > > >> Is Internet address space a scarce resource that should be conserved? > >Drop "scarce" and I agree. > > OK, would the following (long) sentence summarize how people feel > about the original question? > > While Internet addresses are not a scarce resource at this time, the > lack of addresses has the potential of becoming a factor constraining > Internet growth, and as such the entire Internet address space should > be managed in such a way as to increase address utilization efficiency > and opportunities for aggregation while minimizing the impact such > managment has on continued Internet expansion. > > Thanks, > -drc David, Very well put. I agree with this definition. Of course he question is how to do this? Ted Wolf Jr From owner-ire Thu Aug 29 06:04:38 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id GAA27458 for ire-outgoing; Thu, 29 Aug 1996 06:04:38 +0900 (JST) Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id GAA27453; Thu, 29 Aug 1996 06:04:29 +0900 (JST) Received: (from gih@localhost) by nico.aarnet.edu.au (8.6.10/8.6.10) id HAA06172; Thu, 29 Aug 1996 07:05:21 +1000 From: Geoff Huston Message-Id: <199608282105.HAA06172@nico.aarnet.edu.au> Subject: Re: a possible answer... To: davidc@apnic.net (David R. Conrad) Date: Thu, 29 Aug 1996 07:05:21 +1000 (EST) Cc: bmanning@ISI.EDU, ire@apnic.net In-Reply-To: <199608281114.UAA25824@moonsky.jp.apnic.net> from "David R. Conrad" at Aug 28, 96 08:14:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk errk - its a bit like defining "motherhood" isn't it, becuase you are starting to list the criteria of motherhood, and when you go down that track you start the endless list... Here I see no mention of the objectives through management of: - maintaining the integrity of the global Internet - maintaining the value of the global Internet - fairness in the public distribution function You see its gets back to the original premise. Internet addresses are simply a means to an end. The end is exploitation of the value of Internet connectivity. Internet addresses are seen as a necessary precondition to that exploitative activity. In order to ensure equitable access to this resource (the Internet) and ensure equitable means of opportunity of exploitation the distribution function of addresses has to serve two primary functions: maintain the "value" of the Internet itself, and distribute the addresses "fairly" in so far as you do not deliberately disenfranchise any party. Now your "conservation" question really breaks into two issues as I see it. You believe that applying administrative pressure will increase the efficiency and aggregatability which in turn will reduce the growth pressures on the routing table and with aggregation will in theory reduce the route flap levels wich in turn will keep the Internet working (i.e. "value" of the Internet as a broken Internet has reduced "value"!) You also believe that some addresses are "nicer" than others (and its true that the old class A space is a tougher space to play in while RIP still lives) and you believe that it is in the public interest to "conserve" space in so far as you wish to be able to distribute addresses from the old class C space to parties who as yet have not started to exploit the Internet (i.e. there is an element of scarcity rationing in so far as you do not wish to distribute all your addresses to current applicants extragavantly). Now the challenge is to summarize all THAT up in 1 sentence! phew, its beyond me! Geoff > > >> Is Internet address space a scarce resource that should be conserved? > >Drop "scarce" and I agree. > > OK, would the following (long) sentence summarize how people feel > about the original question? > > While Internet addresses are not a scarce resource at this time, the > lack of addresses has the potential of becoming a factor constraining > Internet growth, and as such the entire Internet address space should > be managed in such a way as to increase address utilization efficiency > and opportunities for aggregation while minimizing the impact such > managment has on continued Internet expansion. > > Thanks, > -drc > > From owner-ire Thu Aug 29 11:11:37 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id LAA29509 for ire-outgoing; Thu, 29 Aug 1996 11:11:37 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id LAA29504; Thu, 29 Aug 1996 11:11:30 +0900 (JST) Received: by dragon.jp.apnic.net; id LAA00686; Thu, 29 Aug 1996 11:01:59 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma000681; Thu, 29 Aug 96 11:01:59 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id LAA29719; Thu, 29 Aug 1996 11:09:24 +0900 (JST) Message-Id: <199608290209.LAA29719@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Geoff Huston cc: davidc@apnic.net (David R. Conrad), bmanning@ISI.EDU, ire@apnic.net Subject: Re: a possible answer... In-reply-to: Your message of "Thu, 29 Aug 1996 07:05:21 +1000." <199608282105.HAA06172@nico.aarnet.edu.au> Date: Thu, 29 Aug 1996 11:09:24 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Geoff, >errk - its a bit like defining "motherhood" isn't it, Yes and no. I will admit my answer was a bit on the general side, however like saying "motherhood is good" there are a bunch of implications that people might not notice at first glance. >- maintaining the integrity of the global Internet >- maintaining the value of the global Internet Implied by "continued Internet expansion". I don't think limiting growth to insure integrity is a goal and as a result, given the assumption that the reason additional people connect to the Internet is because they find value in it, expansion while maintaining integrity implies value. >- fairness in the public distribution function A separate issue, not addressed yet. >You believe that applying administrative pressure will >increase the efficiency and aggregatability which in turn will reduce >the growth pressures on the routing table and with aggregation will in >theory reduce the route flap levels wich in turn will keep the >Internet working Remove the word "administrative" and I would agree -- I am taking no stand on how pressure is applied yet. There are various arguments for/against administrative pressure and economic pressure, but this isn't something I want to get into yet. My interest in this exchange is to come up with a common set of goals we can all agree on. How to reach those goals is merely an implementation detail (:-)). >You also believe that some addresses are "nicer" >than others (and its true that the old class A space is a tougher >space to play in while RIP still lives) I don't believe this should be an area of concern for IRE. Address class is merely a historical aberration that is being fixed. >and you believe that it is in >the public interest to "conserve" space in so far as you wish to be >able to distribute addresses from the old class C space to parties who >as yet have not started to exploit the Internet I think the terminology of "managing" the space (all the space, not just class C space) is more appropriate than "conserving". From the input received to date, it would seem that there is a consensus that IPv4 Internet addresses are not "scarce", but that limitations inherent in the technology can be a factor constraining the growth in the future. Thus, the implication is that the IPv4 Internet address space should be used efficiently in order to extend the lifetime of the IPv4 Internet. Complicating things a bit is that since the concern is to insure continued growth of the Internet, address space must be used (not just allocated) in a fashion that allows for aggregation. Note also that "managing" can apply to existing allocations, whereas "conserving" implies (at least to me) handling of the remaing free pool. >Now the challenge is to summarize all THAT up in 1 sentence! I doubt any document IRE produces will be the among the smaller RFCs (:-)). Regards, -drc From owner-ire Fri Aug 30 01:15:48 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA19652 for ire-outgoing; Fri, 30 Aug 1996 01:15:48 +0900 (JST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id BAA19647; Fri, 30 Aug 1996 01:15:43 +0900 (JST) From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 29 Aug 1996 09:18:42 -0700 Posted-Date: Thu, 29 Aug 1996 09:17:09 -0700 (PDT) Message-Id: <199608291617.AA00700@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Thu, 29 Aug 1996 09:17:09 -0700 Subject: Administrative Bounds To: davidc@apnic.net (David R. Conrad) Date: Thu, 29 Aug 1996 09:17:09 -0700 (PDT) Cc: ire@apnic.net In-Reply-To: <199608281114.UAA25824@moonsky.jp.apnic.net> from "David R. Conrad" at Aug 28, 96 08:14:16 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > > >> Is Internet address space a scarce resource that should be conserved? > >Drop "scarce" and I agree. > > OK, would the following (long) sentence summarize how people feel > about the original question? > > While Internet addresses are not a scarce resource at this time, the > lack of addresses has the potential of becoming a factor constraining > Internet growth, and as such the entire Internet address space should > be managed in such a way as to increase address utilization efficiency > and opportunities for aggregation while minimizing the impact such > managment has on continued Internet expansion. > > Thanks, > -drc Almost... :) >From a registry perspective, I feel that it can only concern itself with the first component... to wit: ..."the entire Internet address space should be managed in such a way as to increase address utilization efficiency"... The second half of the equation is the purview of other domains... ..."opportunities for aggregation"... As to minimization of impact, this is a failure of the pier efforts. -- --bill From owner-ire Fri Aug 30 01:53:31 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id BAA19883 for ire-outgoing; Fri, 30 Aug 1996 01:53:31 +0900 (JST) Received: from jazz.internic.net (jazz.internic.net [198.41.0.134]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id BAA19875; Fri, 30 Aug 1996 01:53:28 +0900 (JST) Received: (kimh@localhost) by jazz.internic.net (8.7.4/SLAM-1) id NAA02812; Thu, 29 Aug 1996 13:01:04 -0400 (EDT) From: Kim Hubbard Message-Id: <199608291701.NAA02812@jazz.internic.net> Subject: Re: Administrative Bounds To: bmanning@ISI.EDU Date: Thu, 29 Aug 1996 13:01:04 -0400 (EDT) Cc: davidc@apnic.net, ire@apnic.net In-Reply-To: <199608291617.AA00700@zed.isi.edu> from "bmanning@ISI.EDU" at Aug 29, 96 09:17:09 am X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > > > > > >> Is Internet address space a scarce resource that should be conserved? > > >Drop "scarce" and I agree. > > > > OK, would the following (long) sentence summarize how people feel > > about the original question? > > > > While Internet addresses are not a scarce resource at this time, the > > lack of addresses has the potential of becoming a factor constraining > > Internet growth, and as such the entire Internet address space should > > be managed in such a way as to increase address utilization efficiency > > and opportunities for aggregation while minimizing the impact such > > managment has on continued Internet expansion. > > > > Thanks, > > -drc > > Almost... :) > > >From a registry perspective, I feel that it can only concern itself with > the first component... to wit: > > ..."the entire Internet address space should be managed in such a way as > to increase address utilization efficiency"... > > The second half of the equation is the purview of other domains... > > ..."opportunities for aggregation"... > > As to minimization of impact, this is a failure of the pier efforts. > > > -- > --bill > Bill, You always say the registries shouldn't be concerned with routing issues, and in theory you're right. However, in reality the way we allocate, i.e., CIDR, referrals to upstream ISPs, etc. shows that routing issues do play a part in how we allocate space. Kim From owner-ire Fri Aug 30 03:33:13 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id DAA20429 for ire-outgoing; Fri, 30 Aug 1996 03:33:13 +0900 (JST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id DAA20424 for ; Fri, 30 Aug 1996 03:33:10 +0900 (JST) From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 29 Aug 1996 11:36:05 -0700 Posted-Date: Thu, 29 Aug 1996 11:34:32 -0700 (PDT) Message-Id: <199608291834.AA00805@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Thu, 29 Aug 1996 11:34:32 -0700 Subject: Re: Administrative Bounds To: kimh@internic.net (Kim Hubbard) Date: Thu, 29 Aug 1996 11:34:32 -0700 (PDT) Cc: ire@apnic.net In-Reply-To: <199608291701.NAA02812@jazz.internic.net> from "Kim Hubbard" at Aug 29, 96 01:01:04 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > Bill, > > You always say the registries shouldn't be concerned with routing issues, > and in theory you're right. However, in reality the way we allocate, i.e., > CIDR, referrals to upstream ISPs, etc. shows that routing issues do play > a part in how we allocate space. > > Kim But those issues are brought to the delegation registries as justifications. Unless the registries are concerning themselves with other, non-technical issues regarding ISP viability, then my firm feeling is that delegation registries should optimize for efficient address utilization. The routing problems will be fixed in other ways. -- --bill From owner-ire Fri Aug 30 06:24:15 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id GAA21369 for ire-outgoing; Fri, 30 Aug 1996 06:24:15 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id GAA21364; Fri, 30 Aug 1996 06:24:10 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id RAA05230; Thu, 29 Aug 1996 17:23:19 -0400 (EDT) Message-Id: <199608292123.RAA05230@brookfield.ans.net> To: bmanning@ISI.EDU cc: davidc@apnic.net (David R. Conrad), ire@apnic.net Reply-To: curtis@ans.net Subject: Re: Administrative Bounds In-reply-to: Your message of "Thu, 29 Aug 1996 09:17:09 PDT." <199608291617.AA00700@zed.isi.edu> Date: Thu, 29 Aug 1996 17:23:19 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <199608291617.AA00700@zed.isi.edu>, bmanning@ISI.EDU writes: > > > > >> Is Internet address space a scarce resource that should be conserved? > > >Drop "scarce" and I agree. > > > > OK, would the following (long) sentence summarize how people feel > > about the original question? > > > > While Internet addresses are not a scarce resource at this time, the > > lack of addresses has the potential of becoming a factor constraining > > Internet growth, and as such the entire Internet address space should > > be managed in such a way as to increase address utilization efficiency > > and opportunities for aggregation while minimizing the impact such > > managment has on continued Internet expansion. > > > > Thanks, > > -drc > > Almost... :) > > >From a registry perspective, I feel that it can only concern itself with > the first component... to wit: > > ..."the entire Internet address space should be managed in such a way as > to increase address utilization efficiency"... > > The second half of the equation is the purview of other domains... > > ..."opportunities for aggregation"... I think the registries need to be more than just cognisant of "opportunities for aggregation". The ISP are the ones that need to learn how to better take advantage of the "opportunities". > As to minimization of impact, this is a failure of the pier efforts. Its a real problem and the registries need to consider this. > --bill Curtis From owner-ire Fri Aug 30 11:40:31 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id LAA22966 for ire-outgoing; Fri, 30 Aug 1996 11:40:31 +0900 (JST) Received: from dragon.jp.apnic.net (firewall-user@apnic.hq.unu.edu [202.253.138.44]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id LAA22950; Fri, 30 Aug 1996 11:39:10 +0900 (JST) Received: by dragon.jp.apnic.net; id LAA22862; Fri, 30 Aug 1996 11:29:33 +0900 Received: from moonsky.jp.apnic.net(10.0.10.4) by dragon.jp.apnic.net via smap (g3.0.3) id xma022856; Fri, 30 Aug 96 11:29:24 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.7.1/8.7.1) with ESMTP id LAA06901; Fri, 30 Aug 1996 11:36:45 +0900 (JST) Message-Id: <199608300236.LAA06901@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: bmanning@ISI.EDU cc: kimh@internic.net (Kim Hubbard), ire@apnic.net, davidc@apnic.net Subject: Re: Administrative Bounds In-reply-to: Your message of "Thu, 29 Aug 1996 11:34:32 MST." <199608291834.AA00805@zed.isi.edu> Date: Fri, 30 Aug 1996 11:36:45 +0900 From: "David R. Conrad" Sender: owner-ire@apnic.net Precedence: bulk Bill, >> You always say the registries shouldn't be concerned with routing issues, >> and in theory you're right. However, in reality the way we allocate, i.e., >> CIDR, referrals to upstream ISPs, etc. shows that routing issues do play >> a part in how we allocate space. > But those issues are brought to the delegation registries as > justifications. Sometimes. >Unless the registries are concerning themselves > with other, non-technical issues regarding ISP viability, > then my firm feeling is that delegation registries should > optimize for efficient address utilization. Optimizing for efficient address utilization would imply we would allocate *exactly* the number of addresses necessary to satisfy the number of interfaces connected directly to the Internet, e.g., if a site has 2003 interfaces, you would have us allocate: a /22 a /23 a /24 a /25 a /26 a /28 a /31 a /32 instead of a /21. Further, if we weren't concerned about routing, there is no reason for the addresses to be aligned on CIDR boundaries, thus the list above is probably a mimimum. Given that people usually (but not always!) want addresses to connect (or have the possibility of connecting) to the Internet, the end result is that they'd likely need to come back to the registries and request additional space just so they can get a block that can be routed. It is easy to say "the registries shouldn't be concerned with routing issues" since we don't run "real" routers (I know -- I've done it :-)), however the registries are in the business of administering "Internet addresses" not just IPv4 addresses and as such, it would seem this means the registries must also take into account the cost/benefit tradeoffs of whether or not the addresses allocated contribute to the partitioning of the Internet. Don't get me wrong, I would be ecstatic if the registries didn't have to care about routing issues, yet it would seem you hold a minority view on this (unusual for you, no?). > The routing problems will be fixed in other ways. Yes, but it would appear the consensus is that the registries should (at least) not exacerbate the problem. Regards, -drc From owner-ire Sat Aug 31 07:09:13 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id HAA29346 for ire-outgoing; Sat, 31 Aug 1996 07:09:13 +0900 (JST) Received: from core.atmnet.net (core.atmnet.net [207.67.247.4]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id HAA29339; Sat, 31 Aug 1996 07:09:09 +0900 (JST) Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id PAA05515; Fri, 30 Aug 1996 15:10:38 -0700 (PDT) Received: by jfbb.atmnet.net with Microsoft Mail id <01BB9685.8F32ABA0@jfbb.atmnet.net>; Fri, 30 Aug 1996 15:11:46 -0700 Message-ID: <01BB9685.8F32ABA0@jfbb.atmnet.net> From: Jim Browning To: "'David R. Conrad'" Cc: "ire@apnic.net" , "bmanning@ISI.EDU" Subject: RE: a possible answer... Date: Fri, 30 Aug 1996 15:11:44 -0700 Encoding: 28 TEXT Sender: owner-ire@apnic.net Precedence: bulk >From: David R. Conrad[SMTP:davidc@apnic.net] >Sent: Wednesday, August 28, 1996 4:14 AM > >>> Is Internet address space a scarce resource that should be conserved? >>Drop "scarce" and I agree. > >OK, would the following (long) sentence summarize how people feel >about the original question? > >While Internet addresses are not a scarce resource at this time, the >lack of addresses has the potential of becoming a factor constraining >Internet growth, and as such the entire Internet address space should >be managed in such a way as to increase address utilization efficiency >and opportunities for aggregation while minimizing the impact such >management has on continued Internet expansion. Is the last part intended to be neutral with respect to Internet expansion? I would prefer that the policies have a positive impact on Internet expansion, or at least do not in any way restrict such expansion. How about: "... while not restricting continued Internet expansion." It _is_ a little bit shorter... :-) -- Jim From owner-ire Sat Aug 31 09:02:04 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id JAA29948 for ire-outgoing; Sat, 31 Aug 1996 09:02:04 +0900 (JST) Received: from core.atmnet.net (core.atmnet.net [207.67.247.4]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id JAA29943; Sat, 31 Aug 1996 09:02:01 +0900 (JST) Received: from jfbb.atmnet.net (jfbb.atmnet.net [207.67.252.138]) by core.atmnet.net (8.7.5/8.6.9) with SMTP id RAA07286; Fri, 30 Aug 1996 17:03:31 -0700 (PDT) Received: by jfbb.atmnet.net with Microsoft Mail id <01BB9695.53520BC0@jfbb.atmnet.net>; Fri, 30 Aug 1996 17:04:37 -0700 Message-ID: <01BB9695.53520BC0@jfbb.atmnet.net> From: Jim Browning To: "'David R. Conrad'" Cc: "bmanning@ISI.EDU" , Kim Hubbard , "ire@apnic.net" Subject: RE: Administrative Bounds Date: Fri, 30 Aug 1996 17:04:36 -0700 Encoding: 39 TEXT Sender: owner-ire@apnic.net Precedence: bulk >From: David R. Conrad[SMTP:davidc@apnic.net] >Sent: Thursday, August 29, 1996 7:37 PM >Yes, but it would appear the consensus is that the registries should >(at least) not exacerbate the problem. There are many people who believe that the size of the routing table is an *existing* problem, whereas the scarcity of addresses is a problem that *might* develop. I believe that the registries have to do more than avoid exacerbating the problem. The registries should develop policies which will actually *reduce* the size of the routing table. Also, as to minimizing impact and Bill's comment that this relates to a failure of PIER. As operator of a commercial network, I will say that renumbering is not the only way these policies affect continued growth. The fundamental ability to obtain required addresses in a *timely manner* is a prerequisite to growth. The current practices can occasionally limit growth, as well as upset the competitive balance by favoring larger operators. This is not only a theory, as it absolutely *has* happened. Customers want to see the addresses available before they sign a contract, as they are aware of what a problem it can be to obtain addresses from a registry. I know that the registries are only attempting to ensure that there is a valid requirement for the addresses, however no businessperson (neither the ultimate user nor the network operator) wants to risk their fortunes on a subjective process. Also, larger providers are more likely to have larger blocks of (contiguous) space available, and are able to obtain additional space with much less negotiation/justification, and in a much shorter period of time. Is there a consensus that this is in fact a problem with the current policies and practices which should be addressed (npi) as part of a goal of fairness? -- Jim From owner-ire Sat Aug 31 13:08:16 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id NAA01204 for ire-outgoing; Sat, 31 Aug 1996 13:08:16 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id NAA01198; Sat, 31 Aug 1996 13:08:10 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id AAA11598; Sat, 31 Aug 1996 00:08:41 -0400 (EDT) Message-Id: <199608310408.AAA11598@brookfield.ans.net> To: Jim Browning cc: "'David R. Conrad'" , "bmanning@ISI.EDU" , Kim Hubbard , "ire@apnic.net" Reply-To: curtis@ans.net Subject: Re: Administrative Bounds In-reply-to: Your message of "Fri, 30 Aug 1996 17:04:36 PDT." <01BB9695.53520BC0@jfbb.atmnet.net> Date: Sat, 31 Aug 1996 00:08:40 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message <01BB9695.53520BC0@jfbb.atmnet.net>, Jim Browning writes: > >From: David R. Conrad[SMTP:davidc@apnic.net] > >Sent: Thursday, August 29, 1996 7:37 PM > > >Yes, but it would appear the consensus is that the registries should > >(at least) not exacerbate the problem. > > There are many people who believe that the size of the routing table is an > *existing* problem, whereas the scarcity of addresses is a problem that > *might* develop. I believe that the registries have to do more than avoid > exacerbating the problem. The registries should develop policies which > will actually *reduce* the size of the routing table. They actually have. Take a routing dump and look at all of the consecutive /24 with the eact same AS path. This isn't the registry's fault. > Also, as to minimizing impact and Bill's comment that this relates to a > failure of PIER. As operator of a commercial network, I will say that > renumbering is not the only way these policies affect continued growth. > The fundamental ability to obtain required addresses in a *timely manner* > is a prerequisite to growth. The current practices can occasionally limit > growth, as well as upset the competitive balance by favoring larger > operators. This is not only a theory, as it absolutely *has* happened. > Customers want to see the addresses available before they sign a contract, > as they are aware of what a problem it can be to obtain addresses from a > registry. Get addresses from your provider when you are small enough that one customer is a significant fraction of your total CIDR allocation. > I know that the registries are only attempting to ensure that there is a > valid requirement for the addresses, however no businessperson (neither the > ultimate user nor the network operator) wants to risk their fortunes on a > subjective process. Also, larger providers are more likely to have larger > blocks of (contiguous) space available, and are able to obtain additional > space with much less negotiation/justification, and in a much shorter > period of time. Small providers often get allocations of a multiple of their current size. Large ISPs get a fraction of their current size with each request. In both cases the prior blocks need to have been well used. > Is there a consensus that this is in fact a problem with the current > policies and practices which should be addressed (npi) as part of a goal of > fairness? > -- > Jim Actually, I do think there has been an unfair situation. Either: --1-- a. The registries strongly discourage "portable address" allocations, b. and the ISPs allow: - dual homed prefixes within their CIDR block and - migrations from their CIDR block with a very generous renumbering interval Or: --2-- a. The registries allow "portable address" allocations, b. and the ISPs don't allow dual homed prefixes within their CIDR block and don't allow migrations from their CIDR block. The current situation is unfair to smaller providers: --3-- 1a. The registries strongly discourage "portable address" allocations, 2b. and the ISPs don't allow dual homed prefixes within their CIDR block and don't allow migrations from their CIDR block. The third situation is unfair to small providers. Renumbering technology just isn't there. Refusal to accept this was the failure of the "Address Lending" draft and the demise of CIDRD. Option (2) is very bad for the routing table size. (2b) clearly reflects the practices of some providers. (1a) represents the practices of the registries. One way to start to encourage (1b) is to agree that it is The Right Thing To Do. If this WG comes to that agreement then they can put wording in the RFC that gives the registries the power to "encourage" that practice, just as they "discourage" portable address. The registries should be free to use their discression. If the practice (1b) does not become widespread the registries can and should withhold allocations from the large ISPs that are not doing The Right Thing. Can we get consensus on this point? Curtis From owner-ire Sat Aug 31 13:43:47 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id NAA01424 for ire-outgoing; Sat, 31 Aug 1996 13:43:47 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id NAA01418 for ; Sat, 31 Aug 1996 13:43:44 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id AAA23295; Sat, 31 Aug 1996 00:46:43 -0400 (EDT) Date: Sat, 31 Aug 1996 00:46:43 -0400 (EDT) From: "Dorian R. Kim" To: Curtis Villamizar cc: "ire@apnic.net" Subject: Re: Administrative Bounds In-Reply-To: <199608310408.AAA11598@brookfield.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ire@apnic.net Precedence: bulk On Sat, 31 Aug 1996, Curtis Villamizar wrote: > Actually, I do think there has been an unfair situation. > > Either: > > --1-- > > a. The registries strongly discourage "portable address" > allocations, > > b. and the ISPs allow: > - dual homed prefixes within their CIDR block and > - migrations from their CIDR block with a very generous > renumbering interval > > The third situation is unfair to small providers. Renumbering > technology just isn't there. Refusal to accept this was the failure > of the "Address Lending" draft and the demise of CIDRD. I'm not sure if I'd go so far. "address lending" draft did recommend a reasonable grace period for renumbering. Perhaps it should have gone further than that, but this does not show a refusal to accept the fact that renumbering technology isn't there. > practices of the registries. One way to start to encourage (1b) is to > agree that it is The Right Thing To Do. > > If this WG comes to that agreement then they can put wording in the > RFC that gives the registries the power to "encourage" that practice, > just as they "discourage" portable address. The registries should be > free to use their discression. If the practice (1b) does not become > widespread the registries can and should withhold allocations from the > large ISPs that are not doing The Right Thing. > > Can we get consensus on this point? I wholehearted agree that 1b is a Good Thing. Now having said that, what is a "generous" and/or "reasonable" grace period? In practice, we deal with this on case by case bases. However, keeping track of various "floating" bits of our CIDR block with various different expiration dates on the grace period has created an administrative headache, which is made worse by the coordination necessary between various providers to get cases closed. I can imagine what a headache it would be for a large NSP. Perhaps this is a half baked idea, but agreeing to a standard length of grace period (depending on the length of prefix), as well as procedures of coordination between providers might help with this situation? -dorian From owner-ire Sat Aug 31 15:06:09 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA01941 for ire-outgoing; Sat, 31 Aug 1996 15:06:09 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id PAA01936 for ; Sat, 31 Aug 1996 15:06:04 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id CAA13903; Sat, 31 Aug 1996 02:06:54 -0400 (EDT) Message-Id: <199608310606.CAA13903@brookfield.ans.net> To: "Dorian R. Kim" cc: Curtis Villamizar , "ire@apnic.net" Reply-To: curtis@ans.net Subject: Re: Administrative Bounds In-reply-to: Your message of "Sat, 31 Aug 1996 00:46:43 EDT." Date: Sat, 31 Aug 1996 02:06:54 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message , "Dorian R . Kim" writes: > > I wholehearted agree that 1b is a Good Thing. Now having said that, what is a > "generous" and/or "reasonable" grace period? I've been saying minimum of 6 months. > In practice, we deal with this on case by case bases. However, keeping track > of various "floating" bits of our CIDR block with various different expiratio > n > dates on the grace period has created an administrative headache, which is > made worse by the coordination necessary between various providers to get > cases closed. I can imagine what a headache it would be for a large NSP. Add a community to the IRR entry like CICNET-RENUMBER. Then run a perlprogram that either runs peval and give it a query for CICNET-RENUMBER or asks the RA whois. Then look up each prefix and check the datas (or put expire dates in remarks). Use that to trigger reminders. Or you can set TTs with long next action times. > Perhaps this is a half baked idea, but agreeing to a standard length of grace > period (depending on the length of prefix), as well as procedures of > coordination between providers might help with this situation? > > -dorian I think it would help. There are providers who don't like to give any grace period and some who think two weeks is plenty of time. Curtis From owner-ire Sat Aug 31 15:17:44 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id PAA02016 for ire-outgoing; Sat, 31 Aug 1996 15:17:44 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id PAA02011 for ; Sat, 31 Aug 1996 15:17:40 +0900 (JST) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id CAA24549; Sat, 31 Aug 1996 02:20:37 -0400 (EDT) Date: Sat, 31 Aug 1996 02:20:37 -0400 (EDT) From: "Dorian R. Kim" To: Curtis Villamizar cc: "ire@apnic.net" Subject: Re: Administrative Bounds In-Reply-To: <199608310606.CAA13903@brookfield.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ire@apnic.net Precedence: bulk On Sat, 31 Aug 1996, Curtis Villamizar wrote: > In message , "Dorian R > . Kim" writes: > Add a community to the IRR entry like CICNET-RENUMBER. Then run a > perlprogram that either runs peval and give it a query for > CICNET-RENUMBER or asks the RA whois. Then look up each prefix and > check the datas (or put expire dates in remarks). Use that to trigger > reminders. Or you can set TTs with long next action times. The difficult part which I alluded to before is reminding the other provider to remove the transition prefixes. In my experience, it takes several tries at least, and often require repeated email/phone calls of "can you please take that route out? Pretty please?" > I think it would help. There are providers who don't like to give any > grace period and some who think two weeks is plenty of time. IMO, minimum of 30 days for a /24 is reasonable, although 60 days is preferred. If we can get consensus, we can set up a table that can be used as a reference chart. Something like: /24 45 days /23-/22 90 days /21-/19 6 months /18-/17 12-18months I would question the utility of collecting anything shorter than /16 back, however. -dorian From owner-ire Sat Aug 31 19:49:39 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id TAA03131 for ire-outgoing; Sat, 31 Aug 1996 19:49:39 +0900 (JST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by teckla.apnic.net (8.7.1/8.7.1) with ESMTP id TAA03126 for ; Sat, 31 Aug 1996 19:49:35 +0900 (JST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id GAA14944; Sat, 31 Aug 1996 06:50:28 -0400 (EDT) Message-Id: <199608311050.GAA14944@brookfield.ans.net> To: "Dorian R. Kim" cc: Curtis Villamizar , "ire@apnic.net" Reply-To: curtis@ans.net Subject: Re: Administrative Bounds In-reply-to: Your message of "Sat, 31 Aug 1996 02:20:37 EDT." Date: Sat, 31 Aug 1996 06:50:27 -0400 From: Curtis Villamizar Sender: owner-ire@apnic.net Precedence: bulk In message , "Dorian R . Kim" writes: > > IMO, minimum of 30 days for a /24 is reasonable, although 60 days is > preferred. If we can get consensus, we can set up a table that can be used as > a reference chart. Something like: > > /24 45 days > /23-/22 90 days > /21-/19 6 months > /18-/17 12-18months > > I would question the utility of collecting anything shorter than /16 back, > however. > > -dorian The sliding scale is a good idea. Can we keep the low end a little higher. How about: /24 60 days (2 months) /23-/22 120 days (4 months) /21-/19 6 months /18-/17 12 months This is not because it takes a lot to handle this many hosts, just that if there are any complications it can take just as long to decide how to do some of the renumbering on a /24 as a /20. We also need to include some provision for granting an extension. I'd favor requesting an extension from the provider with the opportunity to appeal to the next level registry if the renumbering effort has encountered a stone wall (like a vendor licence server). Curtis From owner-ire Sat Aug 31 22:33:10 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id WAA03856 for ire-outgoing; Sat, 31 Aug 1996 22:33:10 +0900 (JST) Received: from moses.internic.net (moses.internic.net [198.41.0.68]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id WAA03851; Sat, 31 Aug 1996 22:33:06 +0900 (JST) Received: (kimh@localhost) by moses.internic.net (8.6.10/MOSES-1) id JAA08302; Sat, 31 Aug 1996 09:36:54 -0400 From: Kim Hubbard Message-Id: <199608311336.JAA08302@moses.internic.net> Subject: Re: Administrative Bounds To: jfbb@atmnet.net (Jim Browning) Date: Sat, 31 Aug 1996 09:36:54 -0400 (EDT) Cc: davidc@apnic.net, bmanning@ISI.EDU, kimh@internic.net, ire@apnic.net In-Reply-To: <01BB9695.53520BC0@jfbb.atmnet.net> from "Jim Browning" at Aug 30, 96 05:04:36 pm X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > > >From: David R. Conrad[SMTP:davidc@apnic.net] > >Sent: Thursday, August 29, 1996 7:37 PM > > >Yes, but it would appear the consensus is that the registries should > >(at least) not exacerbate the problem. > > There are many people who believe that the size of the routing table is an > *existing* problem, whereas the scarcity of addresses is a problem that > *might* develop. I believe that the registries have to do more than avoid > exacerbating the problem. The registries should develop policies which > will actually *reduce* the size of the routing table. There may not be a scarcity of address problem at this time but we were definitely heading in that direction a couple of years ago which is why the registries implemented their current policies. The registry policies *do* help to limit the size of the routing table, but we cannot just give every startup ISP a /14 as a first allocation to make sure they only have 1 routing entry. > > > Also, as to minimizing impact and Bill's comment that this relates to a > failure of PIER. As operator of a commercial network, I will say that > renumbering is not the only way these policies affect continued growth. > The fundamental ability to obtain required addresses in a *timely manner* > is a prerequisite to growth. The current practices can occasionally limit > growth, as well as upset the competitive balance by favoring larger > operators. This is not only a theory, as it absolutely *has* happened. > Customers want to see the addresses available before they sign a contract, > as they are aware of what a problem it can be to obtain addresses from a > registry. Yes, I've had many startup ISPs come to me and say they want as many addresses as Sprint, MCI and UUNET because their potential customers won't take them seriously until they do. This is ludicrous. > > I know that the registries are only attempting to ensure that there is a > valid requirement for the addresses, however no businessperson (neither the > ultimate user nor the network operator) wants to risk their fortunes on a > subjective process. Also, larger providers are more likely to have larger > blocks of (contiguous) space available, and are able to obtain additional > space with much less negotiation/justification, and in a much shorter > period of time. The larger providers have the larger blocks because they can justify them. They didn't start out with large blocks - they had to go through the same justification and slow start as everyone else. Some larger providers also know what it takes to receive blocks with less negotiation and that is by making sure their SWIPs are in *before* they ask for more space and by utilizing the space efficiently. They know this because they've been dealing with the registries longer and have learned the process. Or shall I say, accepted the process. Some ISPs refuse to submit their SWIPs and then complain because they can't get additional space in a *timely manner*. I know some of you don't want to be bothered with SWIP or slow start, however, the registries need to be able to verify utilization. As you know Jim, it doesn't take that long to begin receiving the larger blocks - if you follow the basic procedures. > > Is there a consensus that this is in fact a problem with the current > policies and practices which should be addressed (npi) as part of a goal of > fairness? Several documents already show how to get address space quickly (if that's your goal) by submitting your SWIPs and following the assignment guidelines. Kim > -- > Jim > > > From owner-ire Sat Aug 31 22:38:11 1996 Received: (from daemon@localhost) by teckla.apnic.net (8.7.1/8.7.1) id WAA03905 for ire-outgoing; Sat, 31 Aug 1996 22:38:11 +0900 (JST) Received: from moses.internic.net (moses.internic.net [198.41.0.68]) by teckla.apnic.net (8.7.1/8.7.1) with SMTP id WAA03900 for ; Sat, 31 Aug 1996 22:38:09 +0900 (JST) Received: (kimh@localhost) by moses.internic.net (8.6.10/MOSES-1) id JAA08319; Sat, 31 Aug 1996 09:41:56 -0400 From: Kim Hubbard Message-Id: <199608311341.JAA08319@moses.internic.net> Subject: Re: Administrative Bounds To: curtis@ans.net Date: Sat, 31 Aug 1996 09:41:56 -0400 (EDT) Cc: dorian@cic.net, ire@apnic.net In-Reply-To: <199608311050.GAA14944@brookfield.ans.net> from "Curtis Villamizar" at Aug 31, 96 06:50:27 am X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ire@apnic.net Precedence: bulk > > > In message , "Dorian R > . Kim" writes: > > > > IMO, minimum of 30 days for a /24 is reasonable, although 60 days is > > preferred. If we can get consensus, we can set up a table that can be used as > > a reference chart. Something like: > > > > /24 45 days > > /23-/22 90 days > > /21-/19 6 months > > /18-/17 12-18months > > > > I would question the utility of collecting anything shorter than /16 back, > > however. > > > > -dorian > > > The sliding scale is a good idea. Can we keep the low end a little > higher. How about: > > /24 60 days (2 months) > /23-/22 120 days (4 months) > /21-/19 6 months > /18-/17 12 months > > This is not because it takes a lot to handle this many hosts, just > that if there are any complications it can take just as long to decide > how to do some of the renumbering on a /24 as a /20. > > We also need to include some provision for granting an extension. I'd > favor requesting an extension from the provider with the opportunity > to appeal to the next level registry if the renumbering effort has > encountered a stone wall (like a vendor licence server). I agree with this. Quite a few times an end-user will call and ask me to intervene on their behalf if their ISP won't allow an appropriate amount of time to renumber. In all cases, when I've called the ISP has been willing to *rethink* their decision and it's worked out well. But it does seem to help to have the next level registry involved sometimes. Kim > > Curtis >