Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)
"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Wed, 23 March 2016 16:17 UTC
Return-Path: <rmohanr@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925EF12D725 for <siprec@ietfa.amsl.com>; Wed, 23 Mar 2016 09:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.129
X-Spam-Level:
X-Spam-Status: No, score=-13.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg5TpgMip9DP for <siprec@ietfa.amsl.com>; Wed, 23 Mar 2016 09:17:38 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AA212D716 for <siprec@ietf.org>; Wed, 23 Mar 2016 09:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=181350; q=dns/txt; s=iport; t=1458749857; x=1459959457; h=from:to:cc:subject:date:message-id:mime-version; bh=FGKJ2+q+uyJjA7TibQ5Q0R47GRXNRjbfy319F1nV6Cs=; b=l2wlagaHsc9QxOpAVbij86oO3KsW4cDDzybNwapkYF/5LAqM20Hdhyo5 iOnz6X1pn4CLK+5KgzEea1W+nWD4WEvYzvYtPZ5LAHUsgD8KBWZE8p2Jo mJt3O3cGScaW9poT6fvyiRYNwO5nbBgy1Cn2NMwkL38Rsd0Px213r9Tha 0=;
X-Files: Diff_ draft-ietf-siprec-metadata-21.txt - draft-ietf-siprec-metadata-22.txt.html, draft-ietf-siprec-metadata-22.txt : 54794, 65820
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AZCABKwPJW/5hdJa1UAQmDM1N6BoU7oXKJTgGJc4FtAxcBCYQVgQ1KAhyBITkTAQEBAQEBAWQcC4RBAQEBBAEBAQsMAQwGOAIBBgQHDAYBCBEBAgECASABCwQlCxcGCgQKBAUJBYgZDpMTnQ8GkG8BAQEBAQEBAQEBAQEBAQEBAQEBAQENCIpihAsBBgEEBQIBBQIQJg2CTYJcBYdghVuHTYJSAYMdglOFXII3gWYWN4N/hz2BG4YOgTiHQAEPEgFAgUw3GRSBNWoBiFABHgcWfgEBAQ
X-IronPort-AV: E=Sophos;i="5.24,382,1454976000"; d="txt'?html'217?scan'217,208,217";a="251002536"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2016 16:17:33 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2NGHWuh020981 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 16:17:33 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 12:17:31 -0400
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 12:17:31 -0400
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)
Thread-Index: AQHRhR+AUpwAAGV770CXFo5LOQ8miw==
Date: Wed, 23 Mar 2016 16:17:31 +0000
Message-ID: <D318C156.55FEE%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.71.57]
Content-Type: multipart/mixed; boundary="_003_D318C15655FEErmohanrciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/siprec/qzAcATtUHZqKPwAA5gpDx1SD4RU>
Subject: Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2016 16:17:44 -0000
WG, Please find the diffs attached that addresses the below comments of Ben and also the nits pointed by Alissa/Paul. I will publish this diffs during the IETF week. Regards, Ram -----Original Message----- From: siprec <siprec-bounces@ietf.org> on behalf of Cisco Employee <rmohanr@cisco.com> Date: Tuesday, 22 March 2016 at 9:21 AM To: Ben Campbell <ben@nostrum.com> Cc: "siprec@ietf.org" <siprec@ietf.org>, ART ADs <art-ads@ietf.org>, IESG <iesg@ietf.org> Subject: Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT) >Hi Ben, > >Thanks for your review. See inline > >-----Original Message----- >From: Ben Campbell <ben@nostrum.com> >Date: Monday, 21 March 2016 at 11:39 PM >To: Cisco Employee <rmohanr@cisco.com> >Cc: "siprec@ietf.org" <siprec@ietf.org>, IESG <iesg@ietf.org>, ART ADs ><art-ads@ietf.org> >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 <ben@nostrum.com> >>> Date: Wednesday, 16 March 2016 at 9:36 AM >>> To: Cisco Employee <rmohanr@cisco.com> >>> Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "siprec@ietf.org" >>> <siprec@ietf.org>, "draft-ietf-siprec-metadata@ietf.org" >>> <draft-ietf-siprec-metadata@ietf.org>, The IESG <iesg@ietf.org>, >>> "siprec-chairs@ietf.org" <siprec-chairs@ietf.org>, Brian Rosen >>> <br@brianrosen.net> >>> 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 <ben@nostrum.com> >>>>> Date: Tuesday, 15 March 2016 at 7:52 PM >>>>> To: Cisco Employee <rmohanr@cisco.com> >>>>> Cc: "draft-ietf-siprec-metadata@ietf.org" >>>>> <draft-ietf-siprec-metadata@ietf.org>, "siprec@ietf.org" >>>>> <siprec@ietf.org>, Brian Rosen <br@brianrosen.net>, >>>>> "siprec-chairs@ietf.org" <siprec-chairs@ietf.org> >>>>> 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 <ben@nostrum.com> >>>>>>> Date: Tuesday, 15 March 2016 at 12:36 AM >>>>>>> To: Cisco Employee <rmohanr@cisco.com> >>>>>>> Cc: "draft-ietf-siprec-metadata@ietf.org" >>>>>>> <draft-ietf-siprec-metadata@ietf.org>, "siprec@ietf.org" >>>>>>> <siprec@ietf.org>, Brian Rosen <br@brianrosen.net>, The IESG >>>>>>> <iesg@ietf.org>, "siprec-chairs@ietf.org" <siprec-chairs@ietf.org> >>>>>>> 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 >>>>>>>>> >>>>>>>>>> >>>>>>>>>> [...] > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec
- [siprec] Ben Campbell's No Objection on draft-iet… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Paul Kyzivat
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Paul Kyzivat
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Paul Kyzivat
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Paul Kyzivat
- Re: [siprec] Ben Campbell's No Objection on draft… Paul Kyzivat
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)
- Re: [siprec] Ben Campbell's No Objection on draft… Ben Campbell
- Re: [siprec] Ben Campbell's No Objection on draft… Ram Mohan R (rmohanr)