[arin-ppml] ULA-C

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> Therefore, I believe the concerns about ULA-C becoming a path
    David> for policy abuse cannot be completely discounted.  However,
    David> in reality the risk is no where near as large as some are
    David> claiming.  Further, I believe this risk can be easily managed
    David> via the RIRs' number resource policy processes, if the RIRs
    David> were to be given full policy control of ULA-C registrations.

    mcr> I agree --- there could be abuse.
    mcr> Rather than overconstrain ourselves in advance, is there
    mcr> nothing we can do on a complaint basis?

    David> Where do those complaints go? How do we resolve disputes? For
    David> PA and PI essentially that is dealt within the policy
    David> development processes for the RIRs. That is how we hash
    David> things out as a community, it seems logical to use the same
    David> processes for ULA-C. 

Let's say that I start announcing 134.84.123.0/24 from my ASN.
What would you do?  Who would you complain to?

(yes, RPKI is a tool to prevent that, as is the RPDB, assume it happens)

But, assuming it gets through, how is that different than announcing
IANA's FC00::/7 on the public Internet?

What I'm asking is: why do we have to think through all possible actions
in advance, and write intricate policies... why do we have no mechanisms
to permit judgement?  There is a pathology where organizations try to
write policies for everything, as opposed to routine things+clear
exceptions, only I don't know what the word is.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS8PCEYCLcPvd0N1lAQIxEwf/egQXX+DlSIA70YyuG+gTg7OL8eF8ya/f
y9PJj085yuwL9jSyfglDJxdDIKAXDz5Nmq/8qIcNW8Xqy++Kkn4BSlOk0+BGmGfs
IYX6RoZB6X0E6b5Baf0zwQ43zBmKoDy0W4aBnFBx4rTr4HTyt8aaoYspgFFr1Nuj
RQCBBqdeRb+V3Oa+tZFTRk9eh+gmrKKjzaVmweCm9HzVOgYUZOCVjAv2vMr00uk8
INLtf045IQKOqmkG1LWoCfibkpprgVTga2HC06Mfh617/ptc4blmkSnl+ibaJ8gT
sQP6PjDgtGICGW2lrTDOJWXOGEih6AI/SlAzbCLdHXIoYR8GeMcFGw==
=s/MA
-----END PGP SIGNATURE-----