draft-ietf-dime-rfc4006bis-10.txt   draft-ietf-dime-rfc4006bis-11.txt 
Network Working Group L. Bertz, Ed. Network Working Group L. Bertz, Ed.
Internet-Draft Sprint Internet-Draft Sprint
Obsoletes: 4006 (if approved) D. Dolson, Ed. Obsoletes: 4006 (if approved) D. Dolson, Ed.
Intended status: Standards Track Y. Lifshitz, Ed. Intended status: Standards Track Y. Lifshitz, Ed.
Expires: January 16, 2019 Sandvine Expires: February 27, 2019 Sandvine
July 15, 2018 August 26, 2018
Diameter Credit-Control Application Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-10 draft-ietf-dime-rfc4006bis-11
Abstract Abstract
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. The Diameter Credit- messaging services, and download services. The Diameter Credit-
Control application as defined in this document obsoletes RFC4006, Control application as defined in this document obsoletes RFC4006,
and it must be supported by all new Diameter Credit-Control and it must be supported by all new Diameter Credit-Control
Application implementations. Application implementations.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2019. This Internet-Draft will expire on February 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 77, line 8 skipping to change at page 77, line 8
IPv4 Address 0 IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as The address type is in the form of "dotted-decimal" IPv4 address, as
defined in [RFC0791]. defined in [RFC0791].
IPv6 Address 1 IPv6 Address 1
The address type is in the form of IPv6 address, as defined in The address type is in the form of IPv6 address, as defined in
[RFC4291]. The address MUST conform to the text representation of [RFC4291]. The address MUST conform to the text representation of
the address according to [RFC5952]. the address according to [RFC5952].
Because [RFC5952] is more restrictive than the RFC3513 format
required by [RFC4006], some legacy implementations may not be
compliant with the new requirements. Accordingly, implementations
receiving this AVP MAY be liberal in the textual IPv6 representations
that are accepted without raising an error.
URL 2 URL 2
The address type is in the form of Uniform Resource Locator, as The address type is in the form of Uniform Resource Locator, as
defined in [RFC3986]. defined in [RFC3986].
SIP URI 3 SIP URI 3
The address type is in the form of SIP Uniform Resource Identifier, The address type is in the form of SIP Uniform Resource Identifier,
as defined in [RFC3261]. as defined in [RFC3261].
skipping to change at page 87, line 26 skipping to change at page 87, line 26
order to implement the policy-defined action. order to implement the policy-defined action.
The Final-Unit-Action AVP defines the behavior of the service element The Final-Unit-Action AVP defines the behavior of the service element
when the user's account cannot cover the cost of the service and MUST when the user's account cannot cover the cost of the service and MUST
always be present if the QoS-Final-Unit-Indication AVP is included in always be present if the QoS-Final-Unit-Indication AVP is included in
a command. a command.
If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit- If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-
Indication group MUST NOT contain any other AVPs. Indication group MUST NOT contain any other AVPs.
If the Final-Unit-Action AVP is set to REDIRECT at least one of the If the Final-Unit-Action AVP is set to REDIRECT then the Redirect-
Redirect-Server and Redirect-Server-Extension AVPs MUST be present. Server-Extension AVPs MUST be present. The Filter-Rule AVP or the
The Filter-Rule AVP or the Filter-Id AVP MAY be present in the Filter-Id AVP MAY be present in the Credit-Control-Answer message if
Credit-Control-Answer message if the user is also allowed to access the user is also allowed to access other services that are not
other services that are not accessible through the address given in accessible through the address given in the Redirect-Server-Extension
the Redirect-Server-Extension AVP or if the access to these services AVP or if the access to these services needs to be limited in some
needs to be limited in some way (e.g., QoS). way (e.g., QoS).
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
Filter-Rule AVP or the Filter-Id AVP SHOULD be present. Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can
be used to define a specific condition and action combination. If be used to define a specific condition and action combination. If
used only with traffic conditions, it should define which traffic used only with traffic conditions, it should define which traffic
should allowed when no more service units are granted. However, if should allowed when no more service units are granted. However, if
QoS or treatment information exists in the AVP, these actions should QoS or treatment information exists in the AVP, these actions should
be executed, e.g., limiting the allowed traffic with certain QoS. be executed, e.g., limiting the allowed traffic with certain QoS.
 End of changes. 5 change blocks. 
11 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/