Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

From: "Christopher Richards" <[email-masked]>
Date: Fri, 30 Jan 2004 10:09:17 -0600

All,

Please find enclosed issue regarding the current tariff change mechanism
specified in the DCC draft.
Best Regards,
Chris Richards.

Description of issue: Tariff Change
Submitter name: Chris Richards, Tim Roberts
Date first submitted: 29.01.2004
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt
Comment type: T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Sections: 8.16, 8.41 and 8.42

Rationale/Explanation of issues: 

The current draft implements a tariff time change capability by allowing the
Used-Service-Units to report back the used resources before and after a
tariff change. However, the resources supplied by the DCC server are given
in a single Granted-Service-Units AVP. However, using this mechanism has a
number of drawbacks and practical issues:

1. It is complex for the DCC server since it must reserve credit on the
basis of which will be more expensive before or after consumption (As
acknowledged in section 5 of the draft). This is particularly inconvenient
when the model changes e.g. some bundled minutes after the duration, or
rates change to a minimum of x or any other model. As a result, either the
server will have to allocate smaller quotas resulting in increased quota
activity or it will have to reserve a larger amount of credit exacerbating
credit fragmentation concerns.

2. The draft document states that the mechanism is not used when the
resource unit is time. However, in order to perform tariff time changes, the
client will have to re-authorise all quotas for all sessions that react to
the same tariff time change - this will lead to a flood of messaging and
processing on the client and server which will result in delayed responses
and inaccurate time change values. 

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism
has been introduced for the Diameter IMS charging application which avoids
the problems stated above - there are no longer used resources that straddle
a tariff change thus removing this indeterminate charging scenario. It would
seem highly desirable to align with this mechanism so all applications can
benefit.

Requested changes:

- Section 5, last paragraph:

FROM:
   The Diameter credit-control server and client may optionally support a 
   tariff change mechanism. The Diameter credit-control server may 
   include a Tariff-Time-Change AVP in the answer message. Note that the 
   granted units should be allocated based on the worst-case scenario in 
   case of forthcoming tariff change, so that the overall reported used 
   units would never exceed the credit reservation.  
   When the Diameter credit-control client reports the used units and a 
   tariff change has occurred during the reporting period then the 
   Diameter credit-control client SHOULD itemize the units used before 
   and after the tariff change. In case some units straddled the tariff 
   change, the credit-control client SHOULD itemize those units as well.

TO:
   The Diameter credit-control server and client may optionally support a 
   tariff change mechanism. The Diameter credit-control server may 
   include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in
   two quota allocations in the answer message. One of the granted units is
   allocated to be used before the potential tariff change while the
   second granted units are used after a tariff change. Both granted unit
   quotas MUST contain the same Service-Identifier and Rating-Group values.
   This dual quota mechanism ensures that the overall reported used
   units would never exceed the credit reservation.  
   The Diameter credit-control client reports both the used units before 
   and after the tariff change.

- Section 8.16, new paragraphs:

NEW:
   The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP
is
   present. It instructs the client when the resources in the
Granted-Service-
   Unit AVP should be used.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are
present,
   the server MUST include two separate Granted-Service-Unit AVPs (for the
   same Service-Identifier and/or Rating-Group when either the Service-
   Identifier or Rating-Group AVP is included). One of the Granted-Service-
   Units resources are used before a tariff change occurs, while the other
   is to be used after the tariff change has occurred.

- Section 8.16, last paragraph:

FROM:
   The Granted-Service-Unit AVP has the following ABNF grammar:   
             
         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  [ Tariff-Time-Change ]   
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ]
TO:
   The Granted-Service-Unit AVP has the following ABNF grammar:   
             
         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  [ Tariff-Time-Change ]   
                                  [Tariff-Change-Usage ]
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ]

- Section 8.41, first and second paragraphs:

FROM:
   The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 
   includes the time in seconds since January 1, 1900 00:00 UTC when the 
   tariff of the service will be changed. 
    
   The tariff change mechanism is optional for client and server and it 
   is not used for unit type time, since the server has full control of 
   the time.  
    
