Gen-ART review of draft-ietf-siprec-architecture-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]