Skip to main content

Last Call Review of draft-ietf-siprec-architecture-08
review-ietf-siprec-architecture-08-genart-lc-housley-2013-09-23-00

Request Review of draft-ietf-siprec-architecture
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-10-01
Requested 2013-09-19
Authors Andrew Hutton , Leon Portman , Rajnish Jain , Ken Rehor
I-D last updated 2013-09-23
Completed reviews Genart Last Call review of -08 by Russ Housley (diff)
Genart Telechat review of -11 by Russ Housley (diff)
Secdir Last Call review of -08 by Derek Atkins (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-siprec-architecture by General Area Review Team (Gen-ART) Assigned
Reviewed revision 08 (document currently at 12)
Result Ready w/issues
Completed 2013-09-23
review-ietf-siprec-architecture-08-genart-lc-housley-2013-09-23-00
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-siprec-architecture-08
Reviewer: Russ Housley
Review Date: 2013-09-23
IETF LC End Date: 2013-10-01
IESG Telechat date: Unknown

Summary:  

Major Concerns:

The use of "required" in Section 3.2.4 is confusing to me.  It says:

   In a basic session involving only audio there are typically two audio
   /RTP streams between the two UAs involved transporting media in each
   direction.  When recording this media the two streams may be mixed at
   the SRC before being transmitted to the SRS or it may be required
   that the media streams are not mixed and are sent to the SRS as two
   separate streams.

Is this a requirement that the SRC imposes on the SRS?  Please clarify.


Minor Concerns:

The definitions include:

   Recording unaware User Agent (UA): A SIP User Agent that is unaware
   of SIP extensions associated with the Communication Session.  Such
   Recording unaware UA will be notified that a session is being
   recorded or express preferences as to whether a recording should be
   started, paused, resumed or stopped via some other means that is out
   of scope of SIPREC.

There is no definition of SIPREC.  Perhaps it could simply say:

   ... is out of scope for the SIP media recording architecture.

Note that "SIPREC" does occur a few other places in the document, and
this approach to the replacement seems to work for them too.

Of course, the alternative it to define SIPREC.


Section 5 talks about encryption of the media stream, but it does not
offer any suggestions about the protection of the stored media.  I
doubt that there is a simple bit of advice, but implementers should
be warned against strong protection of the media during transmission
and then providing no protection to the stored media.


Other Comments:

The introduction defines these two acronyms: Session Recording
Client (SRC) and the Session Recording Server (SRS).  However, they are
spelled out many times throughout the introduction.  These acronyms are
not really used until after the definitions section.  I suggest using
them throughout the document.


There is a period missing at the end of the first sentence in
Section 3.1.2.

In Section 	3.2.2, it says:

   o Identifies the sessions that is to be recorded. ...

This should say "sessions that are to be recorded".


There is a period missing at the end of the last bullet in
Section 3.2.2.