And the -12 version is likewise ready for publication as an Informational RFC. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, August 27, 2013 12:41 PM > To: Ben Campbell > Cc: Eric McMurry; General Area Review Team (gen-art@xxxxxxxx); ietf@xxxxxxxx; > dime@xxxxxxxx; bclaise@xxxxxxxxx; Black, David > Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11 > > 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:ben@xxxxxxxxxxx] > > Sent: Thursday, August 22, 2013 4:50 PM > > To: Black, David > > Cc: Eric McMurry; General Area Review Team (gen-art@xxxxxxxx); > ietf@xxxxxxxx; > > dime@xxxxxxxx; bclaise@xxxxxxxxx > > 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.black@xxxxxxx> 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:emcmurry@xxxxxxxxxxxx] > > >> Sent: Thursday, August 22, 2013 3:06 PM > > >> To: Black, David > > >> Cc: ben@xxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx); > > >> ietf@xxxxxxxx; dime@xxxxxxxx; bclaise@xxxxxxxxx > > >> 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.black@xxxxxxx> 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.black@xxxxxxx Mobile: +1 (978) 394-7754 > > >>> ---------------------------------------------------- > > >>> > > >> > > > > >