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

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

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