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

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

Hi Ben,

I just published the new revision. Please review this whenever you get
time.

https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/


Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-21


Thanks,
Ram

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Wednesday, 16 March 2016 at 9:36 AM
To: Cisco Employee <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>, The IESG <[e-mail]>,
"[e-mail]" <[e-mail]>, Brian Rosen
<[e-mail]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

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