From nobody Thu May 5 11:18:58 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DEC12D572 for ; Thu, 5 May 2016 11:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 kvIDiUYy-mdQ for ; Thu, 5 May 2016 11:18:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC8A12D70A for ; Thu, 5 May 2016 11:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5012; q=dns/txt; s=iport; t=1462472334; x=1463681934; h=from:to:subject:date:message-id:mime-version; bh=Qxwsr5MqmLwTf14C/CRLO6iBq1xrVq6vi/0PYlYfOi0=; b=iWp8mHu5CaPHqGibpo+W+3PncjYf+xtJ6GayhVaMxwcm4nYC1/ANyjLc S/Et6/jecbl4s/VHi/IfMkljNnR1gb9Mh/9YJWYQBBIUCbq77h7ehsCm7 Ylsp2yIuRTG13jNS3y0gjMwnBvhx5erfvU0wpEeqyd9FPa/t7yrYwPWuF c=; X-Files: id-event_charter_v1.txt : 2212 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAwCYjStX/4ENJK1WCYJsTFN9BrQkh?= =?us-ascii?q?HMOgXYXAQqHJjgUAQEBAQEBAWUcC4Q4CwUBAQFWFR0BCwEgJCULJwQTDogcDp5?= =?us-ascii?q?MoGYBAQEBAQUBAQEBAQEBARAEBIYgiGQRhW8FmBoBgS2BeoFnbW+CCIUmgWiET?= =?us-ascii?q?YhejzMBHgFDg2tsh1t/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,583,1454976000"; d="txt'?scan'208,217";a="99491794" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 18:18:53 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u45IIrbf000985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 May 2016 18:18:53 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 13:18:52 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Thu, 5 May 2016 13:18:52 -0500 From: "Morteza Ansari (moransar)" To: "id-event@ietf.org" Thread-Topic: Straw man text for proposed charter Thread-Index: AQHRpvqTgBAoFeyLHUGd148PgQ6OuQ== Date: Thu, 5 May 2016 18:18:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.112.68] Content-Type: multipart/mixed; boundary="_004_D350D8892C7B5moransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:18:57 -0000 --_004_D350D8892C7B5moransarciscocom_ Content-Type: multipart/alternative; boundary="_000_D350D8892C7B5moransarciscocom_" --_000_D350D8892C7B5moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put t= ogether the attached as a straw man charter proposal to start the discussio= n. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. Cheers, Morteza --_000_D350D8892C7B5moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <97AE6623D10EE2469A8BD07148D3C384@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi folks,

At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and = put together the attached as a straw man charter proposal to start the disc= ussion. Please send your comments and suggestions for any changes or propos= e a new one if you think its necessary.


Cheers,
Morteza
--_000_D350D8892C7B5moransarciscocom_-- --_004_D350D8892C7B5moransarciscocom_ Content-Type: text/plain; name="id-event_charter_v1.txt" Content-Description: id-event_charter_v1.txt Content-Disposition: attachment; filename="id-event_charter_v1.txt"; size=2212; creation-date="Thu, 05 May 2016 18:18:52 GMT"; modification-date="Thu, 05 May 2016 18:18:52 GMT" Content-ID: <77FF3A0B12CC6E4FAB49371FEF962FD4@emea.cisco.com> Content-Transfer-Encoding: base64 Q2hhcnRlcgoKIEN1cnJlbnQgU3RhdHVzOiBUQkQKCiBDaGFpcnM6CiAgICAgVEJECgogQXBwbGlj YXRpb25zIGFuZCBSZWFsLVRpbWUgQXJlYSBEaXJlY3RvcnM6CiAgICAgVEJECgogQXBwbGljYXRp b25zIGFuZCBSZWFsLVRpbWUgQXJlYSBBZHZpc29yOgogICAgIFRCRAoKIE1haWxpbmcgTGlzdHM6 CiAgICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBpZC1ldmVudEBpZXRmLm9yZwogICAgIFRvIFN1YnNj cmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dAogICAgIEFyY2hpdmU6ICAgICAgICAgICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL2Jyb3dzZS9pZC1ldmVudC8KCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgpNYW55 IGlkZW50aXR5IHJlbGF0ZWQgcHJvdG9jb2xzIHJlcXVpcmUgYSBtZWNoYW5pc20gdG8gY29udmV5 IG1lc3NhZ2VzIGJldHdlZW4Kc3lzdGVtcyBpbiBvcmRlciB0byBwcmV2ZW50IG9yIG1pdGlnYXRl IHNlY3VyaXR5IHJpc2tzLCBvciB0byBwcm92aWRlCm91dC1vZi1iYW5kIGluZm9ybWF0aW9uIGFz IG5lY2Vzc2FyeS4gRm9yIGV4YW1wbGUsIGFuIE9BdXRoIGF1dGhvcml6YXRpb24Kc2VydmVyLCBo YXZpbmcgcmVjZWl2ZWQgYSB0b2tlbiByZXZvY2F0aW9uIHJlcXVlc3QgKFJGQzcwMDkpIG1heSBu ZWVkIHRvCmluZm9ybSBhZmZlY3RlZCByZXNvdXJjZSBzZXJ2ZXJzOyBhIGNsb3VkIHByb3ZpZGVy IG1heSB3aXNoIHRvIGluZm9ybSBhbm90aGVyCmNsb3VkIHByb3ZpZGVyIG9mIHN1c3BlY3RlZCBm cmF1ZHVsZW50IHVzZSBvZiBpZGVudGl0eSBpbmZvcm1hdGlvbjsgYW4KSWRlbnRpdHkgUHJvdmlk ZXIgbWF5IHdpc2ggdG8gc2lnbmFsIGEgc2Vzc2lvbiBsb2dvdXQgdG8gYSBzZXJ2aWNlIHByb3Zp ZGVyLgoKSXQgaXMgZXhwZWN0ZWQgdGhhdCBzZXZlcmFsIGlkZW50aXR5IGFuZCBzZWN1cml0eSB3 b3JraW5nIGdyb3VwcyBhbmQKb3JnYW5pemF0aW9ucyB3aWxsIHVzZSBJZGVudGl0eSBFdmVudCBU b2tlbnMgdG8gZGVzY3JpYmUgYXJlYSBzcGVjaWZpYwpldmVudHMgc3VjaCBhczogU0NJTSBQcm92 aXNpb25pbmcgRXZlbnRzLCBPcGVuSUQgUklTQyBFdmVudHMsIGFuZCBPQXV0aApUb2tlbiBSZXZv Y2F0aW9uIGFtb25nIG90aGVycy4KClRoZSBJZC1FdmVudCB3b3JraW5nIGdyb3VwIHdpbGwgcHJv ZHVjZSBhbiBFdmVudCBUb2tlbiBzcGVjaWZpY2F0aW9uIHRoYXQKZGVmaW5lczoKIC0gQSBKV1Qg ZXh0ZW5zaW9uIGZvciBjb252ZXlpbmcgaWRlbnRpdHkgZXZlbnRzCiAtIEV2ZW50IG1ldGFkYXRh IGF0dHJpYnV0ZXMKIC0gQW4gZXh0ZW5zaW9uIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBmb3IgcHJv dG9jb2wgc3BlY2lmaWMgZXZlbnRzCiAtIEEgSldUIHRva2VuIHJldm9jYXRpb24gZXZlbnQgYXMg YSBub3JtYXRpdmUgZXhhbXBsZQoKVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIGRldmVsb3Ag YW4gZXZlbnQgZGVsaXZlcnkgc3BlY2lmaWNhdGlvbiB0aGF0CmRlZmluZXM6CiAtIEEgSlNPTiBt ZXNzYWdlIGZvcm1hdCBmb3IgZGVsaXZlcmluZyBvbmUgb3IgbW9yZSBldmVudHMKIC0gQSByZWdp c3RyeSBmb3IgZGVmaW5pbmcgYSBkZWxpdmVyeSBtZXRob2QKIC0gVHdvIGluaXRpYWwgbWV0aG9k cyBmb3IgZGVsaXZlcmluZyBldmVudHMgdXNpbmcgSFRUUCBQT1NUIChwdXNoKSBhbmQgSFRUUAog ICBHRVQgKHBvbGxpbmcpCiAtIE1ldGhvZHMgYnkgd2hpY2ggc3Vic2NyaWJlcnMgY2FuIGluaXRp YWxpemUsIGRldGVjdCwgYW5kIG9wdGlvbmFsbHkgcmVjb3ZlcgogICBtaXNzaW5nIGV2ZW50cwoK R29hbHMgYW5kIE1pbGVzdG9uZXM6CiAgICBKdW5lIDIwMTYgLSBJbml0aWFsIGFkb3B0aW9uIG9m IGV2ZW50IHRva2VuIGFuZCBldmVudCBkZWxpdmVyeSBkcmFmdHMKRGVjZW1iZXIgMjAxNiAtIFdH IGxhc3QgY2FsbCBvZiBldmVudCB0b2tlbiBkcmFmdApGZWJydWFyeSAyMDE3IC0gZXZlbnQgdG9r ZW4gZHJhZnQgdG8gSUVTRyBhcyBwcm9wb3NlZCBzdGFuZGFyZAogICBNYXJjaCAyMDE3IC0gV0cg bGFzdCBjYWxsIG9mIGV2ZW50IGRlbGl2ZXJ5IGRyYWZ0CiAgICAgTWF5IDIwMTcgLSBldmVudCBk ZWxpdmVyeSBkcmFmdCB0byBJRVNHIGFzIHByb3Bvc2VkIHN0YW5kYXJkCiAgICBKdWx5IDIwMTcg LSB3b3JrIGNvbXBsZXRlZDsgZGlzY3VzcyByZWNoYXJ0ZXIgaWYgbmVlZGVkCg== --_004_D350D8892C7B5moransarciscocom_-- From nobody Thu May 5 21:42:38 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037AF12B05F for ; Thu, 5 May 2016 21:42:37 -0700 (PDT) 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 7WN0rz2zQ1Ed for ; Thu, 5 May 2016 21:42:35 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 6065112B04E for ; Thu, 5 May 2016 21:42:35 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v145so126627582oie.0 for ; Thu, 05 May 2016 21:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yQRQH65cG2x48SjAi3TnS2LkfZQPwwJz3FavL6KzgqY=; b=Q4YL7jyqwYSP0YZz2E79HjKvy9icZN22ilABC4ZCgLfaIfMsmBU28HgwcdYl85ffbl aWOV7EEW0z8ZrSbOjIOS1K83Lz2mIr8Qomhi+We9meahvPX1EJrMakwelXKF2NM7PcQS rv/9vICwU2O65G4whiH9d+VdCojMPxitaYq7d91hNuV6Oi6gUqfN+5B40BteiZn8QuA3 uWgU5RrbneM2Dy5t0N+GHgThPAV9NyTFzeE2WfvgoM3xLeDzOOoA8EvPohqIxVLSSDqn dQitQy3PLgQfnzpobjNAqTwOPS1UBXfqC8ygQ25DDSDBzPa2cBnIT6z5zcL3M9u7Lc/+ NjjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yQRQH65cG2x48SjAi3TnS2LkfZQPwwJz3FavL6KzgqY=; b=NAoe9ddoO4y8ZBK1Ln9GDog/bjpFe53s1a9zgTQh9iTGQzZpnno4q2NkJU8q7H9mym tzPkUTJeQrGXuVJ3T6Bk2Um7F6KSSxtv+UQl3ZM/t6ugpL1VmwFpdmqu1450j2idP8uv ymsyhnWbDN+DjrqQaH+gNNKvdG1raykMGdrngAOaLY6XCU59gDLT6fTVrFC0Ag2K+9Xf aUblCuviVVgHIAOo2Ez9g7qlSovFVwzlHYVjLkH1oW+Z/T3TOtIQsNdnK1SE5g0/cdcm SZA6kOnM0JWF1tFZbOvufflGy+gHPPUBHhcevOzZksWB8kp3Qjfh4RWaaxv22lw1VrxP INow== X-Gm-Message-State: AOPr4FUOn6J6oRpMvE45BP/GNRLGJs2wEHoVpVLumC53d5JCfHBhpkK/AC/99eth4VbntHsI7FKuaS3ktZf76A== MIME-Version: 1.0 X-Received: by 10.202.168.147 with SMTP id r141mr186578oie.40.1462509754856; Thu, 05 May 2016 21:42:34 -0700 (PDT) Received: by 10.157.6.199 with HTTP; Thu, 5 May 2016 21:42:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2016 21:42:34 -0700 Message-ID: From: Alan Karp To: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary=001a113cdb666b3bf8053225165b Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 04:42:37 -0000 --001a113cdb666b3bf8053225165b Content-Type: text/plain; charset=UTF-8 I don't see anything about access control for publishing events and subscribing to them. I also think the spec should allow filters on subscriptions. -------------- Alan Karp On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) < moransar@cisco.com> wrote: > Hi folks, > > At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put > together the attached as a straw man charter proposal to start the > discussion. Please send your comments and suggestions for any changes or > propose a new one if you think its necessary. > > > Cheers, > Morteza > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a113cdb666b3bf8053225165b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't see anything about access control for publishi= ng events and subscribing to them.=C2=A0 I also think the spec should allow= filters on subscriptions.


--------------
Alan Karp
=

On Thu, May 5, 2016 at 11:18 AM, Morteza Ans= ari (moransar) <moransar@cisco.com> wrote:
Hi folks,

At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and = put together the attached as a straw man charter proposal to start the disc= ussion. Please send your comments and suggestions for any changes or propos= e a new one if you think its necessary.


