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

From: Alissa Cooper <[email-masked]>
Date: Fri, 4 Dec 2015 09:19:50 -0800

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: Tue, 8 Dec 2015 12:49:55 +0000

Hi Alissa,

Sorry for delay. I am working on addressing the comments. Will publish a
new revision some time next week.

Regards,
Ram