RE: Operational Issues with 69.0.0.0/8...
This will never work - because it all makes way too much sense... -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, December 06, 2002 5:18 PM To: 'Adam Tauvix Debus'; nanog@merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... In a message written on Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote:
ARIN announced the fact that it received the 69/8 delegation on August 8th. ARIN received the delegation on August 6th. ARIN made its first allocation/assignment (I don't know which it was, but that isn't important) out of that block on September 19th. [snip] Do people have any suggestions for ARIN (and other RIRs) on how they can better dissemenate this information so that people will update their filters?
* One month from filtered to first use is too short. Should be 6 months, with multiple notices. To back this up I can point to a number of places that stopped all global changes from before thanksgiving to after christmas. (Not that I support such things.) * Mailing nanog is nice, but ARIN probably should mail all the ARIN members, or particularly people with ASN's. Far too many people view the nanog mailing list as entertainment, rather than operational necessity. * Space that goes from "reserved" to "in use" should be test routed first. Perhaps more of a job for ISI before they turn it over than ARIN. This allows people to make sure their changes actually worked. * Maintain an RADB object of reserved space, so those with automated tools can easily query it. * Perhaps offer a BGP feed (multi-hop, a-la RBL) of reserved space to ARIN members. If I were in charge it would be: 1) Notify all ARIN members 6 months in advance of the block being used. At the same time, announce the block from somewhere so people can check that they do in fact hear it as they open up their filters. 2) Notify people 3 months, 1 month, and 1 week before making the first allocation. 3) Drop the supernet test on the same day of the first allocation. 4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. I disagree with this part of your suggestion. Delaying new allocations will only serve to delay acceptance of new spaces. If you implement all
On Sat, 2002-12-07 at 08:56, Todd A. Blank wrote: the other safeguards you have suggested, the multitude of notices should ensure that clued, well-informed, responsible networks have ample time to make adjustments in their networks. Networks not among those will most likely not respond until their downstream customers complain, and the best way to get those complaints started is to get more folks into those new networks. I suggest moving all of the GTLD name servers into newly allocated blocks as they become available. This will certainly break networks which are low on operational clue, and force them to get fixed. -- Jeff S Wheeler <jsw@five-elements.com> 502-523-6989
JSW> Date: 07 Dec 2002 14:16:46 -0500 JSW> From: Jeff S Wheeler JSW> I suggest moving all of the GTLD name servers into newly JSW> allocated blocks as they become available. This will JSW> certainly break networks which are low on operational clue, JSW> and force them to get fixed. Let the GTLD nameservers end in .0 and .255 while we're at it. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (3)
-
E.B. Dreger
-
Jeff S Wheeler
-
Todd A. Blank