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:
Technical Summary: 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. Document
Quality: 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. Personnel: 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.