Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 14 March 2016 22:45 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5A12D7D5 for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 15:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InkyzAvt1R04 for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 15:45:14 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2060612D7E0 for <siprec@ietf.org>; Mon, 14 Mar 2016 15:45:07 -0700 (PDT)
Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-04v.sys.comcast.net with comcast id Vykl1s0062EPM3101yl63p; Mon, 14 Mar 2016 22:45:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id Vyl51s0093KdFy101yl5dG; Mon, 14 Mar 2016 22:45:06 +0000
To: Ben Campbell <ben@nostrum.com>
References: <20160302002515.30664.79446.idtracker@ietfa.amsl.com> <D2FD1094.53195%rmohanr@cisco.com> <2025D20B-7234-4CE3-9E34-E3C0AAFAD5BC@nostrum.com> <56E0A8E9.2020505@alum.mit.edu> <E1A21BC5-C534-4763-9466-5649B0BB311D@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56E73EF0.5020603@alum.mit.edu>
Date: Mon, 14 Mar 2016 18:45:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <E1A21BC5-C534-4763-9466-5649B0BB311D@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457995506; bh=f0WvF8CsEI+1I6Rzwi3Gje68NUCSrBkb15OlkqhUzV4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gwFFWTaLCAGAvZSnvwwe589GHWN+A0DRNe5CfHKfcBkemYsaX/cKgevWNMlz/8i6E KCi37BrAhXyWXUloLeg2GsWhRyhje3SngGvE6/Lms4d5VARb3wssxM2zhHDjcc2/2d vxlexpOIrdwkhCH4/xAVR85FuzXBIYV4H0iD39SqfIcY6e1Teds+rHAk5Hs89TOq16 +S1RJ6aa2whrzYTqY+Bn2N49EPeCml1a53VkSJtv5HASWZq9qQXxD6AjU+Ske63/mR G1ZatrCr1hKI0cnkEHFj8HJ/n2Bu51h4mcABIGZfr1WOuvNz4NeVDGA5Ry41ifQNfw Js9N/y0uGxlkw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/siprec/uxhJEBp2_uiO0zkOlvxHeDrX17o>
Cc: siprec@ietf.org
Subject: Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 22:45:16 -0000

On 3/14/16 2:27 PM, Ben Campbell wrote:
> On 9 Mar 2016, at 16:51, Paul Kyzivat wrote:
>
>> On 3/9/16 5:40 PM, Ben Campbell wrote:
>>
>>
>>> I read that to mean that the SRS builds a database over time, and
>>> recognizes that the same CS arrived in two different xml documents, and
>>> therefore associates it with the <recording> element of each?
>>>
>>> If so, that seems to conflict with the statement in the 2nd to last
>>> paragraph in section 4, that says the model represents a snapshot. I
>>> think maybe an XML document represents a snapshot, but the model
>>> represents metadata accumulated over time. This would explain some
>>> confusion I had over things like CSRS Association.
>>
>>
>> The SRC delivers a series of xml snapshots over the RS. We don't
>> mandate what the SRS does with those. But we try to provide sufficient
>> information so that it *could* build up a database such as you describe.
>
> Keeping a history may not be required, but there seems to be
> relationships in the model that cannot ever occur in real life unless
> the SRS builds a cross-snapshot picture. (E.g.,  a given CS associated
> with more than one RS, and much anything useful with CSRS associations).
>
>>
>>
>>> In any case, I don't get a sense of how this works from the draft. I
>>> think it would benefit from a section that describes the high-level
>>> operation (unless that's already in another document, in which case a
>>> reference would help.)
>>
>>
>> I *thought this was evident. Maybe not.
>
> Maybe I missed something, but the only thing I find on the subject is
> the penultimate paragraph in section 4, which says:
>
> " The model allows the capture of a snapshot of a recording's metadata
>     at a given instant in time.  Metadata changes to reflect changes in
>     what is being recorded.  For example, if a participant joins a
>     conference, then the SRC sends the SRS a snapshot of metadata having
>     that participant information (with attributes like name/AoR pair and
>     associate-time.) "
>
> To me that suggests that the model only describes an instant in time.
> One might infer otherwise from the document as a whole, but I think a
> more explicit explanation of assumptions would be helpful for someone
> coming newly to this work.

OK, you are right. Those of us who have been working on it knew what we 
meant, but the text doesn't reflect that. Would the following be a 
suitable replacement for the above paragraph?

"The model allows metadata describing communications sessions to be 
communicated to the SRS as a series of snapshots, each representing the 
state as seen by a single SRC at a particular instant in time. Metadata 
changes from one snapshot to another reflect changes in what is being 
recorded. For example, if a participant joins a conference, then the SRC 
sends the SRS a snapshot of metadata having that participant information 
(with attributes like name/AoR pair and associate-time.)"

	Thanks,
	Paul