Comment #5 on issue 9 by tkudoh...@gmail.com: The current statemachine does not confirm provisioning until start-time http://code.google.com/p/ogf-nsi-project/issues/detail?id=9 Making prov.cf/fl to be immediately returned after prov.rq for auto provsion case is not simple. One of the advantage of current state machine is its ability to handle skew of message delivery. That is, if a prov.cf is issued by an ultimate requester just before the start time, some of the children may receive a prov.rq after the start time because of the delay of message delivery. In such a case, some of the children may go through the path of auto-provision and some may go through that of manual. This is ok in the current state machine, since all the children will transit to provisioning state after a transient period, and there are no difference in message exchange sequences. I believe this advantage should be kept in the new state machine. If cf/fl is immediately sent back after a request is made for auto-provision cases, that cf/fl is not for actual provisioning but just confirms receipt of the message. That means, we will need another cf/fl to confirm actual provisioning. Since no request for provisioing is made at the start time in the auto-start mode, that cf/fl will be sent from a provider to a requester without preceeding request message. This will break message symmetricity. In addition, to keep the above advantage, both message cf/fl and provision cf/fl should be sent from a provider even in a manual provisioning case. This is not beautiful. Also, it is not clear what a requester should do if it receives a fail message for provision request for auto-provision case. That means, some of the children refuses receiving a message. I think we need to discuss pros and cons of possble design changes at a f2f meeting. So I propose to leave this for version 2.0. This relates to issue #53 and #54.