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

"Ben Campbell" <ben@nostrum.com> Mon, 14 March 2016 18:27 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 385D112D5DE for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 11:27:33 -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 qtHCrrmbQH0n for <siprec@ietfa.amsl.com>; Mon, 14 Mar 2016 11:27:31 -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 7CF2812D6C4 for <siprec@ietf.org>; Mon, 14 Mar 2016 11:27:30 -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 u2EIRQxR062810 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Mar 2016 13:27:27 -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 13:27:25 -0500
Message-ID: <E1A21BC5-C534-4763-9466-5649B0BB311D@nostrum.com>
In-Reply-To: <56E0A8E9.2020505@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>
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/fN--Bm2gqlcOs80At18XlDXYKIc>
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 18:27:33 -0000

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.

Ben.