Cheers,
Morteza

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--001a113cdb666b3bf8053225165b-- From nobody Thu May 5 22:00:41 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E57512D190 for ; Thu, 5 May 2016 22:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 xS5fAkhbOlsU for ; Thu, 5 May 2016 22:00:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28A612D0CB for ; Thu, 5 May 2016 22:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=myB+qNw/0OsdtFVtXlrHESew9Sr5/PaBFC2nSHosCbk=; b=ajlTRr3TN2QtCPsVmRLLwrnLfEvmCTq93I29gmv/o1qnCmZiStL35RvAE4l0W9D4MtdbTx0MIv3MRpHnpfNG+Yn+Aoa0/x/Vq483M1l4HjoIz79X1Q3XBR8TpjFo/XTT43QhboUf0k4EutzEdVqRVZ55JKkhbULmM/Z494G4P20= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (TLS) id 15.1.485.9; Fri, 6 May 2016 05:00:36 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0485.011; Fri, 6 May 2016 05:00:36 +0000 From: Mike Jones To: Alan Karp , "Morteza Ansari (moransar)" Thread-Topic: [Id-event] Straw man text for proposed charter Thread-Index: AQHRpvqTgBAoFeyLHUGd148PgQ6OuZ+rVXQAgAAAWIA= Date: Fri, 6 May 2016 05:00:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.90.97] x-ms-office365-filtering-correlation-id: 8974354c-03b6-4890-6859-08d3756b5c8c x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 5:sjFe9/yKnbY4qzJWnqSx0CF7EEOJM58iTjvrMlfzsLJ38qI8ylFq9UIe826yIlaQzeks48za8+Npr37FJFrsOYC/5skm9L6R3bGWjNf4F0iTC6o87D5MLacxV75PGDopnWGxejVqAeHxyVd7q5R1FA==; 24:xNInvqlPeRHRXUmQfWpL/Y4GWq3RYuKjpca9LBfPUSwlYukRHIHAUqFiY7ErNFhJsYWazVAbtavl1kWzFjciMc/MfrbX8xRE+V9CHv18jvY=; 7:Uwnh21O6sGcUNkK6X00sgD68WlWw60q6hwTCZxxEC/FE37bhd3pXScSTYG20x8oFUX4lAFYrRaPeXJWMKScU79My45oRuQO++F2OZbmzCenvPTC2g6pPV1fKKk4cOtlcEiLLELf/qQ31CUwR4RSR/7n56GznI8JtxNNiAyBkFW0vD3N64BtpsaC0OQzV2ZiAWiNKD5199Z6RmVj97dRB4w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19617315012)(10290500002)(19580405001)(19580395003)(81166005)(86362001)(5008740100001)(92566002)(86612001)(10400500002)(19609705001)(11100500001)(10090500001)(87936001)(5005710100001)(8936002)(99286002)(189998001)(122556002)(2906002)(50986999)(106116001)(5002640100001)(561944003)(5004730100002)(19300405004)(19625215002)(77096005)(33656002)(790700001)(1220700001)(16236675004)(586003)(5003600100002)(102836003)(9686002)(3846002)(2900100001)(76576001)(5890100001)(66066001)(6116002)(54356999)(3280700002)(15975445007)(2950100001)(76176999)(5001770100001)(4326007)(3660700001)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16454DDD82325703ACC961C4F57D0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2016 05:00:36.2152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 05:00:40 -0000 --_000_SN1PR0301MB16454DDD82325703ACC961C4F57D0SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGd1eXMsIGZvciB3cml0aW5nIHRoZSBpbml0aWFsIGNoYXJ0ZXIgdGV4dC4gIFJlYWRp bmcgaXQgbm93LCBJIGFtIGV4dHJlbWVseSB3b3JyaWVkIGJ5IHRoZSBzY29wZSBjcmVlcCBldmlk ZW50IGluIHRoZSBwcm9wb3NhbC4NCg0KSSBzdHJvbmdseSBzdXBwb3J0IGEgd29ya2luZyBncm91 cCB0byBkZWZpbmUgYW4gSUQgRXZlbnRzIGRhdGEgZm9ybWF0LiAgSSBqdXN0IGFzIHN0cm9uZ2x5 IGJlbGlldmUgdGhhdCBzcGVjaWZpYyBldmVudCBkZWxpdmVyeSBtZWNoYW5pc21zIHdpbGwgbmVj ZXNzYXJpbHkgYmUgYXBwbGljYXRpb24tc3BlY2lmaWMgYW5kIHRoZXJlZm9yZSBNVVNUIGJlIGV4 cGxpY2l0bHkgYmUgc3RhdGVkIGFzIGJlaW5nIG91dCBvZiBzY29wZSBpbiB0aGUgd29ya2luZyBn cm91cCBjaGFydGVyLiAgQXR0ZW1wdGluZyB0byBzcGVjaWZ5IGEgcGFydGljdWxhciBldmVudCBk ZWxpdmVyeSBtZWNoYW5pc20gd2lsbCB0YWtlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIHNpbXBs ZSBhbmQgcXVpY2sgdG8gYXBwcm92ZSBhbmQgYm9nIGl0IGRvd24gaW4gbmVjZXNzYXJpbHkgYXBw bGljYXRpb24tc3BlY2lmaWMgZGViYXRlcy4NCg0KU2hvdWxkIGV2ZW50IGRlbGl2ZXJ5IGJlIHJl bGlhYmxlPyAgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNpb24uDQpTaG91 bGQgZXZlbnRzIGJlIGlkZW1wb3RlbnQ/ICBUaGF04oCZcyBhbiBhcHBsaWNhdGlvbi1zcGVjaWZp YyBkZWNpc2lvbi4NClNob3VsZCBldmVudHMgYmUgdW5pY2FzdCwgbXVsdGljYXN0LCBvciBicm9h ZGNhc3Q/ICBUaGF04oCZcyBhbiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkZWNpc2lvbi4NClNob3Vs ZCBldmVudHMgaGF2ZSBjYXRlZ29yaWVzIHdpdGggY2F0ZWdvcnktc3BlY2lmaWMgc3Vic2NyaXB0 aW9ucz8gIFRoYXTigJlzIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIGRlY2lzaW9uLg0KU2hvdWxk IG9ubHkgb25lIHBhcnR5IGF0IGEgdGltZSBiZSBhYmxlIHRvIHJlZ2lzdGVyIGZvciBkZWxpdmVy eSBvZiBldmVudHMgb3Igc2hvdWxkIG11bHRpcGxlIHBhcnRpZXMgYmUgYWJsZSB0byByZXF1ZXN0 IGRlbGl2ZXJ5PyAgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNpb24uDQpJ IGNvdWxkIGNvbnRpbnVlIHdpdGggdGhpcyBsaXN0LCBidXQgSSB0aGluayB5b3UgYWxsIGdldCB0 aGUgcG9pbnTigKYNCg0KSWYgd2Ugc3RhcnQgZGViYXRpbmcgYXBwbGljYXRpb24tc3BlY2lmaWMg ZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtcywgd2XigJlsbCBwbGVhc2UgYWxtb3N0IG5vIG9uZSwg c2luY2UgbmVhcmx5IGFsbCBhcHBsaWNhdGlvbnMgaGF2ZSBkaWZmZXJlbnQgZXZlbnQgZGVsaXZl cnkgcmVxdWlyZW1lbnRzLiAgV2UgTVVTVCBleHBsaWNpdGx5IHJ1bGUgYWxsIGRlbGl2ZXJ5IG1l Y2hhbmlzbXMgYXMgYmVpbmcgb3V0IG9mIHNjb3BlLg0KDQpJZiB3ZSBkZWZpbmUgb25seSBhIGRh dGEgZm9ybWF0LCB3ZSBjYW4gcXVpY2tseSBwcm9kdWNlIGEgdmVyeSB1c2VmdWwgc3BlY2lmaWNh dGlvbi4gIElmIHdlIGRvbuKAmXQsIHdl4oCZbGwgZ2V0IGJvZ2dlZCBkb3duIGluIHRoZSBtdWQg b2YgZGViYXRpbmcgd2hpY2ggYXBwbGljYXRpb25zIHdl4oCZcmUgY2F0ZXJpbmcgdG8gYW5kIHdo aWNoIHdlIGFyZW7igJl0IOKAkyBhbiBleGVyY2lzZSBvZiBwaWNraW5nIGZhdm9yaXRlcyBhbmQg bGltaXRpbmcgYXBwbGljYWJpbGl0eSBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gIFRoYXQgd2F5IGlz IGEgc2xvdywgcGFpbmZ1bCBkZXNjZW50IGludG8gc3RhbmRhcmRzIHF1aWNrc2FuZCDigJMgc29t ZXRoaW5nIHdlIG11c3QgYXZvaWQuICBIYXZpbmcgYSBzdGFuZGFyZCBJRCBldmVudHMgcmVwcmVz ZW50YXRpb24gaXMgZmFyIHRvbyBpbXBvcnRhbnQgdG8gdGllIHRvIGEgcGFydGljdWxhciBsaW1p dGVkIGV2ZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNpbmNlcmVseSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFsYW4gS2FycA0KU2VudDogVGh1cnNkYXksIE1heSA1LCAyMDE2IDk6NDMgUE0NClRv OiBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIDxtb3JhbnNhckBjaXNjby5jb20+DQpDYzogaWQt ZXZlbnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIFN0cmF3IG1hbiB0ZXh0IGZv ciBwcm9wb3NlZCBjaGFydGVyDQoNCkkgZG9uJ3Qgc2VlIGFueXRoaW5nIGFib3V0IGFjY2VzcyBj b250cm9sIGZvciBwdWJsaXNoaW5nIGV2ZW50cyBhbmQgc3Vic2NyaWJpbmcgdG8gdGhlbS4gIEkg YWxzbyB0aGluayB0aGUgc3BlYyBzaG91bGQgYWxsb3cgZmlsdGVycyBvbiBzdWJzY3JpcHRpb25z Lg0KDQoNCi0tLS0tLS0tLS0tLS0tDQpBbGFuIEthcnANCg0KT24gVGh1LCBNYXkgNSwgMjAxNiBh dCAxMToxOCBBTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSA8bW9yYW5zYXJAY2lzY28uY29t PG1haWx0bzptb3JhbnNhckBjaXNjby5jb20+PiB3cm90ZToNCkhpIGZvbGtzLA0KDQpBdCBJSVcg YSBmZXcgb2YgdXMgKFBoaWwsIFdpbGxpYW0sIEFkYW0sIGFuZCBJKSBodWRkbGVkIGZvciBhIGJp dCBhbmQgcHV0IHRvZ2V0aGVyIHRoZSBhdHRhY2hlZCBhcyBhIHN0cmF3IG1hbiBjaGFydGVyIHBy b3Bvc2FsIHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucyBmb3IgYW55IGNoYW5nZXMgb3IgcHJvcG9zZSBhIG5ldyBvbmUgaWYg eW91IHRoaW5rIGl0cyBuZWNlc3NhcnkuDQoNCg0KQ2hlZXJzLA0KTW9ydGV6YQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGlu ZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg== --_000_SN1PR0301MB16454DDD82325703ACC961C4F57D0SN1PR0301MB1645_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIGd1eXMsIGZvciB3cml0aW5n IHRoZSBpbml0aWFsIGNoYXJ0ZXIgdGV4dC4mbmJzcDsgUmVhZGluZyBpdCBub3csIEkgYW0gZXh0 cmVtZWx5IHdvcnJpZWQgYnkgdGhlIHNjb3BlIGNyZWVwIGV2aWRlbnQgaW4gdGhlIHByb3Bvc2Fs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBzdHJvbmdseSBz dXBwb3J0IGEgd29ya2luZyBncm91cCB0byBkZWZpbmUgYW4gSUQgRXZlbnRzIGRhdGEgZm9ybWF0 LiZuYnNwOyBJIGp1c3QgYXMgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHNwZWNpZmljIGV2ZW50IGRl bGl2ZXJ5IG1lY2hhbmlzbXMgd2lsbCBuZWNlc3NhcmlseSBiZQ0KIGFwcGxpY2F0aW9uLXNwZWNp ZmljIGFuZCB0aGVyZWZvcmUgTVVTVCBiZSBleHBsaWNpdGx5IGJlIHN0YXRlZCBhcyBiZWluZyBv dXQgb2Ygc2NvcGUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgY2hhcnRlci4mbmJzcDsgQXR0ZW1wdGlu ZyB0byBzcGVjaWZ5IGEgcGFydGljdWxhciBldmVudCBkZWxpdmVyeSBtZWNoYW5pc20gd2lsbCB0 YWtlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIHNpbXBsZSBhbmQgcXVpY2sgdG8gYXBwcm92ZSBh bmQgYm9nIGl0IGRvd24gaW4NCiBuZWNlc3NhcmlseSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkZWJh dGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U2hvdWxkIGV2 ZW50IGRlbGl2ZXJ5IGJlIHJlbGlhYmxlPyZuYnNwOyBUaGF04oCZcyBhbiBhcHBsaWNhdGlvbi1z cGVjaWZpYyBkZWNpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U2hvdWxkIGV2ZW50cyBiZSBpZGVt cG90ZW50PyZuYnNwOyBUaGF04oCZcyBhbiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkZWNpc2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+U2hvdWxkIGV2ZW50cyBiZSB1bmljYXN0LCBtdWx0aWNhc3QsIG9y IGJyb2FkY2FzdD8mbmJzcDsgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPlNob3VsZCBldmVudHMgaGF2ZSBjYXRlZ29yaWVzIHdpdGgg Y2F0ZWdvcnktc3BlY2lmaWMgc3Vic2NyaXB0aW9ucz8mbmJzcDsgVGhhdOKAmXMgYW4gYXBwbGlj YXRpb24tc3BlY2lmaWMgZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlNob3VsZCBvbmx5IG9u ZSBwYXJ0eSBhdCBhIHRpbWUgYmUgYWJsZSB0byByZWdpc3RlciBmb3IgZGVsaXZlcnkgb2YgZXZl bnRzIG9yIHNob3VsZCBtdWx0aXBsZSBwYXJ0aWVzIGJlIGFibGUgdG8gcmVxdWVzdCBkZWxpdmVy eT8gJm5ic3A7VGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMNCiBkZWNpc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+SSBjb3VsZCBjb250aW51ZSB3aXRoIHRoaXMgbGlzdCwgYnV0IEkgdGhp bmsgeW91IGFsbCBnZXQgdGhlIHBvaW504oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5JZiB3ZSBzdGFydCBkZWJhdGluZyBhcHBsaWNhdGlvbi1zcGVjaWZpYyBl dmVudCBkZWxpdmVyeSBtZWNoYW5pc21zLCB3ZeKAmWxsIHBsZWFzZSBhbG1vc3Qgbm8gb25lLCBz aW5jZSBuZWFybHkgYWxsIGFwcGxpY2F0aW9ucyBoYXZlIGRpZmZlcmVudCBldmVudCBkZWxpdmVy eSByZXF1aXJlbWVudHMuJm5ic3A7DQogV2UgTVVTVCBleHBsaWNpdGx5IHJ1bGUgYWxsIGRlbGl2 ZXJ5IG1lY2hhbmlzbXMgYXMgYmVpbmcgb3V0IG9mIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SWYgd2UgZGVmaW5lIG9ubHkgYSBkYXRhIGZvcm1hdCwg d2UgY2FuIHF1aWNrbHkgcHJvZHVjZSBhIHZlcnkgdXNlZnVsIHNwZWNpZmljYXRpb24uJm5ic3A7 IElmIHdlIGRvbuKAmXQsIHdl4oCZbGwgZ2V0IGJvZ2dlZCBkb3duIGluIHRoZSBtdWQgb2YgZGVi YXRpbmcgd2hpY2ggYXBwbGljYXRpb25zDQogd2XigJlyZSBjYXRlcmluZyB0byBhbmQgd2hpY2gg d2UgYXJlbuKAmXQg4oCTIGFuIGV4ZXJjaXNlIG9mIHBpY2tpbmcgZmF2b3JpdGVzIGFuZCBsaW1p dGluZyBhcHBsaWNhYmlsaXR5IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBUaGF0IHdheSBp cyBhIHNsb3csIHBhaW5mdWwgZGVzY2VudCBpbnRvIHN0YW5kYXJkcyBxdWlja3NhbmQg4oCTIHNv bWV0aGluZyB3ZSBtdXN0IGF2b2lkLiZuYnNwOyBIYXZpbmcgYSBzdGFuZGFyZCBJRCBldmVudHMg cmVwcmVzZW50YXRpb24gaXMNCiBmYXIgdG9vIGltcG9ydGFudCB0byB0aWUgdG8gYSBwYXJ0aWN1 bGFyIGxpbWl0ZWQgZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpbmNlcmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkLWV2ZW50IFttYWlsdG86 aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxhbiBLYXJw PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgNSwgMjAxNiA5OjQzIFBNPGJyPg0KPGI+ VG86PC9iPiBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpICZsdDttb3JhbnNhckBjaXNjby5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZC1ldmVudEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0lkLWV2ZW50XSBTdHJhdyBtYW4gdGV4dCBmb3IgcHJvcG9zZWQgY2hhcnRlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qgc2VlIGFueXRoaW5nIGFi b3V0IGFjY2VzcyBjb250cm9sIGZvciBwdWJsaXNoaW5nIGV2ZW50cyBhbmQgc3Vic2NyaWJpbmcg dG8gdGhlbS4mbmJzcDsgSSBhbHNvIHRoaW5rIHRoZSBzcGVjIHNob3VsZCBhbGxvdyBmaWx0ZXJz IG9uIHN1YnNjcmlwdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpBbGFu IEthcnA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIE1heSA1LCAyMDE2IGF0IDExOjE4IEFNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpICZs dDs8YSBocmVmPSJtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9y YW5zYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BdCBJSVcgYSBmZXcgb2YgdXMgKFBoaWws IFdpbGxpYW0sIEFkYW0sIGFuZCBJKSBodWRkbGVkIGZvciBhIGJpdCBhbmQgcHV0IHRvZ2V0aGVy IHRoZSBhdHRhY2hlZCBhcyBhIHN0cmF3IG1hbiBjaGFydGVyIHByb3Bvc2FsIHRvIHN0YXJ0IHRo ZSBkaXNjdXNzaW9uLiBQbGVhc2UNCiBzZW5kIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z IGZvciBhbnkgY2hhbmdlcyBvciBwcm9wb3NlIGEgbmV3IG9uZSBpZiB5b3UgdGhpbmsgaXRzIG5l Y2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Nb3J0ZXphPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB16454DDD82325703ACC961C4F57D0SN1PR0301MB1645_-- From nobody Sat May 7 01:35:17 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C012D0BA for ; Sat, 7 May 2016 01:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 WcoldPbC4guB for ; Sat, 7 May 2016 01:35:11 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 B37A612B014 for ; Sat, 7 May 2016 01:35:10 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u478Z10i023159 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 7 May 2016 10:35:01 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u478Yvdw021074 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 May 2016 10:34:59 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1462610100; bh=alaZtQRY6XJ4egMep9oMwACSWYD97rP7u5TEEy1vTZ0=; h=From:Subject:Date:References:To:In-Reply-To:Cc; b=xRDQYsegZpvPCx5UcfhlOxssNcawsrxMkWRxN9TpHj8Dryr8j/SoXdW3myligLtIU Ux7hzAq5zTQBJTf1AlgmLnNZMXt0790fVhB9M48qXXC7Nd0T3JzGpBwadkzzV8s/G1 d6znKtRJFtmGDOxVh+vZ0RhOmXrW4ssTAQJ8u1T8= X-Footer: c3VuZXQuc2U= Received: from [62.102.145.131] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA; Sat, 7 May 2016 10:34:53 +0200 From: "Leif Johansson" Content-Type: multipart/alternative; boundary=Apple-Mail-061BCD49-A0FF-4006-A520-6B8309E29BC7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <8A843FD3-2A47-45F9-81F2-C83127B0C099@sunet.se> Date: Sat, 7 May 2016 10:34:53 +0200 References: To: Mike Jones In-Reply-To: X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QPkz1VU - 5b9d3444f098 - 20160507 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 08:35:15 -0000 --Apple-Mail-061BCD49-A0FF-4006-A520-6B8309E29BC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNClNraWNrYXQgZnLDpW4gbWluIGlQaG9uZQ0KDQo+IDYgbWFqIDIwMTYga2wuIDA3OjAwIHNr cmV2IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT46DQo+IA0KPiBUaGFu a3MgZ3V5cywgZm9yIHdyaXRpbmcgdGhlIGluaXRpYWwgY2hhcnRlciB0ZXh0LiAgUmVhZGluZyBp dCBub3csIEkgYW0gZXh0cmVtZWx5IHdvcnJpZWQgYnkgdGhlIHNjb3BlIGNyZWVwIGV2aWRlbnQg aW4gdGhlIHByb3Bvc2FsLg0KPiAgDQo+IEkgc3Ryb25nbHkgc3VwcG9ydCBhIHdvcmtpbmcgZ3Jv dXAgdG8gZGVmaW5lIGFuIElEIEV2ZW50cyBkYXRhIGZvcm1hdC4gIEkganVzdCBhcyBzdHJvbmds eSBiZWxpZXZlIHRoYXQgc3BlY2lmaWMgZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtcyB3aWxsIG5l Y2Vzc2FyaWx5IGJlIGFwcGxpY2F0aW9uLXNwZWNpZmljIGFuZCB0aGVyZWZvcmUgTVVTVCBiZSBl eHBsaWNpdGx5IGJlIHN0YXRlZCBhcyBiZWluZyBvdXQgb2Ygc2NvcGUgaW4gdGhlIHdvcmtpbmcg Z3JvdXAgY2hhcnRlci4gIEF0dGVtcHRpbmcgdG8gc3BlY2lmeSBhIHBhcnRpY3VsYXIgZXZlbnQg ZGVsaXZlcnkgbWVjaGFuaXNtIHdpbGwgdGFrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBzaW1w bGUgYW5kIHF1aWNrIHRvIGFwcHJvdmUgYW5kIGJvZyBpdCBkb3duIGluIG5lY2Vzc2FyaWx5IGFw cGxpY2F0aW9uLXNwZWNpZmljIGRlYmF0ZXMuDQo+ICANCj4gU2hvdWxkIGV2ZW50IGRlbGl2ZXJ5 IGJlIHJlbGlhYmxlPyAgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNpb24u DQo+IFNob3VsZCBldmVudHMgYmUgaWRlbXBvdGVudD8gIFRoYXTigJlzIGFuIGFwcGxpY2F0aW9u LXNwZWNpZmljIGRlY2lzaW9uLg0KPiBTaG91bGQgZXZlbnRzIGJlIHVuaWNhc3QsIG11bHRpY2Fz dCwgb3IgYnJvYWRjYXN0PyAgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNp b24uDQo+IFNob3VsZCBldmVudHMgaGF2ZSBjYXRlZ29yaWVzIHdpdGggY2F0ZWdvcnktc3BlY2lm aWMgc3Vic2NyaXB0aW9ucz8gIFRoYXTigJlzIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIGRlY2lz aW9uLg0KPiBTaG91bGQgb25seSBvbmUgcGFydHkgYXQgYSB0aW1lIGJlIGFibGUgdG8gcmVnaXN0 ZXIgZm9yIGRlbGl2ZXJ5IG9mIGV2ZW50cyBvciBzaG91bGQgbXVsdGlwbGUgcGFydGllcyBiZSBh YmxlIHRvIHJlcXVlc3QgZGVsaXZlcnk/ICBUaGF04oCZcyBhbiBhcHBsaWNhdGlvbi1zcGVjaWZp YyBkZWNpc2lvbi4NCj4gSSBjb3VsZCBjb250aW51ZSB3aXRoIHRoaXMgbGlzdCwgYnV0IEkgdGhp bmsgeW91IGFsbCBnZXQgdGhlIHBvaW504oCmDQo+ICANCj4gSWYgd2Ugc3RhcnQgZGViYXRpbmcg YXBwbGljYXRpb24tc3BlY2lmaWMgZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtcywgd2XigJlsbCBw bGVhc2UgYWxtb3N0IG5vIG9uZSwgc2luY2UgbmVhcmx5IGFsbCBhcHBsaWNhdGlvbnMgaGF2ZSBk aWZmZXJlbnQgZXZlbnQgZGVsaXZlcnkgcmVxdWlyZW1lbnRzLiAgV2UgTVVTVCBleHBsaWNpdGx5 IHJ1bGUgYWxsIGRlbGl2ZXJ5IG1lY2hhbmlzbXMgYXMgYmVpbmcgb3V0IG9mIHNjb3BlLg0KPiAg DQo+IElmIHdlIGRlZmluZSBvbmx5IGEgZGF0YSBmb3JtYXQsIHdlIGNhbiBxdWlja2x5IHByb2R1 Y2UgYSB2ZXJ5IHVzZWZ1bCBzcGVjaWZpY2F0aW9uLiAgSWYgd2UgZG9u4oCZdCwgd2XigJlsbCBn ZXQgYm9nZ2VkIGRvd24gaW4gdGhlIG11ZCBvZiBkZWJhdGluZyB3aGljaCBhcHBsaWNhdGlvbnMg d2XigJlyZSBjYXRlcmluZyB0byBhbmQgd2hpY2ggd2UgYXJlbuKAmXQg4oCTIGFuIGV4ZXJjaXNl IG9mIHBpY2tpbmcgZmF2b3JpdGVzIGFuZCBsaW1pdGluZyBhcHBsaWNhYmlsaXR5IG9mIHRoZSBz cGVjaWZpY2F0aW9uLiAgVGhhdCB3YXkgaXMgYSBzbG93LCBwYWluZnVsIGRlc2NlbnQgaW50byBz dGFuZGFyZHMgcXVpY2tzYW5kIOKAkyBzb21ldGhpbmcgd2UgbXVzdCBhdm9pZC4gIEhhdmluZyBh IHN0YW5kYXJkIElEIGV2ZW50cyByZXByZXNlbnRhdGlvbiBpcyBmYXIgdG9vIGltcG9ydGFudCB0 byB0aWUgdG8gYSBwYXJ0aWN1bGFyIGxpbWl0ZWQgZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtLg0K PiAgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTaW5jZXJlbHksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KKzENCg0KPiAgDQo+IEZyb206IElk LWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFs YW4gS2FycA0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDUsIDIwMTYgOTo0MyBQTQ0KPiBUbzogTW9y dGV6YSBBbnNhcmkgKG1vcmFuc2FyKSA8bW9yYW5zYXJAY2lzY28uY29tPg0KPiBDYzogaWQtZXZl bnRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZC1ldmVudF0gU3RyYXcgbWFuIHRleHQgZm9y IHByb3Bvc2VkIGNoYXJ0ZXINCj4gIA0KPiBJIGRvbid0IHNlZSBhbnl0aGluZyBhYm91dCBhY2Nl c3MgY29udHJvbCBmb3IgcHVibGlzaGluZyBldmVudHMgYW5kIHN1YnNjcmliaW5nIHRvIHRoZW0u ICBJIGFsc28gdGhpbmsgdGhlIHNwZWMgc2hvdWxkIGFsbG93IGZpbHRlcnMgb24gc3Vic2NyaXB0 aW9ucy4NCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLQ0KPiBBbGFuIEthcnANCj4gIA0KPiBPbiBU aHUsIE1heSA1LCAyMDE2IGF0IDExOjE4IEFNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIDxt b3JhbnNhckBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBmb2xrcywNCj4gIA0KPiBBdCBJSVcgYSBm ZXcgb2YgdXMgKFBoaWwsIFdpbGxpYW0sIEFkYW0sIGFuZCBJKSBodWRkbGVkIGZvciBhIGJpdCBh bmQgcHV0IHRvZ2V0aGVyIHRoZSBhdHRhY2hlZCBhcyBhIHN0cmF3IG1hbiBjaGFydGVyIHByb3Bv c2FsIHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucyBmb3IgYW55IGNoYW5nZXMgb3IgcHJvcG9zZSBhIG5ldyBvbmUgaWYgeW91 IHRoaW5rIGl0cyBuZWNlc3NhcnkuDQo+ICANCj4gIA0KPiBDaGVlcnMsDQo+IE1vcnRlemENCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElk LWV2ZW50IG1haWxpbmcgbGlzdA0KPiBJZC1ldmVudEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQo+IA0KPiAgDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkLWV2ZW50IG1haWxpbmcg bGlzdA0KPiBJZC1ldmVudEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50DQo= --Apple-Mail-061BCD49-A0FF-4006-A520-6B8309E29BC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGJyPjxi cj5Ta2lja2F0IGZyw6VuIG1pbiBpUGhvbmU8L2Rpdj48ZGl2Pjxicj42IG1haiAyMDE2IGtsLiAw NzowMCBza3JldiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8YnI+PGJy PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQoNCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRh IG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoYW5r cyBndXlzLCBmb3Igd3JpdGluZyB0aGUgaW5pdGlhbCBjaGFydGVyIHRleHQuJm5ic3A7IFJlYWRp bmcgaXQgbm93LCBJIGFtIGV4dHJlbWVseSB3b3JyaWVkIGJ5IHRoZSBzY29wZSBjcmVlcCBldmlk ZW50IGluIHRoZSBwcm9wb3NhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPkkgc3Ryb25nbHkgc3VwcG9ydCBhIHdvcmtpbmcgZ3JvdXAgdG8gZGVmaW5lIGFuIElE IEV2ZW50cyBkYXRhIGZvcm1hdC4mbmJzcDsgSSBqdXN0IGFzIHN0cm9uZ2x5IGJlbGlldmUgdGhh dCBzcGVjaWZpYyBldmVudCBkZWxpdmVyeSBtZWNoYW5pc21zIHdpbGwgbmVjZXNzYXJpbHkgYmUN CiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBhbmQgdGhlcmVmb3JlIE1VU1QgYmUgZXhwbGljaXRseSBi ZSBzdGF0ZWQgYXMgYmVpbmcgb3V0IG9mIHNjb3BlIGluIHRoZSB3b3JraW5nIGdyb3VwIGNoYXJ0 ZXIuJm5ic3A7IEF0dGVtcHRpbmcgdG8gc3BlY2lmeSBhIHBhcnRpY3VsYXIgZXZlbnQgZGVsaXZl cnkgbWVjaGFuaXNtIHdpbGwgdGFrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBzaW1wbGUgYW5k IHF1aWNrIHRvIGFwcHJvdmUgYW5kIGJvZyBpdCBkb3duIGluDQogbmVjZXNzYXJpbHkgYXBwbGlj YXRpb24tc3BlY2lmaWMgZGViYXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPlNob3VsZCBldmVudCBkZWxpdmVyeSBiZSByZWxpYWJsZT8mbmJzcDsgVGhhdOKA mXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlNo b3VsZCBldmVudHMgYmUgaWRlbXBvdGVudD8mbmJzcDsgVGhhdOKAmXMgYW4gYXBwbGljYXRpb24t c3BlY2lmaWMgZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlNob3VsZCBldmVudHMgYmUgdW5p Y2FzdCwgbXVsdGljYXN0LCBvciBicm9hZGNhc3Q/Jm5ic3A7IFRoYXTigJlzIGFuIGFwcGxpY2F0 aW9uLXNwZWNpZmljIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5TaG91bGQgZXZlbnRzIGhh dmUgY2F0ZWdvcmllcyB3aXRoIGNhdGVnb3J5LXNwZWNpZmljIHN1YnNjcmlwdGlvbnM/Jm5ic3A7 IFRoYXTigJlzIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5TaG91bGQgb25seSBvbmUgcGFydHkgYXQgYSB0aW1lIGJlIGFibGUgdG8gcmVnaXN0ZXIg Zm9yIGRlbGl2ZXJ5IG9mIGV2ZW50cyBvciBzaG91bGQgbXVsdGlwbGUgcGFydGllcyBiZSBhYmxl IHRvIHJlcXVlc3QgZGVsaXZlcnk/ICZuYnNwO1RoYXTigJlzIGFuIGFwcGxpY2F0aW9uLXNwZWNp ZmljDQogZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgY291bGQgY29udGludWUgd2l0aCB0 aGlzIGxpc3QsIGJ1dCBJIHRoaW5rIHlvdSBhbGwgZ2V0IHRoZSBwb2ludOKApjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SWYgd2Ugc3RhcnQgZGViYXRpbmcgYXBw bGljYXRpb24tc3BlY2lmaWMgZXZlbnQgZGVsaXZlcnkgbWVjaGFuaXNtcywgd2XigJlsbCBwbGVh c2UgYWxtb3N0IG5vIG9uZSwgc2luY2UgbmVhcmx5IGFsbCBhcHBsaWNhdGlvbnMgaGF2ZSBkaWZm ZXJlbnQgZXZlbnQgZGVsaXZlcnkgcmVxdWlyZW1lbnRzLiZuYnNwOw0KIFdlIE1VU1QgZXhwbGlj aXRseSBydWxlIGFsbCBkZWxpdmVyeSBtZWNoYW5pc21zIGFzIGJlaW5nIG91dCBvZiBzY29wZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPklmIHdlIGRlZmluZSBv bmx5IGEgZGF0YSBmb3JtYXQsIHdlIGNhbiBxdWlja2x5IHByb2R1Y2UgYSB2ZXJ5IHVzZWZ1bCBz cGVjaWZpY2F0aW9uLiZuYnNwOyBJZiB3ZSBkb27igJl0LCB3ZeKAmWxsIGdldCBib2dnZWQgZG93 biBpbiB0aGUgbXVkIG9mIGRlYmF0aW5nIHdoaWNoIGFwcGxpY2F0aW9ucw0KIHdl4oCZcmUgY2F0 ZXJpbmcgdG8gYW5kIHdoaWNoIHdlIGFyZW7igJl0IOKAkyBhbiBleGVyY2lzZSBvZiBwaWNraW5n IGZhdm9yaXRlcyBhbmQgbGltaXRpbmcgYXBwbGljYWJpbGl0eSBvZiB0aGUgc3BlY2lmaWNhdGlv bi4mbmJzcDsgVGhhdCB3YXkgaXMgYSBzbG93LCBwYWluZnVsIGRlc2NlbnQgaW50byBzdGFuZGFy ZHMgcXVpY2tzYW5kIOKAkyBzb21ldGhpbmcgd2UgbXVzdCBhdm9pZC4mbmJzcDsgSGF2aW5nIGEg c3RhbmRhcmQgSUQgZXZlbnRzIHJlcHJlc2VudGF0aW9uIGlzDQogZmFyIHRvbyBpbXBvcnRhbnQg dG8gdGllIHRvIGEgcGFydGljdWxhciBsaW1pdGVkIGV2ZW50IGRlbGl2ZXJ5IG1lY2hhbmlzbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaW5jZXJlbHksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4rMTwvZGl2Pjxicj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFu Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gSWQtZXZlbnQgWzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFsYW4gS2FycDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg TWF5IDUsIDIwMTYgOTo0MyBQTTxicj4NCjxiPlRvOjwvYj4gTW9ydGV6YSBBbnNhcmkgKG1vcmFu c2FyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSI+bW9yYW5zYXJAY2lz Y28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb SWQtZXZlbnRdIFN0cmF3IG1hbiB0ZXh0IGZvciBwcm9wb3NlZCBjaGFydGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBzZWUgYW55dGhpbmcgYWJvdXQgYWNj ZXNzIGNvbnRyb2wgZm9yIHB1Ymxpc2hpbmcgZXZlbnRzIGFuZCBzdWJzY3JpYmluZyB0byB0aGVt LiZuYnNwOyBJIGFsc28gdGhpbmsgdGhlIHNwZWMgc2hvdWxkIGFsbG93IGZpbHRlcnMgb24gc3Vi c2NyaXB0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLS0tLS0tLS0tLTxicj4NCkFsYW4gS2FycDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWF5 IDUsIDIwMTYgYXQgMTE6MTggQU0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgJmx0OzxhIGhy ZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JhbnNhckBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+SGkgZm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF0IElJVyBhIGZldyBvZiB1cyAoUGhpbCwgV2lsbGlh bSwgQWRhbSwgYW5kIEkpIGh1ZGRsZWQgZm9yIGEgYml0IGFuZCBwdXQgdG9nZXRoZXIgdGhlIGF0 dGFjaGVkIGFzIGEgc3RyYXcgbWFuIGNoYXJ0ZXIgcHJvcG9zYWwgdG8gc3RhcnQgdGhlIGRpc2N1 c3Npb24uIFBsZWFzZQ0KIHNlbmQgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgZm9yIGFu eSBjaGFuZ2VzIG9yIHByb3Bvc2UgYSBuZXcgb25lIGlmIHlvdSB0aGluayBpdHMgbmVjZXNzYXJ5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNoZWVy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1vcnRlemE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCg0KDQo8L2Rpdj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+SWQt ZXZlbnQgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48L3NwYW4+PGJyPjwv ZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-061BCD49-A0FF-4006-A520-6B8309E29BC7-- From nobody Sat May 7 07:19:50 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8C612D150 for ; Sat, 7 May 2016 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 M0QFQxfeJWT9 for ; Sat, 7 May 2016 07:19:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 5AEEF12B011 for ; Sat, 7 May 2016 07:19:46 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u47EJekU012438 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 7 May 2016 14:19:40 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u47EJeoY005735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 May 2016 14:19:40 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u47EJdXT025380; Sat, 7 May 2016 14:19:40 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 May 2016 07:19:39 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-C505E492-BD19-4D78-A1DA-124B689788AE Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sat, 7 May 2016 07:19:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Jones X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 14:19:48 -0000 --Apple-Mail-C505E492-BD19-4D78-A1DA-124B689788AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike A number of people have indicated they need a transport. The commonalities a= re 90-99% the same. It would seem wise to sort out what is truly contextual.= =20 I think things like feed definitions and filters are highly contextual in pa= rticular.=20 Putting that aside i do not see much difference between RISC, logout, revoca= tion, and SCIM other than event meaning. =20 Why would we want multiple solutions here? Your colleague Craig has a very different case, but the watermarking in his p= olling proposal serves to address all your concerns and can be used in push s= ystem as well.=20 Phil > On May 5, 2016, at 22:00, Mike Jones wrote: >=20 > Thanks guys, for writing the initial charter text. Reading it now, I am e= xtremely worried by the scope creep evident in the proposal. > =20 > I strongly support a working group to define an ID Events data format. I j= ust as strongly believe that specific event delivery mechanisms will necessa= rily be application-specific and therefore MUST be explicitly be stated as b= eing out of scope in the working group charter. Attempting to specify a par= ticular event delivery mechanism will take something that could be simple an= d quick to approve and bog it down in necessarily application-specific debat= es. > =20 > Should event delivery be reliable? That=E2=80=99s an application-specific= decision. > Should events be idempotent? That=E2=80=99s an application-specific decis= ion. > Should events be unicast, multicast, or broadcast? That=E2=80=99s an appl= ication-specific decision. > Should events have categories with category-specific subscriptions? That=E2= =80=99s an application-specific decision. > Should only one party at a time be able to register for delivery of events= or should multiple parties be able to request delivery? That=E2=80=99s an a= pplication-specific decision. > I could continue with this list, but I think you all get the point=E2=80=A6= > =20 > If we start debating application-specific event delivery mechanisms, we=E2= =80=99ll please almost no one, since nearly all applications have different e= vent delivery requirements. We MUST explicitly rule all delivery mechanisms= as being out of scope. > =20 > If we define only a data format, we can quickly produce a very useful spec= ification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in the mud of= debating which applications we=E2=80=99re catering to and which we aren=E2=80= =99t =E2=80=93 an exercise of picking favorites and limiting applicability o= f the specification. That way is a slow, painful descent into standards qui= cksand =E2=80=93 something we must avoid. Having a standard ID events repre= sentation is far too important to tie to a particular limited event delivery= mechanism. > =20 > Sincerely, > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp > Sent: Thursday, May 5, 2016 9:43 PM > To: Morteza Ansari (moransar) > Cc: id-event@ietf.org > Subject: Re: [Id-event] Straw man text for proposed charter > =20 > I don't see anything about access control for publishing events and subscr= ibing to them. I also think the spec should allow filters on subscriptions.= >=20 >=20 > -------------- > Alan Karp > =20 > On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) wrote: > Hi folks, > =20 > At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put t= ogether the attached as a straw man charter proposal to start the discussion= . Please send your comments and suggestions for any changes or propose a new= one if you think its necessary. > =20 > =20 > Cheers, > Morteza >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-C505E492-BD19-4D78-A1DA-124B689788AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mike

