Subject: [Dime] Issue #26 proposed resolution

From: Steve Donovan <[email-masked]>
Date: Tue, 29 Jul 2014 14:55:07 -0500

All,

Issue #26 - Overload control endpoints under specified.

During the DIME meeting in Toronto the proposal was made to remove the 
concept of Endpoints and Associations.

These concepts were helpful getting the specification to where it is now 
but a number of us consider the concepts to be confusing at best and 
potentially misleading.

The high level proposal is to remove section 3.1 that talks about 
Overload Control Endpoints and DOIC Associations.  The remainder of the 
document would then be updated to handle any references to that section 
and to the concepts of endpoint and association.

I've done a quick review of the document and there are a number of 
places where the term "overload control endpoint" is used.  I think most 
of these can be changed to "overload control node" or "DOIC node" with 
no additional change needed (other than to define these terms in the 
terminology section).

I want to see if there are any objections to this potential change 
before doing the work to propose specific wording changes.  If there is 
general agreement then I will come back to the list with detailed 
proposal for wording changes that would be reflected in the -04 version 
of the draft.

The other option would be to rewrite section 3.1 to have a more concise 
definition of endpoint, most likely removing the concept of DOIC 
association.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 30 Jul 2014 08:41:28 +0000

Steve,

I find the concept of DOIC End Points (and DOIC associations between DOIC End Points) helpful; especially the figures in section 3.1 are useful as they show valid scenarios.
I, however, agree that more clarifying text is needed to say how nodes detect in wich scenario they actually are.

E.g. with regard to figure 2, current text says
 "... there is an agent that is not participating directly in the exchange of overload reports."
but it is not said how the agent determines that it should/must be transparent.

Similarly for other figures.

Rather than deleting clause 3.1, I would prefer to add text providing rules for nodes to detect which of the valid scenarios is actually applicable. Please see my proposal of rules A) to F) sent on July 11th.

Regards,
Ulrich  

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, July 29, 2014 9:55 PM
To: [email-masked]
Subject: [Dime] Issue #26 proposed resolution

All,

Regards,

Steve

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 30 Jul 2014 15:09:33 +0000

The concept of DOIC endpoint is introduced in section 3.
I share the view that the section 3.1 can be removed. And the figures do not provide real added-values after saying in the introduction:

  "Any Diameter node can act as a DOIC endpoint, including clients,
   servers, and agents.  DOIC endpoints are further divided into
   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
   overload abatement by sending an Overload Report (OLR) to one or more
   reacting nodes.

   A reacting node consumes OLRs, and performs whatever actions are
   needed to fulfill the abatement requests included in the OLRs.  A
   Reporting node may report overload on its own behalf, or on behalf of
   other (typically upstream) nodes.  Likewise, a reacting node may
   perform overload abatement on its own behalf, or on behalf of other
   (typically downstream) nodes."

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mercredi 30 juillet 2014 10:41
À : ext Steve Donovan; [email-masked]
Objet : Re: [Dime] Issue #26 proposed resolution

Steve,

Regards,
Ulrich  

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, July 29, 2014 9:55 PM
To: [email-masked]
Subject: [Dime] Issue #26 proposed resolution

All,

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jul 2014 15:04:23 -0500

I concur. "Association" is an abstract concept that isn't needed to explain behavior. The specification should be about behavior.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 31 Jul 2014 10:07:48 +0300

I am also for removing Section 3.1.

- Jouni