Re: [Dime] Mirja Kühlewind's No Objection on draft-ietf-dime-agent-overload-10: (with COMMENT)

[Steve Donovan <[e-mail]>]

Mirja,

Thank you for your review.  Please see my comments inline.

Regards,

Steve

On 3/15/17 2:54 PM, Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dime-agent-overload-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> One rather important comment:
> While the security considerations section describes a possible attack, it
> does not say anything about how to handle this attack and the actually
> impact this attack might have. Please add more text!
I've added the following: "The impacts of this attack, as well as the 
mitigation strategies, are the same as outlined in RFC7683.
>
> And then some mostly editorial high level comments:
> All in all, I had a rather hard time reading this document because it
> seems on the one hand sightly over-specified and over structured, while
> not giving very concrete guidance in some cases.
>
> E.g. in section 5.2.5;
>   "In the case that the OCS entry validity duration expires or has a
>     validity duration of zero ("0"), meaning that if the reporting node
>     has explicitly signaled the end of the overload condition then
>     abatement associated with the OCS entry MUST be ended in a
> controlled
>     fashion."
>     I don't think normative language is needed here because there is no
> impact of interoperation. But then is does't explain what "in a
> controlled fashion means". So I wouldn't even know how to implement that
> MUST correctly.
The draft is an extension of RFC7683 and, as such, doesn't always repeat 
this from that RFC.  There is wording in RFC7683 that discusses what a 
controlled fashion means.
>
> Another example in section 4:
> " In this scenario, when doing abatement on the
>     PEER report, the reacting node SHOULD take into consideration the
>     number of messages already throttled by the handling of the HOST/
>     REALM report abatement."
> How to take that into consideration? And why is this normative?
The reacting node is the one doing the abatement on both the HOST/REALM 
report and the PEER report. As such, it has all of the information it 
needs to adjust the abatement for the PEER report based on what 
abatement has already happened based on the HOST/REALM reports.

It is normative to ensure similar abatement behavior across all Diameter 
nodes implementing this mechanism.
>
> Or here in section 5.2.3:
> "When a reacting node receives an OC-OLR AVP with a report type of
>     peer it MUST determine if the report was generated by the Diameter
>     peer from which the report was received.
>
>     If a reacting node receives an OC-OLR AVP of type peer and the
>     SourceID matches the DiameterIdentity of the Diameter peer from
> which
>     the response message was received then the report was generated by a
>     Diameter peer."
> Why don't you just say the following:
> "When a reacting node receives an OC-OLR AVP with a report type of
>     peer it MUST determine that the SourceID matches the DiameterIdentity
> of the Diameter peer from which
>     the response message was received."
That would have been another way of specifying the requirement.  I'm 
more comfortable with sticking with what has already been agreed to by 
the working group.
>
> Also the indentation used is sometimes confusing. In some cases you
> should probably really use real listings with bullet points.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime