[121582] in North American Network Operators' Group
Re: 1/8 and 27/8 allocated to APNIC
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Jan 22 13:27:56 2010
Date: Fri, 22 Jan 2010 10:27:25 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: "nanog@nanog.org" <nanog@nanog.org>
Mail-Followup-To: "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Jan 22, 2010 at 12:32:30PM -0400, Brian Dickso=
n wrote:
> So, if the tainted *portions* of problem /8's are set aside, you end up w=
ith sets of varying
> sizes of /N. E.g. if there is one /24 that is a problem, you set that asi=
de, and end up with
> a set that consists of one each of /9 through /24. Even if you set aside =
a /16, you get a set
> which is /9, /10, /11, /12, /13, /14, /15, and /16.
If the tainted portions were going to be set aside, it makes much
more sense to me that they be set aside at the RIR level and simply
not be counted against the RIR when they go back to IANA for more.
It makes the bookkeeping much simpler. When you go to IANA's web
site 1/8 went to an RIR. You can look there to find the few /24's
that couldn't be given out. The alternative is to blow up the IANA
allocation list by several orders of magnitude, for no good reason.
Really though, we need the squatters to feel pain. They are the
ones in the wrong. Unfortunately who ever receives the allocations
will also feel pain.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBS1nuDbN3O8aJIdTMAQIgwA/+NlKxZ0kzr+f0j5FfdrqkhgAoUaMp+fVu
dfssE/fdeGxfOubHjvc514dPo44/nOC/AJm2ZagNtcnWXQQOrMCmdhLQe8btBhns
UN7ThKaYhF4pkN6RcL/+h+EavN7/GXwYan61ui+4esfdELuzjc9oMupkiGBYPScj
I5vNrimcrzKnwS1JXjfqfnvktPT0IY6BQWgvK69Sv8iS061vc/mw6IpFWvecFj8I
w+Fhy8wnu6CBjmpXOpQ9Q/ufwM/Zxq2Ch8hzmbIiQ3P8NTRDK6RsMG0AU8U3TGCM
xIYVen/UK9M7GDGSCR28nplGuOq/TSKMEoT+u8vJmmBHwRN6JpYJitfbZoRQGer9
uuWMU4BFu82lOay0L55k1dqBBJ4jJfIS9cYPE/++pHwVjo0CQ04BrNIj9WlV3IQG
vG99M1w9KNS84hPatqTFetWruvGFhfyzWSVrsZXiYKZWv92HNgGedD0MMiLTmsZE
4OJo61ybdIwUo0X63b1BD46otR/td/tiYDaoR2qlkUXvf2ZkU+PGGU7I/HBxtVgq
Vid+36miclxHuKdPcr9ijDlQi7AZcOwOt4E+5g6bTsB99Rtof/4uc8plHDw7xJG6
i6nFUzopCXuCbfnY495PTz3a47NOraDQ41VvNBz4P9wogP6ORs+HbKlWYsKipTxQ
mOEin00M3dg=
=Ykmk
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
