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

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

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