A number of people have indicate= d they need a transport. The commonalities are 90-99% the same. It would see= m wise to sort out what is truly contextual. 

I think things like feed= definitions and filters are highly contextual in particular. 

Putting= that aside i do not see much difference between RISC, logout, revocation, a= nd SCIM other than event meaning.  

Why would we want multiple solutio= ns here?

Your colleague Craig has a very different case, but the watermarki= ng in his polling proposal serves to address all your concerns and can be us= ed in push system as well. 

Phil

On May 5, 2016, at 22:0= 0, Mike Jones <Michael.Jon= es@microsoft.com> wrote:

=

Thanks guys, for writing the initial ch= arter text.  Reading it now, I am extremely worried by the scope creep e= vident in the proposal.

 

I strongly support a working group to d= efine an ID Events data format.  I just as strongly believe that specif= ic event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being ou= t of scope in the working group charter.  Attempting to specify a parti= cular event delivery mechanism will take something that could be simple and q= uick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable? = ; That=E2=80=99s an application-specific decision.

Should events be idempotent?  That= =E2=80=99s an application-specific decision.

Should events be unicast, multicast, or= broadcast?  That=E2=80=99s an application-specific decision.

Should events have categories with cate= gory-specific subscriptions?  That=E2=80=99s an application-specific de= cision.

