Re: [XCON] CPCP Requirement: Repeat times

[Paul Kyzivat <pkyzivat@cisco.com>]

Even, Roni wrote:
> Paul,
> The question is what is the usage for those parameters. A conference has a
> duration. If you want time for reservation what I claim that this is not
> enough. The issue of repeat times was mentioned.
That seems like just another representation for multiple start/stop times.

> What about address books so
> when reserving a conference you can select the participants.
What about them? That seems entirely irrelevant to this discussion. If 
you have address books, then use them with some tool that creates your 
conference policy before submitting it via CPCP.

> What is the
> semantics of the time, will the server let you know if the reservation  is
> OK when you reserve, will it let you know what are the resource availability
> be time in the response.
It seems logical to me that the policy server should refuse to accept 
the policy if some attribute in it is unacceptable. A situation where 
the resources aren't available at the specified times seems to fall into 
that category.

If you want a tool that can help you select a time when the resources 
are available, that is a different story. I think it falls into the 
category of a tool for creating policy.

> What I am saying that just having these two
> parameter makes sense if you define what they are for, how you use them in
> CPCP , what will the conference server do with them and what are the
> response you can expect from the conference policy server. This needs to be
> defined in order to have consistency between different implementations of
> conference policy servers.
Well yes, clearly there is some amount of definition that is currently 
lacking. But it doesn't seem like so much.

> My video is that conference policy has nothing to do with reservation. BTW
> the 3GPP MRF is only doing ad-hoc and reservation is handled by an
> application server.
Just a different way to slice the pie.

In any case, there is probably a role for an application server that 
provides a UI for creating conference policy. I would expect such things 
to be layered on what is being defined here, and not to be standardized.

	Paul


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon