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: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
Re: Gen-ART review of draft-ietf-dime-overload-reqs-11
Thanks, David! On Aug 27, 2013, at 11:40 AM, Black, David david.bl...@emc.com wrote: 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:
Re: Gen-ART review of draft-ietf-dime-overload-reqs-11
Great. Thanks! - Jouni On Aug 27, 2013, at 7:40 PM, Black, David david.bl...@emc.com wrote: 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