Should only one party at a time be able= to register for delivery of events or should multiple parties be able to re= quest delivery?  That=E2=80=99s an application-specific decision.

I could continue with this list, but I t= hink you all get the point=E2=80=A6

 

If we start debating application-specif= ic event delivery mechanisms, we=E2=80=99ll please almost no one, since near= ly all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as being out of scope.=

 

If we define only a data format, we can= quickly produce a very useful specification.  If we don=E2=80=99t, we=E2= =80=99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80=93 an exercise= of picking favorites and limiting applicability of the specification. = That way is a slow, painful descent into standards quicksand =E2=80=93 some= thing we must avoid.  Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.<= o:p>

 

      &nb= sp;            &= nbsp;            = ;            &nb= sp;             S= incerely,

      &nb= sp;            &= nbsp;            = ;            &nb= sp;             -= - Mike

 =

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

I don't see anything about access control for publish= ing events and subscribing to them.  I also think the spec should allow= filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mora= nsar) <moransar@c= isco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Adam, a= nd I) huddled for a bit and put together the attached as a straw man charter= proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if y= ou think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-C505E492-BD19-4D78-A1DA-124B689788AE-- From nobody Sat May 7 07:50:47 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28DE12B052 for ; Sat, 7 May 2016 07:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 CyxJm7XD67Ai for ; Sat, 7 May 2016 07:50:43 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 06E1112D174 for ; Sat, 7 May 2016 07:50:41 -0700 (PDT) X-AuditID: 1209190f-c8fff70000004b9e-1f-572e00c0fd93 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3F.23.19358.0C00E275; Sat, 7 May 2016 10:50:40 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u47Eod2v018549; Sat, 7 May 2016 10:50:40 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u47EobMu021903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 May 2016 10:50:38 -0400 To: "Phil Hunt (IDM)" , Mike Jones References: From: Justin Richer Message-ID: Date: Sat, 7 May 2016 10:50:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E6E536A93AE46626CD5630C" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nonuAQS/coGm5ksWeiVMYLToWdDNZ 7J32icXiTm8zu8WC+Y3sDqweU35vZPXYOesuu8eSJT+ZPFp3/GX3+Pj0FksAaxSXTUpqTmZZ apG+XQJXxr4V09gKji5krNi/gLuB8UxFFyMnh4SAicS6h4/Yuxi5OIQE2pgkuv58ZoNwNjBK 9F+cDZW5xSTx4/dFZpAWYQFrid8zT7F0MXJwiAjES/y5YgBR08gkMaXvJiuIwywwgVFi1ZX1 YA1sAqoS09e0MIHYvAJWEh/PP2YBsVkEVCQ2PjjLDmKLCkRJPDm9lhmiRlDi5MwnYDWcAnYS U/efAetlFgiTOPrgOfMERv5ZSMpmIUlB2LYSd+buhrLlJZq3zoaydSUWbVvBjiy+gJFtFaNs Sm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRlBkcEry72Cc0+B9iFGAg1GJh/eEp264 EGtiWXFl7iFGSQ4mJVFe7n6gEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe/j9AOd6UxMqq1KJ8 mJQ0B4uSOC8jAwODkEB6YklqdmpqQWoRTFaGg0NJgvfgf6BGwaLU9NSKtMycEoQ0EwcnyHAe oOFrQWp4iwsSc4sz0yHypxgVpcR5N/0DSgiAJDJK8+B6QYkr4e1h01eM4kCvCPP+AWnnASY9 uO5XQIOZgAa/n6sJMrgkESEl1cBoteJSevsHCZnvG7bvdy//NOOM5Te14FuNaVc4Pmh98Zx4 5zKPrKb+lqmG2suuJO7tVhYv3lutraLQn3lUc9HXEyIK/tOr6zcoyYgIbjBy7hX+9TPx4ta9 RprXJT5f+pAwqXIqb+3GxMqTepZ3d/eYe8Yf3FHg5Wxwf6Mbh/Q29tjl7W88m0yVWIozEg21 mIuKEwHcSjU7NwMAAA== Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 14:50:46 -0000 This is a multi-part message in MIME format. --------------5E6E536A93AE46626CD5630C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Importantly, I think the concerns are separable. We can quickly define the format and content, as Mike suggests, and define an API (or set of APIs) around its transport later. We don't have to hold up the first work for the latter, nor should things be so tightly coupled that we'd need to do that anyway. -- Justin On 5/7/2016 10:19 AM, Phil Hunt (IDM) wrote: > Mike > > A number of people have indicated they need a transport. The > commonalities are 90-99% the same. It would seem wise to sort out what > is truly contextual. > > I think things like feed definitions and filters are highly contextual > in particular. > > Putting that aside i do not see much difference between RISC, logout, > revocation, and SCIM other than event meaning. > > Why would we want multiple solutions here? > > Your colleague Craig has a very different case, but the watermarking > in his polling proposal serves to address all your concerns and can be > used in push system as well. > > Phil > > On May 5, 2016, at 22:00, Mike Jones > wrote: > >> Thanks guys, for writing the initial charter text. Reading it now, I >> am extremely worried by the scope creep evident in the proposal. >> >> I strongly support a working group to define an ID Events data >> format. I just as strongly believe that specific event delivery >> mechanisms will necessarily be application-specific and therefore >> MUST be explicitly be stated as being out of scope in the working >> group charter. Attempting to specify a particular event delivery >> mechanism will take something that could be simple and quick to >> approve and bog it down in necessarily application-specific debates. >> >> Should event delivery be reliable? That’s an application-specific >> decision. >> >> Should events be idempotent? That’s an application-specific decision. >> >> Should events be unicast, multicast, or broadcast? That’s an >> application-specific decision. >> >> Should events have categories with category-specific subscriptions? >> That’s an application-specific decision. >> >> Should only one party at a time be able to register for delivery of >> events or should multiple parties be able to request delivery? >> That’s an application-specific decision. >> >> I could continue with this list, but I think you all get the point… >> >> If we start debating application-specific event delivery mechanisms, >> we’ll please almost no one, since nearly all applications have >> different event delivery requirements. We MUST explicitly rule all >> delivery mechanisms as being out of scope. >> >> If we define only a data format, we can quickly produce a very useful >> specification. If we don’t, we’ll get bogged down in the mud of >> debating which applications we’re catering to and which we aren’t – >> an exercise of picking favorites and limiting applicability of the >> specification. That way is a slow, painful descent into standards >> quicksand – something we must avoid. Having a standard ID events >> representation is far too important to tie to a particular limited >> event delivery mechanism. >> >> Sincerely, >> >> -- Mike >> >> *From:*Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of >> *Alan Karp >> *Sent:* Thursday, May 5, 2016 9:43 PM >> *To:* Morteza Ansari (moransar) > > >> *Cc:* id-event@ietf.org >> *Subject:* Re: [Id-event] Straw man text for proposed charter >> >> I don't see anything about access control for publishing events and >> subscribing to them. I also think the spec should allow filters on >> subscriptions. >> >> >> >> -------------- >> Alan Karp >> >> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) >> > wrote: >> >> Hi folks, >> >> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit >> and put together the attached as a straw man charter proposal to >> start the discussion. Please send your comments and suggestions >> for any changes or propose a new one if you think its necessary. >> >> Cheers, >> >> Morteza >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------5E6E536A93AE46626CD5630C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Importantly, I think the concerns are separable. We can quickly define the format and content, as Mike suggests, and define an API (or set of APIs) around its transport later. We don't have to hold up the first work for the latter, nor should things be so tightly coupled that we'd need to do that anyway.

 -- Justin


