Session Recording Protocol
draft-ietf-siprec-protocol-18

[Ballot comment]

Thanks for clearing up my discuss points.

old stuff below.

I had a discuss point that said: "5.3: How does a UA know if
it's preference to not be recorded has been ignored?"
Maybe there's a missing timer there.

I also had a discuss point that said:
I'll clear once you answer: but wouldn't it be easier
all around to just mandate use of mutually authenticated
TLS between SRC and SRS in all cases?  (Even if some
hop-by-hop stuff is needed when there are proxies between
SRC and SRS.) Also - how is it ok to ever not re-encrypt
the media in the RS since if you do not, anyone from the
CS who has the right session key can send the SRS bogus
packets that it'll accept.

[Ballot comment]
Changing from rs-metadata-request to rs-metadata with XML content resolves the issue I wanted to discuss, so I'm clearing that.  Thanks for the change, and for addressing my non-blocking comments as well.  I'll leave one non-blocking comment below, but it is non-blocking -- no discussion needed, and if you want to leave the text as it is, that's fine.

-- Section 8.2.1.1 --

  UAs may receive multiple sets of RTCP Receiver Reports, one or more
  from other UAs participating in the CS, and one from the SRS
  participating in the RS.  A UA SHOULD process the RTCP Receiver
  Reports from the SRS if it is recording-aware.

Is it worth mentioning what the UA is likely to do with the reports from other UAs (just for information, without 2119 words)?  Would the UA generally process them too?  Ignore them?  Doesn't matter?  Is there any advantage one way or another, or any advice that would be useful for implementors to have?

[Ballot discuss]

(1) cleared

(2) 12.2: Thanks for fixing up the ekt reference. I still
would like to know how, in a case where the recording
is for audit/compliance purposes, one can ever allow
the RS to not be re-encrypted since that creates the
potential for the CS peers to fake the traffic to the RS.

(3) cleared

[Ballot comment]

I had a discuss point that said: "5.3: How does a UA know if
it's preference to not be recorded has been ignored?"
Maybe there's a missing timer there.

I also had a discuss point that said:
I'll clear once you answer: but wouldn't it be easier
all around to just mandate use of mutually authenticated
TLS between SRC and SRS in all cases?  (Even if some
hop-by-hop stuff is needed when there are proxies between
SRC and SRS.) Also - how is it ok to ever not re-encrypt
the media in the RS since if you do not, anyone from the
CS who has the right session key can send the SRS bogus
packets that it'll accept.

[Ballot comment]

