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

["Ben Campbell" <[e-mail]>]

I'm going to be on the road for the rest of the week. I will try to fit 
in a look at the diff, but please do not hold submission on my behalf 
(revisions are cheap). Failing that, I should be able to look at it by 
Monday or Tuesday.

Ben.

On 15 Mar 2016, at 22:15, Ram Mohan R (rmohanr) wrote:

> Hi All,
>
> Please find the diffs attached. This addresses Stephen¹s and Ben¹s 
> IESG
> comments. Please check and let me know if this is fine. I will publish 
> the
> revision by end of this week.
>
> Regards,
> Ram
>
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Date: Tuesday, 15 March 2016 at 7:52 PM
> To: Cisco Employee <[e-mail]>
> Cc: "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, Brian Rosen <[e-mail]>,
> "[e-mail]" <[e-mail]>
> Subject: Re: Ben Campbell's No Objection on 
> draft-ietf-siprec-metadata-20:
> (with COMMENT)
>
>> Hi Ram,
>>
>> It all looks good to me.
>>
>> Thanks!
>>
>> Ben.
>>
>> On 15 Mar 2016, at 8:00, Ram Mohan R (rmohanr) wrote:
>>
>>> Hi Ben,
>>>
>>> Thanks for review. See inline. Removed those that does not need any
>>> response (which you have accepted). Will send diffs to WG and 
>>> reviewers
>>> soon with all the comments incorporated.
>>>
>>> -----Original Message-----
>>> From: Ben Campbell <[e-mail]>
>>> Date: Tuesday, 15 March 2016 at 12:36 AM
>>> To: Cisco Employee <[e-mail]>
>>> Cc: "[e-mail]"
>>> <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, Brian Rosen <[e-mail]>, The IESG
>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>> Subject: Re: Ben Campbell's No Objection on
>>> draft-ietf-siprec-metadata-20:
>>> (with COMMENT)
>>>
>>>>
>>>>>>
>>>>>> Now that you've added the reference, you may not need the 
>>>>>> normative
>>>>>> language here. Is the RECOMMENDED something new beyond what is
>>>>>> already
>>>>>> required in siprec-protocol? (I am pretty sure the MUST is 
>>>>>> already
>>>>>> covered there.)
>>>>>
>>>>> Right. I have fixed this after discussion with Stephen. New text 
>>>>> for
>>>>> para
>>>>> 1 in Security Consideration is:
>>>>> Para 2 is removed.
>>>>>
>>>>> NEW:
>>>>> This document describes an extensive set of metadata that may be
>>>>> recorded
>>>>> by the SRS. Most of the
>>>>> metadata could be considered private data.   The procedures 
>>>>> mentioned
>>>>> in
>>>>> security consideration
>>>>> section of <xref target="I-D.ietf-siprec-protocol"/> MUST be
>>>>> implemented
>>>>> by SRC and SRS for
>>>>>  mutual authentication and to protect the content of the metadata 
>>>>> in
>>>>> the
>>>>> RS.
>>>>>
>>>>> 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.
>>>>
>>>> Perhaps s/"control what metadata is recorded"/"limit what metadata 
>>>> is
>>>> recorded" ?
>>>
>>> I see that Paul and you have discussed in the other thread and came 
>>> up
>>> with text for this part. I will use that text here.
>>>
>>> NEW: (Taken from your mail with Paul)
>>>
>>> "An SRC MAY, by policy, choose to limit the parts of the metadata 
>>> sent
>>> to the SRS for recording. And the policy of the SRS might not 
>>> require
>>> all the metadata it receives. For the sake of data minimization, the 
>>> SRS
>>> MUST NOT record additional metadata that is not explicitly required 
>>> by
>>> local policy. Metadata in storage needs to be provided with a level 
>>> of
>>> security that is comparable to that of the recording session."
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> - 13.2: I think RFCs 3325 and 3326 need to be normative 
>>>>>>>> references.
>>>>>>>> That's an issue for 3325, but section 6.5.1 normatively states 
>>>>>>>> that
>>>>>>>> P-AID
>>>>>>>> is a potential source for nameID. (which should probably be 
>>>>>>>> scoped
>>>>>>>> to
>>>>>>>> only be true for deployments where P-AID makes sense.)
>>>>>>>
>>>>>>> Fine. We can make reference to 3325 and 3326 normative.
>>>>>>
>>>>>> On reflection, I think I've changed my mind on suggesting 3325 be
>>>>>> normative. In the description of the nameID attribute, it would 
>>>>>> be
>>>>>> better to say that nameID is the AoR of the participant, and then
>>>>>> non-normatively mention examples of where that might come from
>>>>>> (including P-AID as one of those examples.)
>>>>>
>>>>> WFM. I will modify the text to make it non-normative.
>>>>>
>>>>> NEW:
>>>>> The AoR is drawn from From header or P-Asserted-Identity header or
>>>>> Remote-Party-ID header.
>>>>
>>>> I suggest going a little further, such as "... For example, the AoR 
>>>> may
>>>> be drawn from the From header field or P-Asserted-Identity header
>>>> field." (eliding RPID as mentioned earlier)
>>>
>>> WFM. Will add the suggested text.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> And now that I look at that paragraph again, I wonder if an
>>>>>> RFC4424/4424bis identity assertion should be listed as an example
>>>>>> source?
>>>>>
>>>>> I am fine with adding RFC4424 Identity assertion header as one 
>>>>> source
>>>>> for
>>>>> nameID.
>>>>
>>>> On reflection, the actual AoR would still come from From, etc, even
>>>> with
>>>> 4474/4474bis. So the mention is probably not needed.
>>>
>>> Ok. Will not add this.
>>>
>>> I will send out diffs with all the comments incorporated soon.
>>>
>>> Regards,
>>> Ram
>>>>
>>>>>
>>>>> Ram
>>>>>
>>>>>>
>>>>>> [...]