Jerry,

My comments in-line


I agree with your statements;
 User is not interested in partial results, as he/she is not even aware/interested in which NSAs/domains are involved. User doesn’t care (if everything works fine ;) ).

The protocol should be designed with the user in mind. The user does not care about guard time values, differences in setup times for MPLS vs optical lambdas, and concern itself with choices an NSA/NRM will make in path-finding. 

The protocol designers can keep the user in mind, but the protocol is between the RA and the PA and and has a specific purpose: to reserve and instantiate a connection across the globe.  We need to keep in mind that the RA is not always the end user - it is by definition another NSA and could be an NSA in the tree/chain somewhere.  If we want to differentiate between the user and the network, then we can create a simplified User to Network API, and a different Network to Network API...but I don't think thats what we want to do (:-)   We need to IMO *not* think about the user, but to think about the Requesting Agent - regardless of who it represents.

Of course, I understand the intermediate RA-PA interaction. The main purpose of highlighting the User here is to indicate the the Start Time and End Time comes from the originating RA and differentiate it from the intermediate RA's. 

While the guard times may be network specific, we do need to at least consider what we would like an NSA to do if for instance a provisioning guard time pushes a reservation forward into a previous reservation:   Do we  1) reject the request since we can't prepend our guard time and still make the Requested Start Time?   OR  2)  Do we retard the Estimated Start Time to allow for the guard time?   OR 3) do we reduce the guard time to fit the available lead time?

I think we now agree that the Start Time is just an estimate, due primarily to the guard time itself being just an estimate.  So none of these times are etched in stone...So which option do we recommend or require?   The protocol is sensitive to these various times - they cause timers to go off, messages to be sent, error handling to kick in...   If they are adjusted during scheduling or provisioning, we MUST understand what impact they will have to the protocol and how that will be carried through the service tree.

I propose #1. Anything else will fall under negotiation which we have punted.