Subject: RE: Outsourcing and Provisioning common model

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 1 Feb 2002 10:12:27 -0500

Actually, this does not affect the protocol at all. It is mainly a question
of PIB structures. It is also worth pointing out that with the proper
outsourcing semantics defined through PIBS, this will not only be useful to
RSVP, but to any protocol with a control plain requiring configuration
policies for the data plain.

regards,

-Walter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 31, 2002 8:37 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Outsourcing and Provisioning common model
> 
> 
> Hi,
> 
> If I understand it correctly, 3GPP would like to use COPS-PR 
> for the GO interface and they have a tight schedule for their 
> next release. If we keep on changing the COPS protocols, is 
> it possible that people who are friendly with COPS will pick 
> up an alternative solution (SNMP or even Radius) simply for 
> stability reasons. By the time we come up with a perfect COPS 
> solution, many have already stood behind other protocols. 
> This applies not only to folks in 3GPP but also to those who 
> are interested in using COPS for policy management. Timing 
> may be everything for gaining market recognition. Without 
> market share, what is a perfect solution good for? 
> 
> Man 
> 
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 01 Feb 2002 12:50:03 -0500

Agree.

The proposal submitted into 3GPP is to USE THE COPS PROTOCOL WITH THE
COPS-PR EXTENSION AS IS.  NO PROTOCOL CHANGE REQUIRED.

We envision 3GPP's usage will be applicable to other usage also.
Hence we should work toward NO MORE COPS or COPS-PR PROTOCOL CHANGES!

Also, some good news:
3GPP CN3 have re-confirmed on Wed Jan 30, 2002 that the previous decision 
have not
change.  That is COPS-PR and UMTS Go PIB will be used for the 3GPP CN3 
functionalities.

We are continuing to get the UMTS Go PIB completed as part of 3GPP CN3 work 
item.
We will send updated UMTS Go PIB drafts into IETF as individual submissions.

-- Kwok --

At 08:36 PM 1/31/02 -0500, [email-masked] wrote:
>Hi,
>
>If I understand it correctly, 3GPP would like to use COPS-PR for the GO 
>interface and they have a tight schedule for their next release. If we 
>keep on changing the COPS protocols, is it possible that people who are 
>friendly with COPS will pick up an alternative solution (SNMP or even 
>Radius) simply for stability reasons. By the time we come up with a 
>perfect COPS solution, many have already stood behind other protocols. 
>This applies not only to folks in 3GPP but also to those who are 
>interested in using COPS for policy management. Timing may be everything 
>for gaining market recognition. Without market share, what is a perfect 
>solution good for?
>
>Man

---

From: Nguyen Thi Mai Trang <[email-masked]>
Date: Mon, 25 Feb 2002 16:50:07 +0100

Hi Walter, Kwok, Herzog and everybody,

> As such the arguement for normalization is to take the best of both COPS and
> COPS-PR, and merge them together.

I think that COPS include COPS-PR but when I read this sentence, COPS and
COPS-PR seem two  separate parts. I wonder that COPS-PR is a functional mode of
COPS protocol or COPS-PR is a protocol layer? I explain this question:

In RFC 3084, COPS-PR is defined as one functional mode of COPS protocol in which
the policies is supplied to the PEP before the event arrive. COPS Outsourcing is
another mode in which the policies is supplied to the PEP after the event
arrive. I read your draft and find that there are some cases (pages 8), the
event arrive ("When a packet arrive") and there is not yet policies to applied
("it does not match the criteria for an existing session"), the PEP marks the
session as "pending" and sends a REQ to the PDP to get policies for this event.
This means that you are in Outsourcing mode but the message are unchanged in
compare with COPS-PR. It means that you use 'Context = Configuration', 'ClientSI
= Named ClientSI'.

Therefore, I find that you call a protocol COPS-PR because it uses the PIB data
presentation and the Objects transporting PIB instances (COPS-PR plays the role
of protocol layer) rather than the Provioning model defined in the begining of
RFC 3084. I feel the same thing while reading COPS-UMTS.

Why don't you use 'Context = Resource-Allocation/ or Authorization' and
''ClientSI = Signaled ClientSI' for the case of Access Request and Access
Response because the sementic of this REQ is signaling to the PDP a new session
and request for an authorization?
For Accessor Provisioning Request, Provisioning Response and Report messages, I
totally agreed with your draft that it is pure COPS-PR.

I agreed with Kwok in a precedent message that the dynamic-ness of provisioning
can be from very static to very dynamic in COPS-PR. But the choice binary
Outsourcing/Provisioning for a client-type may cause sometimes paradox with
concepts defined in RFC 3084. Especially we call a client-type COPS-Provisioning
but some events arrive before its policies are requested and supplied.

IMHO, defining a 'unified mode' as the presentation of Shai Herzog is a good
idea and neccessary for an agree upon terminology for client-types using both
Outsourcing and Provisioning modes. A well definied terminology concerning
'Context' , 'ClientSI object', data representation in this mode...is wished.

Please tell me if I have misunderstandings. Thank you very much.
Mai Trang