On 5/7/2016 10:19 AM, Phil Hunt (IDM) wrote:
Mike

A number of people have indicated they need a transport. The commonalities are 90-99% the same. It would seem wise to sort out what is truly contextual. 

I think things like feed definitions and filters are highly contextual in particular. 

Putting that aside i do not see much difference between RISC, logout, revocation, and SCIM other than event meaning.  

Why would we want multiple solutions here?

Your colleague Craig has a very different case, but the watermarking in his polling proposal serves to address all your concerns and can be used in push system as well. 

Phil

On May 5, 2016, at 22:00, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks guys, for writing the initial charter text.  Reading it now, I am extremely worried by the scope creep evident in the proposal.

 

I strongly support a working group to define an ID Events data format.  I just as strongly believe that specific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being out of scope in the working group charter.  Attempting to specify a particular event delivery mechanism will take something that could be simple and quick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable?  That’s an application-specific decision.

Should events be idempotent?  That’s an application-specific decision.

Should events be unicast, multicast, or broadcast?  That’s an application-specific decision.

Should events have categories with category-specific subscriptions?  That’s an application-specific decision.

Should only one party at a time be able to register for delivery of events or should multiple parties be able to request delivery?  That’s an application-specific decision.

I could continue with this list, but I think you all get the point…

 

If we start debating application-specific event delivery mechanisms, we’ll please almost no one, since nearly all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as being out of scope.

 

If we define only a data format, we can quickly produce a very useful specification.  If we don’t, we’ll get bogged down in the mud of debating which applications we’re catering to and which we aren’t – an exercise of picking favorites and limiting applicability of the specification.  That way is a slow, painful descent into standards quicksand – something we must avoid.  Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.

 

                                                          Sincerely,

                                                          -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

I don't see anything about access control for publishing events and subscribing to them.  I also think the spec should allow filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put together the attached as a straw man charter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if you think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--------------5E6E536A93AE46626CD5630C-- From nobody Sat May 7 08:03:33 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7200412D1CB for ; Sat, 7 May 2016 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 Ss4zeN1c1YIz for ; Sat, 7 May 2016 08:03:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1C07A12D1AE for ; Sat, 7 May 2016 08:03:21 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u47F3IO1017311 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 May 2016 15:03:19 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u47F3HRc024955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 May 2016 15:03:18 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u47F3FjY022316; Sat, 7 May 2016 15:03:15 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 May 2016 08:03:14 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-D508E1FE-7773-4DAB-8DC8-E2BC9A1F71FA Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sat, 7 May 2016 08:03:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Justin Richer X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Alan Karp , Mike Jones , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 15:03:30 -0000 --Apple-Mail-D508E1FE-7773-4DAB-8DC8-E2BC9A1F71FA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the charter proposal we have the event format on fast track. (A meeting o= r so) Phil > On May 7, 2016, at 07:50, Justin Richer wrote: >=20 > Importantly, I think the concerns are separable. We can quickly define the= format and content, as Mike suggests, and define an API (or set of APIs) ar= ound its transport later. We don't have to hold up the first work for the la= tter, nor should things be so tightly coupled that we'd need to do that anyw= ay. >=20 > -- Justin >=20 >> On 5/7/2016 10:19 AM, Phil Hunt (IDM) wrote: >> Mike >>=20 >> A number of people have indicated they need a transport. The commonalitie= s are 90-99% the same. It would seem wise to sort out what is truly contextu= al.=20 >>=20 >> I think things like feed definitions and filters are highly contextual in= particular.=20 >>=20 >> Putting that aside i do not see much difference between RISC, logout, rev= ocation, and SCIM other than event meaning.=20 >>=20 >> Why would we want multiple solutions here? >>=20 >> Your colleague Craig has a very different case, but the watermarking in h= is polling proposal serves to address all your concerns and can be used in p= ush system as well.=20 >>=20 >> Phil >>=20 >> On May 5, 2016, at 22:00, Mike Jones wrote:= >>=20 >>> Thanks guys, for writing the initial charter text. Reading it now, I am= extremely worried by the scope creep evident in the proposal. >>> =20 >>> I strongly support a working group to define an ID Events data format. I= just as strongly believe that specific event delivery mechanisms will neces= sarily be application-specific and therefore MUST be explicitly be stated as= being out of scope in the working group charter. Attempting to specify a p= articular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific deba= tes. >>> =20 >>> Should event delivery be reliable? That=E2=80=99s an application-specif= ic decision. >>> Should events be idempotent? That=E2=80=99s an application-specific dec= ision. >>> Should events be unicast, multicast, or broadcast? That=E2=80=99s an ap= plication-specific decision. >>> Should events have categories with category-specific subscriptions? Tha= t=E2=80=99s an application-specific decision. >>> Should only one party at a time be able to register for delivery of even= ts or should multiple parties be able to request delivery? That=E2=80=99s a= n application-specific decision. >>> I could continue with this list, but I think you all get the point=E2=80= =A6 >>> =20 >>> If we start debating application-specific event delivery mechanisms, we=E2= =80=99ll please almost no one, since nearly all applications have different e= vent delivery requirements. We MUST explicitly rule all delivery mechanisms= as being out of scope. >>> =20 >>> If we define only a data format, we can quickly produce a very useful sp= ecification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in the mud o= f debating which applications we=E2=80=99re catering to and which we aren=E2= =80=99t =E2=80=93 an exercise of picking favorites and limiting applicabilit= y of the specification. That way is a slow, painful descent into standards q= uicksand =E2=80=93 something we must avoid. Having a standard ID events rep= resentation is far too important to tie to a particular limited event delive= ry mechanism. >>> =20 >>> Sincerely, >>> -- Mike >>> =20 >>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp= >>> Sent: Thursday, May 5, 2016 9:43 PM >>> To: Morteza Ansari (moransar) >>> Cc: id-event@ietf.org >>> Subject: Re: [Id-event] Straw man text for proposed charter >>> =20 >>> I don't see anything about access control for publishing events and subs= cribing to them. I also think the spec should allow filters on subscription= s. >>>=20 >>>=20 >>> -------------- >>> Alan Karp >>> =20 >>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) wrote: >>> Hi folks, >>> =20 >>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and pu= t together the attached as a straw man charter proposal to start the discuss= ion. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. >>> =20 >>> =20 >>> Cheers, >>> Morteza >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-D508E1FE-7773-4DAB-8DC8-E2BC9A1F71FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In the charter proposal we have the ev= ent format on fast track. (A meeting or so)

Phil

On May= 7, 2016, at 07:50, Justin Richer <jri= cher@mit.edu> wrote:

=20 =20 =20

Importantly, I think the concerns are separable. We can quickly define the format and content, as Mike suggests, and define an API (or set of APIs) around its transport later. We don't have to hold up the first work for the latter, nor should things be so tightly coupled that we'd need to do that anyway.

 -- Justin


On 5/7/2016 10:19 AM, Phil Hunt (IDM) wrote:
Mike

A number of people have indicated they need a transport. The commonalities are 90-99% the same. It would seem wise to sort out what is truly contextual. 

I think things like feed definitions and filters are highly contextual in particular. 

Putting that aside i do not see much difference between RISC, logout, revocation, and SCIM other than event meaning.  

Why would we want multiple solutions here?

Your colleague Craig has a very different case, but the watermarking in his polling proposal serves to address all your concerns and can be used in push system as well. 

Phil

On May 5, 2016, at 22:00, Mike Jones <Michael.Jones@microso= ft.com> wrote:

Thanks guys, for writing the initial charter text.  Reading it= now, I am extremely worried by the scope creep evident in the proposal.

 

I strongly support a working group to define an ID Events data format.  I just as strongly believe that specific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being out of scope in the working group charter.  Attempting to specify a particular event delivery mechanism will take something that could be simple and quick to approve and bog it down in necessarily application-specific debates.<= /p>

 

Should event delivery be reliable?  That=E2=80=99s an application-specific decision.

Should events be idempotent?  That=E2=80=99s an application-sp= ecific decision.

Should events be unicast, multicast, or broadcast?  That=E2=80= =99s an application-specific decision.

Should events have categories with category-specific subscriptions?  That=E2=80=99s an application-specific d= ecision.

Should only one party at a time be able to register for delivery of events or should multiple parties be able to request delivery?  That=E2=80=99s an application-specif= ic decision.

I could continue with this list, but I think you all get the point=E2=80=A6

 

If we start debating application-specific event delivery mechanisms, we=E2=80=99ll please almost no one, since nearly= all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as being out of scope.

 

If we define only a data format, we can quickly produce a very useful specification.  If we don=E2=80=99t, we=E2=80= =99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80= =93 an exercise of picking favorites and limiting applicability of the specification.  That way is a slow, painful descent int= o standards quicksand =E2=80=93 something we must avoid. = Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  Sincerely,

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

I don't see anything about access control for publishing events and subscribing to them. = I also think the spec should allow filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) <moransar@cisco.com&= gt; wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put together the attached as a straw man charter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if you think its necessary.=

 

 

Cheers,<= /span>

Morteza<= /span>


= _______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/l= istinfo/id-event

 

_______________________________________________ Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-e=
vent@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

=20
____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-D508E1FE-7773-4DAB-8DC8-E2BC9A1F71FA-- From nobody Sat May 7 10:23:15 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8591512B019 for ; Sat, 7 May 2016 10:23:13 -0700 (PDT) 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 1m16EXZANq_Z for ; Sat, 7 May 2016 10:23:11 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 44B2412B020 for ; Sat, 7 May 2016 10:23:11 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id v145so171014142oie.0 for ; Sat, 07 May 2016 10:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fHtfbnTywYX8mwOhhUO29VEOjyMmQC1sCVVF6Cv1C3c=; b=JlaJIBt38jDxUP1Z5Cf+HeLsy3jNZYzhgCvckrO8C7nVWJ/9BHiaMwBme1E6Rpw9P5 TLVz0ZqKxvzGa7T5BU9BKclRWltSocuyvj9wUmY07yDrUPSrfEkfolj/jzdqhgO8s/yz 0tN1WXxLYTH7+onTTx7/cCf2bQXkqRsgiYiQWIKgBSLYPFAE5NgBrQVGFDHaywPwq8Xu eJmPDxrkTxCYSvntPFk9cQuAdT+hEZN/BCf0SD9SRrJ5AkzeLf4ZVBYy1/+qFN9rG4jv QEzcOyfc84Nw93utQJkrF9VPEw2L0pFE08ciKKM05jtDTRoQnPx3km0LzsOe0hgOTCu1 jpvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fHtfbnTywYX8mwOhhUO29VEOjyMmQC1sCVVF6Cv1C3c=; b=N92vWf5fwBjKVGxlgSkozp6PK8nH9EoIEim1eJzO/dHdHFj02huY05e57eL+P+tXel 69QfsPJo0CL+rcwqNHixxhGGZtcJ0uAJVD1/gOVXSTpr/nMEQznJb7MGS0Rm7QyecdsB DL9SHt0SK7z9GXL8d5y/5mjrO1yox0KiEURE2yTyA0SbpF455Zr7Kq9kASpx2WdcEAcY EZgTURaxKDgJpuJomy+5isAMYd5YUKrg1To41XIrNjGOpGJw3r4s+ofBu89VecOdBORT 66Hk5mODK2h/hRckjIRDk3xpoVcJtib5v/HLlj8afeX4UuUyeY3uHOho9kFmI59UllF2 p0/Q== X-Gm-Message-State: AOPr4FWJFLKtsGSnxulnkv9aKNfZYpiYlDn4XNjw7vPHH8OeFX8ii4J/OnbCrup8XwKCeCVIWkvBZ8h0Sdi24g== MIME-Version: 1.0 X-Received: by 10.157.45.198 with SMTP id g64mr13194761otb.132.1462641790641; Sat, 07 May 2016 10:23:10 -0700 (PDT) Received: by 10.157.6.199 with HTTP; Sat, 7 May 2016 10:23:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 May 2016 10:23:10 -0700 Message-ID: From: Alan Karp To: Mike Jones Content-Type: multipart/alternative; boundary=94eb2c11507a5d7116053243d48c Archived-At: Cc: "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 17:23:13 -0000 --94eb2c11507a5d7116053243d48c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As one who proposed doing more, I believe that your position is valid. My only question is whether or not that will be enough for interoperability. -------------- Alan Karp On Thu, May 5, 2016 at 10:00 PM, Mike Jones wrote: > Thanks guys, for writing the initial charter text. Reading it now, I am > extremely worried by the scope creep evident in the proposal. > > > > I strongly support a working group to define an ID Events data format. I > just as strongly believe that specific event delivery mechanisms will > necessarily be application-specific and therefore MUST be explicitly be > stated as being out of scope in the working group charter. Attempting to > specify a particular event delivery mechanism will take something that > could be simple and quick to approve and bog it down in necessarily > application-specific debates. > > > > Should event delivery be reliable? That=E2=80=99s an application-specifi= c > decision. > > Should events be idempotent? That=E2=80=99s an application-specific deci= sion. > > Should events be unicast, multicast, or broadcast? That=E2=80=99s an > application-specific decision. > > Should events have categories with category-specific subscriptions? > That=E2=80=99s an application-specific decision. > > Should only one party at a time be able to register for delivery of event= s > or should multiple parties be able to request delivery? That=E2=80=99s a= n > application-specific decision. > > I could continue with this list, but I think you all get the point=E2=80= =A6 > > > > If we start debating application-specific event delivery mechanisms, we= =E2=80=99ll > please almost no one, since nearly all applications have different event > delivery requirements. We MUST explicitly rule all delivery mechanisms a= s > being out of scope. > > > > If we define only a data format, we can quickly produce a very useful > specification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in the= mud of debating > which applications we=E2=80=99re catering to and which we aren=E2=80=99t = =E2=80=93 an exercise of > picking favorites and limiting applicability of the specification. That > way is a slow, painful descent into standards quicksand =E2=80=93 somethi= ng we must > avoid. Having a standard ID events representation is far too important t= o > tie to a particular limited event delivery mechanism. > > > > Sincerely, > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Alan > Karp > *Sent:* Thursday, May 5, 2016 9:43 PM > *To:* Morteza Ansari (moransar) > *Cc:* id-event@ietf.org > *Subject:* Re: [Id-event] Straw man text for proposed charter > > > > I don't see anything about access control for publishing events and > subscribing to them. I also think the spec should allow filters on > subscriptions. > > > > -------------- > Alan Karp > > > > On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) < > moransar@cisco.com> wrote: > > Hi folks, > > > > At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put > together the attached as a straw man charter proposal to start the > discussion. Please send your comments and suggestions for any changes or > propose a new one if you think its necessary. > > > > > > Cheers, > > Morteza > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --94eb2c11507a5d7116053243d48c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As one who proposed doing= more, I believe that your position is valid.=C2=A0 My only question is whe= ther or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Thanks guys, for writing the initial = charter text.=C2=A0 Reading it now, I am extremely worried by the scope cre= ep evident in the proposal.

=C2=A0

I strongly support a working group to= define an ID Events data format.=C2=A0 I just as strongly believe that spe= cific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being o= ut of scope in the working group charter.=C2=A0 Attempting to specify a par= ticular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific debates.

=C2=A0

Should event delivery be reliable?=C2= =A0 That=E2=80=99s an application-specific decision.

Should events be idempotent?=C2=A0 Th= at=E2=80=99s an application-specific decision.

Should events be unicast, multicast, = or broadcast?=C2=A0 That=E2=80=99s an application-specific decision.=

Should events have categories with ca= tegory-specific subscriptions?=C2=A0 That=E2=80=99s an application-specific= decision.

Should only one party at a time be ab= le to register for delivery of events or should multiple parties be able to= request delivery?=C2=A0 That=E2=80=99s an application-specific decision.

I could continue with this list, but = I think you all get the point=E2=80=A6

