From ron at aol.net Mon Dec 2 13:21:34 2002 From: ron at aol.net (Ron da Silva) Date: Mon, 2 Dec 2002 13:21:34 -0500 Subject: [ppml] Question? In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB490@msmdcfs01.msmgmt.com> References: <390E55B947E7C848898AEBB9E50770600EB490@msmdcfs01.msmgmt.com> Message-ID: <20021202182134.GF3670@aol.net> On Sat, Nov 30, 2002 at 12:45:43PM -0500, McBurnett, Jim wrote: > > What I propose is that...[we] start a committee of a few folks from > each RIR, the IETF, IANA, and a few other organizations and fix this... Ok, committee could be a good idea, but we need to better articulate what 'this' is, clear expectations of outcome and measure of success. To what problem would this committee be expected to create a solution? Also, what would the committee do with the result? I suspect that at best the committee would be able to "suggest" a solution to its constituents. -ron From jmcburnett at msmgmt.com Mon Dec 2 14:59:35 2002 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Mon, 2 Dec 2002 14:59:35 -0500 Subject: [ppml] Question? Message-ID: <390E55B947E7C848898AEBB9E50770600EB495@msmdcfs01.msmgmt.com> Purpose: To design a method of stopping SPAMmers that becomes a standard rather that the current haphazard Blacklist approach. This should include creation of new procedures and methods by the industry with the aid of IETF engineering to identify and to correct the problem in a politically correct manner. (I hate to say it this way, but to say: Shut down the Spammers T-1 is not quite the correct approach, however gratifying it may be) Outcome: An RFC or other similar document with guidelines defining SPAM, listing unacceptable practices to limit or stop abuses of individuals or companies. Along with as clear, concise (as much as it can be coming from a commitee) language that defines SPAM and the possible actions that are recommended to ISP's, End users, and Domain Admins to fight it. Finally: If the committee comes out and says: Should a block of Address from ISP A is identified as being a massive SPAMer, then the AUP's from it's provider with support from the community at large and the RIR's, IETF, IANA, may take these actions, I believe many will adopted it, and the ones who refuse will become the minority since the current outcry about SPAM is just going to grow. Folks, we are on the verge of email becoming the next snail mail if we sit back and watch and allow the junk to flow. If anyone follows the news and the FTC's actions on junk mail, how can we not think about some kind of action? Did you enjoy getting 5,10 or 20 pieces of junk mail daily from the US Postal Service when this was the norm? Suggestions anyone? Jim -----Original Message----- From: Ron da Silva [mailto:ron at aol.net] Sent: Monday, December 02, 2002 1:22 PM To: ppml at arin.net Subject: Re: [ppml] Question? On Sat, Nov 30, 2002 at 12:45:43PM -0500, McBurnett, Jim wrote: > > What I propose is that...[we] start a committee of a few folks from > each RIR, the IETF, IANA, and a few other organizations and fix this... Ok, committee could be a good idea, but we need to better articulate what 'this' is, clear expectations of outcome and measure of success. To what problem would this committee be expected to create a solution? Also, what would the committee do with the result? I suspect that at best the committee would be able to "suggest" a solution to its constituents. -ron From memsvcs at arin.net Mon Dec 2 15:09:07 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 2 Dec 2002 15:09:07 -0500 (EST) Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: <200212022009.PAA16314@ops.arin.net> During the Final Call for Policy Proposal 2002-2 (http://www.arin.net/policy/2002_2.html) there was discussion that the policy implied standards processes bodies other then the IETF might be used and that the IETF regards of itself as the standards body at the IP address layer. Due to this discussion the ARIN Advisory Council voted during a meeting (conference call) on Nov 22 not to forward Policy Proposal 2002-2 to the BoT for further consideration. The decision was to post the policy back to the PPML mailing list for further discussion to aid in resolving the issue mentioned above. So in accordance with the ARIN Advisory Council's decision we are asking for further discussion on Policy Proposal 2002-2. We are specifically looking for guidance on the issue above and ask that any IETF or IAB members provide input if possible. Thank you. John Sweeting ARIN Advisory Council From mcf at uwm.edu Mon Dec 2 15:20:03 2002 From: mcf at uwm.edu (Mark McFadden) Date: Mon, 2 Dec 2002 14:20:03 -0600 Subject: [ppml] Question? References: <390E55B947E7C848898AEBB9E50770600EB495@msmdcfs01.msmgmt.com> Message-ID: <010701c29a40$32ace010$b6985981@ucce.uwm.edu> Is RFC 2505 insufficient, or perhaps not comprehensive enough? There's also been other work done: http://www.ripe.net/ripe/docs/spam.html It seems to me that what we need is a version of SMTP where the "sender pays" in some sense. Otherwise, we are stuck with the SMTP that has the feature of costing the sender exactly the same -- whether one address is in the header or one million are. mark Mark McFadden Internet/Web Technology Programs UW-Milwaukee mcf at uwm.edu ----- Original Message ----- From: "McBurnett, Jim" To: "Ron da Silva" ; Sent: Monday, December 02, 2002 1:59 PM Subject: RE: [ppml] Question? > Purpose: > To design a method of stopping SPAMmers that becomes a standard rather that the current haphazard Blacklist approach. > This should include creation of new procedures and methods by the industry with the aid of IETF engineering to identify and to correct the problem in a politically correct manner. (I hate to say it this way, but to say: Shut down the Spammers T-1 is not quite the correct approach, however gratifying it may be) > > Outcome: An RFC or other similar document with guidelines defining SPAM, listing unacceptable practices to limit or stop abuses of individuals or companies. > Along with as clear, concise (as much as it can be coming from a commitee) language that defines SPAM and the possible actions that are recommended to ISP's, End users, and Domain Admins to fight it. > > Finally: If the committee comes out and says: > Should a block of Address from ISP A is identified as being a massive SPAMer, then the AUP's from it's provider with support from the community at large and the RIR's, IETF, IANA, may take these actions, I believe many will adopted it, and the ones who refuse will become the minority since the current outcry about SPAM is just going to grow. > > Folks, we are on the verge of email becoming the next snail mail if we sit back and watch and allow the junk to flow. > If anyone follows the news and the FTC's actions on junk mail, how can we not think about some kind of action? > Did you enjoy getting 5,10 or 20 pieces of junk mail daily from the US Postal Service when this was the norm? > > Suggestions anyone? > > > Jim > -----Original Message----- > From: Ron da Silva [mailto:ron at aol.net] > Sent: Monday, December 02, 2002 1:22 PM > To: ppml at arin.net > Subject: Re: [ppml] Question? > > > On Sat, Nov 30, 2002 at 12:45:43PM -0500, McBurnett, Jim wrote: > > > > What I propose is that...[we] start a committee of a few folks from > > each RIR, the IETF, IANA, and a few other organizations and fix this... > > Ok, committee could be a good idea, but we need to better articulate > what 'this' is, clear expectations of outcome and measure of success. > To what problem would this committee be expected to create a solution? > Also, what would the committee do with the result? I suspect that at > best the committee would be able to "suggest" a solution to its > constituents. > > -ron > > From john at chagres.net Mon Dec 2 15:24:58 2002 From: john at chagres.net (John M. Brown) Date: Mon, 2 Dec 2002 13:24:58 -0700 Subject: [ppml] Question? In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB495@msmdcfs01.msmgmt.com> Message-ID: <001301c29a40$e2811510$f9ecdfd8@laptoy> Hmm, developing a STANDARD to stop spammers means they will find a way to "route around the damage, er, standard". What people seem to fail at understanding is that SPAM is no different, technically speaking, than regular mail. It follows the various RFC's to communicate the bits. People have tried for multiple years to define nice neat little definitions of what SPAM is, how to 100 percent guarantee that a message is SPAM and zap it. So far, I haven't seen any silver bullet that catches 100 percent all spam with no false positives. To have the IETF, RIR's, and others create a standard is myopic at best, and dangerous at worse. SPAM is a social and economic issue. As long as WorldCom and others take money from those that SPAM, the edge of the net is unsecure, and people make money from sending SPAM, it will continue to exist. Bottomline, RIR's, ICANN, IANA, IETF, IESG, IAB, et al are NOT the Police.Net. We should NOT encourage them to be the Police.Net. If enough people don't like SPAM, then march on your state capital, or on Washington DC and get the laws changed. If you don't like that, then stop buying services from those that support spammers. Otherwords vote with your checkbook. I'd suspect that WorldCom would drop a DS1 spammer if they new I recently decided NOT to purchase a DS3 worth of bandwidth becuase of the recent article in which the admitted to supporting spammers as customers. I voted with my checkbook. John Brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, December 02, 2002 1:00 PM > To: Ron da Silva; ppml at arin.net > Subject: RE: [ppml] Question? > > > Purpose: > To design a method of stopping SPAMmers that becomes a > standard rather that the current haphazard Blacklist > approach. This should include creation of new procedures and > methods by the industry with the aid of IETF engineering to > identify and to correct the problem in a politically correct > manner. (I hate to say it this way, but to say: Shut down the > Spammers T-1 is not quite the correct approach, however > gratifying it may be) > > Outcome: An RFC or other similar document with guidelines > defining SPAM, listing unacceptable practices to limit or > stop abuses of individuals or companies. > Along with as clear, concise (as much as it can > be coming from a commitee) language that defines SPAM and the > possible actions that are recommended to ISP's, End users, > and Domain Admins to fight it. > > Finally: If the committee comes out and says: > Should a block of Address from ISP A is identified as > being a massive SPAMer, then the AUP's from it's provider > with support from the community at large and the RIR's, IETF, > IANA, may take these actions, I believe many will adopted it, > and the ones who refuse will become the minority since the > current outcry about SPAM is just going to grow. > > Folks, we are on the verge of email becoming the next snail > mail if we sit back and watch and allow the junk to flow. If > anyone follows the news and the FTC's actions on junk mail, > how can we not think about some kind of action? Did you enjoy > getting 5,10 or 20 pieces of junk mail daily from the US > Postal Service when this was the norm? > > Suggestions anyone? > > > Jim > -----Original Message----- > From: Ron da Silva [mailto:ron at aol.net] > Sent: Monday, December 02, 2002 1:22 PM > To: ppml at arin.net > Subject: Re: [ppml] Question? > > > On Sat, Nov 30, 2002 at 12:45:43PM -0500, McBurnett, Jim wrote: > > > > What I propose is that...[we] start a committee of a few folks from > > each RIR, the IETF, IANA, and a few other organizations and fix > > this... > > Ok, committee could be a good idea, but we need to better > articulate what 'this' is, clear expectations of outcome and > measure of success. To what problem would this committee be > expected to create a solution? Also, what would the committee > do with the result? I suspect that at best the committee > would be able to "suggest" a solution to its constituents. > > -ron > From john at chagres.net Mon Dec 2 15:29:34 2002 From: john at chagres.net (John M. Brown) Date: Mon, 2 Dec 2002 13:29:34 -0700 Subject: [ppml] Question? In-Reply-To: <010701c29a40$32ace010$b6985981@ucce.uwm.edu> Message-ID: <001501c29a41$86f37890$f9ecdfd8@laptoy> Sender pays is a lovely idea, but a PIA to install and maintain. How do you handle false positives?? Or we have to have a complete sender pay system, even for real email. Bad Idea, IMHO, it will have a chilling affect on the freedom to send email, rate zones will get created and it will be called Postal Service. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Mark McFadden > Sent: Monday, December 02, 2002 1:20 PM > To: ppml at arin.net > Subject: Re: [ppml] Question? > > > Is RFC 2505 insufficient, or perhaps not comprehensive enough? > > There's also been other work done: > http://www.ripe.net/ripe/docs/spam.html > > It seems to me that what we need is a version of SMTP where > the "sender pays" in some sense. Otherwise, we are stuck > with the SMTP that has the feature of costing the sender > exactly the same -- whether one address is in the header or > one million are. > > mark > > Mark McFadden > Internet/Web Technology Programs > UW-Milwaukee > mcf at uwm.edu > > ----- Original Message ----- > From: "McBurnett, Jim" > To: "Ron da Silva" ; > Sent: Monday, December 02, 2002 1:59 PM > Subject: RE: [ppml] Question? > > > > Purpose: > > To design a method of stopping SPAMmers that becomes a > standard rather > that the current haphazard Blacklist approach. > > This should include creation of new procedures and methods by the > > industry > with the aid of IETF engineering to identify and to correct > the problem in a politically correct manner. (I hate to say > it this way, but to say: Shut down the Spammers T-1 is not > quite the correct approach, however gratifying it may be) > > > > Outcome: An RFC or other similar document with guidelines defining > > SPAM, > listing unacceptable practices to limit or stop abuses of > individuals or companies. > > Along with as clear, concise (as much as it can be coming from a > > commitee) > language that defines SPAM and the possible actions that are > recommended to ISP's, End users, and Domain Admins to fight it. > > > > Finally: If the committee comes out and says: > > Should a block of Address from ISP A is identified as being > a massive > SPAMer, then the AUP's from it's provider with support from > the community at large and the RIR's, IETF, IANA, may take > these actions, I believe many will adopted it, and the ones > who refuse will become the minority since the current outcry > about SPAM is just going to grow. > > > > Folks, we are on the verge of email becoming the next snail > mail if we > > sit > back and watch and allow the junk to flow. > > If anyone follows the news and the FTC's actions on junk > mail, how can > > we > not think about some kind of action? > > Did you enjoy getting 5,10 or 20 pieces of junk mail daily > from the US > Postal Service when this was the norm? > > > > Suggestions anyone? > > > > > > Jim > > -----Original Message----- > > From: Ron da Silva [mailto:ron at aol.net] > > Sent: Monday, December 02, 2002 1:22 PM > > To: ppml at arin.net > > Subject: Re: [ppml] Question? > > > > > > On Sat, Nov 30, 2002 at 12:45:43PM -0500, McBurnett, Jim wrote: > > > > > > What I propose is that...[we] start a committee of a few > folks from > > > each RIR, the IETF, IANA, and a few other organizations and fix > > > this... > > > > Ok, committee could be a good idea, but we need to better > articulate > > what 'this' is, clear expectations of outcome and measure > of success. > > To what problem would this committee be expected to create > a solution? > > Also, what would the committee do with the result? I > suspect that at > > best the committee would be able to "suggest" a solution to its > > constituents. > > > > -ron > > > > > From pfs at cisco.com Mon Dec 2 19:16:23 2002 From: pfs at cisco.com (Philip Smith) Date: Tue, 03 Dec 2002 10:16:23 +1000 Subject: [ppml] Open discussion on Policy Proposal 2002-2 In-Reply-To: <200212022009.PAA16314@ops.arin.net> Message-ID: <5.1.0.14.2.20021203101055.00ae2d70@lint.cisco.com> I'd be curious to know where the Advisory Council found the text which referred to standards process bodies other than the IETF. The proposal referred to the concept that entities other than the IETF may wish to carry out publicly recorded experiments which require Internet resources on a temporary basis. Surely we aren't implying here that the IETF is the only organisation allowed to carry out experiments on the Internet? Where is this documented? Who is enforcing it? Who in the IETF does anyone have to go to before they are permitted to experiment on the Internet? philip -- At 15:09 02/12/2002 -0500, Member Services wrote: >During the Final Call for Policy Proposal 2002-2 >(http://www.arin.net/policy/2002_2.html) there was discussion >that the policy implied standards processes bodies other then >the IETF might be used and that the IETF regards of itself as >the standards body at the IP address layer. Due to this >discussion the ARIN Advisory Council voted during a meeting >(conference call) on Nov 22 not to forward Policy Proposal >2002-2 to the BoT for further consideration. The decision was >to post the policy back to the PPML mailing list for further >discussion to aid in resolving the issue mentioned above. > >So in accordance with the ARIN Advisory Council's decision we >are asking for further discussion on Policy Proposal 2002-2. >We are specifically looking for guidance on the issue above >and ask that any IETF or IAB members provide input if >possible. Thank you. > >John Sweeting >ARIN Advisory Council From Michael.Dillon at radianz.com Tue Dec 3 05:42:41 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 3 Dec 2002 10:42:41 +0000 Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: >So in accordance with the ARIN Advisory Council's decision we >are asking for further discussion on Policy Proposal 2002-2. One way to resolve this issue is to change the language so that it is clear that the IETF is the standards body. For instance: "by the IANA in coordination with standards bodies, such as the IETF" ... "Organisations such as the IETF, who describe experimental activities as part of their" becomes: "by the IANA in coordination with the IETF" ... "The IETF describes experimental activities as part of their" If we do this, what do we get? 1. We now have a clear relationship for experimental allocations rather than a vague and fuzzy one. 2. We now no longer have to decide whether or not a so-called "standards body" should be allowed to experiment on a case by case basis. 3. We no longer have any need to discuss the merits of any experiments because they will have already been discussed thoroughly in an open forum, namely the IETF. ARIN can focus solely on the resource allocation issues and defer all other issues and discussion to the IETF. 4. We won't ever have to discuss whether or not an experiment from a non-IETF standards body was fair enough or discussed openly enough or relevant enough since all experiments will be initiated by the most open standards body in existence. Some people may argue that there is a case for accepting experimental requests from other standards bodies that work with a specific industry, for instance ITU-T and the cellular phone industry. However, the IETF is open enough to accomodate work that was begin in other forums, therefore this argument does not hold. In other words, we aren't specifying that we want all work to be done under IETF auspices, merely that we want all work to pass through the IETF's review before it comes to ARIN so that ARIN can focus on being an RIR. I'll leave it to someone else to do a detailed edit of the wording. --Michael Dillon From Michael.Dillon at radianz.com Tue Dec 3 05:50:14 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 3 Dec 2002 10:50:14 +0000 Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: >Surely we aren't implying here that the IETF is the only organisation >allowed to carry out experiments on the Internet? Where is this documented? >Who is enforcing it? Who in the IETF does anyone have to go to before they >are permitted to experiment on the Internet? The proposal says that an experimental RFC must be published. The RFC process is documented by the IETF http://www.ietf.org so this implies that the experiment must go through an open public review process *BEFORE* coming to ARIN. It does not say that only the IETF can do experiments because that is a ludicrous idea. The IETF is not the sort of organization that can do anything other than discuss things, agree on things and publish the results of their agreement. --Michael Dillon From Stacy_Taylor at icgcomm.com Tue Dec 3 14:14:18 2002 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 3 Dec 2002 12:14:18 -0700 Subject: [ppml] Policy 2002-5 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA017108F1@denexg21.icgcomm.com> Greetings All, To make good on my campaign promise to make our policies comply with the standards of the English language, I have altered policy 2002-5. How do you like this? If an organization, whether a member or non-member, ISP or end-user, relinquishes a larger block of portable address space to ARIN, they shall be allowed to receive a smaller block, /24 or shorter, in exchange. The organization will not be required to justify their use of the new, smaller block. The organization must return the block to be exchanged within 12 months. ARIN staff shall, at their discretion, determine whether the smaller replacement block shall be a subnet of the returned block, or a block allocated from some different range. If any of the relinquished blocks had associated maintenance fees, then the new block will be subject to the appropriate fees for that block size. Likewise those without maintenance fees shall remain so. I am also interested in continuing the discussion on the relative merits of this policy. Hope you had a great Thanksgiving! Stacy From Trevor.Paquette at TeraGo.ca Tue Dec 3 14:27:11 2002 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Tue, 3 Dec 2002 12:27:11 -0700 Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F1@denexg21.icgcomm.com> Message-ID: <002c01c29b01$fadb64f0$3102a8c0@teraint.net> much better reading... could this policy possibly be used to exchange blocks? meaning.. get one of the SAME size because the original is getting 'dirty' (blocked by blacklist etc?). I hope that the wording "shall receive a smaller block", really means a SMALLER block; not one of the same size. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Taylor, Stacy > Sent: Tuesday, December 03, 2002 12:14 PM > To: 'ppml at arin.net' > Subject: [ppml] Policy 2002-5 > > > Greetings All, > > To make good on my campaign promise to make our policies > comply with the > standards of the English language, I have altered policy > 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to > ARIN, they shall be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the > new, smaller > block. The organization must return the block to be > exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned > block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance > fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the > relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From john at chagres.net Tue Dec 3 14:38:12 2002 From: john at chagres.net (John M. Brown) Date: Tue, 3 Dec 2002 12:38:12 -0700 Subject: [ppml] Policy 2002-5 In-Reply-To: <002c01c29b01$fadb64f0$3102a8c0@teraint.net> Message-ID: <000f01c29b03$844de5e0$f9ecdfd8@laptoy> I believe that the RIR's should stay out of the laundry business. Its the responsibility of the prefix holder to clean their own underwear.. :) So, NO, I don't think this should be used to exchange 'dirty' blocks. John Brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Trevor Paquette > Sent: Tuesday, December 03, 2002 12:27 PM > To: ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > much better reading... > > could this policy possibly be used to exchange blocks? > > meaning.. get one of the SAME size because the original is > getting 'dirty' (blocked by blacklist etc?). I hope that the > wording "shall receive a smaller block", really means a > SMALLER block; not one of the same size. > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Taylor, Stacy > > Sent: Tuesday, December 03, 2002 12:14 PM > > To: 'ppml at arin.net' > > Subject: [ppml] Policy 2002-5 > > > > > > Greetings All, > > > > To make good on my campaign promise to make our policies > > comply with the > > standards of the English language, I have altered policy > > 2002-5. How do you > > like this? > > > > > > If an organization, whether a member or non-member, ISP or > end-user, > > relinquishes a larger block of portable address space to ARIN, they > > shall be > > allowed to receive a smaller block, /24 or shorter, in > exchange. The > > organization will not be required to justify their use of the > > new, smaller > > block. The organization must return the block to be > > exchanged within 12 > > months. ARIN staff shall, at their discretion, determine > whether the > > smaller replacement block shall be a subnet of the returned > > block, or a > > block allocated from some different range. > > If any of the relinquished blocks had associated maintenance > > fees, then the > > new block will be subject to the appropriate fees for that > block size. > > Likewise those without maintenance fees shall remain so. > > > > > > I am also interested in continuing the discussion on the > > relative merits of > > this policy. > > > > Hope you had a great Thanksgiving! > > Stacy > > > From jlturner at gblx.net Tue Dec 3 14:39:47 2002 From: jlturner at gblx.net (Jennifer Turner) Date: Tue, 3 Dec 2002 12:39:47 -0700 (MST) Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F1@denexg21.icgcomm.com> Message-ID: Nice - very clear and to the point, Stacy. -Jenn On Tue, 3 Dec 2002, Taylor, Stacy wrote: > Greetings All, > > To make good on my campaign promise to make our policies comply with the > standards of the English language, I have altered policy 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to ARIN, they shall be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the new, smaller > block. The organization must return the block to be exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy From John.Sweeting at teleglobe.com Tue Dec 3 14:39:59 2002 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 3 Dec 2002 14:39:59 -0500 Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BB7A@usresms03.teleglobe.com> Philip, Just to clarify, it was not the AC that raised these points...these points came from postings to the Final Call. The AC thought that it was important enough to return the proposal to the discussion phase to ensure that the wording was looked at and possibly changed to ensure there was no ambiquity. The questions you have asked below are some of the same ones we would like answered. -----Original Message----- From: Philip Smith [mailto:pfs at cisco.com] Sent: Monday, December 02, 2002 7:16 PM To: ppml at arin.net Cc: Member Services Subject: Re: [ppml] Open discussion on Policy Proposal 2002-2 I'd be curious to know where the Advisory Council found the text which referred to standards process bodies other than the IETF. The proposal referred to the concept that entities other than the IETF may wish to carry out publicly recorded experiments which require Internet resources on a temporary basis. Surely we aren't implying here that the IETF is the only organisation allowed to carry out experiments on the Internet? Where is this documented? Who is enforcing it? Who in the IETF does anyone have to go to before they are permitted to experiment on the Internet? philip -- At 15:09 02/12/2002 -0500, Member Services wrote: >During the Final Call for Policy Proposal 2002-2 >(http://www.arin.net/policy/2002_2.html) there was discussion >that the policy implied standards processes bodies other then >the IETF might be used and that the IETF regards of itself as >the standards body at the IP address layer. Due to this >discussion the ARIN Advisory Council voted during a meeting >(conference call) on Nov 22 not to forward Policy Proposal >2002-2 to the BoT for further consideration. The decision was >to post the policy back to the PPML mailing list for further >discussion to aid in resolving the issue mentioned above. > >So in accordance with the ARIN Advisory Council's decision we >are asking for further discussion on Policy Proposal 2002-2. >We are specifically looking for guidance on the issue above >and ask that any IETF or IAB members provide input if >possible. Thank you. > >John Sweeting >ARIN Advisory Council From John.Sweeting at teleglobe.com Tue Dec 3 14:53:39 2002 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 3 Dec 2002 14:53:39 -0500 Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BB7B@usresms03.teleglobe.com> Michael, I do not believe that the proposal says that an experimental RFC MUST be published...what it does say is: "The RIRs have a strong preference for the use of an Experimental RFC published through the IETF, but will accept other publication mechanisms where the experiment's objectives and practices are publicly and openly available free of charges and free of any constraints of disclosure." Does this change your opinion on the proposal? or just reinforce it? -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Tuesday, December 03, 2002 5:50 AM To: ppml at arin.net Subject: Re: [ppml] Open discussion on Policy Proposal 2002-2 >Surely we aren't implying here that the IETF is the only organisation >allowed to carry out experiments on the Internet? Where is this documented? >Who is enforcing it? Who in the IETF does anyone have to go to before they >are permitted to experiment on the Internet? The proposal says that an experimental RFC must be published. The RFC process is documented by the IETF http://www.ietf.org so this implies that the experiment must go through an open public review process *BEFORE* coming to ARIN. It does not say that only the IETF can do experiments because that is a ludicrous idea. The IETF is not the sort of organization that can do anything other than discuss things, agree on things and publish the results of their agreement. --Michael Dillon From Stacy_Taylor at icgcomm.com Tue Dec 3 15:03:53 2002 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 3 Dec 2002 13:03:53 -0700 Subject: [ppml] Policy 2002-5 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA017108F2@denexg21.icgcomm.com> The block an organization would exchange would be for a smaller block only. The goal is for organizations to turn in space they are already not using, or could free up by consolidation. -----Original Message----- From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] Sent: Tuesday, December 03, 2002 11:27 AM To: ppml at arin.net Subject: RE: [ppml] Policy 2002-5 much better reading... could this policy possibly be used to exchange blocks? meaning.. get one of the SAME size because the original is getting 'dirty' (blocked by blacklist etc?). I hope that the wording "shall receive a smaller block", really means a SMALLER block; not one of the same size. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Taylor, Stacy > Sent: Tuesday, December 03, 2002 12:14 PM > To: 'ppml at arin.net' > Subject: [ppml] Policy 2002-5 > > > Greetings All, > > To make good on my campaign promise to make our policies > comply with the > standards of the English language, I have altered policy > 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to > ARIN, they shall be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the > new, smaller > block. The organization must return the block to be > exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned > block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance > fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the > relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From billd at cait.wustl.edu Tue Dec 3 16:01:24 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 3 Dec 2002 15:01:24 -0600 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? Message-ID: 2002-6: Aggregation Requests Proposed Policy: As is..... If an organization, whether a member or non-member, ISP or end-user, relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall be allowed to receive a block in exchange, /24 or shorter, but no more than the shortest block that could contain all of the returned blocks. Exchanged space shall be returned within 12 months. For example, if an organization relinquished three /24s, they should be allowed to take either a /24, a /23, or a /22 in exchange. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, the replacement space shall be as well, but if any one of the returned blocks had associated maintenance fees, then the replacement block shall also be subject to maintenance fees. Proposed..... If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they will receive a block in exchange. The block received in exchange shall be /24 or shorter, but not shorter than need be in order to contain all of the returned blocks. Exchanged space shall be returned within 12 months. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, then replacement space will be without fee, but if any one of the returned blocks had associated maintenance fees, then the replacement block will also be subject to maintenance fees appropriate to the replacement block size. For example, if an organization relinquished three /24s, they would eligible to receive a /24, a /23, or a /22 in exchange. This is similar to the 2002-5 wording that Stacy is working with........ I think the wording in the first sentence can be shortened in both policies to "any organization" ....does anyone see a problem with this? Bill Darte AC From john at chagres.net Tue Dec 3 16:00:19 2002 From: john at chagres.net (John M. Brown) Date: Tue, 3 Dec 2002 14:00:19 -0700 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: Message-ID: <001201c29b0e$fce63d30$f9ecdfd8@laptoy> as long as we don't get to do laundry with this policy. I'd like to see there be language that removes the ability to exchange blocks because the are "dirty" or blacklisted. If the lang is not specifically in there, then people will use the loop-hole. john brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Bill Darte > Sent: Tuesday, December 03, 2002 2:01 PM > To: ppml at arin.net > Cc: 'Taylor, Stacy' > Subject: [ppml] Wording issues with the 2002-6 Aggregation > Requests Proposal??? > > > 2002-6: Aggregation Requests > > Proposed Policy: > > As is..... > If an organization, whether a member or non-member, ISP or > end-user, relinquishes a group of portable, non-aggregatable > address blocks to ARIN, they shall be allowed to receive a > block in exchange, /24 or shorter, but no more than the > shortest block that could contain all of the returned blocks. > Exchanged space shall be returned within 12 months. For > example, if an organization relinquished three /24s, they > should be allowed to take either a /24, a /23, or a /22 in > exchange. If all of the previous address blocks were > maintained in the ARIN database without maintenance fees, the > replacement space shall be as well, but if any one of the > returned blocks had associated maintenance fees, then the > replacement block shall also be subject to maintenance fees. > > Proposed..... > If any organization relinquishes a group of portable, > non-aggregatable address blocks to ARIN, they will receive a > block in exchange. The block received in exchange shall be > /24 or shorter, but not shorter than need be in order to > contain all of the returned blocks. Exchanged space shall be > returned within 12 months. If all of the previous address > blocks were maintained in the ARIN database without > maintenance fees, then replacement space will be without fee, > but if any one of the returned blocks had associated > maintenance fees, then the replacement block will also be > subject to maintenance fees appropriate to the replacement > block size. For example, if an organization relinquished > three /24s, they would eligible to receive a /24, a /23, or a > /22 in exchange. > > > This is similar to the 2002-5 wording that Stacy is working > with........ I think the wording in the first sentence can be > shortened in both policies to "any organization" ....does > anyone see a problem with this? > > Bill Darte > AC > > > > From billd at cait.wustl.edu Tue Dec 3 16:24:26 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 3 Dec 2002 15:24:26 -0600 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: To play devil's advocate in this matter...... It seems that there is a tradeoff of goods and evils here. Of course we could add wording that limits the policy, but we would have to be able to assess the 'dirtyness' of the space..... e.g. what if only one of three blocks is dirty? How dirty is dirty? How would we know/test? Is it worth more to assume the potential role of 'launderer' for the sake of route table efficiency than to deal with the hassles of specifying and investigating dirtiness and limit the efficiency benefits? Seems to me the answer (as with all things) is, it depends! I think it depends upon how many dirty blocks would be returned relative to others and how costly it might be to do the investigation/assessments. Also, isn't there an ultimate benefit to getting blocks laundered, such that they become usable again and a productive part of the Internet? Just wondering what you all think. Bill Darte AC and Devil's advocate (on only this issue) > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Tuesday, December 03, 2002 3:00 PM > To: 'Bill Darte'; ppml at arin.net > Cc: 'Taylor, Stacy' > Subject: RE: [ppml] Wording issues with the 2002-6 > Aggregation Requests > Proposal??? > > > as long as we don't get to do laundry with this policy. > > I'd like to see there be language that removes the ability > to exchange blocks because the are "dirty" or blacklisted. > > If the lang is not specifically in there, then people will > use the loop-hole. > > john brown > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Bill Darte > > Sent: Tuesday, December 03, 2002 2:01 PM > > To: ppml at arin.net > > Cc: 'Taylor, Stacy' > > Subject: [ppml] Wording issues with the 2002-6 Aggregation > > Requests Proposal??? > > > > > > 2002-6: Aggregation Requests > > > > Proposed Policy: > > > > As is..... > > If an organization, whether a member or non-member, ISP or > > end-user, relinquishes a group of portable, non-aggregatable > > address blocks to ARIN, they shall be allowed to receive a > > block in exchange, /24 or shorter, but no more than the > > shortest block that could contain all of the returned blocks. > > Exchanged space shall be returned within 12 months. For > > example, if an organization relinquished three /24s, they > > should be allowed to take either a /24, a /23, or a /22 in > > exchange. If all of the previous address blocks were > > maintained in the ARIN database without maintenance fees, the > > replacement space shall be as well, but if any one of the > > returned blocks had associated maintenance fees, then the > > replacement block shall also be subject to maintenance fees. > > > > Proposed..... > > If any organization relinquishes a group of portable, > > non-aggregatable address blocks to ARIN, they will receive a > > block in exchange. The block received in exchange shall be > > /24 or shorter, but not shorter than need be in order to > > contain all of the returned blocks. Exchanged space shall be > > returned within 12 months. If all of the previous address > > blocks were maintained in the ARIN database without > > maintenance fees, then replacement space will be without fee, > > but if any one of the returned blocks had associated > > maintenance fees, then the replacement block will also be > > subject to maintenance fees appropriate to the replacement > > block size. For example, if an organization relinquished > > three /24s, they would eligible to receive a /24, a /23, or a > > /22 in exchange. > > > > > > This is similar to the 2002-5 wording that Stacy is working > > with........ I think the wording in the first sentence can be > > shortened in both policies to "any organization" ....does > > anyone see a problem with this? > > > > Bill Darte > > AC > > > > > > > > > From john at chagres.net Tue Dec 3 16:25:06 2002 From: john at chagres.net (John M. Brown) Date: Tue, 3 Dec 2002 14:25:06 -0700 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: Message-ID: <001301c29b12$73668390$f9ecdfd8@laptoy> So how many times does one get to return blocks ?? If I return 12 /24's now, and get new ones, and then a year later return those for new ones, rinse, lather, repeat. What does the RIR do when they issue those returned blocks to someone else and they have problems using them ??? How do you launder them?? Who is inspector 12 ?? I believe the BoT wants to see the AC have crisp and clear policies. As currently worded I believe a certain amount of crispness is lacking and that can be used for abuse. > -----Original Message----- > From: Bill Darte [mailto:billd at cait.wustl.edu] > Sent: Tuesday, December 03, 2002 2:24 PM > To: ppml at arin.net > Cc: 'John M. Brown' > Subject: RE: [ppml] Wording issues with the 2002-6 > Aggregation Requests Proposal??? > > > To play devil's advocate in this matter...... > > It seems that there is a tradeoff of goods and evils here. > > Of course we could add wording that limits the policy, but we > would have to be able to assess the 'dirtyness' of the > space..... e.g. what if only one of three blocks is dirty? > How dirty is dirty? How would we know/test? > > Is it worth more to assume the potential role of 'launderer' > for the sake of route table efficiency than to deal with the > hassles of specifying and investigating dirtiness and limit > the efficiency benefits? > > Seems to me the answer (as with all things) is, it depends! > I think it depends upon how many dirty blocks would be > returned relative to others and how costly it might be to do > the investigation/assessments. Also, isn't there an ultimate > benefit to getting blocks laundered, such that they become > usable again and a productive part of the Internet? > > Just wondering what you all think. > > Bill Darte > AC and Devil's advocate (on only this issue) > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Tuesday, December 03, 2002 3:00 PM > > To: 'Bill Darte'; ppml at arin.net > > Cc: 'Taylor, Stacy' > > Subject: RE: [ppml] Wording issues with the 2002-6 > > Aggregation Requests > > Proposal??? > > > > > > as long as we don't get to do laundry with this policy. > > > > I'd like to see there be language that removes the ability > > to exchange blocks because the are "dirty" or blacklisted. > > > > If the lang is not specifically in there, then people will use the > > loop-hole. > > > > john brown > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > Behalf Of Bill Darte > > > Sent: Tuesday, December 03, 2002 2:01 PM > > > To: ppml at arin.net > > > Cc: 'Taylor, Stacy' > > > Subject: [ppml] Wording issues with the 2002-6 Aggregation > > > Requests Proposal??? > > > > > > > > > 2002-6: Aggregation Requests > > > > > > Proposed Policy: > > > > > > As is..... > > > If an organization, whether a member or non-member, ISP or > > > end-user, relinquishes a group of portable, non-aggregatable > > > address blocks to ARIN, they shall be allowed to receive a > > > block in exchange, /24 or shorter, but no more than the > > > shortest block that could contain all of the returned blocks. > > > Exchanged space shall be returned within 12 months. For > > > example, if an organization relinquished three /24s, they > > > should be allowed to take either a /24, a /23, or a /22 in > > > exchange. If all of the previous address blocks were > > > maintained in the ARIN database without maintenance fees, the > > > replacement space shall be as well, but if any one of the > > > returned blocks had associated maintenance fees, then the > > > replacement block shall also be subject to maintenance fees. > > > > > > Proposed..... > > > If any organization relinquishes a group of portable, > > > non-aggregatable address blocks to ARIN, they will receive a > > > block in exchange. The block received in exchange shall be > > > /24 or shorter, but not shorter than need be in order to > > > contain all of the returned blocks. Exchanged space shall be > > > returned within 12 months. If all of the previous address > > > blocks were maintained in the ARIN database without > > > maintenance fees, then replacement space will be without fee, > > > but if any one of the returned blocks had associated > > > maintenance fees, then the replacement block will also be > > > subject to maintenance fees appropriate to the replacement > > > block size. For example, if an organization relinquished > > > three /24s, they would eligible to receive a /24, a /23, or a > > > /22 in exchange. > > > > > > > > > This is similar to the 2002-5 wording that Stacy is working > > > with........ I think the wording in the first sentence can be > > > shortened in both policies to "any organization" ....does > > > anyone see a problem with this? > > > > > > Bill Darte > > > AC > > > > > > > > > > > > > > > From billd at cait.wustl.edu Tue Dec 3 16:45:02 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 3 Dec 2002 15:45:02 -0600 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: In the first place, you would not be able to return 12 a second time, because you would return the original 12 for a single aggregated block which would no longer fit the criteria of the policy...no? Second, ...current policy I believe (stated by Richard earlier) is that blocks are not reissued for a year........ is that sufficient time? Why not longer if need be? I agree with the BoT that policies should be crisp and clear. I would be happy for you to suggest a 'crisper' wording. Also, are you suggesting that the policy is better off dropped than run the risk of laundering as worded, or do you believe the policy is a good one as long as we can create wording (and process) that eliminates organizations from returning dirty blocks? Bill Darte AC > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Tuesday, December 03, 2002 3:25 PM > To: 'Bill Darte'; ppml at arin.net > Subject: RE: [ppml] Wording issues with the 2002-6 > Aggregation Requests > Proposal??? > > > So how many times does one get to return blocks ?? > > If I return 12 /24's now, and get new ones, and then > a year later return those for new ones, rinse, lather, > repeat. > > What does the RIR do when they issue those returned blocks > to someone else and they have problems using them ??? > > > How do you launder them?? Who is inspector 12 ?? > > I believe the BoT wants to see the AC have crisp and > clear policies. As currently worded I believe a certain > amount of crispness is lacking and that can be used for > abuse. > > > > -----Original Message----- > > From: Bill Darte [mailto:billd at cait.wustl.edu] > > Sent: Tuesday, December 03, 2002 2:24 PM > > To: ppml at arin.net > > Cc: 'John M. Brown' > > Subject: RE: [ppml] Wording issues with the 2002-6 > > Aggregation Requests Proposal??? > > > > > > To play devil's advocate in this matter...... > > > > It seems that there is a tradeoff of goods and evils here. > > > > Of course we could add wording that limits the policy, but we > > would have to be able to assess the 'dirtyness' of the > > space..... e.g. what if only one of three blocks is dirty? > > How dirty is dirty? How would we know/test? > > > > Is it worth more to assume the potential role of 'launderer' > > for the sake of route table efficiency than to deal with the > > hassles of specifying and investigating dirtiness and limit > > the efficiency benefits? > > > > Seems to me the answer (as with all things) is, it depends! > > I think it depends upon how many dirty blocks would be > > returned relative to others and how costly it might be to do > > the investigation/assessments. Also, isn't there an ultimate > > benefit to getting blocks laundered, such that they become > > usable again and a productive part of the Internet? > > > > Just wondering what you all think. > > > > Bill Darte > > AC and Devil's advocate (on only this issue) > > > > > -----Original Message----- > > > From: John M. Brown [mailto:john at chagres.net] > > > Sent: Tuesday, December 03, 2002 3:00 PM > > > To: 'Bill Darte'; ppml at arin.net > > > Cc: 'Taylor, Stacy' > > > Subject: RE: [ppml] Wording issues with the 2002-6 > > > Aggregation Requests > > > Proposal??? > > > > > > > > > as long as we don't get to do laundry with this policy. > > > > > > I'd like to see there be language that removes the ability > > > to exchange blocks because the are "dirty" or blacklisted. > > > > > > If the lang is not specifically in there, then people > will use the > > > loop-hole. > > > > > > john brown > > > > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > > > Behalf Of Bill Darte > > > > Sent: Tuesday, December 03, 2002 2:01 PM > > > > To: ppml at arin.net > > > > Cc: 'Taylor, Stacy' > > > > Subject: [ppml] Wording issues with the 2002-6 Aggregation > > > > Requests Proposal??? > > > > > > > > > > > > 2002-6: Aggregation Requests > > > > > > > > Proposed Policy: > > > > > > > > As is..... > > > > If an organization, whether a member or non-member, ISP or > > > > end-user, relinquishes a group of portable, non-aggregatable > > > > address blocks to ARIN, they shall be allowed to receive a > > > > block in exchange, /24 or shorter, but no more than the > > > > shortest block that could contain all of the returned blocks. > > > > Exchanged space shall be returned within 12 months. For > > > > example, if an organization relinquished three /24s, they > > > > should be allowed to take either a /24, a /23, or a /22 in > > > > exchange. If all of the previous address blocks were > > > > maintained in the ARIN database without maintenance fees, the > > > > replacement space shall be as well, but if any one of the > > > > returned blocks had associated maintenance fees, then the > > > > replacement block shall also be subject to maintenance fees. > > > > > > > > Proposed..... > > > > If any organization relinquishes a group of portable, > > > > non-aggregatable address blocks to ARIN, they will receive a > > > > block in exchange. The block received in exchange shall be > > > > /24 or shorter, but not shorter than need be in order to > > > > contain all of the returned blocks. Exchanged space shall be > > > > returned within 12 months. If all of the previous address > > > > blocks were maintained in the ARIN database without > > > > maintenance fees, then replacement space will be without fee, > > > > but if any one of the returned blocks had associated > > > > maintenance fees, then the replacement block will also be > > > > subject to maintenance fees appropriate to the replacement > > > > block size. For example, if an organization relinquished > > > > three /24s, they would eligible to receive a /24, a /23, or a > > > > /22 in exchange. > > > > > > > > > > > > This is similar to the 2002-5 wording that Stacy is working > > > > with........ I think the wording in the first sentence can be > > > > shortened in both policies to "any organization" ....does > > > > anyone see a problem with this? > > > > > > > > Bill Darte > > > > AC > > > > > > > > > > > > > > > > > > > > > > From dawn.martin at wcom.com Tue Dec 3 16:48:12 2002 From: dawn.martin at wcom.com (Dawn Martin) Date: Tue, 03 Dec 2002 16:48:12 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: Message-ID: <001b01c29b15$adee0170$8dde2799@wcomnet.com> Please pardon my ignorance here, but just wondering what was said in regards to deals made with these users that don't end up returning the address space. What does ARIN do? I have some ideas but was wondering if this was already solved. Also, I don't see a problem with shortening the first sentence as Bill suggested. Should there be an example of the billing for the blocks as well? Or do we assume that the folks that are currently being billed know who they are and understand the billing process? Dawn Martin -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Bill Darte Sent: Tuesday, December 03, 2002 4:01 PM To: ppml at arin.net Cc: 'Taylor, Stacy' Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? 2002-6: Aggregation Requests Proposed Policy: As is..... If an organization, whether a member or non-member, ISP or end-user, relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall be allowed to receive a block in exchange, /24 or shorter, but no more than the shortest block that could contain all of the returned blocks. Exchanged space shall be returned within 12 months. For example, if an organization relinquished three /24s, they should be allowed to take either a /24, a /23, or a /22 in exchange. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, the replacement space shall be as well, but if any one of the returned blocks had associated maintenance fees, then the replacement block shall also be subject to maintenance fees. Proposed..... If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they will receive a block in exchange. The block received in exchange shall be /24 or shorter, but not shorter than need be in order to contain all of the returned blocks. Exchanged space shall be returned within 12 months. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, then replacement space will be without fee, but if any one of the returned blocks had associated maintenance fees, then the replacement block will also be subject to maintenance fees appropriate to the replacement block size. For example, if an organization relinquished three /24s, they would eligible to receive a /24, a /23, or a /22 in exchange. This is similar to the 2002-5 wording that Stacy is working with........ I think the wording in the first sentence can be shortened in both policies to "any organization" ....does anyone see a problem with this? Bill Darte AC From chuegen at cisco.com Tue Dec 3 16:56:08 2002 From: chuegen at cisco.com (Craig A. Huegen) Date: Tue, 3 Dec 2002 15:56:08 -0600 (Central Standard Time) Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: Message-ID: On Tue, 3 Dec 2002, Bill Darte wrote: > Proposed..... > If any organization relinquishes a group of portable, non-aggregatable [...] I'm fine with Bill's wording on this but would ask for another statement to be added. The new blocks should be aligned with the published "minimum allocation" size. For instance, if I were to return 3 /24's in exchange for a /22 from 205/8 space, I would expect that /22 to come out of space that had an allocation policy of /22 or longer. Otherwise, the organization is subject to some filters presently in place on minimum prefix length based on registry allocations. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From ron at aol.net Tue Dec 3 16:57:08 2002 From: ron at aol.net (Ron da Silva) Date: Tue, 3 Dec 2002 16:57:08 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? In-Reply-To: References: Message-ID: <20021203215708.GA16347@aol.net> On Tue, Dec 03, 2002 at 03:45:02PM -0600, Bill Darte wrote: > In the first place, you would not be able to return 12 a second time, > because you would return the original 12 for a single aggregated block which > would no longer fit the criteria of the policy...no? I suppose, if I had 12 /24s and they were "dirty" (whatever that means), I could trade in 3 of them for a /22. And then after some time, say 6 months, trade in that /22 along with another /24 for a /21. etc.. I could have a decent amount of space by the time I am done. Why not require that in order to exercise this policy the request must come from an ARIN member (which implies billing and justification are in place) ? rhetorically, -ron From dawn.martin at wcom.com Tue Dec 3 16:55:26 2002 From: dawn.martin at wcom.com (Dawn Martin) Date: Tue, 03 Dec 2002 16:55:26 -0500 Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F2@denexg21.icgcomm.com> Message-ID: <002101c29b16$b0ca29e0$8dde2799@wcomnet.com> I'm not sure that returning a larger block of address space for a slightly smaller block is enough reason to accept the exchange. Is there a way for the ARIN staff to ensure that the space is "clean". I don't know of a easy way of doing this, even over time the blocks stay on lists long after the original SPAMer is gone. Dawn Martin WorldCom IP Planning & Policy Analyst dawn.martin at wcom.com (703)886-4746 -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Taylor, Stacy Sent: Tuesday, December 03, 2002 3:04 PM To: 'Trevor Paquette'; ppml at arin.net Subject: RE: [ppml] Policy 2002-5 The block an organization would exchange would be for a smaller block only. The goal is for organizations to turn in space they are already not using, or could free up by consolidation. -----Original Message----- From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] Sent: Tuesday, December 03, 2002 11:27 AM To: ppml at arin.net Subject: RE: [ppml] Policy 2002-5 much better reading... could this policy possibly be used to exchange blocks? meaning.. get one of the SAME size because the original is getting 'dirty' (blocked by blacklist etc?). I hope that the wording "shall receive a smaller block", really means a SMALLER block; not one of the same size. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Taylor, Stacy > Sent: Tuesday, December 03, 2002 12:14 PM > To: 'ppml at arin.net' > Subject: [ppml] Policy 2002-5 > > > Greetings All, > > To make good on my campaign promise to make our policies > comply with the > standards of the English language, I have altered policy > 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to > ARIN, they shall be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the > new, smaller > block. The organization must return the block to be > exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned > block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance > fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the > relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From Stacy_Taylor at icgcomm.com Tue Dec 3 17:10:37 2002 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 3 Dec 2002 15:10:37 -0700 Subject: [ppml] Policy 2002-5 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA017108F5@denexg21.icgcomm.com> (Hi Dawn!) We could change the sentence: ARIN staff shall, at their discretion, determine whether the smaller replacement block shall be a subnet of the returned block, or a block allocated from some different range. to: The smaller replacement block shall be a subnet of the returned block. Although, does that remove the carrot from the equation? Is there a way to inform the blacklists that a block has been returned to the registry and should be removed from the list? Stacy -----Original Message----- From: Dawn Martin [mailto:dawn.martin at wcom.com] Sent: Tuesday, December 03, 2002 1:55 PM To: 'Taylor, Stacy'; 'Trevor Paquette'; ppml at arin.net Subject: RE: [ppml] Policy 2002-5 I'm not sure that returning a larger block of address space for a slightly smaller block is enough reason to accept the exchange. Is there a way for the ARIN staff to ensure that the space is "clean". I don't know of a easy way of doing this, even over time the blocks stay on lists long after the original SPAMer is gone. Dawn Martin WorldCom IP Planning & Policy Analyst dawn.martin at wcom.com (703)886-4746 -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Taylor, Stacy Sent: Tuesday, December 03, 2002 3:04 PM To: 'Trevor Paquette'; ppml at arin.net Subject: RE: [ppml] Policy 2002-5 The block an organization would exchange would be for a smaller block only. The goal is for organizations to turn in space they are already not using, or could free up by consolidation. -----Original Message----- From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] Sent: Tuesday, December 03, 2002 11:27 AM To: ppml at arin.net Subject: RE: [ppml] Policy 2002-5 much better reading... could this policy possibly be used to exchange blocks? meaning.. get one of the SAME size because the original is getting 'dirty' (blocked by blacklist etc?). I hope that the wording "shall receive a smaller block", really means a SMALLER block; not one of the same size. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Taylor, Stacy > Sent: Tuesday, December 03, 2002 12:14 PM > To: 'ppml at arin.net' > Subject: [ppml] Policy 2002-5 > > > Greetings All, > > To make good on my campaign promise to make our policies > comply with the > standards of the English language, I have altered policy > 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to > ARIN, they shall be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the > new, smaller > block. The organization must return the block to be > exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned > block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance > fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the > relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From john at chagres.net Tue Dec 3 17:34:43 2002 From: john at chagres.net (John M. Brown) Date: Tue, 3 Dec 2002 15:34:43 -0700 Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F5@denexg21.icgcomm.com> Message-ID: <001a01c29b1c$2d1f49d0$f9ecdfd8@laptoy> Is there a way to have the blacklist remove the block ? RIR's have no control over blacklists. Thus if a blacklist feels the blocks are just being laundered they will keep them on the list. Then you have blacklists that don't remove today, even after the ISP was most active and zapped the offender. > Is there a way to inform the blacklists that a block has been > returned to the registry and should be removed from the list? > > Stacy > > > -----Original Message----- > From: Dawn Martin [mailto:dawn.martin at wcom.com] > Sent: Tuesday, December 03, 2002 1:55 PM > To: 'Taylor, Stacy'; 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > I'm not sure that returning a larger block of address space > for a slightly smaller block is enough reason to accept the > exchange. Is there a way for the ARIN staff to ensure that > the space is "clean". I don't know of a easy way of doing > this, even over time the blocks stay on lists long after the > original SPAMer is gone. > > Dawn Martin > WorldCom IP Planning & Policy Analyst > dawn.martin at wcom.com > (703)886-4746 > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Taylor, Stacy > Sent: Tuesday, December 03, 2002 3:04 PM > To: 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > The block an organization would exchange would be for a > smaller block only. The goal is for organizations to turn in > space they are already not using, or could free up by consolidation. > > -----Original Message----- > From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] > Sent: Tuesday, December 03, 2002 11:27 AM > To: ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > much better reading... > > could this policy possibly be used to exchange blocks? > > meaning.. get one of the SAME size because the original is > getting 'dirty' (blocked by blacklist etc?). I hope that the > wording "shall receive a smaller block", really means a > SMALLER block; not one of the same size. > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Taylor, Stacy > > Sent: Tuesday, December 03, 2002 12:14 PM > > To: 'ppml at arin.net' > > Subject: [ppml] Policy 2002-5 > > > > > > Greetings All, > > > > To make good on my campaign promise to make our policies > > comply with the > > standards of the English language, I have altered policy > > 2002-5. How do you > > like this? > > > > > > If an organization, whether a member or non-member, ISP or > end-user, > > relinquishes a larger block of portable address space to ARIN, they > > shall be > > allowed to receive a smaller block, /24 or shorter, in > exchange. The > > organization will not be required to justify their use of the > > new, smaller > > block. The organization must return the block to be > > exchanged within 12 > > months. ARIN staff shall, at their discretion, determine > whether the > > smaller replacement block shall be a subnet of the returned > > block, or a > > block allocated from some different range. > > If any of the relinquished blocks had associated maintenance > > fees, then the > > new block will be subject to the appropriate fees for that > block size. > > Likewise those without maintenance fees shall remain so. > > > > > > I am also interested in continuing the discussion on the > > relative merits of > > this policy. > > > > Hope you had a great Thanksgiving! > > Stacy > > > From john at chagres.net Tue Dec 3 17:40:04 2002 From: john at chagres.net (John M. Brown) Date: Tue, 3 Dec 2002 15:40:04 -0700 Subject: [ppml] Policy 2002-5, different question In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F5@denexg21.icgcomm.com> Message-ID: <001b01c29b1c$ec6692d0$f9ecdfd8@laptoy> Another question: What does this do to the fragmentation of the RIR's address pool? I can see from a routing table perspective that we ""MAY"" see better aggregation of routes, but it seems that the RIR may end up with a large pile of very fragmented space. Another question: Does it make sense to only give smaller re-allocs? If I have 4 /24's out of various swamp locations, and I wish to return these non-aggregatable /24's for a /22, why can't I do that ? That would seem to help route table growth, but add to RIR fragmentation. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Taylor, Stacy > Sent: Tuesday, December 03, 2002 3:11 PM > To: 'dawn.martin at wcom.com'; Taylor, Stacy; 'Trevor Paquette'; > ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > (Hi Dawn!) > > We could change the sentence: > ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned > block, or a block allocated from some different range. > > to: > > The smaller replacement block shall be a subnet of the returned block. > > Although, does that remove the carrot from the equation? > > Is there a way to inform the blacklists that a block has been > returned to the registry and should be removed from the list? > > Stacy > > > -----Original Message----- > From: Dawn Martin [mailto:dawn.martin at wcom.com] > Sent: Tuesday, December 03, 2002 1:55 PM > To: 'Taylor, Stacy'; 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > I'm not sure that returning a larger block of address space > for a slightly smaller block is enough reason to accept the > exchange. Is there a way for the ARIN staff to ensure that > the space is "clean". I don't know of a easy way of doing > this, even over time the blocks stay on lists long after the > original SPAMer is gone. > > Dawn Martin > WorldCom IP Planning & Policy Analyst > dawn.martin at wcom.com > (703)886-4746 > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Taylor, Stacy > Sent: Tuesday, December 03, 2002 3:04 PM > To: 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > The block an organization would exchange would be for a > smaller block only. The goal is for organizations to turn in > space they are already not using, or could free up by consolidation. > > -----Original Message----- > From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] > Sent: Tuesday, December 03, 2002 11:27 AM > To: ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > much better reading... > > could this policy possibly be used to exchange blocks? > > meaning.. get one of the SAME size because the original is > getting 'dirty' (blocked by blacklist etc?). I hope that the > wording "shall receive a smaller block", really means a > SMALLER block; not one of the same size. > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Taylor, Stacy > > Sent: Tuesday, December 03, 2002 12:14 PM > > To: 'ppml at arin.net' > > Subject: [ppml] Policy 2002-5 > > > > > > Greetings All, > > > > To make good on my campaign promise to make our policies > > comply with the > > standards of the English language, I have altered policy > > 2002-5. How do you > > like this? > > > > > > If an organization, whether a member or non-member, ISP or > end-user, > > relinquishes a larger block of portable address space to ARIN, they > > shall be > > allowed to receive a smaller block, /24 or shorter, in > exchange. The > > organization will not be required to justify their use of the > > new, smaller > > block. The organization must return the block to be > > exchanged within 12 > > months. ARIN staff shall, at their discretion, determine > whether the > > smaller replacement block shall be a subnet of the returned > > block, or a > > block allocated from some different range. > > If any of the relinquished blocks had associated maintenance > > fees, then the > > new block will be subject to the appropriate fees for that > block size. > > Likewise those without maintenance fees shall remain so. > > > > > > I am also interested in continuing the discussion on the > > relative merits of > > this policy. > > > > Hope you had a great Thanksgiving! > > Stacy > > > From billd at cait.wustl.edu Tue Dec 3 18:05:05 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Tue, 3 Dec 2002 17:05:05 -0600 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: Good point, but perhaps the remedy is that the initial request is without audit of efficient use, but subsequent ones are...or... Justification is required only when the exchange block is above a certain size....or...... A list of all space under control of the requester is reviewed upon request to determine if this is the best aggregation possible (or acceptable)...or... as my original question....... maybe the hassle associated with this policy is such that the benefits are outweighed...... no response anywhere to that one, but I'm guessing that a lot of people think there is value or this proposal would not have gotten this far..... Bill Darte AC -----Original Message----- From: Ron da Silva To: ppml at arin.net Sent: 12/3/02 3:57 PM Subject: Re: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? On Tue, Dec 03, 2002 at 03:45:02PM -0600, Bill Darte wrote: > In the first place, you would not be able to return 12 a second time, > because you would return the original 12 for a single aggregated block which > would no longer fit the criteria of the policy...no? I suppose, if I had 12 /24s and they were "dirty" (whatever that means), I could trade in 3 of them for a /22. And then after some time, say 6 months, trade in that /22 along with another /24 for a /21. etc.. I could have a decent amount of space by the time I am done. Why not require that in order to exercise this policy the request must come from an ARIN member (which implies billing and justification are in place) ? rhetorically, -ron From Stacy_Taylor at icgcomm.com Tue Dec 3 18:00:15 2002 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 3 Dec 2002 16:00:15 -0700 Subject: [ppml] Policy 2002-5 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA017108F8@denexg21.icgcomm.com> Okay - is there a way to involve principal players from the blacklists in this discussion? Seems like they should be aware we are addressing the issue...... -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Tuesday, December 03, 2002 2:35 PM To: ppml at arin.net Subject: RE: [ppml] Policy 2002-5 Is there a way to have the blacklist remove the block ? RIR's have no control over blacklists. Thus if a blacklist feels the blocks are just being laundered they will keep them on the list. Then you have blacklists that don't remove today, even after the ISP was most active and zapped the offender. > Is there a way to inform the blacklists that a block has been > returned to the registry and should be removed from the list? > > Stacy > > > -----Original Message----- > From: Dawn Martin [mailto:dawn.martin at wcom.com] > Sent: Tuesday, December 03, 2002 1:55 PM > To: 'Taylor, Stacy'; 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > I'm not sure that returning a larger block of address space > for a slightly smaller block is enough reason to accept the > exchange. Is there a way for the ARIN staff to ensure that > the space is "clean". I don't know of a easy way of doing > this, even over time the blocks stay on lists long after the > original SPAMer is gone. > > Dawn Martin > WorldCom IP Planning & Policy Analyst > dawn.martin at wcom.com > (703)886-4746 > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Taylor, Stacy > Sent: Tuesday, December 03, 2002 3:04 PM > To: 'Trevor Paquette'; ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > The block an organization would exchange would be for a > smaller block only. The goal is for organizations to turn in > space they are already not using, or could free up by consolidation. > > -----Original Message----- > From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] > Sent: Tuesday, December 03, 2002 11:27 AM > To: ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > much better reading... > > could this policy possibly be used to exchange blocks? > > meaning.. get one of the SAME size because the original is > getting 'dirty' (blocked by blacklist etc?). I hope that the > wording "shall receive a smaller block", really means a > SMALLER block; not one of the same size. > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Taylor, Stacy > > Sent: Tuesday, December 03, 2002 12:14 PM > > To: 'ppml at arin.net' > > Subject: [ppml] Policy 2002-5 > > > > > > Greetings All, > > > > To make good on my campaign promise to make our policies > > comply with the > > standards of the English language, I have altered policy > > 2002-5. How do you > > like this? > > > > > > If an organization, whether a member or non-member, ISP or > end-user, > > relinquishes a larger block of portable address space to ARIN, they > > shall be > > allowed to receive a smaller block, /24 or shorter, in > exchange. The > > organization will not be required to justify their use of the > > new, smaller > > block. The organization must return the block to be > > exchanged within 12 > > months. ARIN staff shall, at their discretion, determine > whether the > > smaller replacement block shall be a subnet of the returned > > block, or a > > block allocated from some different range. > > If any of the relinquished blocks had associated maintenance > > fees, then the > > new block will be subject to the appropriate fees for that > block size. > > Likewise those without maintenance fees shall remain so. > > > > > > I am also interested in continuing the discussion on the > > relative merits of > > this policy. > > > > Hope you had a great Thanksgiving! > > Stacy > > > From broseman at ix.netcom.com Tue Dec 3 18:26:22 2002 From: broseman at ix.netcom.com (Barbara Roseman) Date: Tue, 03 Dec 2002 13:26:22 -1000 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? In-Reply-To: Message-ID: <5.0.2.1.2.20021203131038.0f0217c0@popd.ix.netcom.com> At 05:05 PM 12/3/2002 -0600, Bill Darte wrote: > Good point, but perhaps the remedy is that the initial request is without >audit of efficient use, but subsequent ones are...or... > >Justification is required only when the exchange block is above a certain >size....or...... > >A list of all space under control of the requester is reviewed upon request >to determine if this is the best aggregation possible (or >acceptable)...or... The original intent of the proposal (as I understood it) was to allow companies with non-aggregateable blocks of IPs to turn those in for an equal or smaller aggregate block of IPs. So, if a company has a /24, and a /23, and a /20, none of which are contiguous, the could renumber into a /19 or longer prefix. As written, it was intended to serve the needs of a fairly small segment of the IP community: those who found themselves with non-contiguous space in excess of their actual needs who had the time and resources to renumber into contiguous space. Would it make sense to be explicit about the non-contiguous, non-aggregatable nature of the blocks being exchanged? This would entail some kind of audit of IP space available to the user. Or, as Bill asks, is this too much trouble to establish as a policy for the too few numbers of users who are intended to benefit. -Barb From jlewis at lewis.org Tue Dec 3 22:19:36 2002 From: jlewis at lewis.org (jlewis at lewis.org) Date: Tue, 3 Dec 2002 22:19:36 -0500 (EST) Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F8@denexg21.icgcomm.com> Message-ID: Which blacklists? Blacklists come and go, and are too numerous and transient for the RIR's to try to notify them each time IP space is reassigned. If any such effort is made, it would make more sense to make net reassignment info available via HTTP in an easily parsable format, and then just hope the various "players" take notice and perhaps automate periodically checking this info and taking appropriate action. On Tue, 3 Dec 2002, Taylor, Stacy wrote: > Okay - is there a way to involve principal players from the blacklists in > this discussion? Seems like they should be aware we are addressing the > issue...... > > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Tuesday, December 03, 2002 2:35 PM > To: ppml at arin.net > Subject: RE: [ppml] Policy 2002-5 > > > Is there a way to have the blacklist remove the block ? > > RIR's have no control over blacklists. > > Thus if a blacklist feels the blocks are just being laundered > they will keep them on the list. > > Then you have blacklists that don't remove today, even after > the ISP was most active and zapped the offender. > > > Is there a way to inform the blacklists that a block has been > > returned to the registry and should be removed from the list? > > > > Stacy > > > > > > -----Original Message----- > > From: Dawn Martin [mailto:dawn.martin at wcom.com] > > Sent: Tuesday, December 03, 2002 1:55 PM > > To: 'Taylor, Stacy'; 'Trevor Paquette'; ppml at arin.net > > Subject: RE: [ppml] Policy 2002-5 > > > > > > I'm not sure that returning a larger block of address space > > for a slightly smaller block is enough reason to accept the > > exchange. Is there a way for the ARIN staff to ensure that > > the space is "clean". I don't know of a easy way of doing > > this, even over time the blocks stay on lists long after the > > original SPAMer is gone. > > > > Dawn Martin > > WorldCom IP Planning & Policy Analyst > > dawn.martin at wcom.com > > (703)886-4746 > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > > Behalf Of Taylor, Stacy > > Sent: Tuesday, December 03, 2002 3:04 PM > > To: 'Trevor Paquette'; ppml at arin.net > > Subject: RE: [ppml] Policy 2002-5 > > > > > > The block an organization would exchange would be for a > > smaller block only. The goal is for organizations to turn in > > space they are already not using, or could free up by consolidation. > > > > -----Original Message----- > > From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca] > > Sent: Tuesday, December 03, 2002 11:27 AM > > To: ppml at arin.net > > Subject: RE: [ppml] Policy 2002-5 > > > > > > much better reading... > > > > could this policy possibly be used to exchange blocks? > > > > meaning.. get one of the SAME size because the original is > > getting 'dirty' (blocked by blacklist etc?). I hope that the > > wording "shall receive a smaller block", really means a > > SMALLER block; not one of the same size. > > > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > > Taylor, Stacy > > > Sent: Tuesday, December 03, 2002 12:14 PM > > > To: 'ppml at arin.net' > > > Subject: [ppml] Policy 2002-5 > > > > > > > > > Greetings All, > > > > > > To make good on my campaign promise to make our policies > > > comply with the > > > standards of the English language, I have altered policy > > > 2002-5. How do you > > > like this? > > > > > > > > > If an organization, whether a member or non-member, ISP or > > end-user, > > > relinquishes a larger block of portable address space to ARIN, they > > > shall be > > > allowed to receive a smaller block, /24 or shorter, in > > exchange. The > > > organization will not be required to justify their use of the > > > new, smaller > > > block. The organization must return the block to be > > > exchanged within 12 > > > months. ARIN staff shall, at their discretion, determine > > whether the > > > smaller replacement block shall be a subnet of the returned > > > block, or a > > > block allocated from some different range. > > > If any of the relinquished blocks had associated maintenance > > > fees, then the > > > new block will be subject to the appropriate fees for that > > block size. > > > Likewise those without maintenance fees shall remain so. > > > > > > > > > I am also interested in continuing the discussion on the > > > relative merits of > > > this policy. > > > > > > Hope you had a great Thanksgiving! > > > Stacy > > > > > > ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jrace at attglobal.net Tue Dec 3 23:29:31 2002 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 04 Dec 2002 11:29:31 +0700 Subject: [ppml] Policy 2002-5 Message-ID: <200212040429.gB44TkYm087294@smtp1.arin.net> On Tue, 3 Dec 2002 15:10:37 -0700, Taylor, Stacy wrote: >Is there a way to inform the blacklists that a block has been returned to >the registry and should be removed from the list Announce on Spam-L From jrace at attglobal.net Wed Dec 4 00:21:11 2002 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 04 Dec 2002 12:21:11 +0700 Subject: [ppml] Policy 2002-5 Message-ID: <200212040521.gB45LQYm087882@smtp1.arin.net> On Tue, 3 Dec 2002 15:10:37 -0700, Taylor, Stacy wrote: >Is there a way to inform the blacklists that a block has been returned to >the registry and should be removed from the list? Announce on Spam-L Jeffrey Race From jrace at attglobal.net Wed Dec 4 00:22:12 2002 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 04 Dec 2002 12:22:12 +0700 Subject: [ppml] Policy 2002-5 Message-ID: <200212040522.gB45MOYm087893@smtp1.arin.net> On Tue, 3 Dec 2002 16:00:15 -0700, Taylor, Stacy wrote: >Okay - is there a way to involve principal players from the blacklists in >this discussion? Seems like they should be aware we are addressing the >issue...... They all read Spam-L From Michael.Dillon at radianz.com Wed Dec 4 03:38:59 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 4 Dec 2002 08:38:59 +0000 Subject: [ppml] Open discussion on Policy Proposal 2002-2 Message-ID: >I do not believe that the proposal says that an experimental RFC MUST be >published...what it does say is: I started by saying that the wording should be changed to remove references to other standards bodies. If you do that then there is no longer a preference for an IETF document because IETF documents become the only acceptable ones. In other words, I'm suggesting that all the vague weasel wording about this or that standards body should be removed and tightened up. The resulting policy would make it clear that ARIN defers to the IETF on matters of standards and on matters of experiments with IP that may require special experimental allocations. As I said, the intent of this change is to remove the possibility of misunderstanding and to remove the need for ARIN to discuss the merits of any particular proposal. The process should be that all issues get hashed out in the IETF, the experimental RFC goes to the RFC editor who then contacts ARIN to get a special allocation to include in the published RFC. ARIN's role should be clear, simple and non-political. --Michael Dillon From Michael.Dillon at radianz.com Wed Dec 4 05:43:52 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 4 Dec 2002 10:43:52 +0000 Subject: [ppml] Returning blocks of IP space Message-ID: Why are we proposing policies to return blocks of IP space? We are arguing the nitpicking details on wording but not only is there no "whereas" section on these policies, nobody has suggested any good reason to do this. For the record, I don't believe that it is a good reason to do this in order to right-size an organization's allocations. And it seems to me that this policy will result in many blocks being returned from the former class C range. If so, the result will be that ARIN will have many fragmented non-aggregatable blocks in the bank, so to speak. What on earth can we do with such a fragmented mess of unallocated IP space? If there is, in fact, a long term plan for the reorganization and reallocation of the former class C ranges, then I would like to see that discussed in detail before we put forth any policies regarding the swapping of old block for new. I believe we should be proceeding roughly as follows: 1. Assuming that there will come a time when we really do have to squeeze every last drop out of the IPv4 space, let's discuss and publish a plan for the reallocation of the space. This plan should simply assume that all organizations will give back the space when asked because the purpose of this plan is to look one step beyond the process of reclamation. I have suggested that this space could be subdivided into portions in which the largest aggregates are /24, /25, /26, /27, /28, /29 and one for /32. These allocations would go to organizations whose need for globally routable portable allocations is expected to remain rather constant over time. But perhaps someone has a better plan? Let's discuss this. 2. Having reached a consensus on what to do with the space, we will also know which blocks need to be returned and reallocated. At this point we can begin a swapping program with blockholders in the former Class C range. In parallel to this: 1. Assuming that it is a good thing for all IPv4 blockholders to be registered with ARIN, we should undertake a program of contacting and signing up organizations. The fees would be based on the organization's justified need for IP space. If their current allocation is in the former class C range then there will be no change in the allocation until a plan for reallocation of the former class C range has been agreed. Outside of that range, the allocation will be rightsized by shrinking or swapping the allocation. 2. ARIN should publish a directory, updated daily, that identifies all unallocated ARIN space at the largest aggregate level. This should be published in a form that would allow ISPs to use the directory (or a mirror of it) to configure their routers to filter these addresses from the Interner. Presumably this would be published as a BGP feed. In other words, there are two separate activities and they should have separate policies. One activity deals with allocating space and the other deals with getting everyone to maintain a relationship with ARIN. -- Michael Dillon From billd at cait.wustl.edu Wed Dec 4 07:59:19 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 4 Dec 2002 06:59:19 -0600 Subject: [ppml] Policy 2002-5 and 2002-6 with Spam-L Message-ID: So let's imagine that ARIN BoT proceeded with 2002-5 and 2002-6 in some fashion. Let's further assume that those that read Spam-L would heed the notice and remove listed blocks. Would this in effect be the laundering process that John Brown has referenced? If there were statements within the policies that eliminated the recurrent replacement (laundering of blocks) then would these policies and practice positively impact the industry and ARIN's ability to pursue its mission? Would there necessarily be some further 'investigation' or longer delay in reissuance be required to help insure the blocks were again viable? Would the cost of such a practice be prohibitive to ARIN and its members? Perhaps ARIN Staff would like to speculate on the cost/practice for such? Bill Darte AC -----Original Message----- From: Dr. Jeffrey Race To: dawn.martin at wcom.com; ppml at arin.net; Taylor, Stacy; Trevor Paquette Sent: 12/3/02 11:21 PM Subject: RE: [ppml] Policy 2002-5 On Tue, 3 Dec 2002 15:10:37 -0700, Taylor, Stacy wrote: >Is there a way to inform the blacklists that a block has been returned to >the registry and should be removed from the list? Announce on Spam-L Jeffrey Race From billd at cait.wustl.edu Wed Dec 4 08:16:16 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 4 Dec 2002 07:16:16 -0600 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: Barbara, Proposed..... (Bill Darte rewording) If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they will receive a block in exchange. The block received in exchange shall be /24 or shorter, but not shorter than need be in order to contain all of the returned blocks. Exchanged space shall be returned within 12 months. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, then replacement space will be without fee, but if any one of the returned blocks had associated maintenance fees, then the replacement block will also be subject to maintenance fees appropriate to the replacement block size. For example, if an organization relinquished three /24s, they would eligible to receive a /24, a /23, or a /22 in exchange. Is the "non-aggregatable" reference above (and in the original wording) not explicit enough? How few are we talking about? Are there not hundreds of non-contiguous blocks under a single authority out there now? What value to those with such assignments accrues to their use of this policy? If none, then why would anyone undergo renumbering nuisance?....except for being a good netizen? I am ambivelent about creating policies that won't be used in order to express ARIN's, and presumably, the industry's interest in paring the route table and 'potential' for more efficient allocation practice.... Are there other benefits like laundering? Bill Darte AC -----Original Message----- From: Barbara Roseman To: Bill Darte; 'Ron da Silva '; 'ppml at arin.net ' Sent: 12/3/02 5:26 PM Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? At 05:05 PM 12/3/2002 -0600, Bill Darte wrote: > Good point, but perhaps the remedy is that the initial request is without >audit of efficient use, but subsequent ones are...or... > >Justification is required only when the exchange block is above a certain >size....or...... > >A list of all space under control of the requester is reviewed upon request >to determine if this is the best aggregation possible (or >acceptable)...or... The original intent of the proposal (as I understood it) was to allow companies with non-aggregateable blocks of IPs to turn those in for an equal or smaller aggregate block of IPs. So, if a company has a /24, and a /23, and a /20, none of which are contiguous, the could renumber into a /19 or longer prefix. As written, it was intended to serve the needs of a fairly small segment of the IP community: those who found themselves with non-contiguous space in excess of their actual needs who had the time and resources to renumber into contiguous space. Would it make sense to be explicit about the non-contiguous, non-aggregatable nature of the blocks being exchanged? This would entail some kind of audit of IP space available to the user. Or, as Bill asks, is this too much trouble to establish as a policy for the too few numbers of users who are intended to benefit. -Barb From John.Sweeting at teleglobe.com Wed Dec 4 08:41:34 2002 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 4 Dec 2002 08:41:34 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BB85@usresms03.teleglobe.com> I tend to agree with you Barbara; this policy seems targeted to a very small segment of the community. I do not understand why the requested address space would not have to be justified, what is gained by waiving the justification? -----Original Message----- From: Barbara Roseman [mailto:broseman at ix.netcom.com] Sent: Tuesday, December 03, 2002 6:26 PM To: Bill Darte; 'Ron da Silva '; 'ppml at arin.net ' Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? At 05:05 PM 12/3/2002 -0600, Bill Darte wrote: > Good point, but perhaps the remedy is that the initial request is without >audit of efficient use, but subsequent ones are...or... > >Justification is required only when the exchange block is above a certain >size....or...... > >A list of all space under control of the requester is reviewed upon request >to determine if this is the best aggregation possible (or >acceptable)...or... The original intent of the proposal (as I understood it) was to allow companies with non-aggregateable blocks of IPs to turn those in for an equal or smaller aggregate block of IPs. So, if a company has a /24, and a /23, and a /20, none of which are contiguous, the could renumber into a /19 or longer prefix. As written, it was intended to serve the needs of a fairly small segment of the IP community: those who found themselves with non-contiguous space in excess of their actual needs who had the time and resources to renumber into contiguous space. Would it make sense to be explicit about the non-contiguous, non-aggregatable nature of the blocks being exchanged? This would entail some kind of audit of IP space available to the user. Or, as Bill asks, is this too much trouble to establish as a policy for the too few numbers of users who are intended to benefit. -Barb From dawn.martin at wcom.com Wed Dec 4 08:56:49 2002 From: dawn.martin at wcom.com (Dawn Martin) Date: Wed, 04 Dec 2002 08:56:49 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: Message-ID: <000d01c29b9c$febfc7a0$8dde2799@wcomnet.com> I do think there are individuals/companies that have many small blocks of space that would be willing to return them for a larger block, so in this I do think that the policy is needed. This is a policy that might only be used for a small amount of people. I think the small amount of our time put forth to put a policy together is worth any exchanges ARIN does. Saying that I'm also on the fence as to why ARIN should give more space than the company currently has just to get back a bunch of smaller blocks. In the example below from Bill, the company could request a /22 if they were returning 3 /24's, I think there still needs to be some justification. Maybe not so much for a /24, but if someone wants to turn /24, a /23, and a /20 and get a /19 I have to wonder if we are trading the cart for the horse. I would still like to hear some opinions on what ARIN should do if the 12 months comes and goes and they do not hear back from the trader about the old blocks. Dawn -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Bill Darte Sent: Wednesday, December 04, 2002 8:16 AM To: 'Barbara Roseman '; ''ppml at arin.net ' ' Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? Barbara, Proposed..... (Bill Darte rewording) If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they will receive a block in exchange. The block received in exchange shall be /24 or shorter, but not shorter than need be in order to contain all of the returned blocks. Exchanged space shall be returned within 12 months. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, then replacement space will be without fee, but if any one of the returned blocks had associated maintenance fees, then the replacement block will also be subject to maintenance fees appropriate to the replacement block size. For example, if an organization relinquished three /24s, they would eligible to receive a /24, a /23, or a /22 in exchange. Is the "non-aggregatable" reference above (and in the original wording) not explicit enough? How few are we talking about? Are there not hundreds of non-contiguous blocks under a single authority out there now? What value to those with such assignments accrues to their use of this policy? If none, then why would anyone undergo renumbering nuisance?....except for being a good netizen? I am ambivelent about creating policies that won't be used in order to express ARIN's, and presumably, the industry's interest in paring the route table and 'potential' for more efficient allocation practice.... Are there other benefits like laundering? Bill Darte AC -----Original Message----- From: Barbara Roseman To: Bill Darte; 'Ron da Silva '; 'ppml at arin.net ' Sent: 12/3/02 5:26 PM Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? At 05:05 PM 12/3/2002 -0600, Bill Darte wrote: > Good point, but perhaps the remedy is that the initial request is without >audit of efficient use, but subsequent ones are...or... > >Justification is required only when the exchange block is above a certain >size....or...... > >A list of all space under control of the requester is reviewed upon request >to determine if this is the best aggregation possible (or >acceptable)...or... The original intent of the proposal (as I understood it) was to allow companies with non-aggregateable blocks of IPs to turn those in for an equal or smaller aggregate block of IPs. So, if a company has a /24, and a /23, and a /20, none of which are contiguous, the could renumber into a /19 or longer prefix. As written, it was intended to serve the needs of a fairly small segment of the IP community: those who found themselves with non-contiguous space in excess of their actual needs who had the time and resources to renumber into contiguous space. Would it make sense to be explicit about the non-contiguous, non-aggregatable nature of the blocks being exchanged? This would entail some kind of audit of IP space available to the user. Or, as Bill asks, is this too much trouble to establish as a policy for the too few numbers of users who are intended to benefit. -Barb From ron at aol.net Wed Dec 4 09:14:03 2002 From: ron at aol.net (Ron da Silva) Date: Wed, 4 Dec 2002 09:14:03 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: <000d01c29b9c$febfc7a0$8dde2799@wcomnet.com> References: <000d01c29b9c$febfc7a0$8dde2799@wcomnet.com> Message-ID: <20021204141403.GA16551@aol.net> On Wed, Dec 04, 2002 at 08:56:49AM -0500, Dawn Martin wrote: > ...I would still like to hear some opinions on what ARIN should do if the > 12 months comes and goes and they do not hear back from the trader about > the old blocks... Reclamation of all blocks new and old of course! Now where is that confounded reclamation policy... ;-) -ron From john at chagres.net Wed Dec 4 12:11:42 2002 From: john at chagres.net (John M. Brown) Date: Wed, 4 Dec 2002 10:11:42 -0700 Subject: [ppml] Returning blocks of IP space In-Reply-To: Message-ID: <002301c29bb8$38271b90$7d7ba8c0@laptoy> > 2. ARIN should publish a directory, updated daily, that identifies all > unallocated ARIN space at the largest aggregate level. This should be > published in a form that would allow ISPs to use the directory (or a > mirror of it) to configure their routers to filter these addresses from > the Interner. Presumably this would be published as a BGP feed. Strongly disagree with this. 1. ARIN does not have the technical experience and operational clue to maintain this list. 2. ARIN does not have the financial ability to staff such a position 7x24x365, which would be needed incase of a posting error. 3. This is non-scalable and thus not useful. I see thousands of unallocated prefixes being announced. The filter sizes would be large and have a negative impact on router CPU performance. 4. BGP feed is non-scaleable without expending financial resources that could be better spent elsewhere. 5. Mirrors have a tendency to exacerbate the above problems. 6. Legal tort issues with screwing up the list and knocking someone off the net for X period of time. From john at chagres.net Wed Dec 4 12:20:39 2002 From: john at chagres.net (John M. Brown) Date: Wed, 4 Dec 2002 10:20:39 -0700 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: <000d01c29b9c$febfc7a0$8dde2799@wcomnet.com> Message-ID: <002401c29bb9$78a799a0$7d7ba8c0@laptoy> > I would still like to hear some opinions on what ARIN should > do if the 12 months comes and goes and they do not hear back > from the trader about the old blocks. > > Dawn RIR's have no control or authority over the global routing table. Ergo no way to reclaim those old blocks. and IMHO, RIR's should NOT have any control over the routing table. If after 12 months they still have servers or services running in those old blocks, to have them removed from the routing table could create a tort or restraint of trade legal issue that I'm not sure ARIN is financially able to deal with. From jlewis at lewis.org Wed Dec 4 12:27:09 2002 From: jlewis at lewis.org (jlewis at lewis.org) Date: Wed, 4 Dec 2002 12:27:09 -0500 (EST) Subject: [ppml] Returning blocks of IP space In-Reply-To: <002301c29bb8$38271b90$7d7ba8c0@laptoy> Message-ID: On Wed, 4 Dec 2002, John M. Brown wrote: > > 2. ARIN should publish a directory, updated daily, that identifies all > > unallocated ARIN space at the largest aggregate level. This should be > > published in a form that would allow ISPs to use the directory (or a > > mirror of it) to configure their routers to filter these addresses > from > > the Interner. Presumably this would be published as a BGP feed. > > Strongly disagree with this. > > 1. ARIN does not have the technical experience and operational > clue to maintain this list. That's hard to believe. Surely ARIN has or can easily produce a list of all IP ranges they're responsible for, and a list of the ranges not currently allocated. Saying they don't have the experience or clue to maintain such a list implies ARIN is not capable of doing their most basic job (allocation of IP space) since you can't reliably allocate space if you don't know your inventory. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From john at chagres.net Wed Dec 4 12:55:19 2002 From: john at chagres.net (John M. Brown) Date: Wed, 4 Dec 2002 10:55:19 -0700 Subject: [ppml] Returning blocks of IP space In-Reply-To: Message-ID: <002701c29bbe$5014b0e0$7d7ba8c0@laptoy> Providing a list in real time vs. providing a list that is manually reviewed are two different things. Its easy to allocate from NEW inventory, you ignore old inventory. If my memory of the staff and its skill sets is correct, the number of operationally experienced (as in running a backbone) is extreemly limited. A recent ARIN engineering employee also made this statement to me at a recent technical meeting. > -----Original Message----- > From: jlewis at lewis.org [mailto:jlewis at lewis.org] > Sent: Wednesday, December 04, 2002 10:27 AM > To: John M. Brown > Cc: ppml at arin.net > Subject: RE: [ppml] Returning blocks of IP space > > > On Wed, 4 Dec 2002, John M. Brown wrote: > > > > 2. ARIN should publish a directory, updated daily, that > identifies > > > all unallocated ARIN space at the largest aggregate level. This > > > should be published in a form that would allow ISPs to use the > > > directory (or a mirror of it) to configure their routers > to filter > > > these addresses > > from > > > the Interner. Presumably this would be published as a BGP feed. > > > > Strongly disagree with this. > > > > 1. ARIN does not have the technical experience and > operational clue > > to maintain this list. > > That's hard to believe. Surely ARIN has or can easily > produce a list of > all IP ranges they're responsible for, and a list of the ranges not > currently allocated. Saying they don't have the experience > or clue to > maintain such a list implies ARIN is not capable of doing > their most basic > job (allocation of IP space) since you can't reliably > allocate space if > you don't know your inventory. > > > ---------------------------------------------------------------------- > Jon Lewis *jlewis at lewis.org*| I route > System Administrator | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From william at elan.net Wed Dec 4 13:50:12 2002 From: william at elan.net (william at elan.net) Date: Wed, 4 Dec 2002 10:50:12 -0800 (PST) Subject: [ppml] Policy 2002-5 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA017108F1@denexg21.icgcomm.com> Message-ID: We still have several issues that needs to be addressed possibly as separate policies. 1. What will happen when member of arin paying for say /20 returns most of the block and now has say /23. It is unfair to charge that company as it was paying before for much smaller block. ARIN needs to create new billing scale with more then 4 levels. This new scale will also be usefull for several other proposed policies and the idea of new billing scale had been several times before, but this policy just makes it even more pressing to have this worked on sooner. 2. If company is giving up its ip blocks and it previously had blocks in normal arin class-a (i.e. 207, 209, 216, 64, etc), some isps have filters that will not allow advertisements of space < /20. Hence in this case ARIN should allocate new replacement block from different class-A. However ARIN had previously said it would not be allocating any blocks from the old "swamp" space, hence it would be necessary have some separate large ip block (class-A or possibly smaller) designated as new allocation block for blocks smaller then /20 that ARIN would provide as replacement. We do have something like this in ARIN's micro-allocation policy and I think this needs to be extended as general policy for small allocation that ARIN makes: - ARIN allocations and assignments of blocks smaller then its current minimum allocation for new members should be made from specific blocks reserved for this purpose. ARIN should make a list of these blocks publicly available. 3. As had been stated in other discussions we have a problem that some blocks that have been returned might have been used for activities that caused them to be blocked at some isps (blacklisted blocks). Clearly if such blocks are reissued it would create problems, so I think its important that information about which ip block had been returned to ARIN be made available. This can be separate small policy that would apply to all situation where ARIN gets blocks back and puts it into "unallocated" category, i.e. something like this: - ARIN should make publicly available list of blocks that had been previously allocated and then returned back to ARIN. ARIN should wait 12 months or more before re-allocating previously returned blocks. I think year will be enough for blacklist operators to remove the blocks, perhaps waiting period could even be shorter. 4. As had been stated in discussions of 2002-6, its possible that 2002-6 as well as 2002-5 maybe used to get replacements for blocks that had been put in the blacklists (i.e. spammer trying to get new ip block as replacement for its current block). While I really do not like this, I do not necessarily think that ARIN should become "net-police" and I don't think this along should be used not to pass policy that would otherwise be in benefit of internet community. But clearly arin should keep some kind of statistics of who uses these policies and not necessarily allow for immediate use of the policy (especially if somebody where to try to use it twice!). Possibly also the list of blocks to be exchanged due to 2002-5 and 2002-6 policies can be made made available prior to the block being completed returned. The above suggestion in #3 was for list to be published after the block is returned, but perhaps list can also be published for blocks that are expected to be returned as well and if the list states when the block would no longer be used, then waiting period before ARIN could reuse the block could be shorter too. Additionally probably it should be allowed for somebody to comment to ARIN (perhaps to specially designated email) when the block being returned had been in blacklists and possibly company that had it was involved in questionable activities. I'm not certain ARIN should actually do anything due to this complaints, but perhaps keeping statistics of how often this happens would be usefull for future discussions and policy making. --- William Leibzon william at elan.net On Tue, 3 Dec 2002, Taylor, Stacy wrote: > Greetings All, > > To make good on my campaign promise to make our policies comply with the > standards of the English language, I have altered policy 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to ARIN, they will be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the new, smaller > block. The organization must return the block to be exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From Stacy_Taylor at icgcomm.com Wed Dec 4 14:17:39 2002 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Wed, 4 Dec 2002 12:17:39 -0700 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA01710902@denexg21.icgcomm.com> That's so funny! I agree with Bill. I was thinking just the same thing last night. How much will 2002-5 and 2002-6 really benefit the Registry and the routing tables? People have pointed out many ways to abuse both of these policies. And renumbering is a huge pain as we all know. How much are we really advancing our cause with these two? Stacy -----Original Message----- From: Bill Darte [mailto:billd at cait.wustl.edu] Sent: Wednesday, December 04, 2002 5:16 AM To: 'Barbara Roseman '; ''ppml at arin.net ' ' Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? Barbara, Proposed..... (Bill Darte rewording) If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they will receive a block in exchange. The block received in exchange shall be /24 or shorter, but not shorter than need be in order to contain all of the returned blocks. Exchanged space shall be returned within 12 months. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, then replacement space will be without fee, but if any one of the returned blocks had associated maintenance fees, then the replacement block will also be subject to maintenance fees appropriate to the replacement block size. For example, if an organization relinquished three /24s, they would eligible to receive a /24, a /23, or a /22 in exchange. Is the "non-aggregatable" reference above (and in the original wording) not explicit enough? How few are we talking about? Are there not hundreds of non-contiguous blocks under a single authority out there now? What value to those with such assignments accrues to their use of this policy? If none, then why would anyone undergo renumbering nuisance?....except for being a good netizen? I am ambivelent about creating policies that won't be used in order to express ARIN's, and presumably, the industry's interest in paring the route table and 'potential' for more efficient allocation practice.... Are there other benefits like laundering? Bill Darte AC -----Original Message----- From: Barbara Roseman To: Bill Darte; 'Ron da Silva '; 'ppml at arin.net ' Sent: 12/3/02 5:26 PM Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? At 05:05 PM 12/3/2002 -0600, Bill Darte wrote: > Good point, but perhaps the remedy is that the initial request is without >audit of efficient use, but subsequent ones are...or... > >Justification is required only when the exchange block is above a certain >size....or...... > >A list of all space under control of the requester is reviewed upon request >to determine if this is the best aggregation possible (or >acceptable)...or... The original intent of the proposal (as I understood it) was to allow companies with non-aggregateable blocks of IPs to turn those in for an equal or smaller aggregate block of IPs. So, if a company has a /24, and a /23, and a /20, none of which are contiguous, the could renumber into a /19 or longer prefix. As written, it was intended to serve the needs of a fairly small segment of the IP community: those who found themselves with non-contiguous space in excess of their actual needs who had the time and resources to renumber into contiguous space. Would it make sense to be explicit about the non-contiguous, non-aggregatable nature of the blocks being exchanged? This would entail some kind of audit of IP space available to the user. Or, as Bill asks, is this too much trouble to establish as a policy for the too few numbers of users who are intended to benefit. -Barb From broseman at ix.netcom.com Wed Dec 4 16:36:10 2002 From: broseman at ix.netcom.com (Barbara Roseman) Date: Wed, 04 Dec 2002 11:36:10 -1000 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Pr oposal??? In-Reply-To: Message-ID: <5.0.2.1.2.20021204113511.036277b0@popd.ix.netcom.com> At 07:16 AM 12/4/2002 -0600, Bill Darte wrote: >Barbara, > >Proposed..... (Bill Darte rewording) >If any organization relinquishes a group of portable, non-aggregatable >address blocks to ARIN, they will receive a block in exchange. The block >received in exchange shall be /24 or shorter, but not shorter than need be >in order to contain all of the returned blocks. Exchanged space shall be >returned within 12 months. If all of the previous address blocks were >maintained in the ARIN database without maintenance fees, then replacement >space will be without fee, but if any one of the returned blocks had >associated maintenance fees, then the replacement block will also be subject >to maintenance fees appropriate to the replacement block size. For example, >if an organization relinquished three /24s, they would eligible to receive a >/24, a /23, or a /22 in exchange. > >Is the "non-aggregatable" reference above (and in the original wording) not >explicit enough? Oops, my bad. I didn't read your version with enough attention, I got caught up in some replies that seemed to indicate the wording wasn't there. -Barb From jmcburnett at msmgmt.com Wed Dec 4 17:32:32 2002 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 4 Dec 2002 17:32:32 -0500 Subject: [ppml] Policy 2002-5 Message-ID: <390E55B947E7C848898AEBB9E50770600EB4AC@msmdcfs01.msmgmt.com> SNIP>>> - ARIN should make publicly available list of blocks that had been previously allocated and then returned back to ARIN. ARIN should wait 12 months or more before re-allocating previously returned blocks. -------- Can't you almost do that now? By going and check the block owner list at the FTP site? and then going to historical files? Not sure just asking... -------- SNIP>>> completed returned. The above suggestion in #3 was for list to be published after the block is returned, but perhaps list can also be published for blocks that are expected to be returned as well and if the list states when the block would no longer be used, then waiting period before ARIN could reuse the block could be shorter too. Additionally probably it should be allowed for somebody to comment to ARIN (perhaps to specially designated email) when the block being returned had been in blacklists and possibly company that had it was involved in questionable activities. I'm not certain ARIN should actually do anything due to this complaints, but perhaps keeping statistics of how often this happens would be usefull for future discussions and policy making. SNIP>>>> I like this idea, and I realize one of my suggestions earlier would have proposed the use of the "NET-FORCE" concept. But I can equate the use of -5 and -6 to getting a used car, but with a used car I can see how much it was abused. Jim -----Original Message----- From: william at elan.net [mailto:william at elan.net] Sent: Wednesday, December 04, 2002 1:50 PM To: ppml at arin.net Subject: Re: [ppml] Policy 2002-5 We still have several issues that needs to be addressed possibly as separate policies. 1. What will happen when member of arin paying for say /20 returns most of the block and now has say /23. It is unfair to charge that company as it was paying before for much smaller block. ARIN needs to create new billing scale with more then 4 levels. This new scale will also be usefull for several other proposed policies and the idea of new billing scale had been several times before, but this policy just makes it even more pressing to have this worked on sooner. 2. If company is giving up its ip blocks and it previously had blocks in normal arin class-a (i.e. 207, 209, 216, 64, etc), some isps have filters that will not allow advertisements of space < /20. Hence in this case ARIN should allocate new replacement block from different class-A. However ARIN had previously said it would not be allocating any blocks from the old "swamp" space, hence it would be necessary have some separate large ip block (class-A or possibly smaller) designated as new allocation block for blocks smaller then /20 that ARIN would provide as replacement. We do have something like this in ARIN's micro-allocation policy and I think this needs to be extended as general policy for small allocation that ARIN makes: - ARIN allocations and assignments of blocks smaller then its current minimum allocation for new members should be made from specific blocks reserved for this purpose. ARIN should make a list of these blocks publicly available. 3. As had been stated in other discussions we have a problem that some blocks that have been returned might have been used for activities that caused them to be blocked at some isps (blacklisted blocks). Clearly if such blocks are reissued it would create problems, so I think its important that information about which ip block had been returned to ARIN be made available. This can be separate small policy that would apply to all situation where ARIN gets blocks back and puts it into "unallocated" category, i.e. something like this: - ARIN should make publicly available list of blocks that had been previously allocated and then returned back to ARIN. ARIN should wait 12 months or more before re-allocating previously returned blocks. I think year will be enough for blacklist operators to remove the blocks, perhaps waiting period could even be shorter. 4. As had been stated in discussions of 2002-6, its possible that 2002-6 as well as 2002-5 maybe used to get replacements for blocks that had been put in the blacklists (i.e. spammer trying to get new ip block as replacement for its current block). While I really do not like this, I do not necessarily think that ARIN should become "net-police" and I don't think this along should be used not to pass policy that would otherwise be in benefit of internet community. But clearly arin should keep some kind of statistics of who uses these policies and not necessarily allow for immediate use of the policy (especially if somebody where to try to use it twice!). Possibly also the list of blocks to be exchanged due to 2002-5 and 2002-6 policies can be made made available prior to the block being completed returned. The above suggestion in #3 was for list to be published after the block is returned, but perhaps list can also be published for blocks that are expected to be returned as well and if the list states when the block would no longer be used, then waiting period before ARIN could reuse the block could be shorter too. Additionally probably it should be allowed for somebody to comment to ARIN (perhaps to specially designated email) when the block being returned had been in blacklists and possibly company that had it was involved in questionable activities. I'm not certain ARIN should actually do anything due to this complaints, but perhaps keeping statistics of how often this happens would be usefull for future discussions and policy making. --- William Leibzon william at elan.net On Tue, 3 Dec 2002, Taylor, Stacy wrote: > Greetings All, > > To make good on my campaign promise to make our policies comply with the > standards of the English language, I have altered policy 2002-5. How do you > like this? > > > If an organization, whether a member or non-member, ISP or end-user, > relinquishes a larger block of portable address space to ARIN, they will be > allowed to receive a smaller block, /24 or shorter, in exchange. The > organization will not be required to justify their use of the new, smaller > block. The organization must return the block to be exchanged within 12 > months. ARIN staff shall, at their discretion, determine whether the > smaller replacement block shall be a subnet of the returned block, or a > block allocated from some different range. > If any of the relinquished blocks had associated maintenance fees, then the > new block will be subject to the appropriate fees for that block size. > Likewise those without maintenance fees shall remain so. > > > I am also interested in continuing the discussion on the relative merits of > this policy. > > Hope you had a great Thanksgiving! > Stacy > From jmcburnett at msmgmt.com Wed Dec 4 17:36:53 2002 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 4 Dec 2002 17:36:53 -0500 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? Message-ID: <390E55B947E7C848898AEBB9E50770602F2924@msmdcfs01.msmgmt.com> Good Point John, but the question remains. What do we do when IP user A has not returned those IP address? When IPv4 is closer to complete exhaustion there will be an issue with turn around time to reallocation/reissue. And when someone is got their new block and is only partially using their old block, someone else might be in a holding pattern..... Jim -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Wednesday, December 04, 2002 12:21 PM To: dawn.martin at wcom.com; ppml at arin.net Subject: RE: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? > I would still like to hear some opinions on what ARIN should > do if the 12 months comes and goes and they do not hear back > from the trader about the old blocks. > > Dawn RIR's have no control or authority over the global routing table. Ergo no way to reclaim those old blocks. and IMHO, RIR's should NOT have any control over the routing table. If after 12 months they still have servers or services running in those old blocks, to have them removed from the routing table could create a tort or restraint of trade legal issue that I'm not sure ARIN is financially able to deal with. From john at chagres.net Wed Dec 4 17:48:49 2002 From: john at chagres.net (John M. Brown) Date: Wed, 4 Dec 2002 15:48:49 -0700 Subject: [ppml] Wording issues with the 2002-6 Aggregation Requests Proposal??? In-Reply-To: <390E55B947E7C848898AEBB9E50770602F2924@msmdcfs01.msmgmt.com> Message-ID: <000601c29be7$4f5f1fe0$f9ecdfd8@laptoy> The sky is falling..... I believe the most recent exhaustion date is sometime around 2030, but lets say its really 2010, a meer 7 years away. Where is IPv6?? and will there be a cross over in usage needs once v6 gets going??? The only time the RIR's should beable to "reclaim" space is if its not in the global routing tables for a solid 12 months. Exceptions to this are IX's and private networks. The day we let the RIR's control whats in the routing table is going to be a very bad day. Tort and other issues will abound. If v6 isn't going to help solve this problem, then I'd like to see us work more on getting v6 deployed globally. > -----Original Message----- > From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > Sent: Wednesday, December 04, 2002 3:37 PM > To: john at chagres.net; dawn.martin at wcom.com; ppml at arin.net > Subject: RE: [ppml] Wording issues with the 2002-6 > Aggregation Requests Proposal??? > > > Good Point John, > but the question remains. What do we do when IP user A has > not returned those IP address? When IPv4 is closer to > complete exhaustion there will be an issue with turn around > time to reallocation/reissue. And when someone is got their > new block and is only partially using their old block, > someone else might be in a holding pattern..... > > Jim > > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Wednesday, December 04, 2002 12:21 PM > To: dawn.martin at wcom.com; ppml at arin.net > Subject: RE: [ppml] Wording issues with the 2002-6 > Aggregation Requests Proposal??? > > > > I would still like to hear some opinions on what ARIN should > > do if the 12 months comes and goes and they do not hear back > > from the trader about the old blocks. > > > > Dawn > > RIR's have no control or authority over the global routing > table. Ergo no way to reclaim those old blocks. > > and IMHO, RIR's should NOT have any control over the routing table. > > If after 12 months they still have servers or services > running in those old blocks, to have them removed from the > routing table could create a tort or restraint of trade legal > issue that I'm not sure ARIN is financially able to deal with. > From Michael.Dillon at radianz.com Thu Dec 5 05:51:06 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 5 Dec 2002 10:51:06 +0000 Subject: [ppml] Returning blocks of IP space Message-ID: > > 2. ARIN should publish a directory, updated daily, that identifies all > > unallocated ARIN space at the largest aggregate level. This should be > 1. ARIN does not have the technical experience and operational > clue to maintain this list. ARIN already maintains such a list internally in order to know which IP addresses are available to allocate for any new allocations. It doesn't take much operational clue to dump this database (presumably an RDBMS) into a directory and publish that. Since the people who do have operational clue like to use BGP as the format for publishing lists of IP address blocks (i.e. RBL, etc.) it seems reasonable that ARIN should also publish their directory in that format. > 2. ARIN does not have the financial ability to staff such a position > 7x24x365, which would be needed incase of a posting error. Anyone who connects ARIN's announce-only BGP feed directly into production Internet routers is nuts. The BGP feed is there to *PUBLISH* the directory, i.e. make the information available. I won't tell network operators how to deal with the feed but I'd suggest that it makes most sense to mirror the ARIN directory data internally and when it changes, have some internal process that checks the changes and then moves them into the system that generates route filters. Whenever there is an abuse incident, the response team will have the data available and can expedite this process if they choose. > 3. This is non-scalable and thus not useful. I see thousands of > unallocated prefixes being announced. The filter sizes would be > large and have a negative impact on router CPU performance. I said something about the ARIN list being the largest possible aggregate size. And let me remind you about a technique called BGP route filtering that allows someone receiving a BGP feed like ARIN's to ignore routes smaller than a certain size. :-P > 4. BGP feed is non-scaleable without expending financial resources > that could be better spent elsewhere. Everything costs money. It's up to the ARIN members and BoT to decide the wise ways to spend that money. > 5. Mirrors have a tendency to exacerbate the above problems. You cannot prohibit people from recording a copy of the data they receive. In fact, the whole routing registry concept encourages it. Also, if you are running a network that depends on having the ARIN filters in place then you will not want to be dependent on a live BGP connection to ARIN. Therefore best practice would be to mirror the data and configure your routers from the mirror. > 6. Legal tort issues with screwing up the list and knocking someone > off the net for X period of time. Let the BoT and the lawyers worry about the law. IMHO there is no tort issue for ARIN to publish their authoritative data that describes the factual state of the IPv4 address space. --Michael Dillon From Michael.Dillon at radianz.com Thu Dec 5 06:03:34 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 5 Dec 2002 11:03:34 +0000 Subject: [ppml] Policy 2002-5 Message-ID: > > - ARIN should make publicly available list of blocks that had been > >previously allocated and then returned back to ARIN. ARIN should wait > >12 months or more before re-allocating previously returned blocks. -------- > Can't you almost do that now? By going and check the block owner list at the FTP site? and then going to historical files? > Not sure just asking... Yes you may be able to almost do this using existing data and going to a lot of trouble. It's a half-baked solution and I want to replace it with a well thought-out solution that makes it easy for people to access and use the data. > Additionally > probably it should be allowed for somebody to comment to ARIN (perhaps to > specially designated email) when the block being returned had been in > blacklists and possibly company that had it was involved in questionable > activities. If ARIN publishes a complete list of unallocated blocks there will no longer be any problem with blacklists or tainted space. That's because when the system is up and running, I will put forth the suggestion that ARIN should post a weekly message to SPAM-L and a few other places summarizing the week's activity, i.e. returned allocations, new allocations, allocations out of previously used space. After a while the blacklisting community will get the idea that they too can use the ARIN directory. For instance a mail server checks the IP address against the ARIN database before accepting incoming email. Of course this uses the base LDAP directory rather than the BGP format. And ARIN encourages heavy users to mirror the data and use their own LDAP server for this. -- Michael Dillon From Ted.Hardie at nominum.com Wed Dec 11 14:54:12 2002 From: Ted.Hardie at nominum.com (Ted Hardie) Date: Wed, 11 Dec 2002 11:54:12 -0800 (PST) Subject: [ppml] Address space allocations for experimental purposes Message-ID: <200212111954.LAA15339@geode.he.net> This policy proposal has two areas which I believe require clarification. The first relates to the use of Experimental RFCs as a mechanism for publishing information on the proposed use of a prefix allocated to an experiment. While I understand and support ARIN's desire to have an open statement on the use of an allocation, I do not believe this should be the primary method for most allocations. Discussions with one of the draft policy's authors indicate to me that there is an underlying assumption that experimental allocations consume address space in a way different from a normal allocation. I think that assumption needs to be reconsidered and possibly made more explicit. Under normal policies, if a prefix is allocated to an organization, that organization uses it for a period of time and may return it, trade it in, or do any number of other things which do not require anything like peer review. They do require meeting the RIR's policies. In the normal case, that means proving need and paying money. I agree that experiments need to prove need, but proving the need for an allocation seems onerous under this policy. It will take, at the very least, many months and the time and effort of people not normally involved in allocation decisions. For experiments which do not: 1) permanently remove a prefix from the available pool 2) change the way operators or implementors must treat the allocated prefix 3) force a global change to filtering mechanisms It seems to place an un-needed burden on the experimenter, the RFC editor, and the relevant ADs. To use a concrete example, if CAIDA had needed to ask for a prefix for its backscatter analysis (http://www.caida.org/outreach/papers/2001/BackScatter/), would this method have made sense? I suggest that the policy should indicate that allocations will be made only when open statements are made which prove the need for the allocation by describing the experiment. These can be reviewed along the lines of the "designated expert" rules used for IANA allocations (see RFC 2434). I suspect that for ARIN the advisory council could serve as or select the appropriate designated expert. Publication of the open statements leading to short-term allocations could be along the lines of the IETF's IPR statements; that is, documented at a well known place on the appropriate RIR's web site. This would work for any allocation which, in essence, behaved like a normal allocation to an ISP or other RIR member organization. Under the current proposal, an Experimental RFC is strongly preferred even for allocations of this type. That seems to strong and too slow. On the other hand, where the experiment would require an allocation that met one of the three tests above, an approved experimental or standards track RFC does seem appropriate and should be absolutely required. In each of those cases, a very broad section of the Internet community is affected on a long-term basis. Using the IETF's mechanisms for garnering community review and determining consensus seems appropriate here. I suspect it would be needed very rarely (as most of the folks I know running experiments of this type are deliberately trying to avoid this kind of effect), but it should be available when needed. The determination that it will be needed could either be made by the experimenter directly or after the determination that it met one of the tests had been made by the designated expert(s). On a related matter, this document contains the following language on an IETF liaison requirement: "Organisations such as the IETF, who describe experimental activities as part of their standards development process, need to consider the associated Numbering Resource requirements with any proposed experiment, and under this proposal will need to liaise with the RIRs as part of the process of publishing a draft as an Experimental RFC". This is not clear enough to me to know how this liaison works. As I personally understand it, these issues are currently handled by the publication of drafts and/or RFCs with IANA considerations sections noting the relevant details. This policy requests(requires?) the IETF to take a more active role in the liaison. Leaving aside the question of which body in the IETF would do the work, it's not clear who they talk to and how, or what role each plays. It would be far easier to ensure that the right things happen if it were more concrete, as for example: "When the IETF's standards development process requires a change in the use of Numbering Resources on an experimental or permanent basis, the IESG should notify the RIRs by electronic mail to email at example.net on or before the beginning of the last call period of the document which describes the change, so that the RIRs can consult with the IETF on the use of Numbering Resources required by the change. Should the proposal to make a change not be in a document which will go through last call, a message documenting the proposal should be sent to the same address at least one month before the IESG considers the proposal for publication as an RFC. The RIRs shall singly or as a body respond to such notification by mail to one of the following: iesg at ietf.org or ietf at ietf.org." This may well not be the right process, of course, but I believe some language is necessary which documents the liaison process in enough detail to allow an observer to know whether or not it was followed. I understand that there have been some discussions on how the IETF can increase its cooperation with the RIRs, and it may be that this language cannot be too precise until those discussions have been completed; in that case, some forward reference to the outcome of those discussions may be the best way to craft the policy at this time. best regards, Ted Hardie From gih at telstra.net Wed Dec 11 21:06:44 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 12 Dec 2002 13:06:44 +1100 Subject: [ppml] 2002-02 Address space allocations for experimental purposes In-Reply-To: <200212111954.LAA15339@geode.he.net> Message-ID: <5.1.0.14.2.20021212114929.0200aed8@kahuna.telstra.net> A few comments to Ted's note and a proposed revision/edit to the policy. Firstly it is true that there are wide variety of experiments that are conducted on the Internet today that use existing allocated number resources, and the extent to which these experiments are coordinated technically with various folk who perceive that they have some interest in this is a matter for the experimenters. Such activities fall outside the scope of this policy proposal. There have been in the past a number of experiments that have some direct relationship with address allocation. The experimental use of 39.0.0.0/8 in the early days of CIDR deployment is a fine example. Experiments in the dynamic behaviour of the BGP routing system using particular test address prefixes could concievably be another such experiment. (Note that I'm attempting to illustrate the scope of such activities, rather than enter in to a discussion of the metirs or otherwise of such examples) The observation is that there is no clear way in the current IETF / IANA / RIR environment for this latter type of experiment to be undertaken. It is my understanding of the worrent working relationships between these bodes that the IETF cannot undertake temporary address alssignments to end users for such experiments, and that the IANA undertakes address allocations to RIRs, so that the IANA is in no position to undertake this role either. And right now there is no RIR policy to undertake such assignments outside of the conventional policies. This policy is intended to allow the RIRs, and in this case ARIN in particular, to undertake such temporary address assignments. The basic question here is of course is "what is an experiment in this context"? Obviously this is a difficult question to rigidly define in advance, so the proposal attempts instead to document how an experiment that proposes temporary use of Internet number resources should be described. The lowest common denominator is that the use of such resources should be justified in a public experiment proposal. Over and above this lowest common denominator there is a stated preference for documented experiments that exhibit some background of technical coordination - obviously there is some reticence by all of us to support experiments that may have some negative impact on the operation of the Internet. The policy proposal points to the IETF as a preferred venue for such technical coordination and uses a reference to experimental RFCs as a demonstration of an experiment proposal that has been subject to some review within the IETF that would include consideration of technical coordination. Comments I have received on this preference have included observations of the extended time for an experiment proposal to be published by the IETF as an experimental RFC, and one concrete proposal to address this was to use the wording of a document that has achieved "IETF consensus" where this consensus is described in RFC 2434. This would allow Internet drafts to be referenced, under the specific circumstances where the draft has achieved this consensus. Of course this poses the issue of how the RIRs could, as an external body, clearly identify the difference between a draft that has achieved this consensus and one that has not. One proposed refinement of this is to allow the RIRs to refer such experiment proposals to some form of liaison with the IETF. Another comment I've received is that there is an Internet Research Task Force and it too may have a motivation to propose such an experiment. It is not clear that an IRTF proposal along these lines should also need to obtain IESG approval via this proposed RFC 2434 IETF consensus. I have also revieved various comments along the lines that "all such proposed experiments should be described in such a RFC 2434 IETF consensus document" and other comments that "this is desireable but should not be a mandatory constraint". From all these discussions I've noted that there appears to a rough consensus that some form of technical coordination is prudent and responsible for such experiment proposals, bit some variation on how this technical coordination should be undertaken. I would suggest that Ted's suggestion of using the ARIN Advicory Council as a "designated expert reviewer" is a way forward, and if you combine this with the option for the designated expert reviewer to utilize a liaison mechanism with the IETF to obtain specific advice on matters of technical coordination then this could address many of the uncertainties that have been voiced about this proposal (obviously some of the comments have been direct opposites and I'm not claiming that this is a full synthesis of all comments). So in that vein I would like to propose, as an individual contribution to this ARIN consideration of this proposed policy, a re-wording of the policy proposal - it attempts to rephrase the first three sections to make them clearer, as well as taking into account the considerations noted in text above, and includes the designated expert reviewer role. It also specifically words this as an ARIN policy, as I understand that the other RIRs have / are considering different wording in their regions. kind regards, Geoff ================================================ 2002-2: Experimental Internet Resource Allocations There have been a number of experimental address allocations undertaken in the Internet over the past decade. These experimental address allocations have been made by the IANA in coordination with the IETF, on an ad hoc basis. There is currently no systematic means of receiving other Numbering Resources on a temporary basis as part of a recognized experiment in Internet technology deployment. The following policy is proposed: ARIN will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognized experimental activity. The following criteria for this policy are proposed: 1. Documentation of recognized experimental activity A Recognized Experimental Activity is one where the experiment's objectives and practices are described in a publicly accessible document. It is a normal requirement that a Recognized Experimantal Activity also includes the undertaking that the experiment's outcomes also be published in a publically accessible document. A "publically accessible document" is a document that is publicly and openly available free of charges and free of any constraints of disclosure. ARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed. ARIN has a strong preference for the recognition of experimental activity documentation in the form of a document which has achieved "IETF consensus" as described in RFC 2434. 2. Technical Coordination ARIN requires that a recognized experimental activity is able to demonstrate that the activity is technically coordinated. Technical coordination specifically includes consideration of any potential negative impact of the propsed experiment on the operation of the Internet and its deployed services, and consideration of any related experimental activity. ARIN will use a designated expert reviewer to review experimental activities to ensure that the activity is technically coordinated. The reviewer may liaise with the IETF to complete this review. 3. Coordination over Resource Use When the IETF's standards development process proposes a change in the use of Numbering Resources on an experimental basis the IETF should use a liaison mechanism with the Regional Internet Registries (RIRs) of this proposal. The RIRs will jointly or severally respond to the IETF using the same liaison mechanism. 4. Resource Allocation Term and Renewal The Numbering Resources are allocated on a lease/license basis for a period of one year. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN's normal publication policy. 5. Single Resource Allocation per Experiment ARIN will make one-off allocations only, on an annual basis to any applicant. Additional allocations to an organization already holding experimental activity resources relating to the specified activity outside the annual cycle will not be made unless justified by a subsequent complete application. It's important for the requesting organization to ensure they have sufficient resources requested as part of their initial application for the proposed experimental use. 6. Resource Allocation Fees ARIN may charge an administration fee to cover each allocation made of these experimental resources. This fee simply covers registration and maintenance, rather than the full allocation process for standard ARIN members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. 7. Resource Allocation Size The Numbering Resources requested come from the global Internet Resource space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required. 8. Commercial Use Prohibited If there is any evidence that the temporary resource is being used for commercial purposes, or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource and reassign it to the free pool. 9. Resource Request Appeal or Arbitration ARIN reserves the ability to assess and comment on the objectives of the experiment with regard to the requested amount of Numbering Resources and its technical coordination. ARIN reserves the ability to modify the requested allocation as appropriate, and in agreement with the proposer. In the event that the proposed modifications are not acceptable, the requesting organization may request an appeal or arbitration using the normal ARIN procedures. In this case, the original proposer of the experimental activity may be requested to provide additional information regarding the experiment, its objectives and the manner of technical coordination, to assist in the resolution of the appeal. ================================================ From billd at cait.wustl.edu Thu Dec 12 09:41:14 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 12 Dec 2002 08:41:14 -0600 Subject: [ppml] 2002-02 Address space allocations for experimental pur poses Message-ID: >From below.......... > > 2. Technical Coordination > > ARIN requires that a recognized experimental activity is able to > demonstrate that the activity is technically coordinated. > > Technical coordination specifically includes consideration of any > potential negative impact of the propsed experiment on the > operation of the Internet and its deployed services, and > consideration of any related experimental activity. > > ARIN will use a designated expert reviewer to review experimental > activities to ensure that the activity is technically coordinated. The > reviewer may liaise with the IETF to complete this review. > I believe that the paragraph above could be stated as follows... ARIN will review planned experimental activities to ensure that they are technically coordinated. This review will be conducted with ARIN and/or third-party expertise and will include liaison with the IETF. This removes the connotation that 'an expert' will be involved rather than what is more likely a committee of review. It also states what is implicit.... that the coordination review will take place prior to the experimental allocation. If a continuous liaison with IETF is needed to ensure continuing technical coordination is supported, then the last sentence could read..... This review will be conducted with ARIN and/or third-party expertise and will include continuous liaison with the IETF throughout the experiment. If this helps, I'm gratified. If not, well.... it was only a tweak anyway. Bill Darte ARIN AC > -----Original Message----- > From: Geoff Huston [mailto:gih at telstra.net] > Sent: Wednesday, December 11, 2002 8:07 PM > To: ppml at arin.net > Subject: Re: [ppml] 2002-02 Address space allocations for experimental > purposes > > > A few comments to Ted's note and a proposed revision/edit to > the policy. > > Firstly it is true that there are wide variety of experiments > that are > conducted on the Internet today that use existing allocated number > resources, and the extent to which these experiments are coordinated > technically with various folk who perceive that they have > some interest in > this is a matter for the experimenters. Such activities fall > outside the > scope of this policy proposal. > > There have been in the past a number of experiments that have > some direct > relationship with address allocation. The experimental use of > 39.0.0.0/8 in > the early days of CIDR deployment is a fine example. > Experiments in the > dynamic behaviour of the BGP routing system using particular > test address > prefixes could concievably be another such experiment. (Note that I'm > attempting to illustrate the scope of such activities, rather > than enter in > to a discussion of the metirs or otherwise of such examples) > > The observation is that there is no clear way in the current > IETF / IANA / > RIR environment for this latter type of experiment to be > undertaken. It is > my understanding of the worrent working relationships between > these bodes > that the IETF cannot undertake temporary address alssignments > to end users > for such experiments, and that the IANA undertakes address > allocations to > RIRs, so that the IANA is in no position to undertake this > role either. And > right now there is no RIR policy to undertake such > assignments outside of > the conventional policies. This policy is intended to allow > the RIRs, and > in this case ARIN in particular, to undertake such temporary address > assignments. > > The basic question here is of course is "what is an > experiment in this > context"? > > Obviously this is a difficult question to rigidly define in > advance, so the > proposal attempts instead to document how an experiment that proposes > temporary use of Internet number resources should be > described. The lowest > common denominator is that the use of such resources should > be justified in > a public experiment proposal. > > Over and above this lowest common denominator there is a > stated preference > for documented experiments that exhibit some background of technical > coordination - obviously there is some reticence by all of us > to support > experiments that may have some negative impact on the > operation of the > Internet. The policy proposal points to the IETF as a > preferred venue for > such technical coordination and uses a reference to > experimental RFCs as a > demonstration of an experiment proposal that has been subject to some > review within the IETF that would include consideration of technical > coordination. > > Comments I have received on this preference have included > observations of > the extended time for an experiment proposal to be published > by the IETF as > an experimental RFC, and one concrete proposal to address > this was to use > the wording of a document that has achieved "IETF consensus" > where this > consensus is described in RFC 2434. This would allow Internet > drafts to be > referenced, under the specific circumstances where the draft > has achieved > this consensus. Of course this poses the issue of how the > RIRs could, as an > external body, clearly identify the difference between a > draft that has > achieved this consensus and one that has not. One proposed > refinement of > this is to allow the RIRs to refer such experiment proposals > to some form > of liaison with the IETF. > > Another comment I've received is that there is an Internet > Research Task > Force and it too may have a motivation to propose such an > experiment. It is > not clear that an IRTF proposal along these lines should also need to > obtain IESG approval via this proposed RFC 2434 IETF consensus. > > I have also revieved various comments along the lines that "all such > proposed experiments should be described in such a RFC 2434 > IETF consensus > document" and other comments that "this is desireable but > should not be a > mandatory constraint". > > From all these discussions I've noted that there appears to a rough > consensus that some form of technical coordination is prudent and > responsible for such experiment proposals, bit some variation > on how this > technical coordination should be undertaken. > > I would suggest that Ted's suggestion of using the ARIN > Advicory Council as > a "designated expert reviewer" is a way forward, and if you > combine this > with the option for the designated expert reviewer to utilize > a liaison > mechanism with the IETF to obtain specific advice on matters > of technical > coordination then this could address many of the > uncertainties that have > been voiced about this proposal (obviously some of the > comments have been > direct opposites and I'm not claiming that this is a full > synthesis of all > comments). > > So in that vein I would like to propose, as an individual > contribution to > this ARIN consideration of this proposed policy, a re-wording > of the policy > proposal - it attempts to rephrase the first three sections > to make them > clearer, > as well as taking into account the considerations noted in > text above, and > includes the designated expert reviewer role. It also > specifically words > this as an ARIN policy, as I understand that the other RIRs > have / are > considering different wording in their regions. > > kind regards, > > Geoff > > ================================================ > > > 2002-2: Experimental Internet Resource Allocations > > There have been a number of experimental address allocations > undertaken in the Internet over the past decade. These experimental > address allocations have been made by the IANA in coordination with > the IETF, on an ad hoc basis. There is currently no systematic means > of receiving other Numbering Resources on a temporary basis as part of > a recognized experiment in Internet technology deployment. The > following policy is proposed: > > ARIN will allocate Numbering Resources to entities requiring temporary > Numbering Resources for a fixed period of time under the terms of > recognized experimental activity. > > The following criteria for this policy are proposed: > > 1. Documentation of recognized experimental activity > > A Recognized Experimental Activity is one where the experiment's > objectives and practices are described in a publicly accessible > document. It is a normal requirement that a Recognized Experimantal > Activity also includes the undertaking that the experiment's outcomes > also be published in a publically accessible document. > > A "publically accessible document" is a document that is publicly > and openly available free of charges and free of any constraints > of disclosure. > > ARIN will not recognize an experimental activity under this policy if > the entire research experiment cannot be publicly disclosed. > > ARIN has a strong preference for the recognition of experimental > activity documentation in the form of a document which has achieved > "IETF consensus" as described in RFC 2434. > > 2. Technical Coordination > > ARIN requires that a recognized experimental activity is able to > demonstrate that the activity is technically coordinated. > > Technical coordination specifically includes consideration of any > potential negative impact of the propsed experiment on the > operation of the Internet and its deployed services, and > consideration of any related experimental activity. > > ARIN will use a designated expert reviewer to review experimental > activities to ensure that the activity is technically coordinated. The > reviewer may liaise with the IETF to complete this review. > > > 3. Coordination over Resource Use > > When the IETF's standards development process proposes a change in the > use of Numbering Resources on an experimental basis the IETF should > use a liaison mechanism with the Regional Internet Registries (RIRs) > of this proposal. The RIRs will jointly or severally respond to the > IETF using the same liaison mechanism. > > > 4. Resource Allocation Term and Renewal > > The Numbering Resources are allocated on a lease/license basis for a > period of one year. The allocation can be renewed on application to > ARIN providing information as per Detail One. The identity and details > of the applicant and the allocated Numbering Resources will be > published under the conditions of ARIN's normal publication policy. > > 5. Single Resource Allocation per Experiment > > ARIN will make one-off allocations only, on an annual basis to any > applicant. Additional allocations to an organization already holding > experimental activity resources relating to the specified activity > outside the annual cycle will not be made unless justified by a > subsequent complete application. > > It's important for the requesting organization to ensure > they have > sufficient resources requested as part of their initial > application for the proposed experimental use. > > 6. Resource Allocation Fees > > ARIN may charge an administration fee to cover each allocation made of > these experimental resources. This fee simply covers registration and > maintenance, rather than the full allocation process for standard ARIN > members. This administration fee should be as low as possible as these > requests do not have to undergo the same evaluation process as those > requested in the normal policy environment. > > 7. Resource Allocation Size > > The Numbering Resources requested come from the global Internet > Resource space, and are not from private or other non-routable > Internet Resource space. The allocation size should be consistent with > the existing ARIN minimum allocation sizes, unless small > allocations are intended to be explicitly part of the experiment. If > an organization requires more resource than stipulated by the minimum > allocation sizes in force at the time of their request, their > experimental documentation should have clearly described and justified > why this is required. > > 8. Commercial Use Prohibited > > If there is any evidence that the temporary resource is being used for > commercial purposes, or is being used for any activities not > documented in the original experiment description provided to ARIN, > ARIN reserves the right to immediately withdraw the resource and > reassign it to the free pool. > > 9. Resource Request Appeal or Arbitration > > ARIN reserves the ability to assess and comment on the objectives of > the experiment with regard to the requested amount of Numbering > Resources and its technical coordination. ARIN reserves the ability to > modify the requested allocation as appropriate, and in agreement with > the proposer. In the event that the proposed modifications are not > acceptable, the requesting organization may request an appeal or > arbitration using the normal ARIN procedures. In this case, the > original proposer of the experimental activity may be requested to > provide additional information regarding the experiment, its > objectives and the manner of technical coordination, to assist in the > resolution of the appeal. > > ================================================ > > From gih at telstra.net Thu Dec 12 10:03:29 2002 From: gih at telstra.net (Geoff Huston) Date: Fri, 13 Dec 2002 02:03:29 +1100 Subject: [ppml] 2002-02 Address space allocations for experimental pur poses In-Reply-To: Message-ID: <5.1.0.14.2.20021213014037.01978380@localhost> At 08:41 AM 12/12/2002 -0600, Bill Darte wrote: [ see previous msgs for text and Bill's proposed rewrite] >This removes the connotation that 'an expert' will be involved rather than >what is more likely a committee of review. >It also states what is implicit.... that the coordination review will take >place prior to the experimental allocation. The first part I have no particular issue with. I was attempting to fold in Ted Hardie's words without explicitly referencing the AC as the reviewer (policy vs practice). Your words arevpretty much equivalent in terms of policy as far as I see it. I sawva 'reviewer" in the policy as equating to the ARIN AC in terms of practice. i.e. a "reviewer" can just as easily be a committee or an individual. Its a role description not an entity identification. So either wording is fine. The second part (prior to allocation) is implicit in what I wrote. I was describing what is a 'recognized experimental activity' which is a precursor to an allocation in respect of that activity. Your wording makes this explicit and again I've no problem with this, but they are pretty much equivalent in terms of policy. >If a continuous liaison with IETF is needed to ensure continuing technical >coordination is supported, then the last sentence could read..... >This review will be conducted with ARIN and/or third-party expertise and >will include continuous liaison with the IETF throughout the experiment. I was careful to allow IETF liaison to be at the discretion of ARIN rather than a mandatory. Its up to ARIN to figure out if the "may" becomes a "will". I also think that 'continuous' is perhaps unwarranted in terms of ARIN's role. If the experimenters want to undertake some collaborative activity with the IETF that's their choice - I do not think its a reasonable policy imposition on the experimenter nor on ARIN to oversee. >If this helps, I'm gratified. If not, well.... it was only a tweak anyway. I see all but the last issue as neutral. The last issue is a substantive point and probably requires further thought within this forum. regards, Geoff From billd at cait.wustl.edu Thu Dec 12 10:29:44 2002 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 12 Dec 2002 09:29:44 -0600 Subject: [ppml] 2002-02 Address space allocations for experimental pur poses Message-ID: Agreed on all points you make below.... I chose the word 'will' as opposed to 'may' liaise with IETF because it would seem prudent to 'at least touch base'. The term 'may' just seems too weak and 'will' too strong and 'likely' too indecisive. I'd prefer to obligate a 'coordination' of a scope that of course could range from minimal on up........ Just my personal opinion on this issue. Bill Darte > -----Original Message----- > From: Geoff Huston [mailto:gih at telstra.net] > Sent: Thursday, December 12, 2002 9:03 AM > To: Bill Darte; ppml at arin.net > Subject: RE: [ppml] 2002-02 Address space allocations for experimental > pur poses > > > At 08:41 AM 12/12/2002 -0600, Bill Darte wrote: > [ see previous msgs for text and Bill's proposed rewrite] > > >This removes the connotation that 'an expert' will be > involved rather than > >what is more likely a committee of review. > >It also states what is implicit.... that the coordination > review will take > >place prior to the experimental allocation. > > > The first part I have no particular issue with. I was > attempting to fold > in Ted Hardie's words without explicitly referencing the AC as the > reviewer (policy vs practice). > > Your words arevpretty much equivalent in terms of policy as > far as I see it. > > I sawva 'reviewer" in the policy as equating to the ARIN AC > in terms of > practice. i.e. a "reviewer" can just as easily be a committee or > an individual. Its a role description not an entity identification. > So either wording is fine. > > The second part (prior to allocation) is implicit in what I wrote. > I was describing what is a 'recognized experimental activity' > which is a precursor to an allocation in respect of that activity. > > Your wording makes this explicit and again I've no problem > with this, but they are pretty much equivalent in terms of policy. > > > >If a continuous liaison with IETF is needed to ensure > continuing technical > >coordination is supported, then the last sentence could read..... > >This review will be conducted with ARIN and/or third-party > expertise and > >will include continuous liaison with the IETF throughout the > experiment. > > > I was careful to allow IETF liaison to be at the discretion > of ARIN rather > than a mandatory. Its up to ARIN to figure out if the "may" > becomes a "will". > > I also think that 'continuous' is perhaps unwarranted in > terms of ARIN's > role. If the experimenters want to undertake some > collaborative activity > with the IETF that's their choice - I do not think its a reasonable > policy imposition on the experimenter nor on ARIN to oversee. > > >If this helps, I'm gratified. If not, well.... it was only a > tweak anyway. > > I see all but the last issue as neutral. > > The last issue is a substantive point and probably requires > further thought > within this forum. > > regards, > > Geoff > From jrace at attglobal.net Thu Dec 12 22:16:40 2002 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Fri, 13 Dec 2002 10:16:40 +0700 Subject: [ppml] Question? Message-ID: <200212130316.gBD3GrYm020322@smtp1.arin.net> On Mon, 2 Dec 2002 14:20:03 -0600, Mark McFadden wrote: >Is RFC 2505 insufficient, or perhaps not comprehensive enough? >>There's also been other work done: http://www.ripe.net/ripe/docs/spam.html Both documents are insufficient. They have succeeded in localizing the problem to a few big offenders and a lot of little ones, but they have failed in their objective of reducing the burden of UBE and other threats like worms, viruses and Trojans. The reasons for this are easy to understand I will have something for this group to munch on shortly, explaining why these documents have failed and offering a solution. Jeffrey Race From memsvcs at arin.net Tue Dec 17 10:38:39 2002 From: memsvcs at arin.net (Member Services) Date: Tue, 17 Dec 2002 10:38:39 -0500 (EST) Subject: [ppml] Call for Meeting Sponsors Message-ID: ARIN is issuing a Call for Sponsors for the ARIN XI Public Policy and Members meeting to be held April 6-9, 2003 in Memphis, Tennessee. As a nonprofit association ARIN appreciates all types of meeting support. Technical expertise and manpower to build the hotel meeting network and financial support to cover a myriad of costs is sought. We welcome an exclusive sponsor or partial sponsorships. Please visit the updated meeting sponsorship page for full details: http://www.arin.net/membership/sponsor.html Sponsors for the network activities must confirm their commitment no later than January 30. Questions may be sent to memsvcs at arin.net or call ARIN Event Coordinator Bernadette Mimna at 703-227-9878. We look forward to working with you to make ARIN XI a successful meeting. Member Services American Registry for Internet Numbers