[Thanks for addressing my second and third discuss points. I've removed them from the discuss. We've discussed my third DISCUSS point, so I've cleared.]

The reference to 7245 is informational. Do you expect that a reader/implementor could understand/implement this draft without understanding the architecture and terminology from that RFC? The same applies for 3550--I'm skeptical that one could implement this draft without understanding RTP.

-- Figure 1: The text says the flow is basically the same whether the SRC is in an endpoint or separate. This may be logically true, but the flow really would change--none of of the flow between UA(A) and SRC would exist.

-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS" reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add some motivation as to why this draft seems to prefer UPDATE.

-- 5.3: It seems odd to me that the SRC can ignore an explicit preference not to record. Wouldn't it be better just to refuse to complete/accept the call, if some policy overrides the end-user's preference?

-- Figure 3: If the UA prefers not to be recorded, shouldn't it express that at setup time, rather than wait for the SRC to indicate recording is happening? As shown, this almost guarantees a bit of media will be recorded. (Seems like there should be some guidance about this in the text.) The last paragraph of 6.1.2 seems to reinforce the problem by suggesting the participant might base the decision to express a preference on a tag that is optional for the SRC to send in the first place.

-- 6.3, last paragraph: It seems odd that the requirement to render a recording indicator be lower for a media server than for other UAs. This seems to circumvent user notification in one of the most common uses of recording these days.

-- 9.1 : The last bullet seems to be a motivation to not send metadata at all, which is expressly forbidden in the first paragraph.

-- 9.2: The use of  the content-type value as the sole indicator that the an UPDATE request should be interpreted as an request for a metadata snapshot update is rather odd.  If you end up with new kinds of metadata requests in the future, does each one get it's own media-type?

-- 12: If this doc is to depend on the security considerations in 6341, that needs to be a normative reference--which is a bit of a pain because I think it's an informational RFC.

-- 12.1:
"recording session uses TLS" -- I assume that's for SIP? Also It's worth discussing how mutual authentication applies if the SRC is in an end-user device. Is it expected to have a client cert? No option to use  SIP identity?

Also, I'm a bit uncomfortable assuming devices in the same administrative domain automatically trust each other. It might be better to say "If they trust each other..."

-- 12.2:

I get quite a bit of heartburn out of making Security Descriptions MTI and dtls-srtp optional. I guess I may have to hold my nose on this one.

Editorial:

-- 4: 2nd paragraph: " ... does not represent the protocol"
and first bullet: "Delivering recorded media in real-time as the CS media"

I don't understand what either of those mean.

-- 5.1, 2nd paragraph: "B2BUA to bridge
the media between UA(A) and UA(B)"

Is there a reason not to use the terminology from RFC 7092? (e.g. “relay” or “terminate” media)?

-- 7.3.1: The normative language in the first paragraph is redundant to similar language in 6.3.

[Ballot discuss]
I am concerned that this draft allows the recording session to downgrade security from the communication session. It says "SHOULD NOT", but then explicitly allows for the downgrade when the SRC and SRS are in the same administrative domain. This seems to create a whole new "last hop exception" for media, similar to the one for SIPS that we took so many years to deprecate. (Except it's worse because the potentially insecure hop goes to an endpoint not necessarily expected to be a party to the media.)

[2nd and 3rd points cleared]

[Ballot discuss]
I am concerned that this draft allows the recording session to downgrade security from the communication session. It says "SHOULD NOT", but then explicitly allows for the downgrade when the SRC and SRS are in the same administrative domain. This seems to create a whole new "last hop exception" for media, similar to the one for SIPS that we took so many years to deprecate. (Except it's worse because the potentially insecure hop goes to an endpoint not necessarily expected to be a party to the media.)

[Ballot comment]

[Thanks for addressing my second and third discuss points. I've removed them from the discuss.]

The reference to 7245 is informational. Do you expect that a reader/implementor could understand/implement this draft without understanding the architecture and terminology from that RFC? The same applies for 3550--I'm skeptical that one could implement this draft without understanding RTP.

-- Figure 1: The text says the flow is basically the same whether the SRC is in an endpoint or separate. This may be logically true, but the flow really would change--none of of the flow between UA(A) and SRC would exist.

-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS" reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add some motivation as to why this draft seems to prefer UPDATE.

-- 5.3: It seems odd to me that the SRC can ignore an explicit preference not to record. Wouldn't it be better just to refuse to complete/accept the call, if some policy overrides the end-user's preference?

-- Figure 3: If the UA prefers not to be recorded, shouldn't it express that at setup time, rather than wait for the SRC to indicate recording is happening? As shown, this almost guarantees a bit of media will be recorded. (Seems like there should be some guidance about this in the text.) The last paragraph of 6.1.2 seems to reinforce the problem by suggesting the participant might base the decision to express a preference on a tag that is optional for the SRC to send in the first place.

-- 6.3, last paragraph: It seems odd that the requirement to render a recording indicator be lower for a media server than for other UAs. This seems to circumvent user notification in one of the most common uses of recording these days.

-- 9.1 : The last bullet seems to be a motivation to not send metadata at all, which is expressly forbidden in the first paragraph.

-- 9.2: The use of  the content-type value as the sole indicator that the an UPDATE request should be interpreted as an request for a metadata snapshot update is rather odd.  If you end up with new kinds of metadata requests in the future, does each one get it's own media-type?

-- 12: If this doc is to depend on the security considerations in 6341, that needs to be a normative reference--which is a bit of a pain because I think it's an informational RFC.

-- 12.1:
"recording session uses TLS" -- I assume that's for SIP? Also It's worth discussing how mutual authentication applies if the SRC is in an end-user device. Is it expected to have a client cert? No option to use  SIP identity?

Also, I'm a bit uncomfortable assuming devices in the same administrative domain automatically trust each other. It might be better to say "If they trust each other..."

-- 12.2:

I get quite a bit of heartburn out of making Security Descriptions MTI and dtls-srtp optional. I guess I may have to hold my nose on this one.

Editorial:

-- 4: 2nd paragraph: " ... does not represent the protocol"
and first bullet: "Delivering recorded media in real-time as the CS media"

I don't understand what either of those mean.

-- 5.1, 2nd paragraph: "B2BUA to bridge
the media between UA(A) and UA(B)"

Is there a reason not to use the terminology from RFC 7092? (e.g. “relay” or “terminate” media)?

-- 7.3.1: The normative language in the first paragraph is redundant to similar language in 6.3.

[Ballot discuss]

(1) cleared

(2) 12.2: Why is a 2011 ([I-D.ietf-avt-srtp-ekt]) expired
I-D ok as the method for supporting DTLS-SRTP for the CS,
esp when DTLS-SRTP is our currently favoured method for
handing WebRTC security? When is that going to be finished?
On what basis is that an informative and not normative
reference? And is that reference ever likely to be
standardised? (Given that it seems to be a form of TLS MitM
- is that fair?) Perhaps it'd be better to just admit
that re-encryption is needed and get over it?

(3) I'll clear once you answer: but wouldn't it be easier
all around to just mandate use of mutually authenticated
TLS between SRC and SRS in all cases?  (Even if some
hop-by-hop stuff is needed when there are proxies between
SRC and SRS.) Also - how is it ok to ever not re-encrypt
the media in the RS since if you do not, anyone from the
CS who has the right session key can send the SRS bogus
packets that it'll accept.

[Ballot comment]

I had a discuss point that said: "5.3: How does a UA know if
it's preference to not be recorded has been ignored?"
Maybe there's a missing timer there.

[Ballot comment]
I support Stephen's discuss.  Also, I don't see a minimum version specified for TLS, right now, it's 1.2.  Is there any reason that can't be added.  The text on cipher suites is good, but if you'd like to have a pointer to the recommended ones, the TLS BCP has them listed and that can be referenced as well, RFC7525.

[Ballot comment]
As mentioned by Scott Bradner in his OPS-DIR review:
I find no additional operational concerns beyond those
present in running any secure SIP infrastructure.

I do observe that the stage upon which this standards
track ID is dancing on is rather close to the forbidden
zone as described by RFC 2804. But the stage was
selected when the working group was formed and it
is too late to revisit if that was a stage that an IETF
working group should be dancing on.

[Ballot discuss]
I have to raise one of Ben's comments to DISCUSS, after giving it a lot of thought.  We talked about it before Ben posted his ballot, and I said that I thought the way the rs-metadata-request subtype is used is abusing media types: media types are meant to label containers for protocol elements, but are not meant to be protocol elements themselves.  I said I didn't want to get too wound up with that, though, and I don't...

...except that it allows no room for extensibility.  And the moment you need another, different request, we see why this mechanism is abusive.  Now, you may say that you don't see any need for extensibility, but we've been proven wrong in those sorts of assumptions many times.

So, the discussion is about how you will deal with that.  Specifically, an alternative would be to have an rs-request subtype, with a content-type parameter such as "req=metadata" (or even use rs-metadata with "req=snapshot") and a rule that req= values that are not recognised be ignored.  If this should ever need to be extended, other "req=" values could be defined.  A registry could be created in future, if there turns out to be a need.

There are other options, as well, but the main question is why are you sure that no such extensibility is needed?

Also, what you're doing with content-disposition isn't in accord with what that field is for: it is for describing how the information in the message part should be presented -- not what it's meant to contain or be used for.  This, too, could be better handled with a content-type parameter.

The discussion on this point is whether thus was considered, and, if so, why it was rejected.

[Ballot comment]
-- Section 7.1.1 --

  Since the SRC does not expect to receive media from the SRS, the SRC
  typically sets each media stream of the SDP offer to only send media,
  by qualifying them with the a=sendonly attribute

Why "typically"?  Why would it not?  Why not just remove the word? The same question applies to 7.2.

-- Section 8.1.4 --

  It is RECOMMENDED that an SRC or
  Recording aware UA, when acting as a mixer, sets the CSRC list
  accordingly, and that the SRC and SRS interpret the CSRC list
  appropriately when received.

A few questions about this:
"Accordingly" and "appropriately" are quite vague... any better guidance on what is accorded and appropriate?  For the former, I presume you're saying that the UA should set the CSRC list to encompass what's being mixed.  But I have no idea what's appropriate for the SRC and SRS to do when interpreting that.  Further, on "RECOMMENDED", what happens if someone doesn't do this as you're hoping they do?  What are the consequences to interop or security?

-- Section 8.1.5 --

  The ability to identify individual contributing sources is important
  in the content of SIPREC.

I think you mean "context", yes?

-- Section 8.2.1.1 --

  UAs may receive multiple sets of RTCP Receiver Reports, one or more
  from other UAs participating in the CS, and one from the SRS
  participating in the RS.  A UA SHOULD process the RTCP Receiver
  Reports from the SRS if it is recording-aware.

Is it woth mentioning what the UA is likely to do with the reports from other UAs (just for information, without 2119 words)?  Would the UA generally process them too?  Ignore them?  Doesn't matter?  Is there any advantage one way or another, or any advice that would be useful for implementors to have?

[Ballot discuss]
I am concerned that this draft allows the recording session to downgrade security from the communication session. It says "SHOULD NOT", but then explicitly allows for the downgrade when the SRC and SRS are in the same administrative domain. This seems to create a whole new "last hop exception" for media, similar to the one for SIPS that we took so many years to deprecate. (Except it's worse because the potentially insecure hop goes to an endpoint not necessarily expected to be a party to the media.)

Section 6.1.2 includes a "contract in place" as a form of recording indication. The other mechanisms seem to say that a given call is being recorded. A contract cannot do that, except in the degenerate case of "all calls are recorded." This doesn't seem to fit the spirit of the "MUST provide recording indication" language.

Section 12, 2nd paragraph says the SRC and SRS "MUST support SIP with TLS and MAY support SIPS with
  TLS as per [RFC5630]". That actually downgrades the requirement for SIPS support from that in 3261/5630. (3261 says you MUST support SIPS if you support TLS.)

[Ballot comment]
The reference to 7245 is informational. Do you expect that a reader/implementor could understand/implement this draft without understanding the architecture and terminology from that RFC? The same applies for 3550--I'm skeptical that one could implement this draft without understanding RTP.

-- Figure 1: The text says the flow is basically the same whether the SRC is in an endpoint or separate. This may be logically true, but the flow really would change--none of of the flow between UA(A) and SRC would exist.

-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS" reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add some motivation as to why this draft seems to prefer UPDATE.

-- 5.3: It seems odd to me that the SRC can ignore an explicit preference not to record. Wouldn't it be better just to refuse to complete/accept the call, if some policy overrides the end-user's preference?

-- Figure 3: If the UA prefers not to be recorded, shouldn't it express that at setup time, rather than wait for the SRC to indicate recording is happening? As shown, this almost guarantees a bit of media will be recorded. (Seems like there should be some guidance about this in the text.) The last paragraph of 6.1.2 seems to reinforce the problem by suggesting the participant might base the decision to express a preference on a tag that is optional for the SRC to send in the first place.

-- 6.3, last paragraph: It seems odd that the requirement to render a recording indicator be lower for a media server than for other UAs. This seems to circumvent user notification in one of the most common uses of recording these days.

-- 9.1 : The last bullet seems to be a motivation to not send metadata at all, which is expressly forbidden in the first paragraph.

-- 9.2: The use of  the content-type value as the sole indicator that the an UPDATE request should be interpreted as an request for a metadata snapshot update is rather odd.  If you end up with new kinds of metadata requests in the future, does each one get it's own media-type?

-- 12: If this doc is to depend on the security considerations in 6341, that needs to be a normative reference--which is a bit of a pain because I think it's an informational RFC.

-- 12.1:
"recording session uses TLS" -- I assume that's for SIP? Also It's worth discussing how mutual authentication applies if the SRC is in an end-user device. Is it expected to have a client cert? No option to use  SIP identity?

Also, I'm a bit uncomfortable assuming devices in the same administrative domain automatically trust each other. It might be better to say "If they trust each other..."

-- 12.2:

I get quite a bit of heartburn out of making Security Descriptions MTI and dtls-srtp optional. I guess I may have to hold my nose on this one.

Editorial:

-- 4: 2nd paragraph: " ... does not represent the protocol"
and first bullet: "Delivering recorded media in real-time as the CS media"

I don't understand what either of those mean.

-- 5.1, 2nd paragraph: "B2BUA to bridge
the media between UA(A) and UA(B)"

Is there a reason not to use the terminology from RFC 7092? (e.g. “relay” or “terminate” media)?

-- 7.3.1: The normative language in the first paragraph is redundant to similar language in 6.3.

[Ballot discuss]

(1) 5.3: How does a UA know if it's preference to not be
recorded has been ignored?

(2) 12.2: Why is a 2011 ([I-D.ietf-avt-srtp-ekt]) expired
I-D ok as the method for supporting DTLS-SRTP for the CS,
esp when DTLS-SRTP is our currently favoured method for
handing WebRTC security? When is that going to be finished?
On what basis is that an informative and not normative
reference? And is that reference ever likely to be
standardised? (Given that it seems to be a form of TLS MitM
- is that fair?) Perhaps it'd be better to just admit
that re-encryption is needed and get over it?

(3) I'll clear once you answer: but wouldn't it be easier
all around to just mandate use of mutually authenticated
TLS between SRC and SRS in all cases?  (Even if some
hop-by-hop stuff is needed when there are proxies between
SRC and SRS.)

[Ballot comment]
Peter Yee's Gen-ART review raised some good questions. For instance,
I thought these at least were important points:

Page 21, section 8.1.5, 2nd paragraph, 1st sentence: by “content” do you
actually mean “context”?  Or do you mean to the content of a SIPREC
recording?
...
Page 38, section 12, 2nd paragraph, 3rd sentence: perhaps the word
“effective” would be more appropriate than characterizing it as an
“automatic” downgrade?

Page 38, section 12.1, 1st paragraph, 2nd to last sentence: just because
an SRS is compromised does not mean that it cannot be authenticated.  It
may very well be operating “correctly” and be able to authenticate, yet
the compromise allows the attacker to obtain the (decrypted) RS.
Authentication does not imply that the SRS you are talking to is not
compromised.  It only indicates the SRS possesses some form of credential
that appears to identify it correctly.

[Ballot comment]
From Scott Bradner's Opsdir review:

I did an OPS-DIR review of draft-ietf-siprec-protocol-16.

This document describes a mechanism for recording SIP
sessions, ostensibly, only with the knowledge of the SIP endpoints.

The document is clear and mature (which I would hope was
the case for a -16 working group ID).  In particular, the security
considerations section seems quite well written to me.

I find no additional operational concerns beyond those
present in running any secure SIP infrastructure.

I do observe that the stage upon which this standards
track ID is dancing on is rather close to the forbidden
zone as described by RFC 2804. But the stage was
selected when the working group was formed and it
is too late to revisit if that was a stage that an IETF
working group should be dancing on.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-siprec-protocol-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a couple questions about some of the actions requested in the IANA Considerations section of this document.

IANA understands that upon approval of this document, there are five actions which IANA must complete.

First, in the Option Tags subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/

two new option tags will be added as follows:

Name: siprec
Description: This option tag is for identifying the SIP session is for the purpose of a recording session. This is typically not used in a Supported header. When present in a Require header in a request, it indicates that the UAS is either an SRC or SRS capable of handling a recording session.
Reference: [ RFC-to-be ]

Name: record-aware
Description: This option tag is to indicate the ability for the user agent to receive recording indicators in media level or session level SDP. When present in a Supported header, it indicates that the UA can receive recording indicators in media level or session level SDP.
Reference: [ RFC-to-be ]

Second, in the iso.org.dod.internet.features.sip-tree (1.3.6.1.8.4) subregistry in the Media Feature Tags - iso.org.dod.internet.features (1.3.6.1.8) registry located at:

http://www.iana.org/assignments/media-feature-tags/

two new Media Feature Tags are to be registered as follows:

Decimal: [ TBD-at-Registration ]
Name: sip.src
Description: This feature tag indicates that the user agent is a Session Recording Client for the purpose for Recording Session.
Reference: [ RFC-to-be ]

Decimal: [ TBD-at-Registration ]
Name: sip.srs
Description: This feature tag indicates that the user agent is a Session Recording Server for the purpose for Recording Session.
Reference: [ RFC-to-be ]

IANA notes that the authors suggest 25 and 26 for the Decimal values for these registrations.

QUESTION: Both 25 and 26 have been assigned.  The authors should remove
the values from section 11.2.  IANA suggested to use TBD place holder to avoid
this sort of conflicts. 

Third, in the Content Disposition Parameters subregistry of the Content Disposition Values and Parameters registry located at:

http://www.iana.org/assignments/cont-disp/

a new content-disposition parameter is to be registered as followed:

Name: recording-session
Description: metadata about the recording session or reason for metadata snapshot request
Reference: [ RFC-to-be ]

Fourth, in the application subregistry of the Media Types registry located at:

http://www.iana.org/assignments/media-types/

a new media type will be registered as follows:

Name: rs-metadata-request
Template: [ TBD-at-registration ]
Reference: [ RfC-to-be ]

Fifth:

IANA Question --> the next request to IANA requests that two new SDP attributes be registered but for the type says (for both) that the type should be "session or media level." Do the authors mean session AND media level, or do they mean something else?  As this document requests registrations in a Specification Required registry, the authors need to clarify the request before we can initiate the required Expert Review.  Expert review will need to be completed before your document can be approved for publication as an RFC.

In a registry to be identified later (see IANA Question above), located at:

http://www.iana.org/assignments/sdp-parameters/

two new SDP Parameters are to be registered as follows:

Type: record
SDP Name: Recording Indication
Reference: [ RFC-to-be ]

Type: recordpref
SDP Name: Recording Preference
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Recording Protocol) to Proposed Standard


The IESG has received a request from the SIP Recording WG (siprec) to
consider the following document:
- 'Session Recording Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the use of the Session Initiation Protocol
  (SIP), the Session Description Protocol (SDP), and the Real Time
  Protocol (RTP) for delivering real-time media and metadata from a
  Communication Session (CS) to a recording device.  The Session
  Recording Protocol specifies the use of SIP, SDP, and RTP to
  establish a Recording Session (RS) between the Session Recording
  Client (SRC), which is on the path of the CS, and a Session Recording
  Server (SRS) at the recording device.  This document considers only
  active recording, where the SRC purposefully streams media to an SRS
  and all participating user agents are notified of the recording.
  Passive recording, where a recording device detects media directly
  from the network (e.g., using port-mirroring techniques), is outside
  the scope of this document.  In addition, lawful intercept is outside
  the scope of this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1912/

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.