The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC.
Thanks, --David > -----Original Message----- > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: Thursday, August 22, 2013 4:50 PM > To: Black, David > Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; > d...@ietf.org; bcla...@cisco.com > Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 > > Hi David, > > We agree on all your points, and will make the updates in the next version, > pending shepherd instructions. > > Thanks! > > Ben. > > On Aug 22, 2013, at 2:50 PM, "Black, David" <david.bl...@emc.com> wrote: > > > Hi Eric, > > > > This looks good - comments follow ... > > > >>> 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. > >> > >> We agree with this. The thinking here was that we didn't want to specify > >> this > >> in a way that would be specific to a particular type of mechanism. It > >> might > >> not hurt to state that assumption, either as a note on Req 27 or in the sec > >> considerations. > > > > That would be good to add as a note on REQ 27. > > > >> The intent was very much as you say, where requirements on individual node > >> capabilities are hoped to result in better overall system behaviors. There > >> are > >> also some requirements that are stated more at the system level (e.g. 7 and > >> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how > >> insufficient server capacity at a cluster of servers behind a Diameter > >> agent > >> can be treated as if the agent itself was overloaded. > >> > >> On the other hand, any mechanism we design will have to focus on actions of > >> individual nodes, so the numbered requirements tend to focus on that. I'm > >> not > >> sure where to change the balance here--do you have specific suggestions? > > > > I noted this as editorial rather than a minor issue, as I was mostly > > concerned > > that the actual design work will be informed by a sufficient architectural > > "clue" > > that the goal is "better overall system behaviors", which your response > > indicates > > will definitely be the case ;-). > > > > Rather than edit individual requirements, how about adding the following > > sentence > > immediately following the introductory sentence in Section 7?: > > > > These requirements are stated primarily in terms of individual node > > behavior to inform the design of the improved mechanism; > > that design effort should keep in mind that the overall goal is > > improved overall system behavior across all the nodes involved, > > not just improved behavior from specific individual nodes. > > > >>> This inadequacy may, in turn, contribute to broader congestion collapse > >>> > >>> "collapse" is not the right word here - I suggest "issues", "impacts", > >>> "effects" or "problems". > >> > >> We are fine with any of those alternatives. How about impacts. > > > > That's fine. FWIW, "congestion collapse" has a specific (rather severe) > > meaning over in the Transport Area, and that meaning was not intended here. > > > >> 23.843 is the least stable reference. I don't have any issue with pointing > >> that out. The part of it we are referencing is historical front matter > >> though. > > > > I'd note the reference as work in progress, and put the statement about > > stable > > front matter (historical is a bad work to use here) in the body of the draft > > that cites the reference. > > > >> I tried the web and downloaded versions of 2.12.17 and was not able to get > >> the > >> warnings you saw (about the references). What did it say? > > > > Sorry, I didn't mean to send you on a wild goose chase :-). The idnits > > confusion > > manifested right at the top of the output, where everyone ignores it ... > > > > Attempted to download rfc272 state... > > Failure fetching the file, proceeding without it. > > > > You didn't reference RFC 272, so that output's apparently courtesy of idnits > > misinterpreting this reference: > > > > 1195 [TS29.272] > > 1196 3GPP, "Evolved Packet System (EPS); Mobility > > Management > > 1197 Entity (MME) and Serving GPRS Support Node (SGSN) > > related > > 1198 interfaces based on Diameter protocol", TS 29.272 > > 11.4.0, > > 1199 September 2012. > > > > I was amused :-). > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Eric McMurry [mailto:emcmu...@computer.org] > >> Sent: Thursday, August 22, 2013 3:06 PM > >> To: Black, David > >> Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); > >> ietf@ietf.org; d...@ietf.org; bcla...@cisco.com > >> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 > >> > >> Hi David, > >> > >> Thank you for the review. Your time and comments are appreciated! > >> > >> comments/questions inline. > >> > >> > >> Eric > >> > >> > >> > >> On Aug 17, 2013, at 9:18 , "Black, David" <david.bl...@emc.com> wrote: > >> > >>> > >>> 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. > >> > >> We agree with this. The thinking here was that we didn't want to specify > this > >> in a way that would be specific to a particular type of mechanism. It > might > >> not hurt to state that assumption, either as a note on Req 27 or in the sec > >> considerations. > >> > >>> > >>> 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. > >> > >> The intent was very much as you say, where requirements on individual node > >> capabilities are hoped to result in better overall system behaviors. There > are > >> also some requirements that are stated more at the system level (e.g. 7 and > >> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how > >> insufficient server capacity at a cluster of servers behind a Diameter > agent > >> can be treated as if the agent itself was overloaded. > >> > >> On the other hand, any mechanism we design will have to focus on actions of > >> individual nodes, so the numbered requirements tend to focus on that. I'm > not > >> sure where to change the balance here--do you have specific suggestions? > >> > >>> > >>> Section 1.2, 2nd paragraph: > >>> > >>> as network congestion, network congestion can reduce a Diameter nodes > >>> > >>> "nodes" -> "node's" > >> > >> good catch. > >> > >>> > >>> 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". > >> > >> We are fine with any of those alternatives. How about impacts. > >> > >>> > >>> 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. > >> > >> agree. It is actually in sections in the XML (denoted by comments), we > just > >> did not promote those to visible sections in the txt. I recall there being > >> some issue with xml2rfc and numbering, but now that the numbers are set, > this > >> would not be hard to do. > >> > >> > >>> > >>> 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? > >> > >> 23.843 is the least stable reference. I don't have any issue with pointing > >> that out. The part of it we are referencing is historical front matter > >> though. > >> > >> > >> I tried the web and downloaded versions of 2.12.17 and was not able to get > the > >> warnings you saw (about the references). What did it say? > >> > >> > >>> > >>> 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.bl...@emc.com Mobile: +1 (978) 394-7754 > >>> ---------------------------------------------------- > >>> > >> > > >