=C2=A0

If we start debating application-spec= ific event delivery mechanisms, we=E2=80=99ll please almost no one, since n= early all applications have different event delivery requirements.=C2=A0 We MUST explicitly rule all delivery mechanisms as being out of scope.<= /u>

=C2=A0

If we define only a data format, we c= an quickly produce a very useful specification.=C2=A0 If we don=E2=80=99t, = we=E2=80=99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80=93 an exercis= e of picking favorites and limiting applicability of the specification.=C2= =A0 That way is a slow, painful descent into standards quicksand =E2=80=93 = something we must avoid.=C2=A0 Having a standard ID events representation i= s far too important to tie to a particular limited event delivery mechanism.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sincerely,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org= ] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@= ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

=C2=A0

I don't see anything about access control for pu= blishing events and subscribing to them.=C2=A0 I also think the spec should= allow filters on subscriptions.



--------------
Alan Karp

=C2=A0

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mor= ansar) <moransar= @cisco.com> wrote:

Hi folks,

=C2=A0

At IIW a few of us (Phil, William, Adam= , and I) huddled for a bit and put together the attached as a straw man cha= rter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if= you think its necessary.

=C2=A0

=C2=A0

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

=C2=A0


--94eb2c11507a5d7116053243d48c-- From nobody Sat May 7 11:23:14 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3C12D0B2 for ; Sat, 7 May 2016 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ve7jtb-com.20150623.gappssmtp.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 6kIu9TNUCdEK for ; Sat, 7 May 2016 11:23:09 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 772EA12B032 for ; Sat, 7 May 2016 11:23:09 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n62so5194888qkc.2 for ; Sat, 07 May 2016 11:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ZBMYjhM3FeTZp5bwFbTJilfZ12mR6aZ+mG50kyU77TI=; b=kZOf0/NNQ4phr64ilOH4amVzGOJjH9EOcgsNaCCWqoC2XxaporKy8Ve/t6W8UJ31X5 SSWeGyWJjNLXK6gftbasFRqcQz3bY8CtFCnj0/qFpBJZRE1Hz+lRZjUE1SgLbNukj+/9 bjsDb91DhbyRdnLH3IjgkLgbo0WqRg1qMeqaMTO2IsIbmaGze88itld+PHaPWvPf3RZ7 vc2y88IJJTWtq6hctXA90dn0Jh7oiXUtQYJR7SOmy2807ZSt4N3qlA+GIZ/M2QZYydNe KxyhV/SjoXMUz9yO5CRvL3M7w0Vuj+4rw2brE9kNIX2TYzGY4YB/x6Gc3HXPAaKnNP7p hrww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZBMYjhM3FeTZp5bwFbTJilfZ12mR6aZ+mG50kyU77TI=; b=j+tA5KWjb2dY/f27kE3GSbocGpQ2E0pFW1IckICyIOSpMg7Qxe8LhCkhhsn/lHdRBH ypixtbR2FxX8YXPJtD7uzC4VJ5gRk1o4fMqt7WL9ZzzF48OVpHtVF2vqT9d/LuRTaD9f N/YgVQF8Ud4wjbZXRAmL+atgO/ljAHfZm5KFSEWXF+EvwzxLpxevAuNPMD304/qvlI5f Kh4jMg/DJ+j8LP1gaFwyoGodLyFHruNi9FfhaWaFfNuu49ssr6QbzzGGeSnt8jWvX4dq h4yEnPePIt+rcWnzYFaX+s6YcIgqSYaSI6JIXPzf+OzX0IyktqRyDtM6RvmTH1M/ASvt 9rEw== X-Gm-Message-State: AOPr4FX9ociB9dzBC8R4/Dd/IJevS8FULviKcUMM4bJj3ma2isy0F1hQibCCwb0z16lhgA== X-Received: by 10.55.207.193 with SMTP id v62mr2567397qkl.104.1462645388403; Sat, 07 May 2016 11:23:08 -0700 (PDT) Received: from [192.168.1.32] ([191.115.45.214]) by smtp.gmail.com with ESMTPSA id s184sm8170735qhc.28.2016.05.07.11.22.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2016 11:23:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_54C53715-D2FA-40A1-9E64-728547B8058B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Sat, 7 May 2016 15:22:41 -0300 Message-Id: <06F20E0A-A71E-4EA7-9A2A-FE0756CC3007@ve7jtb.com> References: To: Michael Jones X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 18:23:12 -0000 --Apple-Mail=_54C53715-D2FA-40A1-9E64-728547B8058B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On May 6, 2016, at 2:00 AM, Mike Jones = wrote: >=20 > Thanks guys, for writing the initial charter text. Reading it now, I = am extremely worried by the scope creep evident in the proposal. > =20 > I strongly support a working group to define an ID Events data format. = I just as strongly believe that specific event delivery mechanisms will = necessarily be application-specific and therefore MUST be explicitly be = stated as being out of scope in the working group charter. Attempting = to specify a particular event delivery mechanism will take something = that could be simple and quick to approve and bog it down in necessarily = application-specific debates. > =20 > Should event delivery be reliable? That=E2=80=99s an = application-specific decision. > Should events be idempotent? That=E2=80=99s an application-specific = decision. > Should events be unicast, multicast, or broadcast? That=E2=80=99s an = application-specific decision. > Should events have categories with category-specific subscriptions? = That=E2=80=99s an application-specific decision. > Should only one party at a time be able to register for delivery of = events or should multiple parties be able to request delivery? That=E2=80= =99s an application-specific decision. > I could continue with this list, but I think you all get the point=E2=80= =A6 > =20 > If we start debating application-specific event delivery mechanisms, = we=E2=80=99ll please almost no one, since nearly all applications have = different event delivery requirements. We MUST explicitly rule all = delivery mechanisms as being out of scope. > =20 > If we define only a data format, we can quickly produce a very useful = specification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in = the mud of debating which applications we=E2=80=99re catering to and = which we aren=E2=80=99t =E2=80=93 an exercise of picking favorites and = limiting applicability of the specification. That way is a slow, = painful descent into standards quicksand =E2=80=93 something we must = avoid. Having a standard ID events representation is far too important = to tie to a particular limited event delivery mechanism. > =20 > Sincerely, > -- Mike > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan = Karp > Sent: Thursday, May 5, 2016 9:43 PM > To: Morteza Ansari (moransar) > Cc: id-event@ietf.org > Subject: Re: [Id-event] Straw man text for proposed charter > =20 > I don't see anything about access control for publishing events and = subscribing to them. I also think the spec should allow filters on = subscriptions. >=20 >=20 > -------------- > Alan Karp > =20 > On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) = > wrote: > Hi folks, > =20 > At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and = put together the attached as a straw man charter proposal to start the = discussion. Please send your comments and suggestions for any changes or = propose a new one if you think its necessary. > =20 > =20 > Cheers, > Morteza >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_54C53715-D2FA-40A1-9E64-728547B8058B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On May 6, 2016, at 2:00 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Thanks guys, for writing the initial charter = text.  Reading it now, I am extremely worried by the scope creep = evident in the proposal.
 
I strongly support a = working group to define an ID Events data format.  I just as = strongly believe that specific event delivery mechanisms will = necessarily be application-specific and therefore MUST be explicitly be = stated as being out of scope in the working group charter.  = Attempting to specify a particular event delivery mechanism will take = something that could be simple and quick to approve and bog it down in = necessarily application-specific debates.
 
Should event delivery be reliable?  That=E2=80=99s an = application-specific decision.
Should events be idempotent?  That=E2=80=99s an = application-specific decision.
Should events be unicast, multicast, or broadcast?  = That=E2=80=99s an application-specific decision.
Should events have categories with = category-specific subscriptions?  That=E2=80=99s an = application-specific decision.
Should only one party at a time be able to register for = delivery of events or should multiple parties be able to request = delivery?  That=E2=80=99s an application-specific decision.
I could continue with this list, but I think = you all get the point=E2=80=A6
 
If we start debating = application-specific event delivery mechanisms, we=E2=80=99ll please = almost no one, since nearly all applications have different event = delivery requirements.  We MUST explicitly rule all delivery = mechanisms as being out of scope.
 
If we define only a data = format, we can quickly produce a very useful specification.  If we = don=E2=80=99t, we=E2=80=99ll get bogged down in the mud of debating = which applications we=E2=80=99re catering to and which we aren=E2=80=99t = =E2=80=93 an exercise of picking favorites and limiting applicability of = the specification.  That way is a slow, painful descent into = standards quicksand =E2=80=93 something we must avoid.  Having a = standard ID events representation is far too important to tie to a = particular limited event delivery mechanism.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Sincerely,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: Id-event = [mailto:id-event-bounces@ietf.org] On Behalf = Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 = PM
To: Morteza Ansari (moransar) = <moransar@cisco.com>
Cc: id-event@ietf.org
Subject: Re: [Id-event] Straw man = text for proposed charter
 
I don't see anything = about access control for publishing events and subscribing to = them.  I also think the spec should allow filters on = subscriptions.


--------------
Alan Karp
 
On Thu, May 5, 2016 = at 11:18 AM, Morteza Ansari (moransar) <moransar@cisco.com>= wrote:
Hi folks,
 
At IIW a few of us (Phil, = William, Adam, and I) huddled for a bit and put together the attached as = a straw man charter proposal to start the discussion. Please send your = comments and suggestions for any changes or propose a new one if you = think its necessary.
 
 
Cheers,
Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=

= --Apple-Mail=_54C53715-D2FA-40A1-9E64-728547B8058B-- From nobody Sat May 7 13:04:37 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D93812B02E for ; Sat, 7 May 2016 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 M6qfCnef8Ypp for ; Sat, 7 May 2016 13:04:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1347512B05D for ; Sat, 7 May 2016 13:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FnmM9ZXiZ2Mh6cRkSFe20w+1UekEr1SnStX62ghoTQY=; b=oWBqq3MHksq+1Fss0fYfbvwlAglPhHyKdUb0OqifWktz0tbQ9mYEvYtCGyERiylvt9jcz55FcJBSJ3LsllvIHCQK+u34oz4eM79ls0xnlQGfNXP8q9CnXBmHxwAnFTcVtACe7cY/bR0WpdMwm/jv0/XdPbnUsEYw9AeDIqlHFWs= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sat, 7 May 2016 20:04:30 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0485.015; Sat, 7 May 2016 20:04:30 +0000 From: Mike Jones To: Alan Karp Thread-Topic: [Id-event] Straw man text for proposed charter Thread-Index: AQHRpvqTgBAoFeyLHUGd148PgQ6OuZ+rVXQAgAAAWICAAmZ/AIAALRQw Date: Sat, 7 May 2016 20:04:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [166.176.187.13] x-ms-office365-filtering-correlation-id: bb9ef06d-5fc0-444b-b460-08d376b2cd00 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 5:BGM7gw/YGEtQUQyYNNP1deMof6Yzv7JjT/ECwmeJ/1MK7WaxY4BI75La7tK69foSDsY+NVGj6PPHF9zHYyfL3mi+ekyOkrlSyBXSuRX6yHLQxxqLy8OC6OFXv/N33KLRGpc3D4ZdUj43FJNgPb1mGQ==; 24:AbNUeA7TQ7l4KFZzRSznVGrbbiUp49i9NKutBxRaqZodyq4gcPWxBpzHpZh1vdzXIrUBN8h8DNr4aWneK0S3s+LDeDudfLDow3Oj3/L4EbM=; 7:dyRkrQX+NevAhoabZjXneQEXYy5xRy1oIR15sdELEMGRxWnYVcbRZ3VQke4ZGpPc+gy91PblIn62aj2hpz/ZDOR6sRn94rvsdXrHdMHhn0v5I53Eszur43fz9/K4L7WO+EETUMGJIC0TcVnNdpxcMTV3S6d1zpcnSLK1BfkUu+2Mk4nJTr8bdMLUnmhavKiwaDz1ydx4roKrxv52c2ob1w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(9170700001)(1220700001)(2900100001)(92566002)(10090500001)(99286002)(2950100001)(106116001)(81166005)(3900700001)(110136002)(76576001)(86362001)(15975445007)(77096005)(586003)(93886004)(3280700002)(74316001)(2906002)(87936001)(54356999)(50986999)(76176999)(19617315012)(10400500002)(561944003)(5890100001)(10290500002)(3660700001)(6116002)(102836003)(3846002)(11100500001)(66066001)(16236675004)(33656002)(4326007)(8990500004)(5005710100001)(5008740100001)(5004730100002)(19625215002)(19580405001)(19580395003)(189998001)(1411001)(9686002)(8936002)(5002640100001)(5003600100002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164585318932F90C48CDDD5CF57E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2016 20:04:30.1566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 20:04:35 -0000 --_000_SN1PR0301MB164585318932F90C48CDDD5CF57E0SN1PR0301MB1645_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Alan, Interoperability will be on a per-application basis, just like JWT interope= rability. The claims needed in an identity event are application-specific,= just like claims are for JWTs. This is the same standards posture and JWT= s are a huge success =96 including for interoperability, even if I do say s= o myself. Best wishes, -- Mike From: Alan Karp Sent: Saturday, May 7, 2016 10:23 AM To: Mike Jones Cc: Morteza Ansari (moransar); id-event@ietf.org= Subject: Re: [Id-event] Straw man text for proposed charter As one who proposed doing more, I believe that your position is valid. My = only question is whether or not that will be enough for interoperability. -------------- Alan Karp On Thu, May 5, 2016 at 10:00 PM, Mike Jones > wrote: Thanks guys, for writing the initial charter text. Reading it now, I am ex= tremely worried by the scope creep evident in the proposal. I strongly support a working group to define an ID Events data format. I j= ust as strongly believe that specific event delivery mechanisms will necess= arily be application-specific and therefore MUST be explicitly be stated as= being out of scope in the working group charter. Attempting to specify a = particular event delivery mechanism will take something that could be simpl= e and quick to approve and bog it down in necessarily application-specific = debates. Should event delivery be reliable? That=92s an application-specific decisi= on. Should events be idempotent? That=92s an application-specific decision. Should events be unicast, multicast, or broadcast? That=92s an application= -specific decision. Should events have categories with category-specific subscriptions? That= =92s an application-specific decision. Should only one party at a time be able to register for delivery of events = or should multiple parties be able to request delivery? That=92s an applic= ation-specific decision. I could continue with this list, but I think you all get the point=85 If we start debating application-specific event delivery mechanisms, we=92l= l please almost no one, since nearly all applications have different event = delivery requirements. We MUST explicitly rule all delivery mechanisms as = being out of scope. If we define only a data format, we can quickly produce a very useful speci= fication. If we don=92t, we=92ll get bogged down in the mud of debating wh= ich applications we=92re catering to and which we aren=92t =96 an exercise = of picking favorites and limiting applicability of the specification. That= way is a slow, painful descent into standards quicksand =96 something we m= ust avoid. Having a standard ID events representation is far too important= to tie to a particular limited event delivery mechanism. Sincerely, -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp Sent: Thursday, May 5, 2016 9:43 PM To: Morteza Ansari (moransar) > Cc: id-event@ietf.org Subject: Re: [Id-event] Straw man text for proposed charter I don't see anything about access control for publishing events and subscri= bing to them. I also think the spec should allow filters on subscriptions. -------------- Alan Karp On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) > wrote: Hi folks, At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put t= ogether the attached as a straw man charter proposal to start the discussio= n. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. Cheers, Morteza _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_SN1PR0301MB164585318932F90C48CDDD5CF57E0SN1PR0301MB1645_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks Alan,

 

Interoperability will = be on a per-application basis, just like JWT interoperability.  The cl= aims needed in an identity event are application-specific, just like claims= are for JWTs.  This is the same standards posture and JWTs are a huge success =96 including for interoperability, ev= en if I do say so myself.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Best wishes,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

 

 

 

From: Alan Karp
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones Cc: Morteza Ansari (moransar)<= /a>; id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

As one who proposed doing= more, I believe that your position is valid.  My only question is whe= ther or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks guys, for writing the initia= l charter text.  Reading it now, I am extremely worried by the scope c= reep evident in the proposal.

 

I strongly support a working group = to define an ID Events data format.  I just as strongly believe that s= pecific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as bein= g out of scope in the working group charter.  Attempting to specify a = particular event delivery mechanism will take something that could be simpl= e and quick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable?&= nbsp; That=92s an application-specific decision.

Should events be idempotent?  = That=92s an application-specific decision.

Should events be unicast, multicast= , or broadcast?  That=92s an application-specific decision.<= /u>

Should events have categories with = category-specific subscriptions?  That=92s an application-specific dec= ision.

Should only one party at a time be = able to register for delivery of events or should multiple parties be able = to request delivery?  That=92s an application-specific decision.

I could continue with this list, bu= t I think you all get the point=85

 

If we start debating application-sp= ecific event delivery mechanisms, we=92ll please almost no one, since nearl= y all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as bei= ng out of scope.

 

If we define only a data format, we= can quickly produce a very useful specification.  If we don=92t, we= =92ll get bogged down in the mud of debating which applications we=92re catering to and which we aren=92t =96 an exercise of picking favor= ites and limiting applicability of the specification.  That way is a s= low, painful descent into standards quicksand =96 something we must avoid.&= nbsp; Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.=

 

      = ;            &n= bsp;            = ;            &n= bsp;            = ;  Sincerely,

      = ;            &n= bsp;            = ;            &n= bsp;            = ;  -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.o= rg] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@= ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

