Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages

["TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]>]

Hi Steve

I am ok with the changes you proposed including  your modification  coming from  the Janet's remark.

Best regards

JJacques

De : DiME [mailto:[e-mail]] De la part de Janet P Gunn
Envoyé : lundi 24 mars 2014 15:12
À : Steve Donovan
Cc : DiME; [e-mail]
Objet : Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages

Fine with me

Janet

"DiME" <[e-mail]<mailto:[e-mail]>> wrote on 03/24/2014 09:42:06 AM:

> From: Steve Donovan <[e-mail]<mailto:[e-mail]>>
> To: [e-mail]<mailto:[e-mail]>
> Date: 03/24/2014 09:42 AM
> Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> Sent by: "DiME" <[e-mail]<mailto:[e-mail]>>
>
> Janet,
>
> Well, in the sense that the current overload condition caused the
> current abatement request, the wording is mostly correct.  I agree
> it can be made more clear.  It might be better if we changed the
> word condition to report.
>
> Steve

> On 3/21/14 4:10 PM, Janet P Gunn wrote:
> Just a question.
>
> In the phrase " it
>    applies the traffic abatement based on the commonly supported/selected
>    algorithm with the reporting node and the current overload condition."
>
> Is it really the "current overload CONDITION", or the "current
> abatement REQUESTED"?
>
> If the message is asking for a 10% reduction in traffic, that does
> not actually identify the "current overload condition".
>
>
> Janet
>
>
>
>
> From:        "dime issue tracker" <[e-mail]<mailto:[e-mail]>>
> To:        [e-mail]<mailto:[e-mail]>
> Cc:        [e-mail]<mailto:[e-mail]>
> Date:        03/21/2014 09:33 AM
> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> Sent by:        "DiME" <[e-mail]<mailto:[e-mail]>>
>
>
>
> #30: OC-Supported-Features AVP in answer messages
>
> Changes (by [e-mail]<mailto:[e-mail]>):
>
> * status:  new => closed
> * resolution:   => fixed
>
>
> Comment:
>
> We reached the tentative agreement in the DIME meeting on the following:
>
> OC-Supported-Features handling:
>
> Agreed: OC-Supported-Features AVP MUST be included in all answer messages
> (we had already agreed that it must be included in all request messages).
> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will be
> using;
> Agreed: Handling of other feature bits is defined in the extension drafts
>
> Based on this I believe we need the text changes outlined below.
>
> Let me know if I have missed any.
>
> If we agree on the text changes then we can close the issue and I'll
> update the document accordingly.
>
> Regards,
>
> Steve
>
> -----
>
> Section 5.3.2, paragraph 1:
>
> Change:
>
> The answer message
>    initiating endpoint MAY announce as many supported capabilities as it
>    has (the announced set is a subject to local policy and
>    configuration). However, at least one of the announced capabilities
>    MUST be the same as received in the request message.
>
>
> To:
>
> The reporting node MUST include the OC-Supported-Features AVP in all
> response messages for transactions where the request message included the
> OC-Supported-Features AVP.  The reporting node MUST announce support of
> the single algorithm that the reporting node will request the reacting
> node to use to mitigate overload instances.  The reporting node MUST NOT
> change the selected algorithm during a period of time that it is in an
> overload state and, as a result, is sending OC-OLR AVPs in answer
> messages.
>
>     Note: There will always be at least one algorithm supported by both
> the reacting and reporting nodes as all nodes that support DOIC must
> support the loss algorithm defined in this document.
>
> The handling of feature bits in the OC-Feature-Vector AVP that are not
> associated with overload abatement algorithms MUST be specified by the
> extension that defines the feature.
>
> Paragraph 2:
>
> Change:
>
> The answer message initiating endpoint MUST NOT include any overload
>    control solution defined AVPs into its answer messages if the request
>    message initiating endpoint has not indicated support at the
>    beginning of the created session (or transaction in a case of non-
>    session state maintaining applications). The same also applies if
>    none of the announced capabilities match between the two endpoints.
>
> To:
>
> The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
> AVP or any other overload control AVPs defined in extension drafts in
> response messages for transaction where the request message does not
> include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
> AVP in the request message indicates that the sender of the request
> message does not support DOIC.
>
> Section 5.5.2, Paragraph 1:
>
> Change:
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP or indirectly remembering the previously
>    used traffic abatement algorithm with the given reporting node.
>
> To: (removing the last portion of the last sentence)
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP.
>
> -----
>
> +1, with a minor suggested edit:
>
> On Mar 17, 2014, at 2:03 PM, Steve Donovan <[e-mail]<mailto:[e-mail]>>
> wrote:
>
> > Change:
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP or indirectly remembering the previously
> >    used traffic abatement algorithm with the given reporting node.
>
> > To: (removing the last portion of the last sentence)
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
>
> s/"commonly supported"/selected
>
> "Commonly supported" is no longer descriptive. There may be several
> commonly supported algorithm, but the reporting node selects just one.
>
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP.
> >
>
> --
> --------------------------------------+---------------------------
> Reporter:  [e-mail]<mailto:[e-mail]>  |       Owner:  Ulrich Wiehe
>     Type:  defect                    |      Status:  closed
> Priority:  major                     |   Milestone:
> Component:  draft-docdt-dime-ovli     |     Version:
> Severity:  Active WG Document        |  Resolution:  fixed
> Keywords:                            |
> --------------------------------------+---------------------------
>
> Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>
> dime <http://tools.ietf.org/wg/dime/>
>
> _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime
>
>

> _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime

> _______________________________________________
> DiME mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime