On Thu, 6 Dec 2012, Jeroen van der Ham wrote:
It seems that in the current document we have sections on the MDL and MTL. The MTL is deemed to be out of scope, and it is recommended to be "TCP/IP-HTTP-XML (such as SOAP)". Which I would scrap, and just put in SOAP, since NSI does not support any other TCP/IP-HTTP-XML stack.
Given that TCP, HTTP and SOAP already provide more than enough delivery assurance, I have to wonder why we actually need that extra conceptual layer in the Message Delivery Layer. It already is basically outsourced to those layers anyway. And for the few cases where upper layer logic is required to make sure that a request is handled correctly, we turn to the State Machine in the form of acknowledgements.
I agree with what is being said here. Wrt. to the MDL (and this is to Guys response as well), I'm fairly sure it was a conceptual thing to help explaining how an aggregator would work. It cannot be implemented in the simplistic way the slides presents it (an isoloated layer) as one needs to keep track of the states of the subconnections and in a persistent ways if one wants a sensible working system. There is something that reminds of the the MDL in the OpenNSA aggregator, but there are a lot of details to it. Of course the MDL is described in a very generic way open to a lot of interpretation, but I'm not sure that improves the situation. (sorry of this section is a bit hard to understand).
I know that the State Machine is currently still being improved. But did we also take the suggestion to make all short exchanges synchronous, and to allow optional acknowledgement for longer asynchronous exchanges? This would make it much simpler to use NSI in cases with limited connectivity (firewalls/clients/NAT etc.)
Sync/Async doesn't really chage the state machine as I see it. I could be wrong though. I'd like more synchronous messages, but given the way things are wired together, it is difficult to do. I've argued for a generic state change request (replacing provision, release and terminate), along with a publish-subscribe mechanism earlier. This would also allow third party requests for connection updates, where they are currently forced to do a query. However we also have a lot of people asking/waiting for a stable version of NSI to implement, as it is currently very much a moving target. I don't think these changes are particularly complex, but IMHO the group has not been very open to changes in the protocol core mechanisms. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet