RE: [XCON] CPCP Requirement: Repeat times
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [XCON] CPCP Requirement: Repeat times



That's of course what I proposed, although I think stop time is pretty
useful
for most conferences even if it is only advisory.  I had additional options
(stop when convener leaves, for example).

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, February 09, 2004 9:34 AM
> To: hisham.khartabil@nokia.com; Michael P Hammer; Brian Rosen
> Cc: petri.koskelainen@nokia.com; drage@lucent.com; Keith A Lantz;
> XCON-IETF; dbieseli@cisco.com
> Subject: Re: [XCON] CPCP Requirement: Repeat times 
> 
> 
> 
> I think we would get further if we decided it was time to 
> stop calling it
> stop time and instead say there was an optional policy setting of
> 
> terminate conference at time X policy
> and/or
> terminate when all users leave yes/no policy
>  
> There are two disconnected things that are getting convolved 
> together in
> stop time. One is how long resource are reserved for 
> (whatever reservation
> means). The other is the policy around how the conference will end.
> 
> Cullen
> 
> On 2/9/04 2:45 AM, "hisham.khartabil@nokia.com" 
> <hisham.khartabil@nokia.com>
> wrote:
> 
> > Admittedly, the current solution specifies that a convener 
> needs to change the
> > stop time in order to terminate the conference, if he wants 
> the conference to
> > end as he leaves. I sense that people want the convener to 
> explicitly indicate
> > that instead of just modifying the stop-time. Am I correct? 
> I know Brian wants
> > it so.
> > 
> > I also would like to encourage people to read sections 12 
> and 18.3 of the
> > solution draft. Those sections discuss exactly what this 
> thread is all about.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xca
> p-cpcp-usage-02.
> > txt
> > 
> > Regards,
> > Hisham
> > 
> >> -----Original Message-----
> >> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On 
> Behalf Of ext
> >> Michael Hammer
> >> Sent: 06.February.2004 21:49
> >> To: Rosen, Brian
> >> Cc: Koskelainen Petri (Nokia-NRC/Tampere); fluffy@cisco.com; Rosen,
> >> Brian; drage@lucent.com; klantz@cisco.com; xcon@ietf.org;
> >> dbieseli@cisco.com
> >> Subject: RE: [XCON] CPCP Requirement: Repeat times
> >> 
> >> 
> >> Brian,
> >> 
> >> I may be a little confused by what is meant by policy and policy
> >> manipulation with respect to how that translates into 
> resources being
> >> invoked and released.  My vision (delusion) as to how that
> >> might work might
> >> have to wait to see the actual protocol develop.  But, I
> >> suspect that your
> >> answers to my comments below will help clear this up for me.
> >> 
> >> Mike
> >> 
> >> 
> >> At 01:33 PM 2/6/2004 -0500, Rosen, Brian wrote:
> >>>>> End when last person leaves is the way many bridges work.
> >>>> 
> >>>> Is that a technical justification?
> >>> Actually, I think it means there is a requirement for that
> >> to be possible.
> >> 
> >> Agree.  Don't see that as not possible.
> >> 
> >> 
> >>>> 
> >>>>> You might
> >>>>> not like it, but that's the way they work.  Most bridges don't
> >>>>> start if the convener is not there.  If he arrives, and
> >> then leaves,
> >>>>> the conference is over.
> >>>> 
> >>>> What is the meaning of conference policy then?  I thought
> >>>> that it was an
> >>>> authorization for something to take place.  If the conference
> >>>> is authorized
> >>>> to start and someone shows up, then it starts.  If it is
> >>>> authorized to
> >>>> stop, and the bridge resources are needed elsewhere, then
> >> it stops.
> >>> CPCP has two elements, and they each have a role in policy.
> >>> A particular implementation, or more properly, a particular
> >> administrative
> >>> action, may restrict the range of possible policy requests
> >> the convener
> >>> may ask for.   The bridge may not respond the way the
> >> convener would like
> >>> it to.  It must be possible for the bridge to have local
> >> policy, and yet
> >>> allow the convener to manipulate whatever freedoms the 
> local policy
> >>> permits.
> >> 
> >> I agree with this part.  The local "uber-policy" determines if the
> >> convener's policy request is accepted or rejected.
> >> 
> >> 
> >>> You could have the bridge change the start/stop time itself
> >> 
> >> I don't follow this part.  It seems to confuse the role of
> >> the bridge in 
> >> committing to the use of resources and the role of the convener in
> >> committing to pay for what he has asked for.  If it is the
> >> intent of the 
> >> requester to terminate the conference upon his leaving, then
> >> that should 
> >> be  an option of the request he makes to the bridge.
> >> 
> >> If he is requesting that the bridge terminate upon his
> >> departure, shouldn't
> >> that be an update to his policy?  Same for other options.
> >> The bridge of 
> >> course may have resource limitations, and thus there may be
> >> conditional 
> >> authorizations to what is requested.  Where I think I have
> >> some confusion 
> >> is that some of these options/authorizations are implicit not
> >> explicit.
> >> 
> >>> to implement
> >>> its local policy, but that makes the function even more twisted.
> >>> Better to have explicit mechanisms, and let the bridge
> >> implement, or permit
> >>> a subset of them if it wishes.
> >>> 
> >>>> 
> >>>>> It also doesn't work to manipulate stop time to end the
> >>>> conference because
> >>>>> its the bridge that wants to enforce its policy and not
> >> the convener.
> >>>> 
> >>>> Who is the authority here?  Isnt' the bridge-providing
> >>>> service supposed to
> >>>> obey policy?
> >>> As above, local policy must override.
> >> 
> >> I agree, in the sense that local policy drives convener
> >> policy that drives
> >> bridge resource provided/withheld.
> >> 
> >> 
> >>> ....snip...
> >>>> strategy, and an implementation detail.  It seems the
> >>>> confusion here stems
> >>>> from not separating:
> >>>> 
> >>>> Is a conference authorized at the moment,
> >>>> Is a bridge needed at the moment,
> >>>> and should a bridge be reserved at the moment.
> >>> I don't see it that way.  I see it as the bridge has local policy,
> >>> the convener wants to exert whatever freedom the local
> >> policy permits,
> >>> and the participants have to have some way to understand what is
> >>> going to happen.
> >> 
> >> But, isn't the time at which the local policy interacts with
> >> the convener 
> >> request independent of when a particular bridge resource gets
> >> assigned?  A 
> >> convener request could be accepted so long as there are
> >> enough resources
> >> available/reserved in the pool, whether or not a resource is
> >> actually put 
> >> to use.
> >> 
> >> 
> >>>> 
> >>>>> We have to be explicit.
> >>>> 
> >>>> Yes, particularly as to the semantics of policy.  What does
> >>>> start time
> >>>> mean?  What does stop time mean?  I keep seeing primary
> >>>> meanings tangled up
> >>>> with secondary and tertiary implementation implications.
> >>> I've proposed that start time is the earliest time at which
> >>> mixing starts.
> >> 
> >> I thought this was a policy?  This would mean that the start
> >> time would be 
> >> the earliest time at which mixing is permitted to start.  
> Isn't this
> >> independent of whether a resource was invoked?  Note, it may
> >> be reserved 
> >> un-occupied and billed for, but that may not be the most
> >> efficient use of
> >> resources.  (No statistical over-booking allowed.)
> >> 
> >> 
> >>> I've proposed that stop time is interpreted by the stop time
> >>> enumeration.  It could be a hard stop of mixing resources, or it
> >>> could be only advisory.
> >> 
> >> Could this not be defined as the latest time at which mixing
> >> is permitted 
> >> to be used, i.e. that the enumeration option is whether the
> >> stop time may 
> >> get updated explicitly by the convener or another party or
> >> implicitly by a 
> >> convener agent (could be the bridge)?
> >> 
> >> 
> >>>> 
> >>>>> As to Cullen's objection, what you are worried about is
> >> start time,
> >>>>> and not stop time.  By your definition, the conference
> >> never started.
> >>>>> If it did start, then it ends when whoever showed up leaves
> >>>> (if that's
> >>>>> what the conference policy was set to), or when the
> >> convener leaves,
> >>>>> which is surely the right thing.  I don't know how to fix
> >>>> your problem
> >>>>> actually.   Maybe some kind of action that resets start.
> >>>> 
> >>>> The bridge may need to be released and re-captured, but that
> >>>> does not mean
> >>>> the conference is re-started.
> >>> Possibly a minor semantic argument.  I think we both agree that
> >>> the scheduled conference did not take place.
> >> 
> >> Are we talking when a convener was authorized to invoke a 
> conference
> >> resource or accounting for when resources were actually used?
> >> I believe that some conference services still charge as the
> >> resources where 
> >> reserved and represent an opportunity cost.
> >> 
> >>> What is the
> >>> difference between "release and recapture" and "reset start"?
> >> 
> >> One appears to be a new conference instance, while the other
> >> appears to be 
> >> a modification of an existing conference.
> >> 
> >> 
> >>>> 
> >>>>>   The problem is,
> >>>>> that would have to be a convener action; you wouldn't want a
> >>>> participant
> >>>>> to invoke it.
> >>>>> 
> >>>>> Also, Petri, you can't implement a "Meet Me" with
> >>>> start/stop.  MeetMes don't
> >>>>> have start and stop times.
> >>>> 
> >>>> You are asserting what the group is attempting to define.
> >>> Well, we can twist start and stop, but to any person, a 
> meet me, by
> >>> definition, does not have start and stop times.  Could we
> >> implement it
> >>> by twisting start/stop?  I guess, but I don't think its a 
> good idea.
> >>> 
> >>>> 
> >>>>>   They start whenever the convener arrives,
> >>>> 
> >>>> What if the convener never arrives, but the rest of the group
> >>>> does?  To say
> >>>> it never starts seems rather limiting in an unnecessary way.
> >>> That's the way Meet Me (notice the word "Me") services 
> are defined.
> >> 
> >> I should note that the term "meet me" has been used in a more
> >> broad way to 
> >> mean any pre-scheduled conference for which a number
> >> (address) has be setup
> >> and to which users are asked to call into at some future
> >> time.  You seem to
> >> have something more specific in mind.  I have no problem with
> >> a specific, 
> >> maybe trademarked, service to be more narrowly defined, but
> >> see no reason 
> >> to limit other possibilities.
> >> 
> >>> I happen to think its an excellent service.  I would not 
> want anyone
> >>> to be able to use my Meet Me conference if I was not there.
> >>> I am charged for it.  If 4 people know my MeetMe URI, 
> they can decide
> >>> to have a conference (on my nickle) any time they want if there is
> >>> not a restriction that convener starts.  That is 
> precisely why MeetMe
> >>> works the way it does.  Its not a current technology limitation.
> >> 
> >> I have not problem with this being possible, just don't think
> >> CPCP should 
> >> be restricted for being used in other ways.  Protocol should
> >> be generally 
> >> usable for many types of services.
> >> 
> >>> I have no problem at all in allowing CPCP to facilitate an ad-hoc
> >>> conference, which is what I think you are looking for.  Ad-hoc is
> >>> a conference starts either by promoting a one on one to a 
> three way,
> >>> or by the first person connecting to the conference, and 
> it ends when
> >>> the last person leaves (or for some, when the number of 
> participants
> >>> drops below 3).  Ad-hoc is also a useful service, but 
> usually we use
> >>> ad-hoc internally where charging issues are simpler.
> >>>> 
> >>>>> end
> >>>>> when he leaves (usually),
> >>>> 
> >>>> This again is not necessary.  A convener (payer) may want to
> >>>> start the
> >>>> conference, but not stay for the full discussion.  No reason
> >>>> the conference
> >>>> can not continue without that person, if the policy says it can.
> >>> Agree, but I want you to explicitly say that, and I want 
> local policy
> >>> to be able to permit you to say that, or deny you the
> >> ability to say that.
> >> 
> >> OK
> >> 
> >> 
> >>>> 
> >>>>> but restart when he arrives again with out regard
> >>>>> to start and stop.
> >>>> 
> >>>> A new start and stop time is a new conference, perhaps an ad hoc
> >>>> one.  There is no reason the conference policy would restrict
> >>>> the convener
> >>>> from scheduling multiple conferences, unless there is other
> >>>> local policy
> >>>> that over-rides the ability to do so.  But, that again is
> >>>> implementation.
> >>> Well, a new start/stop MAY be a new conference, or it could
> >> be a reschedule
> >>> of an existing one.  Take a scenario where a couple of
> >> participants show,
> >>> the convener doesn't, and the participants leave.
> >> 
> >> Hopefully, the convener could show up late and the conference
> >> is still 
> >> active and resources get invoked for him and whoever else
> >> shows up late.
> >> 
> >>> The convener pushes
> >>> start and stop an hour.  If its a new conference, there is a
> >> new conference
> >>> URI.
> >>> If its a reschedule, then its the same conference, and the
> >> same URI.  I
> >>> think
> >>> that is preferable.
> >> 
> >> So long as the convener shows up within the hour it was originally
> >> scheduled, could it be neither a new conference nor a
> >> reschedule?  Suppose
> >> he shows 20 minutes late, but only needs 40 minutes to get
> >> the work done, 
> >> why should any policy change take place?
> >> 
> >> 
> >>> Local policy, as I advocate, is indeed a controlling factor.
> >>  However, to be
> >>> successful, the convener and the participants have to know
> >> what the local
> >>> policy is, so that their expectations are met.  That means
> >> CPCP has to have
> >>> ways of the participants including the convener to 
> learning the local
> >>> policy,
> >>> which means the language has to have the ability to express
> >> it.  It's not
> >>> just implementation.
> >>> 
> >>>> 
> >>>> I hope the tone of the above does not sound harsh.  I just
> >>>> think it would
> >>>> be useful to separate the definition of "what" the conference
> >>>> is from the
> >>>> definition of "how" it is to be supported.
> >>> Confused about "what a conference is".  I think we are all
> >> working on the
> >>> "how it is to be supported".  I don't even want to think
> >> about a definition
> >>> of what it is.  For example, if I play music on hold to you
> >> while you are
> >>> waiting for a conference to start, is that part of the conference?
> >> 
> >> That sounds like a service description which may be
> >> implementation dependent.
> >> 
> >>> You got
> >>> there with the conference URI, you can probably manipulate
> >> some resources
> >> 
> >> 
> >> _______________________________________________
> >> XCON mailing list
> >> XCON@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/xcon
> >> 
> > 
> 

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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.