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

[Jouni Korhonen <[e-mail]>]

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.


10/9/2014 7:37 PM, Steve Donovan kirjoitti:
> 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:
>>
>> 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
>>
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>