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

[Paul Kyzivat <[e-mail]>]

On 3/10/16 12:25 AM, Ram Mohan R (rmohanr) wrote:
> Paul,
>
> Thanks. I will fix the nits you pointed out.

The last one is more than a nit. So it might require more discussion. Ben?

	Thanks,
	Paul

> 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
>>
>
>