Subject: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm

From: "dime issue tracker" <[email-masked]>
Date: Fri, 05 Sep 2014 07:30:39 -0000

#68: Loss as the common abatemen algorithm

 Some text is misleading since it may imply that one feature shall be in
 common between reporting and reacting node to progress, but in reality we
 only need to have one common abatement algorithm, and in this draft, LOSS
 is defined as default, then there is always one common algorithm

 Corrections are required in following clauses:

 Original text:

 4.2.3.  Reporting Node Behavior (Normative)

   ...

    The operation on the reporting node is straight forward.  The
    reporting node learns the capabilities of the reacting node when it
    receives the OC-Supported-Features AVP as part of any Diameter
    request message.  If the reporting node shares at least one common
    feature with the reacting node, then the DOIC can be enabled between
    these two endpoints.  See Section 4.1 for further discussion on the
    capability and feature announcement between two endpoints.

 Proposed modification:

 4.2.3.  Reporting Node Behavior (Normative)

    ...

    The
    reporting node learns the capabilities of the reacting node when it
    receives the OC-Supported-Features AVP as part of any Diameter
    request message.  Both reacting and reporting node MUST share at least
 one abatement algorithm, in fact, they share at least the loss algorithm,
 that is defined in this document as the default abatement algorithm, then
 the DOIC can always be enabled between these two endpoints at least with
 the default algorithm.  See Section 4.1 for further discussion on the
    capability and feature announcement between two endpoints.

 Original text:

 6.1.  OC-Supported-Features AVP

   ...

    During the message exchange the overload control endpoints 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.  At least one of the announced
    capabilities MUST match.  If there is no single matching capability
    the reacting node MUST act as if it does not implement DOIC and cease
    inserting any DOIC related AVPs into any Diameter messages with this
    specific reacting node.

       Editor's note: The last sentence conflicts with the last sentence
       two paragraphs up.  In reality, there will always be at least one
       matching capability as all nodes supporting DOIC must support the
       loss algorithm.  Suggest removing the last sentence.

 Proposed text:

 6.1.  OC-Supported-Features AVP

   ...

    During the message exchange the overload control endpoints 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. Both reacting and reporting node MUST share
 at least one abatement algorithm, in fact, they share at least the loss
 algorithm, that is defined in this document as the default abatement
 algorithm, then the DOIC can always be enabled between these two endpoints
 at least with the default algorithm.  See Section 4.1 for further
 discussion on the capability and feature announcement between two
 endpoints.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/68>
dime <http://tools.ietf.org/wg/dime/>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 5 Sep 2014 10:30:48 -0400

The proposed modifications lead to some rather long and awkward sentences. 
 For the same meaning, how about 

4.2.3
 
...
 Both reacting and reporting node MUST share the default abatement 
algorithm (loss). 
 Therefore the DOIC can always be enabled between these two endpoints at 
least with
 the default algorithm.
...

6.1

...
 Both reacting and reporting node MUST share the default abatement 
algorithm (loss).
 Therefore the DOIC can always be enabled between these two endpoints
 at least with the default algorithm.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   "dime issue tracker" <[email-masked]>
To:     [email-masked], 
[email-masked]
Cc:     [email-masked]
Date:   09/05/2014 03:36 AM
Subject:        [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the 
common abatemen algorithm
Sent by:        "DiME" <[email-masked]>

 Original text:

   ...

 Proposed modification:

    ...

    The

 Original text:

   ...

 Proposed text:

   ...

 algorithm, then the DOIC can always be enabled between these two 
endpoints

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

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 09:42:54 -0500

Maria Cruz,

I support the need for these changes.  I have a proposal for alternative 
wording below.

Regards,

Steve

>      capability and feature announcement between two endpoints.
SRD> I propose the following wording:

The reporting node learns the capabilities of the reacting node when it 
receives the
OC-Supported-Featuers AVP as part of any Diameter request message. At a 
minimum,
the reacting node and reporting node must both the loss abatement 
algorithm defined in this document
and, as a result, DOIC can always be enabled between these two 
endpoints.  See Section
4.1 ...
>   discussion on the capability and feature announcement between two
SRD> I propose the following:

... Both the reacting and reporting nodes must support the loss 
abatement algorithm
defined in this document.  As a result, DOIC behavior can always be 
enabled between
the reacting and reporting nodes.  See Section 4.1 ...

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 09:46:29 -0500

Janet,

These are similar to what I just sent.  One difference is that these 
still use the endpoint concept that has been purged from the document.  
It now uses the term "DOIC node" or explicitly refers to reacting node 
and/or reporting node.

Otherwise, your suggestions looks good.

Steve

On 9/5/14, 9:30 AM, Janet P Gunn wrote:
> The proposed modifications lead to some rather long and awkward 
> sentences.  For the same meaning, how about
>
> 4.2.3
>
> ...
> This is a PRIVATE message. If you are not the intended recipient, 
> please delete without copying and kindly advise us by e-mail of the 
> mistake in delivery. NOTE: Regardless of content, this e-mail shall 
> not operate to bind CSC to any order or other contract unless pursuant 
> to explicit written agreement or government initiative expressly 
> permitting the use of e-mail for such purpose.
>
>
>
> Subject: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common 
> abatemen algorithm
> ------------------------------------------------------------------------
>
>
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Sep 2014 16:02:20 -0500

Steve, am I correct in assuming the removal of the 2119 "MUST" was intentional?  (For the record, I agree--in this context it's a statement of fact, not a normative requirement.)

If so, I suggest changing it to something other than "must" to avoid confusion with MUST. For example,

" Since the "loss" abatement algorithm [crossref] is mandatory to implement, DOIC can always be enabled between these two endpoints."

On Sep 5, 2014, at 9:42 AM, Steve Donovan <[email-masked]> wrote:

> Maria Cruz,
> 
> I support the need for these changes.  I have a proposal for alternative wording below.
> 
> Regards,
> 
> Steve
> 
> The reporting node learns the capabilities of the reacting node when it receives the
> OC-Supported-Featuers AVP as part of any Diameter request message. At a minimum,
> the reacting node and reporting node must both the loss abatement algorithm defined in this document
> and, as a result, DOIC can always be enabled between these two endpoints.  See Section
> 4.1 ...
>> 
>> 
>> 
>>  Original text:
>> 
> ... Both the reacting and reporting nodes must support the loss abatement algorithm
> defined in this document.  As a result, DOIC behavior can always be enabled between

---

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Sep 2014 10:15:37 -0500

Ben,

I agree, this wording is better.

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 10 Sep 2014 14:17:15 +0000

Ben, Steve,
Proposed rewording is fine to me.
/MCruz

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: martes, 09 de septiembre de 2014 17:16
To: Ben Campbell
Cc: [email-masked]; Maria Cruz Bartolome
Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm

Ben,

Steve