I don't see anything about access control for publis= hing events and subscribing to them.  I also think the spec should all= ow filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mor= ansar) <moransar= @cisco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Ad= am, and I) huddled for a bit and put together the attached as a straw man c= harter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if= you think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 


--_000_SN1PR0301MB164585318932F90C48CDDD5CF57E0SN1PR0301MB1645_-- From nobody Sat May 7 13:24:45 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A335412D0B9 for ; Sat, 7 May 2016 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 2EWzfrFYl2uj for ; Sat, 7 May 2016 13:24:42 -0700 (PDT) Received: from nm1-vm4.bullet.mail.ne1.yahoo.com (nm1-vm4.bullet.mail.ne1.yahoo.com [98.138.91.161]) (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 DABA91200A0 for ; Sat, 7 May 2016 13:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462652681; bh=eQLczCbrkRDJORgrbCh44KXBkuX0JxnxzNzUQHeKPJU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=XoWfj+pbh9eKZSzs2g0WJTxsNWuIAlApzC3RQGpVDV3EPs9azdiReHfeHprs8drirjY5kjo6kv4UUAlOQeEHko8U1qcMG7Nz/SUHRyt89gWL+PXwRihZIYwRPRN0EuWmnuQ0Azq7sAOJlsikltpayPmtvM2+ryEmLCiGdYs9ZTbpQjq4CwLPpHfXeaUgT9B90r4P06Sk8rALp33H0+IeU0ZoVd78L32iO0ltks4LZBGvxB6LbRWAYUuUkNqecqOO1ijtD0tHtMBMwMRwGBu3jcALzRTzN/LhzI2uI1olyp8bJQuY//JIvZuo008l6/LPDrku9fm9hsoA75Q+Nr7Dmw== Received: from [98.138.100.117] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 07 May 2016 20:24:41 -0000 Received: from [98.138.226.124] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 07 May 2016 20:24:41 -0000 Received: from [127.0.0.1] by smtp203.mail.ne1.yahoo.com with NNFMP; 07 May 2016 20:24:41 -0000 X-Yahoo-Newman-Id: 65546.81507.bm@smtp203.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7.S26AoVM1n8Z_bjziVzpCzLTjkw...7nQ.eE7EKnm_DzCi jHsPuP3ZbuDH3CCYlbC7nEaPj9f9hSZ11fyKiyTeodnRGROtRefHO_oeitZD 8t2KpbazyGflDYYqqb7xwhVmWTdttXtBtHj1lZt52mcDiMLv4BJe_clpGy2I T5QbY8mieN.fbexhu6B7wq6wbU71L.pTbqKtHAihgfYW3Mxx7jC3Ooe0tcLG xVc2.A_tlLkuK7.U6oQQ0T96cTb.nTYwakeCjT7qlJBEOUO6zt1vkqxpyD48 mNh6Yc1HPMfjpfXIOKgg93PaOpaVTiIp8AcZxvENo67eDyHYHIEvW0pHMMk7 2OfuSUV_huqndYOS0RjvIucMJEJ4Vix.AtLm0ZC6J3sgbz7IlP2tPLWtuDd2 AoPNZyH_mK2EBAjA1xO0tB5eUtQBpT8HdnI.SGlkDkzxYL5BuMy0vxGrPGha 8iAKBb5yQN5rxq6P7O5skCiwkX8U9JfmiRemLi4dQEVOX7ALCWs.n95GqsVe HHNp2jlfVwmgHbGnulCMTWdRp05WBmsJFfQc- X-Yahoo-SMTP: uzUUtISswBDTAogvmhs0E0cQmR0CbT4a8Q-- Content-Type: multipart/alternative; boundary=Apple-Mail-AF825D37-8A22-4302-AA55-ED51F99BC5B4 Mime-Version: 1.0 (1.0) From: Vivek Biswas X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sat, 7 May 2016 13:24:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Jones Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 20:24:44 -0000 --Apple-Mail-AF825D37-8A22-4302-AA55-ED51F99BC5B4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, I agree that the claims can be application specific, however there is a= possibility to define claims which are domain specific. Thereby claims gene= rated in one application could be understood by another application within t= he same domain. With microservices based architecture getting lot of attention, if two diffe= rent micro services defining different claims for the same claim, it can cre= ate confusion. Nevertheless this well defined claims for a particular domain can be an exte= nsion to the core specification. -Vivek Biswas Consulting Member, Oracle Sent from my iPhone > On May 7, 2016, at 1:04 PM, Mike Jones wrote= : >=20 > Thanks Alan, > =20 > Interoperability will be on a per-application basis, just like JWT interop= erability. The claims needed in an identity event are application-specific,= just like claims are for JWTs. This is the same standards posture and JWTs= are a huge success =E2=80=93 including for interoperability, even if I do s= ay so myself. > =20 > Best wishes, > -- Mike > =20 > =20 > =20 > =20 > From: Alan Karp > Sent: Saturday, May 7, 2016 10:23 AM > To: Mike Jones > Cc: Morteza Ansari (moransar); id-event@ietf.org > Subject: Re: [Id-event] Straw man text for proposed charter > =20 > As one who proposed doing more, I believe that your position is valid. My= only question is whether or not that will be enough for interoperability. >=20 >=20 > -------------- > Alan Karp >=20 >> On Thu, May 5, 2016 at 10:00 PM, Mike Jones = wrote: >> Thanks guys, for writing the initial charter text. Reading it now, I am e= xtremely worried by the scope creep evident in the proposal. >> =20 >> I strongly support a working group to define an ID Events data format. I= just as strongly believe that specific event delivery mechanisms will neces= sarily be application-specific and therefore MUST be explicitly be stated as= being out of scope in the working group charter. Attempting to specify a p= articular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific deba= tes. >> =20 >> Should event delivery be reliable? That=E2=80=99s an application-specifi= c decision. >> Should events be idempotent? That=E2=80=99s an application-specific deci= sion. >> Should events be unicast, multicast, or broadcast? That=E2=80=99s an app= lication-specific decision. >> Should events have categories with category-specific subscriptions? That= =E2=80=99s an application-specific decision. >> Should only one party at a time be able to register for delivery of event= s or should multiple parties be able to request delivery? That=E2=80=99s an= application-specific decision. >> I could continue with this list, but I think you all get the point=E2=80=A6= >> =20 >> If we start debating application-specific event delivery mechanisms, we=E2= =80=99ll please almost no one, since nearly all applications have different e= vent delivery requirements. We MUST explicitly rule all delivery mechanisms= as being out of scope. >> =20 >> If we define only a data format, we can quickly produce a very useful spe= cification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in the mud o= f debating which applications we=E2=80=99re catering to and which we aren=E2= =80=99t =E2=80=93 an exercise of picking favorites and limiting applicabilit= y of the specification. That way is a slow, painful descent into standards q= uicksand =E2=80=93 something we must avoid. Having a standard ID events rep= resentation is far too important to tie to a particular limited event delive= ry mechanism. >> =20 >> Sincerely, >> -- Mike >> =20 >> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp >> Sent: Thursday, May 5, 2016 9:43 PM >> To: Morteza Ansari (moransar) >> Cc: id-event@ietf.org >> Subject: Re: [Id-event] Straw man text for proposed charter >> =20 >> I don't see anything about access control for publishing events and subsc= ribing to them. I also think the spec should allow filters on subscriptions= . >>=20 >>=20 >> -------------- >> Alan Karp >> =20 >> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) wrote: >> Hi folks, >> =20 >> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put= together the attached as a straw man charter proposal to start the discussi= on. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. >> =20 >> =20 >> Cheers, >> Morteza >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-AF825D37-8A22-4302-AA55-ED51F99BC5B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, I agree that the claims can be ap= plication specific, however there is a possibility to define claims which ar= e domain specific. Thereby claims generated in one application could be unde= rstood by another  application within the same domain.

With microservi= ces based architecture getting lot of attention, if two different micro serv= ices defining different claims for the same claim, it can create confusion.<= /div>

Nevertheless this well defined claims for a particular domain can be an ext= ension to the core specification.

-Vivek Biswas
  Consulting Member, Oracle

Sent from my iPhone

On May 7, 2016, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks Alan,

 

Interoperability will b= e on a per-application basis, just like JWT interoperability.  The clai= ms needed in an identity event are application-specific, just like claims ar= e for JWTs.  This is the same standards posture and JWTs are a huge success =E2=80=93 including for interoperabilit= y, even if I do say so myself.

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   Best wishes,

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   -- Mike

 

 

 

 

From: Alan Karp
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones
= Cc: Morteza Ansari (moransar); id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

As one who proposed doing m= ore, I believe that your position is valid.  My only question is whethe= r or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <Michael= .Jones@microsoft.com> wrote:

Thanks guys, for writing the initial c= harter text.  Reading it now, I am extremely worried by the scope creep= evident in the proposal.

 

I strongly support a working group to= define an ID Events data format.  I just as strongly believe that spec= ific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being= out of scope in the working group charter.  Attempting to specify a pa= rticular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable?&nb= sp; That=E2=80=99s an application-specific decision.

Should events be idempotent?  Th= at=E2=80=99s an application-specific decision.

Should events be unicast, multicast, o= r broadcast?  That=E2=80=99s an application-specific decision.

Should events have categories with ca= tegory-specific subscriptions?  That=E2=80=99s an application-specific d= ecision.

Should only one party at a time be ab= le to register for delivery of events or should multiple parties be able to r= equest delivery?  That=E2=80=99s an application-specific decision.

I could continue with this list, but I= think you all get the point=E2=80=A6

 

If we start debating application-spec= ific event delivery mechanisms, we=E2=80=99ll please almost no one, since ne= arly all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as bein= g out of scope.

 

If we define only a data format, we c= an quickly produce a very useful specification.  If we don=E2=80=99t, w= e=E2=80=99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80=93 an exercise= of picking favorites and limiting applicability of the specification. = That way is a slow, painful descent into standards quicksand =E2=80=93 some= thing we must avoid.  Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.<= u>

 

      &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; Sincerely,

      &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@i= etf.org
Subject: Re: [Id-event] Straw man text for proposed charter=

 

I don't see anything about access control for publish= ing events and subscribing to them.  I also think the spec should allow= filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mora= nsar) <moransar@c= isco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Adam= , and I) huddled for a bit and put together the attached as a straw man char= ter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if y= ou think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/mailman/listinfo/id-event

 


____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-AF825D37-8A22-4302-AA55-ED51F99BC5B4-- From nobody Sat May 7 13:31:58 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B912B04C for ; Sat, 7 May 2016 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 iGxAg0Nk4r8d for ; Sat, 7 May 2016 13:31:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B751B12B027 for ; Sat, 7 May 2016 13:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nfdHzHNFQcVHIXw/cPxyA7QF3bKm/pVufIWvXgKZfV8=; b=Ht+1ZTWdujpjCWxkJZzqnwqEsSrNUdbmL6oL0scp6Le1cE0d799/NXyG6w2ptV9hJAJzKR2JQGTRMzzjNbIvsQfwBhT/shr0TMwAZNR61h5xKL+EyekhrZ0tEfT+ZQXYfAtZwxu4mhWOjDxx4/wawtGF4aJ+fc+Vr6yf8nu7kO0= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sat, 7 May 2016 20:31:51 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0485.015; Sat, 7 May 2016 20:31:51 +0000 From: Mike Jones To: Vivek Biswas Thread-Topic: [Id-event] Straw man text for proposed charter Thread-Index: AQHRpvqTgBAoFeyLHUGd148PgQ6OuZ+rVXQAgAAAWICAAmZ/AIAALRQwgAAFoYCAAAIDhw== Date: Sat, 7 May 2016 20:31:50 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [166.176.187.13] x-ms-office365-filtering-correlation-id: bc441a98-10ff-4d86-9f09-08d376b69ef0 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 5:hPdVkGBpUBPLgQMwuJmpwMIXRORIXpn79pz74CtBRMVHCAncqxsl+aM1Ju3Crvim3/9JW/eGmhiYqhmyEGyAN6SB8GQc8BzT2iK9i97JchliTqcEO714DViE8ponbAr477aU4P6HQFdigU/X2F6I5Q==; 24:h+otdIXT+oYLO3K2OjgxoQKNcYFk96u0bQ5l2P0er9M2zVCN+sHbjvg2oQ1D/zYM+6759fnnyJCSStK/BoxV8Lmztifv0yMRkeeLseN7sHY=; 7:Zl0StUiTNFzH5LQvam0TFchLZx/MHxtKkDpg0ylNWgI/nlkmqWnZmUIlUEATPQ0gWv6b3+TCsUaBiJCGfp6psuOC1dcrK7ysCXk5kWcEHtWl6Lm0lR/hQOxQUlBu4yWR3NRNtLkDilYx+OO/bZZ3jwJSA6evNvBrKHltWEUnHBB5TBahrUEmVqW8rzXMsANyz2Ld4Aye/Ih9t8EyN4lFvQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(9170700001)(15975445007)(92566002)(87936001)(86362001)(2906002)(19617315012)(16236675004)(5003600100002)(76576001)(77096005)(561944003)(2950100001)(189998001)(33656002)(3280700002)(3900700001)(66066001)(8936002)(3660700001)(110136002)(5002640100001)(2900100001)(5003630100001)(81166005)(19625215002)(3846002)(6116002)(102836003)(586003)(54356999)(76176999)(50986999)(5004730100002)(2521001)(1220700001)(11100500001)(10090500001)(10400500002)(19580405001)(5005710100001)(8990500004)(10290500002)(19580395003)(106116001)(74316001)(99286002)(93886004)(122556002)(5890100001)(4326007)(9686002)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645DD56619DFBEDB69D6A62F57E0SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2016 20:31:51.0035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: Alan Karp , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 20:31:57 -0000 --_000_SN1PR0301MB1645DD56619DFBEDB69D6A62F57E0SN1PR0301MB1645_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Indeed, that=92s why there=92s a claims registry =96 so common claims can b= e defined once and then reused. From: Vivek Biswas Sent: Saturday, May 7, 2016 1:24 PM To: Mike Jones Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org Subject: Re: [Id-event] Straw man text for proposed charter Yes, I agree that the claims can be application specific, however there is = a possibility to define claims which are domain specific. Thereby claims ge= nerated in one application could be understood by another application with= in the same domain. With microservices based architecture getting lot of attention, if two diff= erent micro services defining different claims for the same claim, it can c= reate confusion. Nevertheless this well defined claims for a particular domain can be an ext= ension to the core specification. -Vivek Biswas Consulting Member, Oracle Sent from my iPhone On May 7, 2016, at 1:04 PM, Mike Jones > wrote: Thanks Alan, Interoperability will be on a per-application basis, just like JWT interope= rability. The claims needed in an identity event are application-specific,= just like claims are for JWTs. This is the same standards posture and JWT= s are a huge success =96 including for interoperability, even if I do say s= o myself. Best wishes, -- Mike From: Alan Karp Sent: Saturday, May 7, 2016 10:23 AM To: Mike Jones Cc: Morteza Ansari (moransar); id-event@ietf.org= Subject: Re: [Id-event] Straw man text for proposed charter As one who proposed doing more, I believe that your position is valid. My = only question is whether or not that will be enough for interoperability. -------------- Alan Karp On Thu, May 5, 2016 at 10:00 PM, Mike Jones > wrote: Thanks guys, for writing the initial charter text. Reading it now, I am ex= tremely worried by the scope creep evident in the proposal. I strongly support a working group to define an ID Events data format. I j= ust as strongly believe that specific event delivery mechanisms will necess= arily be application-specific and therefore MUST be explicitly be stated as= being out of scope in the working group charter. Attempting to specify a = particular event delivery mechanism will take something that could be simpl= e and quick to approve and bog it down in necessarily application-specific = debates. Should event delivery be reliable? That=92s an application-specific decisi= on. Should events be idempotent? That=92s an application-specific decision. Should events be unicast, multicast, or broadcast? That=92s an application= -specific decision. Should events have categories with category-specific subscriptions? That= =92s an application-specific decision. Should only one party at a time be able to register for delivery of events = or should multiple parties be able to request delivery? That=92s an applic= ation-specific decision. I could continue with this list, but I think you all get the point=85 If we start debating application-specific event delivery mechanisms, we=92l= l please almost no one, since nearly all applications have different event = delivery requirements. We MUST explicitly rule all delivery mechanisms as = being out of scope. If we define only a data format, we can quickly produce a very useful speci= fication. If we don=92t, we=92ll get bogged down in the mud of debating wh= ich applications we=92re catering to and which we aren=92t =96 an exercise = of picking favorites and limiting applicability of the specification. That= way is a slow, painful descent into standards quicksand =96 something we m= ust avoid. Having a standard ID events representation is far too important= to tie to a particular limited event delivery mechanism. Sincerely, -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp Sent: Thursday, May 5, 2016 9:43 PM To: Morteza Ansari (moransar) > Cc: id-event@ietf.org Subject: Re: [Id-event] Straw man text for proposed charter I don't see anything about access control for publishing events and subscri= bing to them. I also think the spec should allow filters on subscriptions. -------------- Alan Karp On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) > wrote: Hi folks, At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and put t= ogether the attached as a straw man charter proposal to start the discussio= n. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. Cheers, Morteza _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_SN1PR0301MB1645DD56619DFBEDB69D6A62F57E0SN1PR0301MB1645_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Indeed, that=92s why there=92s a claims registry =96= so common claims can be defined once and then reused.

 

From: Vivek Biswas
Sent: Saturday, May 7, 2016 1:24 PM
To: Mike Jones Cc: Alan Karp; Morteza Ansari (moransar); id-even= t@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

Yes, I agree that the claims can be application specific, however ther= e is a possibility to define claims which are domain specific. Thereby clai= ms generated in one application could be understood by another  applic= ation within the same domain.

With microservices based architecture gettin= g lot of attention, if two different micro services defining different clai= ms for the same claim, it can create confusion.

Nevertheless this well defined claims for a = particular domain can be an extension to the core specification.

-Vivek Biswas
  Consulting Member, Oracle

Sent from my iPhone

On May 7, 2016, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks Alan,

 

Interoperability will = be on a per-application basis, just like JWT interoperability.  The cl= aims needed in an identity event are application-specific, just like claims= are for JWTs.  This is the same standards posture and JWTs are a huge success =96 including for interoperability, ev= en if I do say so myself.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Best wishes,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    -- Mike

 

 

 

 

From: Alan Karp
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones Cc: Morteza Ansari (moransar)<= /a>; id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

As one who proposed doing= more, I believe that your position is valid.  My only question is whe= ther or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks guys, for writing the initia= l charter text.  Reading it now, I am extremely worried by the scope c= reep evident in the proposal.

 

I strongly support a working group = to define an ID Events data format.  I just as strongly believe that s= pecific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as bein= g out of scope in the working group charter.  Attempting to specify a = particular event delivery mechanism will take something that could be simpl= e and quick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable?&= nbsp; That=92s an application-specific decision.

Should events be idempotent?  = That=92s an application-specific decision.

Should events be unicast, multicast= , or broadcast?  That=92s an application-specific decision.<= /u>

Should events have categories with = category-specific subscriptions?  That=92s an application-specific dec= ision.

Should only one party at a time be = able to register for delivery of events or should multiple parties be able = to request delivery?  That=92s an application-specific decision.

I could continue with this list, bu= t I think you all get the point=85

 

If we start debating application-sp= ecific event delivery mechanisms, we=92ll please almost no one, since nearl= y all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as bei= ng out of scope.

 

If we define only a data format, we= can quickly produce a very useful specification.  If we don=92t, we= =92ll get bogged down in the mud of debating which applications we=92re catering to and which we aren=92t =96 an exercise of picking favor= ites and limiting applicability of the specification.  That way is a s= low, painful descent into standards quicksand =96 something we must avoid.&= nbsp; Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.=

 

      = ;            &n= bsp;            = ;            &n= bsp;            = ;  Sincerely,

      = ;            &n= bsp;            = ;            &n= bsp;            = ;  -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.o= rg] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@= ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

