: FW: Diameter Credit Control - IESG Evaluation, Allison Mankin's comments

Text to clear Allison's DISCUSS, still waiting on response.

--------------------------

Hello,

thank you for your comments.

Please see the answers and proposals for improved text below and let us
know whether these corrections and clarifications will address your concerns.

Best Regards,
Harri Hakala
Leena Mattila
Juha-Pekka Koskinen
Marco Stura
John Loughney
-----------------------------------------------------------------
Allison Mankin

Discuss:
- The Subscription-Id-Type AVPs are a very limited set and do not appear extensible: what about
this application for interoperating pres: uri's or other identifiers in future? Another case like this
is the User-Equipment-Identifier, which allows only 3GPP mobiles and wireless. This is inappropriate
in a general AAA document.

Answer:
Actually the AVPs are extensible. Both the Subscriptio-Id-Type and the User-Equipment-Info-Type AVPs
are of type enumerated, it is sufficient to define and document new values to extend the AVPs to
cover other needs. Basically we have defined those AVPs also thinking to extensibility since we cannot
cover all the possible identifier that may pop-up in the future.

Concerning the User-Equipment-Info AVP, we have defined MAC, EUI64 and MODIFIED_EUI64 that
should cover also a broad range of wired (non-3GPP) terminals.

Overall we believe that the AVPs in question are not 3GPP mobiles and wireless specific, rather generic
enough to cover other environments as well.

Discuss:
- The WG needed to think more broadly about SIP. The SIP example works as expected in
the 3GPP-enforced environment because the proxy can measure the quota, but in open 
environments, the proxy at best will see the BYE (and possibly might not see that). Flow II must
state in a careful final paragraph that the degree of credit control measuring of the media by
the proxy depends on the business model design used in setting up the end system and proxies 
in the SIP network.

Answer:
The intention of the flows example is just to illustrate simple examples for the usage of the DCCA.
The purpose of those flows is not to define how SIP work in different environments, it should perhaps
stated that the SIP signaling is inacurate and the focus is on credit control messages.
If a service provider want to offer prepaid services for SIP sessions based on time usage, it should 
make sure that all requests within the dialog created by that INVITE traverse the proxy that provide
prepaid services. Otherwise no prepaid services (usage based) can be offered at all.
Here is a proposal for a new text, perhaps you could suggest even more appropriate text should
you disagree with our proposal.

New text proposal to be added right after the diagram:

This is an example of Diameter Credit Control for SIP sessions. While the flow focuses on illustrating
the usage of credit-control messages, the SIP signaling is inaccurate and the diagram is not by any 
means an attempt to define a service provider's SIP network. However, for the sake of this example
some assumption is made as discussed in the next paragraph.

Typically, prepaid services based e.g. on time usage for SIP session require an entity in the service 
provider network to intercept all the requests within the SIP dialog in order to detect events, such as 
session establishment and session release, which are essential to perform credit-control operations 
with the credit control server. It is, therefore, assumed in this example that the SIP Proxy record-route 
since the initial INVITE to make sure that all the future requests in the created dialog traverse through it.
Finally, the degree of credit control measuring of the media by the proxy depends on the business
model design used in setting up the end system and proxies in the SIP network.

Discuss:
- Flow V and VII need a bigger SIP picture. In V, the INVITE is to B, or to a B2BUA that is
meant to intercept a price inquiry? This is a new SIP service. Flow VII describes use of a SIP
controller, which is probably 3PCC, but that needs to be shown, the call establishment would
need to be shown. 

Answer:
Flow V
The INVITE is sent to B. The term SIP controller was taken from the RFC 3725, not sure whether
this term is appropriate here.
The intention in this example is that this "SIP controller" just buffer the INVITE, just as it would do
a proxy for an ordinary quota request, until the AoC transaction is performed. When the user accept the 
charges the original INVITE is sent forward toward the destination.

Again, the intention of the flows example is just to illustrate simple examples for the usage of the DCCA
features. Perhaps similar text as proposed above is also suitable here?

New text proposal to be added right after the diagram (Flow V):

This is an example of Diameter Credit Control for SIP sessions. While the flow focuses on illustrating
the usage of credit-control messages, the SIP signaling is inaccurate and the diagram is not by any 
means an attempt to define a service provider's SIP network. 

UA A sends an INVITE with SDP to B (1).
Flow VII
SIP controller is here 3PCC, again the term was taken from RFC 3725. Perhaps we could refer to RFC
3725 and mention that best current practices for 3PCC are defined there.
Also in this flow we choose to keep the SIP signaling at very high level since we are not defining SIP
in this document, we are just doing high level examples to illustrate DCCA functionalities.

What about this text proposal?

Figure A.7 is an example of the graceful service termination for a SIP call. It is assumed the call is set up 
so that the controller is in the call as a B2BUA (Back to Back User Agent) performing third party call control
(3PCC). Note that the SIP signaling is inaccurate since the focus of this flow is in the graceful service 
termination and credit control authorization, best practices for 3PCC are defined in [RFC 3725].

We could then add RFC 3725 in the informational references.

Discuss:
- Recommendation on flows V and VII: Jon and I should email you as to whether to clean them up,
remove them, or annotate them.

Answer:
OK with us. Please consider the above proposals while making your decision.