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

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?

[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.

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.

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.

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.

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.

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.