Session Initiation Protocol (SIP) Recording Metadata
draft-ietf-siprec-metadata-22

[Ballot discuss]


(1) In section 10 you have a MUST for integrity and confid,
which is good, but then RECOMMEND S/MIME, which is, I think,
mythical. Wouldn't it be better to reflect reality
(hop-by-hop TLS) and then say what actual security
considerations arise, e.g. who might be on the path and how
can they (mis)behave?

(2) 6.10: Don't you need to say to use UUID version 4 with
random numbers and to not use MAC addresses?  IOW, refer to
RFC4122, Section 4.4 for how to generate UUIDs.

Note that issues related to both of the above were part
of the discussion that ensued from the secdir review. [1]

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06370.html

[Ballot discuss]


(1) In section 10 you have a MUST for integrity and confid,
which is good, but then RECOMMEND S/MIME, which is, I think,
mythical. Wouldn't it be better to reflect reality
(hop-by-hop TLS) and then say what actual security
considerations arise, e.g. who might be on the path and how
can be (mis)behave?

(2) 6.10: Don't you need to say to use UUID version 4 with
random numbers and to not use MAC addresses?  IOW, refer to
RFC4122, Section 4.4 for how to generate UUIDs.

Note that issues related to both of the above were part
of the discussion that ensued from the secdir review. [1]

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06370.html

[Ballot comment]


- section 4, last para: How could an SRC know this and hence
what it's safe to omit?

- 6.9: I would have thought that more precision about
fractional seconds support would be useful here, or else, to
just say that you're limiting to single-second granularity.
Wouldn't doing one or the other be better? Otherwise you
might get different s/w ordering events in different orders
unexpectedly.

[Ballot comment]
I'm going to ballot no-objection on this, but I do have some comments

= Substantive =

- I'm confused about the associations between an RS (as modeled by ) and a CS or CSG. As far as I can tell, a  element is associated with a given CS/CSG by the fact of enclosing it. But the UML and related text indicates that a CS or a CSG can be associated with more than one RS. How does that work in the XML?  Along the same lines, what would it mean for a CS or CSG to be associated with more than one RS?

- 5.1: Does the xml doc contain _exactly_ one  element?

- 5.1.2: See question on 5.1. (Also, the normative language seems redundant between the sections.)

- 6.1.2: Can you elaborate on "persistent recording" and why it removes the need for a CS/CSG?

- 6.2: What does a CSG model? What does it mean for a CS to be part of a group or not part of a group?

-6.2.2: The UML suggests that a given CS cannot be associated with more than 1 CSG. That’s worth mentioning here.

- 6.3: Can a given CS be directly associated with an RS and also a CSG? (I guess that will always be true in the XML, but it's not apparent from the UML).

-6.3.1, sipSessionID: I gather this is the session-id from the media session, not the recording session. If correct, it would be helpful to say it explicitly.

- 6.3.3: "A stream in a persistent RS is not required to be associated with any CS..."
It's not apparent how you would do that in the UML. I can see how you would do it by virture of being contained in a  element.

- 6.5.1: Remote-Party-ID? Citation needed ;-)

- 6.10: Why not MUST? Can you envision good reasons to not use this method?

-6.11: Do I understand correctly that means  no extensions are allowed without changing the version number? Is that really the intent?

-10, first paragraph:
Why is the SHOULD not a MUST? Also,  what does the SRC need to authenticate/authorize?
-- 2nd paragraph: Do you really expect people to implement s/mime?
-- last paragraph: I'm not sure what "Implementations MUST control what metadata
  is recorded" means. Is the point that the implementation must let someone control that policy? That it must not record unnecessary metadata? (If the later, how is "necessary" determined?)

- 13.2: I think RFCs 3325 and 3326 need to be normative references. That's an issue for 3325, but section 6.5.1 normatively states that P-AID is a potential source for nameID. (which should probably be scoped to only be true for deployments where P-AID makes sense.)

= Editorial =

- Figure numbers and captions would be useful.

- I found the organization to be a bit odd. Section 5 starts talking about some but not all XML details, then 6 goes over the UML model, but switches back to XML in the last few sections, then we've got more XML stuff (schema, etc) further down.

- There are a lot of missing articles and commas, especially in the in section 6 and subsections. The RFC editor will fix this, but it would save them work if the authors did a proofreading pass, if they otherwise have reason to update the draft.

- 6.1: It would have been helpful to mention that the  element represented a recording session back when  was first mentioned in section 5.

[Ballot comment]
I don't see how a reader can understand this without understanding what an SRC, an SRS, an RS, and a CS are, and those are defined in RFC 6341.  Why isn't 6341 a normative reference?

