Skip to main content

Last Call Review of draft-ietf-bliss-shared-appearances-
review-ietf-bliss-shared-appearances-secdir-lc-atkins-2012-06-28-00

Request Review of draft-ietf-bliss-shared-appearances
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-05
Requested 2012-06-19
Authors Alan Johnston , Mohsen Soroushnejad , Venkatesh Venkataramanan
I-D last updated 2012-06-28
Completed reviews Genart Last Call review of -?? by David L. Black
Genart Telechat review of -13 by David L. Black (diff)
Secdir Last Call review of -?? by Derek Atkins
Assignment Reviewer Derek Atkins
State Completed
Request Last Call review on draft-ietf-bliss-shared-appearances by Security Area Directorate Assigned
Result Ready
Completed 2012-06-28
review-ietf-bliss-shared-appearances-secdir-lc-atkins-2012-06-28-00
Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   This document describes the requirements and implementation of a
   group telephony feature commonly known as Bridged Line Appearance
   (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
   Appearance (SCA).  When implemented using the Session Initiation
   Protocol (SIP), it is referred to as shared appearances of an Address
   of Record (AOR) since SIP does not have the concept of lines.  This
   feature is commonly offered in IP Centrex services and IP-PBX
   offerings and is likely to be implemented on SIP IP telephones and
   SIP feature servers used in a business environment.  This feature
   allows several user agents (UAs) to share a common AOR, learn about
   calls placed and received by other UAs in the group, and pick up or
   join calls within the group.  This document discusses use cases,
   lists requirements and defines extensions to implement this feature.

The first sentence of the first paragraph of the Security Considerations
section is missing a reference.  It says:

   ...
   semantics provided by [RFC3261], Event Package for Dialog State as
   define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
   [RFC3903], ...

The "define in" should be "defined in", and needs a place where it is
defined.

The second paragraph says that dialog state information and dialog
identifiers MAY be encrypted, but doesn't talk about why one would
choose not to encrypt it.

Similarly, the last paragraph provides guidance on waiting for
confirmed seizures, but does not explain the details about why one must
do so.

Both of these might be obvious to writers, but to someone reading the
document they are not clear.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant