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