[Nsi-wg] Feedback for WS protocol

[Henrik Thostrup Jensen]

Hi again

After sending the email I started working with the new wsdl files and some 
of the issues appears to have solved/changed. I also found another issue, 
but I'll reply in the other thread with that.

On Wed, 13 Jul 2011, Guy Roberts wrote:

> Hello Henrik,
>
> Welcome to the NSI discussions, here are some thoughts on your feedback:
>
> 1. the four messages described are not as illogical as they first appear.  Please be aware that there can be a long delay between a reserveRequest and reserveConfirmed/failed  so a quick acknowledgment of the receipt of the reserveRequest is useful.

Exactly how is it useful? The requester still doesn't know of the 
reservation has been created or not. It does not provide any useful info 
AFAICT.

> 2. In general I agree that the pathObject does not fit well with the serviceParameters
>
> 3. I will check and make sure these are made consistent

I think they match in the new wsdl/xsd.

> 4&5. I have not strong feeling on this point - others may like to comment.

I'd like to see 4, but 5 is not particuarly important.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at ndgf.org>
  NORDUnet / Nordic Data Grid Facility.


> -----Original Message-----
> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Henrik Thostrup Jensen
> Sent: 13 July 2011 12:17
> To: NSI Working Group
> Subject: [Nsi-wg] Feedback for WS protocol
>
> Hi everyone
>
> (I'm the NORDUnet developer creating the OpenNSA NSI implementation).
> (Also, please ignore a potential double post due to wrong sender email)
>
> I have some feedback/changes/wishes/questions for the WS-rendering of the
> NSI protocol.
>
> 1. Odd request/reply structure.
>
> The request/reply structure is somewhat odd. It seems that for every
> request there is an message to imply that the message itself has been
> received as well as the actual response, which also has a response. I.e.,
> the interaction will look like this for a reservation (AFAICT)
>
> A -> B: reserveRequest
> A <- B: reserveResponse
> A <- B: reserveConfirmed
> A -> B: reserveConfirmedResponse
>
> This means that 4 messages are exchanged, when 2 would be enough. This is
> silly in my opinon, and only adds complexity to the implementation without
> adding any value. Also, at some point in time the reserveResponse and
> reserveConfirmed will get reordered as they don't have any ordering
> between them, meaning the requester will have to understand that case. It
> also seems to against the spec, which defines the primitives
> reserveRequest, reserveConfirmed, and reserveFailed.
>
>
> 2. Moving pathObject out of ServiceParameters
>
> I would very much like to move pathObject out of serviceParameters and
> into the top-level attributes. As a reservation is created the pathObject
> send around changes, where as the rest of the ServiceParameters does not.
> This also reflects itself in data structures where this becomes somewhat
> backwards to keep track of the path in aggregate connections. It is of
> course completely possible to keep the current structure, but it would
> simplify the implementation to move the path out of the service
> parameters.
>
> Also: Rename pathObject to path everywhere. We do not put the object
> suffix on other things either.
>
> Also(2): Rename OrderedStpListType to StpListType in spec. and protocol. A
> list is by definition ordered, otherwise it would be called a multiset or
> bag.
>
>
> 3. Protocol service parameters differ spec service parameters
>
> In the spec. schedule is in service parameters, in the WS protocol it is
> in the ReservationRequestType. I don't have any strong opions on where it
> should be, but I think it should be consistent.
>
> Somewhat similarly the spec. has guarenteed and preferred under
> serviceAttrs (which is under ServiceParameters). In the WS protocol
> guaranteed and preferred are directly under ServiceParameters. Again I
> don't have any strong opions on what is correct, but I think it should be
> consistent.
>
>
> 4. The transactionId
>
> The transactionId is not mentioned in the spec., but is used to denote
> session due to SOAPs lack of it. Could we call it something less
> misleading? It has nothing to do with transactions. E.g., sessionId,
> requestId (i prefer the latter as a session could technically consist of
> several requests).
>
>
> 5. Inconsistent path description
>
> The spec. introduces the notion of a service demarcation point as a pair
> of connected STPs. Could we introduce this type (essentially a
> tuple/struct/complextype with two STPs), and use it for describing paths,
> such that a path is a (sourceSTP, destSTP, SDPList).
>
>
>     Best regards, Henrik
>
>  Henrik Thostrup Jensen <htj at ndgf.org>
>  NORDUnet / Nordic Data Grid Facility.
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>