TO:
   The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 
   includes the time in seconds since January 1, 1900 00:00 UTC when the 
   tariff of the service will be changed.

   The tariff change mechanism is optionally enabled by the server for a 
   Diameter credit control session or sub-session.

- Section 8.42:

FROM: 
   The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and 
   defines whether units are used before, after or straddled tariff 
   change when a tariff change has occurred during the reporting period. 
   Omission of this AVP means that no tariff change has been occurred. 
    
   Tariff-Change-Usage can be one of the following. 
    
    UNIT_BEFORE_TARIFF_CHANGE                                  0 
    
     The used units contains the amount of the units before tariff 
     change, that is units measured from the point when the previous 
     measurement ended to the point when tariff change occurred. 
    
    UNIT_AFTER_TARIFF_CHANGE                                   1 
 
     The used units contains the amount of the units after tariff change 
     has been occurred. 
    
    UNIT_INDETERMINATE                                         2 
    
     The used units contains the amount of units that straddle the 
     tariff change (e.g. the metering process reports to the credit-
     control client in blocks of n octets and one block straddled the 
     tariff change).
TO:    
   The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated.

   When present in the Granted-Service-Units AVP, this AVP defines whether
   units are allocated to be used before or after a tariff change event. 

   When present in the Used-Service-Units AVP, this AVP identified what
   resources where used before or after a tariff change during the reporting

   period. 

   Omission of this AVP means that no tariff change is to be reported and/or
   none has occurred. 
    
   Tariff-Change-Usage can be one of the following. 
    
    UNIT_BEFORE_TARIFF_CHANGE                                  0 
    
     When present in the Granted-Service-Units AVP, this value indicates
     the amount of the units allocated for use before a tariff change
     occurs.

     When present in the Reported-Service-Units AVP, this value indicates
     the amount of resource units used before a tariff change had occurred. 
    
    UNIT_AFTER_TARIFF_CHANGE                                   1 
    
     When present in the Granted-Service-Units AVP, this value indicates
     the amount of the units allocated for use after a tariff change
     occurs.

     When present in the Reported-Service-Units AVP, this value indicates
     the amount of resource units used after tariff change had occurred. 

- end of changes

Best Regards,
Chris Richards.

---

From: [email-masked]
Date: Fri, 30 Jan 2004 16:18:09 +0000

Hi Chris,

The option to specify units straddlling a tariff time change was suggested 
by us as we have an implemented system that behaves like this.

There is a fundamental difference between tariffs changing for a service 
that is consumed at a regular rate (i.e. time based such as 
circuit-switched calls) and one that is consumed at an irregular rate 
(such as GPRS or 3G data services).

For time-based services there is no need to report the Tariff-Time-Change 
AVP to the client.  It doesn't even need to know that the tariff has 
changed.  When the server knows that there is tariff change due it can 
take this into account when rating the granted units.  There is no need 
for any additional Diameter traffic for time-based services when there is 
a tariff change.

Regards,

John. 

"Christopher Richards" <[email-masked]>
Sent by: [email-masked]
30/01/2004 16:09

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All, 

Description of issue: Tariff Change 
Submitter name: Chris Richards, Tim Roberts 
Date first submitted: 29.01.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt 
Comment type: T 
Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 
Sections: 8.16, 8.41 and 8.42 
Rationale/Explanation of issues: 
The current draft implements a tariff time change capability by allowing 
the Used-Service-Units to report back the used resources before and after 
a tariff change. However, the resources supplied by the DCC server are 
given in a single Granted-Service-Units AVP. However, using this mechanism 
has a number of drawbacks and practical issues:
1. It is complex for the DCC server since it must reserve credit on the 
basis of which will be more expensive before or after consumption (As 
acknowledged in section 5 of the draft). This is particularly inconvenient 
when the model changes e.g. some bundled minutes after the duration, or 
rates change to a minimum of x or any other model. As a result, either the 
server will have to allocate smaller quotas resulting in increased quota 
activity or it will have to reserve a larger amount of credit exacerbating 
credit fragmentation concerns.
2. The draft document states that the mechanism is not used when the 
resource unit is time. However, in order to perform tariff time changes, 
the client will have to re-authorise all quotas for all sessions that 
react to the same tariff time change - this will lead to a flood of 
messaging and processing on the client and server which will result in 
delayed responses and inaccurate time change values. 
3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism 
has been introduced for the Diameter IMS charging application which avoids 
the problems stated above - there are no longer used resources that 
straddle a tariff change thus removing this indeterminate charging 
scenario. It would seem highly desirable to align with this mechanism so 
all applications can benefit.
Requested changes: 
- Section 5, last paragraph: 
FROM: 
   The Diameter credit-control server and client may optionally support a 
   tariff change mechanism. The Diameter credit-control server may 
   include a Tariff-Time-Change AVP in the answer message. Note that the 
   granted units should be allocated based on the worst-case scenario in 
   case of forthcoming tariff change, so that the overall reported used 
   units would never exceed the credit reservation. 
   When the Diameter credit-control client reports the used units and a 
   tariff change has occurred during the reporting period then the 
   Diameter credit-control client SHOULD itemize the units used before 
   and after the tariff change. In case some units straddled the tariff 
   change, the credit-control client SHOULD itemize those units as well. 
