Hi Henrik- I want to point out the the "bandwdith" is actually a service specific parameter, where as the other two aspects (schedule and path) are generic and apply to the general semantic of a "connection" regardless of service definition. Different services may have different ways to define the connection capacity...bandwidth, timeslots, spectral width, etc. Even two similar services may define their service capacity differently - say an implicit constant bit rate, or a committed information rate with burst capabilities, etc. I suppose we could consider the "size of the pipe" as a generic characteristic - it has an applicable elegance to it, but we would then need to reconcile these different ways of defining the size that might vary by service specifics... So the group should just keep this in mind - we can define an expedient solution for v2 as you suggest (I think a 80% solution that moves v2 along is most important at the moment ), but we should revisit this issue in v3. Jerry On 6/18/13 8:06 AM, Henrik Thostrup Jensen wrote:
On Tue, 18 Jun 2013, Atsuko Takefusa wrote:
I think "path" in ReservationRequestCriteriaType is a mandatory parameter.
I agree. Further:
For ReservationRequestCriteriaType
I think schedule, bandwidth and path should be mandatory.
For ReservationConfirmCriteriaType
serviceAttributes should be optional.
In fact, except for the version attribute (which is optional in one, and mandatory in another), ReservationRequestCriteriaType and ReservationConfirmCriteriaType appear to be the same.
We could consider moving version out of these use a single type. Afterall, both describe a connection. Possibly use complexContent instead, but that actually leaves more types.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg