Last Call Review of draft-ietf-dime-drmp-04
review-ietf-dime-drmp-04-genart-lc-shirazipour-2016-03-25-00

Request Review of draft-ietf-dime-drmp
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-03-24
Requested 2016-03-10
Other Reviews Genart Telechat review of -05 by Meral Shirazipour (diff)
Secdir Last Call review of -04 by Taylor Yu (diff)
Review State Completed
Reviewer Meral Shirazipour
Review review-ietf-dime-drmp-04-genart-lc-shirazipour-2016-03-25
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg13095.html
Reviewed rev. 04 (document currently at 07)
Review result Ready with Nits
Draft last updated 2016-03-25
Review completed: 2016-03-25

Review
review-ietf-dime-drmp-04-genart-lc-shirazipour-2016-03-25






I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.




 




For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.





 




 




Document:  draft-ietf-dime-drmp-04




Reviewer: Meral Shirazipour




Review Date: 2016-03-24




IETF LC End Date:  2016-03-24




IESG Telechat date: NA




 




 




Summary:




This draft is ready to be published as Standards Track RFC but I have some comments.




 




Major issues:




 




Minor issues:




-[Page 7], 




"The mechanism for how the agent determines which requests are




       throttled is implementation dependent and is outside the scope of  this document.





"




 




Shouldn’t all nodes handshake the mechanism to use to avoid countering each other’s throttling decision/effect?




 




-Security:




Security section is well written but not convincing that the method described in this draft is a viable solution specially for first responder and public safety scenarios.





Section 11.2 says DDOS is not an imminent thread but a few compromised nodes could send heavy load of high priority requests – I may be missing something here?




 




 




Nits/editorial comments:




-[Page 2], Please spell out DOIC at first use "Diameter Overload Indication Conveyance"




 




-[Page 3], second sentence would read better as:




old:




"For instance it might be considered important to reduce the




   probability of transactions involving first responders during a




   period of heavy signaling resulting from a natural disaster being




   throttled during overload scenarios.




"




new (suggested):




"For instance it might be considered important to reduce the




probability of transactions involving first responders being throttled





during overload scenarios caused for example by a period of heavy signaling





resulting from a natural disaster.




"




-[Page 3], "the DIOC reacting node", should it be DOIC?




 




-[Page 4], Please spell out AVP at first use (currently done in Section 9)




 




-[Page 6], "Platinum SLA the includes"--->"Platinum SLA that includes"




 




-comment on above sentence? (should we say in case net neutrality rules are not in place, ...." ?




 




-[Page 6], sentence below did not read well.




old:




"In this scenario it is requests with the same command code that have




different implied priorities.




 




"




 




new (suggested):




"In this scenario requests with the same command code have




different implied priorities.




"




 




-[Page 6], Please spell out ULR at first use




 




-[Page 7]




 




-[Page 7], [Page 8], and [Page 9] "non supportant"--->"non-

supporting

"





 




-[Page 12], "which requests are are"--->"which requests are"




 




-[Page 13], Please spell out TCP, SCTP, TLS, DTLS at first use




 




-[Page 14], "degrated"--->"degraded"




 




Best Regards,




Meral




---




Meral Shirazipour




Ericsson




Research




www.ericsson.com