I don't see anything about access control for publis= hing events and subscribing to them.  I also think the spec should all= ow filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mor= ansar) <moransar= @cisco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Ad= am, and I) huddled for a bit and put together the attached as a straw man c= harter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if= you think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://ww= w.ietf.org/mailman/listinfo/id-event
--_000_SN1PR0301MB1645DD56619DFBEDB69D6A62F57E0SN1PR0301MB1645_-- From nobody Sat May 7 18:53:29 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C112D1EA for ; Sat, 7 May 2016 18:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 Thg_WrZz_G6D for ; Sat, 7 May 2016 18:53:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 6F2E412D0CC for ; Sat, 7 May 2016 18:53:25 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u481rIWH022735 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 8 May 2016 01:53:19 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u481rHnF015072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 May 2016 01:53:17 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u481rGJU014895; Sun, 8 May 2016 01:53:16 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 May 2016 18:53:15 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-F0C933C9-046A-4592-93D5-E020CAD939DA Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sat, 7 May 2016 18:53:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> References: To: Mike Jones X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Alan Karp , Vivek Biswas , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 01:53:28 -0000 --Apple-Mail-F0C933C9-046A-4592-93D5-E020CAD939DA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We also set things up so even a domain specific event can be extended.=20 Eg on a password reset event, so event publishers may want to add security d= omain specific attributes. The spec lets them do that while avoiding interop= issues.=20 I believe in the spec we had the example of an account reset and the publish= er adds reset count as an extension.=20 Phil > On May 7, 2016, at 13:31, Mike Jones wrote: >=20 > Indeed, that=E2=80=99s why there=E2=80=99s a claims registry =E2=80=93 so c= ommon claims can be defined once and then reused. > =20 > From: Vivek Biswas > Sent: Saturday, May 7, 2016 1:24 PM > To: Mike Jones > Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org > Subject: Re: [Id-event] Straw man text for proposed charter > =20 > Yes, I agree that the claims can be application specific, however there is= a possibility to define claims which are domain specific. Thereby claims ge= nerated in one application could be understood by another application withi= n the same domain. >=20 > With microservices based architecture getting lot of attention, if two dif= ferent micro services defining different claims for the same claim, it can c= reate confusion. >=20 > Nevertheless this well defined claims for a particular domain can be an ex= tension to the core specification. >=20 > -Vivek Biswas > Consulting Member, Oracle >=20 > Sent from my iPhone >=20 > On May 7, 2016, at 1:04 PM, Mike Jones wrote= : >=20 >> Thanks Alan, >> =20 >> Interoperability will be on a per-application basis, just like JWT intero= perability. The claims needed in an identity event are application-specific= , just like claims are for JWTs. This is the same standards posture and JWT= s are a huge success =E2=80=93 including for interoperability, even if I do s= ay so myself. >> =20 >> Best wishes, >> -- Mike >> =20 >> =20 >> =20 >> =20 >> From: Alan Karp >> Sent: Saturday, May 7, 2016 10:23 AM >> To: Mike Jones >> Cc: Morteza Ansari (moransar); id-event@ietf.org >> Subject: Re: [Id-event] Straw man text for proposed charter >> =20 >> As one who proposed doing more, I believe that your position is valid. M= y only question is whether or not that will be enough for interoperability. >>=20 >>=20 >> -------------- >> Alan Karp >>=20 >>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones wrote: >>> Thanks guys, for writing the initial charter text. Reading it now, I am= extremely worried by the scope creep evident in the proposal. >>> =20 >>> I strongly support a working group to define an ID Events data format. I= just as strongly believe that specific event delivery mechanisms will neces= sarily be application-specific and therefore MUST be explicitly be stated as= being out of scope in the working group charter. Attempting to specify a p= articular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific deba= tes. >>> =20 >>> Should event delivery be reliable? That=E2=80=99s an application-specif= ic decision. >>> Should events be idempotent? That=E2=80=99s an application-specific dec= ision. >>> Should events be unicast, multicast, or broadcast? That=E2=80=99s an ap= plication-specific decision. >>> Should events have categories with category-specific subscriptions? Tha= t=E2=80=99s an application-specific decision. >>> Should only one party at a time be able to register for delivery of even= ts or should multiple parties be able to request delivery? That=E2=80=99s a= n application-specific decision. >>> I could continue with this list, but I think you all get the point=E2=80= =A6 >>> =20 >>> If we start debating application-specific event delivery mechanisms, we=E2= =80=99ll please almost no one, since nearly all applications have different e= vent delivery requirements. We MUST explicitly rule all delivery mechanisms= as being out of scope. >>> =20 >>> If we define only a data format, we can quickly produce a very useful sp= ecification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in the mud o= f debating which applications we=E2=80=99re catering to and which we aren=E2= =80=99t =E2=80=93 an exercise of picking favorites and limiting applicabilit= y of the specification. That way is a slow, painful descent into standards q= uicksand =E2=80=93 something we must avoid. Having a standard ID events rep= resentation is far too important to tie to a particular limited event delive= ry mechanism. >>> =20 >>> Sincerely, >>> -- Mike >>> =20 >>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp= >>> Sent: Thursday, May 5, 2016 9:43 PM >>> To: Morteza Ansari (moransar) >>> Cc: id-event@ietf.org >>> Subject: Re: [Id-event] Straw man text for proposed charter >>> =20 >>> I don't see anything about access control for publishing events and subs= cribing to them. I also think the spec should allow filters on subscription= s. >>>=20 >>>=20 >>> -------------- >>> Alan Karp >>> =20 >>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) wrote: >>> Hi folks, >>> =20 >>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and pu= t together the attached as a straw man charter proposal to start the discuss= ion. Please send your comments and suggestions for any changes or propose a n= ew one if you think its necessary. >>> =20 >>> =20 >>> Cheers, >>> Morteza >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-F0C933C9-046A-4592-93D5-E020CAD939DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We also set things up so even a domain= specific event can be extended. 
<= br>
Eg on a password reset event, so eve= nt publishers may want to add security domain specific attributes. The spec l= ets them do that while avoiding interop issues. 

I believe in the spec= we had the example of an account reset and the publisher adds reset count a= s an extension. 

Phil

On May 7, 2016, at 13:31, Mi= ke Jones <Michael.Jones@mi= crosoft.com> wrote:

Indeed, that=E2=80=99s why there=E2=80=99s a claims r= egistry =E2=80=93 so common claims can be defined once and then reused.

 

From: Vivek Biswas
Sent: Saturday, May 7, 2016 1:24 PM
To: Mike Jones
= Cc: Alan Karp; Morteza Ansari (moransar); id-event= @ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

Yes, I agree that the claims can be application specific, however there= is a possibility to define claims which are domain specific. Thereby claims= generated in one application could be understood by another  applicati= on within the same domain.

With microservices based architecture getting= lot of attention, if two different micro services defining different claims= for the same claim, it can create confusion.

Nevertheless this well defined claims for a p= articular domain can be an extension to the core specification.

-Vivek Biswas
  Consulting Member, Oracle

Sent from my iPhone

On May 7, 2016, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks Alan,

 

Interoperability will b= e on a per-application basis, just like JWT interoperability.  The clai= ms needed in an identity event are application-specific, just like claims ar= e for JWTs.  This is the same standards posture and JWTs are a huge success =E2=80=93 including for interoperabilit= y, even if I do say so myself.

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   Best wishes,

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;   -- Mike

 

 

 

 

From: Alan Karp
Sent: Saturday, May 7, 2016 10:23 AM
To: Mike Jones
= Cc: Morteza Ansari (moransar); id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

 

As one who proposed doing m= ore, I believe that your position is valid.  My only question is whethe= r or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <Michael= .Jones@microsoft.com> wrote:

Thanks guys, for writing the initial c= harter text.  Reading it now, I am extremely worried by the scope creep= evident in the proposal.

 

I strongly support a working group to= define an ID Events data format.  I just as strongly believe that spec= ific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as being= out of scope in the working group charter.  Attempting to specify a pa= rticular event delivery mechanism will take something that could be simple a= nd quick to approve and bog it down in necessarily application-specific debates.

 

Should event delivery be reliable?&nb= sp; That=E2=80=99s an application-specific decision.

Should events be idempotent?  Th= at=E2=80=99s an application-specific decision.

Should events be unicast, multicast, o= r broadcast?  That=E2=80=99s an application-specific decision.

Should events have categories with ca= tegory-specific subscriptions?  That=E2=80=99s an application-specific d= ecision.

Should only one party at a time be ab= le to register for delivery of events or should multiple parties be able to r= equest delivery?  That=E2=80=99s an application-specific decision.

I could continue with this list, but I= think you all get the point=E2=80=A6

 

If we start debating application-spec= ific event delivery mechanisms, we=E2=80=99ll please almost no one, since ne= arly all applications have different event delivery requirements.  We MUST explicitly rule all delivery mechanisms as bein= g out of scope.

 

If we define only a data format, we c= an quickly produce a very useful specification.  If we don=E2=80=99t, w= e=E2=80=99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80=93 an exercise= of picking favorites and limiting applicability of the specification. = That way is a slow, painful descent into standards quicksand =E2=80=93 some= thing we must avoid.  Having a standard ID events representation is far too important to tie to a particular limited event delivery mechanism.<= u>

 

      &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; Sincerely,

      &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ; -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@i= etf.org
Subject: Re: [Id-event] Straw man text for proposed charter=

 

I don't see anything about access control for publish= ing events and subscribing to them.  I also think the spec should allow= filters on subscriptions.



--------------
Alan Karp

 

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mora= nsar) <moransar@c= isco.com> wrote:

Hi folks,

 

At IIW a few of us (Phil, William, Adam= , and I) huddled for a bit and put together the attached as a straw man char= ter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if y= ou think its necessary.

 

 

Cheers,

Morteza


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/mailman/listinfo/id-event

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www= .ietf.org/mailman/listinfo/id-event
____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-F0C933C9-046A-4592-93D5-E020CAD939DA--