Hi Russ, could you please have a look at this new revision of the draft and let the authors know whether or not it addresses your concerns? Thanks, Gonzalo On 18/10/2013 1:59 PM, Hutton, Andrew wrote: > 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. >> > > >