Re: [Gen-art] Gen-art telechat review of draft-ietf-dime-ovlli-09

[Steve Donovan <[e-mail]>]

Elwyn,

I will be pushing version 10 soon.  In it I have made the following changes:

I added the reference in section 5.2.1.1 (apologies for missing it the 
first time).

I also added the following paragraph in section 4.2:

           While it should only be done in exceptional
           circumstances and not during an active occurrence of overload,
           a reacting node that wishes to transition to a
           different abatement algorithm can stop advertising support 
for the
           algorithm indicated by the reporting node, as long as support
           for the loss algorithm is always advertised.

I also corrected an editorial issue in section 5.1.2 pointed out by Lionel.

Regards,

Steve

On 8/19/15 8:31 AM, Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-dime-ovli-09.txt
> Reviewer: Elwyn Davies
> Review Date: 2015/08/19
> IETF LC End Date:
> IESG Telechat date: 2015/08/20
>
> Summary: Ready. Thanks for addressing my last call comments (except 
> one minor change got missed - see below).  A good document.  
> [Apologies for somewhat late review - in inter-continental airport 
> limbo.]
>
> Major issues:
> None
>
> Minor issues:
> s4.2:  I commented on the possibility of turning off an abatement 
> algorithm at last call.   Having thought this through, I assume that 
> in general it would be sufficient for a reacting node to stop 
> announcing its capability.  If this is correct it might be worth 
> mentioning this (as with changing presumably this would be an 
> exceptional case but could happen).  I don't think that anything very 
> special would have to be done with stateful algorithms but maybe a 
> comment would help.
>
> Nits/editorial comments:
> s5.2.1.1:  Adding a pointer to s7.3 was discussed and agreed but 
> hasn't happened.
> _________________