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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]

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.

[Ballot discuss]

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?

[Ballot comment]

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

[Ballot comment]
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.

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-siprec-architecture-08, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Architecture for Media Recording using the Session Initiation Protocol) to Informational RFC


The IESG has received a request from the SIP Recording WG (siprec) to
consider the following document:
- 'An Architecture for Media Recording using the Session Initiation
  Protocol'
  as Informational RFC

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 2013-10-01. 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


  Session recording is a critical requirement in many communications
  environments such as call centers and financial trading.  In some of
  these environments, all calls must be recorded for regulatory,
  compliance, and consumer protection reasons.  Recording of a session
  is typically performed by sending a copy of a media stream to a
  recording device.  This document describes architectures for
  deploying session recording solutions in an environment which is
  based on the Session Initiation Protocol (SIP).




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

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


No IPR declarations have been submitted directly on this I-D.