Please expand "AoR" on first use.  You might also cite 3261 there as defining it.  (I find it a bit odd that there's no citation to 3261 except in the Security Considerations.)

You refer twice to "Unified Modelling Language(UML)": is there a reference for UML?

On the other hand, while we're on references, I really don't think you need any of the citations in Section 5.1.1 (and can remove their associated references).  No one reading this needs to know the details of what a URN is or how the ietf URN namespace is organized (just like you don't have a reference for "URI", and don't need it).  I would just simplify it to this and take out the three unnecessary references:

NEW
  The namespace URI for elements defined by this specification is
  the following URN:
 
      urn:ietf:params:xml:ns:recording:1
END

A really tiny point (which the RFC Editor might also bring up): In Section 6.1.1 you refer to "a RS class" and "a RS object".  Unless that's actually pronounced "Recording Session" when you read it, it should be "an RS [class|object]".

There are a lot of missing articles ("the", "a", "an") throughout.  The RFC Editor will fix these, but...

In Section 6.3.1, the definition of the "reason" attribute is slightly confusing because "reason" is also an English word that can fit into the sentences also.  So, here:

      The reason XML element has
      'protocol' as an attribute, which indicates the protocol from
      which the reason string is derived.

...I initially read "the reason XML element has 'protocol' as an attribute..." differently to how you meant it.  I suggest making it this:

      The 'reason' XML element has
      'protocol' as an attribute, which indicates the protocol from
      which the reason string is derived.

I also suggest going back through this and consistently quoting the words when they refer to attribute or element names, to distinguish them from just plain English ("the 'session' XML element", "the 'reason' XML element", " 'protocol' attribute", and so on).  You could skip this for the camel-cased items (such as "sipSessionID"), and the hyphenated ones ("group-ref"), because they can't be confused with plain words... but it might be better to be consistent.

In Section 6.3.2, I don't like the two non-parallel lists at the end.  I think the RFC Editor will fix these, so I'll just point them out and let you decide what to do (or not).  (In contrast, the list in Section 6.5.2 is properly parallel.)

In Section 6.9, just checking here:

  As a security measure, the timestamp element SHOULD be included in
  all tuples unless the exact time of the status change cannot be
  determined.

Are there other reasons one might not include a timestamp element?  Or is the fact that you can't determine the time the only one?  If the latter, then it should be "MUST ... unless", rather than "SHOULD ... unless", and I think that's what you mean.

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

IANA has completed its review of draft-ietf-siprec-metadata-20.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA needs to complete.

First, in the ns subregistry of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: recording:1
URI: urn:ietf:params:xml:ns:recording:1
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema subregistry also in the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a new schema will be registered as follows:

ID: recording:1
URI: urn:ietf:params:xml:ns:recording:1
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA further understands that the schema to be documented in the registry can be found in section 9 of the current draft and not section 8 as indicated in the IANA Considerations section of that draft.

IANA also notes that the schema request, like the ns request is subject to Expert Review. We will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these are the only actions 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. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alcoop@cisco.com, "Brian Rosen" , siprec-chairs@ietf.org, draft-ietf-siprec-metadata@ietf.org, siprec@ietf.org, br@brianrosen.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) Recording Metadata) to Proposed Standard


The IESG has received a request from the SIP Recording WG (siprec) to
consider the following document:
- 'Session Initiation Protocol (SIP) Recording Metadata'
  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 2016-02-22. 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 the metadata model as
  viewed by Session Recording Server(SRS) and the Recording metadata
  format.




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

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


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

Shepherd Writeup for draft-ietf-siprec-metadata, current version 18.  Date of this writeup: Nov 19, 2015.  Document Shepherd: Brian Rosen

(1) This document is Proposed Standard.  The document header indicates Standards Track.  This document defines a the metadata for the siprec protocol, contains normative language that constrains implementers and thus is properly classified as “Proposed Standard”.
(2) Document Announcement Write-Up:
Technical Summary:
This document describes the metadata sent between a Session Recording Client (SRC) and the Session Recording Server (SRS) in a recording of a Session Initiation Protocol (SIP) session as described in draft-ietf-siprec-protocol. 

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, once the protocol draft was finished, this document converged relatively rapidly to consensus.
Document Quality:
There are multiple interoperable implementations of drafts of this protocol.  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.  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 metadata typically saved with a recording of a SIP session, which raises privacy concerns.  The mechanism requires consent, and active participation at the Session Recording Client and the protocol 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 and the protocol has had significant security review.  The metadata contains information that is considered private, and the document contains requirements and advice on how the metadata should be protected in transit and requires  the recipient (SRS) to have a retention policy on what and how long metadata will be stored.
(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) There are no IPR disclosures filed on the draft.
(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 some minor nits that should be handled in normal RFC editor processing: long lines, outdated reference and dates.
(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 protocol document, which is in the RFC editor queue and an normative reference to the session-id document.
(15) See (14) above.
(16) This document does not change the status of any RFCs. 
(17) This document only adds a namespace and schema and requires no other IANA actions.
(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.

Edit
Back

Shepherd Writeup for draft-ietf-siprec-protocol, current version 18.  Date of this writeup: November 31, 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 the metadata sent between a Session Recording Client (SRC) and the Session Recording Server (SRS) in a recording of a Session Initiation Protocol (SIP) session as described in draft-ietf-siprec-protocol. 

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, once the protocol draft was finished, this document converged relatively rapidly to consensus.
Document Quality:
There are multiple interoperable implementations of drafts of this protocol.  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.  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 metadata typically saved with a recording of a SIP session, which raises privacy concerns.  The mechanism requires consent, and active participation at the Session Recording Client and the protocol 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 and the protocol has had significant security review.  The metadata contains information that is considered private, and the document contains requirements and advice on how the metadata should be protected in transit and requires  the recipient (SRS) to have a retention policy on what and how long metadata child be recorded.
(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) There are no IPR disclosures filed on the draft.
(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 some minor nits that should be handled in normal RFC editor processing: long lines, outdated reference and dates.
(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 protocol document, which is in the RFC editor queue and an normative reference to the session-id document.
(15) See (14) above.
(16) This document does not change the status of any RFCs. 
(17) This document only adds a namespace and schema and requires no other IANA actions.
(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.

Edit
Back