From memsvcs at arin.net Fri Sep 7 11:20:00 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 7 Sep 2001 11:20:00 -0400 (EDT) Subject: ARIN Nomination Period Closes in 10 Days Message-ID: The call for nominations for the ARIN Board of Trustees, ARIN Advisory Council, and the ASO AC from the ARIN region closes at 23:59 EDT Monday, September 17. Please take the time to nominate qualified candidates for these positions. There are two open Board seats, six open ARIN AC seats, and one seat open on the ASO AC. You must be an ARIN member to make nominations for the Board and ARIN Advisory Council, however anyone from within the ARIN region may submit a nomination for the ASO AC. Nominees do not need to be ARIN members. Details and instructions on submitting nominations can be found at: ASO AC: http://www.arin.net/aso/asonom.htm ARIN Board & Advisory Council: http://www.arin.net/announcements/election.html Please direct any questions or concerns to member-services at arin.net. Regards, Susan Hamlin Director, Member Services American Registry for Internet Numbers From memsvcs at arin.net Mon Sep 10 11:24:00 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 10 Sep 2001 11:24:00 -0400 (EDT) Subject: ARIN Forms New RFC 2050 Working Group Message-ID: At the last ARIN Open Policy meeting in San Francisco concerns were raised about RFC 2050. It was noted that this document has aged and that certain portions of it no longer reflected the current state of RIR policy and operations. Similar concerns have been raised in the APNIC and RIPE NCC regions. Accordingly, ARIN is establishing a working group to further examine this issue. Mark McFadden has volunteered to chair the 2050WG. The charter for the working group follows: The objective of the RFC 2050 Working Group is to address the issues relating to relevance of RFC 2050 to the needs of today's Internet registry system. The group will evaluate RFC 2050 and propose a method of replacing it with a new document or documents. Once consensus has emerged on the process that will be used to replace RFC 2050, the working group will cooperatively develop its replacement. The working group will work in coordination with the other Regional Internet Registries, who will conduct a similar review process in their respective regions. An email list for the 2050WG has been established. Subscription information can be found at the following URL: http://www.arin.net/members/mailing.htm All interested individuals are encouraged to participate in this discussion. This will be an agenda item at the next ARIN Open Policy meeting in Miami. Ray Plzak President From memsvcs at arin.net Fri Sep 14 15:11:59 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 14 Sep 2001 15:11:59 -0400 (EDT) Subject: Last Call for Nominations Message-ID: You have until 23:59 EDT, Monday September 17 to submit nominations of candidates to run for a seat on the ASO Address Council from the ARIN region, the ARIN Board of Trustees, or the ARIN Advisory Council. Please see the sites below for details on submitting a nomination: http://www.arin.net/aso/asonom.htm (ASO AC election) http://www.arin.net/announcements/election.html (ARIN BOT and AC) Regards, Susan Hamlin Director, Member Services American Registry for Internet Numbers From memsvcs at arin.net Fri Sep 21 15:58:03 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 21 Sep 2001 15:58:03 -0400 (EDT) Subject: Policy Discussions Message-ID: To Interested Parties: ARIN will hold its next Public Policy and Members Meeting in Miami, Florida on October 28 through 31, 2001. Meeting and registration details can be found at: http://www.arin.net/meetings/ARIN_VIII/index.html ARINs Internet resource policy evaluation process specifies that policy proposals must be posted to the ARIN mailing lists 30 days prior to an ARIN meeting where they will be discussed. ARINs Internet resource policy evaluation process is described at: http://www.arin.net/arin/policy_eval_process.html ARIN staff has received from various sources policy proposals to be discussed at the Miami meeting. Each of these proposals will be released as separate emails to the appropriate lists according to the following schedule: September 24, 2001 Morning - 1 proposal Afternoon - 1 proposal September 26, 2001 Morning - 2 proposals Afternoon - 1 proposal September 28, 2001 Morning - 1 proposal Afternoon - 1 proposal The staggered release format was chosen so as not to flood your inbox with proposals all at once. Everyone, whether a member of ARIN or not, is encouraged to participate in these discussions. Your active participation in these discussions will help to form policies that are beneficial to all. Ray Plzak President From memsvcs at arin.net Mon Sep 24 10:57:49 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 24 Sep 2001 10:57:49 -0400 (EDT) Subject: Policy Proposal 2001-1 Message-ID: <200109241457.KAA02357@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN public policy and members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. It is currently required all /29 and shorter reassignments be reported to the ARIN WHOIS database via SWIP or RWHOIS. It is proposed this policy be modified to require reporting for /28 and shorter reassignments only. This policy proposal discussion will take place on the public policy mailing list (ppml at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From huberman at gblx.net Mon Sep 24 17:45:20 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 24 Sep 2001 14:45:20 -0700 (MST) Subject: Policy Proposal 2001-1 In-Reply-To: <200109241457.KAA02357@ops.arin.net> Message-ID: > It is currently required all /29 and shorter reassignments be > reported to the ARIN WHOIS database via SWIP or RWHOIS. It is > proposed this policy be modified to require reporting for /28 > and shorter reassignments only. Since I actually put forth this idea a few weeks ago on this list, I'll re-iterate, in short, my reasoning: (1) Most /29s I see assigned are for home networks. (1a) Most home networks are (and in my opinion, should be) SWIPed with the upstream's contact information in the POC field. (2) Taking out /29s from the SWIPing requirement should, in some measurable (hopefully meaningful) way, reduce the load on operators and on ARIN. It's just a thought - the initial reaction was positive from seemingly smaller service providers. UUNET (Lee) chimed in and said it would make no difference to them, but then again, UUNET is probably fully automated in their SWIPing duties. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From memsvcs at arin.net Mon Sep 24 17:54:18 2001 From: memsvcs at arin.net (Member Services) Date: Mon, 24 Sep 2001 17:54:18 -0400 (EDT) Subject: Policy Proposal 2001-2 Message-ID: <200109242154.RAA07436@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN public policy and members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. Proposal: A downstream customer's multihoming requirement will serve as justification for a /24 reassignment from their upstream ISP regardless of host requirements. This policy proposal discussion will take place on the public policy mailing list (ppml at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From randy at psg.com Tue Sep 25 11:02:00 2001 From: randy at psg.com (Randy Bush) Date: Tue, 25 Sep 2001 08:02:00 -0700 Subject: Policy Proposal 2001-1 References: <200109241457.KAA02357@ops.arin.net> Message-ID: >> It is currently required all /29 and shorter reassignments be >> reported to the ARIN WHOIS database via SWIP or RWHOIS. It is >> proposed this policy be modified to require reporting for /28 >> and shorter reassignments only. > > Since I actually put forth this idea a few weeks ago on this list, > I'll re-iterate, in short, my reasoning: > > (1) Most /29s I see assigned are for home networks. > > (1a) Most home networks are (and in my opinion, should be) > SWIPed with the upstream's contact information in the POC > field. > > (2) Taking out /29s from the SWIPing requirement should, > in some measurable (hopefully meaningful) way, reduce > the load on operators and on ARIN. there is also a possible privacy benefit by not mandating folk's home data be revealed. randy From lhoward at UU.NET Tue Sep 25 11:43:36 2001 From: lhoward at UU.NET (Lee Howard) Date: Tue, 25 Sep 2001 11:43:36 -0400 (EDT) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: On Tue, 25 Sep 2001, Randy Bush wrote: > Date: Tue, 25 Sep 2001 08:02:00 -0700 > From: Randy Bush > To: David R Huberman > Cc: ppml at arin.net > Subject: Re: Policy Proposal 2001-1 > > >> It is currently required all /29 and shorter reassignments be > >> reported to the ARIN WHOIS database via SWIP or RWHOIS. It is > >> proposed this policy be modified to require reporting for /28 > >> and shorter reassignments only. > > > > Since I actually put forth this idea a few weeks ago on this list, > > I'll re-iterate, in short, my reasoning: > > > > (1) Most /29s I see assigned are for home networks. > > > > (1a) Most home networks are (and in my opinion, should be) > > SWIPed with the upstream's contact information in the POC > > field. > > > > (2) Taking out /29s from the SWIPing requirement should, > > in some measurable (hopefully meaningful) way, reduce > > the load on operators and on ARIN. > > there is also a possible privacy benefit by not mandating folk's home > data be revealed. > > randy We already have such a policy, since the 6/12/2000 Board meeting: Scott Bradner put forth the motion that ARIN require only name, city, state, and zipcode be reported for all residential reassignments via SWIP or an RWHOIS server. "Private residence" would be substituted in the address field. Scott Marcus seconded the motion and a unanimous vote carried the motion. http://www.arin.net/minutes/bot/bot06122000.html There was discussion at the public policy meeting in fall 1999, and the AC made the policy recommendation to the Board. Just the way policy is supposed to work. Given that such a policy exists, do we need to alter the minimum SWIP size? Lee From mury at goldengate.net Tue Sep 25 15:07:57 2001 From: mury at goldengate.net (Mury) Date: Tue, 25 Sep 2001 14:07:57 -0500 (CDT) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: In my opinion, which not everyone appreciates, if I'm going to SWIP network assignments I may as well SWIP them all. It isn't all that labor intensive. Especially if you do it automatically. We have it semi-automated. If the reasoning is to stop SWIPing home user networks, then that should be the criteria, not the size of the block. While I think home users should be SWIPed, it should be noted that a lot of home users are very sensitive about their information (address, phone number, etc) being available so easily on the Internet. Mury CEO GoldenGate Internet Services 763-784-2800 * The Twin Cities Largest Locally Owned Internet Provider * * Multiple DS3s and POPs for Redundancy * * DSL, T1s, DS3s, ISDN, Web Hosting, Colocation, Web Design, and more * On Mon, 24 Sep 2001, David R Huberman wrote: > > > It is currently required all /29 and shorter reassignments be > > reported to the ARIN WHOIS database via SWIP or RWHOIS. It is > > proposed this policy be modified to require reporting for /28 > > and shorter reassignments only. > > Since I actually put forth this idea a few weeks ago on this list, > I'll re-iterate, in short, my reasoning: > > (1) Most /29s I see assigned are for home networks. > > (1a) Most home networks are (and in my opinion, should be) > SWIPed with the upstream's contact information in the POC > field. > > (2) Taking out /29s from the SWIPing requirement should, > in some measurable (hopefully meaningful) way, reduce > the load on operators and on ARIN. > > It's just a thought - the initial reaction was positive from seemingly > smaller service providers. UUNET (Lee) chimed in and said it would make no > difference to them, but then again, UUNET is probably fully automated in > their SWIPing duties. > > /david > > *--------------------------------* > | Global Crossing API | > | Manager, Global IP Addressing | > | (703) 627-5800 | > | huberman at gblx.net | > *--------------------------------* > > From huberman at gblx.net Tue Sep 25 19:57:28 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 25 Sep 2001 16:57:28 -0700 (MST) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: > Given that such a policy exists, do we need to alter the minimum SWIP > size? I had brought this up for discussion not so much for the privacy policy, but because I feel the /29s in the ARIN WHOIS database are mostly "useless objects" - in part, due to the policy. In an effort to lessen the burden on small- and medium-sized ISPs who SWIP manually, and in an effort to lessen the burden on ARIN which manually process thousands of SWIPs a day, and in conjunction with my stated belief that so many /29s are home networks containing upstream POC information, this discussion seemed appropriate. /david From mury at goldengate.net Tue Sep 25 20:40:06 2001 From: mury at goldengate.net (Mury) Date: Tue, 25 Sep 2001 19:40:06 -0500 (CDT) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: On Tue, 25 Sep 2001, David R Huberman wrote: > I had brought this up for discussion not so much for the privacy policy, > but because I feel the /29s in the ARIN WHOIS database are mostly "useless > objects" - in part, due to the policy. > > In an effort to lessen the burden on small- and medium-sized ISPs who SWIP > manually, and in an effort to lessen the burden on ARIN which manually > process thousands of SWIPs a day, and in conjunction with my stated belief > that so many /29s are home networks containing upstream POC information, > this discussion seemed appropriate. This is probably a dumb question I could find the answer to somewhere else, but I'll give it a shot anyway... Why does ARIN need to manually process swips? What is the human intervention achieving that a well written script could not accomplish? Thanks. Mury CEO GoldenGate Internet Services 763-784-2800 * The Twin Cities Largest Locally Owned Internet Provider * * Multiple DS3s and POPs for Redundancy * * DSL, T1s, DS3s, ISDN, Web Hosting, Colocation, Web Design, and more * From mark at amplex.net Tue Sep 25 22:04:45 2001 From: mark at amplex.net (Mark Radabaugh - Amplex) Date: Tue, 25 Sep 2001 22:04:45 -0400 Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: Without commenting on the /29 proposal (OK - /29 is OK with us).... It would help if ARIN would put the information on SWIP requirements, templates, policies, etc. on the web pages rather than burying them on ftp://rs.arin.net. I have rather unsuccessfully looked for that information several times in the past - I finally resorted to calling the help desk. I would speculate that a lot of smaller ISP's that are not SWIP'ing reassignments simply lack the information to do so. Mark Radabaugh Amplex (419) 833-3635 From lhoward at UU.NET Wed Sep 26 12:14:50 2001 From: lhoward at UU.NET (Lee Howard) Date: Wed, 26 Sep 2001 12:14:50 -0400 (EDT) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: I'll say again that I don't feel strongly about this. If we're going to have an arbitrary size limit on required SWIPs, /28 is just as arbitrary as /29. It does seem to beg the question, "What is the purpose of WHOIS?" Specifically, what is it about /24 objects that makes them more useful than /29? If it's because smaller allocations list the upstream ISP as the POC, well that's contrary to policy, and I don't think it's a good reason to change other policies. As for the fact that manual SWIPs are time-consuming for you and yours, if I were able to write a Perl script that would automatically send a SWIP to ARIN based on information stored in a MySQL database, and then distribute that tool and provide a tutorial at the next conference, would that be a better solution? I'm sure every ISP of any size has some way of tracking IP allocations, but it could be a spiral notebook, flat file, MS-Excel, MS-Access, up to an Oracle database. Would you, the smaller ISP, be able to take the time to learn, install, configure and train on a tool like that, and if so, would it save the time you're losing on /29s? I won't go so far as to write a web front-end to allocate IPs and automatically SWIP--it's just too much. Would it be better to have a tutorial on how to set up and manage an RWHOIS server? If RWHOIS could be set up in an hour, and either queried or mirrored your existing databases (even if it required you to convert to flat files or something SQL), no updates would be required by your staff or by ARIN's staff. I think helping you (and other smaller ISPs) automate is probably a better solution than moving already arbitrary boundaries. Lee On Tue, 25 Sep 2001, David R Huberman wrote: > Date: Tue, 25 Sep 2001 16:57:28 -0700 (MST) > From: David R Huberman > To: Lee Howard > Cc: ppml at arin.net > Subject: Re: Policy Proposal 2001-1 > > > > Given that such a policy exists, do we need to alter the minimum SWIP > > size? > > I had brought this up for discussion not so much for the privacy policy, > but because I feel the /29s in the ARIN WHOIS database are mostly "useless > objects" - in part, due to the policy. > > In an effort to lessen the burden on small- and medium-sized ISPs who SWIP > manually, and in an effort to lessen the burden on ARIN which manually > process thousands of SWIPs a day, and in conjunction with my stated belief > that so many /29s are home networks containing upstream POC information, > this discussion seemed appropriate. > > /david > From huberman at gblx.net Wed Sep 26 12:31:38 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 26 Sep 2001 09:31:38 -0700 (MST) Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: > It does seem to beg the question, "What is the purpose > of WHOIS?" Specifically, what is it about /24 objects that makes them > more useful than /29? The requirement for public reassignments is to, among other things, provide a public accounting for who is really using IP space and, when necessary, to provide contact information for that end-user to the broader public. > If it's because smaller allocations list the upstream ISP as the POC, > well that's contrary to policy, and I don't think it's a good reason > to change other policies. My assertion is that a large percentage of /29 assignment list the upstream as POC *because* of the privacy policy ARIN adopted in light on the increased use of IPs by private residential networks. Over time, the consequence of this privacy policy is a decreased usefulness of /29 reassignment info. But I'm making no judgement here - I'm simply stating that for this reason, and to lessen work load for what seems to be a futile task, we move the boundary to a more useful subnet - /28. From randy at psg.com Wed Sep 26 13:13:08 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 10:13:08 -0700 Subject: Policy Proposal 2001-3 References: Message-ID: > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy and Members > meetings in Miami, scheduled for October 28 - 31, 2001. All feedback > received on the mailing lists about this policy proposal will be > included in the discussions that will take place in Miami. > > Proposal: Extend the existing IPv4 micro-allocation policy for > exchange points, gTLDs, ccTLDs, RIRs, and ICANN to > include IPv6 micro-allocations. ARIN's current IPv4 > micro-allocation policy is documented at: > > http://www.arin.net/regserv/ip-assignment.html as, imiho, all this stuff except for IXen is absolutely useless, i see no need to extend it to v6. the dns protocols provide the redundancy to handle the dns servers as well as a 'golden' space. if you think otherwise, please describe your failure model. why the heck do rirs need special address space? they can justify it like the rest of us. eat your own dog food. and why does icann need any address space at all? after all, they have usa today! :-)/2 but i do see micro-allocations for ixen as very useful. randy From mborchers at splitrock.net Wed Sep 26 13:28:34 2001 From: mborchers at splitrock.net (Borchers, Mark) Date: Wed, 26 Sep 2001 12:28:34 -0500 Subject: Policy Proposal 2001-1 Message-ID: > The requirement for public reassignments is to, among other things, > provide a public accounting for who is really using IP space and, when > necessary, to provide contact information for that end-user > to the broader public. The trend in recent years has certainly been toward smaller block assignments. Customers who formerly qualified for a /24 now being given /27's by their ISPs and so on. This fact would seem to militate for putting more information into WHOIS for small blocks. > My assertion is that a large percentage of /29 assignment list the > upstream as POC *because* of the privacy policy ARIN adopted > in light on > the increased use of IPs by private residential networks. Hmm, the networks themselves may be private but they are on public IP space. The privacy issue could be debated at length. From Trevor.Paquette at TeraGo.ca Wed Sep 26 13:47:49 2001 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Wed, 26 Sep 2001 11:47:49 -0600 Subject: Policy Proposal 2001-1 In-Reply-To: Message-ID: <002301c146b3$5b85cbf0$3102a8c0@teraint.net> The issue here seems to be to reduce the workload at ARIN regarding the increasing number of /29 allocations. I'd like to see all allocations SWIPed; and give ARIN the tools to automate this task. (This should not be that hard; should it?) Mant ISPs get calls and email saying 'your server at A.B.C.D' is being used as a spam relay or is infected with such-and-such virus. Because this IP is in a /30 subnet assigned to a customer; the ISP get the email and has to act as relay to inform the customer. If the /30 subnet was SWIPed the ISP would not need to be involved. In my opinion subnet allocations are getting smaller, even for busineses. As IPv4 space begins to run out; more folks will only be allocated a /29 instead of the /28 or /27 that they requested. This will increase the burdon on the upstream ISP to take calls and emails on systems that they have no control over. From ahp at hilander.com Wed Sep 26 13:56:57 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 11:56:57 -0600 Subject: Policy Proposal 2001-3 References: Message-ID: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Member Services" Cc: ; Sent: Wednesday, September 26, 2001 11:13 Subject: Re: Policy Proposal 2001-3 > > as, imiho, all this stuff except for IXen is absolutely useless, i see no > need to extend it to v6. > > the dns protocols provide the redundancy to handle the dns servers as well > as a 'golden' space. if you think otherwise, please describe your failure > model. If you call waiting for timeouts an acceptable method of failover then I suppose you're right. I however don't agree. Alec From randy at psg.com Wed Sep 26 13:58:33 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 10:58:33 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: >> the dns protocols provide the redundancy to handle the dns servers as well >> as a 'golden' space. if you think otherwise, please describe your failure >> model. > If you call waiting for timeouts an acceptable method of failover then I > suppose you're right. I however don't agree. and how does using some specified address space change this? From ahp at hilander.com Wed Sep 26 13:59:25 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 11:59:25 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <0f5901c146b4$facf6d00$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: "Member Services" ; ; Sent: Wednesday, September 26, 2001 11:58 Subject: Re: Policy Proposal 2001-3 > and how does using some specified address space change this? Because it makes multi-homing on a small block of address space feasible. Alec From randy at psg.com Wed Sep 26 14:03:44 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:03:44 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: >>> the dns protocols provide the redundancy to handle the dns servers as >>> well as a 'golden' space. if you think otherwise, please describe your >>> failure model. >> If you call waiting for timeouts an acceptable method of failover then I >> suppose you're right. I however don't agree. > Because it makes multi-homing on a small block of address space feasible. and how is it infeasible now? you may want to look at the address space the roots and gtlds are in now before answering. and how does being multi-homed mean that one will not time out on the server if the deamon is dead but the box is up and reachable? and do note that the long timeout is not relevant if the box is not reachable. the golden space snake oil has been available to roots for some years. how many use it? perhaps root operators have actually studied the issues and voted with their feet? randy From ahp at hilander.com Wed Sep 26 14:09:57 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 12:09:57 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 12:03 Subject: Re: Policy Proposal 2001-3 > > and how is it infeasible now? you may want to look at the address space the > roots and gtlds are in now before answering. Are you suggesting that new gTLD servers are never going to be deployed, or that existing ones will not change? > > and how does being multi-homed mean that one will not time out on the server > if the deamon is dead but the box is up and reachable? It doesn't. However, ARIN cannot address issues of operator error on a server. If you would like ARIN to be able to do this, I suggest you lobby the AC. > > and do note that the long timeout is not relevant if the box is not > reachable. True, but if the appropriate internet connection is down then it is very relevant, and I see the type of errors you describe above as being relatively few. > > the golden space snake oil has been available to roots for some years. how > many use it? perhaps root operators have actually studied the issues and > voted with their feet? *shrug*, perhaps. I'd like to see your data on this instead changing a ratified AC proposal based on your straw-man. Alec From markk at netsol.com Wed Sep 26 14:09:50 2001 From: markk at netsol.com (Mark Kosters) Date: Wed, 26 Sep 2001 14:09:50 -0400 Subject: Policy Proposal 2001-3 In-Reply-To: ; from randy@psg.com on Wed, Sep 26, 2001 at 11:03:44AM -0700 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> Message-ID: <20010926140950.P1105@slam.admin.cto.netsol.com> On Wed, Sep 26, 2001 at 11:03:44AM -0700, Randy Bush wrote: > the golden space snake oil has been available to roots for some years. how > many use it? perhaps root operators have actually studied the issues and > voted with their feet? Cause all the roots got their snake oil before it was termed golden space. Bigger question is before we throw all this out, we need to closely look the number of unique addresses we want to have active to bootstrap the system query. Mark -- Mark Kosters markk at netsol.com Verisign Applied Research From randy at psg.com Wed Sep 26 14:45:34 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:45:34 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <20010926140950.P1105@slam.admin.cto.netsol.com> Message-ID: > Bigger question is before we throw all this out, we need to closely look > the number of unique addresses we want to have active to bootstrap the > system query. it seems to me that richness of diversity in this is good. i.e. i find the roots's address space diversity more apprealing than the gtlds. though i admit i can not easily expresss why. for a new rathole, the prepends don't cheer me. am i off in this? randy --- a.root-servers.net 198.41.0.0/24 7018 10913 10913 10913 10913 19836 2914 10913 10913 10913 10913 10913 10913 19836 b.root-servers.net 128.9.0.0/16 2914 226 7018 2914 226 c.root-servers.net 192.33.4.0/24 2914 174 174 174 174 2149 7018 174 2149 d.root-servers.net 128.8.0.0/16 2914 209 27 7018 209 27 e.root-servers.net 192.203.230.0/24 7018 297 2914 297 f.root-servers.net 192.5.4.0/23 2914 6461 3557 7018 701 3557 g.root-servers.net 192.112.36.0/24 7018 209 568 5927 2914 209 568 5927 h.root-servers.net 128.63.0.0/16 2914 7170 13 7018 7170 13 i.root-servers.net 192.36.148.0/24 2914 1239 1880 8674 7018 1239 1880 8674 j.root-servers.net 198.41.0.0/24 7018 10913 10913 10913 10913 19836 2914 10913 10913 10913 10913 10913 10913 19836 k.root-servers.net 193.0.14.0/24 7018 3561 5378 5459 2914 5413 5413 5459 l.root-servers.net 198.32.64.0/24 2914 20144 7018 2914 20144 m.root-servers.net 202.12.27.0/24 2914 2516 7500 7018 3549 2518 7500 a.gtld-servers.net 192.5.6.0/24 7018 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 2914 10913 10913 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 b.gtld-servers.net 192.33.14.0/24 2914 209 1668 6992 7018 209 1668 6992 c.gtld-servers.net 192.26.92.0/24 2914 6461 1668 10593 7018 1668 10593 d.gtld-servers.net 192.31.80.0/24 7018 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 2914 10913 10913 10913 10913 10913 10913 11840 19836 19836 19836 19836 19836 19836 19836 19836 19836 19836 e.gtld-servers.net 192.12.94.0/24 2914 2516 7018 209 2516 f.gtld-servers.net 192.35.51.0/24 2914 701 14744 7018 14744 14744 14744 14744 g.gtld-servers.net 192.42.93.0/24 2914 701 7342 7018 7342 h.gtld-servers.net 192.54.112.0/24 2914 1239 1755 13214 7018 1239 1755 13214 i.gtld-servers.net 192.36.144.0/24 2914 1239 1880 8674 7018 1239 1880 8674 j.gtld-servers.net 210.132.96.0/19 2914 2516 7018 701 2516 k.gtld-servers.net 213.177.192.0/21 2914 1239 1755 13214 7018 1239 1755 13214 l.gtld-servers.net 192.41.162.0/24 2914 701 14745 7018 14745 14745 14745 14745 m.gtld-servers.net 202.153.112.0/20 2914 4637 9925 7018 701 4637 9925 -30- From randy at psg.com Wed Sep 26 14:47:22 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 11:47:22 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> Message-ID: > *shrug*, perhaps. I'd like to see your data on this instead changing a > ratified AC proposal based on your straw-man. let's just say that, imiho, ac proposals have been varied, to be polite. so i try to stick with the technical engineering, not the social. randy From ahp at hilander.com Wed Sep 26 14:58:11 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 12:58:11 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> Message-ID: <107001c146bd$305c6790$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 12:47 Subject: Re: Policy Proposal 2001-3 > > let's just say that, imiho, ac proposals have been varied, to be polite. > so i try to stick with the technical engineering, not the social. Well the discussion has proceeded over a rather long period of time, to be sure. However to my knowledge gTLD servers have always been part of all of the proposals. Alec From randy at psg.com Wed Sep 26 15:11:59 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:11:59 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> Message-ID: > Well the discussion has proceeded over a rather long period of time a process improvement, indeed. as is this public discussion. thanks arin. > gTLD servers have always been part of all of the proposals. if having servers in 'special' space has yet to be shown to improve use, why is not not appropriate to treat them just as we do all others? they can get routable space from theu upstreams or justify space if their needs are large enough. and, if the above does not work, then maybe the whole model is broken for many many people. and you may not want to go there. randy --- # grep \"..\" /etc/named.conf | wc 21 153 975 From memsvcs at arin.net Wed Sep 26 15:24:00 2001 From: memsvcs at arin.net (Member Services) Date: Wed, 26 Sep 2001 15:24:00 -0400 (EDT) Subject: Policy Proposal 2001-5 Message-ID: ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. Proposal: Establish a micro-assignment policy that would allow entities, using multihoming as justification, to obtain an assignment from ARIN longer than the current minimum assignment size of a /20. This policy proposal discussion will take place on the public policy mailing list (ppml at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From ahp at hilander.com Wed Sep 26 15:38:13 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:38:13 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com> Message-ID: <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:11 Subject: Re: Policy Proposal 2001-3 > > > gTLD servers have always been part of all of the proposals. > > if having servers in 'special' space has yet to be shown to improve use, > why is not not appropriate to treat them just as we do all others? they > can get routable space from theu upstreams or justify space if their needs > are large enough. What do you mean by use? The whole idea behind the micro-allocations from the beginning was the notion that some pieces of infrastructure: a) Really do need their own PI blocks b) don't consume enough IP addresses to meet standard requirements. The goal was to put guidelines around which infrastructure met these requirements. Alec From randy at psg.com Wed Sep 26 15:43:25 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:43:25 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> Message-ID: >> if having servers in 'special' space has yet to be shown to improve use, >> why is not not appropriate to treat them just as we do all others? they >> can get routable space from theu upstreams or justify space if their needs >> are large enough. > What do you mean by use? reasonable results when querying the servers using the dns protocols. > The whole idea behind the micro-allocations from the beginning was the notion > that some pieces of infrastructure: > a) Really do need their own PI blocks and i have yet to see this assertion supported technically for anything but IXen randy From ahp at hilander.com Wed Sep 26 15:44:30 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:44:30 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com> Message-ID: <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:43 Subject: Re: Policy Proposal 2001-3 > > > The whole idea behind the micro-allocations from the beginning was the notion > > that some pieces of infrastructure: > > a) Really do need their own PI blocks > > and i have yet to see this assertion supported technically for anything but > IXen Well it looks like we've gotten back to the beginning, with you asserting that DNS's ability to handle failures is sufficient, and my assertion that said ability is not acceptable. Alec From randy at psg.com Wed Sep 26 15:46:30 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:46:30 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: > Well it looks like we've gotten back to the beginning, with you asserting > that DNS's ability to handle failures is sufficient, and my assertion that > said ability is not acceptable. as the rfcs support my argument, please state yours in similar technical terms. randy From ahp at hilander.com Wed Sep 26 15:47:42 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:47:42 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:46 Subject: Re: Policy Proposal 2001-3 > > as the rfcs support my argument, please state yours in similar technical > terms. It's pretty simple. Waiting for requests to timeout is not an optimal solution for failover. Alec From ahp at hilander.com Wed Sep 26 15:49:54 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:49:54 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> Message-ID: <112201c146c4$69e05b50$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:46 Subject: Re: Policy Proposal 2001-3 > > as the rfcs support my argument, please state yours in similar technical > terms. And just because that's how it is done now does not qualify as an argument. Alec From randy at psg.com Wed Sep 26 15:50:47 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 12:50:47 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> Message-ID: > Waiting for requests to timeout is not an optimal solution for failover. maybe you missed the following message, critical parts flagged From: Randy Bush To: "Alec H. Peterson" Cc: v6wg at arin.net, ppml at arin.net Subject: Re: Policy Proposal 2001-3 Date: Wed, 26 Sep 2001 11:03:44 -0700 >>> the dns protocols provide the redundancy to handle the dns servers >>> as well as a 'golden' space. if you think otherwise, please >>> describe your failure model. >> If you call waiting for timeouts an acceptable method of failover >> then I suppose you're right. I however don't agree. > Because it makes multi-homing on a small block of address space > feasible. and how is it infeasible now? you may want to look at the address space the roots and gtlds are in now before answering. ** and how does being multi-homed mean that one will not time out on the ** server if the deamon is dead but the box is up and reachable? ** and do note that the long timeout is not relevant if the box is not ** reachable. the golden space snake oil has been available to roots for some years. how many use it? perhaps root operators have actually studied the issues and voted with their feet? randy From ahp at hilander.com Wed Sep 26 15:55:28 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 13:55:28 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com><111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> Message-ID: <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 13:50 Subject: Re: Policy Proposal 2001-3 > > Waiting for requests to timeout is not an optimal solution for failover. > > maybe you missed the following message, critical parts flagged Randy, I've always thought you were good at making solid arguments, but this is just hilarious. Your assertion that DNS timeouts work fine in 'some failure modes' is nothing short of laughable, especially since being able to multi-home effectively will work fine in the failure modes you describe, plus the ones where a single service provider causes an otherwise single-homed address to be unreachable. Furthermore, your apparent intentional ignorance of these points that I have mentioned in other messages is also rather amusing. Unless you actually have something new to add to this discussion I think we're done here. Alec From randy at psg.com Wed Sep 26 16:05:04 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 13:05:04 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> Message-ID: > Your assertion that DNS timeouts work fine in 'some failure modes' alex, i suspect that you have a problem with your mail user agent. i never said any such thing, at least not in today's mail. i just grepped it. other things also make me suspect you have a problem with your mail reading agent. have a great day. randy From ahp at hilander.com Wed Sep 26 16:12:40 2001 From: ahp at hilander.com (Alec H. Peterson) Date: Wed, 26 Sep 2001 14:12:40 -0600 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com><0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com><107001c146bd$305c6790$3220f1d8@windows.hilander.com><10e601c146c2$c8409540$3220f1d8@windows.hilander.com><10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com><111801c146c4$1af73ef0$3220f1d8@windows.hilander.com><112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> Message-ID: <118401c146c7$b531f1b0$3220f1d8@windows.hilander.com> ----- Original Message ----- From: "Randy Bush" To: "Alec H. Peterson" Cc: ; Sent: Wednesday, September 26, 2001 14:05 Subject: Re: Policy Proposal 2001-3 > > alex, Since you can't even get my name right I suspect it is you who is having the literacy problem. > i suspect that you have a problem with your mail user agent. i > never said any such thing, at least not in today's mail. i just grepped > it. other things also make me suspect you have a problem with your > mail reading agent. Perhaps 'working fine' was not an accurate paraphrasing, however: [snip] and how does being multi-homed mean that one will not time out on the server if the deamon is dead but the box is up and reachable? and do note that the long timeout is not relevant if the box is not reachable. [snip] Which to my mind was your assertion that there are some things PI space won't fix. You will also note I did not dispute your assertions, but rather pointed out that they were beyond the scope of the discussion. Just to remind everybody (and you Randy since apparently you have forgotten) the discussion at hand is whether to modify ARIN allocation policy to allow critical DNS server (gTLD, ccTLD, etc) to get small, PI blocks of address space directly from ARIN. From my standpoint, the main reason to do this is to allow such servers to multi-home effectively, to improve reliability. Randy has asserted that is not necessary, since DNS timeouts accomplish the same thing with respect to reliablity. I would agree, if we changed it to mean 'eventual reliability'. However, I personally feel we can do better than eventual reliability, and since we can we very well should. Allowing critical DNS servers to multi-home makes it so it is less likely that clients querying these servers will need to resort to waiting for queries to timeout. Instead, those queries are more likely to be answered on the first try, since the network connectivity for the server can be provided by multiple providers easily. But then, I must be wrong, because the RFCs say so, and we know they're always right. Alec From randy at psg.com Wed Sep 26 16:17:25 2001 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2001 13:17:25 -0700 Subject: Policy Proposal 2001-3 References: <0f4501c146b4$a2abf300$3220f1d8@windows.hilander.com> <0f9d01c146b6$733d1660$3220f1d8@windows.hilander.com> <107001c146bd$305c6790$3220f1d8@windows.hilander.com> <10e601c146c2$c8409540$3220f1d8@windows.hilander.com> <10fe01c146c3$a91817a0$3220f1d8@windows.hilander.com> <111801c146c4$1af73ef0$3220f1d8@windows.hilander.com> <112e01c146c5$30dbd720$3220f1d8@windows.hilander.com> <118401c146c7$b531f1b0$3220f1d8@windows.hilander.com> Message-ID: > Just to remind everybody (and you Randy since apparently you have > forgotten) the discussion at hand is whether to modify ARIN allocation > policy to allow critical DNS server (gTLD, ccTLD, etc) to get small, PI > blocks of address space directly from ARIN. Date: Wed, 26 Sep 2001 11:17:21 -0400 (EDT) From: Member Services To: arin-announce at arin.net, v6wg at arin.net Subject: Policy Proposal 2001-3 ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. Proposal: Extend the existing IPv4 micro-allocation policy for exchange points, gTLDs, ccTLDs, RIRs, and ICANN to include IPv6 micro-allocations. ARIN's current IPv4 micro-allocation policy is documented at: http://www.arin.net/regserv/ip-assignment.html This policy proposal discussion will take place on the IPv6 working group mailing list (v6wg at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers From martind at UU.NET Thu Sep 27 10:35:04 2001 From: martind at UU.NET ( dawn martin) Date: Thu, 27 Sep 2001 10:35:04 -0400 Subject: Policy Proposal 2001-1 In-Reply-To: <002301c146b3$5b85cbf0$3102a8c0@teraint.net> Message-ID: <001b01c14761$9995dda0$0a0a0a0a@lteng122> I would have to agree here, if it is so much work to get the SWIPs put into ARIN, then they need better automation (they already know this). But, how much more work is it going to be for your helpdesk to answer for all the SPAM that is getting sent on a certain block. If you don't feel that this is an issue, than why do we SWIP at all? If your helpdesk has the extra cycles to handle SPAM enquiries, etc. than let's just stop SWIPing altogether. I for one, wouldn't mind if we could SWIP /32's. -Dawn Martin -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Trevor Paquette Sent: Wednesday, September 26, 2001 1:48 PM To: ppml at arin.net Subject: RE: Policy Proposal 2001-1 The issue here seems to be to reduce the workload at ARIN regarding the increasing number of /29 allocations. I'd like to see all allocations SWIPed; and give ARIN the tools to automate this task. (This should not be that hard; should it?) Mant ISPs get calls and email saying 'your server at A.B.C.D' is being used as a spam relay or is infected with such-and-such virus. Because this IP is in a /30 subnet assigned to a customer; the ISP get the email and has to act as relay to inform the customer. If the /30 subnet was SWIPed the ISP would not need to be involved. In my opinion subnet allocations are getting smaller, even for busineses. As IPv4 space begins to run out; more folks will only be allocated a /29 instead of the /28 or /27 that they requested. This will increase the burdon on the upstream ISP to take calls and emails on systems that they have no control over. From memsvcs at arin.net Fri Sep 28 10:55:10 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 28 Sep 2001 10:55:10 -0400 (EDT) Subject: Policy Proposal 2001-6 Message-ID: <200109281455.KAA04036@ops.arin.net> ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. The policy proposal stated below addresses how ARIN reviews IP address space requests from single organizations with large multi-homed discrete networks. This issue was discussed at the last ARIN public policy meeting and has since been discussed on the public policy mailing list. The archives for this mailing list are located at http://www.arin.net/mailinglists/ppml/index.html This policy proposal discussion will continue to take place on the public policy mailing list (ppml at arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers **Proposed Allocation Policy for: Single organizations with large multi-homed discrete networks ARIN currently has an allocation policy that is 'blind' to route Filtering and global routablity, yet in order for address space to be usable it must be accepted and routed by the community at large. This fact can create allocation concerns for organizations that have multiple discrete multi-homed networks. Organizations may design their networks in this manner for a number of reasons including regulatory restrictions (Federal FCC mandated inter-lata restrictions), geographic diversity/distance between networks, and routing policy. Current RIR allocation policy requires that before a single organization can obtain additional address space it must show 80% utilization (through SWIP or rWhois) per RFC 2050. Currently, some organizations have circumvented this requirement by Creating "multiple maintainers" with ARIN and request address space for networks as though they were separate organizations. This practice creates both practical and financial concerns for ARIN. In practice it appears that organizations can just 'buy' additional address space without regard to utilization on other networks and this in turn increases ARIN's revenue dependence on a small number of organizations. Current allocation requirements can become unreasonable when operating a set of discrete networks for organizations which intend on following the current allocations policy. Discrete networks must often have separate unique globally routable address space and will often grow at different rates. This growth differential can lead to a situation where one discrete network is completely allocated but another network has not yet been fully utilized. Under the current allocation policy the organization would need to Request additional address space from the RIR; however, given a strict interpretation of the existing policy, the RIR may not be able to grant additional address space to the organization, due to the 80% utilization requirement. This constraint can easily be seen when you consider an organization with two geographically discrete autonomous networks. The organization initially requested a /19 from the RIR for its two networks with the intent to route a single /20 from each network. Network A's utilization grows considerably faster than Network B. Network A is currently showing 90% utilization and needs additional address space for new customers being added to this network. Network B's address space is being utilized but currently only shows 40% utilization. This would produce an allocation utilization percentage of 65% which is below the requirement for additional address space by a RIR. We propose for organizations which meet the following criteria to be granted the opportunity to request additional address space under the requirements listed below. Criteria for the application of this policy: * The organization should be a single entity, and not a consortium of smaller independent entities. (Example: Not a group of independent network operators who form a group specifically for this policy) * This policy applies only to organizations that have been previously granted address space by an RIR. This policy does not apply to organizations with only legacy address space. * The organization must have multiple (at least two) discrete multi-homed networks. * The organization must have a compelling criteria for creating discrete networks. Examples: 1) regulatory restrictions for data transmission 2) geographic distance and diversity between networks 3) autonomous multi-homed discrete networks * The organization must apply for this policy to be applied to their account. * Organizations with 'multiple maintainers' should request that this policy apply to their accounts, their existing allocations merged, and additional allocations will fall under this policy. * Upon adoption the use of 'multiple maintainers' for a single organization should not be permitted. These organizations should then use this policy to govern additional allocations. Requirements for additional allocations from RIR: * The organization must record allocations or assignments down to the /29 level for all downstream networks via rWhois, SWIP, or approved RIR public database. * The organization must keep detailed records of how it has allocated space to each discrete network. This should include the block allocated, any reserved blocks, and date of allocation. The allocation information should also be present in a public database via a routing registry, rWhois, or via SWIP. * The organization must not allocate additional space to a discrete network unless all the blocks allocated to that network show utilization greater than 80% individually and as a whole. * The organization must not allocate a CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to a new network. * The organization must not allocate an additional CIDR block larger than the current minimum assignment size of the RIR (currently /20 for ARIN) to an existing network, unless previous growth rates for that network indicate that it is likely to utilize a larger CIDR block before the time the organization will be requesting an additional block from the RIR. The suggested minimum allocation size for an additional block for a network is the current minimum assignment size of the RIR. * When allocating a block larger than the minimum assignment size to an existing network the organization should use the smallest allocation possible out of a larger reserved block. This requirement is to reduce the number of routes the organization will announce from that autonomous system. Example: A fast growing network is allocated a /20 out of a reserved /19, when the /20 is 80% utilized the announcement is expanded to a /19 and the /20 announcement is removed. This practice also allows the reserved /20 to be used by another discrete network should the 'fast growing network' not use the address space as anticipated. * When applying for additional address space, from an RIR, for new networks or additional space for existing networks the organization must show greater than 50% utilization for the last block granted by the RIR and their allocations as a whole. * The organization must follow guidelines of RFC 2050 (or its replacement) and the policy of the granting RIR for allocations that are assigned or allocated to downstream networks. This includes record keeping of allocation requests and network utilization documents for audits by the RIR. From memsvcs at arin.net Fri Sep 28 17:26:05 2001 From: memsvcs at arin.net (Member Services) Date: Fri, 28 Sep 2001 17:26:05 -0400 (EDT) Subject: ASO AC Candidates Announced Message-ID: The following individuals have been nominated to run for the open seat on the ASO Address Council in the ARIN region, becoming vacant with the expiration of Raimundo Beca's term on December 31, 2001. The seat is a three year term expiring December 31, 2004. Timothy J. Biggs Dewey Coffman Eric B. Decker Christopher Faulkner Greg Hiscott Rob Leon Peter Schroebel Candidate bios and a form for voicing support can be found on the ARIN website at: http://www.arin.net/aso/asonominees.htm The ASO AC election will begin online for ARIN members at 9:00 AM EDT October 22,and will close at 6:00 PM, October 29. All attendees at the October 29 ARIN Public Policy meeting in Miami, FL will be eligible to vote onsite. The winner will be announced on October 30. Ray Plzak President From memsvcs at arin.net Sat Sep 29 09:33:17 2001 From: memsvcs at arin.net (Member Services) Date: Sat, 29 Sep 2001 09:33:17 -0400 (EDT) Subject: Fall Issue of ARIN Today Available Online Message-ID: The second issue of ARIN's quarterly newsletter, ARIN Today, is now available in pdf format online at: www.arin.net/ See the announcement link. Comments concerning the newsletter and expressions of interest in submitting articles for future editions should be sent to member-services at arin.net Regards, Susan Hamlin Director, Member Services