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

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

All of your responses look good to me.

Thanks!

Ben.

On 21 Mar 2016, at 22:51, Ram Mohan R (rmohanr) wrote:

> Hi Ben,
>
> Thanks for your review. See inline
>
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Date: Monday, 21 March 2016 at 11:39 PM
> To: Cisco Employee <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, IESG <[e-mail]>, ART ADs
> <[e-mail]>
> Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
> (with COMMENT)
>
>> (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.
>
> I will keep the text to “MUST be followed by”
>
>>
>>
>> # 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"?
>
> Right will add - “of all related CSs”
>
>>
>> - 6.5.1, name-id:
>>
>> Consider moving the reference for P-AID to the first mention of it.
>
> Ok.
>
>>
>> (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."
>
> NEW:
> If two SRCs use the same UUID, they MUST retain the UUID/element mapping.
>
> Regards,
> Ram
>
>>
>> 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
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [...]