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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Paul,

Thanks. I will fix the nits you pointed out.

Regards,
Ram

-----Original Message-----
From: Paul Kyzivat <[e-mail]>
Date: Thursday, 10 March 2016 at 10:50 AM
To: Cisco Employee <[e-mail]>, Ben Campbell <[e-mail]>
Cc: "[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[e-mail]>,
Brian Rosen <[e-mail]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

>[Omitting the IESG]
>
>This seems fine to me except for a couple of small English tweaks:
>
>> NEW:
>> The 'recording' element MUST contain an xmlns namespace attribute with
>> value as urn:ietf:params:xml:ns:recording:1. Only one recording element
>> MUST be present in every recording metadata XML document.
>
>s/Only one/Exactly one/
>
>> NEW:
>> 
>> A persistent RS is a SIP dialog that is setup between SRC to SRS even
>> before any CS is setup. So the metadata sent from SRC to SRS when the RS
>> is setup will not have have CS(and the related CSG) elements in the XML
>>as
>> there is no session that is associated to the RS yet.  For e.g; a phone
>> acting
>> as SRC can setup a RS with SRS even before phone is part of a CS. Once
>>the
>> phone
>> joins a CS, the same RS would be used to convey the CS metadata.
>
>(The above seems to suggest that a persistent RS must be setup before
>any CS.)
>
>s/even before/possibly even before/
>
>s/will not have have CS/may not have CS/
>
>> NEW:
>> One instance of a Communication Session Group(CS-Group) class namely
>>     the Communication Session Group object provides association or
>>     linking of Communication Sessions. A CS-Group is used to group all
>> related CS. For e.g, in a contact centre flow a call may get transferred
>> to multiple agents. Each of these may trigger setup of new CS.
>> In cases where the SRC knows the related CSs it can group them using
>> The CS-Group element.
>
>s/centre/center/ (AFAIK we are doing American English)
>
>> Some implementations may have the SRC choose parts of metadata that can
>>be
>> sent to the SRS.
>> In other cases, SRCs may send metadata that is not appropriate for the
>>SRS
>> to record. Which
>>   metadata is actually recorded by the SRS must be carefully considered
>>to
>> balance privacy
>> concerns with usability. Implementations MUST control what metadata is
>> recorded, and MUST NOT
>>   save metadata sent by the SRC that does not conform to the recording
>> policy of the SRS.
>> Metadata in storage needs to be provided with a level of security that
>>is
>> comparable to that
>> of the recording session.
>
>How about:
>
>An SRC MAY, by policy, choose to limit the parts of the metadata sent to
>the SRS for recording. And the SRS MAY not need all the metadata it
>receives or choose, by policy, to limit the metadata it records.
>Metadata in storage needs to be provided with a level of security that
>is comparable to that of the recording session.
>
>	Thanks,
>	Paul
>