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

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

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
>>>>
>>>>>
>>>>> [...]