Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-metadata-18

From: Alissa Cooper <[email-masked]>
Date: Thu, 14 Jan 2016 08:43:08 -0800

Hi Ram,

Is an update forthcoming?

Thanks,
Alissa

> On Dec 8, 2015, at 4:49 AM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> Sorry for delay. I am working on addressing the comments. Will publish a
> new revision some time next week.
> 
> Regards,
> Ram
> 
> -----Original Message-----
> From: Alissa Cooper <[email-masked]>
> Date: Friday, 4 December 2015 at 10:49 PM
> To: Cisco Employee <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [siprec] AD evaluation: draft-ietf-siprec-metadata-18
> 
>> Is a rev of this document forthcoming?
>> 
>> Thanks,
>> Alissa
>> 
>>> On Nov 19, 2015, at 12:21 PM, Alissa Cooper <[email-masked]> wrote:
>>> 
>>> Hi Ram,
>>> 
>>> Thanks. A few comments below.
>>> 
>>>> On Nov 19, 2015, at 9:32 AM, Ram Mohan R (rmohanr) <[email-masked]>
>>>> wrote:
>>>>> 
>>>>> - "However if there are implementations where SRC has enough
>>>>> information, this could be sent as Extension Data attached to the
>>>>> CS.² I
>>>>> assume the main barrier here isn¹t whether the SRC ³has enough
>>>>> information,² but rather whether the entity operating the SRC has a
>>>>> desire
>>>>> to specify its
>>>>> own policy preferences and whether any entities operating SRSes have
>>>>> any
>>>>> interest in supporting them in an automated fashion.
>>>> 
>>>> Yes that’s right. Will re-word the sentence to some thing like this.
>>>> Does
>>>> this sound better and takes care of this and the previous comment ?
>>>> 
>>>> EXISTING:
>>>> This document does not specify attributes relating to what should
>>>> happen to a recording of a CS after it has been delivered to the SRS.
>>>> (E.g., how long to retain the recording, what access controls to
>>>> apply.)  The SRS is assumed to behave in accordance with policy.  The
>>>> ability for the SRC to influence this policy is outside the scope of
>>>> this document.  However if there are implementations where SRC has
>>>> enough information, this could be sent as Extension Data attached to
>>>> the CS.
>>>> 
>>>> 
>>>> 
>>>> NEW:
>>>> This document does not specify attributes relating to what should
>>>> happen to a recording of a CS after it has been delivered to the SRS.
>>>> (E.g., how long to retain the recording, what access controls to
>>>> apply.)  The SRS is assumed to behave in accordance with its policy.
>>>> The
>>>> ability for the SRC to influence this policy is outside the scope of
>>>> this document.  However if there are implementations where SRC has
>>>> has desire to specify its own policy preferences, this could be sent as
>>>> Extension Data attached to the CS.
>>>> 
>>> 
>>> This is better, thanks. I would suggest s/its policy/its local policy/
>>> 
>>>> 
>>>>> 
>>>>> == Section 6.6 ==
>>>>> 
>>>>> Why are the capabilities of the participant being recorded? It¹s not
>>>>> obvious from the text.
>>>> 
>>>> There was a requirement to indicate the capability of the participant
>>>> (for
>>>> e.g; whether the participant is “automata”, “focus”, “msg-taker” and so
>>>> on) 
>>>> I believe SRS vendors would use this information along with other
>>>> metadata.
>>> 
>>> It would help to include a motivating example in the text here.
>>> 
>>>>> 
>>>>> 
>>>>> == Section 9 ==
>>>>> 
>>>>> Why does the schema specify the ability to include elements from other
>>>>> namespaces in the requestsnapshot element? I thought the expectation
>>>>> was
>>>>> that there might be one requestreason given and that¹s all.
>>>> 
>>>> Yes. This was from the discussions in the WG. We want to have a
>>>> flexibility to allow a SRS include any extension data in the request
>>>> (additional information about why it is requesting for snapshot).
>>>> 
>>>> <xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
>>>>   <xs:complexType name="requestsnapshot">
>>>>     <xs:sequence>
>>>>        <xs:element name="requestreason" type="tns:name"
>>>> minOccurs="0"/>
>>>>        <xs:any namespace='##other'
>>>>          minOccurs='0'
>>>>          maxOccurs='unbounded'
>>>>          processContents='lax'/>
>>>>     </xs:sequence>
>>>>   </xs:complexType>
>>> 
>>> Ah right, I recall that now.
>>> 
>>> Will await a rev with the changes.
>>> 
>>> Alissa
>>> 
>>> _______________________________________________
>>> siprec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>> 
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 21 Jan 2016 17:23:15 +0000

Hi Alissa/ WG,

Please find the diffs. Please review and let me know your feedback.

I have modified the UML to have same naming for all attributes of each
object.
For the UML objects I still have retained the existing names, however in
description of each object I have added a paragraph that gives the XML
schema element for that object.

Ram