In a message written on Mon, Mar 17, 2003 at 07:01:32AM -0800, [EMAIL PROTECTED] wrote: > Simply having someonechange a DB entry or create an RFC will > not affect the installed silicon base. Won't work. > APNIC is on the moral highground here. They received damaged > goods without notification. IANA needs better technical clue.
s/silicon/filter/ s/APNIC/Joe ISP/ s/IANA/ARIN/ Note, I don't think either case represents "damaged goods", so I'm not supportive of either effort. That said, look at the fixes: Case 1: IANA properly updates RFC's to indiate that 223.255.255.0/24 is not allocatable, and makes APNIC's allocation properly 223/8 minus 223.255.255.0/24. Case 2: ISP's all across the US must handle user complaints, probe, test and then e-mail, call, and plead with hundreds, or even thousands of people to fix their broken filters I don't see any case where an ISP was in danger of receiving IP's that "didn't work" from 223/8, unless of course APNIC was actually thinking about giving out 223.255.255.0/24. That said, it can be demonstrated that the IP's given out in in 69/8 don't work for a measurable percentage of the Internet. My only claim is that if one questionable /24 our of a /8 means the entire /8 can be returned then clearly someone who receives a block out of 69/8 should be able to return their space as well because their entire block is impared. APNIC has a legitimate complaint, and it needs to be solved. That said it's a very minor complaint, and returning the allocation is simply grandstanding on their part, and is going to give fuel to all the people in other blocks who have what are generally much more serious operational problems. Maybe it would be better for APNIC to give up 223/8 for 70/8, since I suspect 70/8 will have the same filtering problems as 69/8. If they want to make life worse for their users, more power to them. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp00000.pgp
Description: PGP signature