Hi, Thanks for the preview of the standard document. This was helpful with implementing the aggregator. We've read through the NSI v2 0.9 and 0.10 draft documentations and have a few questions/comments: In section 8.9 Reservation Versioning Information: "Version numbers of failed (e.g. timed-out) or aborted modifications are not stored, and therefore can be reused …" Is this special case really needed? Why not always require monotonically increasing version numbers? In section 4 NSI State Machines, on the PSM: "An instance of the PSM is created when an initial reservation is committed, and at that time it remains in the Released state." but in section 17.1.1 Processing of NSI the pseudo-code for NSI_rsv.rq creates the RSM, PSM, and LSM immediately and doesn't mention the initial state. In section 18.1 Message transport error handling a few errors are predefined. However, there are two errors with ID SVC0012. We're also missing an error code for the aggregator when one or more child providers return an error. In this case the requester should look at the childExceptions element of the ServiceExceptionType to find the root error. For now we added our own custom error: ID: SVC???? description: CHILD_ERROR text: One or more children reported an error. See the child exceptions for details. Finally, there is not much mention of the interaction between the various state machines. Can a requester still send Provision/Release requests when the LSM is already terminated? Is there any guiding principle or documentation we've missed? Regards, Erik