On Thu, 23 Aug 2012, John MacAuley wrote:
Wiki UUID. Is discusses the algorithm's ability to generate uniqueness.
But, there is a perfectly good RFC that I've already read :-).
Chances of a clash are worse than being hit by a meteorite.
Did you read the note about trying to consider it as a format :-).
Of course, someone with malicious intent could continue to send the same identifier over and over again, but you should be checking if it already exists anyways. Today I will reject a reservation request with and identifier already in use. I guess the question then is, do we feel that letting someone know a connection ID already exists is a security breach?
Right. And you actually have to perform this check for requests than cannot be fulfilled due to other matters (well you can try and guest the least cpu intensive check order). Having the provider assign the connection id also means that only connections which are created actually get one. Thought I'm not sure we have actually discussed if an NSA should keep information about failed reservation requests. Anyway, we are three in favor with B. Can we do this? It would mean removing the connection id from the reservation request, and a slight behavioural change. Should be easy, though you may get into some schema juggling with the wsdl. Since it is the provider assigning the connection ids, we could also go away with the uuid requirement (though implementations are perfectly free to use it). Of course, we could also make a huge slide set, and spend several hours discussing it on the phone :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet