Shepherd Writeup for draft-ietf-siprec-protocol, current version 14. Date of this writeup: February 20, 2015. Document Shepherd: Brian Rosen
(1) This document is Proposed Standard. The document header indicates Standards Track. This document defines a new protocol and thus is properly classified as ÒProposed StandardÓ.
(2) Document Announcement Write-Up:
This document describes how to use Session Initiation Protocol (SIP), Session Description Protocol (SDP) and Real Time Protocol (RTP) to record a SIP Communication Session (CS) that appears on a cooperating SIP UA. The protocol creates a SIP Recording Session between the Session Recording Client (SRC) and the Session Recording Server (SRS) and passes metadata about the session between the SRC and the SRS. The document also specifies extensions for user agents that are participants in a CS to receive recording indications and to provide preferences for recording.
Working Group Summary:
This document has had a relatively long gestation period in the working group, but there has been strong consensus on the direction and text of the document for some time. There were no notable disagreements within the working group over the development of the document. On the contrary, the only discussions were on how best to solve corner cases that occasionally arose as the document was going through the review process. The protocol conforms rather remarkably well to the requirements and architecture that was defined before serious work on the protocol began. This is noteworthy, as it rarely occurs.
There are multiple interoperable implementations of drafts of this protocol. Notably, the National Emergency Number Association (NENA) has included the protocol in itÕs Next Generation 9-1-1 standard, and has held an interoperability event where multiple implementations were tested. Feedback from the event has been incorporated in the draft. There are at least 8 implementations known to the document shepherd that are completed, in process, or planned.
Brian Rosen is the Document Shepherd. Alissa Cooper is the Responsible Area Director.
(3) I have completed a thorough review of the document and believe it is ready to be published.
(4) A number of knowledgeable people have reviewed the document and no significant concerns were raised. All minor issues have been resolved.
(5) This document describes a method to record a SIP session, which raises privacy concerns. The mechanism requires consent, and active participation at the Session Recording Client and the document includes mechanism to notify other participants in the Communications Session that it is being recorded. Therefore, it is not suitable for, and is not intended to be used for any form of legal intercept. The document has benefitted from advice from knowledgeable privacy experts including the responsible Area Director. Nevertheless, a thorough security review is appropriate.
(6) Other than the privacy issue raised above, neither the work group nor I have any concerns or issues.
(7) Each author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.
(8) Avaya, Inc. has filed an IPR disclosure that references this document (https://datatracker.ietf.org/ipr/1912/). The working group is satisfied that this IPR disclosure is not a problem for widespread implementation of the document.
(9) As with many IETF working groups, interest in finishing has flagged, and we did struggle to get sufficient reviews. However, we had strong concurrence within the larger working group that the document should be published. There were no dissents.
(10) There are no threatened appeals and no dissenters, strong or otherwise. As noted above, with session recording, there are always privacy concerns. Anyone who has raised such concerns has been satisfied that the document appropriately deals with the concerns.
(11) There are no nits other than the date, which will need to be updated in the IPR statement and the document.
(12) This document does not define any MIBs, media types or URNs, and thus no reviews for those items is needed.
(13) The references are properly divided into normative and informative sections.
(14) The document has a normative reference to the siprec metadata document, which is nearing completion and an informative reference to the ekt document.
(15) See (14) above.
(16) This document does not change the status of any RFCs; it defines a new protocol.
(17) This document describes several IANA actions, but all of them are simple additions to existing registries. It does register a new media type that will require the usual review.
(18) The document does not create any new registries.
(19) This document does not contain any XML, BNF, MIB or other formal language constructs. A companion document (-metadata) has the XML schemas this document deals with.