An Architecture for Media Recording Using the Session Initiation Protocol
draft-ietf-siprec-architecture-12

The only (non-blocking) comment I have on this is about its status: it strikes me that it doesn't define an "architecture", so much as it "specifies how, and under what circumstances, one or more Technical Specifications may be applied to support a particular Internet capability."  (That's a quote from RFC 2026, Section 3.2.)  In other words, this looks like an Applicability Statement, which is tied to the Technical Specifications it uses, and which might progress along with them.

No big deal: I don't object to its being Informational.  I just think AS (and, therefore, Standards Track) is a better match.

THIS REVIEW WAS DONE BEFORE THE TELECHAT. AN INTERNET ACCESS FAILURE BEFORE THE TELECHAT PREVENTED ME TO POST IT.

1.
It's true that the draft content might be reading as an applicability statement. However, I believe the current status is right (as opposed to Barry, Brian, and Spencer).
The WG Milestones are
Done 	
Use Cases and Requirements to IESG as Informational RFC
Jan 2013 	
Submit Architecture to IESG as Informational RFC
Apr 2013 	
Submit protocol draft to IESG as Proposed Standard RFC
Aug 2013 	
Submit Metadata model and format to IESG as Proposed Standard RFC
Aug 2013 	
Submit SIPREC Call Flows draft to IESG as an informational RFC.

We should not confuse the architecture, which comes before the protocol and metadata model/format, and the applicability statement, which is how to apply the  protocol and metadata model/format for specific use cases.
So, also citing RFC 2026: "specifies how, and under what circumstances, one or more Technical Specifications may be applied to support a particular Internet capability.", the technical specifications are not ready yet, so this document can't be an applicability statement.

2.
As a non English native speaker, let me correct an English sentence ... or look stupid and learn something. Not sure yet, as "means" is a weird name.
OLD:

   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 for the
   SIP media recording architecture.

NEW:
   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 are out of scope for the
   SIP media recording architecture.

I agree with Barry's point on the status of this document.  If it were changed to a Standards Track Applicability Statement, it would make much more sense to me.

This was a discuss, but Andrew Hutton reasonably 
suggests handling it in the metadata draft which is
fine. It'd be nice to add a sentence to this one too
just noting the implicit requirement.

Thanks for the nice clear document with references to
2804. I do have a privacy related question though.  3.3.1
here only points at I-D.ietf-siprec-metadata which
specifies all of the various things the can be metadata
but doesn't seem to say which ought or ought not be
recorded.  And neither does this document. I assume
there's an implicit requirement to only record metadata
that's needed, but where is/should that be stated?

- section 5, if the SRS doesn't authenticate the SRC
couldn't that allow for DoS attacks, e.g. to overload the
SRS so that a call you don't want recorded doesn't get
recorded? Might be worth a mention.

Former DISCUSS, which I am clearing:

This is probably a stupid question, and I will clear on the telechat regardless of what the answer is.   I may just have missed the discussion because I read the document rather quickly.   The question is, why doesn't the document talk about reliable delivery?   If recording a session is a regulatory requirement, then surely the recording should be lossless on the side of the connection that is subject to the requirement.   It's my understanding that a typical stream negotiated through SIP is loss-tolerant.   This seems like a mismatch that ought to be addressed somehow.