There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a particular prefix is? This type of filtering only works if the filter list is relatively short and pretty much never changes. Anything else and the cure is worse than the disease.
I would applaud a generic /32 that is 'allowed' to being cut up into multiple /48's for the purpose of critical infrastructure. But please, keep it to 1 *documented* /32. That way people will know that they will see more specifics from that prefix and that they should be accepting it too.
I'm not sure if it needs to be a /32 or if it needs to be just a single one, but I fully agree this should be documented very well and in a central place. Buried somewhere on a RIR website isn't good enough. (Try finding the the micro allocation list on the ARIN site without help from Google.)
I think this means it must be an RFC. RIR documents just don't have the same standing in the community, and, apparently, quality control.
Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32)
are seen being announced in pieces too. Maybe these IX blocks, which
are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet tickles an undesirable BGP feature in places where the prefix isn't filtered, so these prefixes are best not announced. The allocations seem to be /48s and not /64s though, so in practice this shouldn't be a problem but still no reason why these should be globally visible.
Root nameservers are a very different story of course...