Hi, It was still on my list to investigate the need for a separate User API that is firewall and NAT save. Over the last couple of months I realized that the only real way of solving this is to make the whole NSI synchronous instead of asynchronous. I do think that it is possible to make everything synchronous but there are also a couple of very good reasons to leave it asynchronous. (please note that I do not want to provoke any kind of discussion here, or at least not now) I think that we can get away by leaving the protocol as is. If users can not or do not want to receive the asynchronous messages then that is fine, the aim is to have enough resources available so hardly any request for bandwidth will be turned down anyway. If it is important to the user to know the status of his request, or he is just curious, he can use the a NSI query request to find out the actual state of his request. There is only one but here, this means that the query request must be synchronous! As an extra measure we are implementing the possibility to have status changes sent to the user by email. This is in no way meant as an replacement for the asynchronous messages, and of course only works if the request was made by one of our own users because otherwise we do not have an email address we can use. Almost all users have indicated that they trust us to provide them with the bandwidth when they need it, they only really want to be notified one way or the other when things go wrong. To most email is a very acceptable way of doing so. HansT. On 1/9/13 10:21 AM, Henrik Thostrup Jensen wrote:
On Tue, 8 Jan 2013, John MacAuley wrote:
Thought I might bump this back up since we never closed on the idea of a synchronous response for the query summary operation.
I actually wondered about this sometime. I'm still for it. It makes us marginally more firewall friendly, but in an important way.
Would it be a good idea have two seperate requests for this instead of the one? Possibly calling one query, and the other queryRecursive or similar. The current names are somewhat misleading.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg