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

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

(Adding back ADs and IESG)

This version looks mostly good. I have one substantive comment, and a 
few editorial:

# Substantive #

- 10: (Apologies, I missed this when we discussed the text via mail)

I like the change to refer back to the protocol spec for the normative 
bits in the first paragraph. However, saying those procedures MUST be 
implemented doesn't seem right, since 12.3 of that draft says metadata 
SHOULD be protected. That is, the protocol spec says MUST implement, and 
SHOULD use (for metadata).

I propose a simple fix: s/"MUST be implemented by"/"apply for the"   (Or 
"MUST be followed by", if you really want to keep a 2119 statement 
keyword.


# Editorial #

- 6.2, last paragraph: "One instance of a Communication Session 
Group(CS-Group) class namely the CS-Group object provides association or 
grouping all related CS."

Something's not right with that sentence. Is there a missing "for" or 
"of" before "all related CS"? (And shouldn't that be "all related CSs"?

- 6.5.1, name-id:

Consider moving the reference for P-AID to the first mention of it. 
(Yes, I realize that's not really new text ;-) )

- 6.10 "If two SRCs use the same UUID, it MUST retain the UUID/element 
mapping."

Ambiguous antecedent for "it".






On 19 Mar 2016, at 0:56, Ram Mohan R (rmohanr) wrote:

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