Subject: [Dime] Early candidate DOIC-05

From: Steve Donovan <[email-masked]>
Date: Thu, 20 Nov 2014 09:03:18 -0600

All,

I've attached an early candidate for the DOIC-05 specification. This 
change contains the updates discussed at the Honolulu Dime working group 
meeting, the informal meeting held the next day and comments received 
via the Dime mailing list.

The areas still requiring work are an update to the security 
considerations section and adding text to the requirement conformance 
section.

These changes have been pushed into github.

I have also attached a diff file showing changes from DOIC-04.

Regards,

Steve

---

From: <[email-masked]>
Date: Tue, 25 Nov 2014 17:10:00 +0000

Hi Steve, All

Please find below straightforward editorial comments.

Regards,

Lionel

..............................................................................

*Section 3:

   DOIC nodes do not generate new messages to carry DOIC related
   information.  Rather, they "piggyback" DOIC information over existing
   Diameter messages by inserting new AVPs into existing Diameter
   requests and responses.  Nodes indicate support for DOIC, and any
   needed DOIC parameters, by inserting an OC_Supported_Features AVP
s/ OC_Supported_Features AVP/ OC-Supported-Features AVP
   (Section 6.2) into existing requests and responses.  Reporting nodes
   send OLRs by inserting OC-OLR AVPs (Section 6.3).

   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   some of the parameters of an OLR and the procedures required for
   overload abatement.  An overlaod abatement algorithm separates
s/ overlaod/ overload
   Diameter requests into two sets.  The first set contains the requests
   that are to undergo overload abatement treatment of either throttling
   or diversion.  The second set contains the requests that are to be
   given normal routing treatment.  This document specifies a single
   must-support algorithm, namely the "loss" algorithm (Section 5).
   Future specifications may introduce new algorithms.

*Section 3.2:

   Reporting nodes are allowed to change the overload abatement
   algorithm indicated in the OC-Feature-Vector AVP if the reporting
   node is not currently in and overload condition and sending overload
s/ in and overload/ in an overload
   reports.  The reporting node is not allowed to change the overload
   abatement algorithm while the reporting node is in an overload load
   condition.
s/ is in an overload load condition/ is in an overload condition

*Section 3.3

   Two types of overload abatement treatement are defined, diversion and
s/ treatement/ treatment
   throttling.  Reacting nodes are responsible for determining which
   treatment is appropraite for individual requests.
s/ appropraite/appropriate

*Section 3.4:

   Reporting nodes use the OC-OLR AVP to communicate overload
   occurrences.  This AVP can also be extended to add new AVPs allowing
   a reporting nodes to communicate additional information about
s/   a reporting nodes/reporting nodes
   handling an overload condition.

*section 4.2.2

   If the request matches an active OCS then the reacting node MUST use
   the overload abatement algorithm incideated in the OCS to determine
s/ incideated/indicated
   if the request is to receive overload abatement treatment.

[skip]

   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires or has a
   validity duration of zero ("0"), meaning that the reporting node has
   explicitly signaled the end of the overload condition then overlaod
s/ overlaod/overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.

*Section 4.2.3:

   A reporting node MAY rely on the OC-Validity-Duration AVP values for
   the implicit overload control state cleanup on the reacting node.
   However, it is RECOMMENDED that the reporting node always explicitly
   indicates the end of a overload condition.
s/ a overload condition/an overload condition

[skip]

   A reporting node SHOULD decrease requested overload abatement
   treatment in a controlled fashion to avoid occillations in traffic.
s/ occillations/oscillations 

*Section 6.8:

In the table, replace "x.x" by the corresponding section number, e.g. :

OC-Supported-Features  TBD1  x.x    Grouped     
OC-Supported-Features  TBD1  6.1    Grouped     

*Section 9.1:

   The Diameter protocol involves transactions in the form of requests
   and answers exchanged between clients and servers.  These clients and
   servers may be peers, that is, they may share a direct transport
   (e.g.  TCP or SCTP) connection, or the messages may traverse one or
   more intermediaries, known as Diameter Agents.  Diameter nodes use
   TLS, DTLS, or IPSec to authenticate peers, and to provide
s/IPSec/IPsec
   confidentiality and integrity protection of traffic between peers.
   Nodes can make authorization decisions based on the peer identities
   authenticated at the transport layer.

*Appendix D, Section D.3:

   Intra-Session Request:

      An intra session request is a request that uses the same Session-
s/ An intra session request/ An intra-session request
      Id than the one used in a previous request.  An intra session
s/ An intra-session/ An intra-session
      request generally needs to be delivered to the server that handled
      the session creating request for the session.  The STR message
      defined in [RFC6733] is an example of an intra-session requests.
s/ an intra-session requests/ an intra-session request

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 20 novembre 2014 16:03
À : [email-masked]
Objet : [Dime] Early candidate DOIC-05

All,

I've attached an early candidate for the DOIC-05 specification. This change contains the updates discussed at the Honolulu Dime working group meeting, the informal meeting held the next day and comments received via the Dime mailing list.

The areas still requiring work are an update to the security considerations section and adding text to the requirement conformance section.

Regards,

Steve

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.