From nobody Wed Feb 1 02:52:39 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65FF129D1B; Wed, 1 Feb 2017 02:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.219 X-Spam-Level: X-Spam-Status: No, score=-17.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 vDwuow35hrg1; Wed, 1 Feb 2017 02:52:33 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78B4129C65; Wed, 1 Feb 2017 02:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13184; q=dns/txt; s=iport; t=1485946352; x=1487155952; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yO9PcBQYCGvYRZxfMeSLj3Lt/q5tuhChhBFw0vzYmtw=; b=fLLhSLXFpJFKFdRkLhvZcgmWTkJstuOlryEm22VvvAM8MlVNhjll+kzh 4T5V1RVvkAxPmHD6Qbk5Nd6Bu5BigWapAAgLmFhnnTF+7I11K9PcTPK/l VD7E32ZHM4s3J+UwFiPy0GXd2x2DtuZXgG2g0xtljqVmVuOIoNdnPuBig k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQAGvZFY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYEJB4NQigmiEVCCTIIPgg0shXYCGoIrPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRqBiNWEAIBCA4xAwICAjAUBgsCBA4FG4lXDqxPgiWLMwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFiFCCaoQfEQGDIi6CMQWJBYxAhhYBhmaLHIF5hRWJbZMAAR8?= =?us-ascii?q?4dlUVOxEBhGaBSHUBhW+BIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,319,1477958400"; d="scan'208,217";a="201304409" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2017 10:52:31 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v11AqVWR004788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Feb 2017 10:52:31 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 04:52:30 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 04:52:31 -0600 From: "Arun Arunachalam (carunach)" To: Mirja Kuehlewind Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-insipid-logme-reqs-12:_(with_COMMENT)?= Thread-Index: AQHSe99s8wzrsgaLj0CIteOL96PpwaFUX2aA Date: Wed, 1 Feb 2017 10:52:30 +0000 Message-ID: <524AEBF8-B310-43C7-9EE2-11451AE27912@cisco.com> References: <148588026351.2436.5177963089384572158.idtracker@ietfa.amsl.com> In-Reply-To: <148588026351.2436.5177963089384572158.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.58.68] Content-Type: multipart/alternative; boundary="_000_524AEBF8B31043C79EE211451AE27912ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Arun Arunachalam \(carunach\)" , "insipid-chairs@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" , "insipid@ietf.org" , The IESG , "draft-ietf-insipid-logme-reqs@ietf.org" Subject: Re: [Insipid] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-insipid-logme-reqs-12=3A_=28with_COMMENT=29?= X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 10:52:35 -0000 --_000_524AEBF8B31043C79EE211451AE27912ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJldmlldyBhbmQgc2hh cmluZyB5b3VyIGZlZWRiYWNrIQ0KDQpXZSBkaXNjdXNzZWQ8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9pbnNpcGlkL1dXLXpqeXBLaG1pQU1sRlN3Snc0QlZCNVp3Yz4gYWJv dXQgdGhlIG5lZWQgdG8gcHVibGlzaCB0aGUgcmVxdWlyZW1lbnQgZG9jIHdpdGggQmVuIENhbXBi ZWxsIGR1cmluZyBBRCBldmFsdWF0aW9uIHByb2Nlc3MuDQoNCldlIHdvdWxkIGxpa2UgdG8gc2hh cmUga2V5IHBvaW50cyBmcm9tIHRoZSBkaXNjdXNzaW9uIHRvIElFU0cgdGVhbSBmb3IgY29uc2lk ZXJhdGlvbjoNCg0KKDEpIFRoZSBwcmltYXJ5IG9iamVjdGl2ZSBvZiB0aGlzIHJlcXVpcmVtZW50 cyBkcmFmdCBpcyB0byBnaXZlIGFuIGhpZ2gtbGV2ZWwgdW5kZXJzdGFuZGluZyBvZiB0aGUgbW90 aXZhdGluZyBzY2VuYXJpbywgY29uY2VwdCBkZWZpbml0aW9ucyAoZS5nLiBuZXR3b3JrIGJvdW5k YXJ5KSwgYW5kIHByb3ZpZGUgY2xhcml0eSBvbiB0aGUgY29tcGxldGUgbGlzdCBvZiByZXF1aXJl bWVudHMgdGhhdCBhIHByb3Bvc2VkIHNvbHV0aW9uIG5lZWRzIHRvIHNhdGlzZnkuIEluIG91ciBs b2dnaW5nIGFuZCB0cm91Ymxlc2hvb3Rpbmcgc2NlbmFyaW9zLCB0aGUgcmVxdWlyZW1lbnRzIGxp c3QgaGFzIGJlZW4gaWRlbnRpZmllZCB0aHJvdWdoIGRpc2N1c3Npb25zIGFuZCBjb25zZW5zdXMg YW1vbmcgSU5TSVBJRCB3b3JraW5nIGdyb3VwIG1lbWJlcnMuIFRoZSBzb2x1dGlvbiBkcmFmdCBk ZWZpbmVzIHRoZSBwcm90b2NvbCBtZWNoYW5pc20gZGV0YWlscy4gSW1wbGVtZW50b3JzIC8gRGV2 ZWxvcGVycyBhcmUgZXhwZWN0ZWQgdG8gcmVmZXJlbmNlIGJvdGggZG9jdW1lbnRzLg0KDQooMikg SU5TSVBJRCB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGZvbGxvd2luZyB0aGlzIHRvcCBkb3duIGFw cHJvYWNoIGZvciBxdWl0ZSBhIHdoaWxlIGFzIGNhbiBiZWVuIHNlZW4gZnJvbSB0aGUgZGVjaXNp b25zIGZyb20gMjAxMyBhbmQgMjAxNC4gVGhlIGdyb3VwIGhhcyB3b3JrZWQgZm9yIGEgbG9uZyB0 aW1lIG9uIGFjY2VwdGFibGUgcmVxdWlyZW1lbnRzIGFuZCB3ZSB0aGluayB0aGF0IGl0IGlzIHZh bHVhYmxlIHRvIGZyZWV6ZSB0aGVtIG5vdyBhbmQgcHVibGlzaCB0aGVtIGFzIGEgcmVmZXJlbmNl IHRoYXQgZXhwbGFpbnMgdGhlIHByb2JsZW0gc2NvcGUgYW5kIGRlZmluZXMgdGhlIHRhcmdldCBm b3IgdGhlIHNvbHV0aW9uIHRvIGZ1bGZpbC4NCg0KKDMpIFdvcmtpbmcgZ3JvdXAgZGVjaXNpb25z Og0KDQooYSkgSUVURiA4NywgQmVybGluLCAyMDEzIHRoZSBtZWV0aW5nIG5vdGVzIChodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2luc2lwaWQvMDhsN185dnJ6UmxtVjBxR2tn RHhEckJpOElnKSBzYXkgIiBMb2ctbWUgcmVxdWlyZW1lbnRzOiBBbHRlcm5hdGl2ZXMgdG8gTG9n TWUgZHJhZnQgc2hvdWxkIGJlIHN1Ym1pdHRlZCBpbiBmb2xsb3dpbmcgd2Vla3MuIFNvbHV0aW9u IGRyYWZ0IHdpbGwgY29tZSBsYXRlci4iDQooYikgSUVURiA4OCwgVmFuY291dmVyLCAyMDEzLCBp dCBpcyBub3RlZCAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvbWludXRlcy9t aW51dGVzLTg4LWluc2lwaWQpIHRoYXQgIlByb3Bvc2FsIGlzIHRvIHJlbW92ZSB0aGUgc29sdXRp b24gdGV4dCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIGFuZCBhZG9wdCB0aGUgcmVxdWlyZW1lbnRz IHBhcnQgYXMgV0cgZHJhZnQuLSBQYXVsIEs6IEhhZCBhIGJ1bmNoIG9mIGNvbW1lbnRzLiAgTm90 IHN1cmUgdGhlIHN1YnNldCBvZiByZXF1aXJlbWVudHMgaXMgcmVhZHkgdG8gYmUgYWRvcHRlZC4g VGhlcmUgaXMgc3RpbGwgYSBidW5jaCBvZiB0cnVzdCBpc3N1ZXMgd2l0aCBzdG9yaW5nIHRoZSBs b2cuLSBHb256YWxvIFM6IFNvbHV0aW9uIGRpc2N1c3Npb24gaGFzIG5vdCBldmVuIGJlZ3VuIHll dC4gVGhpcyBpcyBwdXJlbHkgdGhlIHJlcXVpcmVtZW50cyB3ZSBhcmUgdGFsa2luZyBhYm91dCIN CihjKSBBbmQgdGhlIHdvcmtpbmcgZ3JvdXAgbWlsZXN0b25lcyBoYXZlIGJlZW4gc3RhYmxlIHNp bmNlIEZlYnJ1YXJ5IDIwMTQgKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv aW5zaXBpZC92eFJScnFfT3hKeUNXWkR0SEQyNVUzMmNoQ28pOg0KIkNoYW5nZWQgbWlsZXN0b25l ICJSZXF1aXJlbWVudHMgZm9yIG1hcmtpbmcgU0lQIHNlc3Npb25zIGZvciBsb2dnaW5nIHRvIElF U0cgKEluZm9ybWF0aW9uYWwpIiwgc2V0IGR1ZSBkYXRlIHRvIFNlcHRlbWJlciAyMDE0IGZyb20g SnVuZSAyMDE0Lg0KQ2hhbmdlZCBtaWxlc3RvbmUgIlByb3RvY29sIGZvciBtYXJraW5nIFNJUCBz ZXNzaW9ucyBmb3IgbG9nZ2luZyB0byBJRVNHIChQcm9wb3NlZCBTdGFuZGFyZCkiLCBzZXQgZHVl IGRhdGUgdG8gRGVjZW1iZXIgMjAxNCBmcm9tIE5vdmVtYmVyIDIwMTQu4oCdDQoNClRoYW5rcyEN CkFydW4gJiBQZXRlciAoY28tYXV0aG9ycykNCg0KDQoNCg0KT24gSmFuIDMxLCAyMDE3LCBhdCAx MTozMSBBTSwgTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldDxtYWlsdG86aWV0 ZkBrdWVobGV3aW5kLm5ldD4+IHdyb3RlOg0KDQpNaXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1pbnNpcGlkLWxv Z21lLXJlcXMtMTI6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1s DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaW5zaXBpZC1sb2dtZS1yZXFzLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09N TUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSSBkb24ndCBzZWUgYSB2YWx1ZSBpbiBwdWJsaXNoaW5n IHRoaXMgZHJhZnQgYXMgYSBzdGFuZC1hbG9uZSBkb2N1bWVudC4NCklmIG5lZWRlZCBjb250ZW50 IGNhbiBiZSBtZXJnZWQgaW50byBkcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtbWFya2luZw0KKG1h eWJlIGluIHRoZSBhcHBlbmRpeCk7IGVzcGVjaWFsbHkgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGJlbG9uZyBpbg0KdGhlIHNwZWMgaXRzZWxmLg0KDQoNCg0K --_000_524AEBF8B31043C79EE211451AE27912ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9298F2980B140D48827B92E6A8C22D36@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBNaXJq YSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRo YW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJldmlldyBhbmQgc2hhcmluZyB5b3VyIGZlZWRi YWNrITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+V2UmbmJzcDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2luc2lwaWQvV1ctemp5cEtobWlBTWxGU3dKdzRCVkI1WndjIiBjbGFzcz0iIj5kaXNjdXNz ZWQ8L2E+Jm5ic3A7YWJvdXQgdGhlIG5lZWQgdG8gcHVibGlzaCB0aGUgcmVxdWlyZW1lbnQgZG9j IHdpdGggQmVuIENhbXBiZWxsIGR1cmluZyBBRCBldmFsdWF0aW9uIHByb2Nlc3MuJm5ic3A7PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5X ZSB3b3VsZCBsaWtlIHRvIHNoYXJlIGtleSBwb2ludHMgZnJvbSB0aGUgZGlzY3Vzc2lvbiB0byBJ RVNHIHRlYW0gZm9yIGNvbnNpZGVyYXRpb246PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPigxKSBUaGUgcHJpbWFyeSBvYmpl Y3RpdmUgb2YgdGhpcyByZXF1aXJlbWVudHMgZHJhZnQgaXMgdG8gZ2l2ZSBhbiBoaWdoLWxldmVs IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG1vdGl2YXRpbmcgc2NlbmFyaW8sIGNvbmNlcHQgZGVmaW5p dGlvbnMgKGUuZy4gbmV0d29yayBib3VuZGFyeSksIGFuZCBwcm92aWRlIGNsYXJpdHkgb24gdGhl IGNvbXBsZXRlIGxpc3Qgb2YgcmVxdWlyZW1lbnRzIHRoYXQgYSBwcm9wb3NlZCBzb2x1dGlvbg0K IG5lZWRzIHRvIHNhdGlzZnkuIEluIG91ciBsb2dnaW5nIGFuZCB0cm91Ymxlc2hvb3Rpbmcgc2Nl bmFyaW9zLCB0aGUgcmVxdWlyZW1lbnRzIGxpc3QgaGFzIGJlZW4gaWRlbnRpZmllZCB0aHJvdWdo IGRpc2N1c3Npb25zIGFuZCBjb25zZW5zdXMgYW1vbmcgSU5TSVBJRCB3b3JraW5nIGdyb3VwIG1l bWJlcnMuIFRoZSBzb2x1dGlvbiBkcmFmdCBkZWZpbmVzIHRoZSBwcm90b2NvbCBtZWNoYW5pc20g ZGV0YWlscy4mbmJzcDtJbXBsZW1lbnRvcnMgLyBEZXZlbG9wZXJzDQogYXJlIGV4cGVjdGVkIHRv IHJlZmVyZW5jZSBib3RoIGRvY3VtZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPigyKSBJTlNJUElEIHdvcmtpbmcgZ3JvdXAgaGFz IGJlZW4gZm9sbG93aW5nIHRoaXMgdG9wIGRvd24gYXBwcm9hY2ggZm9yIHF1aXRlIGEgd2hpbGUg YXMgY2FuIGJlZW4gc2VlbiBmcm9tIHRoZSBkZWNpc2lvbnMgZnJvbSAyMDEzIGFuZCAyMDE0LiBU aGUgZ3JvdXAgaGFzIHdvcmtlZCBmb3IgYSBsb25nIHRpbWUgb24gYWNjZXB0YWJsZSByZXF1aXJl bWVudHMgYW5kIHdlIHRoaW5rIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8gZnJlZXplDQogdGhlbSBu b3cgYW5kIHB1Ymxpc2ggdGhlbSBhcyBhIHJlZmVyZW5jZSB0aGF0IGV4cGxhaW5zIHRoZSBwcm9i bGVtIHNjb3BlIGFuZCBkZWZpbmVzIHRoZSB0YXJnZXQgZm9yIHRoZSBzb2x1dGlvbiB0byBmdWxm aWwuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4oMykgV29ya2luZyBncm91cCBkZWNpc2lvbnM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4oYSkgSUVURiA4NywgQmVybGluLCAy MDEzIHRoZSBtZWV0aW5nIG5vdGVzICg8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL2luc2lwaWQvMDhsN185dnJ6UmxtVjBxR2tnRHhEckJpOElnIiBjbGFzcz0i Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2luc2lwaWQvMDhsN185dnJ6 UmxtVjBxR2tnRHhEckJpOElnPC9hPikgc2F5ICZxdW90OyBMb2ctbWUgcmVxdWlyZW1lbnRzOg0K IEFsdGVybmF0aXZlcyB0byBMb2dNZSBkcmFmdCBzaG91bGQgYmUgc3VibWl0dGVkIGluIGZvbGxv d2luZyB3ZWVrcy4gU29sdXRpb24gZHJhZnQgd2lsbCBjb21lIGxhdGVyLiZxdW90OzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4oYikgSUVURiA4OCwgVmFuY291dmVyLCAyMDEzLCBpdCBpcyBub3RlZCAo PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvbWludXRlcy9taW51 dGVzLTg4LWluc2lwaWQiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzg4L21pbnV0ZXMvbWludXRlcy04OC1pbnNpcGlkPC9hPikgdGhhdCAmcXVvdDtQcm9wb3NhbCBp cyB0byByZW1vdmUgdGhlIHNvbHV0aW9uIHRleHQgaW4gdGhlDQogY3VycmVudCB2ZXJzaW9uIGFu ZCBhZG9wdCB0aGUgcmVxdWlyZW1lbnRzIHBhcnQgYXMgV0cgZHJhZnQuLSBQYXVsIEs6IEhhZCBh IGJ1bmNoIG9mIGNvbW1lbnRzLiAmbmJzcDtOb3Qgc3VyZSB0aGUgc3Vic2V0IG9mIHJlcXVpcmVt ZW50cyBpcyByZWFkeSB0byBiZSBhZG9wdGVkLiBUaGVyZSBpcyBzdGlsbCBhIGJ1bmNoIG9mIHRy dXN0IGlzc3VlcyB3aXRoIHN0b3JpbmcgdGhlIGxvZy4tIEdvbnphbG8gUzogU29sdXRpb24gZGlz Y3Vzc2lvbiBoYXMgbm90DQogZXZlbiBiZWd1biB5ZXQuIFRoaXMgaXMgcHVyZWx5IHRoZSByZXF1 aXJlbWVudHMgd2UgYXJlIHRhbGtpbmcgYWJvdXQmcXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ KGMpIEFuZCB0aGUgd29ya2luZyBncm91cCBtaWxlc3RvbmVzIGhhdmUgYmVlbiBzdGFibGUgc2lu Y2UgRmVicnVhcnkgMjAxNCAoPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9pbnNpcGlkL3Z4UlJycV9PeEp5Q1daRHRIRDI1VTMyY2hDbyIgY2xhc3M9IiI+aHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pbnNpcGlkL3Z4UlJycV9PeEp5Q1da RHRIRDI1VTMyY2hDbzwvYT4pOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mcXVvdDtDaGFuZ2VkIG1p bGVzdG9uZSAmcXVvdDtSZXF1aXJlbWVudHMgZm9yIG1hcmtpbmcgU0lQIHNlc3Npb25zIGZvciBs b2dnaW5nIHRvIElFU0cgKEluZm9ybWF0aW9uYWwpJnF1b3Q7LCBzZXQgZHVlIGRhdGUgdG8gU2Vw dGVtYmVyIDIwMTQgZnJvbSBKdW5lIDIwMTQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoYW5nZWQg bWlsZXN0b25lICZxdW90O1Byb3RvY29sIGZvciBtYXJraW5nIFNJUCBzZXNzaW9ucyBmb3IgbG9n Z2luZyB0byBJRVNHIChQcm9wb3NlZCBTdGFuZGFyZCkmcXVvdDssIHNldCBkdWUgZGF0ZSB0byBE ZWNlbWJlciAyMDE0IGZyb20gTm92ZW1iZXIgMjAxNC7igJ08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFydW4gJmFt cDsgUGV0ZXIgKGNvLWF1dGhvcnMpPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPk9uIEphbiAzMSwgMjAxNywgYXQgMTE6MzEgQU0sIE1pcmphIEt1ZWhsZXdp bmQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiBjbGFzcz0iIj5pZXRm QGt1ZWhsZXdpbmQubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWlyamEg S8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8 YnIgY2xhc3M9IiI+DQpkcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtcmVxcy0xMjogTm8gT2JqZWN0 aW9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyIGNsYXNzPSIi Pg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXM8YnIgY2xhc3M9IiI+DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBo b3dldmVyLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVh c2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnIgY2xhc3M9IiI+DQpmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtcmVxcy8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaW5zaXBpZC1sb2dtZS1yZXFzLzwvYT48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KQ09NTUVOVDo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBkb24ndCBzZWUgYSB2YWx1ZSBpbiBw dWJsaXNoaW5nIHRoaXMgZHJhZnQgYXMgYSBzdGFuZC1hbG9uZSBkb2N1bWVudC48YnIgY2xhc3M9 IiI+DQpJZiBuZWVkZWQgY29udGVudCBjYW4gYmUgbWVyZ2VkIGludG8gZHJhZnQtaWV0Zi1pbnNp cGlkLWxvZ21lLW1hcmtpbmc8YnIgY2xhc3M9IiI+DQoobWF5YmUgaW4gdGhlIGFwcGVuZGl4KTsg ZXNwZWNpYWxseSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYmVsb25nIGluPGJyIGNsYXNz PSIiPg0KdGhlIHNwZWMgaXRzZWxmLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_524AEBF8B31043C79EE211451AE27912ciscocom_-- From nobody Wed Feb 1 03:34:39 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB4129D1C for ; Wed, 1 Feb 2017 03:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 rh_MiY5Q9kIZ for ; Wed, 1 Feb 2017 03:34:33 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601C2126B6D for ; Wed, 1 Feb 2017 03:34:32 -0800 (PST) Received: (qmail 18259 invoked from network); 1 Feb 2017 12:27:49 +0100 Received: from p5dec2a82.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.130) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Feb 2017 12:27:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <524AEBF8-B310-43C7-9EE2-11451AE27912@cisco.com> Date: Wed, 1 Feb 2017 12:27:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20B994B3-45AB-4AF7-A673-CA877E3FADBB@kuehlewind.net> References: <148588026351.2436.5177963089384572158.idtracker@ietfa.amsl.com> <524AEBF8-B310-43C7-9EE2-11451AE27912@cisco.com> To: "Arun Arunachalam (carunach)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "insipid-chairs@ietf.org" , "insipid@ietf.org" , The IESG , "draft-ietf-insipid-logme-reqs@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [Insipid] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-insipid-logme-reqs-12=3A_=28with_COMMENT=29?= X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 11:34:37 -0000 Hi Arun, Hi Peter, I do see well the value of having and working on this document in the wg = process. I just don=E2=80=99t see any archivable value of it that = justifies to run through the IETF process to the end and publish it as = an RFC. Alternatively, you can simply declare this document as done in the wg = (also mark the milestone as done) and potentially copy parts of it in = (the appendix of) the final protocol document if you still think by then = that there are parts that should be achieved in the RFC series. Again, I don=E2=80=99t think this document has a stand-alone value for = anybody who is not involved in the wg process and I don=E2=80=99t think = it will have any historical value in future, and therefore this document = does not need to be published in the RFC series. Mirja > Am 01.02.2017 um 11:52 schrieb Arun Arunachalam (carunach) = : >=20 > Hi Mirja, >=20 > Thanks for taking the time to review and sharing your feedback! >=20 > We discussed about the need to publish the requirement doc with Ben = Campbell during AD evaluation process.=20 >=20 > We would like to share key points from the discussion to IESG team for = consideration: >=20 > (1) The primary objective of this requirements draft is to give an = high-level understanding of the motivating scenario, concept definitions = (e.g. network boundary), and provide clarity on the complete list of = requirements that a proposed solution needs to satisfy. In our logging = and troubleshooting scenarios, the requirements list has been identified = through discussions and consensus among INSIPID working group members. = The solution draft defines the protocol mechanism details. Implementors = / Developers are expected to reference both documents. >=20 > (2) INSIPID working group has been following this top down approach = for quite a while as can been seen from the decisions from 2013 and = 2014. The group has worked for a long time on acceptable requirements = and we think that it is valuable to freeze them now and publish them as = a reference that explains the problem scope and defines the target for = the solution to fulfil. >=20 > (3) Working group decisions: >=20 > (a) IETF 87, Berlin, 2013 the meeting notes = (https://mailarchive.ietf.org/arch/msg/insipid/08l7_9vrzRlmV0qGkgDxDrBi8Ig= ) say " Log-me requirements: Alternatives to LogMe draft should be = submitted in following weeks. Solution draft will come later." > (b) IETF 88, Vancouver, 2013, it is noted = (https://www.ietf.org/proceedings/88/minutes/minutes-88-insipid) that = "Proposal is to remove the solution text in the current version and = adopt the requirements part as WG draft.- Paul K: Had a bunch of = comments. Not sure the subset of requirements is ready to be adopted. = There is still a bunch of trust issues with storing the log.- Gonzalo S: = Solution discussion has not even begun yet. This is purely the = requirements we are talking about" > (c) And the working group milestones have been stable since February = 2014 = (https://mailarchive.ietf.org/arch/msg/insipid/vxRRrq_OxJyCWZDtHD25U32chCo= ): > "Changed milestone "Requirements for marking SIP sessions for logging = to IESG (Informational)", set due date to September 2014 from June 2014. > Changed milestone "Protocol for marking SIP sessions for logging to = IESG (Proposed Standard)", set due date to December 2014 from November = 2014.=E2=80=9D >=20 > Thanks! > Arun & Peter (co-authors) >=20 >=20 >=20 >=20 >> On Jan 31, 2017, at 11:31 AM, Mirja Kuehlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-insipid-logme-reqs-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I don't see a value in publishing this draft as a stand-alone = document. >> If needed content can be merged into draft-ietf-insipid-logme-marking >> (maybe in the appendix); especially the security considerations = belong in >> the spec itself. >>=20 >>=20 >=20 From nobody Wed Feb 1 04:14:38 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDFC12997E for ; Wed, 1 Feb 2017 04:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148595127664.24476.10689397018292271830.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 04:14:36 -0800 From: IETF Secretariat Archived-At: Subject: [Insipid] Milestones changed for insipid WG X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 12:14:36 -0000 Changed milestone "Requirements for marking SIP sessions for logging to IESG (Informational)", resolved as "Done". Changed milestone "Specification of the new identifier sent to the IESG (Proposed Standard)", resolved as "Done". Changed milestone "Protocol for marking SIP sessions for logging to IESG (Proposed Standard)", set due date to June 2017 from December 2014. URL: https://datatracker.ietf.org/wg/insipid/charter/ From nobody Wed Feb 1 06:22:34 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7661293EE; Wed, 1 Feb 2017 06:22:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 06:22:29 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:22:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Note that I'm balloting no-objection here. If some of these things weren't fixed, I'd be a DISCUSS ballot when the protocol spec turned up, should I still be on the IESG at that point (which I guess is unlikely:-) - 3.2: I think "trust domain" isn't a great term, and doesn't really match the definition offered well. You're including the entire "source" operator plus the bits of any other operator that have agreed to help the source-operator with logging. I don't think that set of things is really a domain. Nor are the things in that set "trusted" except to do this logging stuff properly. It's also not clear to me if the relevant set is meant to differ per-call, or to be the same for all calls that a source-operator might originate. - 5.1: REQ1 seems to me to ignore privacy in one bad respect - isn't the right thing to log the entire message *except* bits that are considered sensitive by the logging entity concerned? E.g. any secrets or PII in the SIP message may be best not logged. Forcing everyone to log the entire thing would seem brittle to me - it may cause operators to not co-operate with one another esp if data privacy laws differ between them. (Or maybe more likely, the logs will not have the sensitive bits, or will eventually have them XXXX'd out.) - REQ9: Not quite sure, but I wonder are there additional requirements for intermediaries inserting this that aren't covered. For example, that that not be (ab)used for other than diagnostics and hence ought not be on by default and maybe more. I think the thing to do is to get someone to do a privacy analysis of this situation before the protocol spec is done - some minor changes might make a biggish difference there. - 6.1: See above wrt 3.2. I'm not convinced that there is such a thing as a "trust domain boundary" as you use the term. I think (not sure) that may mean that logme stuff is either dropped on ingress or else never dropped which'd seem like a bad outcome. From nobody Wed Feb 1 10:27:28 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F096A129884; Wed, 1 Feb 2017 10:27:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148597364396.19190.12631093359396427570.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 10:27:23 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Alissa Cooper's Abstain on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 18:27:24 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Agree with Alvaro. From nobody Wed Feb 1 12:15:47 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8E129EC8; Wed, 1 Feb 2017 12:15:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148598013597.19147.1512173812823544536.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 12:15:35 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Suresh Krishnan's Abstain on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:15:37 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do see the value in the content of this document, but I do not see the value of publishing it as a separate RFC at this point of time. I think it should be merged into the solution document. From nobody Wed Feb 1 12:18:52 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0DE1299D7; Wed, 1 Feb 2017 12:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.354 X-Spam-Level: X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oHWHKtPCmJyw; Wed, 1 Feb 2017 12:18:44 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E04B1299A3; Wed, 1 Feb 2017 12:18:43 -0800 (PST) Received: from [193.109.254.3] by server-8.bemta-6.messagelabs.com id 9A/FB-21675-1A242985; Wed, 01 Feb 2017 20:18:41 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRWlGSWpSXmKPExsWi75nTo7vQaVK EwYyDfBZHt71gsZg7xc9ixp+JzBaPHv1gsph//xmTxfS919gd2Dym/N7I6rG2+yqbx5IlP5kC mKNYM/OS8isSWDNO/rjFXnDFtOLSTrYGxs06XYxcHEIC2xglLl8/zwjhHGKU6N+3kB3OeXv4G yuEs5FR4t21hSxdjBwcbAL2EjP2xHQxcnKICHhKPOw7xQJSwyxwn1Fi49IfzCA1wgJZEhtfBk DUZEvMfXGdDcI2kni+9CkriM0ioCJxe+8GdhCbVyBUYvaRxWwgrUICPhIbv5iAhDkFfCW2v7j PAmIzCshKfGlczQxiMwuIS9x6Mp8JxJYQEJBYsuc8M4QtKvHy8T9WiBodiQW7P7FB2NoSyxa+ ZoZYJShxcuYTsJlCAqoS/1YuYprAKDYLydhZSNpnIWmfhaR9ASPLKkaN4tSistQiXUNTvaSiz PSMktzEzBxdQwMzvdzU4uLE9NScxKRiveT83E2MwFhkAIIdjN+WBRxilORgUhLljX8wMUKILy k/pTIjsTgjvqg0J7X4EKMMB4eSBO8Xh0kRQoJFqempFWmZOcCkAJOW4OBREuGtA0nzFhck5hZ npkOkTjEqSonzJjgCJQRAEhmleXBtsER0iVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8TCBT eDLzSuCmvwJazAS02P1VH8jikkSElFQDo/vTEgVmzrkpqndvbnsudOpvUJfwuodP67lSlxl9r NlsHeR+kidqQfOcgzuC2C76H5rnIqOrkDJ7Im+wbnCA8O8CjgDtXCana5sObbxeePPDvdqfSl snml5ya5QqKXvBkrLMmu2g7IFpLa5zVSbp1TN0mz5dsYbJsNTu6KU0lmsb/s2Qslr6TYmlOCP RUIu5qDgRANfxujk/AwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-15.tower-184.messagelabs.com!1485980320!94036112!1 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29637 invoked from network); 1 Feb 2017 20:18:41 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.140) by server-15.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 1 Feb 2017 20:18:41 -0000 Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Feb 2017 21:18:40 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH11W.internal.vodafone.com (47.73.211.209) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 1 Feb 2017 21:18:40 +0100 Received: from VOEXC17W.internal.vodafone.com (145.230.101.19) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 1 Feb 2017 21:18:40 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc17w.internal.vodafone.com ([145.230.101.19]) with mapi id 14.03.0294.000; Wed, 1 Feb 2017 21:18:39 +0100 From: "Dawes, Peter, Vodafone Group" To: Stephen Farrell , The IESG Thread-Topic: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) Thread-Index: AQHSfJajavmJxKZqI0yQ0voTpeKlMqFUlS7Q Date: Wed, 1 Feb 2017 20:18:38 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com> References: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> In-Reply-To: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" , "draft-ietf-insipid-logme-reqs@ietf.org" , "insipid-chairs@ietf.org" , "gsalguei@cisco.com" Subject: Re: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:18:47 -0000 Hello Stephen, Thanks for the in-depth review of the draft. Some responses below. Best regards, Peter and Arun (co-authors) > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Stephen Farr= ell > Sent: 01 February 2017 14:22 > To: The IESG > Cc: insipid@ietf.org; insipid-chairs@ietf.org; draft-ietf-insipid-logme- > reqs@ietf.org; gsalguei@cisco.com > Subject: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-l= ogme- > reqs-12: (with COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-insipid-logme-reqs-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Note that I'm balloting no-objection here. If some of these things weren'= t > fixed, I'd be a DISCUSS ballot when the protocol spec turned up, should I= still > be on the IESG at that point (which I guess is unlikely:-) >=20 > - 3.2: I think "trust domain" isn't a great term, and doesn't really matc= h the > definition offered well. You're including the entire "source" operator pl= us the > bits of any other operator that have agreed to help the source-operator w= ith > logging. I don't think that set of things is really a domain. Nor are the= things in > that set "trusted" except to do this logging stuff properly. It's also no= t clear to > me if the relevant set is meant to differ per-call, or to be the same for= all calls > that a source-operator might originate. >=20 The term "trust domain" appears in RFC 3324 (referred to by RFC 3325, RFC 7= 316) and RFC 6404. In the 3GPP profile of SIP, it appears in TS 24.229. RFC= 3324 concerns network asserted identities and defines a trust domain as a = collection of nodes with secure connections that have configuration informa= tion on which connected nodes to trust.=20 RFC 6404 concerns security threats related to the interconnection of servic= e providers. SIP service providers (SSPs) who have a peering or transit con= tract are in the trust domain, others are not: "Each SSP may have connectio= ns to one or more remote SSPs through peering or transit contracts. A pote= ntially compromised remote SSP that attacks other SSPs is out of the scope = of this document; this document focuses on attacks on an SSP from outside t= he trust domain such an SSP may have with other SSPs.". The TS 24.229 description of the trust domain (clause 4.4) includes the fo= llowing excerpts "For the IM CN subsystem, this trust domain consists of th= e functional entities that belong to the same operator's network " and " Ad= ditionally, other nodes within the IM CN subsystem that are not part of the= same operator's domain may or may not be part of the trust domain, dependi= ng on whether an interconnect agreement exists with the remote network. " a= nd " Within the IM CN subsystem trust domains will be applied to a number o= f header fields. These trust domains do not necessarily contain the same fu= nctional entities or cover the same operator domains." The use of trust domain in logme-reqs is similar to its use in RFC 6404 and= TS 24.229. The trust domain needs a wide scope in terms of included networ= ks because one of the reasons for the logme mechanism is the unpredictabili= ty in advance of SIP routing through multiple connected service providers, = transit networks, etc. It is also important to define trust domain as it ap= plies specifically to "logme marking" as a protocol element because trust d= omain does not always impact all parts of SIP equally.=20 logme marking is expected to be applied for regression testing and troubles= hooting. It will often be pre-arranged and involve a SIP client specificall= y for testing owned and operated by a service provider. The trust domain is= not expected to change from call to call but only a very small subset of c= alls will be used for testing. > - 5.1: REQ1 seems to me to ignore privacy in one bad respect - isn't the = right > thing to log the entire message > *except* bits that are considered sensitive by the logging entity concern= ed? > E.g. any secrets or PII in the SIP message may be best not logged. Forcin= g > everyone to log the entire thing would seem brittle to me - it may cause > operators to not co-operate with one another esp if data privacy laws dif= fer > between them. (Or maybe more likely, the logs will not have the sensitive > bits, or will eventually have them XXXX'd out.) >=20 Specifying logging the entire message means that troubleshooting tools will= know they have all fields. Privacy might require that one service provider= remove some protocol elements before passing a SIP message to a peer servi= ce provider, logme marking won't be able to bring them back. Within a servi= ce provider, logging must obey data protection laws regardless of any RFC. If the user needs privacy, their user agent should follow the procedures do= cumented in RFC 3323. This way we can avoid imposing privacy related requir= ements on SIP entities that log messages. > - REQ9: Not quite sure, but I wonder are there additional requirements fo= r > intermediaries inserting this that aren't covered. For example, that that= not > be (ab)used for other than diagnostics and hence ought not be on by defau= lt > and maybe more. I think the thing to do is to get someone to do a privacy > analysis of this situation before the protocol spec is done - some minor > changes might make a biggish difference there. We can do a privacy analysis as part of the solution. >=20 > - 6.1: See above wrt 3.2. I'm not convinced that there is such a thing as= a > "trust domain boundary" as you use the term. I think (not sure) that may > mean that logme stuff is either dropped on ingress or else never dropped > which'd seem like a bad outcome. Logme marking of a SIP request will be present until a SIP message is passe= d to a peer service provider that is not part of the prior logging agreemen= t, and then it will be removed. Note that a response to that request might = be logme marked as it re-enters the service provider that removed it from t= he request. >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Wed Feb 1 12:57:17 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52312958A; Wed, 1 Feb 2017 12:57:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148598262942.18688.17689106924752475566.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 12:57:09 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Kathleen Moriarty's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:57:09 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In addition to Stephen's questions, I would like to see a little more text in the following sentence of the Security Considerations section: OLD: If a prior agreement to log sessions exists with the next hop network then the "log me" marker SHOULD NOT be removed. NEW: (or something similar that ties this back to requirement 7) If a prior agreement to log sessions, at a debugging or regression testing level for data, exists with the next hop network then the "log me" marker SHOULD NOT be removed. That requirement only shows up in one place (as far as I could see and I think it would be helpful in the security considerations section as it shows the limited scope of use besides the "trust domain" (name may be changed?). Note that I am balloting No Objection as this is part of the WG's charter (also pointed out in the SecDir review). From nobody Wed Feb 1 14:12:48 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA51295B7; Wed, 1 Feb 2017 14:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 r6iMJuCBiTSR; Wed, 1 Feb 2017 14:12:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7B71295A1; Wed, 1 Feb 2017 14:12:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E4A15BE38; Wed, 1 Feb 2017 22:12:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0ChXVfFNpGW; Wed, 1 Feb 2017 22:12:36 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E87CBE2D; Wed, 1 Feb 2017 22:12:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485987155; bh=AQheD7e//SEzAGwE2hAK35LWVQzZgaOvWXDH61ZHJJE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=o9ok0sVvo9I5rMGmS7Kfov0JhR9cgIbe3GKcPDF4CkeLtV4fW0XipV2BC/GIZzYHn IHIkOw5+HcxHK32Y/IOD+UzRq38srpni0e/2kF8tw/Mlq395IvaOTgjT1TMVa52H2G qkz4CtYlzMHBy1DaX2G2D+ivmBfTqrV/U4QkO1oE= To: "Dawes, Peter, Vodafone Group" , The IESG References: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5b2e4d39-5646-27f2-a7c2-639404f1c70b@cs.tcd.ie> Date: Wed, 1 Feb 2017 22:12:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000508050904060402090207" Archived-At: Cc: "insipid@ietf.org" , "insipid-chairs@ietf.org" , "draft-ietf-insipid-logme-reqs@ietf.org" , "gsalguei@cisco.com" Subject: Re: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:12:43 -0000 This is a cryptographically signed message in MIME format. --------------ms000508050904060402090207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, I don't suggest that we get into it in detail - if needed that'd be better done during IESG evaluation of the solution draft, but I have to say that no matter how many other documents have the same concept, I think it's a broken concept:-) The "it" I mean is to consider the set of {all machines controlled by one operator plus all the other machines needed for one or a set of calls originated by that operator} as a "domain." That'd be like considering the set of {routers affected by a BGP announcement plus all the machines in the original AS} as a domain, which I don't think makes any more sense. Again though, I don't think we need to bottom out on this now, but I suspect things'll work out better if the solution document doesn't depend much on that "trust domain" (IMO non-)concept. Cheers, S. On 01/02/17 20:18, Dawes, Peter, Vodafone Group wrote: > Hello Stephen, Thanks for the in-depth review of the draft. Some > responses below. >=20 > Best regards, Peter and Arun (co-authors) >=20 >> -----Original Message----- From: insipid >> [mailto:insipid-bounces@ietf.org] On Behalf Of Stephen Farrell=20 >> Sent: 01 February 2017 14:22 To: The IESG Cc: insipid@ietf.org; >> insipid-chairs@ietf.org; draft-ietf-insipid-logme- reqs@ietf.org; >> gsalguei@cisco.com Subject: [Insipid] Stephen Farrell's No >> Objection on draft-ietf-insipid-logme- reqs-12: (with COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-insipid-logme-reqs-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here:=20 >> https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 Note that I'm balloting no-objection here. If some of these things weren'= t >> fixed, I'd be a DISCUSS ballot when the protocol spec turned up, >> should I still be on the IESG at that point (which I guess is >> unlikely:-) >>=20 >> - 3.2: I think "trust domain" isn't a great term, and doesn't >> really match the definition offered well. You're including the >> entire "source" operator plus the bits of any other operator that >> have agreed to help the source-operator with logging. I don't think >> that set of things is really a domain. Nor are the things in that >> set "trusted" except to do this logging stuff properly. It's also >> not clear to me if the relevant set is meant to differ per-call, or >> to be the same for all calls that a source-operator might >> originate. >>=20 >=20 > The term "trust domain" appears in RFC 3324 (referred to by RFC 3325, > RFC 7316) and RFC 6404. In the 3GPP profile of SIP, it appears in TS > 24.229. RFC 3324 concerns network asserted identities and defines a > trust domain as a collection of nodes with secure connections that > have configuration information on which connected nodes to trust. >=20 > RFC 6404 concerns security threats related to the interconnection of > service providers. SIP service providers (SSPs) who have a peering or > transit contract are in the trust domain, others are not: "Each SSP > may have connections to one or more remote SSPs through peering or > transit contracts. A potentially compromised remote SSP that attacks > other SSPs is out of the scope of this document; this document > focuses on attacks on an SSP from outside the trust domain such an > SSP may have with other SSPs.". >=20 > The TS 24.229 description of the trust domain (clause 4.4) includes > the following excerpts "For the IM CN subsystem, this trust domain > consists of the functional entities that belong to the same > operator's network " and " Additionally, other nodes within the IM CN > subsystem that are not part of the same operator's domain may or may > not be part of the trust domain, depending on whether an interconnect > agreement exists with the remote network. " and " Within the IM CN > subsystem trust domains will be applied to a number of header fields. > These trust domains do not necessarily contain the same functional > entities or cover the same operator domains." >=20 > The use of trust domain in logme-reqs is similar to its use in RFC > 6404 and TS 24.229. The trust domain needs a wide scope in terms of > included networks because one of the reasons for the logme mechanism > is the unpredictability in advance of SIP routing through multiple > connected service providers, transit networks, etc. It is also > important to define trust domain as it applies specifically to "logme > marking" as a protocol element because trust domain does not always > impact all parts of SIP equally. >=20 > logme marking is expected to be applied for regression testing and > troubleshooting. It will often be pre-arranged and involve a SIP > client specifically for testing owned and operated by a service > provider. The trust domain is not expected to change from call to > call but only a very small subset of calls will be used for testing. >=20 >> - 5.1: REQ1 seems to me to ignore privacy in one bad respect - >> isn't the right thing to log the entire message *except* bits that >> are considered sensitive by the logging entity concerned? E.g. any >> secrets or PII in the SIP message may be best not logged. Forcing=20 >> everyone to log the entire thing would seem brittle to me - it may >> cause operators to not co-operate with one another esp if data >> privacy laws differ between them. (Or maybe more likely, the logs >> will not have the sensitive bits, or will eventually have them >> XXXX'd out.) >>=20 >=20 > Specifying logging the entire message means that troubleshooting > tools will know they have all fields. Privacy might require that one > service provider remove some protocol elements before passing a SIP > message to a peer service provider, logme marking won't be able to > bring them back. Within a service provider, logging must obey data > protection laws regardless of any RFC. >=20 > If the user needs privacy, their user agent should follow the > procedures documented in RFC 3323. This way we can avoid imposing > privacy related requirements on SIP entities that log messages. >=20 >> - REQ9: Not quite sure, but I wonder are there additional >> requirements for intermediaries inserting this that aren't covered. >> For example, that that not be (ab)used for other than diagnostics >> and hence ought not be on by default and maybe more. I think the >> thing to do is to get someone to do a privacy analysis of this >> situation before the protocol spec is done - some minor changes >> might make a biggish difference there. >=20 > We can do a privacy analysis as part of the solution. >=20 >>=20 >> - 6.1: See above wrt 3.2. I'm not convinced that there is such a >> thing as a "trust domain boundary" as you use the term. I think >> (not sure) that may mean that logme stuff is either dropped on >> ingress or else never dropped which'd seem like a bad outcome. >=20 > Logme marking of a SIP request will be present until a SIP message is > passed to a peer service provider that is not part of the prior > logging agreement, and then it will be removed. Note that a response > to that request might be logme marked as it re-enters the service > provider that removed it from the request. >=20 >>=20 >>=20 >> _______________________________________________ insipid mailing >> list insipid@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/insipid >=20 --------------ms000508050904060402090207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEy MjEyMzRaMC8GCSqGSIb3DQEJBDEiBCDAzH5dkN1IvQ9tYN8ojg1M7nl9TuYrGC3zvWOtU7tH DzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBuFSuI8/WMQuFi558DA3Xn7klPAN4k3mHFLSTuU8pSaZE8G+7l3ShZ kxSgKEFG/FTSQFbtFSSbnHEKysPIR129Bw68qwBQb9C0AZtg9PR0IdlrCrdoirc+jfiL8ayV ihIRxy1DrwdHsK/xJoLO66EIoZMQPnuv5EBh1rBG8TsPUcWMw2grsUQQRbxVbus3xmPz8whN 3Jcnvz7LLxKq8wprpfLloMsediXcYxjR4YgXZOFZyoH1Yib0CvHJv76PhRnPDMRJ151zwLju SdZhxcEu1GwJ7KYS3WVrxFnKeOx1tLPgLeHpb+eXUyS14IaX2N0Zxut/WAiT2WsX+1LMcw4a AAAAAAAA --------------ms000508050904060402090207-- From nobody Wed Feb 1 15:23:42 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9821295E7; Wed, 1 Feb 2017 15:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no 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 SyWPXTl7iKqC; Wed, 1 Feb 2017 15:23:39 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2ED129577; Wed, 1 Feb 2017 15:23:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 90EA12D299; Thu, 2 Feb 2017 01:23:38 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyyvfGSRK1FM; Thu, 2 Feb 2017 01:23:38 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id CA8F42CC9B; Thu, 2 Feb 2017 01:23:37 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_688E80DB-0F2C-409F-8274-3E95C6D02918"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148559646171.17936.13169778377127397507.idtracker@ietfa.amsl.com> Date: Thu, 2 Feb 2017 00:23:39 +0100 Message-Id: References: <148559646171.17936.13169778377127397507.idtracker@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "General Area Review Team \(Gen-ART\)" , insipid@ietf.org, draft-ietf-insipid-logme-reqs.all@ietf.org Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-12 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:23:41 -0000 --Apple-Mail=_688E80DB-0F2C-409F-8274-3E95C6D02918 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your review, Stewart. I set the my position to =93No = objection=94 for this document in the upcoming IESG telechat. Jari --Apple-Mail=_688E80DB-0F2C-409F-8274-3E95C6D02918 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYkm37AAoJEM80gCTQU46qeRkP/01jSpF4qPRuOR3GRRJiayUJ WBLTcpyXJVkzf/R736AYVoY5rZFmi6jR7NuaOo2DgMZsWpO3B/ITNpMcVUnBCmWT PY6vR2DGEEA1A+jRLK0jZACHWufg8VI1Jp0SEMF3RhqqqX0x1o+IXGigzp1zLP6C Ujbhkrz4sGls9z8fXsviG4HRuI9s+ZLEKWIsEikyRctokI0/PmtRaRxFsYWIdTTL lDz6nhnvVOy1RNQokBwsHzbeZNTyV38A5b8iNYER2Q4qsR53IxMnZ7qCpdWTddCY rCvxpp6+oFl7ccl3vjUL5gUm7HJ8ijAjhrjYOM97Mq2JKt9ecY2xfwOuyZ4s6YIi ap8fFCE9LdxQtqIKeLOur5b/i/CBfr35LD03kQThbWlChjRJnl11Vc08OhG9zNXp eC3q+zZ3/Lg6xN7jEqymha15vJR+e+pN4J+qFztrCHvuILbP9I45EJ/olRMF4Ltp mbnsp8OprwWIaQTaixUZpxu/P9dTGWQbC58ZBaHEglE14a8geYTEbtRZZmCFl0Ex cjnecHnjEgPJS+MJX9+zn0tcPuFALykXRHcSdqJIwZ+csaS8DzJ17w9fdOQ8EA14 sUF+eK0/0iRtmfYTzMrcBd2tqkVXggscTinsN/8bLONafwfGKcESOdmYzZutRBT7 yBL3zfqeTwiMpTx14d00 =EOJy -----END PGP SIGNATURE----- --Apple-Mail=_688E80DB-0F2C-409F-8274-3E95C6D02918-- From nobody Wed Feb 1 19:43:04 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4712961B; Wed, 1 Feb 2017 19:42:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148600697969.18676.2707024128413115760.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 19:42:59 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Terry Manderson's Abstain on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:43:00 -0000 Terry Manderson has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I fail to see the value in publishing this document as an RFC in its own right. However I shall not stand in the way of publication should that be the ballot outcome. From nobody Wed Feb 1 22:44:15 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A83AD127735; Wed, 1 Feb 2017 22:44:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148601785464.18684.1776016868867703888.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 22:44:14 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Ben Campbell's Discuss on draft-ietf-insipid-logme-reqs-12: (with DISCUSS) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 06:44:15 -0000 Ben Campbell has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Okay, there's 5 obstains, and at this rate may be more by the telechat. I can take a hint :-) This is a discuss-discuss; I want to talk about the recent guidance we've given people for this sort of thing, and how we should address work items that were approved well before that guidance was given. Otherwise, I want to regroup with the authors and working group before progressing this further. From nobody Wed Feb 1 23:24:05 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376011293FE; Wed, 1 Feb 2017 23:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LsIk-51JpQfo; Wed, 1 Feb 2017 23:23:59 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF8C127735; Wed, 1 Feb 2017 23:23:59 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id w75so4365670ywg.1; Wed, 01 Feb 2017 23:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qdHYfG+lSEX2hLnLTVkem+4APsrsbMsqyhAbl+PihZs=; b=m8KJAS045OD6hBOBwjZlozF5BoVvtujGrtEoe5+CQNXDyckYMdkkEB0DllN1bg4WRA XMElEtkD3l9xTh7zBWZe+s9B/w1jN/ZbP+h0UlOqzo4Eop06zdtdeUu54WO2H17muqW0 U9zVUyJTPVKGTgxNpkaRbvPFbp+j4LBEdWLcHdnifvEDa0Je/i+JhQWdJsWs3UviHEP+ y1mnQCvztTNqo60/J2NzQKzVHk31VxTK3/blXT8dJDBLwBRqqPfw664TYq0EPz8Czo92 B4mpUGGuQafIJcT6dDedcf7CINxBVkjd96ybe0TNTkK4de4hMFCpzV+QXW8/+ieaEEkr PaXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qdHYfG+lSEX2hLnLTVkem+4APsrsbMsqyhAbl+PihZs=; b=j7tz4UCX+0AhBaxXHJX0RAy8z83U2IhYSchoLcZ8xlRt1g3zSDpli/8Cr2DMBJzlmx z/56IQGk9WUUinLFhYYWvgj2dUafiQeOBzWJyYTYAJQiqsv1hZLf/LOo11dIk3wIe3hW hlCkmwuNoxeavBLPjvsBUSu9z1HoleOGq+1tEsR872v3+D64Rg++VcKf14PzJWNo4nd3 Kpwfurdg22QsX9AXM1l3thmWDJDDaDyuZAvsIOCLJ/I5rCdfo2ayc5OA//CKngHBa0lA 7xK+jqCNsEAL5s6Bqt1MqyprpdGuxrP179R8zxC2gAkr/UrQcBfpuNZWBYz7nr+4EqdN ppUw== X-Gm-Message-State: AIkVDXJHqG4cfQwQC8dYlDzX1j7Op57wOquIFfS7ne9jGqxuAaEFwdyMUdX/jN3g2L8QfPmVdhZBDhZDoEeMbQ== X-Received: by 10.129.67.25 with SMTP id q25mr5036884ywa.348.1486020238717; Wed, 01 Feb 2017 23:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.132 with HTTP; Wed, 1 Feb 2017 23:23:58 -0800 (PST) In-Reply-To: <148601785464.18684.1776016868867703888.idtracker@ietfa.amsl.com> References: <148601785464.18684.1776016868867703888.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 2 Feb 2017 16:23:58 +0900 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=f403045eb4047541410547870ceb Archived-At: Cc: draft-ietf-insipid-logme-reqs@ietf.org, insipid@ietf.org, The IESG , insipid-chairs@ietf.org, Gonzalo Salgueiro Subject: Re: [Insipid] Ben Campbell's Discuss on draft-ietf-insipid-logme-reqs-12: (with DISCUSS) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 07:24:01 -0000 --f403045eb4047541410547870ceb Content-Type: text/plain; charset=UTF-8 Dear IESG, On Thu, Feb 2, 2017 at 3:44 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-insipid-logme-reqs-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Okay, there's 5 obstains, and at this rate may be more by the telechat. I > can take a hint :-) > > This is a discuss-discuss; I want to talk about the recent guidance we've > given people for this sort of thing, and how we should address work items > that were approved well before that guidance was given. Otherwise, I want > to regroup with the authors and working group before progressing this > further. > It may also be helpful for us to note as part of that chat, that the current approval gating for Informational docs like this one happens to be (as given in https://www.ietf.org/iesg/voting-procedures.html). "For an Informational, Experimental, or Historic document, approval requires one Yes with no Discuss votes. The IESG secretary will refer to the ballot during the telechat, but there will not be a poll of ADs who have not posted a ballot position. If there are no Discuss ballot positions, the Secretariat will ask, "Does any AD object to this document being published?" If an AD raises an objection, a Discuss position must be posted at that time." If Ben was still a Yes and all the rest of us Abstained, the document would be approved. Is that what we think should happen? Curiously yours, Spencer --f403045eb4047541410547870ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear IESG,

