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

"Ben Campbell" <ben@nostrum.com> Mon, 14 March 2016 23:17 UTC

Return-Path: <ben@nostrum.com>
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 989BC12D7E2 for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 16:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 Ab2LL7zDKqA1 for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 16:17:53 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E853212D7BD for <siprec@ietf.org>; Mon, 14 Mar 2016 16:17:52 -0700 (PDT)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2ENHmE5089414 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Mar 2016 18:17:49 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Mon, 14 Mar 2016 18:17:48 -0500
Message-ID: <7005E8B6-90A1-4F06-A8BD-A0C1F0DFA3AC@nostrum.com>
In-Reply-To: <56E73EF0.5020603@alum.mit.edu>
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> <56E73EF0.5020603@alum.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5232)
Archived-At: <http://mailarchive.ietf.org/arch/msg/siprec/Nlsbs2OerrcXtPGUJgaRUFph7f8>
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 23:17:55 -0000

On 14 Mar 2016, at 17:45, Paul Kyzivat wrote:

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

Yes, that would help. Ram proposed different text, which is also fine. 
Either would improve things.

Thanks,

Ben.