Session Initiation Protocol (SIP) Recording Call Flows
draft-ietf-siprec-callflows-08

[Ballot comment]

One of the SIPREC security issues we had to deal with was
getting agreement that commensurate security mechanisms need
to be used for calls and related recording sessions. It's a
pity that none of the flows included here demonstrate that
aspect. In particular, a set of calls that do not have
commensurate security settings might otherwise map to 1 RS,
which I think (not 100% sure) could affect the flows shown
in 3.4.

[Ballot comment]
I had the smae question about privacy considerations that the SecDir reviewer noted:
https://www.ietf.org/mail-archive/web/secdir/current/msg06953.html

But see it is covered in the referenced drafts.  As such, could you note in the security considerations section the references are for both security and privacy considerations?  Just add "and privacy".

[Ballot comment]
* Section 3.1

Can you please clarify what a "Turret flow" is (and hopefully add a reference)? It is not immediately clear why this is special.

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

The IANA Services Operator has reviewed draft-ietf-siprec-callflows-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: andrew.hutton@unify.com, draft-ietf-siprec-callflows@ietf.org, alissa@cooperw.in, siprec-chairs@ietf.org, siprec@ietf.org, "Andrew Hutton"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) Recording Call Flows) to Informational RFC


The IESG has received a request from the SIP Recording WG (siprec) to
consider the following document:
- 'Session Initiation Protocol (SIP) Recording Call Flows'
  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 2016-11-27. 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
  organizations.  In some of these environments, all calls must be
  recorded for regulatory, compliance, and consumer protection reasons.
  The recording of a session is typically performed by sending a copy
  of a media stream to a recording device.  This document lists call
  flows with metadata snapshots sent from a Session Recording
  Client(SRC) to a Session Recording Server(SRS).




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

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


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

(1) This document is Informational.  The document header indicates Informational. The document lists some example
call/message flows and snippits of metadata. It supplements RFC 7865 which specifies the Session Initiation Protocol
Recording Metadata by providing examples to aid implementers.
(2) Document Announcement Write-Up:
Technical Summary:
This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording
Server(SRS).

Working Group Summary:

This document has had a relatively long gestation period in the working group, this is because feedback from real
implementations was thought important and also it could not be completed before the SIPREC metadata specification (RFC 7865)
was published


Document Quality:

There are multiple interoperable implementations of the protocol and metadata shown in this draft.  Notably, the National
Emergency Number Association (NENA) has included the protocol, with the metadata described in this document in it’s Next
Generation 9-1-1 standard, and has held an interoperability event where multiple implementations were tested. A number of
recording vendors provided a detailed review and comments on this draft.

Personnel:

Andrew Hutton is the Document Shepherd.  Alissa Cooper is the Responsible Area Director.


(3) I have completed a thorough review of the document and although the document is difficult to review given that it has a
lot of XML containing UUID’s. I believe it is ready to be published.

(4) The document is quite difficult to review in detail but a number of in-depth reviews by individuals/companies involved
in the implementation have taken place.

(5) There are many security and privacy issues related to the generation of the metadata shown in this document however this
document only shows examples and the concerns have been addressed during the review of the associated metadata specification
itself (RFC 7865) therefore no addition reviews are needed.

(6) Neither the work group nor I have any concerns or issues.

(7) All three authors have 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.  All three declared that they have no IPR on this draft.

(8) There are no IPR disclosures filed on the draft.

(9) As with many IETF working groups, interest in finishing has flagged.  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.

(11) There is one minor nit in that there is a unused reference to RFC 6230 this is due to a change in a late revision of
the document which changed the reference. This should be handled in normal RFC editor processing.

(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 indicated to be informative there are no normative references.

(14) There are no normative references in this draft.

(15) There are no normative references in this draft.

(16) This document does not change the status of any RFCs. 

(17) There are no IANA considerations in this draft.

(18) The document does not create any new registries.

(19) This document does not contain any XML, BNF, MIB or other formal language constructs.  The document does contain XML
schemas.