TO: 
   The Diameter credit-control server and client may optionally support a 
   tariff change mechanism. The Diameter credit-control server may 
   include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in 
   two quota allocations in the answer message. One of the granted units 
is 
   allocated to be used before the potential tariff change while the 
   second granted units are used after a tariff change. Both granted unit 
   quotas MUST contain the same Service-Identifier and Rating-Group 
values. 
   This dual quota mechanism ensures that the overall reported used 
   units would never exceed the credit reservation. 
   The Diameter credit-control client reports both the used units before 
   and after the tariff change. 
- Section 8.16, new paragraphs: 
NEW: 
   The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP 
is 
   present. It instructs the client when the resources in the 
Granted-Service- 
   Unit AVP should be used. 
   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 
present, 
   the server MUST include two separate Granted-Service-Unit AVPs (for the 
   same Service-Identifier and/or Rating-Group when either the Service- 
   Identifier or Rating-Group AVP is included). One of the 
Granted-Service- 
   Units resources are used before a tariff change occurs, while the other 
   is to be used after the tariff change has occurred. 
- Section 8.16, last paragraph: 
FROM: 
   The Granted-Service-Unit AVP has the following ABNF grammar: 

 
 
TO: 

- Section 8.42: 
FROM: 

 

 
    UNIT_INDETERMINATE                                         2 
 
     The used units contains the amount of units that straddle the 
     tariff change (e.g. the metering process reports to the credit- 
     control client in blocks of n octets and one block straddled the 
     tariff change). 
TO: 
   The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated. 
   When present in the Granted-Service-Units AVP, this AVP defines whether 
   units are allocated to be used before or after a tariff change event. 
   When present in the Used-Service-Units AVP, this AVP identified what 
   resources where used before or after a tariff change during the 
reporting 
   period. 
   Omission of this AVP means that no tariff change is to be reported 
and/or 
   none has occurred. 

 
     When present in the Granted-Service-Units AVP, this value indicates 
     the amount of the units allocated for use before a tariff change 
     occurs. 
     When present in the Reported-Service-Units AVP, this value indicates 
     the amount of resource units used before a tariff change had 
occurred. 

 
- end of changes 

Best Regards, 
Chris Richards. 

******************************************************************************

The content of this e-mail may be privileged and/or confidential.
If you are not the addressee indicated in this message 
(or responsible for delivery of the message to such person), 
you may not copy or deliver this message to anyone. In such 
case, you should destroy this message and kindly notify the 
sender and [email-masked] by reply email.  Please
note that in such circumstances any review, dissemination, 
disclosure, alteration, printing, copying or further transmission
of this e-mail and/or any file transmitted with it is prohibited 
and may be unlawful. Please advise us immediately if you or
your employer do not consent to Internet email for messages 
of this kind.  The opinions, conclusions and other information 
in this message are of the author and shall be understood as 
neither given nor endorsed by Vodafone Ireland Limited 
unless it is otherwise indicated by an authorised representative 
independent of this message.  Internet e-mail is
transmitted over the public internet over which Vodafone 
Ireland Limited has no control.  As such, there is no guarantee that 
(i) this e-mail will be delivered within a reasonable time or at all
(ii) this e-mail comes from the purported sender 
(iii) this e-mail has not been intercepted by a third party 
(iv) the contents of this e-mail are unaltered from the time of
transmission.  The presence of this footnote indicates that this 
message (including its attachments) has been processed by an 
automated anti-virus system; however it is the responsibility of 
the recipient to ensure that the message (and attachments) 
are safe and authorised for use in their environment.
Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Number 326967 VAT Reg No. IE6346967G