On Thu, Feb 2, 2017 at 3:44 PM, Ben Campbell &l= t;ben@nostrum.com&= gt; wrote:
Ben = Campbell has entered the following ballot position for
draft-ietf-insipid-logme-reqs-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-insipid-logme-reqs/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Okay, there's 5 obstains, and at this rate may be more by the telechat.= I
can take a hint :-)

This is a discuss-discuss; I want to talk about the recent guidance we'= ve
given people for this sort of thing, and how we should address work items that were approved well before that guidance was given. Otherwise, I want to regroup with the authors and working group before progressing this
further.

It may also be helpful for us = to note as part of that chat, that the current approval gating for Informat= ional docs like this one happens to be (as given in=C2=A0https://www.ietf.org/iesg/voting= -procedures.html).

"For an Informational, Experimental, or Historic document, approval requ= ires one Yes with no Discuss votes. The IESG secretary will refer to the ba= llot during the telechat, but there will not be a poll of ADs who have not = posted a ballot position. If there are no Discuss ballot positions, the Sec= retariat will ask, "Does any AD object to this document being publishe= d?" If an AD raises an objection, a Discuss position must be posted at= that time."

If Ben was still a Yes an= d all the rest of us Abstained, the document would be approved.=C2=A0
=

Is that what we think should happen?=C2=A0
Curiously yours,

Spencer=C2=A0
<= /div>
--f403045eb4047541410547870ceb-- From nobody Thu Feb 2 06:59:55 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E1129459; Thu, 2 Feb 2017 06:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.355 X-Spam-Level: X-Spam-Status: No, score=-5.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156] autolearn=ham autolearn_force=no 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 Mgguj_7Ku1lL; Thu, 2 Feb 2017 06:59:51 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5021293E9; Thu, 2 Feb 2017 06:59:50 -0800 (PST) Received: from [193.109.255.99] by server-7.bemta-6.messagelabs.com id C9/F3-29440-46943985; Thu, 02 Feb 2017 14:59:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRWlGSWpSXmKPExsWi75nTqZviOTn C4N9WdYuj216wWMyd4mcx489EZotHj34wWcy//4zJomFnvgObx5TfG1k9ds66y+6xZMlPpgDm KNbMvKT8igTWjO7ONWwFEyUqmhauYm9gfCHexcjJISSwjVHi7w7mLkYuIPsQo8SzBVOZIJzDj BJHj91lgXA2MUpM/fMDKMPBwSZgLzFjTwxIt4hAsMTxnd2sIDXMAvcZJf5Nf8oKkhAWSJJYfe sbI0RRssSac7eYIWwjiYPbToPZLAIqEpNPrWIHsXkFQiUOrpzPCDJfSMBPYt2xUpAwp4C/RMu vGUwgNqOArMSXxtVgrcwC4hK3nswHi0sICEgs2XOeGcIWlXj5+B8ryBhmAU2J9bv0IcoVJaZ0 P4TaJChxcuYTFojnVSX+rVzENIFRbBaSqbMQumch6Z6FpHsBI8sqRvXi1KKy1CJdQ72kosz0j JLcxMwcXUMDM73c1OLixPTUnMSkYr3k/NxNjMAoZACCHYw7nzsdYpTkYFIS5Z2iNTlCiC8pP6 UyI7E4I76oNCe1+BCjDAeHkgTvM3egnGBRanpqRVpmDjAdwKQlOHiURHgTQdK8xQWJucWZ6RC pU4yKUuK8O0ASAiCJjNI8uDZYCrrEKCslzMsIdIgQT0FqUW5mCar8K0ZxDkYlYd4vIFN4MvNK 4Ka/AlrMBLT45+NJIItLEhFSUg2M3dkOPtdEv05l0pv9PeHMX45f4r/mhR/m/vJeW0CspS3s8 PsPB81Ue4X7bt3W+H799V7+g8e1BYzNeCY2nZAL0+lUl9O9/HKPS27hUTsD5WmPr6xfk+n/4c Op079ePFNLPRQS1MlnI/Tx04or5oZ3Dh4Sv2+QWer0Uum8hozxb2mR/UfbFO88VGIpzkg01GI uKk4EALOaOZM8AwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-7.tower-48.messagelabs.com!1486047588!89553602!1 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14457 invoked from network); 2 Feb 2017 14:59:48 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.137) by server-7.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Feb 2017 14:59:48 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Feb 2017 15:59:46 +0100 Received: from VOEXC05W.internal.vodafone.com (145.230.101.25) by VOEXH08W.internal.vodafone.com (47.73.211.206) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 2 Feb 2017 15:59:46 +0100 Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 2 Feb 2017 15:59:46 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.03.0294.000; Thu, 2 Feb 2017 15:59:45 +0100 From: "Dawes, Peter, Vodafone Group" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) Thread-Index: AQHSfM3D08izgXe000KdNBB8jAq3kaFVz4/w Date: Thu, 2 Feb 2017 14:59:44 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7359E@VOEXM31W.internal.vodafone.com> References: <148598262942.18688.17689106924752475566.idtracker@ietfa.amsl.com> In-Reply-To: <148598262942.18688.17689106924752475566.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" , "insipid-chairs@ietf.org" , "draft-ietf-insipid-logme-reqs@ietf.org" , "gsalguei@cisco.com" Subject: Re: [Insipid] Kathleen Moriarty's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:59:53 -0000 SGVsbG8gS2F0aGxlZW4sIA0KVGhhbmtzIGZvciB0aGUgY29tbWVudCwgd2UgY2FuIGVuc3VyZSB0 aGF0IHRoZSBzb2x1dGlvbiBkcmFmdCBpcyBjbGVhciB0aGF0IGxvZ2dpbmcgYWdyZWVtZW50cyBi ZXR3ZWVuIHBlZXIgb3BlcmF0b3JzIGFyZSBmb3IgdHJvdWJsZXNob290aW5nIGFuZCByZWdyZXNz aW9uIHRlc3RpbmcgcHVycG9zZXMuDQoNClJlZ2FyZHMsDQpjby1hdXRob3JzDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzpL YXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NCj4gU2VudDogMDEgRmVicnVhcnkgMjAx NyAyMDo1Nw0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtaW5zaXBpZC1sb2dtZS1y ZXFzQGlldGYub3JnOyBpbnNpcGlkLWNoYWlyc0BpZXRmLm9yZzsNCj4gZ3NhbGd1ZWlAY2lzY28u Y29tOyBpbnNpcGlkQGlldGYub3JnDQo+IFN1YmplY3Q6IEthdGhsZWVuIE1vcmlhcnR5J3MgTm8g T2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaW5zaXBpZC1sb2dtZS1yZXFzLQ0KPiAxMjogKHdpdGgg Q09NTUVOVCkNCj4gDQo+IEthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtcmVxcy0x MjogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50 cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVy IHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEu aHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pbnNpcGlkLWxvZ21lLXJlcXMvDQo+IA0KPiANCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSW4g YWRkaXRpb24gdG8gU3RlcGhlbidzIHF1ZXN0aW9ucywgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGxp dHRsZSBtb3JlIHRleHQgaW4gdGhlDQo+IGZvbGxvd2luZyBzZW50ZW5jZSBvZiB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbjoNCj4gT0xEOg0KPiAgICBJZiBhIHByaW9yIGFncmVl bWVudCB0byBsb2cNCj4gICAgc2Vzc2lvbnMgZXhpc3RzIHdpdGggdGhlIG5leHQgaG9wIG5ldHdv cmsgdGhlbiB0aGUgImxvZyBtZSIgbWFya2VyDQo+ICAgIFNIT1VMRCBOT1QgYmUgcmVtb3ZlZC4N Cj4gTkVXOiAob3Igc29tZXRoaW5nIHNpbWlsYXIgdGhhdCB0aWVzIHRoaXMgYmFjayB0byByZXF1 aXJlbWVudCA3KQ0KPiAgICBJZiBhIHByaW9yIGFncmVlbWVudCB0byBsb2cNCj4gICAgc2Vzc2lv bnMsIGF0IGEgZGVidWdnaW5nIG9yIHJlZ3Jlc3Npb24gdGVzdGluZyBsZXZlbCBmb3IgZGF0YSwg ZXhpc3RzIHdpdGggdGhlDQo+IG5leHQgaG9wIG5ldHdvcmsgdGhlbiB0aGUgImxvZyBtZSIgbWFy a2VyDQo+ICAgIFNIT1VMRCBOT1QgYmUgcmVtb3ZlZC4NCj4gDQo+IFRoYXQgcmVxdWlyZW1lbnQg b25seSBzaG93cyB1cCBpbiBvbmUgcGxhY2UgKGFzIGZhciBhcyBJIGNvdWxkIHNlZSBhbmQgSSB0 aGluaw0KPiBpdCB3b3VsZCBiZSBoZWxwZnVsIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uIGFzIGl0IHNob3dzIHRoZQ0KPiBsaW1pdGVkIHNjb3BlIG9mIHVzZSBiZXNpZGVz IHRoZSAidHJ1c3QgZG9tYWluIiAobmFtZSBtYXkgYmUgY2hhbmdlZD8pLg0KPiANCj4gTm90ZSB0 aGF0IEkgYW0gYmFsbG90aW5nIE5vIE9iamVjdGlvbiBhcyB0aGlzIGlzIHBhcnQgb2YgdGhlIFdH J3MgY2hhcnRlciAoYWxzbw0KPiBwb2ludGVkIG91dCBpbiB0aGUgU2VjRGlyIHJldmlldykuDQo+ IA0KDQo= From nobody Thu Feb 2 07:28:49 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAA12966C; Thu, 2 Feb 2017 07:28:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148604932797.13969.9123485724260878620.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 07:28:47 -0800 Archived-At: Cc: insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com Subject: [Insipid] Ben Campbell's Yes on draft-ietf-insipid-logme-reqs-12 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:28:48 -0000 Ben Campbell has entered the following ballot position for draft-ietf-insipid-logme-reqs-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ There are no remarks associated with this position. From nobody Mon Feb 6 14:59:04 2017 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF09129685 for ; Mon, 6 Feb 2017 14:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 9Recq0WKZdHU for ; Mon, 6 Feb 2017 14:59:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE2C129684 for ; Mon, 6 Feb 2017 14:59:00 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v16MwwvF067752 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Feb 2017 16:58:59 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Stephen Farrell" Date: Mon, 06 Feb 2017 16:58:58 -0600 Message-ID: <83470E77-DD64-40F5-A820-0E0CB827DBB7@nostrum.com> In-Reply-To: <5b2e4d39-5646-27f2-a7c2-639404f1c70b@cs.tcd.ie> References: <148595894907.19146.186759558704017451.idtracker@ietfa.amsl.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C7240A@VOEXM31W.internal.vodafone.com> <5b2e4d39-5646-27f2-a7c2-639404f1c70b@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "insipid-chairs@ietf.org" , "Dawes, Peter, Vodafone Group" , "gsalguei@cisco.com" , "insipid@ietf.org" , The IESG , "draft-ietf-insipid-logme-reqs@ietf.org" Subject: Re: [Insipid] Stephen Farrell's No Objection on draft-ietf-insipid-logme-reqs-12: (with COMMENT) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 22:59:02 -0000 Hi, I agree with Stephen that "trust domain" is used to mean so many different things that the term has become vacuous. Even if it is well defined in any given RFC, it inherits the baggage from all the other usages. But, I am inclined to defer the push for something more rigorous to the solution draft. Give that the solutions draft will be standards track and privacy affecting, I expect it's security and privacy considerations will get close scrutiny :-) Ben. On 1 Feb 2017, at 16:12, Stephen Farrell wrote: > Hi Peter, > > I don't suggest that we get into it in detail - if needed that'd > be better done during IESG evaluation of the solution draft, but > I have to say that no matter how many other documents have the > same concept, I think it's a broken concept:-) > > The "it" I mean is to consider the set of {all machines controlled > by one operator plus all the other machines needed for one or a > set of calls originated by that operator} as a "domain." That'd be > like considering the set of {routers affected by a BGP announcement > plus all the machines in the original AS} as a domain, which I > don't think makes any more sense. > > Again though, I don't think we need to bottom out on this now, > but I suspect things'll work out better if the solution document > doesn't depend much on that "trust domain" (IMO non-)concept. > > Cheers, > S. > > On 01/02/17 20:18, Dawes, Peter, Vodafone Group wrote: >> Hello Stephen, Thanks for the in-depth review of the draft. Some >> responses below. >> >> Best regards, Peter and Arun (co-authors) >> >>> -----Original Message----- From: insipid >>> [mailto:insipid-bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: 01 February 2017 14:22 To: The IESG Cc: insipid@ietf.org; >>> insipid-chairs@ietf.org; draft-ietf-insipid-logme- reqs@ietf.org; >>> gsalguei@cisco.com Subject: [Insipid] Stephen Farrell's No >>> Objection on draft-ietf-insipid-logme- reqs-12: (with COMMENT) >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-insipid-logme-reqs-12: No Objection >>> >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free to >>> cut this introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>> information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found >>> here: >>> https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> >>> > COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> > Note that I'm balloting no-objection here. If some of these things > weren't >>> fixed, I'd be a DISCUSS ballot when the protocol spec turned up, >>> should I still be on the IESG at that point (which I guess is >>> unlikely:-) >>> >>> - 3.2: I think "trust domain" isn't a great term, and doesn't >>> really match the definition offered well. You're including the >>> entire "source" operator plus the bits of any other operator that >>> have agreed to help the source-operator with logging. I don't think >>> that set of things is really a domain. Nor are the things in that >>> set "trusted" except to do this logging stuff properly. It's also >>> not clear to me if the relevant set is meant to differ per-call, or >>> to be the same for all calls that a source-operator might >>> originate. >>> >> >> The term "trust domain" appears in RFC 3324 (referred to by RFC 3325, >> RFC 7316) and RFC 6404. In the 3GPP profile of SIP, it appears in TS >> 24.229. RFC 3324 concerns network asserted identities and defines a >> trust domain as a collection of nodes with secure connections that >> have configuration information on which connected nodes to trust. >> >> RFC 6404 concerns security threats related to the interconnection of >> service providers. SIP service providers (SSPs) who have a peering or >> transit contract are in the trust domain, others are not: "Each SSP >> may have connections to one or more remote SSPs through peering or >> transit contracts. A potentially compromised remote SSP that attacks >> other SSPs is out of the scope of this document; this document >> focuses on attacks on an SSP from outside the trust domain such an >> SSP may have with other SSPs.". >> >> The TS 24.229 description of the trust domain (clause 4.4) includes >> the following excerpts "For the IM CN subsystem, this trust domain >> consists of the functional entities that belong to the same >> operator's network " and " Additionally, other nodes within the IM CN >> subsystem that are not part of the same operator's domain may or may >> not be part of the trust domain, depending on whether an interconnect >> agreement exists with the remote network. " and " Within the IM CN >> subsystem trust domains will be applied to a number of header fields. >> These trust domains do not necessarily contain the same functional >> entities or cover the same operator domains." >> >> The use of trust domain in logme-reqs is similar to its use in RFC >> 6404 and TS 24.229. The trust domain needs a wide scope in terms of >> included networks because one of the reasons for the logme mechanism >> is the unpredictability in advance of SIP routing through multiple >> connected service providers, transit networks, etc. It is also >> important to define trust domain as it applies specifically to "logme >> marking" as a protocol element because trust domain does not always >> impact all parts of SIP equally. >> >> logme marking is expected to be applied for regression testing and >> troubleshooting. It will often be pre-arranged and involve a SIP >> client specifically for testing owned and operated by a service >> provider. The trust domain is not expected to change from call to >> call but only a very small subset of calls will be used for testing. >> >>> - 5.1: REQ1 seems to me to ignore privacy in one bad respect - >>> isn't the right thing to log the entire message *except* bits that >>> are considered sensitive by the logging entity concerned? E.g. any >>> secrets or PII in the SIP message may be best not logged. Forcing >>> everyone to log the entire thing would seem brittle to me - it may >>> cause operators to not co-operate with one another esp if data >>> privacy laws differ between them. (Or maybe more likely, the logs >>> will not have the sensitive bits, or will eventually have them >>> XXXX'd out.) >>> >> >> Specifying logging the entire message means that troubleshooting >> tools will know they have all fields. Privacy might require that one >> service provider remove some protocol elements before passing a SIP >> message to a peer service provider, logme marking won't be able to >> bring them back. Within a service provider, logging must obey data >> protection laws regardless of any RFC. >> >> If the user needs privacy, their user agent should follow the >> procedures documented in RFC 3323. This way we can avoid imposing >> privacy related requirements on SIP entities that log messages. >> >>> - REQ9: Not quite sure, but I wonder are there additional >>> requirements for intermediaries inserting this that aren't covered. >>> For example, that that not be (ab)used for other than diagnostics >>> and hence ought not be on by default and maybe more. I think the >>> thing to do is to get someone to do a privacy analysis of this >>> situation before the protocol spec is done - some minor changes >>> might make a biggish difference there. >> >> We can do a privacy analysis as part of the solution. >> >>> >>> - 6.1: See above wrt 3.2. I'm not convinced that there is such a >>> thing as a "trust domain boundary" as you use the term. I think >>> (not sure) that may mean that logme stuff is either dropped on >>> ingress or else never dropped which'd seem like a bad outcome. >> >> Logme marking of a SIP request will be present until a SIP message is >> passed to a peer service provider that is not part of the prior >> logging agreement, and then it will be removed. Note that a response >> to that request might be logme marked as it re-enters the service >> provider that removed it from the request. >> >>> >>> >>> _______________________________________________ insipid mailing >>> list insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From nobody Mon Feb 6 15:25:57 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D671296C1; Mon, 6 Feb 2017 15:25:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148642355262.18892.13582314472565223374.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 15:25:52 -0800 Archived-At: Cc: ben@nostrum.com, insipid-chairs@ietf.org, gsalguei@cisco.com, insipid@ietf.org, The IESG , draft-ietf-insipid-logme-reqs@ietf.org, rfc-editor@rfc-editor.org Subject: [Insipid] Document Action: 'Requirements for Marking SIP Messages to be Logged' to Informational RFC (draft-ietf-insipid-logme-reqs-12.txt) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:25:53 -0000 The IESG has approved the following document: - 'Requirements for Marking SIP Messages to be Logged' (draft-ietf-insipid-logme-reqs-12.txt) as Informational RFC This document is the product of the INtermediary-safe SIP session ID Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ Technical Summary This document specifies the requirements for requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. Working Group Summary The document has achieved working group consensus and has received sufficient discussion. There were no particularly contentious issues to work through in this document (unlike its INSIPID predecessor). Document Quality There is no working implementation, per se, of this draft since it is a requirements document. That said, its corresponding solution draft (draft-ietf-insipid-logme-marking) does indeed have working implementations. Personnel Gonzalo Salgueiro is the document shepherd and Ben Campbell is the responsible Area Director. From nobody Tue Feb 7 12:27:52 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1087A129EBA; Tue, 7 Feb 2017 12:27:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148649927105.26803.13483494180613022926.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 12:27:51 -0800 Archived-At: Cc: ben@nostrum.com, insipid@ietf.org, gsalguei@cisco.com, insipid-chairs@ietf.org Subject: [Insipid] insipid - Not having a session at IETF 98 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:27:51 -0000 Gonzalo Salgueiro, a chair of the insipid working group, indicated that the insipid working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Feb 13 04:34:11 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B091294C9; Mon, 13 Feb 2017 04:34:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148698924698.24924.6142018280764619249.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 04:34:06 -0800 Archived-At: Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-marking-06.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 12:34:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID of the IETF. Title : Marking SIP Messages to be Logged Author : Peter Dawes Filename : draft-ietf-insipid-logme-marking-06.txt Pages : 14 Date : 2017-02-13 Abstract: SIP networks use signalling monitoring tools to diagnose user reported problems and for regression testing if network or user agent software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between user agents, and therefore impractical to monitor SIP signalling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular user agent signalling. However, such marking can be carried end-to-end including the SIP user agents, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-marking-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-marking-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/