Re: CAC RE: I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

"James M. Polk" <[email protected]> Mon, 09 Feb 2004 18:39:06 -0600
Newsgroups gmane.ietf.ieprep
Message-ID <4.3.2.7.2.20040209183201.03ed7c88@localhost>
I'm sorry Mike, but that is the functionality RSVP does and has done for 
many many years.... I'm not going to change it. Further, the maintenance 
CAC function (what you would call the part after initial admission) is what 
RSVP does. When referring to CAC and RSVP, this is the definition that is 
used in the IETF for voice and video flows.

When in Rome, you do what the Roman's do....

At 07:16 PM 2/9/2004 -0500, [email protected] wrote:
>In a message dated 2/9/2004 5:23:37 PM Eastern Standard Time, 
>[email protected] writes:
>
>
>>I had assumed that the term "Call Admission Control" was active only only 
>>at the START of a call- that once a call had been admitted in the first 
>>place, there was no further CAC involvement.
>>
>>However, reading between the lines in several posts, and relating that to 
>>some of the reference documents, it appears that the term CAC is being 
>>applied to a mechanism which remains involved throught the live of the 
>>call, and can "rescind" the admission during the course of the call, if 
>>necessary.
>
>
>
>This is a term which needs consistent definition before we continue. It's 
>being used in different ways, including as you noted above.
>
>Since the term is "Admission", I believe it only makes sense to use "CAC" 
>it to refer to the control that is placed on deciding whether or not to 
>admit a new call (i.e., packet flow), not on anything that is done later 
>to decide whether to preempt a call or terminate a packet flow.
>
>Mike


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented