I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-overload-reqs-10 Reviewer: David L. Black Review Date: August 17, 2013 IETF LC End Date: August 16, 2013 IESG Telechat date: (if known) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes scenarios in which Diameter overload can occur and provides requirements for development of new overload control functionality in Diameter. It is well written, and the inclusion of scenarios in which overload can occur, both in terms of the relationships among types of Diameter nodes and actual mobile network experience is very helpful. I apologize for this review being a day late, as I've been on vacation for most of this draft's IETF Last Call period. Major issues: (none) Minor issues: (none) Nits/editorial comments: The following two comments could be minor issues, but I'm going to treat them as editorial, as I expect that they will be addressed in development of the actual overload functionality: a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. b) The draft, and especially its requirements in Section 7 are strongly focused on individual Diameter node overload. That's necessary, but overload conditions can be broader, affecting an entire service or application, or multiple instances of either/both, even if not every individual Diameter node involved is overloaded. A number of the requirements, starting with REQ 22 could be generalized to cover broader overload conditions. This (b) has implications for other requirements, e.g., REQ 13 should also be generalized beyond a single node to avoid increased traffic in an overload situation, even from a node that is not overloaded by itself. There are limits on what is reasonable here, as the desired overload functionality is TCP/SCTP- like reaction to congestion where individual actions taken by nodes based on the information they have (which is not the complete state of the network) results in an overall reduction of load. Section 1.2, 2nd paragraph: as network congestion, network congestion can reduce a Diameter nodes "nodes" -> "node's" Section 5, 1st paragraph: This inadequacy may, in turn, contribute to broader congestion collapse "collapse" is not the right word here - I suggest "issues", "impacts", "effects" or "problems". Section 7 The long enumerated list of requirements is not an easy read. It would be better if these could somehow be grouped by functional category, e.g., security, transport interactions, operational/administrative, etc. idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - this is fine, as the boilerplate has been appropriately modified for this draft that expresses requirements (as opposed to a draft that specifies a protocol). idnits 2.12.17 got confused by the 3GPP and GSMA Informative References. I assume that they're all sufficiently stable to be informative references. However, [TR23.843] is a work in progress, and should be noted as such in its reference - is this needed for any of the other 3GPP or GSMA references? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------