Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-11
Yes
(Spencer Dawkins)
(Stephen Farrell)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Suresh Krishnan)
Recuse
Note: This ballot was opened for revision 09 and is now closed.
Spencer Dawkins Former IESG member
Yes
Yes
(for -10)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(for -09)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -10)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2017-03-16 for -10)
Unknown
Below is the OPS DIR review by Will. ** Editorial ** *Section 2, page 4 > A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 > Diameter Agent. s/ RFC6733/ [RFC6733] Similar changes should also be made in this section to get consistent with section 1 and the last sentence in section 2(therein you were using [RFC6733]). * Section 3.1.1, page 4: > +-+ +-+ +-+ > |c|----|a|----|s| > +-+ +-+ +-+ Though I can easily guess what does “c, a, s” mean here, I still suggest to put full words or at least add a sentence below the figure to explain. The same issue should be fixed in all the figures below in entire section 3. * Section 3.1.2, page 6: > In the case where one of the agents in the above scenario becomes > overloaded s/ scenario becomes/ scenarios become If I understand correctly , here you were referring to two scenarios above? > When the client has an active and a standby connection to the two > agents then an alternative strategy for responding to an overload > report from an agent is to change to standby connection to active and > route all traffic through the new active connection. I would suggest to split this sentence in case of misunderstanding. * Section 3.1.3, page 7: > Handling of overload of one or both of agents a11 or a12 in this case > is equivalent to that discussed in section 2.2. Tried hard to find section 2.2, but there is no such section. * Section 5.1.1, page 8: > When sending a Diameter request a DOIC node that supports the > OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. Full name of AVP should be put into terminology.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -10)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -10)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-03-15 for -10)
Unknown
(Resending because I forgot one more high-level comment; see at the bottom.) 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! 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. 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? 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." Also the indentation used is sometimes confusing. In some cases you should probably really use real listings with bullet points. Please also double-check all normative language: as indicated above there are some cases where the normative language is probably not really needed and there are other cases where an additional upper letter MUST or SHOULD would make things clearer.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -10)
Unknown
Ben Campbell Former IESG member
Recuse
Recuse
(2017-03-14 for -10)
Unknown
While I am not a co-author per se, the author is an immediate team-mate.