Since, I know you love these emails ReserveResponseType can deleted and GenericConfirmedType be used instead. ReserveConfirmedType has a ReservationInfoGroup in it. This type includes an awful lot of data which is included in the initial reservation, but doesn't actually change, such as globalReservationId, description, schedule, bandwidth, and some of the stuff in the path type. This is static information which the client just send, there is no need to include it. AFAICT the only thing that is really needed here is the connectionId, sourceSTP, destSTP, and probably the ero if it was specified in the request. I realize this means a new type, but it is a lot of junk to send back. And symmetric -> symmetricPath :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Agree with 1. I want to keep the ReserveConfirmedType consistent with the data returned in query. I also think some of the other parameters can change in a flexible implementation as well. Although not defined in our current spec I could allow for flexible time and bandwidth, which would then need those to be returned. John On 2013-05-22, at 11:39 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Since, I know you love these emails
ReserveResponseType can deleted and GenericConfirmedType be used instead.
ReserveConfirmedType has a ReservationInfoGroup in it. This type includes an awful lot of data which is included in the initial reservation, but doesn't actually change, such as globalReservationId, description, schedule, bandwidth, and some of the stuff in the path type. This is static information which the client just send, there is no need to include it.
AFAICT the only thing that is really needed here is the connectionId, sourceSTP, destSTP, and probably the ero if it was specified in the request. I realize this means a new type, but it is a lot of junk to send back.
And symmetric -> symmetricPath :-).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Actually, I am now questioning #1 based on semantic meaning of the message. It is not a confirmed message, but a response message. The "GenericConfirmedType" is for confirmations, while the "ReserveResponseType" is meant to return the newly allocated connectionId. Content wise they are the same, but from a documentation perspective they are different. Perhaps creating a new "GenericReturnType" for use in both situations? John On 2013-05-22, at 11:39 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Since, I know you love these emails
ReserveResponseType can deleted and GenericConfirmedType be used instead.
ReserveConfirmedType has a ReservationInfoGroup in it. This type includes an awful lot of data which is included in the initial reservation, but doesn't actually change, such as globalReservationId, description, schedule, bandwidth, and some of the stuff in the path type. This is static information which the client just send, there is no need to include it.
AFAICT the only thing that is really needed here is the connectionId, sourceSTP, destSTP, and probably the ero if it was specified in the request. I realize this means a new type, but it is a lot of junk to send back.
And symmetric -> symmetricPath :-).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On Wed, 22 May 2013, John MacAuley wrote:
Actually, I am now questioning #1 based on semantic meaning of the message. It is not a confirmed message, but a response message. The "GenericConfirmedType" is for confirmations, while the "ReserveResponseType" is meant to return the newly allocated connectionId. Content wise they are the same, but from a documentation perspective they are different. Perhaps creating a new "GenericReturnType" for use in both situations?
I see your point, and they are indeed semantically different. The connection id is in principle redundant in GenericConfirmedType, whereas it definitely needed for ReserveResponseType. However the stuff that goes over the wire is exactly the same. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen
-
John MacAuley