Subject: [Dime] Prep for next weeks DIME interim meeting

From: Steve Donovan <[email-masked]>
Date: Thu, 09 Oct 2014 10:26:58 -0500

All,

As we prepare for next weeks interim meeting, please remember to use the 
following as the source document:

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-04.txt

I've attached a copy for everyone's convenience.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 09 Oct 2014 11:37:25 -0500

Here's a cleaner version of the .txt document.

Steve

On 10/9/14, 10:26 AM, Steve Donovan wrote:
> All,
>
> As we prepare for next weeks interim meeting, please remember to use 
> the following as the source document:
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 13 Oct 2014 12:06:43 +0000

Hello Steve,

I would like to know if you have already considered all the comments I made to version .03, and if not, what has been your proposal. If not considered, I would need to go on then using version .03
A part from that, it would be very helpful if you could provide track changes on the doc or the diff file.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: jueves, 09 de octubre de 2014 17:27
To: [email-masked]
Subject: [Dime] Prep for next weeks DIME interim meeting

All,

As we prepare for next weeks interim meeting, please remember to use the following as the source document:

Regards,

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 15 Oct 2014 23:36:16 +0300

Hi

I had a quick read on the document. This is just mostly for editorials.
There are still places where the same reacting and reporting node 
behavior is told again and again. This is generally error prone and 
maybe we should check how to possible avoid the repetition..

- Jouni

---------------------------------------------

** Section 1 and 3.2

o s/refered/referred

** Section 3

    namely the "loss" algorithm Section 5).  Future specifications may
                             ^^^^^^
    unknown AVPs through unmolested.  The report types described in this
                        ^^^^^^^^^^^^
o The wordind is a bit "funny". I would change to unchanged, for example.

o s/fulfill/fulfil

** Section 3.3

o s/overlaod/overload
o s/Validaty/Validity

** Section 3.4

o s/occurances/occurrences

** Section 3.6.2

o favorable? Should it be "favourable"?

** Section 4.1.2

o s/reqeust/request

** Section 4.1.3.  Agent Behavior (Normative)

    Editor's note -- Need to add this section.
     ^^^^^^^^

o Maybe just add a forward note to future specs?

** Section 4.2.1.2

o agree with the editor's note. there is no way how the reporting
   node would know when the OLR has for sure time out in reacting node.
   Recommend removing the paragraph.

** Section 4.2.1.3

o The text starts using "app-id", "Orig-host" etc here. Use correct
   wording here like "application-id", "Origin-Host" etc.

o "Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration)."

    Reception time of what? A quick read here leads to time delta of 0.

o Agree with the editor's note. Propose using the text in the editor's
   note as-is.

o Regarding the OCS state, use the same language as in previous
   paragraphs. For example use "Algorithm" not "Alg" etc.

o Agree with the editor's note on sending update with validity
   duration 0.

** Section 4.2.3.

   these DOIC nodes See Section 4.1 for further discussion on the
                 ^^^^^

** Section 4.2.4

o Add a note that this is for future specs?

** Section 4.3

    The extention may also define new AVPs for use in DOIC Capability
          ^^^^^^
    Anouncement and for use in DOIC Overload reporting.  These new AVP
     ^^^^

    existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED.
                                                      ^^^^^^^^^^^^^^^^^^
o RFC2119 language issue. Use e.g. "..SHOULD NOT be used."

** Section 5.2

o I think this section can be removed.

** Section 5.4

o I think the editor's note is not needed and enough guidance is
   already given for implementers.

       The goal of this behavior is to reduce the probability of overload
       condition thrashing where an immediate transition from 100%
       reduction to 0% reduction results in the reporting node moving
       quickly back into an overload condition.

o Use normal indentation..

** Section 6

    When added to existing commands, both OC-Feature-Vector and OC-OLR
                           ^^^^^^^^
o Or rather applications?

** Section 6.1

o Agree with the editor's note and propose removeing the sentence.

** Section 6.3.

o Regarding the editor's note I propose that the latter OC-OLR is
   disgarded and the event is logged.