Hi Russ, An update to this draft has been posted and I believe it addresses your comments. See http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-09.txt Regards Andy > -----Original Message----- > From: Russ Housley [mailto:housley@xxxxxxxxxxxx] > Sent: 23 September 2013 23:00 > To: draft-ietf-siprec-architecture.all@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Gen-ART review of draft-ietf-siprec-architecture-08 > > 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. >