Subject: [Dime] Scrubbing of AVP descriptions, resolution of issue 82

From: Steve Donovan <[email-masked]>
Date: Mon, 20 Oct 2014 18:26:55 +0200

With this update I did a scrub of avp description, removing behavior 
definitions that are already in other sections.  There were also a few 
editorial changes mixed in.

I've attached the diff file and a summary of the changes follows.

Regards,

Steve

-----

Section 6.1 OC-Supported-Features

Removed the following which is covered in the section on Capability 
Announcement:

    A reacting node includes this AVP to indicate its capabilities to a
    reporting node.  For example, the reacting node may indicate which
    (future defined) traffic abatement algorithms it supports in addition
    to the default.

    During the message exchange the DOIC nodes express their common set
    of supported capabilities.  The reacting node includes the OC-
    Supported-Features AVP that announces what it supports.  The
    reporting node that sends the answer also includes the OC-Supported-
    Features AVP that describes the capabilities it supports.  The set of
    capabilities advertised by the reporting node depends on local
    policies.  Since the loss abatement algorithm Section 5 is mandatory
    to implement DOIC can always be enabled between these DOIC nodes.

Also changed the following in section 4.1.1, as the OC-Feature-Vector is 
an optional parameter:

Old text:

    A reacting node MUST include the OC-Feature-Vector AVP with an
    indication of the loss algorithm.

New text

A reacting node MAY include the OC-Feature-Vector AVP with an indication 
of the loss algorithm.  A reacting node MUST include the 
OC-Feature-Vector AVP to indicate support for abatement algorithms in 
addition to the loss algorithm.

6.3 OC-OLR

Removed the following, it belongs in the OC-Validity-Duration AVP section:

    The OC-Validity-Duration AVP indicates the validity time of the
    overload report associated with a specific sequence number, measured
    after reception of the OC-OLR AVP.  The validity time MUST NOT be
    updated after reception of subsequent OC-OLR AVPs with the same
    sequence number.  The default value for the OC-Validity-Duration AVP
    value is 5 (i.e., 5 seconds).  When the OC-Validity-Duration AVP is
    not present in the OC-OLR AVP, the default value applies.

Section 6.5 - OC-Sequence-Number

As resolution to issue 82, change the following:

    From the functionality point of view, the OC-Sequence-Number AVP MUST
    be used as a non-volatile increasing counter between two DOIC nodes.

To:

          From the functionality point of view, the OC-Sequence-Number 
AVP MUST
          be used as a non-volatile increasing counter for a sequence of 
overload reports
          between two DOIC nodes for the same overload occurrence.

Moved the following to section 4.2.3 Reporting Node Behavior (for 
overload report handling)

    When generating sequence numbers, the new sequence number MUST be
    greater than any sequence number in an active overload report
    previously sent by the reporting node.  This property MUST hold over
    a reboot of the reporting node.

Added the following to section 4.2.3:

           If OLR is for a new overload condition and there is no unexpired
           overload report for previous overload conditions
           at any reacting node then the reporting node MAY
           set the sequence number to any value.

           The reacting node MAY update the overload report with new 
reduction
           percentages.  When doing so, the reacting node MUST increase the
           sequence number in the new OLR sent.

           When generating sequence numbers for , the new sequence 
number MUST be
           greater than any sequence number in an active (unexpired) 
overload report
           previously sent by the reporting node.  This property MUST 
hold over
           a reboot of the reporting node.

Section 6.5 OC-Validity-Duration AVP:

Removed the following:

    When a reporting node has recovered from overload, it SHOULD
    invalidate any existing overload reports in a timely matter.  This
    can be achieved by sending an updated overload report (meaning the
    OLR contains a new sequence number) with the OC-Validity-Duration AVP
    value set to zero ("0").  If the overload report is about to expire
    naturally, the reporting node MAY choose to simply let it do so.

    A reacting node MUST invalidate and remove an overload report that
    expires without an explicit overload report containing an OC-
    Validity-Duration value set to zero ("0").

Section 6.6 OC-Report-Type

Removed the following editor's note:

       Editor's note: There is still an open issue on the definition of
       Realm reports and whether what report types should be supported.
       There is consensus that host reports should be supported.  There
       is discussion on Realm reports and Realm-Routed-Request reports.
       The above definition applies to Realm-Routed-Request reports where
       Realm reports are defined to apply to all requests that match the
       realm, independent of the presence, absence or value of the
       Destination-Host AVP.