******************************************************************************

---

From: <[email-masked]>
Date: Fri, 30 Jan 2004 18:23:33 +0200

John Prudhoe wrote
 
The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. 

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). 

Agree. Lets keep the UNIT_INDETERMINATE as discussed earlier.
 
For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change. 
 
Fully agree also here. Lets keep th emechanism as it is.
 
Chris Richards wrote
 
3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. 
 
Why don't you align to the DCC instead?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext [email-masked]
Sent: 30 January, 2004 18:18
To: Christopher Richards
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

The option to specify units straddlling a tariff time change was suggested by us as we have an implemented system that behaves like this. 

There is a fundamental difference between tariffs changing for a service that is consumed at a regular rate (i.e. time based such as circuit-switched calls) and one that is consumed at an irregular rate (such as GPRS or 3G data services). 

For time-based services there is no need to report the Tariff-Time-Change AVP to the client.  It doesn't even need to know that the tariff has changed.  When the server knows that there is tariff change due it can take this into account when rating the granted units.  There is no need for any additional Diameter traffic for time-based services when there is a tariff change. 

Regards, 

John. 

30/01/2004 16:09 

All, 

Please find enclosed issue regarding the current tariff change mechanism specified in the DCC draft. 
Best Regards, 
Chris Richards. 

The current draft implements a tariff time change capability by allowing the Used-Service-Units to report back the used resources before and after a tariff change. However, the resources supplied by the DCC server are given in a single Granted-Service-Units AVP. However, using this mechanism has a number of drawbacks and practical issues: 

1. It is complex for the DCC server since it must reserve credit on the basis of which will be more expensive before or after consumption (As acknowledged in section 5 of the draft). This is particularly inconvenient when the model changes e.g. some bundled minutes after the duration, or rates change to a minimum of x or any other model. As a result, either the server will have to allocate smaller quotas resulting in increased quota activity or it will have to reserve a larger amount of credit exacerbating credit fragmentation concerns. 

2. The draft document states that the mechanism is not used when the resource unit is time. However, in order to perform tariff time changes, the client will have to re-authorise all quotas for all sessions that react to the same tariff time change - this will lead to a flood of messaging and processing on the client and server which will result in delayed responses and inaccurate time change values. 

3. In 3GPP IMS charging (3GPP TS 32.225, Release 5), a different mechanism has been introduced for the Diameter IMS charging application which avoids the problems stated above - there are no longer used resources that straddle a tariff change thus removing this indeterminate charging scenario. It would seem highly desirable to align with this mechanism so all applications can benefit. 

Requested changes: 

FROM: 

TO: 

NEW: 
  The Tariff-Change-Usage AVP is included when the Tariff-Time-Change AVP is 
  present. It instructs the client when the resources in the Granted-Service- 
  Unit AVP should be used. 

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, 

FROM: 

FROM: 

TO: 

- Section 8.42: 

FROM: 

   

   
   UNIT_INDETERMINATE                                         2 

   

   

- end of changes 

Best Regards, 
Chris Richards.

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 30 Jan 2004 10:27:19 -0600

Thanks for the reply John,
 
Since there are implementations that can generate straddling usage counts
today, I don't have a problem leaving this value in the Tariff-Change-Usage
AVP.
However, I still think that the current proposed mechanism in the draft
should address it's shortcomings as I described in the Issue email I sent.
Will the change proposal be accepted as an issue to discuss? If so, should I
resubmit the issue with the change described above?
  
Best Regards,
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

There is a fundamental difference between tariffs changing for a service
that is consumed at a regular rate (i.e. time based such as circuit-switched
calls) and one that is consumed at an irregular rate (such as GPRS or 3G
data services). 

