Skip to main content

Shepherd writeup
draft-ietf-siprec-metadata

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
Back