On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
it should bepossible to incorporate RFC2777 verifiability to it.
There is no need for that, since your failure to use a good source of randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is generating ULAs for their customers. Maybe they'd like to be able to prove in case of dispute that other customer with memorable ULA was not favoured. Maybe someone claims I'm not using BCP methods for ULA selection, and I'd like to be able to falsify those claims. Obviously I could come up with some own RRFC2777 style algo to generate ULA, but if it would be internally documented it would hardly be provable, as I couldn't prove I haven't come up with the algo after generating the prefix. Maybe this is not practical enough concern, but I'm wondering, what is the downside? What is the benefit of recommending method which is not testable/provable. -- ++ytti