Last Call Review of draft-ietf-bliss-call-completion-18
review-ietf-bliss-call-completion-18-genart-lc-moriarty-2013-01-05-00

Request Review of draft-ietf-bliss-call-completion
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-12-17
Requested 2012-12-06
Authors Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev
Draft last updated 2013-01-05
Completed reviews Genart Last Call review of -18 by Kathleen Moriarty (diff)
Secdir Last Call review of -18 by Derek Atkins (diff)
Assignment Reviewer Kathleen Moriarty
State Completed
Review review-ietf-bliss-call-completion-18-genart-lc-moriarty-2013-01-05
Reviewed rev. 18 (document currently at 19)
Review result Ready with Nits
Review completed: 2013-01-05

Review
review-ietf-bliss-call-completion-18-genart-lc-moriarty-2013-01-05



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 wait for direction from your document shepherd




or AD before posting a new version of the draft.




 




Document: draft-ietf-bliss-call-completion-18




Reviewer: Kathleen Moriarty




Review Date: 1/4/13




IETF LC End Date: a while ago




IESG Telechat date: 1/10/13




 




Summary: The draft is very well written and ready for publication.  I listed a couple of nits and a possible consideration to add to the security section on privacy/safety.




 




Major issues:




 




Minor issues:




 




Nits/editorial comments:




 




Section 3, the definition for CCE is the only one that does not end with a period, consider adding one.




 




Security Section, start of second paragraph on page 30 (DoD should be DoS):




Change from: “In order to prevent DoD attacks”




To: “In order to prevent DoS attacks”




 




In the Security Section, there is mention of privacy issues only in relation to violations of the expected behavior listed in that section.  I think it would be helpful to describe some of the possible privacy
issues and why you may or may not want to put in protections in place as safety could be affected.  For instance, if the options in RFC3261 were used to prevent a subscription (white list of allowed callers), you may not receive a robo call with emergency messages
from your town, school, etc.  On the other hand, you may want to prevent others from being subscribers to know when you are at home (too hard to do with a black list and a white list could block other important calls).  Or this is just plain tricky…