Subject: [Dime] Ulrich suggested changes 18, 19, 20 and 21

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Dec 2014 08:19:56 -0600

Ulrich,

I support the suggested changes in your suggested changes 18, 19, 20 and 21:

Section 4.3, 3rd paragraph:
Existing text:
    The extension MAY define new AVPs for use in DOIC Capability
    Announcement and for use in DOIC Overload reporting.  These new AVPs
    SHOULD be defined to be extensions to the OC-Supported-Features and
    OC-OLR AVPs defined in this document.
Comment: It is not necessary for a new AVP to be an extension to both the OC-Supported-Features AVP and the OC-OLR AVP.
Proposal: Replace the paragraph with:
    The extension MAY define new AVPs for use in DOIC Capability
    Announcement and for use in DOIC Overload reporting.  These new AVPs
    SHOULD be defined to be extensions to the OC-Supported-Features and/or
    OC-OLR AVPs defined in this document.

Section 5.1, 9th paragraph:
Existing text:
    4.  The reacting node determines if overload abatement treatment
        should be applied to the request.  One approach that could be
        taken for each request is to select a random number between 1 and
        100.  If the random number is less than the indicated reduction
        percentage then the request is given abatement treatment,
        otherwise the request is given normal routing treatment.
Comment:The maths is wrong.
Proposal: Replace the paragraph with:
    4.  The reacting node determines if overload abatement treatment
        should be applied to the request.  One approach that could be
        taken for each request is to select a random number between 1 and
        100.  If the random number is less than or equal to the indicated
        reduction percentage then the request is given abatement treatment,
        otherwise the request is given normal routing treatment.

Section 5.3, 4th paragraph:
Existing text:
    When applying overload abatement treatment for the load abatement
    algorithm, the reacting node MUST abate the requested percentage of
    requests that would have otherwise been sent to the reporting host or
    realm.
Comment: probably a typo.
Proposal: Replace the paragraph with:
    When applying overload abatement treatment for the loss abatement
    algorithm, the reacting node MUST abate the requested percentage of
    requests that would have otherwise been sent to the reporting host or
    realm.

Section 5.3, 6th paragraph:
Existing text:
    If the reacting node does not receive an OLR in messages sent to the
    formerly overloaded node then the reacting node SHOULD slowly
    increase the rate of traffic sent to the overloaded node.
Comment: confusing.
Proposal: Replace paragraph with:
    If the reacting node does not receive an OLR in response to messages
    sent to the formerly overloaded node then the reacting node SHOULD
    slowly increase the rate of traffic sent to the overloaded node.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 16:06:55 -0600

> On Dec 9, 2014, at 8:19 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 

"And/or" is an awkward construct. How about just "or"?  I think the context makes it pretty clear that it's not "xor".

[...]

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Dec 2014 11:33:48 +0000

Ok for me to say just "or"
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Wednesday, December 10, 2014 11:07 PM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Ulrich suggested changes 18, 19, 20 and 21

[...]

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