For time-based services there is no need to report the Tariff-Time-Change
AVP to the client.  It doesn't even need to know that the tariff has
changed.  When the server knows that there is tariff change due it can take
this into account when rating the granted units.  There is no need for any
additional Diameter traffic for time-based services when there is a tariff
change. 

Regards, 

John. 

30/01/2004 16:09 

All, 

Requested changes: 

FROM: 

TO: 

NEW: 

FROM: 

FROM: 

TO: 

- Section 8.42: 

FROM: 

   

   
   UNIT_INDETERMINATE                                         2 

  none has occurred. 

   

   

- end of changes 

Best Regards, 
Chris Richards. 

****************************************************************************
**

****************************************************************************
**

---

From: [email-masked]
Date: Fri, 30 Jan 2004 17:07:39 +0000

Hi Chris,

I've no objection myself in principle to your mechanism of allocating 
quotas together for both units before and units after the tariff change. 
As long as it is all optional.

The question is: how likely is the client to run out of the before units 
before the time of the tariff change.  This would trigger an 
re-authorisation even though the units after are unused.  To avoid this, 
the server would have to allocated a higher quota in that category. 
Alternatively, if the user did little before the tariff change and lots 
after they would be likely to consume the units after much more quickly. 
 
Therefore, I suspect that this mechanism won't reduce the volume of 
authorisation traffic in practice unless larger quotas are allocated, 
which I think defeats your objective of trying to reduce credit 
fragmentation. 

Regards,

John.

30/01/2004 16:27

        To:     "[email-masked]'" <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>, [email-masked]
        Subject:        RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Since there are implementations that can generate straddling usage counts 
today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.
However, I still think that the current proposed mechanism in the draft 
should address it's shortcomings as I described in the Issue email I sent. 
Will the change proposal be accepted as an issue to discuss? If so, should 
I resubmit the issue with the change described above?
  
Best Regards,
Chris. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

Regards, 

John. 

All, 

 

TO: 

 

 
   UNIT_INDETERMINATE                                         2 

 

 
    
- end of changes 
Best Regards, 
Chris Richards.

---

From: <[email-masked]>
Date: Sat, 31 Jan 2004 08:03:38 +0200

Hi all,

> As long as it is all optional. 

I am quite worried about additional optional mechanisms.  Already
the specification is quite complicated and I worry that additional
optional mechansisms will create extremely complicated mechanisms.

I favor simplication at this point, so I'd hope we could discuss
the options and focus on a single mechansim.

thanks,
John

---

From: <[email-masked]>
Date: Sat, 31 Jan 2004 08:48:53 +0200

Assigned issue 18.
 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 30 January, 2004 18:09
To: [email-masked]'
Subject: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

All, 

Requested changes: 

FROM: 

TO: 

NEW: 

FROM: 

FROM: 

TO: 

- Section 8.42: 

FROM: 

    

    
    UNIT_INDETERMINATE                                         2 

    

    

- end of changes 

Best Regards, 
Chris Richards.

---

From: <[email-masked]>
Date: Sat, 31 Jan 2004 08:50:03 +0200

Hi Chris,
 
If you want to resubmit it with changes, I'll add it to the issue number.
 
thanks,
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Christopher Richards
Sent: 30 January, 2004 18:27
To: [email-masked]'
Cc: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Since there are implementations that can generate straddling usage counts today, I don't have a problem leaving this value in the Tariff-Change-Usage AVP.
However, I still think that the current proposed mechanism in the draft should address it's shortcomings as I described in the Issue email I sent. Will the change proposal be accepted as an issue to discuss? If so, should I resubmit the issue with the change described above?
  
Best Regards,
Chris. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 10:18 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [AAA-WG]: DCC: Issue: Tariff Change mechanism.

Hi Chris, 

Regards, 

John. 

30/01/2004 16:09 

All, 

Requested changes: 

FROM: 

TO: 

NEW: 

FROM: 

FROM: 

TO: 

- Section 8.42: 

FROM: 

   

   
   UNIT_INDETERMINATE                                         2 

   

   

- end of changes 

Best Regards, 
Chris Richards.