From nobody Tue Mar 3 07:59:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12DD1A879A for ; Tue, 3 Mar 2015 07:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NSZQG9M82mW3 for ; Tue, 3 Mar 2015 07:59:44 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6251A878E for ; Tue, 3 Mar 2015 07:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1425398383; x=1426607983; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cYZ+MndUlQHUDjHl3H5+ycsBh+EzT19dQrNi7jD7Kok=; b=h3ZWCJUKy51hDC2I3mySd6OAUXWfl7fhYYtXJWFIXzngNGJ7Bz8BCEmP WBKHent5NkcBg3rL/3tZuDA+mxqjZCsi3hvaIkObi8+BHgebDJ47GuPWN oyQ0ZMdbnf0S1Q0Cy2r+AoxFysI7OIdTzX/HoT6aHnd7tyS6d6WJMwpYY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxBgCh2fVU/5ldJa1agwJSVQUEgwe8DYIyhW4CHIEMTQEBAQEBAXyEEAEBBCMRQxICAQgaAiYCAgIwFQYBBgMCBBMJEYgVCAW7a5pCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGEdYJoL4EUBY95g2CFaYEaOYJpjyMjg25vAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,682,1418083200"; d="scan'208";a="128492868" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 03 Mar 2015 15:59:43 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t23FxhAq019771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Mar 2015 15:59:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 09:59:42 -0600 From: "Joe Hildebrand (jhildebr)" To: "spud@ietf.org" Thread-Topic: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVcrn/YYxcKCBL0m1gYXxY+ydN50LX98A Date: Tue, 3 Mar 2015 15:59:41 +0000 Message-ID: <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> In-Reply-To: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.61.175.73] Content-Type: text/plain; charset="utf-8" Content-ID: <2D94260016408D4AB2E0A2E0F455D9E8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 15:59:46 -0000 TmV3IHZlcnNpb24uICBOb3RlIHRoYXQgdGhlIHBhY2tldCBmb3JtYXQgaGFzIGNoYW5nZWQgKGFn YWluKS4gIFNvcnJ5IGFib3V0IHRoYXQsIGJ1dCB0aGUgZ29vZCBuZXdzIGlzIHlvdSBzaG91bGQg anVzdCBoYXZlIHRvIGRlbGV0ZSBzb21lIGNvZGUuICBOaWNlIEhUTUwgdmVyc2lvbiBoZXJlOg0K DQpodHRwOi8vaGlsZGpqLmdpdGh1Yi5pby9kcmFmdC1oaWxkZWJyYW5kLXNwdWQtcHJvdG90eXBl Lw0KDQoNCk9uIDMvMy8xNSwgNDo1OCBQTSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaGlsZGVicmFuZC1zcHVkLXByb3RvdHlwZS0wMi50eHQNCj5oYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpvZSBIaWxkZWJyYW5kIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1oaWxkZWJyYW5kLXNwdWQtcHJvdG90 eXBlDQo+UmV2aXNpb246CTAyDQo+VGl0bGU6CQlTdWJzdHJhdGUgUHJvdG9jb2wgZm9yIFVzZXIg RGF0YWdyYW1zIChTUFVEKSBQcm90b3R5cGUNCj5Eb2N1bWVudCBkYXRlOgkyMDE1LTAzLTAzDQo+ R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTE0DQo+VVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhpbGRlYnJhbmQt c3B1ZC1wcm90b3R5cGUtMDIudHh0DQo+U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhpbGRlYnJhbmQtc3B1ZC1wcm90b3R5cGUvDQo+SHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhpbGRlYnJhbmQtc3B1 ZC1wcm90b3R5cGUtMDINCj5EaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaGlsZGVicmFuZC1zcHVkLXByb3RvdHlwZS0wMg0KPg0KPkFic3RyYWN0 Og0KPiAgIFNQVUQgaXMgYSBwcm90b3R5cGUgZm9yIGdyb3VwaW5nIFVEUCBwYWNrZXRzIHRvZ2V0 aGVyIGluIGEgInR1YmUiLA0KPiAgIGFsc28gYWxsb3dpbmcgbmV0d29yayBkZXZpY2VzIG9uIHRo ZSBwYXRoIGJldHdlZW4gZW5kcG9pbnRzIHRvDQo+ICAgcGFydGljaXBhdGUgZXhwbGljaXRseSBp biB0aGUgdHViZSBvdXRzaWRlIHRoZSBlbmQtdG8tZW5kIGNvbnRleHQuDQo+DQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+DQoNCg0KLS0gDQpKb2UgSGlsZGVicmFu ZA0KDQoNCg0K From nobody Tue Mar 3 10:28:19 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1745C1A8825 for ; Tue, 3 Mar 2015 10:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 YtvW8pl2f689 for ; Tue, 3 Mar 2015 10:28:16 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 AB6E91A885F for ; Tue, 3 Mar 2015 10:28:14 -0800 (PST) Received: by igbhn18 with SMTP id hn18so30428837igb.2 for ; Tue, 03 Mar 2015 10:28:14 -0800 (PST) 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:content-type; bh=BJX7v73I8kD7O2aLdY70+0IBt2hhpx90Du8zHyP3YDg=; b=MC9vWta6M63Cjz+SUsfifgd6reA1Fxidk1AdGPZO/OJGQHAMVTtJhrNMdEib4/aFRS yOUTnQMH7+BZ+WllXrRpo4mdAyL2VQdf781sl7Dy0gbCdB/KT0uCWJ5z3cbjBQwPmIbU 8Ui+1oSt9ee6dE+H6ckvXW+bxB8A2Wk8dP647oEJbwz5MaTvVi3nuqsTfk/+/bBUGBWw 9LxH4EVyfE6llOTdMFcy5wvZrpoklL9hIx4INPsC02sq+zbYYs6NZLW8r2Y8SXFzMrjh /2xmc9YmQjUc/k17HssS5mdrY1UKkJTg6jghM8OBzHuj1LUlHivEIQaEsEk7kkYVcXbm rVfg== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr3994201igl.6.1425407293908; Tue, 03 Mar 2015 10:28:13 -0800 (PST) Received: by 10.42.35.80 with HTTP; Tue, 3 Mar 2015 10:28:13 -0800 (PST) In-Reply-To: <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Tue, 3 Mar 2015 10:28:13 -0800 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e011825c069eb430510667faa Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:28:18 -0000 --089e011825c069eb430510667faa Content-Type: text/plain; charset=UTF-8 The draft currently asks whether the Tube ID should be scoped to a single source address or not. My preference is to stick to a single 5-tuple now, as in the common case, the path may change with a change in source address. There is still some chance that a changing privacy address in V6-land would not, but let's not optimize for that just now. Ted On Tue, Mar 3, 2015 at 7:59 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > New version. Note that the packet format has changed (again). Sorry > about that, but the good news is you should just have to delete some code. > Nice HTML version here: > > http://hildjj.github.io/draft-hildebrand-spud-prototype/ > > > On 3/3/15, 4:58 PM, "internet-drafts@ietf.org" > wrote: > > > > >A new version of I-D, draft-hildebrand-spud-prototype-02.txt > >has been successfully submitted by Joe Hildebrand and posted to the > >IETF repository. > > > >Name: draft-hildebrand-spud-prototype > >Revision: 02 > >Title: Substrate Protocol for User Datagrams (SPUD) Prototype > >Document date: 2015-03-03 > >Group: Individual Submission > >Pages: 14 > >URL: > http://www.ietf.org/internet-drafts/draft-hildebrand-spud-prototype-02.txt > >Status: > https://datatracker.ietf.org/doc/draft-hildebrand-spud-prototype/ > >Htmlized: > http://tools.ietf.org/html/draft-hildebrand-spud-prototype-02 > >Diff: > http://www.ietf.org/rfcdiff?url2=draft-hildebrand-spud-prototype-02 > > > >Abstract: > > SPUD is a prototype for grouping UDP packets together in a "tube", > > also allowing network devices on the path between endpoints to > > participate explicitly in the tube outside the end-to-end context. > > > > > > > > > >Please note that it may take a couple of minutes from the time of > submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > > > > > > -- > Joe Hildebrand > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --089e011825c069eb430510667faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The draft currently asks whether the Tube ID sho= uld be scoped to a single source address or not.=C2=A0 My preference is to = stick to a single 5-tuple now, as in the common case, the path may change w= ith a change in source address.

There is still some = chance that a changing privacy address in V6-land would not, but let's = not optimize for that just now.

Ted
<= div class=3D"gmail_extra">
On Tue, Mar 3, 201= 5 at 7:59 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
New version.=C2=A0 Note that the= packet format has changed (again).=C2=A0 Sorry about that, but the good ne= ws is you should just have to delete some code.=C2=A0 Nice HTML version her= e:

http://hildjj.github.io/draft-hildebrand-spud-prototype/

On 3/3/15, 4:58 PM, "inter= net-drafts@ietf.org" <internet-drafts@ietf.org> wrote:

>
>A new version of I-D, draft-hildebrand-spud-prototype-02.txt
>has been successfully submitted by Joe Hildebrand and posted to the
>IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-hildebrand-spud-prototype=
>Revision:=C2=A0 =C2=A0 =C2=A0 02
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Substrate Protocol for User Dat= agrams (SPUD) Prototype
>Document date: 2015-03-03
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014
>URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-hildebrand-spud-prototype-02= .txt
>Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://d= atatracker.ietf.org/doc/draft-hildebrand-spud-prototype/
>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.= org/html/draft-hildebrand-spud-prototype-02
>Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= http://www.ietf.org/rfcdiff?url2=3Ddraft-hildebrand-spud-prototype-02 >
>Abstract:
>=C2=A0 =C2=A0SPUD is a prototype for grouping UDP packets together in a= "tube",
>=C2=A0 =C2=A0also allowing network devices on the path between endpoint= s to
>=C2=A0 =C2=A0participate explicitly in the tube outside the end-to-end = context.
>
>
>
>
>Please note that it may take a couple of minutes from the time of submi= ssion
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>


--
Joe Hildebrand



_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud

--089e011825c069eb430510667faa-- From nobody Tue Mar 3 10:30:51 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50981A6F03 for ; Tue, 3 Mar 2015 10:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2dJj_339A5NS for ; Tue, 3 Mar 2015 10:30:48 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87331A1BF3 for ; Tue, 3 Mar 2015 10:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1425407448; x=1426617048; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H/42KKXOIHP9Qf68Q79IN3qD53FbIr0HgP3Fhn2kH6k=; b=RHDLjgWeUW2y+oiiYOYKOio+91jvHIkJz9yAw7LQp10246llQiDJSoGP sSjNaltk2gv4fKKvF0Y8v/jvkJgU1xZ4dBsOxptWadu6hbm8IIPMX9zsn IUHzyBQRTKbEA6L0FBzS1L9w3dlLR4sQ/txCP1MjUjTLSGd2pNLihySMS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsBgBI/fVU/5xdJa1agwKBLASDB7wNiCACHIEMTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICHxEVBwkCBA4FiBsDEbwKlQkNhR4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcYJEgXczB4JoL4EUAQSPeYgBgUiNU4YMI4F/HxSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,682,1418083200"; d="scan'208";a="128538615" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 03 Mar 2015 18:30:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t23IUl3I026513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 18:30:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 12:30:47 -0600 From: "Joe Hildebrand (jhildebr)" To: Ted Hardie Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVcrn/YYxcKCBL0m1gYXxY+ydN50LX98AgAAYvoCAABF6AA== Date: Tue, 3 Mar 2015 18:30:46 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.61.175.73] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:30:49 -0000 T24gMy8zLzE1LCA3OjI4IFBNLCAiVGVkIEhhcmRpZSIgPHRlZC5pZXRmQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCj5UaGUgZHJhZnQgY3VycmVudGx5IGFza3Mgd2hldGhlciB0aGUgVHViZSBJRCBzaG91 bGQgYmUgc2NvcGVkIHRvIGEgc2luZ2xlIHNvdXJjZSBhZGRyZXNzIG9yIG5vdC4gIE15IHByZWZl cmVuY2UgaXMgdG8gc3RpY2sgdG8gYSBzaW5nbGUgNS10dXBsZSBub3csIGFzIGluIHRoZSBjb21t b24gY2FzZSwgdGhlIHBhdGggbWF5IGNoYW5nZSB3aXRoIGEgY2hhbmdlIGluIHNvdXJjZSBhZGRy ZXNzLg0KPg0KPlRoZXJlIGlzIHN0aWxsIHNvbWUgY2hhbmNlIHRoYXQgYSBjaGFuZ2luZyBwcml2 YWN5IGFkZHJlc3MgaW4gVjYtbGFuZCB3b3VsZCBub3QsIGJ1dCBsZXQncyBub3Qgb3B0aW1pemUg Zm9yIHRoYXQganVzdCBub3cuDQoNCkknbSBvayB3aXRoIHRoYXQgZm9yIG5vdy4gIFRoZSBuZXh0 IHF1ZXN0aW9uIHRoZW4gaXMgaWYgdGhlIFR1YmUgSUQgYWRkcyBhbnkgdmFsdWUgYXQgYWxsPyAg SXMgdGhlIHNvdXJjZSBzb2NrYWRkcl9pbls2XSBlbm91Z2g/ICBXZSBjb3VsZCBzYXZlIHNvbWUg Ynl0ZXMuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Mar 3 10:50:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0660C1A870A for ; Tue, 3 Mar 2015 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 q4UHWGJKHLpX for ; Tue, 3 Mar 2015 10:50:13 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 4AF021A1BF3 for ; Tue, 3 Mar 2015 10:50:13 -0800 (PST) Received: by igkb16 with SMTP id b16so30493817igk.1 for ; Tue, 03 Mar 2015 10:50:12 -0800 (PST) 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:content-type; bh=9mcUSJG5C/FUQgwfUswC/XNlqgDe80V1GHR6yCWaBrc=; b=UDj0zBrT1OUcS2tQv08QkOAkgmREwppiT5QLnYt6ArRfDyAy3PRwpszKgEa00d4BGc JDDuVvisbAPZNWcLAVz3C6ee9TVPOKSCY86m9N4m4MotVAFOg7zTjXD3adUa7GB7SzKk 8uH2UXHATBRtbC5zuWdkTLWaFI36N5/xevN+rV4GrMDAALsGgNpTHQv3lRpm9zanFntF zWHpltj2VOTRCyiFhmDq/uWmoWPCFHnPJutdWaWvZuTE7jDpfw2T026z2i6j7aUo/Z3A dH6xaT//JG6qDSAboduCjnCGqJNi1pj9BTquVbXHdl1jRJ+azc1cdzHO/h6hqdVPatN6 nGyA== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr30336022igb.6.1425408612504; Tue, 03 Mar 2015 10:50:12 -0800 (PST) Received: by 10.42.35.80 with HTTP; Tue, 3 Mar 2015 10:50:12 -0800 (PST) In-Reply-To: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Tue, 3 Mar 2015 10:50:12 -0800 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b41444c0240cf051066ce86 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:50:15 -0000 --047d7b41444c0240cf051066ce86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2015 at 10:30 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 3/3/15, 7:28 PM, "Ted Hardie" wrote: > > >The draft currently asks whether the Tube ID should be scoped to a singl= e > source address or not. My preference is to stick to a single 5-tuple now= , > as in the common case, the path may change with a change in source addres= s. > > > >There is still some chance that a changing privacy address in V6-land > would not, but let's not optimize for that just now. > > I'm ok with that for now. The next question then is if the Tube ID adds > any value at all? Is the source sockaddr_in[6] enough? We could save so= me > bytes. > > =E2=80=8BI don't think it is enough, because you still need to disambigua= te flows that go between the same endpoints but are different tubes. The explicit identifiers allow you to make statements about their relationships more easily (think about the ordinal ranking use case, where a video app wants to say "this thumbnail flow is more important than the full-resolution flow") =E2=80=8BThese aren't the bytes to save, in my opinion. Ted=E2=80=8B > -- > Joe Hildebrand > > > > --047d7b41444c0240cf051066ce86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 3, 2015 at 10:30 AM= , Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
=
= On 3/3/15, 7:28 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

>The draft currently asks whether the Tube ID should be scoped to a sing= le source address or not.=C2=A0 My preference is to stick to a single 5-tup= le now, as in the common case, the path may change with a change in source = address.
>
>There is still some chance that a changing privacy address in V6-land w= ould not, but let's not optimize for that just now.

I'm ok with that for now.=C2=A0 The next question then is if the= Tube ID adds any value at all?=C2=A0 Is the source sockaddr_in[6] enough?= =C2=A0 We could save some bytes.

=E2=80=8BI don't think it is enough, because you stil= l need to disambiguate flows that go between the same endpoints but are dif= ferent tubes.=C2=A0 The explicit identifiers allow you to make statements a= bout their relationships more easily (think about the ordinal ranking use c= ase, where a video app wants to say "this thumbnail flow is more impor= tant than the full-resolution flow")

=E2=80=8BT= hese aren't the bytes to save, in my opinion.

= Ted=E2=80=8B


=C2=A0
--
Joe Hildebrand




--047d7b41444c0240cf051066ce86-- From nobody Tue Mar 3 10:53:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8D1A88CE for ; Tue, 3 Mar 2015 10:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kuZi64NXmI82 for ; Tue, 3 Mar 2015 10:53:22 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 99B611AC3E6 for ; Tue, 3 Mar 2015 10:53:21 -0800 (PST) Received: from [10.179.1.252] (unknown [213.55.184.235]) by trammell.ch (Postfix) with ESMTPSA id 5857A1A0161; Tue, 3 Mar 2015 19:53:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Mar 2015 19:53:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85640FC4-4EB1-49F6-A7D9-D3C85760B874@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> To: "Joe Hildebrand (jhildebr)" Archived-At: Cc: Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:53:25 -0000 Sent from my iPhone (but not top quoted) > On 03 Mar 2015, at 19:30, Joe Hildebrand (jhildebr) w= rote: >=20 >> On 3/3/15, 7:28 PM, "Ted Hardie" wrote: >>=20 >> The draft currently asks whether the Tube ID should be scoped to a single= source address or not. My preference is to stick to a single 5-tuple now, a= s in the common case, the path may change with a change in source address. >>=20 >> There is still some chance that a changing privacy address in V6-land wou= ld not, but let's not optimize for that just now. >=20 > I'm ok with that for now. The next question then is if the Tube ID adds a= ny value at all? Is the source sockaddr_in[6] enough? We could save some b= ytes. Sub-port level multiplexing for userspace spud implementations, and inabilit= y for someone who knows the 5 tuple to spoof p2a messages. It's a 64-bit str= ong proof you saw the packet, which is strong enough to make brute force exp= ensive. 32 bits isn't. And 48 bit ints are weird, ieee 802 notwithstanding. (And if we scope tube ids to 5 tuples always, the we can't carry them across= v6 privacy addresses. Otherwise, whither privacy?) > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Mar 3 10:57:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5B1AC42F for ; Tue, 3 Mar 2015 10:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kKp77T2-yWkC for ; Tue, 3 Mar 2015 10:57:35 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 414C61AC3E6 for ; Tue, 3 Mar 2015 10:57:35 -0800 (PST) Received: from [10.179.1.252] (unknown [213.55.184.235]) by trammell.ch (Postfix) with ESMTPSA id 678041A0161; Tue, 3 Mar 2015 19:57:04 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-108F0CBE-3104-4C51-81A8-0990FFB7A2B0 Mime-Version: 1.0 (1.0) From: Brian Trammell X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Mar 2015 19:57:04 +0100 Content-Transfer-Encoding: 7bit Message-Id: <006752BB-DB73-42D2-9E08-98C619BAA720@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> To: Ted Hardie Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:57:38 -0000 --Apple-Mail-108F0CBE-3104-4C51-81A8-0990FFB7A2B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone (but not top quoted) > On 03 Mar 2015, at 19:50, Ted Hardie wrote: >=20 >> On Tue, Mar 3, 2015 at 10:30 AM, Joe Hildebrand (jhildebr) wrote: >> On 3/3/15, 7:28 PM, "Ted Hardie" wrote: >>=20 >> >The draft currently asks whether the Tube ID should be scoped to a singl= e source address or not. My preference is to stick to a single 5-tuple now,= as in the common case, the path may change with a change in source address.= >> > >> >There is still some chance that a changing privacy address in V6-land wo= uld not, but let's not optimize for that just now. >>=20 >> I'm ok with that for now. The next question then is if the Tube ID adds a= ny value at all? Is the source sockaddr_in[6] enough? We could save some b= ytes. > =E2=80=8BI don't think it is enough, because you still need to disambiguat= e flows that go between the same endpoints but are different tubes. The exp= licit identifiers allow you to make statements about their relationships mor= e easily (think about the ordinal ranking use case, where a video app wants t= o say "this thumbnail flow is more important than the full-resolution flow")= Also this; it allows some spud endpoint users to group sub flows and bind pr= operties in interesting ways. (I was actually wondering if 64 bits are enough to allow enough subflow poin= ts while still keeping the active tube id space small) > =E2=80=8BThese aren't the bytes to save, in my opinion. >=20 > Ted=E2=80=8B >=20 >=20 > =20 >> -- >> Joe Hildebrand >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail-108F0CBE-3104-4C51-81A8-0990FFB7A2B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone (but not t= op quoted)

On 03 Mar 2015, at 19:50, Ted Hardie <ted.ietf@gmail.com> wrote:

<= blockquote type=3D"cite">
On= Tue, Mar 3, 2015 at 10:30 AM, Joe Hildebrand (jhildebr) &= lt;jhildebr@cisco.co= m> wrote:
On 3/3/15, 7:28 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

>The draft currently asks whether the Tube ID should be scoped to a singl= e source address or not.  My preference is to stick to a single 5-tuple= now, as in the common case, the path may change with a change in source add= ress.
>
>There is still some chance that a changing privacy address in V6-land wo= uld not, but let's not optimize for that just now.

I'm ok with that for now.  The next question then is if the Tube= ID adds any value at all?  Is the source sockaddr_in[6] enough?  W= e could save some bytes.

=E2=80=8BI don't think it is enough, because you still need t= o disambiguate flows that go between the same endpoints but are different tu= bes.  The explicit identifiers allow you to make statements about their= relationships more easily (think about the ordinal ranking use case, where a= video app wants to say "this thumbnail flow is more important than the full= -resolution flow")

=
Also this; it allows some spud endpoint users to group sub flows a= nd bind properties in interesting ways.

(I was actu= ally wondering if 64 bits are enough to allow enough subflow points while st= ill keeping the active tube id space small)

=E2=80=8BThese aren't the bytes to save, in my opinion.
=
Ted=E2=80=8B


 
--
Joe Hildebrand




____________________= ___________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman= /listinfo/spud
= --Apple-Mail-108F0CBE-3104-4C51-81A8-0990FFB7A2B0-- From nobody Tue Mar 3 10:59:29 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74BD1AC42A for ; Tue, 3 Mar 2015 10:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Hzp5VtXSwrJp for ; Tue, 3 Mar 2015 10:59:26 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93D91AC3E6 for ; Tue, 3 Mar 2015 10:59:25 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-4e-54f6048b25eb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2E.C7.13725.B8406F45; Tue, 3 Mar 2015 19:59:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.100]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 19:59:23 +0100 From: Salvatore Loreto To: "Joe Hildebrand (jhildebr) " Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVeQpIBitgQQWrEmeEhmdu/nqKw== Date: Tue, 3 Mar 2015 18:59:22 +0000 Message-ID: <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_CD38BE7E-AD28-40D6-BFCD-4C43E9AEE245"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM+JvjW4Py7cQgxcTGS3O7jnObrHowlNG i8a5dg7MHlN+b2T12DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgydh3axVZw3bxi4vkz7A2M c026GDk5JARMJL6vu8sEYYtJXLi3nq2LkYtDSOAIo8TEk0cZIZzFjBLTDi5mAaliEzCTeP5w CzOILSLgJTH73yswm1nARWL6pJVsILawQKTEmY9LmCBqoiSutz1gg7D1JA6u2cAKYrMIqEj8 a2gCi/MK2Ev8XLKZCWLZO0aJLw93gQ3lFLCV6G64DbaYEei876fWMEEsE5e49WQ+1NkiEg8v nmaDsEUlXj7+xwphK0ksuv0ZbCizwBRGidMvFjNBbBOUODnzCcsERtFZSGbNQlY3C0kdRJG2 xLKFr5lnMXIA2ToSkxcyQoRNJV4f/QhlW0vM+HWQDcJWlJjS/ZB9ASPHKkbR4tTi4tx0I2O9 1KLM5OLi/Dy9vNSSTYzA+Dy45bfuDsbVrx0PMQpwMCrx8G5Q/hoixJpYVlyZe4hRmoNFSZzX zvhQiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG0YPs60NenfjfM40la76uvPUc1fLAN87B 7KuPyR5t9K79+/nVIqP8BO32ypXLlk8QmfTshcCDH/P8v3la279zWyNzXinHTFX81L8Hy5WO z3xwc+0Ntyd2vmv+Zl/4cnJb0fFvYWHXe7jEhTjlMisX7/R79WeWvMP3O+py85akJLs/qi6t 4sycq8RSnJFoqMVcVJwIAPF5o/uwAgAA Archived-At: Cc: Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:59:28 -0000 --Apple-Mail=_CD38BE7E-AD28-40D6-BFCD-4C43E9AEE245 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I tend to agree with Ted changing the source IP address in most of the case implies a different = path (i.e. some or all different middle-boxes in the path towards the = destination) using the source sockaddr_in would mean inserting the actual ip address = in SPUD and then making easy for the rest of the path figure it out when you are = behind a NAT=20 /Sal > On 03 Mar 2015, at 20:30, Joe Hildebrand (jhildebr) = wrote: >=20 > On 3/3/15, 7:28 PM, "Ted Hardie" wrote: >=20 >> The draft currently asks whether the Tube ID should be scoped to a = single source address or not. My preference is to stick to a single = 5-tuple now, as in the common case, the path may change with a change in = source address. >>=20 >> There is still some chance that a changing privacy address in V6-land = would not, but let's not optimize for that just now. >=20 > I'm ok with that for now. The next question then is if the Tube ID = adds any value at all? Is the source sockaddr_in[6] enough? We could = save some bytes. >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_CD38BE7E-AD28-40D6-BFCD-4C43E9AEE245 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtTCCBfcw ggPfoAMCAQICECdJad3aK1sYKvRZUYHGY2cwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMDkw NTI1WhcNMTcxMjAzMDkwNTI0WjBuMREwDwYDVQQKDAhFcmljc3NvbjEZMBcGA1UEAwwQU2FsdmF0 b3JlIExvcmV0bzEsMCoGCSqGSIb3DQEJARYdc2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20x EDAOBgNVBAUTB3RlaWxvc2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCNk8Iy/Fsn 7ymm3JY2s4AJQK4TRSjMVqkTUX8/F+gN6RGt5nNeFO3KBeYRWMAko4JCtz/u43G5HYm4zcXn8hdB ku94IV1rRPIUkP66ytoI1zu+fHm6w+1+IVBwKsBDi9PwaEwqTTuksTQYnZoTMkX+tJxzy7m0vjNi DGYDLC3RT/ymj52EIAH+QmkNqv/1Iw1RaJ8gMkreWxe7xgqrvqJ+m/p6GFpsQSbEVFYxz5vhh6xN BqPD0kBF0AhPyoWw7cIKFZ/SHkySNsrC2vbGmTtxX1GHo4M3oDl3KtO3AHG/sFnt9ZSkjUadMjEa I+/CryZVUjfEOJVkhhWftD/rW1vnAgMBAAGjggHDMIIBvzBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYyLmNlcjAoBgNVHREEITAfgR1zYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTBV BgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH AwIwHQYDVR0OBBYEFMdcgwlkDjoPNsC/O46GnDXzMZ98MB8GA1UdIwQYMBaAFLENytRGt6+GAsMv bwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAA6FcabbIFtthK+wT OgErOArRUJWvwOWTC5aGSrMxNjoEbojqib6j2Qh8v3g5glcP923Lbu1gL/NtyZnHUJV3C4ivSt+w XRUhOCLs4fwDTOiHMfkNpxx1FFEXsaLfSB9HeFWY+FrlDMh1xZHTcBsx940u1PBhfvWg/ogSZ/4Y 7gIb0RZkJ7P+JN3vHSpb0ubSAcQeHC3S2zFdrFMb+GfV2LG+A95NWsL/fxOjsMiVYXba8DVWif9l ads1P9BFoaK2gHcmaBViQVzhf8WMlZfOGiuk8fjVu3+d+8ub0bKuvl2jPo/dcCmo8cFonCb94cem XzbS6Sm0bsv456iCSHUAKUi7f+G+GRx4IpZFS45twCSQ7BNd0Y6WGDurLKFjqO5I+917FrR4sJ8o RQn/uKBY4C05aLs5uq7Qbpx+V4LeBCMiimbIeYXfxhsx1rr9icy8qwMSzYjxl2eHubcobwbo0TcO obrGGLQxVHUqn1YR/f2uFiVZiy4BF8OUPAUscTOPOx7u3LAlV/QT16/vQw3Xx1K+u67cxgRNKBhy qLgN5ZsZ/654CkP/Anw4JO9fr9cWrGul4TJodqGmIGVNjpmMlM1HOzR+UQDTjG8Yr1P1D091hLEH h9/XJZcCtdmv/wcAAtYJ7WLT9HdBlRO0PYbzqDvO9kwkKs83Q3xemdXLB1owgga2MIIEnqADAgEC AhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1 MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjq o3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1l l4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h 2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImb VWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZX VSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDE SYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBI L41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8T C1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh7 3CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0 MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29u ZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52 cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEA bgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHs MmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnf sYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XM tOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagB LnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1 lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0Ibbu ZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgd mLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HY NkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0x ggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMwMzE4NTkyMlowIwYJKoZIhvcN AQkEMRYEFDUGcZHgWLMNEznfpqzW7QowvkjEMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICECdJad3aK1sY KvRZUYHGY2cwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMA0GCSqGSIb3 DQEBAQUABIIBAI0IS0jdsSehYo5aZf0PySnVMPN0XIgE/a7/dsmgPhx/NqF3FGl2FspkNzTTq7cR bH8Q35zDB2iWsLqaIEssx0JDiZ2ROgMxn/tC7KMIhLYAK3nGWrK/IKbDvonGxMht4Sl26jDU/FrB Rkt/DyABk1td/hVn6v5e/1oMwRjHUKBMKa33CVg/QtppkpOeeuZa5C4V+TThs2bHjHOvhVkeMAS0 YTjH98F7ExH1TEAgssfZ9a29IGFqM53xT3dWuWtW66x7jHO8JOqf30MckayLY4GePlR0jE8NsJbn /5ZECYY8aNR94WkN4AsMx5g5dQt/W7OEkYjeE8P8u7aV03nM6w4AAAAAAAA= --Apple-Mail=_CD38BE7E-AD28-40D6-BFCD-4C43E9AEE245-- From nobody Tue Mar 3 11:01:03 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A671A1A33 for ; Tue, 3 Mar 2015 11:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9xj6C4-WU-vg for ; Tue, 3 Mar 2015 11:00:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686EC1A879F for ; Tue, 3 Mar 2015 11:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=924; q=dns/txt; s=iport; t=1425409244; x=1426618844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M0IL9oDpPVdpcB9lQs9vF5to8qT5FV6cP51b7ZKIqcc=; b=Oy0I3iGOVmQgkhdUFjX24cE/mL86DIRMOKLTNz7qSoVyWt+nl/4X7pNF j+DpK+i22E0eWCON34YZtbzfoNWbQlcrShvGF4iVDrKRPjGG2P5A4Fh5X g+gA+v4gD3Y8kefKV8wq6XvxccOcNsk7q0ibhAz6wBEtnSSudeIPuB0Sw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsBgAJBPZU/49dJa1agwKBLASDB7wNiCACHIEMTQEBAQEBAXyEEAEBBCMRPgUCEAIBCBoCJgICAh8RFQcJAgQOBYgbAxG8ApUDDYUeAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGCRIF3MweCaC+BFAEEj3mIAYFIjVOGDCOBfx8UgTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,682,1418083200"; d="scan'208";a="400555727" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 03 Mar 2015 19:00:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t23J0hrW003812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 19:00:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 13:00:43 -0600 From: "Joe Hildebrand (jhildebr)" To: Ted Hardie Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVcrn/YYxcKCBL0m1gYXxY+ydN50LX98AgAAYvoCAABF6AP//9KoAgAATsYA= Date: Tue, 3 Mar 2015 19:00:43 +0000 Message-ID: <82FC66A7-1CD1-4271-955E-0586C6853457@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.61.175.73] Content-Type: text/plain; charset="utf-8" Content-ID: <90B4D49AEAAD9545A2C7C32144590A63@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 19:00:59 -0000 T24gMy8zLzE1LCA3OjUwIFBNLCAiVGVkIEhhcmRpZSIgPHRlZC5pZXRmQGdtYWlsLmNvbT4gd3Jv dGU6DQoNCj7igItJIGRvbid0IHRoaW5rIGl0IGlzIGVub3VnaCwgYmVjYXVzZSB5b3Ugc3RpbGwg bmVlZCB0byBkaXNhbWJpZ3VhdGUgZmxvd3MgdGhhdCBnbyBiZXR3ZWVuIHRoZSBzYW1lIGVuZHBv aW50cyBidXQgYXJlIGRpZmZlcmVudCB0dWJlcy4gIFRoZSBleHBsaWNpdCBpZGVudGlmaWVycyBh bGxvdyB5b3UgdG8gbWFrZSBzdGF0ZW1lbnRzIGFib3V0IHRoZWlyIHJlbGF0aW9uc2hpcHMgbW9y ZSBlYXNpbHkgKHRoaW5rIGFib3V0IHRoZSBvcmRpbmFsIHJhbmtpbmcNCj4gdXNlIGNhc2UsIHdo ZXJlIGEgdmlkZW8gYXBwIHdhbnRzIHRvIHNheSAidGhpcyB0aHVtYm5haWwgZmxvdyBpcyBtb3Jl IGltcG9ydGFudCB0aGFuIHRoZSBmdWxsLXJlc29sdXRpb24gZmxvdyIpDQo+DQo+4oCLVGhlc2Ug YXJlbid0IHRoZSBieXRlcyB0byBzYXZlLCBpbiBteSBvcGluaW9uLg0KDQpBbHRob3VnaCBpbiBU Q1Agd2UgY3VycmVudGx5IHVzZSBkaWZmZXJlbnQgc291cmNlIHBvcnRzIGZvciBkaWZmZXJlbnQg c29ja2V0cywgSSdtIGhhcHB5IHRvIGFncmVlIHdpdGggeW91IHVudGlsL3VubGVzcyB3ZSBsZWFy biBzb21ldGhpbmcgbmV3Lg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Tue Mar 3 11:02:41 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC021A88B9 for ; Tue, 3 Mar 2015 11:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Hdg0Rm4bQIKX for ; Tue, 3 Mar 2015 11:02:38 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6A11A88AF for ; Tue, 3 Mar 2015 11:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=798; q=dns/txt; s=iport; t=1425409358; x=1426618958; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7GMrdB8MxQtbOp/O00YPiiWFK7UNcptCt/GAxzvOj8k=; b=VLoQc4NoUiW/UIANGDC7It2iEgmrGihruJ6W0iUjMqaOn50geRelOI83 IwSjsZZVdZFxRTcCjvvQsi/llm4Esz8e0i7HgiVqEdcqeym39kZ8ruUXl EWVXEynsGG6bS62j4jj6RYeL36S/2EPLrGDreX81Ga9IIsFyplPAsBIPZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsBgDCBPZU/5JdJa1agwKBLASDB7wNiCACHIEMTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICMBUQAgQOBYgvvASaLQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlxhG4HgmgvgRQBBI95iUmTXyODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,682,1418083200"; d="scan'208";a="128549880" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 03 Mar 2015 19:02:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t23J2b3S004976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 19:02:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 13:02:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Salvatore Loreto Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVeQvZrH3T8NxiUa4CiQ1eR4+Hp0LkskA Date: Tue, 3 Mar 2015 19:02:36 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> In-Reply-To: <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.61.175.73] Content-Type: text/plain; charset="utf-8" Content-ID: <756AA8412E267C45AD16B71E3227F516@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 19:02:39 -0000 T24gMy8zLzE1LCA3OjU5IFBNLCAiU2FsdmF0b3JlIExvcmV0byIgPHNhbHZhdG9yZS5sb3JldG9A ZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkkgdGVuZCB0byBhZ3JlZSB3aXRoIFRlZA0KPmNoYW5n aW5nIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBpbiBtb3N0IG9mIHRoZSBjYXNlIGltcGxpZXMgYSBk aWZmZXJlbnQgcGF0aA0KPihpLmUuIHNvbWUgb3IgYWxsIGRpZmZlcmVudCBtaWRkbGUtYm94ZXMg aW4gdGhlIHBhdGggdG93YXJkcyB0aGUgZGVzdGluYXRpb24pDQo+DQo+DQo+dXNpbmcgdGhlIHNv dXJjZSBzb2NrYWRkcl9pbiB3b3VsZCBtZWFuIGluc2VydGluZyB0aGUgYWN0dWFsIGlwIGFkZHJl c3MgaW4gU1BVRA0KPmFuZCB0aGVuIG1ha2luZyBlYXN5IGZvciB0aGUgcmVzdCBvZiB0aGUgcGF0 aCBmaWd1cmUgaXQgb3V0IHdoZW4geW91IGFyZSBiZWhpbmQgYSBOQVQNCg0KTm8sIEkgd2FzIGp1 c3Qgc3VnZ2VzdGluZyB0byB1c2UgdGhlIG9uZSByZXR1cm5lZCBmcm9tIHJlY3Zmcm9tLCBub3Qg dG8gYWRkIHRoZSBhZGRyZXNzIHRvIHRoZSBTUFVEIGhlYWRlci4NCg0KLS0gDQpKb2UgSGlsZGVi cmFuZA0KDQoNCg0K From nobody Wed Mar 4 10:21:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5F11AC3DC for ; Wed, 4 Mar 2015 10:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 IXEwVWqJsjk5 for ; Wed, 4 Mar 2015 10:21:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8873E1AC3D8 for ; Wed, 4 Mar 2015 10:21:00 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-06-54f74d0b186c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.AB.16191.B0D47F45; Wed, 4 Mar 2015 19:20:59 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.100]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 19:20:58 +0100 From: Salvatore Loreto To: "Joe Hildebrand (jhildebr) " Thread-Topic: Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) Thread-Index: AQHQVqf2Jpx4KDss3Eir7SriCb8NSw== Date: Wed, 4 Mar 2015 18:20:58 +0000 Message-ID: <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> In-Reply-To: <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/signed; boundary="Apple-Mail=_2022CA4B-8AF1-4DB0-9D43-76D129783C9A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+JvjS637/cQg6VNohZn9xxnt1h04Smj A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx8u1JtoIuw4oNV3+zNzD+1+ti5OSQEDCR ePvqCiuELSZx4d56ti5GLg4hgSOMEifeL2WEcBYzSvy9dpUFpIpNwEzi+cMtzCC2iICXxOx/ r8BsZgFliRkLdzGC2MICiRL/Zy9ihKhJk+h5soUJwtaTmHboAFg9i4CKxJENy8HivAL2Ep8e LoDavIRJ4se8W2DNnAIOEvMan4IVMQKd9/3UGiaIZeISt57MZ4I4W0Ti4cXTbBC2qMTLx/+g 3lGSWLH9EtgHzAJTGCUm3/zGCLFNUOLkzCcsExhFZyGZNQtZ3SwkdRBF2hLLFr5mnsXIAWTr SExeyAgRNpV4ffQjlG0tMePXQTYIW1FiSvdD9gWMHKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJS SzYxAqPx4JbfqjsYL79xPMQowMGoxMNrUPotRIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjOZtvKflZ/A1sS0pnniYsbM1mydiadyPa2bTpnL5zGOUet6n obP26zW9xwcPiuXOXdUXvmdGsLG0ev4B94Nia+u1vuZFPu3rOSHYwuxcEr9reYTLVk3Ox2LJ YVfnqRmdWLZfPD36ZcE5TpPlz062mhWyXtpwctFbBr8D8/r/224NPc/x2SNVVYmlOCPRUIu5 qDgRAMPa3zunAgAA Archived-At: Cc: "spud@ietf.org" Subject: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:21:03 -0000 --Apple-Mail=_2022CA4B-8AF1-4DB0-9D43-76D129783C9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, extensibility is mentioned in several part of the draft 02, however I am missing extensibility be listed in the requirements and = assumptions list in section 2. I would like SPUD would permit extension to provide additional info, but = at same time I would also have a clear explanation on the limitations, i.e. where = extensions are effective, when extension should be ignored etc. br Salvatore --Apple-Mail=_2022CA4B-8AF1-4DB0-9D43-76D129783C9A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtTCCBfcw ggPfoAMCAQICECdJad3aK1sYKvRZUYHGY2cwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMDkw NTI1WhcNMTcxMjAzMDkwNTI0WjBuMREwDwYDVQQKDAhFcmljc3NvbjEZMBcGA1UEAwwQU2FsdmF0 b3JlIExvcmV0bzEsMCoGCSqGSIb3DQEJARYdc2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20x EDAOBgNVBAUTB3RlaWxvc2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCNk8Iy/Fsn 7ymm3JY2s4AJQK4TRSjMVqkTUX8/F+gN6RGt5nNeFO3KBeYRWMAko4JCtz/u43G5HYm4zcXn8hdB ku94IV1rRPIUkP66ytoI1zu+fHm6w+1+IVBwKsBDi9PwaEwqTTuksTQYnZoTMkX+tJxzy7m0vjNi DGYDLC3RT/ymj52EIAH+QmkNqv/1Iw1RaJ8gMkreWxe7xgqrvqJ+m/p6GFpsQSbEVFYxz5vhh6xN BqPD0kBF0AhPyoWw7cIKFZ/SHkySNsrC2vbGmTtxX1GHo4M3oDl3KtO3AHG/sFnt9ZSkjUadMjEa I+/CryZVUjfEOJVkhhWftD/rW1vnAgMBAAGjggHDMIIBvzBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYyLmNlcjAoBgNVHREEITAfgR1zYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTBV BgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH AwIwHQYDVR0OBBYEFMdcgwlkDjoPNsC/O46GnDXzMZ98MB8GA1UdIwQYMBaAFLENytRGt6+GAsMv bwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAA6FcabbIFtthK+wT OgErOArRUJWvwOWTC5aGSrMxNjoEbojqib6j2Qh8v3g5glcP923Lbu1gL/NtyZnHUJV3C4ivSt+w XRUhOCLs4fwDTOiHMfkNpxx1FFEXsaLfSB9HeFWY+FrlDMh1xZHTcBsx940u1PBhfvWg/ogSZ/4Y 7gIb0RZkJ7P+JN3vHSpb0ubSAcQeHC3S2zFdrFMb+GfV2LG+A95NWsL/fxOjsMiVYXba8DVWif9l ads1P9BFoaK2gHcmaBViQVzhf8WMlZfOGiuk8fjVu3+d+8ub0bKuvl2jPo/dcCmo8cFonCb94cem XzbS6Sm0bsv456iCSHUAKUi7f+G+GRx4IpZFS45twCSQ7BNd0Y6WGDurLKFjqO5I+917FrR4sJ8o RQn/uKBY4C05aLs5uq7Qbpx+V4LeBCMiimbIeYXfxhsx1rr9icy8qwMSzYjxl2eHubcobwbo0TcO obrGGLQxVHUqn1YR/f2uFiVZiy4BF8OUPAUscTOPOx7u3LAlV/QT16/vQw3Xx1K+u67cxgRNKBhy qLgN5ZsZ/654CkP/Anw4JO9fr9cWrGul4TJodqGmIGVNjpmMlM1HOzR+UQDTjG8Yr1P1D091hLEH h9/XJZcCtdmv/wcAAtYJ7WLT9HdBlRO0PYbzqDvO9kwkKs83Q3xemdXLB1owgga2MIIEnqADAgEC AhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1 MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjq o3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1l l4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h 2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImb VWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZX VSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDE SYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBI L41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8T C1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh7 3CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0 MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29u ZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52 cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEA bgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHs MmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnf sYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XM tOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagB LnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1 lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0Ibbu ZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgd mLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HY NkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0x ggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMwNDE4MjA1OFowIwYJKoZIhvcN AQkEMRYEFEOy9MiaSMeoPO2Yp7bpv1X4WxzGMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICECdJad3aK1sY KvRZUYHGY2cwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMA0GCSqGSIb3 DQEBAQUABIIBADqpTRMbQ1HrN1Tr/53G22v37W34mD/Yxgvg/CHslOX2OsXpSCja7NarWj2wGS/M qXxyJFY0ave6UIldGLlQVIVdLL6h1HjDkfsrnEUnBJFZeVAPw3WxjzEcCKdd0wd/S22lS6Z46SdV UXdTJpFdjakPq7jQvxfYOtd5ZinDRKEZjW+5IYMYhj+zig6QtR3Xmy52Yvb0hLgSGGi87LNmMe2x vi4MQHrH8Nj7izZlpocxvPvAVhVM+Gok7edZjdskuCfkJp+WfjmVSz18DfMP/yWMzXNreBxSQ7PI lhi1cYj/ZC3XZdipzK/WeeEXASY280jZMaLsZiM3lD3/tNFT/x0AAAAAAAA= --Apple-Mail=_2022CA4B-8AF1-4DB0-9D43-76D129783C9A-- From nobody Thu Mar 5 08:56:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05681A037F for ; Thu, 5 Mar 2015 08:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 qvVIrB0Wjs00 for ; Thu, 5 Mar 2015 08:56:03 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B309E1A0065 for ; Thu, 5 Mar 2015 08:55:51 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-6a-54f88a95d540 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.1D.04410.59A88F45; Thu, 5 Mar 2015 17:55:50 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 17:55:49 +0100 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: Declarations: Authentication and encryption Thread-Index: AdBXY2MAP8c8eV5hRTutLmFxuvIZQg== Date: Thu, 5 Mar 2015 16:55:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23C9FBE5ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje60rh8hBtNaWCwWXXjK6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFPvHrEUHFOp+HJ7FlsD43H5LkZODgkBE4lvd3qYIGwxiQv3 1rN1MXJxCAkcYZRYvW4dK4SziFHi2aa/rCBVbAIWEg0rN7OB2CICyhJr7yxiB7GFgSatPfSG BSJuKXHm7QMoW0+i+UkjUC8HB4uAisTn13UgYV4BX4mbC3rBxjACLf5+ag3YEcwC4hK3nsyH OkhAYsme88wQtqjEy8f/WCFsRYmr05dD1edLrLg/mwVipqDEyZlPWCYwCs1CMmoWkrJZSMog 4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA mDi45bfqDsbLbxwPMQpwMCrx8Bbk/wgRYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVANjj11Pz9ROvRJ234KWR5lRuu8YWX+sPPUxvrrjYbGiKG/4Cu7Ize83 2rTeOxD03PSPwLN17T8Co9aYTJ0efixr5Z6vml+PGIqY/cp8KeYqf9/fo2j2iYbamxPMGjrZ Xa4rut4N2rXj7bone1xkKlkzJ3QnClaXN7z79aBegyFnm+W0e1KJJ58qsRRnJBpqMRcVJwIA a0mUoWoCAAA= Archived-At: Subject: [Spud] Declarations: Authentication and encryption X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:56:05 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23C9FBE5ESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am aware that security is not the main scope at the moment, but still I a= m interested about opinions about this. The principle of declarations is to "trust but verify". I think still authe= ntication can help this trust quite much. If the two points communicating h= ave some relationship or history and have a proof about their identity a mo= re "brave" trust can be the default behavior. Verification of declarations = can still happen. Also authentication can be verified by the middlebox, eve= n after choosing appropriate actions based on the content of the declaratio= ns so not delaying the flow and deceisons. The other thing is that I see the privacy of both endhosts and of middlebox= es important. Middleboxes might not want to allow others (e.g. other middle= boxes) to collect data about their answers as these are partly consequences= of business decisions. Endpoints might have similar concerns. Encryption c= an easily solve this. In summary what do you think about authentication and encryption of declara= tions? Cheers, Szilveszter --_000_EA4C43BE752A194597B002779DF69BAE23C9FBE5ESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am aware that security is not the main scope at th= e moment, but still I am interested about opinions about this.

 

The principle of declarations is to “trust but= verify”. I think still authentication can help this trust quite much= . If the two points communicating have some relationship or history and hav= e a proof about their identity a more “brave” trust can be the default behavior. Verification of declarations can still = happen. Also authentication can be verified by the middlebox, even after ch= oosing appropriate actions based on the content of the declarations so not = delaying the flow and deceisons.

 

The other thing is that I see the privacy of both en= dhosts and of middleboxes important. Middleboxes might not want to allow ot= hers (e.g. other middleboxes) to collect data about their answers as these = are partly consequences of business decisions. Endpoints might have similar concerns. Encryption can easily so= lve this.

 

In summary what do you think about authentication an= d encryption of declarations?

 

Cheers,

Szilveszter

--_000_EA4C43BE752A194597B002779DF69BAE23C9FBE5ESESSMB303erics_-- From nobody Thu Mar 5 09:06:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566111A1B71 for ; Thu, 5 Mar 2015 09:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 2_OsVQBR09PF for ; Thu, 5 Mar 2015 09:06:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DF11A6EE7 for ; Thu, 5 Mar 2015 09:04:25 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-9d-54f88c97e243 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.60.04032.79C88F45; Thu, 5 Mar 2015 18:04:24 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 18:04:23 +0100 From: Szilveszter Nadas To: "Joe Hildebrand (jhildebr)" , "spud@ietf.org" Thread-Topic: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVcrn/YYxcKCBL0m1gYXxY+ydN50LX98AgAK/IRA= Date: Thu, 5 Mar 2015 17:04:22 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6Mnh8hBr3dnBZn9xxnt1h04Smj A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxbqtEwU/hiiN/n7I2MD7m72Lk5JAQMJGY 9/cUC4QtJnHh3nq2LkYuDiGBI4wSO18eZoFwFjFKvP66jB2kik3AQqJh5WY2EFtEIFzi+f4j zCC2sECQxKF3s5gh4sESu3dcZ4ewrSReXFzI2sXIwcEioCKxdHsFiMkr4Ctx/Jw5iCkkUCLx e3okSDGngK3E4p/vmUBsRqBzvp9aA2YzC4hL3HoynwniTAGJJXvOM0PYohIvH/9jhbAVJa5O Xw5VryOxYPcnNghbW2LZwtdg9bwCghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OKk 3HQjI73Uoszk4uL8PL281JJNjMAIObjlt8EOxpfPHQ8xCnAwKvHwbjj2PUSINbGsuDL3EKM0 B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxqBi3KSpz9SS/rFCQ3Kqy0lnA6 bRGWGPtXYnPejZc32t61LLjvZa78sGtJtaG5kCj38h9W01mnBeSbsXQ8+yAgPVmkRmBPZEmo yMSlsi9a7/6/mX3l/uRfuU8euMsrbJ9mISb4Vr/vUcG9uUKtEueMg8s/VD89c7z+5HoZ1bxJ Cg+Wnzwfr6nEUpyRaKjFXFScCACAoLrgcQIAAA== Archived-At: Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:06:24 -0000 Hi, Some minor comments/questions. Section 5 and 6 "may contain CBOR" contradicts for me with "0 key MUST NOT = be used when the adec ot pdec bit is set" of Section 4.6. Or do you mean th= at adec=3D0 pdec=3D0 packets may also contain declarations?=20 Section 5: it is unclear for me what does "proof of implementation" mean. Section 10: "which may always have the following keys" - I assume that thi= s key is optional but it is often expected to be used. Or shall it always b= e used when responding to a specific path declarations. Cheers, Szilveszter -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Joe Hildebrand (jhil= debr) Sent: Tuesday, March 03, 2015 17:00 To: spud@ietf.org Subject: [Spud] FW: New Version Notification for draft-hildebrand-spud-prot= otype-02.txt New version. Note that the packet format has changed (again). Sorry about= that, but the good news is you should just have to delete some code. Nice= HTML version here: http://hildjj.github.io/draft-hildebrand-spud-prototype/ On 3/3/15, 4:58 PM, "internet-drafts@ietf.org" w= rote: > >A new version of I-D, draft-hildebrand-spud-prototype-02.txt >has been successfully submitted by Joe Hildebrand and posted to the=20 >IETF repository. > >Name: draft-hildebrand-spud-prototype >Revision: 02 >Title: Substrate Protocol for User Datagrams (SPUD) Prototype >Document date: 2015-03-03 >Group: Individual Submission >Pages: 14 >URL: http://www.ietf.org/internet-drafts/draft-hildebrand-spud-= prototype-02.txt >Status: https://datatracker.ietf.org/doc/draft-hildebrand-spud-pro= totype/ >Htmlized: http://tools.ietf.org/html/draft-hildebrand-spud-prototype= -02 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hildebrand-spud-p= rototype-02 > >Abstract: > SPUD is a prototype for grouping UDP packets together in a "tube", > also allowing network devices on the path between endpoints to > participate explicitly in the tube outside the end-to-end context. > > = =20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >The IETF Secretariat > > -- Joe Hildebrand _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Thu Mar 5 09:16:35 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357CF1A1BB8 for ; Thu, 5 Mar 2015 09:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 CkVi2LsDp216 for ; Thu, 5 Mar 2015 09:16:32 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031971A1BCE for ; Thu, 5 Mar 2015 09:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6865; q=dns/txt; s=iport; t=1425575512; x=1426785112; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dNQeNnGKpUfH3M4gdaooHAG8EjWLbQlh7yp35nacqyQ=; b=bzq99IiCQuQVTi1rCGmYupxgn+jG2ny6GbLsv2Grcxn7OYbuBM4h/uU5 d1a4lC6iQuwlwRVb/hXfOXANyEyLN19Mc6LpooZg+Qcspa7LVu/maRSk4 71+mNHwBDrEgp2Peyvs0bDRgmQck3S/lJXQKp40CsCY5cfbs/KKWY0Kqh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBwAXjfhU/51dJa1RCYJDQ1JaBL5+PIF6hXACgThNAQEBAQEBfIQPAQEBBC1FFwIBCBEEAQELHQcyFAkIAQEEARIIiCcN2BQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEEyo3AYMXgRQFkAeDY4c9khwjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208,217";a="129274581" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 05 Mar 2015 17:11:50 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t25HBotu004956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 17:11:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 11:11:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Szilveszter Nadas , "spud@ietf.org" Thread-Topic: Declarations: Authentication and encryption Thread-Index: AdBXY2MAP8c8eV5hRTutLmFxuvIZQgAAzXLA Date: Thu, 5 Mar 2015 17:11:49 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366AFBD3@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.245] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366AFBD3xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] Declarations: Authentication and encryption X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:16:34 -0000 --_000_913383AAA69FF945B8F946018B75898A366AFBD3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think authentication is important to prevent MIM from modifying the SPUD = packets. http://tools.ietf.org/html/draft-ietf-pcp-authentication-02 discus= ses authentication mechanism b/w the endpoint and PCP-aware firewall; the t= ransport key derived from authentication can be used to generate authentica= tion tag for the SPUD packet. -Tiru From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Szilveszter Nadas Sent: Thursday, March 05, 2015 10:26 PM To: spud@ietf.org Subject: [Spud] Declarations: Authentication and encryption Hi, I am aware that security is not the main scope at the moment, but still I a= m interested about opinions about this. The principle of declarations is to "trust but verify". I think still authe= ntication can help this trust quite much. If the two points communicating h= ave some relationship or history and have a proof about their identity a mo= re "brave" trust can be the default behavior. Verification of declarations = can still happen. Also authentication can be verified by the middlebox, eve= n after choosing appropriate actions based on the content of the declaratio= ns so not delaying the flow and deceisons. The other thing is that I see the privacy of both endhosts and of middlebox= es important. Middleboxes might not want to allow others (e.g. other middle= boxes) to collect data about their answers as these are partly consequences= of business decisions. Endpoints might have similar concerns. Encryption c= an easily solve this. In summary what do you think about authentication and encryption of declara= tions? Cheers, Szilveszter --_000_913383AAA69FF945B8F946018B75898A366AFBD3xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think authentication= is important to prevent MIM from modifying the SPUD packets. htt= p://tools.ietf.org/html/draft-ietf-pcp-authentication-02 discusses auth= entication mechanism b/w the endpoint and PCP-aware firewall; the transport= key derived from authentication can be used to generate authentication tag for the SPUD packet.

 

-Tiru

 

From: Spud [ma= ilto:spud-bounces@ietf.org] On Behalf Of Szilveszter Nadas
Sent: Thursday, March 05, 2015 10:26 PM
To: spud@ietf.org
Subject: [Spud] Declarations: Authentication and encryption

 

Hi,

 

I am aware that security is not the main scope at th= e moment, but still I am interested about opinions about this.

 

The principle of declarations is to “trust but= verify”. I think still authentication can help this trust quite much= . If the two points communicating have some relationship or history and hav= e a proof about their identity a more “brave” trust can be the default behavior. Verification of declarations can still = happen. Also authentication can be verified by the middlebox, even after ch= oosing appropriate actions based on the content of the declarations so not = delaying the flow and deceisons.

 

The other thing is that I see the privacy of both en= dhosts and of middleboxes important. Middleboxes might not want to allow ot= hers (e.g. other middleboxes) to collect data about their answers as these = are partly consequences of business decisions. Endpoints might have similar concerns. Encryption can easily so= lve this.

 

In summary what do you think about authentication an= d encryption of declarations?

 

Cheers,

Szilveszter

--_000_913383AAA69FF945B8F946018B75898A366AFBD3xmbrcdx10ciscoc_-- From nobody Thu Mar 5 12:18:58 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8865B1A8991 for ; Thu, 5 Mar 2015 12:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GfA3dPMUgn-8 for ; Thu, 5 Mar 2015 12:16:40 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D7A1A8949 for ; Thu, 5 Mar 2015 12:16:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 19029D930B; Thu, 5 Mar 2015 21:16:38 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U99BTOEF0g2l; Thu, 5 Mar 2015 21:16:37 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CEA3CD9305; Thu, 5 Mar 2015 21:16:37 +0100 (MET) Message-ID: <54F8B9A5.5000008@tik.ee.ethz.ch> Date: Thu, 05 Mar 2015 21:16:37 +0100 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Salvatore Loreto , "Joe Hildebrand (jhildebr) " References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> In-Reply-To: <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 12:18:47 -0800 Cc: "spud@ietf.org" Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:16:42 -0000 Hi Salvatore, in the slides we are currently preparing for the BoF we have three constraints listed: - Information exposure is declarative - All entities may trust but verify - Information must be incrementally useful (e.g. not all nodes might support spud) I think this narrows down the scope. I bet we will discuss this further in the BoF and therefore leave for now this as it is. Mirja On 04.03.2015 19:20, Salvatore Loreto wrote: > Hi Joe, > > extensibility is mentioned in several part of the draft 02, > however I am missing extensibility be listed in the requirements and assumptions list > in section 2. > > I would like SPUD would permit extension to provide additional info, but at same time > I would also have a clear explanation on the limitations, i.e. where extensions are effective, when extension > should be ignored etc. > > > br > Salvatore > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri Mar 6 01:45:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1491ACD41 for ; Fri, 6 Mar 2015 01:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ypu50SCxs0_s for ; Fri, 6 Mar 2015 01:45:52 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BD31ACD3D for ; Fri, 6 Mar 2015 01:45:51 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-41-54f9774da8a5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.E1.13725.D4779F45; Fri, 6 Mar 2015 10:45:49 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 10:45:48 +0100 From: Szilveszter Nadas To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Salvatore Loreto , "Joe Hildebrand (jhildebr) " Thread-Topic: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) Thread-Index: AQHQVqf7LkbhqrxUUECt4gIbIRb7a50ORH2AgADtuNA= Date: Fri, 6 Mar 2015 09:45:48 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> <54F8B9A5.5000008@tik.ee.ethz.ch> In-Reply-To: <54F8B9A5.5000008@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja5v+c8Qg0uHzC3O7jnObrFh9RQW i0UXnjI6MHtM+b2R1WPJkp9MHsc+fGULYI7isklJzcksSy3St0vgyrh98zljwQ2xijmTXRsY 9wl1MXJySAiYSMw6/IgJwhaTuHBvPVsXIxeHkMARRokHC75COYsYJSZ8fs0GUsUmYCHRsHIz WEJE4BijxNPLn5hBEswCyhIzFu5i7GLk4BAWyJH49FoMJCwikCtx9+g5JgjbSuLQ9ndg5SwC KhJPvzaygti8Ar4SN9vPQS37xyTR+uUz2DJOAT2JvzPugTUwAp33/dQaJohd4hK3nsyHOltA Ysme88wQtqjEy8f/WCFsRYmr05dD1etJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7Cwk LbOQtMxC0rKAkWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBUHdzyW3cH4+rXjocYBTgY lXh4DSR+hgixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHM 6NT+7cfd9/9e/myDtfeFhl8L/Lcyf12vE+14Q2DG3t+25ZFb96ak7+f7teKsw4x3s7v/T7mt OfdJ3TXBrQvKi16dVox4uc9M3Ozloqow+zL1dqYL07nPls+67t39L239S7Hd8U2v1xYXXGDO dN3O/tPl0nP3/yu3BxnwrDzSuGPKf6Pdf8/ZK7EUZyQaajEXFScCALxYaViLAgAA Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 09:45:54 -0000 Hi, I do not really see how these constraints contradicts extensibility. Also I= see a value in pre-discussion in mailing list. I tis not really important = for me whether any of the drafts is modified. It would be funny to ossify middlebox signaling with a protocol which is su= pposed to help in solving ossification for E2E communication. :) I think I = accept the constrains below, it would be very hard to incrementally deploy = SPUD otherwise.=20 A question related to this is in the back of my mind for a while. Shall SPU= D standardize the minimum amount of common/necessary signaling information = elements and allow any signaling solution, even proprietary, using SPUD to = reach the middleboxes? Or shall SPUD include most of the information elemen= ts needed? I am in favor of the first, because that allows innovation, thou= gh clearly interop is much more a hassle. (If you think about 5-tuple ICMP,= that is in fact an example of the first.) Also the first principle would h= elp focusing the scope of the WG more, which might be an advantage. Maybe e= ven signaling protocol design guidelines could be created similarly to the = proposed transport protocol design guidelines. Clearly the constraints belo= w do require a different thinking about how to design signaling protocols o= ver SPUD. Cheers, Szilveszter -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Mirja K=FChlewind Sent: Thursday, March 05, 2015 21:17 To: Salvatore Loreto; Joe Hildebrand (jhildebr) Cc: spud@ietf.org Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hi= ldebrand-spud-prototype-02.txt) Hi Salvatore, in the slides we are currently preparing for the BoF we have three constrai= nts listed: - Information exposure is declarative - All entities may trust but verify - Information must be incrementally useful (e.g. not all nodes might suppor= t spud) I think this narrows down the scope. I bet we will discuss this further in = the BoF and therefore leave for now this as it is. Mirja On 04.03.2015 19:20, Salvatore Loreto wrote: > Hi Joe, > > extensibility is mentioned in several part of the draft 02, however I=20 > am missing extensibility be listed in the requirements and assumptions=20 > list in section 2. > > I would like SPUD would permit extension to provide additional info,=20 > but at same time I would also have a clear explanation on the=20 > limitations, i.e. where extensions are effective, when extension should b= e ignored etc. > > > br > Salvatore > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Fri Mar 6 07:59:37 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C841A006F for ; Fri, 6 Mar 2015 07:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 YWSqQbvUjiQd for ; Fri, 6 Mar 2015 07:59:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208441A0023 for ; Fri, 6 Mar 2015 07:59:32 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-3e-54f9cee27390 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.7D.04032.2EEC9F45; Fri, 6 Mar 2015 16:59:31 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.70]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Fri, 6 Mar 2015 16:59:30 +0100 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: Middlebox to middlebox declarations in SPUD? Thread-Index: AdBYJoa+SD/vVT23T368fpODlbcb5g== Date: Fri, 6 Mar 2015 15:59:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23CA0A02ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7jcz9DDNZNZbdYdOEpowOjx5Il P5kCGKO4bFJSczLLUov07RK4Mrqm3mEqeKdSsfFlA2sD41H5LkZODgkBE4ldj6axQNhiEhfu rWfrYuTiEBI4wijRf+Q2K4SziFFi65x9zCBVbAIWEg0rN7OB2CICyhJr7yxiB7GFBUwlbj65 ygwRt5JoWQ1j60nMPLgeqIaDg0VARWLVAVGQMK+Ar8S8nefAxjACLf5+ag0TiM0sIC5x68l8 JoiDBCSW7DnPDGGLSrx8/I8VwlaS+LHhEgtEfb7E0oeXGSFmCkqcnPmEZQKj0Cwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3Z xAiMiYNbfhvsYHz53PEQowAHoxIPr4HEzxAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAyOqid7wl41mE06X/bQoVzVSf/Xe5PVhNpc+xw0noyz+xIvXmJ 14mehWpbrjzMSH5tPO8sa5BH/4yLJSbvD/A8+DbPbaZPqPxvRnbHNOerDf8fuYd03X2dPj1f 823Ki5wuv/ipT+at2h0dXc7dvXjGjeKMEzsk6pxaetIdzd83GaVk/j32xlmJpTgj0VCLuag4 EQC+Eti1agIAAA== Archived-At: Subject: [Spud] Middlebox to middlebox declarations in SPUD? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 15:59:35 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23CA0A02ESESSMB303erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, An option we came up with in one of the discussions is whether there are us= e cases for middlebox to middlebox communications in SPUD (or Path to Path = as in the Use Case doc terminology). At first glance it is hard to find a r= eason to use SPUD for this purpose, still it might be worth some thinking t= o not rule out this too fast. A related topic, which occurred to me is the separation of trust domains in= end-user devices. What if both the application and the user/OS would like = to communicate declarations? They might have different relations, intents a= nd authority. Shall the user be able to override app declarations or vice v= ersa? Shall both be able to make and receive declarations? Philosophically, we could look at the user/OS as a middlebox in this scenar= io. In that case some it is easier to find middlebox to middlebox use cases= . If this philosophy is applied it might also be easier to solve these ques= tions. (Of course there can be even more actors in the OS, like middleware, TP, Br= owser, App running in browser.) Cheers, Sz. --_000_EA4C43BE752A194597B002779DF69BAE23CA0A02ESESSMB303erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

An option we came up with in one of the discussions = is whether there are use cases for middlebox to middlebox communications in= SPUD (or Path to Path as in the Use Case doc terminology). At first glance= it is hard to find a reason to use SPUD for this purpose, still it might be worth some thinking to not rule o= ut this too fast.

 

 

A related topic, which occurred to me is the separat= ion of trust domains in end-user devices. What if both the application and = the user/OS would like to communicate declarations? They might have differe= nt relations, intents and authority. Shall the user be able to override app declarations or vice versa? Shall b= oth be able to make and receive declarations?  

 

Philosophically, we could look at the user/OS as a m= iddlebox in this scenario. In that case some it is easier to find middlebox= to middlebox use cases. If this philosophy is applied it might also be eas= ier to solve these questions.

 

(Of course there can be even more actors in the OS, = like middleware, TP, Browser, App running in browser.)

 

Cheers,

Sz.

--_000_EA4C43BE752A194597B002779DF69BAE23CA0A02ESESSMB303erics_-- From nobody Fri Mar 6 12:52:30 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85841A854D for ; Fri, 6 Mar 2015 12:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 S-FKoGF2pvj7 for ; Fri, 6 Mar 2015 12:52:28 -0800 (PST) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7464D1A6F12 for ; Fri, 6 Mar 2015 12:52:24 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8B1F73A026 for ; Fri, 6 Mar 2015 15:52:22 -0500 (EST) Received: by qgdq107 with SMTP id q107so15672530qgd.6 for ; Fri, 06 Mar 2015 12:52:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.236.211 with SMTP id h202mr22429440qhc.88.1425675142421; Fri, 06 Mar 2015 12:52:22 -0800 (PST) Received: by 10.140.104.115 with HTTP; Fri, 6 Mar 2015 12:52:22 -0800 (PST) In-Reply-To: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Fri, 6 Mar 2015 15:52:22 -0500 Message-ID: From: Patrick McManus To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11359dae6de2f80510a4dce6 Archived-At: Cc: "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:52:29 -0000 --001a11359dae6de2f80510a4dce6 Content-Type: text/plain; charset=UTF-8 First - Thanks Joe and Brian. I have a few margin notes to share :) Next, I may just be confused because I have read the text less than the authors at this point, but it seems as if unidirectional flows are off the table.. the text doesn't really say this, but the open-ack seems to imply it. There certainly are unidirectional udp flows but some clarification would help. Thirdly, is there advice given or implied for middleboxes that see data spud packets on opening tubes? The only thing I really see about the opening state is the diagram - but the diagram applies to the endpoint, not to the middlebox state, right? I'm concerned the text will read like there needs to be a full rtt handshake before data packets can flow on a spud tube and there are counter examples to things we would like to run on spud already. Fourthly, there are a couple "reserved bits MUST be zero".. should that be "senders MUST set to zero, receivers MUST ignore "? Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I think there are several cases where it would be nice if they didn't.. load balancers are a good example - a request is sent to a central service that parses it and dispatches it to the best back end server.. historically that server needs to lie about its address somehow when sending the reply (either via proxy or more likely via spoofing - and if spoofed you need to figure out the ack traffic). It would be cool to have that all in one tube with real addresses so the transport could decide how to deal with those issues. Sixthly, am I misreading the 8.2 MUST that SPUD enabled NATs need to share internal addressing info on the external side of the NAT? Is that really a MUST - some folks will be frothing at the mouth with the perceived information disclosure issues. Again, thanks for this. > --001a11359dae6de2f80510a4dce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First - Thanks Joe and Brian. I have a few margin notes to share :)
Next, I may just be confused because I have read the text less = than the authors at this point, but it seems as if unidirectional flows are= off the table.. the text doesn't really say this, but the open-ack see= ms to imply it. There certainly are unidirectional udp flows but some clari= fication would help.

Thirdly, is there advice give= n or implied for middleboxes that see data spud packets on opening tubes? T= he only thing I really see about the opening state is the diagram - but the= diagram applies to the endpoint, not to the middlebox state, right? I'= m concerned the text will read like there needs to be a full rtt handshake = before data packets can flow on a spud tube and there are counter examples = to things we would like to run on spud already.

Fo= urthly, there are a couple "reserved bits MUST be zero".. should = that be "senders MUST set to zero, receivers MUST ignore "?
=

Fifthly, on the topic of whether tube-ids need a consis= tent 5 tuple, I think there are several cases where it would be nice if the= y didn't.. =C2=A0load balancers are a good example - a request is sent = to a central service that parses it and dispatches it to the best back end = server.. historically that server needs to lie about its address somehow wh= en sending the reply (either via proxy or more likely via spoofing - and if= spoofed you need to figure out the ack traffic). It would be cool to have = that all in one tube with real addresses so the transport could decide how = to deal with those issues.

Sixthly, am I misreadin= g the 8.2 MUST that SPUD enabled NATs need to share internal addressing inf= o on the external side of the NAT? Is that really a MUST - some folks will = be frothing at the mouth with the perceived information disclosure issues.<= /div>

Again, thanks for this.

<= br>
--001a11359dae6de2f80510a4dce6-- From nobody Fri Mar 6 13:46:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255041A1A8B for ; Fri, 6 Mar 2015 13:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ABoonK7U4rdV for ; Fri, 6 Mar 2015 13:46:04 -0800 (PST) Received: from mail3.netlab.uky.edu (wonder.netlab.uky.edu [128.163.140.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42161A0100 for ; Fri, 6 Mar 2015 13:46:04 -0800 (PST) Received: from culp.local (cpe-96-29-241-159.swo.res.rr.com [96.29.241.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail3.netlab.uky.edu (Postfix) with ESMTPSA id 27AACC103; Fri, 6 Mar 2015 16:46:02 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_26640739-6728-4804-9279-A7983BA5890F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ken Calvert In-Reply-To: Date: Fri, 6 Mar 2015 16:46:00 -0500 Message-Id: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> To: Patrick McManus X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 21:46:06 -0000 --Apple-Mail=_26640739-6728-4804-9279-A7983BA5890F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Mar 2015, at 15:52, Patrick McManus wrote: > Next, I may just be confused because I have read the text less than = the authors at this point, but it seems as if unidirectional flows are = off the table.. the text doesn't really say this, but the open-ack seems = to imply it. There certainly are unidirectional udp flows but some = clarification would help. Actually, the state machine diagram - which I interpreted as applying at = ANY specific point along a path - doesn't (quite) imply the above, at = least as I interpret it. It seems to work fine for a middlebox that = only sees the initiator->responder side (i.e., the only side of a = unidirectional flow). Although in that case it looks like the initiator = doesn't get out of "resuming" state... > ... > Fourthly, there are a couple "reserved bits MUST be zero".. should = that be "senders MUST set to zero, receivers MUST ignore "? Along those lines, it seems the intent is that ONLY endpoints touch the = "command" bits, and that middleboxes MUST NOT modify them. (SHOULD NOT? = Are there non-nefarious use cases?) This should probably be made = explicit; I didn't see it anywhere, sorry if I missed it. Ken Calvert --Apple-Mail=_26640739-6728-4804-9279-A7983BA5890F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 6 Mar 2015, at 15:52, Patrick = McManus <mcmanus@ducksong.com> = wrote:

Next, I may just be confused because I have read the text = less than the authors at this point, but it seems as if unidirectional = flows are off the table.. the text doesn't really say this, but the = open-ack seems to imply it. There certainly are unidirectional udp flows = but some clarification would help.

Actually, = the state machine diagram - which I interpreted as applying at ANY = specific point along a path - doesn't (quite) imply the above, at least = as I interpret it.  It seems to work fine for a middlebox that only = sees the initiator->responder side (i.e., the only side of a = unidirectional flow).  Although in that case it looks like the = initiator doesn't get out of "resuming" = state...

...

Fourthly, there are a couple "reserved bits MUST be = zero".. should that be "senders MUST set to zero, receivers MUST ignore = "?

Along those lines, it seems the = intent is that ONLY endpoints touch the "command" bits, and that = middleboxes MUST NOT modify them.  (SHOULD NOT?  Are there = non-nefarious use cases?)  This should probably be made explicit; I = didn't see it anywhere, sorry if I missed = it.

Ken Calvert






= --Apple-Mail=_26640739-6728-4804-9279-A7983BA5890F-- From nobody Sat Mar 7 00:24:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14891A8A3B for ; Sat, 7 Mar 2015 00:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 LJkO8L-TVOWK for ; Sat, 7 Mar 2015 00:24:40 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9B81A8A10 for ; Sat, 7 Mar 2015 00:24:39 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-51-54fab5c5efba Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.57.07828.5C5BAF45; Sat, 7 Mar 2015 09:24:37 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.100]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Sat, 7 Mar 2015 09:24:35 +0100 From: Salvatore Loreto To: Patrick McManus Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQWLAk2iZBOt9V2Emc5in6z/Nk3g== Date: Sat, 7 Mar 2015 08:24:34 +0000 Message-ID: <01241E5D-C2DB-4A93-843E-B9EB13368E52@ericsson.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/signed; boundary="Apple-Mail=_FDA6FD00-29B8-4C17-A3CD-B18D5A9F4DA9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM+Jvje7Rrb9CDE6cEbQ4u+c4u8XL2WsY LRZdeMpo0TjXzoHFY8rvjaweO1vXMnrsnHWX3WPJkp9MASxRXDYpqTmZZalF+nYJXBnXJ01k KbhiVjF70nmWBsYtxl2MnBwSAiYSs04vZYWwxSQu3FvPBmILCRxhlDh7UxPCXswoseB5EIjN JmAm8fzhFmYQW0RAS2Jf0zP2LkYuDmaBPkaJ29uvM4EkhAUiJc58XMIEURQlcb3tAdBQDiBb T+L2vWCQMIuAisTEZbMZQcK8AvYSh0/bgIwREmhiklj0/ykjSA2nQKBE66n/YDYj0G3fT60B G8ksIC5x68l8JoibRSQeXjzNBmGLSrx8/A/qFyWJFdsvMULcNoVR4uKN8+wgCV4BQYmTM5+w TGAUnYVk1ixkdbOQ1EEUaUssW/iaGcLWlNjfvRwqbirx+uhHRgjbWmLGr4NsELaixJTuh+wL GDlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG68Etv612MB587niIUYCDUYmH9+PCXyFC rIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBkn/JuEWtwMkv+ /7AdTxkW9HWvfPPRfI5lsfZhX5VmG11r51d/xdkd5k1+FnZsxX7fgPvr4/7/2avySmZmb4Df ek+XDfVrTky67Lb4YOlTDplbfHfXubGvO/F/96VU278vtC9wJ6sWL3V7KRT8MC2189nFRNbZ M2Sab521OBb4vUD2eei+n5frlViKMxINtZiLihMB0kzwabgCAAA= Archived-At: Cc: Ted Hardie , "Joe Hildebrand \(jhildebr\) " , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 08:24:41 -0000 --Apple-Mail=_FDA6FD00-29B8-4C17-A3CD-B18D5A9F4DA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 06 Mar 2015, at 22:52, Patrick McManus = wrote: >=20 >=20 > Thirdly, is there advice given or implied for middleboxes that see = data spud packets on opening tubes? The only thing I really see about = the opening state is the diagram - but the diagram applies to the = endpoint, not to the middlebox state, right? I'm concerned the text will = read like there needs to be a full rtt handshake before data packets can = flow on a spud tube and there are counter examples to things we would = like to run on spud already. I agree on this point, I was going to send a similar comment It should be clear in the spec that the endpoint will be able to send = data right after having=20 sent the SPUD packet with the "open=E2=80=9Dcommand, without have to = wait a full rtt=20 (i.e. the end point should not be forced to wait for the creation = acknowledge of a tube to start sending data) actually it should be stretched to the point to make possible for the = end point to star sending data in the same message containing the SPUD packet with the =E2=80=9Copen=E2=80=9D command /Salvatore --Apple-Mail=_FDA6FD00-29B8-4C17-A3CD-B18D5A9F4DA9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtTCCBfcw ggPfoAMCAQICECdJad3aK1sYKvRZUYHGY2cwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMDkw NTI1WhcNMTcxMjAzMDkwNTI0WjBuMREwDwYDVQQKDAhFcmljc3NvbjEZMBcGA1UEAwwQU2FsdmF0 b3JlIExvcmV0bzEsMCoGCSqGSIb3DQEJARYdc2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20x EDAOBgNVBAUTB3RlaWxvc2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCNk8Iy/Fsn 7ymm3JY2s4AJQK4TRSjMVqkTUX8/F+gN6RGt5nNeFO3KBeYRWMAko4JCtz/u43G5HYm4zcXn8hdB ku94IV1rRPIUkP66ytoI1zu+fHm6w+1+IVBwKsBDi9PwaEwqTTuksTQYnZoTMkX+tJxzy7m0vjNi DGYDLC3RT/ymj52EIAH+QmkNqv/1Iw1RaJ8gMkreWxe7xgqrvqJ+m/p6GFpsQSbEVFYxz5vhh6xN BqPD0kBF0AhPyoWw7cIKFZ/SHkySNsrC2vbGmTtxX1GHo4M3oDl3KtO3AHG/sFnt9ZSkjUadMjEa I+/CryZVUjfEOJVkhhWftD/rW1vnAgMBAAGjggHDMIIBvzBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYyLmNlcjAoBgNVHREEITAfgR1zYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTBV BgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH AwIwHQYDVR0OBBYEFMdcgwlkDjoPNsC/O46GnDXzMZ98MB8GA1UdIwQYMBaAFLENytRGt6+GAsMv bwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAA6FcabbIFtthK+wT OgErOArRUJWvwOWTC5aGSrMxNjoEbojqib6j2Qh8v3g5glcP923Lbu1gL/NtyZnHUJV3C4ivSt+w XRUhOCLs4fwDTOiHMfkNpxx1FFEXsaLfSB9HeFWY+FrlDMh1xZHTcBsx940u1PBhfvWg/ogSZ/4Y 7gIb0RZkJ7P+JN3vHSpb0ubSAcQeHC3S2zFdrFMb+GfV2LG+A95NWsL/fxOjsMiVYXba8DVWif9l ads1P9BFoaK2gHcmaBViQVzhf8WMlZfOGiuk8fjVu3+d+8ub0bKuvl2jPo/dcCmo8cFonCb94cem XzbS6Sm0bsv456iCSHUAKUi7f+G+GRx4IpZFS45twCSQ7BNd0Y6WGDurLKFjqO5I+917FrR4sJ8o RQn/uKBY4C05aLs5uq7Qbpx+V4LeBCMiimbIeYXfxhsx1rr9icy8qwMSzYjxl2eHubcobwbo0TcO obrGGLQxVHUqn1YR/f2uFiVZiy4BF8OUPAUscTOPOx7u3LAlV/QT16/vQw3Xx1K+u67cxgRNKBhy qLgN5ZsZ/654CkP/Anw4JO9fr9cWrGul4TJodqGmIGVNjpmMlM1HOzR+UQDTjG8Yr1P1D091hLEH h9/XJZcCtdmv/wcAAtYJ7WLT9HdBlRO0PYbzqDvO9kwkKs83Q3xemdXLB1owgga2MIIEnqADAgEC AhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1 MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjq o3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1l l4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h 2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImb VWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZX VSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDE SYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBI L41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8T C1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh7 3CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0 MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29u ZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52 cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEA bgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHs MmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnf sYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XM tOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagB LnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1 lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0Ibbu ZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgd mLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HY NkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0x ggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMwNzA4MjQzNFowIwYJKoZIhvcN AQkEMRYEFP8yZtRSZn6lg5902nqJzuQgv6ZpMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICECdJad3aK1sY KvRZUYHGY2cwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhAnSWnd2itbGCr0WVGBxmNnMA0GCSqGSIb3 DQEBAQUABIIBAAXINMwC6g62xIjhBwgaaDrG4MMAMQfPy0C7PztevfyNJO5Qp+FApBSKTJ3vHNxw WTb7cIpmHwbK66L/B6rKL5D2rjIOzXUJm/vegiyPhQ+MjB7Tg9m0VIxwtk2OpBUjxSln2EbjC4Om /D+bXGCjkFsKVmhWeO/0O/L4IgfX95YBz0AqoY7KknZLJHhAsfcS/llnIdVpjhK3f8oxmXspU3kK DDSP6pZ70v2uq6tZrblibo0abmHXMKnb3n00BJ8MUFbYkNcJWXdWmE3ZyuOD6IABwqAbUgbqQtj+ AIcfFEYQgCByWEO37+Sx8q+q3guS6EswIFqMn58JV2wxl6zG4IsAAAAAAAA= --Apple-Mail=_FDA6FD00-29B8-4C17-A3CD-B18D5A9F4DA9-- From nobody Mon Mar 9 01:06:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054041A8035 for ; Mon, 9 Mar 2015 01:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Gt0D4yddI9kr for ; Mon, 9 Mar 2015 01:06:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3A61A6FF7 for ; Mon, 9 Mar 2015 01:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1425888369; x=1427097969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J9RAXFyE1wGJpWc8Vh56s0XMyUKWU6rRxQkKtPv6CAY=; b=C4m1VaWEaE0oZQ4IThGLYRS3Ux8Wjl/UqiZoDt5VNIulAoWSxHGGsvNA 2+SlOFJwqsrlLcr+dPdygiu2aRy0b8yTmOQHmUvoEREFLoGYv3uHld5tT qzQDsw8MIGxioJsH+vbCik0NlPIXntvIZ3FCDAq3KdTNkJBWHuiLWZl0I 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQBEVP1U/4gNJK1agwZSWgSDBr83CoVwAhyBC00BAQEBAQF8hA8BAQEDAQEBASAROgkCBQsCAQgYAgImAgICJQsVEAIEDgWIJwgNp0GbHAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGJdoRuB4JoL4EWAQSQD4lTgRqFfIxeI4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,366,1422921600"; d="scan'208";a="401945317" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2015 08:06:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t29868MA017901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 08:06:08 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 03:06:08 -0500 From: "Pal Martinsen (palmarti)" To: Salvatore Loreto Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQWLArUAx1J41uB0ODlSa3YIO5pJ0UIjuA Date: Mon, 9 Mar 2015 08:06:07 +0000 Message-ID: <4EB75551-2027-48AF-B0B8-25B89D72098A@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <01241E5D-C2DB-4A93-843E-B9EB13368E52@ericsson.com> In-Reply-To: <01241E5D-C2DB-4A93-843E-B9EB13368E52@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.160.223] Content-Type: text/plain; charset="utf-8" Content-ID: <1558B5915F3CD14492B9FF1EE195A8E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Patrick McManus , Ted Hardie , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 08:06:12 -0000 DQo+IE9uIDA3IE1hciAyMDE1LCBhdCAwOToyNCwgU2FsdmF0b3JlIExvcmV0byA8c2FsdmF0b3Jl LmxvcmV0b0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gDQo+PiBPbiAwNiBNYXIgMjAxNSwg YXQgMjI6NTIsIFBhdHJpY2sgTWNNYW51cyA8bWNtYW51c0BkdWNrc29uZy5jb20+IHdyb3RlOg0K Pj4gDQo+PiANCj4+IFRoaXJkbHksIGlzIHRoZXJlIGFkdmljZSBnaXZlbiBvciBpbXBsaWVkIGZv ciBtaWRkbGVib3hlcyB0aGF0IHNlZSBkYXRhIHNwdWQgcGFja2V0cyBvbiBvcGVuaW5nIHR1YmVz PyBUaGUgb25seSB0aGluZyBJIHJlYWxseSBzZWUgYWJvdXQgdGhlIG9wZW5pbmcgc3RhdGUgaXMg dGhlIGRpYWdyYW0gLSBidXQgdGhlIGRpYWdyYW0gYXBwbGllcyB0byB0aGUgZW5kcG9pbnQsIG5v dCB0byB0aGUgbWlkZGxlYm94IHN0YXRlLCByaWdodD8gSSdtIGNvbmNlcm5lZCB0aGUgdGV4dCB3 aWxsIHJlYWQgbGlrZSB0aGVyZSBuZWVkcyB0byBiZSBhIGZ1bGwgcnR0IGhhbmRzaGFrZSBiZWZv cmUgZGF0YSBwYWNrZXRzIGNhbiBmbG93IG9uIGEgc3B1ZCB0dWJlIGFuZCB0aGVyZSBhcmUgY291 bnRlciBleGFtcGxlcyB0byB0aGluZ3Mgd2Ugd291bGQgbGlrZSB0byBydW4gb24gc3B1ZCBhbHJl YWR5Lg0KPiANCj4gSSBhZ3JlZSBvbiB0aGlzIHBvaW50LCBJIHdhcyBnb2luZyB0byBzZW5kIGEg c2ltaWxhciBjb21tZW50DQo+IA0KPiBJdCBzaG91bGQgYmUgY2xlYXIgaW4gdGhlIHNwZWMgdGhh dCB0aGUgZW5kcG9pbnQgd2lsbCBiZSBhYmxlIHRvIHNlbmQgZGF0YSByaWdodCBhZnRlciBoYXZp bmcgDQo+IHNlbnQgdGhlIFNQVUQgcGFja2V0IHdpdGggdGhlICJvcGVu4oCdY29tbWFuZCwgd2l0 aG91dCBoYXZlIHRvIHdhaXQgYSBmdWxsIHJ0dCANCj4gKGkuZS4gdGhlIGVuZCBwb2ludCBzaG91 bGQgbm90IGJlIGZvcmNlZCB0byB3YWl0IGZvciB0aGUgY3JlYXRpb24gYWNrbm93bGVkZ2Ugb2Yg YSB0dWJlIHRvIHN0YXJ0IHNlbmRpbmcgZGF0YSkNCj4gDQo+IGFjdHVhbGx5IGl0IHNob3VsZCBi ZSBzdHJldGNoZWQgdG8gdGhlIHBvaW50IHRvIG1ha2UgcG9zc2libGUgZm9yIHRoZSBlbmQgcG9p bnQgdG8gc3RhciBzZW5kaW5nIGRhdGEgaW4gdGhlIHNhbWUgbWVzc2FnZSBjb250YWluaW5nIHRo ZQ0KPiBTUFVEIHBhY2tldCB3aXRoIHRoZSDigJxvcGVu4oCdIGNvbW1hbmQNCj4gDQoNCkNsaWVu dHMgdXNpbmcgSUNFIHRvIG9wZW4gdXAgTkFUL0ZXIHBpbmhvbGVzIGNhbiBwcm9iYWJseSBkbyBz b21lIHNtYXJ0IHRoaW5ncyB3aXRoIHRoZSBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MgYXMgd2Vs bC4gVGhpcyB3b3VsZCBhbGxvdyBmb3IgYW5kIGVuZHBvaW50cyB0byBjaGVjayB0aGUgYXZhaWxh YmxlIG5ldHdvcmsgcGF0aHMgYW5kIGNob29zZSB0aGUgb25lIHRoYXQgc3VwcG9ydHMgU1BVRC4N Cg0KSSBoYXZlIGEgZmVlbGluZyB0aGF0IElDRS9TVFVOIGFuZCBTUFVEIHdpbGwgYmUgc29tZXdo YXQgaW50ZXJtaW5nbGVkIGZvciBiaS1kaXJlY3Rpb25hbCBVRFAgc3RyZWFtcyBsaWtlIGludGVy YWN0aXZlIHZpZGVvICh3ZWJSVEMpLiBQcm9iYWJseSBhIGJpdCBwcmVtYXR1cmUgdG8gaGF2ZSB0 aGlzIGRpc2N1c3Npb24uDQoNCi4tLg0KUMOlbC1FcmlrDQoNCj4gL1NhbHZhdG9yZQ0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3B1ZCBt YWlsaW5nIGxpc3QNCj4gU3B1ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwdWQNCg0K From nobody Mon Mar 9 09:39:41 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ADE1A8A64 for ; Mon, 9 Mar 2015 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 f2CEHiWVr3Lf for ; Mon, 9 Mar 2015 09:39:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37ADD1A909B for ; Mon, 9 Mar 2015 09:38:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D43ADD9309 for ; Mon, 9 Mar 2015 17:38:56 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sAC+ZU6eAh2h for ; Mon, 9 Mar 2015 17:38:56 +0100 (MET) Received: from mirjas-air.fritz.box (stgt-5f71ac98.pool.mediaWays.net [95.113.172.152]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9EF7FD9302 for ; Mon, 9 Mar 2015 17:38:56 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 9 Mar 2015 17:38:56 +0100 To: spud@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Spud] Draft agenda for BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:39:40 -0000 Hi all, we uploaded a draft agenda for the BoF: http://www.ietf.org/proceedings/92/agenda/agenda-92-spud Eliot & Mirja From nobody Mon Mar 9 10:24:37 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE41A90E1 for ; Mon, 9 Mar 2015 10:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 oJ4OHiZMZgXk for ; Mon, 9 Mar 2015 10:24:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A861A90D8 for ; Mon, 9 Mar 2015 10:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4060; q=dns/txt; s=iport; t=1425921863; x=1427131463; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DS4hIcJBp1lMFJxjpC3R+EAVXHTQ/Td8oqEqGPnV+qg=; b=dDWC1ymIWR8R9bWxGLYqWLgUaBlsOH/TC8DjEw9FoW4i63DDQShnL2YA hAWA/r2XpmjU2U31RsBKhsva3ns23cH8tvSoskVr/Ix3fkWrlMqGeeGXW bHtwZFrgyn9QpHoIeVV/SrttFyH9B3l5p8580pBSlURnF0BTlPAAfHAWs Q=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBACR1v1U/xbLJq1bg1hagwq/WQEJhXACgXcBAQEBAQF8hBABAQQBAQEgSwoRCwQUCRYLAgIJAwIBAgEVMAYBDAYCAQEFiCYNpUSbNgEBAQEBAQEBAQEBAQEBAQEBAQEZixeEdYJogUUFkXSBLoZAgRqDKIIzjH8jg289MYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="asc'?scan'208,217";a="385396513" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Mar 2015 17:24:21 +0000 Received: from [10.61.108.1] (dhcp-10-61-108-1.cisco.com [10.61.108.1]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t29HOKfx026349; Mon, 9 Mar 2015 17:24:20 GMT Message-ID: <54FDD743.7070204@cisco.com> Date: Mon, 09 Mar 2015 18:24:19 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , spud@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vfEtBxOAKaxBgeLIlw0btHF1ChClnN17L" Archived-At: Subject: Re: [Spud] Draft agenda for BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:24:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vfEtBxOAKaxBgeLIlw0btHF1ChClnN17L Content-Type: multipart/alternative; boundary="------------020504080901020706040303" This is a multi-part message in MIME format. --------------020504080901020706040303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, Please now take a look at the agenda. During the session we are planning to ask a few questions. The chairs think that the following questions are good starting points: * What are the capabilities that we need and don=E2=80=99t have today; = and why do we need them? * Are use cases well understood and relevant? * Are there sufficient deployment incentives on endpoints? In the netwo= rk? * Should this be a UDP-based approach? * What are the next steps? What other questions are important to think about during the BoF and address at the end of the BoF? Eliot On 3/9/15 5:38 PM, Mirja K=C3=BChlewind wrote: > Hi all, > > we uploaded a draft agenda for the BoF: > > http://www.ietf.org/proceedings/92/agenda/agenda-92-spud > > Eliot & Mirja > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --------------020504080901020706040303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

Please now take a look at the agenda.=C2=A0 During the session we are= planning to ask a few questions.=C2=A0 The chairs think that the following questions are good starting points:

  • What are the capabilities that we need and don=E2=80=99t have t= oday; and why do we need them?
  • Are use cases well understood and relevant?
  • Are there sufficient deployment incentives on endpoints? In the network?
  • Should this be a UDP-based approach?
  • What are the next steps?

What other questions are important to think about during the BoF and address at the end of the BoF?

Eliot



On 3/9/15 5:38 PM, Mirja K=C3=BChlewin= d wrote:
Hi all,

we uploaded a draft agenda for the BoF:

http://www.ietf.org/proceedings/92/agenda/age=
nda-92-spud

Eliot & Mirja

_______________________________________________
Spud mailing list
Spud@=
ietf.org
https://www.ietf.org/mailman/listinfo/spud

--------------020504080901020706040303-- --vfEtBxOAKaxBgeLIlw0btHF1ChClnN17L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU/ddDAAoJEIe2a0bZ0nozbM4IALHhBchHoIT6kY1JzuJBPm5a 7BZP1gtHD+Z1thXa87RrvU7fLAmLi8JVYhMZWt51uwb+tYlX9Piw3pIXT8sZ2yvL HUq9cojEcCcCy7zDI2nkSpoDrbSG/yFEOLskeuU5JaL5bcZ7e19BHZNDz2mddTn+ VGUah6tZtr5a6xcKERmA9wsyXe2tb9uAG++q79x1EsGXsZrXmR22OV77QL1Pc4my mz+1UN1QRWZMDxba3MJpjLFZUdOMqiD8Me7vDN4Zfpwu/HfLEl1/XZF1TwBxN66p /Df8KTR2UWIvk7y7OR5GHMpdOe+qwKPWX351y6m86PEj4uXc+qZW7SqhQsz4BAA= =Q1Ad -----END PGP SIGNATURE----- --vfEtBxOAKaxBgeLIlw0btHF1ChClnN17L-- From nobody Mon Mar 9 12:29:22 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF92E1A87BC for ; Mon, 9 Mar 2015 12:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 e0uRbiltRxPA for ; Mon, 9 Mar 2015 12:29:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC2B1A00FB for ; Mon, 9 Mar 2015 12:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1868; q=dns/txt; s=iport; t=1425929353; x=1427138953; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+ubUNF3UlVPbr5jeVLvzs7hW7m5O6Y81dwWmsmQjwsY=; b=SYnSCVHgjAW7mMv69wttiyR5oitNPD8T5FT+Uidq9DQonj+yraqtjzAD QWqwivQ4ZaddTrkpULnkUA06zPAaY6FxtwHyPUkq7DVzO0ilLJGpc3vyS CHsuDF66XGeurhoHl1OyGcOh3mVc0fNQSMfNAB9aIggwMKH55aEVr8glU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJDQCi8/1U/4QNJK1cgwZSWgSDBr0uiCYCHIEPTQEBAQEBAXyEEAEBBCMRQxICAQgaAiYCAgIwFRACBAESiC+mSJtCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaEdQSCZC+BFgEEkA+JU5N0I4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="402142830" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 09 Mar 2015 19:29:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29JTCpl004691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:29:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:29:12 -0500 From: "Joe Hildebrand (jhildebr)" To: Szilveszter Nadas , "spud@ietf.org" Thread-Topic: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQVcrn/YYxcKCBL0m1gYXxY+ydN50LX98AgAK/IRCABmNJgA== Date: Mon, 9 Mar 2015 19:29:12 +0000 Message-ID: <92A93DA7-4682-497D-B641-807B0438EDA9@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <68437E86D9E72C48B8EB6CD30DB06389@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:29:21 -0000 T24gMy81LzE1LCAxMDowNCBBTSwgIlN6aWx2ZXN6dGVyIE5hZGFzIiA8U3ppbHZlc3p0ZXIuTmFk YXNAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPlNvbWUgbWlub3IgY29tbWVudHMv cXVlc3Rpb25zLg0KPg0KPlNlY3Rpb24gNSBhbmQgNiAibWF5IGNvbnRhaW4gQ0JPUiIgY29udHJh ZGljdHMgZm9yIG1lIHdpdGggIjAga2V5IE1VU1QgTk9UIGJlIHVzZWQgd2hlbiB0aGUgYWRlYyBv dCBwZGVjIGJpdCBpcyBzZXQiIG9mIFNlY3Rpb24gNC42LiBPciBkbyB5b3UgbWVhbiB0aGF0IGFk ZWM9MCBwZGVjPTAgcGFja2V0cyBtYXkgYWxzbyBjb250YWluIGRlY2xhcmF0aW9ucz8NCg0KSSB3 YXMgdGhpbmtpbmcgYWJvdXQgZW5kLXRvLWVuZCB0aGluZ3MgZm9yIHRoZSBub24tMCBrZXlzIGlu IGFuIG9wZW4gcGFja2V0LiBhMHAwIHBhY2tldHMgbWF5IGNvbnRhaW4gbm9uLTAga2V5cywgYnV0 IEknbSBub3QgdGhpbmtpbmcgb2YgdGhvc2UgYXMgZGVjbGFyYXRpb25zLiAgV2UnbGwgZmluZCBv dXQgbW9yZSBhcyB3ZSBwcm90b3R5cGUgYSByZWFsIHRyYW5zcG9ydCBvbiB0b3Agb2YgU1BVRC4N Cg0KSSBzdWdnZXN0IHdlIGxlYXZlIGl0IGludGVudGlvbmFsbHkgdmFndWUgZm9yIHRoZSBtb21l bnQuDQoNCj5TZWN0aW9uIDU6IGl0IGlzIHVuY2xlYXIgZm9yIG1lIHdoYXQgZG9lcyAicHJvb2Yg b2YgaW1wbGVtZW50YXRpb24iIG1lYW4uIA0KDQplLmcuIHdlYnNvY2tldHMgKFJGQyA2NDU1LCBz ZWN0aW9uIDEuMykuICBUaGUgY2xpZW50IHByb3ZpZGVzIGEgbm9uY2UuICBUaGUgc2VydmVyIGRv ZXMgc29tZSBjYWxjdWxhdGlvbiB0aGF0IHByb3ZlcyB3aXRoIGhpZ2hlciBjb25maWRlbmNlIHRo YW4gdGhlIG1hZ2ljIG51bWJlciBwcm92aWRlZCB0aGF0IGl0IGlzIHNwZWFraW5nIFNQVUQsIHNl bmRpbmcgdGhlIHJlc3VsdCBpbiB0aGUgYWNrIHBhY2tldC4NCg0KPlNlY3Rpb24gMTA6ICJ3aGlj aCBtYXkgYWx3YXlzIGhhdmUgdGhlIGZvbGxvd2luZyBrZXlzIiAgLSBJIGFzc3VtZSB0aGF0IHRo aXMga2V5IGlzIG9wdGlvbmFsIGJ1dCBpdCBpcyBvZnRlbiBleHBlY3RlZCB0byBiZSB1c2VkLiBP ciBzaGFsbCBpdCBhbHdheXMgYmUgdXNlZCB3aGVuIHJlc3BvbmRpbmcgdG8gYSBzcGVjaWZpYyBw YXRoIGRlY2xhcmF0aW9ucy4NCg0KUHJvYmFibHkgb25seSB3aGVuIHJlc3BvbmRpbmcgdG8gYSBz cGVjaWZpYyBwYXRoIGRlY2xhcmF0aW9uLiAgSSdtIGdvaW5nIHRvIGNoYW5nZSB0aGUgbmFtZSB0 byAibWlkcG9pbnQgdG9rZW4iIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGlzIGlzIG5vdCBhIGNv b2tpZSBpbiB0aGUgSFRUUCBzZW5zZS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Mon Mar 9 12:35:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB09B1A90B4 for ; Mon, 9 Mar 2015 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PQJ7lHgYuwgr for ; Mon, 9 Mar 2015 12:35:36 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001611A8AAA for ; Mon, 9 Mar 2015 12:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1804; q=dns/txt; s=iport; t=1425929735; x=1427139335; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=6gvrFUmopdA/aSuMfiolJyXUJETkcqM6POgCMmd2zBc=; b=Pfoduy8QOg+c3pHsgD6nqlZBd1BqgBwnBnxbt2F3MOB8k6i/q7lG2aDz /cQ/SlDk3Gez2+cKelmhEIlluOgzguDzYUuvAebQov6/zAo8fxbEThm+Z QroVfjIWrJ5Bl8SBrBFZl/ifL7Twf/5RegWhMeAsGjC7X7FtHblDSwcLH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADDQBI9f1U/5FdJa1TCYMGgSwEgwa9L4gmHoEPTQEBAQEBAXyEEAIEIxE+GQEIGgImAgQwFRIEARKIL6ZFm0IBAQEBAQEEAQEBAQEBAQEBARiBIYl2hBMoPoJkL4EWBZAPiVOTdCODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="130276165" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 09 Mar 2015 19:35:35 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t29JZZkX009585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:35:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:35:35 -0500 From: "Joe Hildebrand (jhildebr)" To: Szilveszter Nadas , "spud@ietf.org" Thread-Topic: [Spud] Declarations: Authentication and encryption Thread-Index: AQHQWqA2V9QWJmy3s0SAx6WfN0EAWA== Date: Mon, 9 Mar 2015 19:35:34 +0000 Message-ID: <9AD8B373-E033-4421-A06D-15C0589EE5F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] Declarations: Authentication and encryption X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:35:38 -0000 T24gMy81LzE1LCA5OjU1IEFNLCAiU3ppbHZlc3p0ZXIgTmFkYXMiIDxTemlsdmVzenRlci5OYWRh c0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+SGksDQo+IA0KPkkgYW0gYXdhcmUgdGhhdCBzZWN1 cml0eSBpcyBub3QgdGhlIG1haW4gc2NvcGUgYXQgdGhlIG1vbWVudCwgYnV0IHN0aWxsIEkgYW0g aW50ZXJlc3RlZCBhYm91dCBvcGluaW9ucyBhYm91dCB0aGlzLg0KPiANCj5UaGUgcHJpbmNpcGxl IG9mIGRlY2xhcmF0aW9ucyBpcyB0byDigJx0cnVzdCBidXQgdmVyaWZ54oCdLiBJIHRoaW5rIHN0 aWxsIGF1dGhlbnRpY2F0aW9uIGNhbiBoZWxwIHRoaXMgdHJ1c3QgcXVpdGUgbXVjaC4gSWYgdGhl IHR3byBwb2ludHMgY29tbXVuaWNhdGluZyBoYXZlIHNvbWUgcmVsYXRpb25zaGlwIG9yIGhpc3Rv cnkgYW5kIGhhdmUgYSBwcm9vZiBhYm91dCB0aGVpciBpZGVudGl0eSBhIG1vcmUg4oCcYnJhdmXi gJ0NCj4gdHJ1c3QgY2FuIGJlIHRoZSBkZWZhdWx0IGJlaGF2aW9yLiBWZXJpZmljYXRpb24gb2Yg ZGVjbGFyYXRpb25zIGNhbiBzdGlsbCBoYXBwZW4uIEFsc28gYXV0aGVudGljYXRpb24gY2FuIGJl IHZlcmlmaWVkIGJ5IHRoZSBtaWRkbGVib3gsIGV2ZW4gYWZ0ZXIgY2hvb3NpbmcgYXBwcm9wcmlh dGUgYWN0aW9ucyBiYXNlZCBvbiB0aGUgY29udGVudCBvZiB0aGUgZGVjbGFyYXRpb25zIHNvIG5v dCBkZWxheWluZyB0aGUgZmxvdyBhbmQgZGVjZWlzb25zLg0KPiANCj5UaGUgb3RoZXIgdGhpbmcg aXMgdGhhdCBJIHNlZSB0aGUgcHJpdmFjeSBvZiBib3RoIGVuZGhvc3RzIGFuZCBvZiBtaWRkbGVi b3hlcyBpbXBvcnRhbnQuIE1pZGRsZWJveGVzIG1pZ2h0IG5vdCB3YW50IHRvIGFsbG93IG90aGVy cyAoZS5nLiBvdGhlciBtaWRkbGVib3hlcykgdG8gY29sbGVjdCBkYXRhIGFib3V0IHRoZWlyIGFu c3dlcnMgYXMgdGhlc2UgYXJlIHBhcnRseSBjb25zZXF1ZW5jZXMgb2YgYnVzaW5lc3MNCj4gZGVj aXNpb25zLiBFbmRwb2ludHMgbWlnaHQgaGF2ZSBzaW1pbGFyIGNvbmNlcm5zLiBFbmNyeXB0aW9u IGNhbiBlYXNpbHkgc29sdmUgdGhpcy4NCj4NCj4gDQo+SW4gc3VtbWFyeSB3aGF0IGRvIHlvdSB0 aGluayBhYm91dCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBvZiBkZWNsYXJhdGlvbnM/ DQoNCkkgaW1hZ2luZSBlbmRwb2ludHMgbmVnb3RpYXRpbmcgdGhlaXIgb3duIHRyYW5zcG9ydCBs YXllcnMgYW5kIHNlY3VyaXR5IGNvbnRleHRzIHdpdGggbWlkcG9pbnRzLCB1c2luZyB0aGUgdG9r ZW4gbWVjaGFuaXNtIGFzIGEgc3ViLWFkZHJlc3MuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K DQoNCg== From nobody Mon Mar 9 12:42:17 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E447E1A8982 for ; Mon, 9 Mar 2015 12:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Ih130amEWjMP for ; Mon, 9 Mar 2015 12:42:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7928C1A0072 for ; Mon, 9 Mar 2015 12:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1388; q=dns/txt; s=iport; t=1425930134; x=1427139734; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DtwYj8WKStwnni+S0PPK+s+ZF+ZPO57v0BCa3yAK4qw=; b=O/5hYtvIAn4bQqedI0v2SE9ccN9bLRDfBTaVz0JyX9OqAb3Isqz7xuaJ 18GAcg17iYxDwiqJQBipSvdyLjFR6ZR+YtzJY5/AwnrjVM9N/JoEDp+i6 /EFbflj3dNsfX+2/Mftl0THEPJIqvQL709fhvqPJfzeH5V1wOJxnKJDD7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHDQDC9v1U/5BdJa1cgwaBLASDBr0viCYCHIEPTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICMBUQAgQOBYgvpk2bRAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hDszB4JoL4EWAQSQD4lTk3QjgjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="399021202" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 09 Mar 2015 19:42:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t29JgDcI017965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:42:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:42:13 -0500 From: "Joe Hildebrand (jhildebr)" To: Salvatore Loreto Thread-Topic: Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) Thread-Index: AQHQVqf4JQjwNdJnsku/AoeBVLSQCp0UhDIA Date: Mon, 9 Mar 2015 19:42:13 +0000 Message-ID: <0072EAE8-8DF8-4811-8FB5-A4B2476D4F45@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> In-Reply-To: <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:42:16 -0000 T24gMy80LzE1LCAxMToyMCBBTSwgIlNhbHZhdG9yZSBMb3JldG8iIDxzYWx2YXRvcmUubG9yZXRv QGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj5IaSBKb2UsDQo+DQo+ZXh0ZW5zaWJpbGl0eSBpcyBt ZW50aW9uZWQgaW4gc2V2ZXJhbCBwYXJ0IG9mIHRoZSBkcmFmdCAwMiwNCj5ob3dldmVyIEkgYW0g bWlzc2luZyBleHRlbnNpYmlsaXR5IGJlIGxpc3RlZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGFuZCBh c3N1bXB0aW9ucyBsaXN0DQo+aW4gc2VjdGlvbiAyLg0KDQpJIGp1c3QgYWRkZWQ6IA0KDQoiLSBT UFVEIG11c3QgZW5hYmxlIG11bHRpcGxlIG5ldyB0cmFuc3BvcnQgc2VtYW50aWNzIHdpdGhvdXQg cmVxdWlyaW5nIHVwZGF0ZXMNCiAgdG8gU1BVRCBpbXBsZW1lbnRhdGlvbnMgaW4gbWlkZGxlYm94 ZXMuIg0KDQpJIHRoaW5rIHRoYXQgY2FwdHVyZXMgdGhlIG1vc3QgaW1wb3J0YW50IG9mIHRoZSBl eHRlbnNpYmlsaXR5IGRpcmVjdGlvbnMuICBXZSBjYW4gZWRpdCB0aGlzIHJlcXVpcmVtZW50IGdv aW5nIGZvcndhcmQgdG8gY2FwdHVyZSBvdGhlciBheGVzIG9mIGV4dGVuc2liaWxpdHkuDQoNCj5J IHdvdWxkIGxpa2UgU1BVRCB3b3VsZCBwZXJtaXQgZXh0ZW5zaW9uIHRvIHByb3ZpZGUgYWRkaXRp b25hbCBpbmZvLCBidXQgYXQgc2FtZSB0aW1lDQo+SSB3b3VsZCBhbHNvIGhhdmUgYSBjbGVhciBl eHBsYW5hdGlvbiBvbiB0aGUgbGltaXRhdGlvbnMsIGkuZS4gd2hlcmUgZXh0ZW5zaW9ucyBhcmUg ZWZmZWN0aXZlLCB3aGVuIGV4dGVuc2lvbg0KPnNob3VsZCBiZSBpZ25vcmVkIGV0Yy4NCg0KIk11 c3QgaWdub3JlIChhbmQgcGFzcyBhbG9uZyB1bmNoYW5nZWQpIHdoYXQgeW91IGRvbid0IHVuZGVy c3RhbmQiIGlzIGdvaW5nIHRvIGJlIG9uZSBvZiB0aGUgbW9zdCBwb3dlcmZ1bCBhZ2VudHMgb2Yg Y2hhbmdlIHdlIGhhdmUgYXQgb3VyIGRpc3Bvc2FsLiAgTGV0J3MgbWFrZSBzdXJlIGl0J3Mgd2Vs bC11bmRlcnN0b29kLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon Mar 9 14:27:17 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED951A9172 for ; Mon, 9 Mar 2015 14:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YJVNoqqL8Sg5 for ; Mon, 9 Mar 2015 14:27:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DCE1A8BB6 for ; Mon, 9 Mar 2015 14:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=990; q=dns/txt; s=iport; t=1425936430; x=1427146030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hrs9Z+XfRPGQ1Hs0MkAoWoz/0zZlFh/XghhrD4HGXb8=; b=Ae5lifTqukOV8r7PkfZrwMHrY17OOJtQNZdiSnJwl5FZqnNj971WkAQe jUKp41iSQyVZrIJoioZa+XXOksf0eiD1yCx8+b/8Gzut+ywDeszh+oyhJ eTqdvTTrWU/zWvqciAixFKnaK8rRwfmcwKb96hnsQWWYlHHWS76eEXTHs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHDQCBD/5U/4cNJK1cgwaBLASDBr0wiCYCHIEPTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICMBUQAgQBDQUbiBSjTptnAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaEOzMHAgKCZC+BFgEEkA+JU5N0I4IygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="130361689" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 09 Mar 2015 21:27:10 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t29LRA3H019974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 21:27:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 16:27:09 -0500 From: "Joe Hildebrand (jhildebr)" To: Szilveszter Nadas , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Salvatore Loreto Thread-Topic: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) Thread-Index: AQHQVqf4JQjwNdJnsku/AoeBVLSQCp0OudWAgADiFgCABQWagA== Date: Mon, 9 Mar 2015 21:27:09 +0000 Message-ID: <78608660-E8DC-4E59-914D-02C29F4F49B6@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <7C6DFF6A-A653-486D-AA39-F8A5FDC0A661@ericsson.com> <76EFE5DD-86C1-476A-BC93-074ACA3A5C88@ericsson.com> <54F8B9A5.5000008@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.213.230] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Extensibility (wa New Version Notification for draft-hildebrand-spud-prototype-02.txt) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:27:15 -0000 T24gMy82LzE1LCAyOjQ1IEFNLCAiU3ppbHZlc3p0ZXIgTmFkYXMiIDxTemlsdmVzenRlci5OYWRh c0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+QSBxdWVzdGlvbiByZWxhdGVkIHRvIHRoaXMgaXMg aW4gdGhlIGJhY2sgb2YgbXkgbWluZCBmb3IgYSB3aGlsZS4gU2hhbGwgU1BVRCBzdGFuZGFyZGl6 ZSB0aGUgbWluaW11bSBhbW91bnQgb2YgY29tbW9uL25lY2Vzc2FyeSBzaWduYWxpbmcgaW5mb3Jt YXRpb24gZWxlbWVudHMgYW5kIGFsbG93IGFueSBzaWduYWxpbmcgc29sdXRpb24sIGV2ZW4gcHJv cHJpZXRhcnksIHVzaW5nIFNQVUQgdG8gcmVhY2ggdGhlIG1pZGRsZWJveGVzPyBPciBzaGFsbCBT UFVEIGluY2x1ZGUgbW9zdCBvZiB0aGUgaW5mb3JtYXRpb24gZWxlbWVudHMgbmVlZGVkPyBJIGFt IGluIGZhdm9yIG9mIHRoZSBmaXJzdCwgYmVjYXVzZSB0aGF0IGFsbG93cyBpbm5vdmF0aW9uLCB0 aG91Z2ggY2xlYXJseSBpbnRlcm9wIGlzIG11Y2ggbW9yZSBhIGhhc3NsZS4gDQoNCkkgbW9zdGx5 IGFncmVlLiAgSSB3YW50IHRvIG1ha2Ugc3VyZSB3ZSBnZXQgYW55dGhpbmcgdGhhdCAqYWxsKiBp bXBsZW1lbnRhdGlvbnMgbmVlZCB0byBzdXBwb3J0IGludG8gdGhlIGJhc2Ugc3BlYy4gIFRoZW4g d2UgY2FuIG1vdmUgYWxsIG9mIHRoZSBvdGhlciBleHRlbnNpb25zIGludG8gc2VwYXJhdGUgZG9j dW1lbnRzLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon Mar 9 14:30:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553971A8BB6 for ; Mon, 9 Mar 2015 14:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 TYlX3llZzw9C for ; Mon, 9 Mar 2015 14:30:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF31F1AC3D1 for ; Mon, 9 Mar 2015 14:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1425936648; x=1427146248; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ZTQ0Psr03m0FXD/p1XDrj3/b4yMgYB6FLGvI/cL4ph0=; b=mDgAIxDpMLuB+YcKgvVIhaBYxgozj+mRm8EjVApJrmY4rpriZle026Q2 uqema1TQT2dHvBz11+WgQ/QQNU9/lJcikxBvPB7DQqZqn/GRnnE9jeync htC/gLOUp8BOpUMWX62DNrkZcixg2poSxpPKj7ijajGCt7yW+RYVqKW+c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BqGwA1EP5U/5xdJa1cgwaBLASDBrlog0iIJh6BD00BAQEBAQF8hBACBCMRVwEIGgImAgQwFRIEARKIL6NTm2YBAQEBAQEBAwEBAQEBAQEBAQEBF4EhiXaEeYJkL4EWAQSQD4lTk3Qjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="402163528" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2015 21:30:47 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t29LUlHB024684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 21:30:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 16:30:46 -0500 From: "Joe Hildebrand (jhildebr)" To: Szilveszter Nadas , "spud@ietf.org" Thread-Topic: [Spud] Middlebox to middlebox declarations in SPUD? Thread-Index: AQHQWrBORnHsapANS0muK8cPWUbQnQ== Date: Mon, 9 Mar 2015 21:30:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.213.230] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] Middlebox to middlebox declarations in SPUD? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:30:49 -0000 T24gMy82LzE1LCA4OjU5IEFNLCAiU3ppbHZlc3p0ZXIgTmFkYXMiIDxTemlsdmVzenRlci5OYWRh c0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+IA0KPlBoaWxvc29waGljYWxseSwgd2UgY291bGQg bG9vayBhdCB0aGUgdXNlci9PUyBhcyBhIG1pZGRsZWJveCBpbiB0aGlzIHNjZW5hcmlvLiBJbiB0 aGF0IGNhc2Ugc29tZSBpdCBpcyBlYXNpZXIgdG8gZmluZCBtaWRkbGVib3ggdG8gbWlkZGxlYm94 IHVzZSBjYXNlcy4gSWYgdGhpcyBwaGlsb3NvcGh5IGlzIGFwcGxpZWQgaXQgbWlnaHQgYWxzbyBi ZSBlYXNpZXIgdG8gc29sdmUgdGhlc2UgcXVlc3Rpb25zLg0KDQpUaGF0IGZlZWxzIHJpZ2h0IHRv IG1lLiAgU2ltaWxhcmx5LCBhcyBJJ3ZlIGJlZW4gcHJvdG90eXBpbmcsIEkgd2FzIHdvcnJpZWQg YWJvdXQgd2hhdCB0byBkbyB3aXRoIHBhY2tldHMgSSBtaXNzZWQsIHNpbmNlIHRoZSBPUyBpc24n dCBxdWV1ZWluZyBmb3IgbWUuICBPbmNlIEkgc3RhcnRlZCB0aGlua2luZyBhYm91dCB0aG9zZSBw YWNrZXRzIGFzIGp1c3QgbG9zdCBvbiBhIGRpZmZlcmVudCBzZWdtZW50IG9mIHRoZSBwYXRoLCBJ IHN0b3BwZWQgd29ycnlpbmcgYWJvdXQgdGhlbS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoN Cg0K From nobody Mon Mar 9 14:37:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D501ACDA3 for ; Mon, 9 Mar 2015 14:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6KCSWKpEMlPk for ; Mon, 9 Mar 2015 14:37:22 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638781ACD7F for ; Mon, 9 Mar 2015 14:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1425937027; x=1427146627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LERCtGzTu3rxHTPYkyVXpgGOiKwYwCFlG3x5WSNbDE4=; b=ZSkjCOUeQOTCAuCujZ99X5dAYWLjdZHaZ1mgSBl71JOspxYvdJ6NAVgv n82vO4dckvUQoyI0ufsKHv2SKsDT7PSo2eXeFpTsdNYgKnD8G4JKombbh U7SfD1pTYe/dSMsCsd9T6FWX2azQ4PJukGTIZHZ2iCeDK6Q1S/nXnjiWq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHDQAPEv5U/40NJK1cgwaBLASDBr0wiCYCHIEPTQEBAQEBAXyEEAEBBCMRMRICEAIBCBoCJgICAjAVBwkCBAENBYgvo3GbZwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hDszB4JoL4EWAQSODYICiVOBGoV8jF4jgjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="130367767" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP; 09 Mar 2015 21:37:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t29Lb6Ym018324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 21:37:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 16:37:06 -0500 From: "Joe Hildebrand (jhildebr)" To: Patrick McManus , Ted Hardie Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQWE9zJBDJbJdH6EupEdFNpjrMAJ0UoPsA Date: Mon, 9 Mar 2015 21:37:05 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.213.230] Content-Type: text/plain; charset="utf-8" Content-ID: <1E56FDCFE3A98340BF1FD9992AF87E0B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:37:24 -0000 T24gMy82LzE1LCAxOjUyIFBNLCAiUGF0cmljayBNY01hbnVzIiA8bWNtYW51c0BkdWNrc29uZy5j b20+IHdyb3RlOg0KDQo+Rmlyc3QgLSBUaGFua3MgSm9lIGFuZCBCcmlhbi4gSSBoYXZlIGEgZmV3 IG1hcmdpbiBub3RlcyB0byBzaGFyZSA6KQ0KPg0KPk5leHQsIEkgbWF5IGp1c3QgYmUgY29uZnVz ZWQgYmVjYXVzZSBJIGhhdmUgcmVhZCB0aGUgdGV4dCBsZXNzIHRoYW4gdGhlIGF1dGhvcnMgYXQg dGhpcyBwb2ludCwgYnV0IGl0IHNlZW1zIGFzIGlmIHVuaWRpcmVjdGlvbmFsIGZsb3dzIGFyZSBv ZmYgdGhlIHRhYmxlLi4gdGhlIHRleHQgZG9lc24ndCByZWFsbHkgc2F5IHRoaXMsIGJ1dCB0aGUg b3Blbi1hY2sgc2VlbXMgdG8gaW1wbHkgaXQuIFRoZXJlIGNlcnRhaW5seSBhcmUgdW5pZGlyZWN0 aW9uYWwNCj4gdWRwIGZsb3dzIGJ1dCBzb21lIGNsYXJpZmljYXRpb24gd291bGQgaGVscC4NCg0K SXQgd2Fzbid0IG15IGludGVudCB0byBydWxlIHRoZW0gb3V0LCBidXQgd2UgcHJvYmFibHkgbmVl ZCB0byB0aGluayBhYm91dCBob3cgdG8gZW5zdXJlIHRoYXQgdGhlIHN0YXRlIHRyYW5zaXRpb25z IG1ha2UgdGhhdCBtb3JlIGNsZWFyLg0KDQo+VGhpcmRseSwgaXMgdGhlcmUgYWR2aWNlIGdpdmVu IG9yIGltcGxpZWQgZm9yIG1pZGRsZWJveGVzIHRoYXQgc2VlIGRhdGEgc3B1ZCBwYWNrZXRzIG9u IG9wZW5pbmcgdHViZXM/IA0KDQpOb3QgeWV0Lg0KDQo+VGhlIG9ubHkgdGhpbmcgSSByZWFsbHkg c2VlIGFib3V0IHRoZSBvcGVuaW5nIHN0YXRlIGlzIHRoZSBkaWFncmFtIC0gYnV0IHRoZSBkaWFn cmFtIGFwcGxpZXMgdG8gdGhlIGVuZHBvaW50LCBub3QgdG8gdGhlIG1pZGRsZWJveCBzdGF0ZSwg cmlnaHQ/IEknbQ0KPiBjb25jZXJuZWQgdGhlIHRleHQgd2lsbCByZWFkIGxpa2UgdGhlcmUgbmVl ZHMgdG8gYmUgYSBmdWxsIHJ0dCBoYW5kc2hha2UgYmVmb3JlIGRhdGEgcGFja2V0cyBjYW4gZmxv dyBvbiBhIHNwdWQgdHViZSBhbmQgdGhlcmUgYXJlIGNvdW50ZXIgZXhhbXBsZXMgdG8gdGhpbmdz IHdlIHdvdWxkIGxpa2UgdG8gcnVuIG9uIHNwdWQgYWxyZWFkeS4NCg0KQWdyZWUuICBUaGlzIHJl YWxseSBpc24ndCBjbGVhciB5ZXQgYW5kIGl0IG5lZWRzIHRvIGJlLg0KDQo+Rm91cnRobHksIHRo ZXJlIGFyZSBhIGNvdXBsZSAicmVzZXJ2ZWQgYml0cyBNVVNUIGJlIHplcm8iLi4gc2hvdWxkIHRo YXQgYmUgInNlbmRlcnMgTVVTVCBzZXQgdG8gemVybywgcmVjZWl2ZXJzIE1VU1QgaWdub3JlICI/ DQoNClllcy4gIFdpbGxmaXguDQoNCj5GaWZ0aGx5LCBvbiB0aGUgdG9waWMgb2Ygd2hldGhlciB0 dWJlLWlkcyBuZWVkIGEgY29uc2lzdGVudCA1IHR1cGxlLCBJIHRoaW5rIHRoZXJlIGFyZSBzZXZl cmFsIGNhc2VzIHdoZXJlIGl0IHdvdWxkIGJlIG5pY2UgaWYgdGhleSBkaWRuJ3QuLiAgbG9hZCBi YWxhbmNlcnMgYXJlIGEgZ29vZCBleGFtcGxlIC0gYSByZXF1ZXN0IGlzIHNlbnQgdG8gYSBjZW50 cmFsIHNlcnZpY2UgdGhhdCBwYXJzZXMgaXQgYW5kIGRpc3BhdGNoZXMgaXQgdG8NCj4gdGhlIGJl c3QgYmFjayBlbmQgc2VydmVyLi4gaGlzdG9yaWNhbGx5IHRoYXQgc2VydmVyIG5lZWRzIHRvIGxp ZSBhYm91dCBpdHMgYWRkcmVzcyBzb21laG93IHdoZW4gc2VuZGluZyB0aGUgcmVwbHkgKGVpdGhl ciB2aWEgcHJveHkgb3IgbW9yZSBsaWtlbHkgdmlhIHNwb29maW5nIC0gYW5kIGlmIHNwb29mZWQg eW91IG5lZWQgdG8gZmlndXJlIG91dCB0aGUgYWNrIHRyYWZmaWMpLiBJdCB3b3VsZCBiZSBjb29s IHRvIGhhdmUgdGhhdCBhbGwgaW4gb25lDQo+IHR1YmUgd2l0aCByZWFsIGFkZHJlc3NlcyBzbyB0 aGUgdHJhbnNwb3J0IGNvdWxkIGRlY2lkZSBob3cgdG8gZGVhbCB3aXRoIHRob3NlIGlzc3Vlcy4N Cg0KSSBsaWtlIHRoZSB1c2UgY2FzZS4NCg0KPlNpeHRobHksIGFtIEkgbWlzcmVhZGluZyB0aGUg OC4yIE1VU1QgdGhhdCBTUFVEIGVuYWJsZWQgTkFUcyBuZWVkIHRvIHNoYXJlIGludGVybmFsIGFk ZHJlc3NpbmcgaW5mbyBvbiB0aGUgZXh0ZXJuYWwgc2lkZSBvZiB0aGUgTkFUPyBJcyB0aGF0IHJl YWxseSBhIE1VU1QgLSBzb21lIGZvbGtzIHdpbGwgYmUgZnJvdGhpbmcgYXQgdGhlIG1vdXRoIHdp dGggdGhlIHBlcmNlaXZlZCBpbmZvcm1hdGlvbiBkaXNjbG9zdXJlIGlzc3Vlcy4NCg0KVGhlIGlu dGVudCB3YXMgdGhhdCB0aGUgbWFwcGluZyBpcyBvbmx5IHNoYXJlZCBpbnRlcm5hbGx5LiAgSSds bCBzZWUgaWYgSSBjYW4gZml4IHRoZSB3b3JkaW5nLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoN Cg0KDQo= From nobody Mon Mar 9 14:50:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22B71ACCEC for ; Mon, 9 Mar 2015 14:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 UZ0EkvUeRT3I for ; Mon, 9 Mar 2015 14:50:39 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FDB1ACD6A for ; Mon, 9 Mar 2015 14:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1872; q=dns/txt; s=iport; t=1425937833; x=1427147433; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=shAV2kJF6cJOJPG1tvc0pV0oqqeyd6y4WPtvivNnIh8=; b=T3NzrmtG5uuw1AoOKON4V2Wqydk7FCL4Ue4r6x7j2Oa8ZPFJJgfJVyRz Jx3Whjw52Uql/fZr/BJIBOEj47GTjJnupHJgeEBXT550mHxj1rNlaYe8J dvQwGKv5HaMmE63k13UsfPSxzqLCsxsCTqLYCGRZ5yGrfodRrxsGAmCxu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0DQB2FP5U/5tdJa1cgwZSVQUEgwa9MII4hW4CHIEPTQEBAQEBAXyEEAEBBCMRQxICAQgaAiYCAgIwFQYBBgMCBBMJiCYIBaMjm2gBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoR1gmgvgRYFkA+DZIVvgRo5gm+PMiODbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="130371637" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 09 Mar 2015 21:50:32 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t29LoWjb000425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 21:50:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 16:50:32 -0500 From: "Joe Hildebrand (jhildebr)" To: "spud@ietf.org" Thread-Topic: New Version Notification for draft-hildebrand-spud-prototype-03.txt Thread-Index: AQHQWrKyMfN3PwlT8U+g4tE7ze3//50Un/eA Date: Mon, 9 Mar 2015 21:50:31 +0000 Message-ID: <7CD99639-F1AD-4FED-8DA1-72E5AC3EBD37@cisco.com> References: <20150309214750.13328.47507.idtracker@ietfa.amsl.com> In-Reply-To: <20150309214750.13328.47507.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.213.230] Content-Type: text/plain; charset="utf-8" Content-ID: <6E3B3F0E8D155A43899BAA13EDB41F9F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-03.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:50:52 -0000 TWlub3IgY2hhbmdlcywgcmVmbGVjdGluZyBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KDQpPbiAz LzkvMTUsIDM6NDcgUE0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhp bGRlYnJhbmQtc3B1ZC1wcm90b3R5cGUtMDMudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBKb2UgSGlsZGVicmFuZCBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3Np dG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQtaGlsZGVicmFuZC1zcHVkLXByb3RvdHlwZQ0KPlJldmlz aW9uOgkwMw0KPlRpdGxlOgkJU3Vic3RyYXRlIFByb3RvY29sIGZvciBVc2VyIERhdGFncmFtcyAo U1BVRCkgUHJvdG90eXBlDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOQ0KPkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQkxNA0KPlVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oaWxkZWJyYW5kLXNwdWQtcHJvdG90 eXBlLTAzLnR4dA0KPlN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oaWxkZWJyYW5kLXNwdWQtcHJvdG90eXBlLw0KPkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oaWxkZWJyYW5kLXNwdWQtcHJvdG90eXBl LTAzDQo+RGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWhpbGRlYnJhbmQtc3B1ZC1wcm90b3R5cGUtMDMNCj4NCj5BYnN0cmFjdDoNCj4gICBTUFVE IGlzIGEgcHJvdG90eXBlIGZvciBncm91cGluZyBVRFAgcGFja2V0cyB0b2dldGhlciBpbiBhICJ0 dWJlIiwNCj4gICBhbHNvIGFsbG93aW5nIG5ldHdvcmsgZGV2aWNlcyBvbiB0aGUgcGF0aCBiZXR3 ZWVuIGVuZHBvaW50cyB0bw0KPiAgIHBhcnRpY2lwYXRlIGV4cGxpY2l0bHkgaW4gdGhlIHR1YmUg b3V0c2lkZSB0aGUgZW5kLXRvLWVuZCBjb250ZXh0Lg0KPg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUg SUVURiBTZWNyZXRhcmlhdA0KPg0KPg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Mon Mar 9 15:06:00 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9321ACDB8 for ; Mon, 9 Mar 2015 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 EhCiccEO9iou for ; Mon, 9 Mar 2015 15:05:55 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0449C1ACDA1 for ; Mon, 9 Mar 2015 15:05:55 -0700 (PDT) Received: by iecvy18 with SMTP id vy18so43414266iec.1 for ; Mon, 09 Mar 2015 15:05:54 -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:content-type; bh=RvpOpPQeVOA6Y98bEriJYapUHHbn3fv5tYzEmM1ucjs=; b=BIRrUFDku2NiUREKYTlNNmQAEthPrn9zicZMGwG7d1a/MRIdbe9oSCeeFNYSi8b1ql gGAYZeoe6DNeKTRlRfWEROM83mtFDJn46qsA7Qc/TUwrSYSruDW0MEgy7B3ArowmkNwz Wnmu7ROcbbCYSkxG63md/Eqj5qQLW61ThpmwqNEl/8V0SLi94nVCUQbshVybxFVsBcv3 ka643dQb2sQfDKu81xiFoDjDVKJAL4IqKB8T2t3GgB08VeiSpkWXRwRTuSAdR4qGHugH 24T3/OgSw4rWQ8tmzw3pbrd++ieA4LWBz3unP7x1jZbvbS06yzbA+n6inZbq13OXv6WK vwlA== MIME-Version: 1.0 X-Received: by 10.107.167.145 with SMTP id q139mr52277111ioe.16.1425938754472; Mon, 09 Mar 2015 15:05:54 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Mon, 9 Mar 2015 15:05:54 -0700 (PDT) In-Reply-To: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Mon, 9 Mar 2015 15:05:54 -0700 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a11429990ee924e0510e23c63 Archived-At: Cc: Patrick McManus , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:05:57 -0000 --001a11429990ee924e0510e23c63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2015 at 2:37 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 3/6/15, 1:52 PM, "Patrick McManus" wrote: > > > > > >Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I > think there are several cases where it would be nice if they didn't.. lo= ad > balancers are a good example - a request is sent to a central service tha= t > parses it and dispatches it to > > the best back end server.. historically that server needs to lie about > its address somehow when sending the reply (either via proxy or more like= ly > via spoofing - and if spoofed you need to figure out the ack traffic). It > would be cool to have that all in one > > tube with real addresses so the transport could decide how to deal with > those issues. > > I like the use case. > > =E2=80=8BSo, I may need a whiteboard here, because the way I see this use c= ase sharing a tube-id seems like a loss. What I think you're saying is Client A (from 192.0.2.1) sends traffic toward service Z (at 203.0.113.1) . The packet goes from A across a path until it reaches middlebox L (at 198.51.100.1) which dispatches=E2=80=8B it= toward a backend server Z-15 (at 203.0.113.15) which would currently spoof 203.0.113.1. This often forces L to maintain a map for the tuple in A's packets to the correct backend. A tube-id would simplify this (since L could use it instead of a tuple). =E2=80=8BWhat I hear you saying is that you'd prefer to allow Z-15 to emit = a packet using its own IP address, rather than Z's, and have it be understood to be in the same flow by dint of it sharing the same tube-id. This gives the tube-id some serious security requirements that it doesn't currently (as an advisory bit) have. Have I misunderstood you? Do you want something different here? Ted=E2=80=8B --001a11429990ee924e0510e23c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2015 at 2:37 PM,= Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
<= div class=3D"gmail_quote">
On 3/6/15, 1:52 PM, "Patrick McManus" <mcmanus@ducksong.com> wrote:

>

>Fifthly, on the topic of whether tube-ids need a consistent 5 tuple, I = think there are several cases where it would be nice if they didn't..= =C2=A0 load balancers are a good example - a request is sent to a central s= ervice that parses it and dispatches it to
> the best back end server.. historically that server needs to lie about= its address somehow when sending the reply (either via proxy or more likel= y via spoofing - and if spoofed you need to figure out the ack traffic). It= would be cool to have that all in one
> tube with real addresses so the transport could decide how to deal wit= h those issues.
=C2=A0
<= span class=3D""> I like the use case.


=C2=A0
=E2=80=8BSo, I may need a whiteboard here, because the way I see thi= s use case sharing a tube-id seems like a loss.=C2=A0

What I think = you're saying is Client A (from 192.0.2.1) sends traffic toward service= Z (at 203.0.113.1) .=C2=A0 The packet goes from A across a path until it r= eaches middlebox L (at 198.51.100.1) which dispatches=E2=80=8B it toward a = backend server Z-15 (at 203.0.113.15) which would currently spoof 203.0.113= .1.=C2=A0 This often forces L to maintain a map for the tuple in A's pa= ckets to the correct backend.=C2=A0 A tube-id would simplify this (since L = could use it instead of a tuple).=C2=A0

=E2=80=8BWh= at I hear you saying is that you'd prefer to allow Z-15 to emit a packe= t using its own IP address, rather than Z's, and have it be understood = to be in the same flow by dint of it sharing the same tube-id.=C2=A0=C2=A0= =C2=A0 This gives the tube-id some serious security requirements that it do= esn't currently (as an advisory bit) have.=C2=A0 Have I misunderstood y= ou?=C2=A0=C2=A0 Do you want something different here?

Ted=E2=80=8B

--001a11429990ee924e0510e23c63-- From nobody Tue Mar 10 13:18:30 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3274B1A8932 for ; Tue, 10 Mar 2015 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 7UR2yw7gLFjC for ; Tue, 10 Mar 2015 13:18:28 -0700 (PDT) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 17DB21A890D for ; Tue, 10 Mar 2015 13:18:28 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3B23B3A01D for ; Tue, 10 Mar 2015 16:18:27 -0400 (EDT) Received: by qgef51 with SMTP id f51so5057951qge.0 for ; Tue, 10 Mar 2015 13:18:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.145.11 with SMTP id 11mr45547095qhr.19.1426018706896; Tue, 10 Mar 2015 13:18:26 -0700 (PDT) Received: by 10.140.104.115 with HTTP; Tue, 10 Mar 2015 13:18:26 -0700 (PDT) In-Reply-To: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Tue, 10 Mar 2015 16:18:26 -0400 Message-ID: From: Patrick McManus To: Ted Hardie Content-Type: multipart/alternative; boundary=001a1137645477f1e30510f4dad0 Archived-At: Cc: Patrick McManus , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:18:29 -0000 --001a1137645477f1e30510f4dad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2015 at 6:05 PM, Ted Hardie wrote: > So, I may need a whiteboard here, because the way I see this use case > sharing a tube-id seems like a loss. > > What I think you're saying is Client A (from 192.0.2.1) sends traffic > toward service Z (at 203.0.113.1) . The packet goes from A across a path > until it reaches middlebox L (at 198.51.100.1) which dispatches=E2=80=8B = it toward > a backend server Z-15 (at 203.0.113.15) which would currently spoof > 203.0.113.1. This often forces L to maintain a map for the tuple in A's > packets to the correct backend. A tube-id would simplify this (since L > could use it instead of a tuple). > > =E2=80=8BWhat I hear you saying is that you'd prefer to allow Z-15 to emi= t a > packet using its own IP address, rather than Z's, and have it be understo= od > to be in the same flow by dint of it sharing the same tube-id. This > gives the tube-id some serious security requirements that it doesn't > currently (as an advisory bit) have. Have I misunderstood you? Do you > want something different here? > "want" is such a strong word :) I'm just brainstorming. There is a case where L doesn't want to be part of the flow after Z-15 is selected, but obviously it needs to be in a TCP scenario if for no other reason than to forward the ack traffic to Z-15 - the fact that it continues to be involved is really an artifact of the protocol - L isn't a typical on path middlebox; but spuds is still interesting here for its interaction with something like a client side NAT. This is an ordered flow (a tube?) with 3 end points. I don't really know that the tube-id itself takes on security requirements here, the transport running in the tube might have a totally self defined security and identification model independent of the tube-id - mobility leads you down that path naturally. (but yes - that's a hard problem :)). Is there a reason that gets bumped up to the spuds wrapper? --001a1137645477f1e30510f4dad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 9, 2015 at 6:05 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
So, I may need a wh= iteboard here, because the way I see this use case sharing a tube-id seems = like a loss.=C2=A0

What I think you're saying is Client A (from= 192.0.2.1) sends traffic toward service Z (at 203.0.113.1) .=C2=A0 The pac= ket goes from A across a path until it reaches middlebox L (at 198.51.100.1= ) which dispatches=E2=80=8B it toward a backend server Z-15 (at 203.0.113.1= 5) which would currently spoof 203.0.113.1.=C2=A0 This often forces L to ma= intain a map for the tuple in A's packets to the correct backend.=C2=A0= A tube-id would simplify this (since L could use it instead of a tuple).= =C2=A0

=E2=80=8BWhat I hear you saying is that you&= #39;d prefer to allow Z-15 to emit a packet using its own IP address, rathe= r than Z's, and have it be understood to be in the same flow by dint of= it sharing the same tube-id.=C2=A0=C2=A0=C2=A0 This gives the tube-id some= serious security requirements that it doesn't currently (as an advisor= y bit) have.=C2=A0 Have I misunderstood you?=C2=A0=C2=A0 Do you want someth= ing different here?

"want" is such a strong word :) I'm just brains= torming.

There is a case where L do= esn't want to be part of the flow after Z-15 is selected, but obviously= it needs to be in a TCP scenario if for no other reason than to forward th= e ack traffic to Z-15 - the fact that it continues to be involved is really= an artifact of the protocol - L isn't a typical on path middlebox; but= spuds is still interesting here for its interaction with something like a = client side NAT. This is an ordered flow (a tube?) with 3 end points.
I don't really know that the tube-id= itself takes on security requirements here, the transport running in the t= ube might have a totally self defined security and identification model ind= ependent of the tube-id - mobility leads you down that path naturally. (but= yes - that's a hard problem :)). Is there a reason that gets bumped up= to the spuds wrapper?




=
--001a1137645477f1e30510f4dad0-- From nobody Tue Mar 10 13:52:33 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2E01A89AE for ; Tue, 10 Mar 2015 13:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Y537m9LaroWv for ; Tue, 10 Mar 2015 13:52:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293C81A1AAE for ; Tue, 10 Mar 2015 13:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1426020750; x=1427230350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lATNSurP1ZvGdGdjXwbWksd5mioga5YJQd7a1qW9JZ0=; b=Ejrmn+UK1OatYorwGu54UcqowgUAxipWm2K6DhFTbO8Ybh//phWVvZPO /VB7ZdprvApO4ST87mgmbH0agzg/OsmXVIfjFWXsxQievnfDIAdEQPuD6 y8vFL3ocYYTuJO6IYJn1Xp5CG2ak6gZtnRoH/ZUwVEOLAM2tAVtHvx7JK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+BQBzWP9U/51dJa1cgwaBMIMGvVBphzcCHIEUOBQBAQEBAQEBfIQQAQEEIxFDAhACAQgaAiYCAgIwFQcJAgQBDQWIL6oomVgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcYQ7MweCaC+BFAEEj3aJRQGTVCOCMoE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,376,1422921600"; d="scan'208";a="130636099" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 10 Mar 2015 20:52:29 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2AKqTA4021923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 20:52:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 15:52:29 -0500 From: "Joe Hildebrand (jhildebr)" To: Patrick McManus , Ted Hardie Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQWE9zJBDJbJdH6EupEdFNpjrMAJ0UoPsAgABspACAAXROAP//pOyA Date: Tue, 10 Mar 2015 20:52:28 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.66.71] Content-Type: text/plain; charset="utf-8" Content-ID: <821C4022756482489D4B703B5B7E36C2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:52:31 -0000 T24gMy8xMC8xNSwgMjoxOCBQTSwgIlBhdHJpY2sgTWNNYW51cyIgPG1jbWFudXNAZHVja3Nvbmcu Y29tPiB3cm90ZToNCg0KPiJ3YW50IiBpcyBzdWNoIGEgc3Ryb25nIHdvcmQgOikgSSdtIGp1c3Qg YnJhaW5zdG9ybWluZy4NCj4NCj5UaGVyZSBpcyBhIGNhc2Ugd2hlcmUgTCBkb2Vzbid0IHdhbnQg dG8gYmUgcGFydCBvZiB0aGUgZmxvdyBhZnRlciBaLTE1IGlzIHNlbGVjdGVkLCBidXQgb2J2aW91 c2x5IGl0IG5lZWRzIHRvIGJlIGluIGEgVENQIHNjZW5hcmlvIGlmIGZvciBubyBvdGhlciByZWFz b24gdGhhbiB0byBmb3J3YXJkIHRoZSBhY2sgdHJhZmZpYyB0byBaLTE1IC0gdGhlIGZhY3QgdGhh dCBpdCBjb250aW51ZXMgdG8gYmUgaW52b2x2ZWQNCj4gaXMgcmVhbGx5IGFuIGFydGlmYWN0IG9m IHRoZSBwcm90b2NvbCAtIEwgaXNuJ3QgYSB0eXBpY2FsIG9uIHBhdGggbWlkZGxlYm94OyBidXQg c3B1ZHMgaXMgc3RpbGwgaW50ZXJlc3RpbmcgaGVyZSBmb3IgaXRzIGludGVyYWN0aW9uIHdpdGgg c29tZXRoaW5nIGxpa2UgYSBjbGllbnQgc2lkZSBOQVQuIFRoaXMgaXMgYW4gb3JkZXJlZCBmbG93 IChhIHR1YmU/KSB3aXRoIDMgZW5kIHBvaW50cy4NCg0KSSBjb3VsZCBpbWFnaW5lIEwgc2VuZGlu ZyBhIHBhdGggZGVjbGFyYXRpb24gdGhhdCBhbGxvd3MgWi0xNSB0byB0YWtlIG92ZXIsIGJhc2lj YWxseSBhbiBpbi1mbGlnaHQgaGFuZC1vZmYuICBXZSB3b3VsZCBoYXZlIHRvIGdldCB0aGF0IHBy b3RvY29sIGNvcnJlY3QgZWFybHkgb24gaW4gdGhlIHByb2Nlc3Mgc28gdGhhdCBldmVyeW9uZSBp bXBsZW1lbnRzIGl0LCB0aG91Z2guDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Mar 10 14:02:59 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B613F1A0087 for ; Tue, 10 Mar 2015 14:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 HXPCP_r4oilP for ; Tue, 10 Mar 2015 14:02:57 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 43C651A701A for ; Tue, 10 Mar 2015 14:02:56 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so30604601iec.1 for ; Tue, 10 Mar 2015 14:02:55 -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:content-type; bh=NlovS4Z7DYK8ZK1RzuA8VSvX+WWMco3+a7BxQuoehU4=; b=cBSFy/U2eLNH297SBvfyivNs/2ozskI4ms+bgMCxUIXWGluWlKD+qln62H2xdQm5lR n7I/ICcDdouTL1Cz9+LA3YH79bayWPzj8mdp0i5IBYk9P5bMyPU/vHAhSov0z6Z+mgfG /4lzjE6cWO7tTET2WckX9V5Kl74OQD7rUIkoMHHGjSDUFGVGNeRKrHSUNqqrVv2hy3+P iVpWp66V+wT/JKJS2VOx/SwbcFgigy4mJOArH+zU910+WqFoAjqlmONLsxD0JMRjwNHu 0k4KPNcz+ZP6XT0Tg/9MGUbmu2TDrpMMBCBQbd1XWz30Utc5rl/3f8Q3DrQCxziBbgHT S47w== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr59487538igl.6.1426021375711; Tue, 10 Mar 2015 14:02:55 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Tue, 10 Mar 2015 14:02:55 -0700 (PDT) In-Reply-To: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> Date: Tue, 10 Mar 2015 14:02:55 -0700 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e011825c08aa0b30510f5793a Archived-At: Cc: Patrick McManus , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:02:58 -0000 --089e011825c08aa0b30510f5793a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2015 at 1:52 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 3/10/15, 2:18 PM, "Patrick McManus" wrote: > > >"want" is such a strong word :) I'm just brainstorming. > > > >There is a case where L doesn't want to be part of the flow after Z-15 i= s > selected, but obviously it needs to be in a TCP scenario if for no other > reason than to forward the ack traffic to Z-15 - the fact that it continu= es > to be involved > > is really an artifact of the protocol - L isn't a typical on path > middlebox; but spuds is still interesting here for its interaction with > something like a client side NAT. This is an ordered flow (a tube?) with = 3 > end points. > > I could imagine L sending a path declaration that allows Z-15 to take > over, basically an in-flight hand-off. We would have to get that protoco= l > correct early on in the process so that everyone implements it, though. > > =E2=80=8BSo, I don't think this is the right thing to do in a substrate. Y= ou may want to build a protocol that can do this on top of the substrate's capabilities, but gating acceptance of the substrate on this particular use case seems to me unwarranted fate sharing. If you want an application-layer protocol that can handle service handoff, information like "Z-15 has path to path information for tube-id N" as an advisory message may be useful. But if Z-15 has a different IP address, as above, there is no guarantee that the path will remain the same; anything from ECMP on up may change it. Call me old-fashioned (or make me one, even better), but I believe it is easier here to use anycast IP addressing for the source addresses while allowing the tube-id to be used to dispatch to the right back end. In an SDN world, you might not even need that to be in L, but in the baseline network elements matching tables. regards, Ted --089e011825c08aa0b30510f5793a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 10, 2015 at 1:52 PM= , Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
=
= On 3/10/15, 2:18 PM, "Patrick McManus" <mcmanus@ducksong.com> wrote:

>"want" is such a strong word :) I'm just brainstorming. >
>There is a case where L doesn't want to be part of the flow after Z= -15 is selected, but obviously it needs to be in a TCP scenario if for no o= ther reason than to forward the ack traffic to Z-15 - the fact that it cont= inues to be involved
> is really an artifact of the protocol - L isn't a typical on path = middlebox; but spuds is still interesting here for its interaction with som= ething like a client side NAT. This is an ordered flow (a tube?) with 3 end= points.

I could imagine L sending a path declaration that allows Z-15 to tak= e over, basically an in-flight hand-off.=C2=A0 We would have to get that pr= otocol correct early on in the process so that everyone implements it, thou= gh.


=E2=80=8BSo, I don't think this is the right thin= g to do in a substrate.=C2=A0 You may want to build a protocol that can do = this on top of the substrate's capabilities, but gating acceptance of t= he substrate on this particular use case seems to me unwarranted fate shari= ng.

If you want an application-layer protocol that c= an handle service handoff, information like "Z-15 has path to path inf= ormation for tube-id N" as an advisory message may be useful. =C2=A0= =C2=A0 But if Z-15 has a different IP address, as above, there is no guaran= tee that the path will remain the same; anything from ECMP on up may change= it.

Call me old-fashioned (or make me one, even bet= ter), but I believe it is easier here to use anycast IP addressing for the = source addresses while allowing the tube-id to be used to dispatch to the r= ight back end.=C2=A0 In an SDN world, you might not even need that to be in= L, but in the baseline network elements matching tables.

regards,

Ted

--089e011825c08aa0b30510f5793a-- From nobody Tue Mar 10 14:15:52 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DF51A8A39 for ; Tue, 10 Mar 2015 14:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 utq4XzgqxBjV for ; Tue, 10 Mar 2015 14:15:47 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0C71A8A29 for ; Tue, 10 Mar 2015 14:15:47 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 1F6411A0032; Tue, 10 Mar 2015 22:15:16 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1B7C42FB-2912-4F69-8EDF-2722380EEC44"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: Date: Tue, 10 Mar 2015 22:15:15 +0100 Message-Id: <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> To: Patrick McManus X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Ted Hardie , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:15:50 -0000 --Apple-Mail=_1B7C42FB-2912-4F69-8EDF-2722380EEC44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Patrick, all, ...in the hopes the conversation has not overtaken me, see inline = below... > On 10 Mar 2015, at 21:18, Patrick McManus = wrote: >=20 > On Mon, Mar 9, 2015 at 6:05 PM, Ted Hardie wrote: > So, I may need a whiteboard here, because the way I see this use case = sharing a tube-id seems like a loss. >=20 > What I think you're saying is Client A (from 192.0.2.1) sends traffic = toward service Z (at 203.0.113.1) . The packet goes from A across a = path until it reaches middlebox L (at 198.51.100.1) which dispatches=E2=80= =8B it toward a backend server Z-15 (at 203.0.113.15) which would = currently spoof 203.0.113.1. This often forces L to maintain a map for = the tuple in A's packets to the correct backend. A tube-id would = simplify this (since L could use it instead of a tuple). >=20 > =E2=80=8BWhat I hear you saying is that you'd prefer to allow Z-15 to = emit a packet using its own IP address, rather than Z's, and have it be = understood to be in the same flow by dint of it sharing the same = tube-id. This gives the tube-id some serious security requirements = that it doesn't currently (as an advisory bit) have. Have I = misunderstood you? Do you want something different here? >=20 > "want" is such a strong word :) I'm just brainstorming. >=20 > There is a case where L doesn't want to be part of the flow after Z-15 = is selected, but obviously it needs to be in a TCP scenario if for no = other reason than to forward the ack traffic to Z-15 - the fact that it = continues to be involved is really an artifact of the protocol - L isn't = a typical on path middlebox; but spuds is still interesting here for its = interaction with something like a client side NAT. This is an ordered = flow (a tube?) with 3 end points. >=20 > I don't really know that the tube-id itself takes on security = requirements here, the transport running in the tube might have a = totally self defined security and identification model independent of = the tube-id - mobility leads you down that path naturally. (but yes - = that's a hard problem :)). Is there a reason that gets bumped up to the = spuds wrapper? If we scope a tube ID to a five tuple, then it has some very nice = properties. Since we're probably multiplexing significantly less than = 2**64 tubes over a five tuple, the currently-active tube ID space is = extremely sparse, and if the tube ID is sufficiently random, it is hard = enough to guess them that we can presume that anyone that has the ID of = a given tube is one of the endpoints, is on path, or is cooperating with = a device on path. This is a property we need in any case in which we're = requiring middleboxes to spoof endpoints, which itself will be necessary = for NAT traversal. Further, the five tuple has really become the state lookup key in each = domain of routability in which its IP addresses are valid. So if the = session ID is scoped to this key, it never has to be rewritten or = otherwise handled by the middleboxes *other* than to bind a group of = packets together so some common properties can be assigned to them. If you use the tube ID for mobility -- i.e., to cover the "my endpoint = address changed, but my session is the same" case, which I very much = wanted to use it for when kicking this idea around much earlier -- now = the scope is different, and all this gets much messier. The tube ID has = to be chosen by the initiating endpoint, which in a mobile-client world = is often the endpoint whose address may change, so scoping to the = three-tuple of the fixed-address side of the connection brings with it a = coordination problem -- and negotiation / decollision of tube IDs adds = complexity and roundtrips, both of which are to be avoided. Of course you could fix that problem by scoping the tube ID to the = entire Internet, but this would (1) need way more bits, (2) probably = need decollision anyway, and (3) has less than optimal (read: = "terrifying") privacy implications for trackability etc. What I can see being useful here is a facility built in to the "core" = spud vocabulary that says "this tube is related to some other tube, = here's the ID", for a small set of values of "related". This is more a = signal to the remote endpoint than the path, though, so it's not clear = it needs to be exposed in SPUD. One tube ID linkage that would need to = be exposed to the path is "prefer to drop packets in this tube before = packets in tube ID x" or "prefer to forward packets in tube ID x before = packets in this tube", which gives you a nice simple vocabulary for = expressing almost everything you need to for differential QoS from a = given source without allowing global marking with all its attendant mark = inflation problems. Of course, since everything along the path and everything cooperating = with everything along the path knows the tube id, any tube linkage = features probably have implications for spoofing we'll need to be = careful about. Cheers, Brian --Apple-Mail=_1B7C42FB-2912-4F69-8EDF-2722380EEC44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU/17jAAoJENt3nsOmbNJcZoIIAKjuvWNOu2O+V7KyESU06WUc VGcqBEFOhV1tM8tbCPfPJMHVjr3Lz328GHv1q0OtZVIqQQyCiL7WN64fR+46jpx4 KjzEtY5b7bHfvM3CFI5qqF6zCUYCml36NU3EtoEBNrxDdhjSfnYP0Bq2WaO5fhI6 dZbEX/FGE36jMapVdBfojG2hPuXQfeikDIz7ShC36UxddXXCW9Xt/5HAgomNyiGn rCcGyEG4Dc5WbQgFudJqcQsp6Vc7qPXWWFIxNpmo0bELrUHzxb2qiZ8VzAtdndPk PtUdyC+scUgtfE1O5BC2CZres5rwk4CVWVTNJLlHA85xi0ZVjD29IPaBMQFHpsc= =Xxvl -----END PGP SIGNATURE----- --Apple-Mail=_1B7C42FB-2912-4F69-8EDF-2722380EEC44-- From nobody Tue Mar 10 14:16:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC871A8A0F for ; Tue, 10 Mar 2015 14:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1wTYVTOW61JF for ; Tue, 10 Mar 2015 14:16:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1761A8A1B for ; Tue, 10 Mar 2015 14:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1426022183; x=1427231783; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FUu3RD8RxDQ4YkXmGuFdq1zJJFksFpBKydO2YlSz8ic=; b=BPm/RqKtcWfM4B0ogkz1k399r8XadwONBwkLCLGl+R2ekIdi0HV9CF5R Zi/9kosuUqrBEcHygV+ld8wWFd+YuT0IZ503qDrqSmFQzKpTvVdb0RYIe o72+2nCqrJw+C3riIO7yHD/TTfUNts+qicEJMpFrEjU/KEHPy7V1SzV9t U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8CQCGXv9U/5pdJa1cgwaBLASDBr1viCcCHIEUTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICHxEVBwkCBA4FiBsDEapClg0NhSgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoJEgXczB4JoL4EWAQSOFoIDiBGBSoEajEmCUYNDI4ICHBSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="130690408" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 10 Mar 2015 21:16:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALGMsg019649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:16:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:16:21 -0500 From: "Joe Hildebrand (jhildebr)" To: "spud@ietf.org" Thread-Topic: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQWE9zJBDJbJdH6EupEdFNpjrMAJ0UoPsAgABspACAAXROAP//pOyAgABngoD//58rgA== Date: Tue, 10 Mar 2015 21:16:21 +0000 Message-ID: <077EA8A3-8086-4F41-A782-49B36733AA97@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.66.71] Content-Type: text/plain; charset="utf-8" Content-ID: <01BD9CCEF5111E449174B14443560C2A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Patrick McManus , Ted Hardie Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:16:26 -0000 T24gMy8xMC8xNSwgMzowMiBQTSwgIlRlZCBIYXJkaWUiIDx0ZWQuaWV0ZkBnbWFpbC5jb20+IHdy b3RlOg0KDQoNCj7igItTbywgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSByaWdodCB0aGluZyB0 byBkbyBpbiBhIHN1YnN0cmF0ZS4gIFlvdSBtYXkgd2FudCB0byBidWlsZCBhIHByb3RvY29sIHRo YXQgY2FuIGRvIHRoaXMgb24gdG9wIG9mIHRoZSBzdWJzdHJhdGUncyBjYXBhYmlsaXRpZXMsIGJ1 dCBnYXRpbmcgYWNjZXB0YW5jZSBvZiB0aGUgc3Vic3RyYXRlIG9uIHRoaXMgcGFydGljdWxhciB1 c2UgY2FzZSBzZWVtcyB0byBtZSB1bndhcnJhbnRlZCBmYXRlIHNoYXJpbmcuDQoNCkknbGwgYnV5 IHRoYXQgYXJndW1lbnQuICBPbmUgbm90Y2ggc2ltcGxlciB3b3VsZCBiZSAic2VlLW90aGVyLWFk ZHJlc3MiLCB3aXRoIHNvbWUgaW5kaWNhdGlvbiBvZiB3aGV0aGVyIHlvdXIgaW5pdGlhbCBwYWNr ZXQgaGFkIGJlZW4gZm9yd2FyZGVkIG9yIG5vdC4NCg0KPklmIHlvdSB3YW50IGFuIGFwcGxpY2F0 aW9uLWxheWVyIHByb3RvY29sIHRoYXQgY2FuIGhhbmRsZSBzZXJ2aWNlIGhhbmRvZmYsIGluZm9y bWF0aW9uIGxpa2UgIlotMTUgaGFzIHBhdGggdG8gcGF0aCBpbmZvcm1hdGlvbiBmb3IgdHViZS1p ZCBOIiBhcyBhbiBhZHZpc29yeSBtZXNzYWdlIG1heSBiZSB1c2VmdWwuICAgIEJ1dCBpZiBaLTE1 IGhhcyBhIGRpZmZlcmVudCBJUCBhZGRyZXNzLCBhcyBhYm92ZSwgdGhlcmUgaXMgbm8gZ3VhcmFu dGVlIHRoYXQNCj4gdGhlIHBhdGggd2lsbCByZW1haW4gdGhlIHNhbWU7IGFueXRoaW5nIGZyb20g RUNNUCBvbiB1cCBtYXkgY2hhbmdlIGl0Lg0KDQpBZ3JlZS4NCg0KPkNhbGwgbWUgb2xkLWZhc2hp b25lZCAob3IgbWFrZSBtZSBvbmUsIGV2ZW4gYmV0dGVyKSwgYnV0IEkgYmVsaWV2ZSBpdCBpcyBl YXNpZXIgaGVyZSB0byB1c2UgYW55Y2FzdCBJUCBhZGRyZXNzaW5nIGZvciB0aGUgc291cmNlIGFk ZHJlc3NlcyANCg0KRGlkIHlvdSBtZWFuIHRoZSByZXNwb25kZXIncyAoc2VydmVyJ3M/KSBhZGRy ZXNzIGhlcmU/ICAiU291cmNlIiBpcyBhIGxpdHRsZSBjb25mdXNpbmcgdG8gbWUuDQoNCj53aGls ZSBhbGxvd2luZyB0aGUgdHViZS1pZCB0byBiZSB1c2VkIHRvIGRpc3BhdGNoIHRvIHRoZSByaWdo dCBiYWNrIGVuZC4gIEluIGFuIFNETiB3b3JsZCwgeW91IG1pZ2h0IG5vdCBldmVuIG5lZWQgdGhh dA0KPiB0byBiZSBpbiBMLCBidXQgaW4gdGhlIGJhc2VsaW5lIG5ldHdvcmsgZWxlbWVudHMgbWF0 Y2hpbmcgdGFibGVzLg0KDQpUaGF0IGRvZXNuJ3Qgc291bmQgb2xkLWZhc2hpb25lZCB0byBtZSBh dCBhbGwuIChJIGhvcGUgdGhpcyBtZXNzYWdlIGJlY29tZXMgdGhlIHRvcCBHb29nbGUgaGl0IGZv ciAiZ29vZCBvbGQtZmFzaGlvbmVkIFNETiIsIGZvciBleGFtcGxlKQ0KDQpJIGxpa2UgdGhlIHBv dGVudGlhbCBjb21iaW5hdGlvbnMgb2YgYW55Y2FzdCwgU0ROLCBhbmQgdHViZS1JRHMgYXMgc3Vi LWFkZHJlc3NlcywgdGhvdWdoLiAgVGhlIHJlc3BvbmRlciBwcm9iYWJseSBuZWVkcyB0byBub3Rl IHRoZSBhZGRyZXNzIHRoYXQgd2FzIHVzZWQgdG8gcmVhY2ggaXQsIGFuZCB1c2UgdGhhdCBhZGRy ZXNzIGFzIHRoZSBzb3VyY2Ugb24gaXQncyBvdXRib3VuZCBwYWNrZXRzIC0gc2VuZG1zZygyKSBh bGxvd3MgZm9yIHRoYXQgb24gc29tZSBzeXN0ZW1zLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoN Cg0KDQo= From nobody Tue Mar 10 14:29:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D21A8A75 for ; Tue, 10 Mar 2015 14:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 EPHvvKMT_s5J for ; Tue, 10 Mar 2015 14:29:22 -0700 (PDT) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id B0A081A8982 for ; Tue, 10 Mar 2015 14:29:22 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 00DC73A02F for ; Tue, 10 Mar 2015 17:29:16 -0400 (EDT) Received: by qcyl6 with SMTP id l6so5502756qcy.10 for ; Tue, 10 Mar 2015 14:29:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.239.194 with SMTP id k185mr15778927qhc.2.1426022951718; Tue, 10 Mar 2015 14:29:11 -0700 (PDT) Received: by 10.140.104.115 with HTTP; Tue, 10 Mar 2015 14:29:11 -0700 (PDT) In-Reply-To: <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> Date: Tue, 10 Mar 2015 17:29:11 -0400 Message-ID: From: Patrick McManus To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11359ebe7a97ad0510f5d7db Archived-At: Cc: Patrick McManus , Ted Hardie , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:29:23 -0000 --001a11359ebe7a97ad0510f5d7db Content-Type: text/plain; charset=UTF-8 On Tue, Mar 10, 2015 at 5:15 PM, Brian Trammell wrote: > What I can see being useful here is a facility built in to the "core" spud > vocabulary that says "this tube is related to some other tube, here's the > ID", for a small set of values of "related". This is more a signal to the > remote endpoint than the path, though, so it's not clear it needs to be > exposed in SPUD. I think you can extend the use case under discussion to think about this as a second tube initiated in the opposite direction. If I have tube (a->b) started on my home lan that goes through my nat.. and I get back tube (c->a [related to a->b]) then the tube is implicitly asking to be allowed through the "nat/firewally-properties" based on the fact that a->b is alive and was initiated from the a side. That's probably got some ugly properties - but for handoff it has some nice ones (no rendezvous or simultaneous open tricks, etc..).. maybe worth exploring. Or maybe we've explored it here already ;) It just seems if we're going to be signalling middleboxes, this is one of the roles they play. --001a11359ebe7a97ad0510f5d7db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Mar 10, 2015 at 5:15 PM, Brian Trammell <ietf@trammell.ch> wrote:
What I can see being useful = here is a facility built in to the "core" spud vocabulary that sa= ys "this tube is related to some other tube, here's the ID", = for a small set of values of "related". This is more a signal to = the remote endpoint than the path, though, so it's not clear it needs t= o be exposed in SPUD.


I think you can extend the use case under discussion to think about t= his as a second tube initiated in the opposite direction.

If I have tube (a->b) started on my home lan that= goes through my nat.. and I get back tube (c->a [related to a->b]) t= hen the tube is implicitly asking to be allowed through the "nat/firew= ally-properties" based on the fact that a->b is alive and was initi= ated from the a side. That's probably got some ugly properties - but fo= r handoff it has some nice ones (no rendezvous or simultaneous open tricks,= etc..).. maybe worth exploring. Or maybe we've explored it here alread= y ;)

It just seems if we're going to be signalling middleboxes, = this is one of the roles they play.


--001a11359ebe7a97ad0510f5d7db-- From nobody Tue Mar 10 14:31:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9911D1A8A93 for ; Tue, 10 Mar 2015 14:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 DdfDwlvJ5Kva for ; Tue, 10 Mar 2015 14:31:41 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 1D0861A8A83 for ; Tue, 10 Mar 2015 14:31:41 -0700 (PDT) Received: by igdh15 with SMTP id h15so7811643igd.3 for ; Tue, 10 Mar 2015 14:31:40 -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:content-type; bh=a4hDvS0LdiXPxIX1y2+4SJUaVP9yjCPLJa7c0rZ/T0Q=; b=xyNRj2O9GXCoJuod9fGy0dunr3ehqMfPnaeQShxV+0CEtQbJZGS3ulxrw43qierGwH vMQFDoIkKceYv3f/7dZKM2crKzM2CHozasfg/0cFQEonAIPH/2yuyyXo7HQ3sq97zH5p iEV3WclbEq1GGdfrlnW18squLTDiT5XmlQNCAraneCYx33/LkTjbemE9XfRLGQyGhyfL b57vGAAmhSwts0i5q285o01RggXCgvl5UcKrarqkcnacdpRbI42zd3falCteuVyjBGMh Ee6+xnXOPNPDWeB7+oyUkkbLUKEWGqhO1KEU/SWgNLhb4yOYw951Ks8LnmWJ1t0KEzq3 SjHg== MIME-Version: 1.0 X-Received: by 10.107.167.145 with SMTP id q139mr61195892ioe.16.1426023100610; Tue, 10 Mar 2015 14:31:40 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Tue, 10 Mar 2015 14:31:40 -0700 (PDT) In-Reply-To: <077EA8A3-8086-4F41-A782-49B36733AA97@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <077EA8A3-8086-4F41-A782-49B36733AA97@cisco.com> Date: Tue, 10 Mar 2015 14:31:40 -0700 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a114299905a7d5b0510f5e0b1 Archived-At: Cc: Patrick McManus , "spud@ietf.org" Subject: Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:31:42 -0000 --001a114299905a7d5b0510f5e0b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2015 at 2:16 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > >Call me old-fashioned (or make me one, even better), but I believe it is > easier here to use anycast IP addressing for the source addresses > > Did you mean the responder's (server's?) address here? "Source" is a > little confusing to me. > > =E2=80=8BYes, I did, sorry for the lack of clarity.=E2=80=8B > >while allowing the tube-id to be used to dispatch to the right back end. > In an SDN world, you might not even need that > > to be in L, but in the baseline network elements matching tables. > > That doesn't sound old-fashioned to me at all. (I hope this message > becomes the top Google hit for "good old-fashioned SDN", for example) > > I like the potential combinations of anycast, SDN, and tube-IDs as > sub-addresses, though. The responder probably needs to note the address > that was used to reach it, and use that address as the source on it's > outbound packets - sendmsg(2) allows for that on some systems. > > =E2=80=8BThe critical thing about using tube-IDs as sub-addresses (or dis= patch tokens, if you prefer), is that the SDN system you're using has to see them in the bits of the address it sees. This, it turns out, may not be trivial, though updates to the relevant standards to make it so are possible. Ted > -- > Joe Hildebrand > > > > --001a114299905a7d5b0510f5e0b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 10, 2015 at 2:16 PM= , Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
>Call me old-fashioned (or make me one, even better), but I believe it i= s easier here to use anycast IP addressing for the source addresses

Did you mean the responder's (server's?) address here?=C2=A0= "Source" is a little confusing to me.

=E2=80=8BYes, I did= , sorry for the lack of clarity.=E2=80=8B

=C2=A0
>while allowing the tube-id to be used to dispatch to the right back end= .=C2=A0 In an SDN world, you might not even need that
> to be in L, but in the baseline network elements matching tables.

That doesn't sound old-fashioned to me at all. (I hope this mess= age becomes the top Google hit for "good old-fashioned SDN", for = example)

I like the potential combinations of anycast, SDN, and tube-IDs as sub-addr= esses, though.=C2=A0 The responder probably needs to note the address that = was used to reach it, and use that address as the source on it's outbou= nd packets - sendmsg(2) allows for that on some systems.

=E2=80=8BThe critical thing about using tube-IDs as sub-a= ddresses (or dispatch tokens, if you prefer), is that the SDN system you= 9;re using has to see them in the bits of the address it sees.=C2=A0 This, = it turns out, may not be trivial, though updates to the relevant standards = to make it so are possible.

Ted


=C2= =A0
--
Joe Hildebrand




--001a114299905a7d5b0510f5e0b1-- From nobody Tue Mar 10 14:31:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4131A8AA7 for ; Tue, 10 Mar 2015 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 bZ51TcPE6ge1 for ; Tue, 10 Mar 2015 14:31:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443921A8A94 for ; Tue, 10 Mar 2015 14:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2366; q=dns/txt; s=iport; t=1426023105; x=1427232705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=leZeW76ctwAY8La0+5IqVnkWFbVLFAV4rt0MEszfGM8=; b=e7TxuiAZEz0c6OUwix3epQUCI3jbhOVblY04J52ITom+53hTre5onhBR XjZuzCzOE9fk5NjZe9Iv9qJVa1oZsE3ZEs1CFgjeSy0rKkrJIgeC4Jabg A2VjPuEcNJvjEOP1FyL7bpwOV/VEmMuI2tDZVKGL693nNtSpqJRd6Mqsv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8CQC+Yf9U/5tdJa1cgwaBLASDBr1viCcCHIEXTQEBAQEBAXyEEAEBBCMRPgUCEAIBCA4MAiYCAgIwFRACBAENBYgvqjybQgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hDszB4JoL4EWAQSQGYlbk3cjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="402518927" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Mar 2015 21:31:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALViYl003025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:31:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:31:44 -0500 From: "Joe Hildebrand (jhildebr)" To: Brian Trammell , Patrick McManus Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQW3dQCPwWSuN47kWqINgVg9Lj250WK4KA Date: Tue, 10 Mar 2015 21:31:44 +0000 Message-ID: <5F294E01-B194-4969-8603-671D57569637@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> In-Reply-To: <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.66.71] Content-Type: text/plain; charset="utf-8" Content-ID: <5E1256BDF53B8344AEA257F0CFC50957@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:31:52 -0000 T24gMy8xMC8xNSwgMzoxNSBQTSwgIkJyaWFuIFRyYW1tZWxsIiA8aWV0ZkB0cmFtbWVsbC5jaD4g d3JvdGU6DQoNCj5XaGF0IEkgY2FuIHNlZSBiZWluZyB1c2VmdWwgaGVyZSBpcyBhIGZhY2lsaXR5 IGJ1aWx0IGluIHRvIHRoZSAiY29yZSIgc3B1ZCB2b2NhYnVsYXJ5IHRoYXQgc2F5cyAidGhpcyB0 dWJlIGlzIHJlbGF0ZWQgdG8gc29tZSBvdGhlciB0dWJlLCBoZXJlJ3MgdGhlIElEIiwgZm9yIGEg c21hbGwgc2V0IG9mIHZhbHVlcyBvZiAicmVsYXRlZCIuIFRoaXMgaXMgbW9yZSBhIHNpZ25hbCB0 byB0aGUgcmVtb3RlIGVuZHBvaW50IHRoYW4gdGhlIHBhdGgsIHRob3VnaCwgc28gaXQncyBub3Qg Y2xlYXIgaXQgbmVlZHMgdG8gYmUgZXhwb3NlZCBpbiBTUFVELiANCg0KSSB0aGluayB5b3UncmUg cmlnaHQgdGhhdCB0aGUgdHViZSByZWxhdGlvbnNoaXBzIGRvbid0IG5lZWQgdG8gYmUgbWFkZSBl eHBsaWNpdCB0byBwYXRoIGVsZW1lbnRzLiAgU3RpdGNoaW5nIHRvZ2V0aGVyIG11bHRpcGxlIHR1 YmVzIGludG8gYSBzZXNzaW9uLWxpa2UgdGhpbmcgc2VlbXMgbGlrZSBhIGpvYiBmb3IgdGhlIG5l dyBsYXllciBpbnNpZGUgU1BVRC4gIEluIHRoaXMgY2FzZSwgd2hlbmV2ZXIgeW91IG5lZWRlZCBh IG5ldyA1dHVwbGUsIHlvdSdkIGNyYW5rIHVwIGEgbmV3IHR1YmUuICBTaW1pbGFyIHRvIG1wdGNw LCBidXQgd2l0aG91dCB0eWluZyB0aGUgZmxvd3MgdG9nZXRoZXIuDQoNCj5PbmUgdHViZSBJRCBs aW5rYWdlIHRoYXQgd291bGQgbmVlZCB0byBiZSBleHBvc2VkIHRvIHRoZSBwYXRoIGlzICJwcmVm ZXIgdG8gZHJvcCBwYWNrZXRzIGluIHRoaXMgdHViZSBiZWZvcmUgcGFja2V0cyBpbiB0dWJlIElE IHgiIG9yICJwcmVmZXIgdG8gZm9yd2FyZCBwYWNrZXRzIGluIHR1YmUgSUQgeCBiZWZvcmUgcGFj a2V0cyBpbiB0aGlzIHR1YmUiLCB3aGljaCBnaXZlcyB5b3UgYSBuaWNlIHNpbXBsZSB2b2NhYnVs YXJ5IGZvciBleHByZXNzaW5nIGFsbW9zdCBldmVyeXRoaW5nIHlvdSBuZWVkIHRvIGZvciBkaWZm ZXJlbnRpYWwgUW9TIGZyb20gYSBnaXZlbiBzb3VyY2Ugd2l0aG91dCBhbGxvd2luZyBnbG9iYWwg bWFya2luZyB3aXRoIGFsbCBpdHMgYXR0ZW5kYW50IG1hcmsgaW5mbGF0aW9uIHByb2JsZW1zLg0K DQpUaGF0J3MgYSBkaWZmZXJlbnQga2luZCBvZiByZWxhdGlvbnNoaXAgdGhhbiBJIHdhcyBjb25z aWRlcmluZy4gIEkgdGhpbmsgdGhhdCB3b3VsZCBEYW4gV2luZyBhbmQgUGFsIE1hcnRpbnNlbiB0 aGUgdG9vbHMgdGhleSBuZWVkIGZvciBtZWRpYSBRb1MuICANCg0KPk9mIGNvdXJzZSwgc2luY2Ug ZXZlcnl0aGluZyBhbG9uZyB0aGUgcGF0aCBhbmQgZXZlcnl0aGluZyBjb29wZXJhdGluZyB3aXRo IGV2ZXJ5dGhpbmcgYWxvbmcgdGhlIHBhdGgga25vd3MgdGhlIHR1YmUgaWQsIGFueSB0dWJlIGxp bmthZ2UgZmVhdHVyZXMgcHJvYmFibHkgaGF2ZSBpbXBsaWNhdGlvbnMgZm9yIHNwb29maW5nIHdl J2xsIG5lZWQgdG8gYmUgY2FyZWZ1bCBhYm91dC4NCg0KVGhlcmUgd291bGQgaGF2ZSB0byBiZSBz b21lIHNvcnQgb2YgcHJvb2YgdGhhdCB0aGUgZmxvd3MgYXJlIGZyb20gdGhlICJzYW1lIiBlbmRw b2ludDsgbWF5YmUgdGhlIG9wZW4gcGFja2V0cyB3b3VsZCBpbmNsdWRlIHNvbWV0aGluZyBzaWdu ZWQgYnkgdGhlIHNhbWUgcHJpdmF0ZSBrZXksIGZvciBpbnN0YW5jZS4NCg0KDQotLSANCkpvZSBI aWxkZWJyYW5kDQoNCg0KDQo= From nobody Tue Mar 10 14:35:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF81A8AA6 for ; Tue, 10 Mar 2015 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 CKLKLb0fQu7u for ; Tue, 10 Mar 2015 14:35:02 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 745EB1A8A9D for ; Tue, 10 Mar 2015 14:35:02 -0700 (PDT) Received: by igdh15 with SMTP id h15so7836521igd.3 for ; Tue, 10 Mar 2015 14:35:02 -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:content-type; bh=Ep/Ro4KxnAlql9l4NF30mj33Cbb06hV0VwlXo2o8xkE=; b=z73MaRHxF4gIdYmXfEgcgkzneyMJnDCxzvD7eRvu35y/RfkkgAJS5+tXpX6wm0TopT iS2NBRUaYjqo2hTFyODBWyPutCx5iBlQjm6nmVmTfPjEigMhgMfgmg57Bq2lt8PUsL91 9U3J18dfC0kCu0w/bqGQV4Hj+tMNLLwg01iTn/Qj8eceWUVaLOcwd+Jzn3mmdgcPmX8s tL4EdflQ/CHAx0rBlMuSy4HOj86MCchadZKFbR3vS9QVulltU04Bgph5eqZmnAuGGc5s NHrkHzhxZ5pYgup1KgH6sMnq8RptE+9DTgEkv9qx+0DU3Evy0Nbn32fMN3NCMHIioLAC SBLQ== MIME-Version: 1.0 X-Received: by 10.107.135.75 with SMTP id j72mr21679854iod.0.1426023301993; Tue, 10 Mar 2015 14:35:01 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Tue, 10 Mar 2015 14:35:01 -0700 (PDT) In-Reply-To: <5F294E01-B194-4969-8603-671D57569637@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> Date: Tue, 10 Mar 2015 14:35:01 -0700 Message-ID: From: Ted Hardie To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a113fb98e5b7c6f0510f5ecee Archived-At: Cc: Brian Trammell , "spud@ietf.org" , Patrick McManus Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:35:04 -0000 --001a113fb98e5b7c6f0510f5ecee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2015 at 2:31 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > >One tube ID linkage that would need to be exposed to the path is "prefer > to drop packets in this tube before packets in tube ID x" or "prefer to > forward packets in tube ID x before packets in this tube", which gives yo= u > a nice simple vocabulary for expressing almost everything you need to for > differential QoS from a given source without allowing global marking with > all its attendant mark inflation problems. > > =E2=80=8BYes, that's quite similar to the "ordinal priority" requirement = that we discussed in relation to WebRTC where you may want to indication which of a related set of flows should have priority based on application semantics). That's a different kind of relationship than I was considering. I think > that would Dan Wing and Pal Martinsen the tools they need for media QoS. > > >Of course, since everything along the path and everything cooperating > with everything along the path knows the tube id, any tube linkage featur= es > probably have implications for spoofing we'll need to be careful about. > > There would have to be some sort of proof that the flows are from the > "same" endpoint; maybe the open packets would include something signed by > the same private key, for instance. > =E2=80=8BAre you thinking a TOFU-like trust? I can demonstrate that flow N= and flow N+1 are from the same source, even though I cannot tell you anything about the source that emitted them? Ted=E2=80=8B --001a113fb98e5b7c6f0510f5ecee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 10, 2015 at 2:31 PM= , Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
=
=
>One tube ID linkage that would need to be exposed to the path is "= prefer to drop packets in this tube before packets in tube ID x" or &q= uot;prefer to forward packets in tube ID x before packets in this tube"= ;, which gives you a nice simple vocabulary for expressing almost everythin= g you need to for differential QoS from a given source without allowing glo= bal marking with all its attendant mark inflation problems.

=E2=80=8BYes, that's quite simil= ar to the "ordinal priority" requirement that we discussed in rel= ation to WebRTC where you may want to indication which of a related set of = flows should have priority based on application semantics).


That's a different kind of relationship than I was considering.= =C2=A0 I think that would Dan Wing and Pal Martinsen the tools they need fo= r media QoS.

>Of course, since everything along the path and everything cooperating w= ith everything along the path knows the tube id, any tube linkage features = probably have implications for spoofing we'll need to be careful about.=

There would have to be some sort of proof that the flows are from th= e "same" endpoint; maybe the open packets would include something= signed by the same private key, for instance.

=E2=80=8BAre = you thinking a TOFU-like trust?=C2=A0 I can demonstrate that flow N and flo= w N+1 are from the same source, even though I cannot tell you anything abou= t the source that emitted them?

Ted=E2=80=8B
=C2=A0
--001a113fb98e5b7c6f0510f5ecee-- From nobody Tue Mar 10 14:38:24 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425EF1A8A6A for ; Tue, 10 Mar 2015 14:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZoR9ZR6gmLbe for ; Tue, 10 Mar 2015 14:38:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CE01A87AC for ; Tue, 10 Mar 2015 14:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1426023502; x=1427233102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=etoY7YrbpICybH4MZDm6jsSvprcTTEveKdqIfgCUKkE=; b=bEVUdW1zhO2QeYcHrTSrwWIQ1/x6V4z5i1qEgCOOJ5lnM7IormiiDwuT flXefTJMkbxKuWLYCCaX/RbqFYzTUoclpxxI3IWt1nq3wWw6GXl9cU2pP VY9GWTILEXPjIII2fa6RO8MjE7yGdLgpewxat9WLLukP20cxhNgOGEbJJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8CQCkY/9U/4gNJK1cgwaBLASDBr1viCcCHIEXTQEBAQEBAXyEEAEBBCMRQwIQAgEIGgImAgICHxEVEAIEDgWIGwMRqkKWCw2FKAEBAQEBAQEBAQEBAQEBAQEBAQEBGIEhiXaCRIF3MweCaC+BFgEEkBmGBIINgUqNY4YUI4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="402580747" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 10 Mar 2015 21:38:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALcKQl010438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:38:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:38:20 -0500 From: "Joe Hildebrand (jhildebr)" To: Ted Hardie Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQW3dQCPwWSuN47kWqINgVg9Lj250WK4KAgABlgYD//5xXgA== Date: Tue, 10 Mar 2015 21:38:19 +0000 Message-ID: <11346183-2A54-4190-B408-74B94EC351B8@cisco.com> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.66.71] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "spud@ietf.org" , Patrick McManus Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:38:23 -0000 T24gMy8xMC8xNSwgMzozNSBQTSwgIlRlZCBIYXJkaWUiIDx0ZWQuaWV0ZkBnbWFpbC5jb20+IHdy b3RlOg0KDQo+4oCLQXJlIHlvdSB0aGlua2luZyBhIFRPRlUtbGlrZSB0cnVzdD8gIEkgY2FuIGRl bW9uc3RyYXRlIHRoYXQgZmxvdyBOIGFuZCBmbG93IE4rMSBhcmUgZnJvbSB0aGUgc2FtZSBzb3Vy Y2UsIGV2ZW4gdGhvdWdoIEkgY2Fubm90IHRlbGwgeW91IGFueXRoaW5nIGFib3V0IHRoZSBzb3Vy Y2UgdGhhdCBlbWl0dGVkIHRoZW0/DQoNCkkgdGhpbmsgdGhhdCdzIHRoZSByaWdodCBwcm9wZXJ0 eSB0byBzaG9vdCBmb3IsIHByaXZhY3ktd2lzZS4gIElmIHRoZSBzZW5kZXIgd2FudHMgdG8gc2hh cmUgdGhlIGtleWluZyBpbmZvcm1hdGlvbiBhcm91bmQgdG8gYW5vdGhlciBib3ggaW4gb3JkZXIg dG8gZW5hYmxlIHR1YmUtc29ydGluZywgdGhhdCBpcyBpdHMgYnVzaW5lc3MuDQoNCkkgZ3Vlc3Mg dGhhdCdzIFRPRlUtaXNoIGluIHRoYXQgSSB3b3VsZCByZW1lbWJlciBhdCBsZWFzdCB0aGUgcHVi bGljIGtleSBpbmZvIGZyb20gdGhlIGZpcnN0IHR1YmUgaWYgSSB3YW50ZWQgdG8gZG8gdHViZS1z b3J0aW5nLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Tue Mar 10 14:40:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5AD1A8A6A for ; Tue, 10 Mar 2015 14:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GKeldfyJ4k5E for ; Tue, 10 Mar 2015 14:40:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569821A87AC for ; Tue, 10 Mar 2015 14:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1500; q=dns/txt; s=iport; t=1426023636; x=1427233236; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1jt8Mp8YrNGruK/ymV0eNnjoNx38ph1OWGnHcv5h6sg=; b=Wr+4AdRlICSgb7GGYpkylrnGV944vuk624u4rnFw9pBgSyFwso5KNu9x lchKNK49KU4S9gD4guoUkzEggIzP3hX2vXXb0U0Ii7/vJZqva5GnChc8Q q1gJ9ArtFSNro24M6egHoZxn+EJ6TiI4Iw8k8ayk+3Be91lngwa2vcSU0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8CQBOZP9U/5xdJa1cgwaBLASDBr1viCcCHIEXTQEBAQEBAXyEEAEBBCMEDUMCEAIBCBoCJgICAjAVEAIEAQ0FiC+qRptCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaEbgeCaC+BFgEEkBmJWwGTdiODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="402467772" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2015 21:40:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALeZGS014702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:40:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:40:35 -0500 From: "Joe Hildebrand (jhildebr)" To: Patrick McManus , Brian Trammell Thread-Topic: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt Thread-Index: AQHQW3dQCPwWSuN47kWqINgVg9Lj250Wj2KA//+emIA= Date: Tue, 10 Mar 2015 21:40:34 +0000 Message-ID: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150225 x-originating-ip: [10.24.66.71] Content-Type: text/plain; charset="utf-8" Content-ID: <977A83E3CD127547B47B33542D8846A3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:40:38 -0000 T24gMy8xMC8xNSwgMzoyOSBQTSwgIlBhdHJpY2sgTWNNYW51cyIgPG1jbWFudXNAZHVja3Nvbmcu Y29tPiB3cm90ZToNCg0KPkkgdGhpbmsgeW91IGNhbiBleHRlbmQgdGhlIHVzZSBjYXNlIHVuZGVy IGRpc2N1c3Npb24gdG8gdGhpbmsgYWJvdXQgdGhpcyBhcyBhIHNlY29uZCB0dWJlIGluaXRpYXRl ZCBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLg0KDQpUaGF0J3MgYW4gaW50ZXJlc3Rpbmcgd2F5 IG9mIHRoaW5raW5nIGFib3V0IGl0LiANCg0KPklmIEkgaGF2ZSB0dWJlIChhLT5iKSBzdGFydGVk IG9uIG15IGhvbWUgbGFuIHRoYXQgZ29lcyB0aHJvdWdoIG15IG5hdC4uIGFuZCBJIGdldCBiYWNr IHR1YmUgKGMtPmEgW3JlbGF0ZWQgdG8gYS0+Yl0pIHRoZW4gdGhlIHR1YmUgaXMgaW1wbGljaXRs eSBhc2tpbmcgdG8gYmUgYWxsb3dlZCB0aHJvdWdoIHRoZSAibmF0L2ZpcmV3YWxseS1wcm9wZXJ0 aWVzIiBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IGEtPmINCj4gaXMgYWxpdmUgYW5kIHdhcyBpbml0 aWF0ZWQgZnJvbSB0aGUgYSBzaWRlLiBUaGF0J3MgcHJvYmFibHkgZ290IHNvbWUgdWdseSBwcm9w ZXJ0aWVzIC0gYnV0IGZvciBoYW5kb2ZmIGl0IGhhcyBzb21lIG5pY2Ugb25lcyAobm8gcmVuZGV6 dm91cyBvciBzaW11bHRhbmVvdXMgb3BlbiB0cmlja3MsIGV0Yy4uKS4uIG1heWJlIHdvcnRoIGV4 cGxvcmluZy4gT3IgbWF5YmUgd2UndmUgZXhwbG9yZWQgaXQgaGVyZSBhbHJlYWR5IDspDQo+DQo+ SXQganVzdCBzZWVtcyBpZiB3ZSdyZSBnb2luZyB0byBiZSBzaWduYWxsaW5nIG1pZGRsZWJveGVz LCB0aGlzIGlzIG9uZSBvZiB0aGUgcm9sZXMgdGhleSBwbGF5Lg0KDQpUaGUgZmlyZXdhbGwgcGVv cGxlIGFyZW4ndCBnb2luZyB0byBiZSB2ZXJ5IGV4Y2l0ZWQgYWJvdXQgaW5ib3VuZCBvcGVuIHBh Y2tldHMgdW5sZXNzIHdlIGNhbiBkbyBhIHN0cm9uZyBoYW5kLW9mZiBmcm9tIG9uZSBmbG93IHRv IHRoZSBuZXh0LiAgSSB3b25kZXIgaWYgdGhpcyBlbmRzIHVwIGJlaW5nIHRoZSBzYW1lIG1hdGgg YXMgdGhlIHR1YmUgYnVuZGxpbmcgYml0cyBmb3IgUW9TLi4uDQoNCg0KLS0gDQpKb2UgSGlsZGVi cmFuZA0KDQoNCg0K From nobody Wed Mar 11 06:32:32 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070651A8A9B for ; Wed, 11 Mar 2015 06:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 w4s-a6WbmUDr for ; Wed, 11 Mar 2015 06:32:30 -0700 (PDT) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [IPv6:2001:bf0:c000::1:8]) (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 A30201A8799 for ; Wed, 11 Mar 2015 06:32:28 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t2BDWFT5004046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Mar 2015 14:32:15 +0100 Received: from hedwig.krautrouting.org ([217.197.86.49]) by x-berg.in-berlin.de with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1YVgkB-0008Hp-1v; Wed, 11 Mar 2015 14:32:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Philipp S. Schmidt" In-Reply-To: <5F294E01-B194-4969-8603-671D57569637@cisco.com> Date: Wed, 11 Mar 2015 14:32:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Brian Trammell , Ted Hardie , "spud@ietf.org" , Patrick McManus Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:32:32 -0000 My first impression about SPUD was more of a session layer than of = =E2=80=9Cjust=E2=80=9D a middle box signaling layer=E2=80=A6 > On 10.03.2015, at 22:31, Joe Hildebrand (jhildebr) = wrote: >=20 > On 3/10/15, 3:15 PM, "Brian Trammell" wrote: >=20 >> What I can see being useful here is a facility built in to the "core" = spud vocabulary that says "this tube is related to some other tube, = here's the ID", for a small set of values of "related". This is more a = signal to the remote endpoint than the path, though, so it's not clear = it needs to be exposed in SPUD.=20 >=20 > I think you're right that the tube relationships don't need to be made = explicit to path elements. Stitching together multiple tubes into a = session-like thing seems like a job for the new layer inside SPUD. In = this case, whenever you needed a new 5tuple, you'd crank up a new tube. = Similar to mptcp, but without tying the flows together. =E2=80=A6 therefore I would rather think of the Tube ID as some kind of = session ID all flows that belong to a session share. A little like the key in MP_CAPABLE extension = of MPTCP. This implies there can be multiple conversations on different 5-tupels = sharing a Tube ID. >=20 >> One tube ID linkage that would need to be exposed to the path is = "prefer to drop packets in this tube before packets in tube ID x" or = "prefer to forward packets in tube ID x before packets in this tube", = which gives you a nice simple vocabulary for expressing almost = everything you need to for differential QoS from a given source without = allowing global marking with all its attendant mark inflation problems. >=20 > That's a different kind of relationship than I was considering. I = think that would Dan Wing and Pal Martinsen the tools they need for = media QoS. In case of such a thing, I would rather try to avoid using Tube IDs. >> Of course, since everything along the path and everything cooperating = with everything along the path knows the tube id, any tube linkage = features probably have implications for spoofing we'll need to be = careful about. >=20 > There would have to be some sort of proof that the flows are from the = "same" endpoint; maybe the open packets would include something signed = by the same private key, for instance. The question is: do we care - or do we expect that packets related to = this tube should be checked by the application to e.g. allow middle = boxes to announce an alternative endpoint by referencing the tube id? AVE! Philipp S. Schmidt / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <---(phone: +49-179-6737439)---<---(jabber: = phils@jabber.ccc.de)---' From nobody Wed Mar 11 06:47:38 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747631A010C for ; Wed, 11 Mar 2015 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 r7pnNTmh-2ys for ; Wed, 11 Mar 2015 06:47:35 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3C41A87E8 for ; Wed, 11 Mar 2015 06:47:35 -0700 (PDT) Received: from public-docking-etx-2847.ethz.ch (public-docking-pat-etx-mapped-0014.ethz.ch [195.176.110.239]) by trammell.ch (Postfix) with ESMTPSA id D91411A00F4; Wed, 11 Mar 2015 14:47:03 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EBB6B87E-B47F-4634-98A1-682138FBD9D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: Date: Wed, 11 Mar 2015 14:47:03 +0100 Message-Id: <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> To: "Philipp S. Schmidt" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Patrick McManus , Ted Hardie , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 13:47:37 -0000 --Apple-Mail=_EBB6B87E-B47F-4634-98A1-682138FBD9D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Mar 2015, at 14:32, Philipp S. Schmidt = wrote: >=20 > My first impression about SPUD was more of a session layer than of = =E2=80=9Cjust=E2=80=9D a middle box signaling layer=E2=80=A6 >=20 >> On 10.03.2015, at 22:31, Joe Hildebrand (jhildebr) = wrote: >>=20 >> On 3/10/15, 3:15 PM, "Brian Trammell" wrote: >>=20 >>> What I can see being useful here is a facility built in to the = "core" spud vocabulary that says "this tube is related to some other = tube, here's the ID", for a small set of values of "related". This is = more a signal to the remote endpoint than the path, though, so it's not = clear it needs to be exposed in SPUD. >>=20 >> I think you're right that the tube relationships don't need to be = made explicit to path elements. Stitching together multiple tubes into = a session-like thing seems like a job for the new layer inside SPUD. In = this case, whenever you needed a new 5tuple, you'd crank up a new tube. = Similar to mptcp, but without tying the flows together. >=20 > =E2=80=A6 therefore I would rather think of the Tube ID as some kind = of session ID all flows that > belong to a session share. A little like the key in MP_CAPABLE = extension of MPTCP. > This implies there can be multiple conversations on different 5-tupels = sharing a Tube ID. It seems to me like part of the problem we're having here is that we = have (in the SPUD prototype) a single tube ID, which is endpoint and = path visible, and we're wanting to do things with it that have = fundamentally different scoping rules. Perhaps we can apply the question that led to the separation of TCP and = IP in the first place: does the path need to see it / can the path do = something universally useful with it? Put it in SPUD. Is it end-to-end? = Stick it above SPUD, encrypt it, and hide the key from the path. Put that way, session IDs binding flows together seem to me to be an = end-to-end thing. But of course different situations might have = different requirements. Cheers, Brian >>> One tube ID linkage that would need to be exposed to the path is = "prefer to drop packets in this tube before packets in tube ID x" or = "prefer to forward packets in tube ID x before packets in this tube", = which gives you a nice simple vocabulary for expressing almost = everything you need to for differential QoS from a given source without = allowing global marking with all its attendant mark inflation problems. >>=20 >> That's a different kind of relationship than I was considering. I = think that would Dan Wing and Pal Martinsen the tools they need for = media QoS. >=20 > In case of such a thing, I would rather try to avoid using Tube IDs. >=20 >>> Of course, since everything along the path and everything = cooperating with everything along the path knows the tube id, any tube = linkage features probably have implications for spoofing we'll need to = be careful about. >>=20 >> There would have to be some sort of proof that the flows are from the = "same" endpoint; maybe the open packets would include something signed = by the same private key, for instance. >=20 > The question is: do we care - or do we expect that packets related to = this tube should be checked by the application to e.g. allow middle = boxes to announce an alternative endpoint by referencing the tube id? >=20 > AVE! > Philipp S. Schmidt / phils=E2=80=A6 > -- > = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt = Schwitters) | > :wq! <---(phone: +49-179-6737439)---<---(jabber: = phils@jabber.ccc.de)---' >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_EBB6B87E-B47F-4634-98A1-682138FBD9D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVAEdXAAoJENt3nsOmbNJcJZoH/0BGPL1AAud/1pSBWJflmZUV wHEufyW004CMd6B0QZdz2lYB9QCZ0T/xH/L1utKzw08MMQWNlRT89yPqhyYexnsK ABf1jpifJUZu1XaqLtA3tM2Kn9YqR82VgTcUxmvsYfFRjQX47c+5xRk9KWi2gwcI FFtz8lKepILIY9aZ37q/3AdLymApM6gDlv2ppmg+DnwW7VNVLr2LwkLBrpR+16K9 laalO29k+j1RayGtuQ+s2/enxo2jcNJR30AQ0KIFkNYD7iSoTPlRZuqUxKqLshoU sQM6ZRAAyTdJeEacdakwdWqAoN0hhfFORlk2AdHuMx+htyxHY3rgyk447BVQ/SA= =WCYN -----END PGP SIGNATURE----- --Apple-Mail=_EBB6B87E-B47F-4634-98A1-682138FBD9D3-- From nobody Wed Mar 11 07:52:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EDE1AC41D for ; Wed, 11 Mar 2015 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 8mJHAI3XRxiT for ; Wed, 11 Mar 2015 07:52:39 -0700 (PDT) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E3AAA1A88E6 for ; Wed, 11 Mar 2015 07:52:38 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 46EEA3A022 for ; Wed, 11 Mar 2015 10:52:33 -0400 (EDT) Received: by qcwb13 with SMTP id b13so10731670qcw.9 for ; Wed, 11 Mar 2015 07:52:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.80.213 with SMTP id c79mr46070612qgd.74.1426085547942; Wed, 11 Mar 2015 07:52:27 -0700 (PDT) Received: by 10.140.104.115 with HTTP; Wed, 11 Mar 2015 07:52:27 -0700 (PDT) In-Reply-To: <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch> Date: Wed, 11 Mar 2015 10:52:27 -0400 Message-ID: From: Patrick McManus To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c120a28128870511046aa5 Archived-At: Cc: "Philipp S. Schmidt" , Ted Hardie , Patrick McManus , "Joe Hildebrand \(jhildebr\)" , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:52:39 -0000 --001a11c120a28128870511046aa5 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell wrote: > > Perhaps we can apply the question that led to the separation of TCP and IP > in the first place: does the path need to see it / can the path do > something universally useful with it? Put it in SPUD. Is it end-to-end? > Stick it above SPUD, encrypt it, and hide the key from the path. > > I like that as a guiding principle > Put that way, session IDs binding flows together seem to me to be an > end-to-end thing. But of course different situations might have different > requirements. > > I feel like the sticky part here is that middle boxes on the paths are playing a role here where the information can be useful.. in particular without this information they aren't able to route e2e based on just 5 tuple because of the nat/firewall translations they do. --001a11c120a28128870511046aa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:

Perhaps we can apply the question that led to the separation of TCP and IP = in the first place: does the path need to see it / can the path do somethin= g universally useful with it? Put it in SPUD. Is it end-to-end? Stick it ab= ove SPUD, encrypt it, and hide the key from the path.


I like that as a guiding principle
=
=C2=A0
Put that way, session IDs binding flows together seem to me to be an end-to= -end thing. But of course different situations might have different require= ments.


I feel like the sticky part here is th= at middle boxes on the paths are playing a role here where the information = can be useful.. in particular without this information they aren't able= to route e2e based on just 5 tuple because of the nat/firewall translation= s they do.



--001a11c120a28128870511046aa5-- From nobody Thu Mar 12 03:01:03 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDAB1A90CE for ; Thu, 12 Mar 2015 03:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 IGQRYPS4iuAN for ; Thu, 12 Mar 2015 03:01:01 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDD01A90D7 for ; Thu, 12 Mar 2015 03:01:01 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:52c8:8000::e9e] (unknown [IPv6:2001:67c:10ec:52c8:8000::e9e]) by trammell.ch (Postfix) with ESMTPSA id 38FA91A00F4; Thu, 12 Mar 2015 11:00:30 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5b5 Content-Type: multipart/signed; boundary="Apple-Mail=_7C235343-5EA1-4EE5-B657-07A52C639D61"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 12 Mar 2015 11:00:29 +0100 References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> To: stackevo@iab.org, spud@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Spud] Fwd: New Version Notification for draft-trammell-stackevo-newtea-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:01:02 -0000 --Apple-Mail=_7C235343-5EA1-4EE5-B657-07A52C639D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Shortly before the Monday deadline, I threw together a couple of = thoughts into a document that might eventually evolve into a more = architectural view of the vocabulary of the things we can expect to be = able to deployably say with SPUD (separate from the current discussion = on the scope of the tube ID). This follows from discussions about trying = to keep markings declarative. Comments welcome. Thanks, cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: "Brian Trammell" , "Brian Trammell" = > Subject: New Version Notification for = draft-trammell-stackevo-newtea-00.txt > Date: 9 Mar 2015 18:41:02 CET >=20 >=20 > A new version of I-D, draft-trammell-stackevo-newtea-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-trammell-stackevo-newtea > Revision: 00 > Title: Thoughts on New Transport Encapsulation = Approaches > Document date: 2015-03-09 > Group: Individual Submission > Pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt > Status: = https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/ > Htmlized: = http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00 >=20 >=20 > Abstract: > This document presently consists of a collection of unordered > thoughts about new approaches to using encapsulation in support of > stack evolution and new transport protocol deployment in an > increasingly encrypted Internet. It aims eventually to enumerate a > set of architectural assumptions for transport evolution based upon > new encapsulations, and discuss limitations on the vocabulary used = in > each of these new interfaces necessary to achieve deployment >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_7C235343-5EA1-4EE5-B657-07A52C639D61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVAWO+AAoJENt3nsOmbNJcUFMH/RB6Ow39TFl24A76Zi6+fyQk RKJWmWPveg9TpemLfe0JpYk7IPcatpzD2nYIcED9wBoVZwamPtd+yrztppNbnWDK s9EnBsGOFie2Ki4iIpRti193ABbVwiOoX/OXYWszXak7b/GoNtt68xzQ6uxEZTdP P672vf2FZ/qvX8tFX2MaloBHwsN4BL9zzcxKKTe6ijkRNnTdo7wnkx3/ad8M4kmD CarnL3kj1fW89AcpMjyv+JkAt90/fnYVuTBs1wxOov5dlwo99jqqWNY0QmRY55R6 9MBQF0KQ69Vz5uHSrabrdgIAHw53xQ8/5Rr/d/hbXJ2odO01HDGSDz7nh+Vn4Wk= =mOgM -----END PGP SIGNATURE----- --Apple-Mail=_7C235343-5EA1-4EE5-B657-07A52C639D61-- From nobody Thu Mar 12 14:00:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB58F1A90A9 for ; Thu, 12 Mar 2015 14:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 gpgU2dYkyk8F for ; Thu, 12 Mar 2015 14:00:27 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 6B13A1A90A7 for ; Thu, 12 Mar 2015 14:00:27 -0700 (PDT) Received: by igjz20 with SMTP id z20so492285igj.4 for ; Thu, 12 Mar 2015 14:00:27 -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:content-type; bh=l+p3V4Zqw32uR0e9qYqpU/9b75oybILBuNUOY6eV67A=; b=X4qZqomJJ8tfz8KTZkQdGhIfvC4siUUAZppumWlPSEnDxbw63dalqiqUvoLIyoB0Oe ypBIaNgsh+JDnrYHtl/WYLX5+2ua8qQ9gtmH6AZK99y/wBTnVnCjhvORyqreFOOErL+c XvGCcC3OKjcSoPT8sgJj1wYrBretN57OPU/q/I9RNV2SBbye1hnIbp7KSwPlKpxCfOXy OiciO/LhY3vD3jeTw4bM8wOYIrzxdaXcY3+5GSXNeLWCHJB4d3fZZaUyKERm1SHvP6mS 3s/H+n1fXGGmsFbmryFHp3Vcl5kGcb2zLZZGz/tCmT5ojPjYsj9cT0dUz0q+07fkl4wN fTIA== MIME-Version: 1.0 X-Received: by 10.107.167.145 with SMTP id q139mr79232745ioe.16.1426194026886; Thu, 12 Mar 2015 14:00:26 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Thu, 12 Mar 2015 14:00:26 -0700 (PDT) In-Reply-To: References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 14:00:26 -0700 Message-ID: From: Ted Hardie To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114299905a7e6a05111dacbd Archived-At: Cc: stackevo@iab.org, "spud@ietf.org" Subject: Re: [Spud] [Stackevo] Fwd: New Version Notification for draft-trammell-stackevo-newtea-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:00:30 -0000 --001a114299905a7e6a05111dacbd Content-Type: text/plain; charset=UTF-8 Hi Brian, Thanks for throwing something together (and it's amusing to see a draft which declares itself to have been done "a few minutes before" the deadline). Two thoughts, just as quick: First, you make an important observation about the scope of comparison, but you've buried it a bit. You note that declarative marking aims "to treat all markings on packets and flows as relative to other markings on packets and flows from the same sender". That should get a much bigger play in the next version, I think, as it both explains why the incentive to lie is no longer present and has a huge impact on the system. Per-sender comparative state make sense in some contexts (the scheduler in a browser, based on traffic from tabs, for example), but it gets harder and harder as you increase the number of senders and in some contexts may simply be too expensive. Doing this in contexts where you are already doing packet or flow state manipulation seems the likely target of this work, and it may be best to make it more explicit. The second thought is around reputation. There's a lot of experience with reputation systems that suggests that the ability to mint new identities and the ability to assign reputation are in conflict. NAT, DHCP-reassignment, new IPv6 privacy addresses and many other issues make assigning this reputation to IP-layer addresses problematic. Doing it at above that layer with a long-lived cryptographic token has very serious privacy implications and doing it without one means you can mint an identifier freely. A reputation that lasts for the duration of the flow doesn't have these issues, and it may be the best we can do at the moment. Thanks again for kicking off the discussion, Ted On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell wrote: > Greetings, all, > > Shortly before the Monday deadline, I threw together a couple of thoughts > into a document that might eventually evolve into a more architectural view > of the vocabulary of the things we can expect to be able to deployably say > with SPUD (separate from the current discussion on the scope of the tube > ID). This follows from discussions about trying to keep markings > declarative. > > Comments welcome. > > Thanks, cheers, > > Brian > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > To: "Brian Trammell" , "Brian Trammell" < > ietf@trammell.ch> > > Subject: New Version Notification for > draft-trammell-stackevo-newtea-00.txt > > Date: 9 Mar 2015 18:41:02 CET > > > > > > A new version of I-D, draft-trammell-stackevo-newtea-00.txt > > has been successfully submitted by Brian Trammell and posted to the > > IETF repository. > > > > Name: draft-trammell-stackevo-newtea > > Revision: 00 > > Title: Thoughts on New Transport Encapsulation Approaches > > Document date: 2015-03-09 > > Group: Individual Submission > > Pages: 6 > > URL: > http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/ > > Htmlized: > http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00 > > > > > > Abstract: > > This document presently consists of a collection of unordered > > thoughts about new approaches to using encapsulation in support of > > stack evolution and new transport protocol deployment in an > > increasingly encrypted Internet. It aims eventually to enumerate a > > set of architectural assumptions for transport evolution based upon > > new encapsulations, and discuss limitations on the vocabulary used in > > each of these new interfaces necessary to achieve deployment > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > _______________________________________________ > Stackevo mailing list > Stackevo@iab.org > https://www.iab.org/mailman/listinfo/stackevo > > --001a114299905a7e6a05111dacbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thanks for thro= wing something together (and it's amusing to see a draft which declares= itself to have been done "a few minutes before" the deadline).= =C2=A0 Two thoughts, just as quick:

First, you make = an important observation about the scope of comparison, but you've buri= ed it a bit.=C2=A0 You note that declarative marking aims "to treat al= l markings on packets and flows as relative to other markings on packets and flows from the same sender".=C2=A0= That should get a much bigger play in the next version, I think, as it bot= h explains why the incentive to lie is no longer present and has a huge imp= act on the system. =C2=A0 Per-sender comparative state make sense in some c= ontexts (the scheduler in a browser, based on traffic from tabs, for exampl= e), but it gets harder and harder as you increase the number of senders and= in some contexts may simply be too expensive.=C2=A0 Doing this in contexts= where you are already doing packet or flow state manipulation seems the li= kely target of this work, and it may be best to make it more explicit.
<= br>
The second thought is around reputation.=C2=A0 There'= ;s a lot of experience with reputation systems that suggests that the abili= ty to mint new identities and the ability to assign reputation are in confl= ict.=C2=A0 NAT, DHCP-reassignment, new IPv6 privacy addresses and many othe= r issues make assigning this reputation to IP-layer addresses problematic.= =C2=A0 Doing it at above that layer with a long-lived cryptographic token h= as very serious privacy implications and doing it without one means you can= mint an identifier freely. A reputation that lasts for the duration of the= flow doesn't have these issues, and it may be the best we can do at th= e moment.

Thanks again for kicking off the discussio= n,

Ted
On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell= <ietf@trammell.ch> wrote:
= Greetings, all,

Shortly before the Monday deadline, I threw together a couple of thoughts i= nto a document that might eventually evolve into a more architectural view = of the vocabulary of the things we can expect to be able to deployably say = with SPUD (separate from the current discussion on the scope of the tube ID= ). This follows from discussions about trying to keep markings declarative.=

Comments welcome.

Thanks, cheers,

Brian

> Begin forwarded message:
>
> From: internet-drafts@ietf= .org
> To: "Brian Trammell" <ietf@trammell.ch>, "Brian Trammell" <ietf@trammell.ch>
> Subject: New Version Notification for draft-trammell-stackevo-newtea-0= 0.txt
> Date: 9 Mar 2015 18:41:02 CET
>
>
> A new version of I-D, draft-trammell-stackevo-newtea-00.txt
> has been successfully submitted by Brian Trammell and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-trammell-stackevo-newtea<= br> > Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thoughts= on New Transport Encapsulation Approaches
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-03-09
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.= txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://d= atatracker.ietf.org/doc/draft-trammell-stackevo-newtea/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.= org/html/draft-trammell-stackevo-newtea-00
>
>
> Abstract:
>=C2=A0 =C2=A0This document presently consists of a collection of unorde= red
>=C2=A0 =C2=A0thoughts about new approaches to using encapsulation in su= pport of
>=C2=A0 =C2=A0stack evolution and new transport protocol deployment in a= n
>=C2=A0 =C2=A0increasingly encrypted Internet.=C2=A0 It aims eventually = to enumerate a
>=C2=A0 =C2=A0set of architectural assumptions for transport evolution b= ased upon
>=C2=A0 =C2=A0new encapsulations, and discuss limitations on the vocabul= ary used in
>=C2=A0 =C2=A0each of these new interfaces necessary to achieve deployme= nt
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>


_______________________________________________
Stackevo mailing list
Stackevo@iab.org
https://www.iab.org/mailman/listinfo/stackevo


--001a114299905a7e6a05111dacbd-- From nobody Thu Mar 12 15:15:57 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9E81AC3BA for ; Thu, 12 Mar 2015 15:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WqmfYXilp8z1 for ; Thu, 12 Mar 2015 15:15:55 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14D1AC3BC for ; Thu, 12 Mar 2015 15:15:55 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id A11881A01F1; Thu, 12 Mar 2015 23:15:24 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5CBEA5AE-DEB3-4C3E-846F-D05BAC1C8604"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: Date: Thu, 12 Mar 2015 23:15:23 +0100 Message-Id: References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> To: Ted Hardie X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stackevo@iab.org, "spud@ietf.org" Subject: Re: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 22:15:57 -0000 --Apple-Mail=_5CBEA5AE-DEB3-4C3E-846F-D05BAC1C8604 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Ted, > On 12 Mar 2015, at 22:00, Ted Hardie wrote: >=20 > Hi Brian, >=20 > Thanks for throwing something together (and it's amusing to see a = draft which declares itself to have been done "a few minutes before" the = deadline). Two thoughts, just as quick: >=20 > First, you make an important observation about the scope of = comparison, but you've buried it a bit. You note that declarative = marking aims "to treat all markings on packets and flows as relative to = other markings on packets and flows from the same sender". That should = get a much bigger play in the next version, I think, as it both explains = why the incentive to lie is no longer present and has a huge impact on = the system. Per-sender comparative state make sense in some contexts = (the scheduler in a browser, based on traffic from tabs, for example), = but it gets harder and harder as you increase the number of senders and = in some contexts may simply be too expensive. ...here the definition of "sender" might be somewhat flexible. NAT = breaks this as it does reputation, of course. So a sender might be an = "endpoint, flow, tube ID" tuple in SPUD. This of course ties into the = identifier scope question (and what knowing a tube ID proves about you). = which I've now convinced myself also needs to be addressed in the next = version ("tube ID" is a SPUD-specific concept, "packet group = linkability" is not). > Doing this in contexts where you are already doing packet or flow = state manipulation seems the likely target of this work, and it may be = best to make it more explicit. Yep. > The second thought is around reputation. There's a lot of experience = with reputation systems that suggests that the ability to mint new = identities and the ability to assign reputation are in conflict. NAT, = DHCP-reassignment, new IPv6 privacy addresses and many other issues make = assigning this reputation to IP-layer addresses problematic. ...this is why the section in question gets handwavey. It also ties into = the identifier scope question, although the traceability/reputation = tradeoff is unavoidable, and personally I come down on the = privacy-for-endpoints side of that one almost every time. On thinking a bit more about it, it's probably not realistic for devices = on path that in a situation where they have to identify endpoints by = address to be doing much reputation analysis anyway. I could see access = providers shunting users (by link) on to "ignore spud declaration" VLANs = if they get caught lying too often -- but this is in a context where all = the hardware, software, management, and process infrastructure to be = able to do things per user is already in place. > Doing it at above that layer with a long-lived cryptographic token = has very serious privacy implications and doing it without one means you = can mint an identifier freely. A reputation that lasts for the duration = of the flow doesn't have these issues, and it may be the best we can do = at the moment. This is another way to do it, though of course you can also always = freely mint another flow (with SPUD, merely by opening another tube on = the same fivetuple, even). Endpoints, though, are in a much better position to evaluate the = trustworthiness of path declarations, and in this case a coarse = remote-endpoint address identifier with a time decay function is = probably sufficient. Whether that actually improves quality of = connectivity/service for those endpoints is another question. > Thanks again for kicking off the discussion, And thanks for continuing it. Cheers, Brian > Ted >=20 > On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell = wrote: > Greetings, all, >=20 > Shortly before the Monday deadline, I threw together a couple of = thoughts into a document that might eventually evolve into a more = architectural view of the vocabulary of the things we can expect to be = able to deployably say with SPUD (separate from the current discussion = on the scope of the tube ID). This follows from discussions about trying = to keep markings declarative. >=20 > Comments welcome. >=20 > Thanks, cheers, >=20 > Brian >=20 > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > To: "Brian Trammell" , "Brian Trammell" = > > Subject: New Version Notification for = draft-trammell-stackevo-newtea-00.txt > > Date: 9 Mar 2015 18:41:02 CET > > > > > > A new version of I-D, draft-trammell-stackevo-newtea-00.txt > > has been successfully submitted by Brian Trammell and posted to the > > IETF repository. > > > > Name: draft-trammell-stackevo-newtea > > Revision: 00 > > Title: Thoughts on New Transport Encapsulation = Approaches > > Document date: 2015-03-09 > > Group: Individual Submission > > Pages: 6 > > URL: = http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt > > Status: = https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/ > > Htmlized: = http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00 > > > > > > Abstract: > > This document presently consists of a collection of unordered > > thoughts about new approaches to using encapsulation in support of > > stack evolution and new transport protocol deployment in an > > increasingly encrypted Internet. It aims eventually to enumerate = a > > set of architectural assumptions for transport evolution based = upon > > new encapsulations, and discuss limitations on the vocabulary used = in > > each of these new interfaces necessary to achieve deployment > > > > > > > > > > Please note that it may take a couple of minutes from the time of = submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > >=20 >=20 > _______________________________________________ > Stackevo mailing list > Stackevo@iab.org > https://www.iab.org/mailman/listinfo/stackevo >=20 >=20 --Apple-Mail=_5CBEA5AE-DEB3-4C3E-846F-D05BAC1C8604 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVAg/8AAoJENt3nsOmbNJc5fMH/01Do7uylWav7JmaHj8thuq/ NQnGaen86nCszAVyj/SnP4b0fv8Pp6Nyy7hbW3lr0KQr0HEihX6ZsyW8THCwC3Pj T9Y6mbILVsszV5ouVBvqgRXm+r6q94lpY/K5X9XA5wKYdtpm4J2UkoO1BwlD9Jkp Onx8IoaaqYOLCq43qlOOZNDoA3v5Vxe1TVgadTDYUO3JBckWiVUpA8jx25XFYqtF vFYuTUOsuIalp8Xh0wUkz7VfjKGCMGQ7/nGC2tFR/ATI31x0ae7yQveLhWAmIyqw YeLQF8p/XlDvm2Bf7t3PN9yg07Lkv0C6n+8SpJPpag5/NTyzxSE6LAyrTaOr8zo= =CySq -----END PGP SIGNATURE----- --Apple-Mail=_5CBEA5AE-DEB3-4C3E-846F-D05BAC1C8604-- From nobody Thu Mar 12 17:07:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5C1A8864 for ; Thu, 12 Mar 2015 17:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=unavailable 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 Hayosu6L2oUg for ; Thu, 12 Mar 2015 17:07:45 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 470E51A886D for ; Thu, 12 Mar 2015 17:07:44 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so69606604iec.2 for ; Thu, 12 Mar 2015 17:07:43 -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:content-type; bh=8GU/VqWqV9WhS/cIWQdIxzs9WGuN2C+0bnSMhcBtyE8=; b=stDJgDXGl9OndCIlQ2JeXjE5YAJcanJxdPLF4XaPKVQqya/XAwvqYsXYa7wYEAa7ar MyPbpKh0R1WMB5h5u3XQ0zGpIiQDubWztOz3e30KnHiVniavqSiwlx857GrcCwtfupxr d9L/idiDsVQW2vDJTKbFv7tA2eSmnT9DJZmaEsA9/8Fc0z526pMrfMw1KfrYON/4vqZT 9RCO/0oDEkzB1dQsMN8jUGbgtbHLNL+bGhwPpsMpsby6HKfwClcVYS9vK5LeCeZXJPKv 05CspVkZd+pTFfjIH+r9FZDeEPRsX6+/EBiXmaXmgTBG9hgHGGdvOdnj9yQObZM/HIil 1s7Q== MIME-Version: 1.0 X-Received: by 10.107.135.75 with SMTP id j72mr40892718iod.0.1426205263475; Thu, 12 Mar 2015 17:07:43 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Thu, 12 Mar 2015 17:07:43 -0700 (PDT) In-Reply-To: References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 17:07:43 -0700 Message-ID: From: Ted Hardie To: Brian Trammell Content-Type: multipart/alternative; boundary=001a113fb98e1b3b8d0511204a86 Archived-At: Cc: stackevo@iab.org, "spud@ietf.org" Subject: Re: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 00:07:47 -0000 --001a113fb98e1b3b8d0511204a86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 12, 2015 at 3:15 PM, Brian Trammell wrote: > > > > Doing it at above that layer with a long-lived cryptographic token has > very serious privacy implications and doing it without one means you can > mint an identifier freely. A reputation that lasts for the duration of th= e > flow doesn't have these issues, and it may be the best we can do at the > moment. > > This is another way to do it, though of course you can also always freely > mint another flow (with SPUD, merely by opening another tube on the same > fivetuple, even). Y=E2=80=8Bou're right, though the points Joe made about dispatching might c= ome into play here. Anything like a load balancer that is using the identifier to manage a state table will treat a new identifier as a new flow; that may mean dispatching it to a new backend. So an endpoint can do that, but it is not guaranteed to avoid other side effects. > Endpoints, though, are in a much better position to evaluate the > trustworthiness of path declarations, and in this case a coarse > remote-endpoint address identifier with a time decay function is probably > sufficient. Whether that actually improves quality of connectivity/servic= e > for those endpoints is another question. > > I =E2=80=8B =E2=80=8Bthink we need to be careful not to over-promise here. A= n initial state might be some rate X for verification, with reputation allowing you to reduce X (or bad data causing you to maintain or increase it). There are other options, of course; in a multi-link system, indications that the path via one link has path elements which are giving you bad/false data might cause you to consider paths using the other link, but this is definitely trending into the "try it after proving simpler stuff works" area. regards=E2=80=8B, Ted > > Thanks again for kicking off the discussion, > > And thanks for continuing it. > > Cheers, > > Brian > > > Ted > > > > On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell > wrote: > > Greetings, all, > > > > Shortly before the Monday deadline, I threw together a couple of > thoughts into a document that might eventually evolve into a more > architectural view of the vocabulary of the things we can expect to be ab= le > to deployably say with SPUD (separate from the current discussion on the > scope of the tube ID). This follows from discussions about trying to keep > markings declarative. > > > > Comments welcome. > > > > Thanks, cheers, > > > > Brian > > > > > Begin forwarded message: > > > > > > From: internet-drafts@ietf.org > > > To: "Brian Trammell" , "Brian Trammell" < > ietf@trammell.ch> > > > Subject: New Version Notification for > draft-trammell-stackevo-newtea-00.txt > > > Date: 9 Mar 2015 18:41:02 CET > > > > > > > > > A new version of I-D, draft-trammell-stackevo-newtea-00.txt > > > has been successfully submitted by Brian Trammell and posted to the > > > IETF repository. > > > > > > Name: draft-trammell-stackevo-newtea > > > Revision: 00 > > > Title: Thoughts on New Transport Encapsulation > Approaches > > > Document date: 2015-03-09 > > > Group: Individual Submission > > > Pages: 6 > > > URL: > http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt > > > Status: > https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/ > > > Htmlized: > http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00 > > > > > > > > > Abstract: > > > This document presently consists of a collection of unordered > > > thoughts about new approaches to using encapsulation in support of > > > stack evolution and new transport protocol deployment in an > > > increasingly encrypted Internet. It aims eventually to enumerate a > > > set of architectural assumptions for transport evolution based upon > > > new encapsulations, and discuss limitations on the vocabulary used = in > > > each of these new interfaces necessary to achieve deployment > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > _______________________________________________ > > Stackevo mailing list > > Stackevo@iab.org > > https://www.iab.org/mailman/listinfo/stackevo > > > > > > --001a113fb98e1b3b8d0511204a86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 3:15 PM= , Brian Trammell <ietf@trammell.ch> wrote:


>=C2=A0 Doing it at above that layer with a long-lived cryptographic tok= en has very serious privacy implications and doing it without one means you= can mint an identifier freely. A reputation that lasts for the duration of= the flow doesn't have these issues, and it may be the best we can do a= t the moment.

This is another way to do it, though of course you can also always f= reely mint another flow (with SPUD, merely by opening another tube on the s= ame fivetuple, even).
=C2=A0
Y=E2= =80=8Bou're right, though the points Joe made about dispatching might c= ome into play here.=C2=A0 Anything like a load balancer that is using the i= dentifier to manage a state table will treat a new identifier as a new flow= ; that may mean dispatching it to a new backend.=C2=A0 So an endpoint can d= o that, but it is not guaranteed to avoid other side effects.

=C2=A0
Endpoints, though, are in a much better position to evaluate the trustworth= iness of path declarations, and in this case a coarse remote-endpoint addre= ss identifier with a time decay function is probably sufficient. Whether th= at actually improves quality of connectivity/service for those endpoints is= another question.


I
=E2=80=8B =E2=80=8Bthink we need to be careful not to over-promise here.= =C2=A0 An initial state might be some rate X for verification, with reputat= ion allowing you to reduce X (or bad data causing you to maintain or increa= se it).=C2=A0 There are other options, of course; in a multi-link system, i= ndications that the path via one link has path elements which are giving yo= u bad/false data might cause you to consider paths using the other link, bu= t this is definitely trending into the "try it after proving simpler s= tuff works" area.

regards=E2=80= =8B,

Ted

=C2=A0
> Thanks again for kicking off the discussion,

And thanks for continuing it.

Cheers,

Brian

> Ted
>
> On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell <ietf@trammell.ch> wrote:
> Greetings, all,
>
> Shortly before the Monday deadline, I threw together a couple of thoug= hts into a document that might eventually evolve into a more architectural = view of the vocabulary of the things we can expect to be able to deployably= say with SPUD (separate from the current discussion on the scope of the tu= be ID). This follows from discussions about trying to keep markings declara= tive.
>
> Comments welcome.
>
> Thanks, cheers,
>
> Brian
>
> > Begin forwarded message:
> >
> > From: internet-drafts= @ietf.org
> > To: "Brian Trammell" <ietf@trammell.ch>, "Brian Trammell" <ietf@trammell.ch>
> > Subject: New Version Notification for draft-trammell-stackevo-new= tea-00.txt
> > Date: 9 Mar 2015 18:41:02 CET
> >
> >
> > A new version of I-D, draft-trammell-stackevo-newtea-00.txt
> > has been successfully submitted by Brian Trammell and posted to t= he
> > IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-trammell-stackevo-ne= wtea
> > Revision:=C2=A0 =C2=A0 =C2=A000
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tho= ughts on New Transport Encapsulation Approaches
> > Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-03-09
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ind= ividual Submission
> > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6 > > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-trammell-stackevo-new= tea-00.txt
> > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.= ietf.org/html/draft-trammell-stackevo-newtea-00
> >
> >
> > Abstract:
> >=C2=A0 =C2=A0This document presently consists of a collection of u= nordered
> >=C2=A0 =C2=A0thoughts about new approaches to using encapsulation = in support of
> >=C2=A0 =C2=A0stack evolution and new transport protocol deployment= in an
> >=C2=A0 =C2=A0increasingly encrypted Internet.=C2=A0 It aims eventu= ally to enumerate a
> >=C2=A0 =C2=A0set of architectural assumptions for transport evolut= ion based upon
> >=C2=A0 =C2=A0new encapsulations, and discuss limitations on the vo= cabulary used in
> >=C2=A0 =C2=A0each of these new interfaces necessary to achieve dep= loyment
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of= submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
>
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
>
>


--001a113fb98e1b3b8d0511204a86-- From nobody Mon Mar 16 04:07:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F341A008A for ; Mon, 16 Mar 2015 04:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 B1K5iYu7PIuV for ; Mon, 16 Mar 2015 04:07:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D961A007C for ; Mon, 16 Mar 2015 04:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9038; q=dns/txt; s=iport; t=1426504047; x=1427713647; h=from:to:subject:date:message-id:mime-version; bh=DbZDUEmIULRCYE6mNIEMzRgV+zNHAbO+jre+CzuQZtA=; b=j/IJJ3u+Mw7IHUMyu4yBkHLgaupiQ3b3GC6QJ7d1t05+P8DrkGWLfkfE dRCQa03WIHxGwCLFJs4rSc5WfoVM1t+WQEXCuK2UOl2Z/LPX0AHeHphgR YKf5UWcJFR5XjpN20LxGvmTmfNarV2Dk0VZaqaQvqRgHr1IbRAsb56mGM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBQAKuQZV/4YNJK1bgwZSWgSDCLtJhASBfYYSgQ5MAQEBAQEBfYQWI0QBDBcBSgIEMCcELogUDZl6j0qbAgEBCAEBAQEBHY8xg0YvgRYFkDqDa4FkhBeBVJJAI4NubwGBAkF/AQEB X-IronPort-AV: E=Sophos;i="5.11,409,1422921600"; d="scan'208,217";a="404028196" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 16 Mar 2015 11:07:27 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2GB7QvV004045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Mar 2015 11:07:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 06:07:26 -0500 From: "Pal Martinsen (palmarti)" To: "spud@ietf.org" Thread-Topic: Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRQ== Date: Mon, 16 Mar 2015 11:07:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.210.128] Content-Type: multipart/alternative; boundary="_000_B57E4F68A0C644D8A72947B1BED309C9ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:07:30 -0000 --_000_B57E4F68A0C644D8A72947B1BED309C9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBhIGZldyBhZGRpdGlvbmFsIFNQVUQgdXNlLWNhc2VzIEkgd2FudCB0byBi cmluZyB0byB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4gU29tZSBvZiB0aGVtIGhhdmUgYWxyZWFk eSBiZWVuIHNvbHZlZCBieSB1c2luZyBTVFVOIGFzIGEgc2lnbmFsbGluZyBwcm90b2NvbCAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIudHh0 KS4gSSB0aGluayBTUFVEIGlzIGEgbW9yZSBlZmZpY2llbnQgY2FycmllciBvZiB0aGUgYml0cyBu ZWVkZWQgdG8gc29sdmUgc29tZSBvZiB0aGUgdXNlLWNhc2VzLiBCdXQgZm9yIG5vdyB0aGV5IGFy ZSBqdXN0IHVzZS1jYXNlcywgYW5kIGRpc2N1c3Npb25zIG9uIGhvdyB0byBzb2x2ZSB0aGVtIHNo b3VsZCBwcm9iYWJseSBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIHN0YWdlLg0KDQoqIFJhdGUgQWRh cHRpb24gV2l0aCBDb25maWRlbmNlDQpUb2RheXMgZGVsYXkgc2Vuc2luZyByYXRlIGFkYXB0aW9u IG1lY2hhbmlzbXMgc2VlbXMgdG8gYmUgd29ya2luZyB2ZXJ5IHdlbGwgYW5kIGNhbiBwb3RlbnRp YWxseSByZWFjdCB3aXRoaW4gaGFsZiBhIFJUVCAoSXMgVFQsIFRyaXAgVGltZSwgbW9yZSBhY2N1 cmF0ZSBvciBpbiB1c2UgYXMgYSB0ZXJtPykuIEhhdmluZyBleHBsaWNpdCBuZXR3b3JrIGZlZWRi YWNrIHNpZ25hbGxlZCBiYWNrIHRvIGVuZHBvaW50IGVuYWJsZWQgZW5kcG9pbnRzIHRvIHBpY2sg YSBtb3JlIHJlYXNvbmFibGUgc3RhcnRpbmcgdmFsdWUgd2hlbiBzZW5kaW5nIG1lZGlhLiBFeHBs aWNpdCBzaWduYWxsaW5nIGR1cmluZyB0aGUgY2FsbCBlbmFibGVzIHRoZSBuZXR3b3JrIGFzIHRv IHNpZ25hbCBpbmZvcm1hdGlvbiBiYWNrIHRvIHRoZSBlbmRwb2ludCBiZWZvcmUgdGhlIHByb2Js ZW1zIG9jY3VyIChFQ04pLiBVcC9kb3duIHNwZWVkaW5nIGNvdWxkIHBvdGVudGlhbGx5IGJlIGRv bmUgaW4gbGFyZ2VyIGNodW5rcyB3aXRoIGNvbmZpZGVuY2UuDQoNCiogRmlyc3QgQ29tZSwgRmly c3QgU2VydmUNCkluIFdpRmkgd2UgaGF2ZSBzb21lIGxhYiB0ZXN0cyB0aGF0IHNob3cgd2hlbiB5 b3UgaGl0IGEgbGltaXQgeW91IGhpdCBpdCBoYXJkIGFuZCBldmVyeWJvZHkgb24gdGhhdCBsaW5r IHN1ZmZlcnMuIElmIDkgcGVvcGxlIGVuam95IHRoZWlyIHZpZGVvIGNvbnZlcnNhdGlvbnMgZ29p bmcgdGhyb3VnaCB0aGUgc2FtZSBXaUZpIEFQLCBpdCBpcyBhbm5veWluZyBpZiBhIDEwdGggY2Fs bCBpcyBhZGRlZCBjYXVzaW5nIGV2ZXJ5Ym9keSB0byBnZXQgYmFkIHZpZGVvLiBBIHBvc3NpYmxl IHNvbHV0aW9uIGlzIHRvIGxldCB0aGUgbmV0d29yayBzaWduYWwgYmFjayB0byB0aGUgMTB0aCBw YXJ0aWNpcGFudHMgdHJ5aW5nIHRvIHNlbmQgdmlkZW8gdGhhdCBiYW5kd2lkdGggaXMgbm90IGF2 YWlsYWJsZTsg4oCcSSB3aWxsIHB1dCB5b3UgaW4gd29yc2UgdGhhbiBiZXN0IGVmZm9ydCBxdWV1 ZSBpZiB5b3UgdHJ5IHRvIHNlbmQgYXQgdGhhdCByYXRl4oCdLiBJZiBiYW5kd2lkdGggYmVjb21l IGF2YWlsYWJsZSB0aGUgbmV0d29yayB3aWxsIG5vdGlmeSB0aGUgdXNlci4gTm90ZSB0aGF0IHRo aXMgaXMgbm90IFJTVlAgYW5kIHJlc291cmNlIGFsbG9jYXRpb24sIGp1c3QgaGludHMgZnJvbSB0 aGUgbmV0d29yayB0aGF0IGlmIHlvdSB0cnksIHlvdSB3aWxsIHN1ZmZlci4NCg0KKiBEeW5hbWlj IFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXNhdGlvbiAoRFBUUFAgKnNpZ2gqKQ0KVGhlIFNQVUQg dXNlIGNhc2UgZHJhZnQgb3BlbnMgdXAgZm9yIHR1YmUgcHJpb3JpdGlzYXRpb24uIEl0IGlzIHBv c3NpYmxlIHRvIHByaW9yaXRpc2UgYW1vbmcgZm9yIGV4YW1wbGUgYXVkaW8sIHZpZGVvIGFuZCBk YXRhIHR1YmVzIHdoZW4gbXVsdGlwbGV4aW5nIChCdW5kbGUpIGlzIGluIHVzZS4gSXQgaXMgaW1w b3J0YW50IHRoYXQgdGhlIHByaW9yaXRpc2F0aW9uIGlzIG1hZGUgZHluYW1pYy4gV2hlbiBydW5u aW5nIGEgdmlkZW8gY29uZmVyZW5jZSB5b3UgbWlnaHQgd2FudCB0byBwcmlvcml0aXNlIHZpZGVv IHBhY2tldHMsIGJ1dCBzdWRkZW5seSB0aGVyZSBpcyBhIG5lZWQgdG8gdXBsb2FkIGEgbGFyZ2Ug cHJlc2VudGF0aW9uIHRvIGFsbCB0aGUgcGFydGljaXBhbnRzLiBJbiB0aGF0IGNhc2UgaXQgbWln aHQgbm90IG1ha2Ugc2Vuc2UgZm9yIHBhcnRpY2lwYW50cyBoYXZpbmcgcHJpc3RpbmUgMTA4MHA2 MCB2aWRlbyB3YXRjaGluZyBlYWNoIG90aGVyIHdhaXRpbmcgZm9yIHRoZSBzbG93IHVwbG9hZGlu ZyBvZiB0aGUgcHJlc2VudGF0aW9uIHRvIGZpbmlzaC4NCg0KQW5kIHRoZSBwYWNrZXQgdHlwZSBw cmlvcml0aXNhdGlvbiBkb2VzIG5vdCBuZWNlc3NhcmlseSBzdG9wIGF0IGF1ZGlvIG9yIHZpZGVv IGxldmVsLiBWaWRlbyBwYWNrZXRzIGNhbiBoYXZlIGZvciBleGFtcGxlIHNwYXRpYWwgbGF5ZXJz IHdoZXJlIHBhY2tldHMgYmVsb25naW5nIHRvIGEgdGVtcG9yYWwgbGF5ZXIgY2FuIGJlIGRpc2Nh cmRlZCBieSB0aGUgbmV0d29yayB3aXRob3V0IHRvIG11Y2ggaW1wYWN0IG9uIHRoZSB2aWRlbyBx dWFsaXR5LiBEaXNjYXJkaW5nIGFuIEktRnJhbWUgd291bGQgaGF2ZSBtdWNoIG1vcmUgaW1wYWN0 IG9uIHRoZSBxdWFsaXR5Lg0KDQoNCg0KQ29tbWVudHMsIGZsYW1lcyBhbmQgd2hhdCBub3QgYXJl IG9mIGNvdXJzZSB3ZWxjb21lLg0KDQouLS4NClDDpWwtRXJpaw0K --_000_B57E4F68A0C644D8A72947B1BED309C9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7FD2127B3ED65E4AA4CF2FB2A1E17EAA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgYSBmZXcgYWRkaXRpb25h bCBTUFVEIHVzZS1jYXNlcyBJIHdhbnQgdG8gYnJpbmcgdG8gdGhlIGxpc3QgYmVmb3JlIHRoZSBC b0YuIFNvbWUgb2YgdGhlbSBoYXZlIGFscmVhZHkgYmVlbiBzb2x2ZWQgYnkgdXNpbmcgU1RVTiBh cyBhIHNpZ25hbGxpbmcgcHJvdG9jb2wgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1kaXNjdXNzLTAyLnR4dCIgY2xhc3M9IiI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIudHh0PC9hPiku DQogSSB0aGluayBTUFVEIGlzIGEgbW9yZSBlZmZpY2llbnQgY2FycmllciBvZiB0aGUgYml0cyBu ZWVkZWQgdG8gc29sdmUgc29tZSBvZiB0aGUgdXNlLWNhc2VzLiBCdXQgZm9yIG5vdyB0aGV5IGFy ZSBqdXN0IHVzZS1jYXNlcywgYW5kIGRpc2N1c3Npb25zIG9uIGhvdyB0byBzb2x2ZSB0aGVtIHNo b3VsZCBwcm9iYWJseSBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIHN0YWdlLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KiBSYXRlIEFkYXB0 aW9uIFdpdGggQ29uZmlkZW5jZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ub2RheXMgZGVsYXkgc2Vu c2luZyByYXRlIGFkYXB0aW9uIG1lY2hhbmlzbXMgc2VlbXMgdG8gYmUgd29ya2luZyB2ZXJ5IHdl bGwgYW5kIGNhbiBwb3RlbnRpYWxseSByZWFjdCB3aXRoaW4gaGFsZiBhIFJUVCAoSXMgVFQsIFRy aXAgVGltZSwgbW9yZSBhY2N1cmF0ZSBvciBpbiB1c2UgYXMgYSB0ZXJtPykuIEhhdmluZyBleHBs aWNpdCBuZXR3b3JrIGZlZWRiYWNrIHNpZ25hbGxlZCBiYWNrIHRvIGVuZHBvaW50IGVuYWJsZWQN CiBlbmRwb2ludHMgdG8gcGljayBhIG1vcmUgcmVhc29uYWJsZSBzdGFydGluZyB2YWx1ZSB3aGVu IHNlbmRpbmcgbWVkaWEuIEV4cGxpY2l0IHNpZ25hbGxpbmcgZHVyaW5nIHRoZSBjYWxsIGVuYWJs ZXMgdGhlIG5ldHdvcmsgYXMgdG8gc2lnbmFsIGluZm9ybWF0aW9uIGJhY2sgdG8gdGhlIGVuZHBv aW50IGJlZm9yZSB0aGUgcHJvYmxlbXMgb2NjdXIgKEVDTikuIFVwL2Rvd24gc3BlZWRpbmcgY291 bGQgcG90ZW50aWFsbHkgYmUgZG9uZSBpbiBsYXJnZXINCiBjaHVua3Mgd2l0aCBjb25maWRlbmNl LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+KiBGaXJzdCBDb21lLCBGaXJzdCBTZXJ2ZSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5JbiBXaUZpIHdlIGhhdmUgc29tZSBsYWIgdGVzdHMgdGhhdCBzaG93IHdoZW4geW91IGhp dCBhIGxpbWl0IHlvdSBoaXQgaXQgaGFyZCBhbmQgZXZlcnlib2R5IG9uIHRoYXQgbGluayBzdWZm ZXJzLiBJZiA5IHBlb3BsZSBlbmpveSB0aGVpciB2aWRlbyBjb252ZXJzYXRpb25zIGdvaW5nIHRo cm91Z2ggdGhlIHNhbWUgV2lGaSBBUCwgaXQgaXMgYW5ub3lpbmcgaWYgYSAxMHRoIGNhbGwgaXMg YWRkZWQgY2F1c2luZyBldmVyeWJvZHkNCiB0byBnZXQgYmFkIHZpZGVvLiBBIHBvc3NpYmxlIHNv bHV0aW9uIGlzIHRvIGxldCB0aGUgbmV0d29yayBzaWduYWwgYmFjayB0byB0aGUgMTB0aCBwYXJ0 aWNpcGFudHMgdHJ5aW5nIHRvIHNlbmQgdmlkZW8gdGhhdCBiYW5kd2lkdGggaXMgbm90IGF2YWls YWJsZTsg4oCcSSB3aWxsIHB1dCB5b3UgaW4gd29yc2UgdGhhbiBiZXN0IGVmZm9ydCBxdWV1ZSBp ZiB5b3UgdHJ5IHRvIHNlbmQgYXQgdGhhdCByYXRl4oCdLiBJZiBiYW5kd2lkdGggYmVjb21lIGF2 YWlsYWJsZQ0KIHRoZSBuZXR3b3JrIHdpbGwgbm90aWZ5IHRoZSB1c2VyLiBOb3RlIHRoYXQgdGhp cyBpcyBub3QgUlNWUCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlvbiwganVzdCBoaW50cyBmcm9tIHRo ZSBuZXR3b3JrIHRoYXQgaWYgeW91IHRyeSwgeW91IHdpbGwgc3VmZmVyLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KiBEeW5h bWljIFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXNhdGlvbiAoRFBUUFAgKnNpZ2gqKTwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5UaGUgU1BVRCB1c2UgY2FzZSBkcmFmdCBvcGVucyB1cCBmb3IgdHViZSBw cmlvcml0aXNhdGlvbi4gSXQgaXMgcG9zc2libGUgdG8gcHJpb3JpdGlzZSBhbW9uZyBmb3IgZXhh bXBsZSBhdWRpbywgdmlkZW8gYW5kIGRhdGEgdHViZXMgd2hlbiBtdWx0aXBsZXhpbmcgKEJ1bmRs ZSkgaXMgaW4gdXNlLiBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgcHJpb3JpdGlzYXRpb24gaXMg bWFkZSBkeW5hbWljLiBXaGVuIHJ1bm5pbmcgYQ0KIHZpZGVvIGNvbmZlcmVuY2UgeW91IG1pZ2h0 IHdhbnQgdG8gcHJpb3JpdGlzZSB2aWRlbyBwYWNrZXRzLCBidXQgc3VkZGVubHkgdGhlcmUgaXMg YSBuZWVkIHRvIHVwbG9hZCBhIGxhcmdlIHByZXNlbnRhdGlvbiB0byBhbGwgdGhlIHBhcnRpY2lw YW50cy4gSW4gdGhhdCBjYXNlIGl0IG1pZ2h0IG5vdCBtYWtlIHNlbnNlIGZvciBwYXJ0aWNpcGFu dHMgaGF2aW5nIHByaXN0aW5lIDEwODBwNjAgdmlkZW8gd2F0Y2hpbmcgZWFjaCBvdGhlciB3YWl0 aW5nDQogZm9yIHRoZSBzbG93IHVwbG9hZGluZyBvZiB0aGUgcHJlc2VudGF0aW9uIHRvIGZpbmlz aC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkFuZCB0aGUgcGFja2V0IHR5cGUgcHJpb3JpdGlzYXRpb24gZG9lcyBub3QgbmVjZXNzYXJp bHkgc3RvcCBhdCBhdWRpbyBvciB2aWRlbyBsZXZlbC4gVmlkZW8gcGFja2V0cyBjYW4gaGF2ZSBm b3IgZXhhbXBsZSBzcGF0aWFsIGxheWVycyB3aGVyZSBwYWNrZXRzIGJlbG9uZ2luZyB0byBhIHRl bXBvcmFsIGxheWVyIGNhbiBiZSBkaXNjYXJkZWQgYnkgdGhlIG5ldHdvcmsgd2l0aG91dCB0byBt dWNoIGltcGFjdCBvbiB0aGUgdmlkZW8NCiBxdWFsaXR5LiBEaXNjYXJkaW5nIGFuIEktRnJhbWUg d291bGQgaGF2ZSBtdWNoIG1vcmUgaW1wYWN0IG9uIHRoZSBxdWFsaXR5LiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5Db21tZW50cywgZmxhbWVzIGFuZCB3aGF0IG5vdCBhcmUgb2YgY291cnNlIHdl bGNvbWUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UMOlbC1FcmlrPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B57E4F68A0C644D8A72947B1BED309C9ciscocom_-- From nobody Mon Mar 16 09:56:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1361A88BC for ; Mon, 16 Mar 2015 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 UFUyHzPm_kNb for ; Mon, 16 Mar 2015 09:55:59 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 88E6A1A878E for ; Mon, 16 Mar 2015 09:55:59 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so176527989iec.2 for ; Mon, 16 Mar 2015 09:55:59 -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:content-type; bh=wTDX+LTU1N8Bkr8VQlEq9i/wqGwr+ih5Ix3Y25R2WPg=; b=hpuoz0s6ivk5DUqJC/qWr8NUOpB13DN6LqPWwlZuMmhnrefixwZAcC9DSrp6KMbBqX j4IUskv3iCxhoG+CkcyqBmoeGa1wInJ9V1B5gOKfCDe494nT5yYinUgztUuhiUWc0ONP +oCj8qaq3DC10aQxNPvVlPI3PwIaq75pM/DWglhJg4zGVmAqmRZjn721sFXg2DPSlSz3 5eNlAGfRIJzkmYRdZQbMTHhqu33ep3fknfTEbshXt4svNyPiico+mQiGqIM4Nhj66Ezu 64xuLQCapw9ZeXxo+4bQiMdmNjVy42NB17bGDNJXWJAKHKRH+gwYzQ+hzfXPI8qXEsyI 8exw== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr109687596igl.6.1426524958821; Mon, 16 Mar 2015 09:55:58 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Mon, 16 Mar 2015 09:55:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 09:55:58 -0700 Message-ID: From: Ted Hardie To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=089e011825c06f121905116ab952 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 16:56:02 -0000 --089e011825c06f121905116ab952 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi P=C3=A5l-Erik, Thanks for your message; some comments in-line. On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > I have a few additional SPUD use-cases I want to bring to the list > before the BoF. Some of them have already been solved by using STUN as a > signalling protocol ( > http://tools.ietf.org/id/draft-martinsen-tram-discuss-02.txt). I think > SPUD is a more efficient carrier of the bits needed to solve some of the > use-cases. But for now they are just use-cases, and discussions on how to > solve them should probably be deferred to a later stage. > > * Rate Adaption With Confidence > Todays delay sensing rate adaption mechanisms seems to be working very > well and can potentially react within half a RTT (Is TT, Trip Time, more > accurate or in use as a term?). Having explicit network feedback signalle= d > back to endpoint enabled endpoints to pick a more reasonable starting val= ue > when sending media. Explicit signalling during the call enables the netwo= rk > as to signal information back to the endpoint before the problems occur > (ECN). Up/down speeding could potentially be done in larger chunks with > confidence. > > * First Come, First Serve > In WiFi we have some lab tests that show when you hit a limit you hit it > hard and everybody on that link suffers. If 9 people enjoy their video > conversations going through the same WiFi AP, it is annoying if a 10th ca= ll > is added causing everybody to get bad video. A possible solution is to le= t > the network signal back to the 10th participants trying to send video tha= t > bandwidth is not available; =E2=80=9CI will put you in worse than best ef= fort queue > if you try to send at that rate=E2=80=9D. If bandwidth become available t= he network > will notify the user. Note that this is not RSVP and resource allocation, > just hints from the network that if you try, you will suffer. > =E2=80=8B > =E2=80=8BWhen you say "the network" here, this seems to me the first hop-AP= . For cases where the radio resources are at issue, it seems likely that you might want to coordinate this with the other 802.11 facilities, so I'm not sure that this the right layer to do this. In particular, multi-AP deployments might request the station re-associate to a less-busy AP or make other adjustments to the channel handling of frame marked with the higher priority WMM bits (given the potential issues with cross-talk, shifting APs is certainly not a panacea, but my be better than what amounts to admission control). =E2=80=8B > > * Dynamic Per Type Packet Prioritisation (DPTPP *sigh*) > The SPUD use case draft opens up for tube prioritisation. It is possible > to prioritise among for example audio, video and data tubes when > multiplexing (Bundle) is in use. It is important that the prioritisation = is > made dynamic. When running a video conference you might want to prioritis= e > video packets, but suddenly there is a need to upload a large presentatio= n > to all the participants. In that case it might not make sense for > participants having pristine 1080p60 video watching each other waiting fo= r > the slow uploading of the presentation to finish. > > And the packet type prioritisation does not necessarily stop at audio or > video level. Video packets can have for example spatial layers where > packets belonging to a temporal layer can be discarded by the network > without to much impact on the video quality. Discarding an I-Frame would > have much more impact on the quality. > > =E2=80=8BI think ordinal priority among the tubes coming from the same user= is a baseline use case. There seem to be two possibilities to making that dynamic: mint a new tube or set of tubes on the same 6-tuple =E2=80=8Bwhen= the ordinal priority changes or update the ordinal priority on the existing tubes. I am not sure of the complexity trade-off between those two yet, and I'd be interested in folks thoughts on that. =E2=80=8Bregards, Ted=E2=80=8B > > > Comments, flames and what not are of course welcome. > > .-. > P=C3=A5l-Erik > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > --089e011825c06f121905116ab952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi P=C3=A5l-Erik,

Thanks = for your message; some comments in-line.

On Mon, Mar 16, 2015 at 4:07 AM, Pal Marti= nsen (palmarti) <palmarti@cisco.com> wrote:
Hi,

I have a few additional SPUD use-cases I want to bring to the list bef= ore the BoF. Some of them have already been solved by using STUN as a signa= lling protocol (http://tools.ietf.org/id/draft-martinsen-tr= am-discuss-02.txt). I think SPUD is a more efficient carrier of the bits needed to solve some = of the use-cases. But for now they are just use-cases, and discussions on h= ow to solve them should probably be deferred to a later stage.

* Rate Adaption With Confidence
Todays delay sensing rate adaption mechanisms seems to be working very= well and can potentially react within half a RTT (Is TT, Trip Time, more a= ccurate or in use as a term?). Having explicit network feedback signalled b= ack to endpoint enabled endpoints to pick a more reasonable starting value when sending media. Exp= licit signalling during the call enables the network as to signal informati= on back to the endpoint before the problems occur (ECN). Up/down speeding c= ould potentially be done in larger chunks with confidence.=C2=A0

* First Come, First Serve=C2=A0
In WiFi we have some lab tests that show when you hit a limit you hit = it hard and everybody on that link suffers. If 9 people enjoy their video c= onversations going through the same WiFi AP, it is annoying if a 10th call = is added causing everybody to get bad video. A possible solution is to let the network signal back to= the 10th participants trying to send video that bandwidth is not available= ; =E2=80=9CI will put you in worse than best effort queue if you try to sen= d at that rate=E2=80=9D. If bandwidth become available the network will notify the user. Note that this is not RSVP and resource = allocation, just hints from the network that if you try, you will suffer.= =C2=A0
=E2=80=8B

=E2=80=8BWhen you say "the network" here, this seems to = me the first hop-AP.=C2=A0 For cases where the radio resources are at issue= , it seems likely that you might want to coordinate this with the other 802= .11 facilities, so I'm not sure that this the right layer to do this.= =C2=A0 In particular, multi-AP deployments might request the station re-ass= ociate to a less-busy AP or make other adjustments to the channel handling = of frame marked with the higher priority WMM bits (given the potential issu= es with cross-talk, shifting APs is certainly not a panacea, but my be bett= er than what amounts to admission control).=C2=A0

=E2=80=8B
=C2=A0
* Dynamic Per Type Packet Prioritisation (DPTPP *sigh*)
The SPUD use case draft opens up for tube prioritisation. It is possib= le to prioritise among for example audio, video and data tubes when multipl= exing (Bundle) is in use. It is important that the prioritisation is made d= ynamic. When running a video conference you might want to prioritise video packets, but suddenly = there is a need to upload a large presentation to all the participants. In = that case it might not make sense for participants having pristine 1080p60 = video watching each other waiting for the slow uploading of the presentation to finish.

And the packet type prioritisation does not necessarily stop at audio = or video level. Video packets can have for example spatial layers where pac= kets belonging to a temporal layer can be discarded by the network without = to much impact on the video quality. Discarding an I-Frame would have much more impact on the quality.= =C2=A0


=E2=80=8BI think ordin= al priority among the tubes coming from the same user is a baseline use cas= e.=C2=A0 There seem to be two possibilities to making that dynamic:=C2=A0 m= int a new tube or set of tubes on the same 6-tuple =E2=80=8Bwhen the ordina= l priority changes or update the ordinal priority on the existing tubes.=C2= =A0 I am not sure of the complexity trade-off between those two yet, and I&= #39;d be interested in folks thoughts on that.

=E2= =80=8Bregards,

Ted=E2=80=8B

=C2=A0


Comments, flames and what not are of course welcome.=C2=A0

.-.
P=C3=A5l-Erik

_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud


--089e011825c06f121905116ab952-- From nobody Mon Mar 16 14:02:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619BE1A90FA for ; Mon, 16 Mar 2015 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E_CbwjmOmZfU for ; Mon, 16 Mar 2015 14:02:27 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 3B8531A90F6 for ; Mon, 16 Mar 2015 14:02:27 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2GL2Nnl004693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Mar 2015 17:02:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2GL2Nnl004693 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1426539745; bh=/CJSmnj+DsJDMN2QbdADhFgK51k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=w+Hoi285DJkttEup1XbK9WK6yTaM0DB10C4bjLYYyv/LppDzW476FFxSSK+ASScAC Z/kkxfI7SG+rF3swoZTVDzhmvQQ0ftq+LZhkGeThzlMVPMmyzAVgB/ygXmcz4fSrzl jgCn1s1J1XbMvcT74VxqYwr81E5XGAKsOitayRaU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2GL2Nnl004693 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 16 Mar 2015 17:02:03 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2GL24Ji004463 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Mar 2015 17:02:05 -0400 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub17.corp.emc.com (10.254.93.46) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 16 Mar 2015 17:02:04 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0224.002; Mon, 16 Mar 2015 17:02:04 -0400 From: "Black, David" To: Ted Hardie , "Pal Martinsen (palmarti)" Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fl4EA///wybA= Date: Mon, 16 Mar 2015 21:02:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.163] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936412E51MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:02:30 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936412E51MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgZm91ciBwb3RlbnRpYWxseSByZWxhdGVkIGRyYWZ0czoNCg0KLS0gUmF0ZSBBZGFw dGF0aW9uIGJhc2VkIG9uIG5ldHdvcmsgZmVlZGJhY2ssIGFuZCAodG8gc29tZSBleHRlbnQpIEZD RlMgKHdlYWspIGFkbWlzc2lvbiBjb250cm9sOg0KDQpUaGlzIHdvcmsgaXMgVENQIGJhc2VkLCBi dXQgd2l0aCBzaW1pbGFyIGdvYWxzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gvDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mbGluY2stbW9iaWxlLXRocm91Z2hwdXQtZ3Vp ZGFuY2UvDQoNClRoZSBsYXR0ZXIgZHJhZnQgaXMgKElNSE8pIGJldHRlciB2aWV3ZWQgYXMgYSBw cm9vZi1vZi1jb25jZXB0IGRlbW9uc3RyYXRpb24gdGhhdCB0aGlzIGNhbiB3b3JrLCBhcyBvcHBv c2VkIHRvIGEgc3BlY2lmaWMgcHJvdG9jb2wgZGVzaWduIGZvciBob3cgdG8gZG8gaXQuICBEZXNp Z24gY29uY2VybnMgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB3aGF0IHdhcyBkb25lIHRoZXJlIChl LmcuLCBhZ2dyZXNzaXZlIHVzZSBvZiBUQ1Agb3B0aW9ucykuDQoNCi0tIER5bmFtaWMgUGVyIFR5 cGUgUGFja2V0IFByaW9yaXRpemF0aW9uIChEUFRQUCAqc2lnaCopDQoNCldlYiBSVEMgd2FudHMg dG8gZG8gdGhpcyBmcm9tIHRoZSBhcHBsaWNhdGlvbjoNCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLw0KDQpBbmQgaXQg Y2FuIGJlIGRvbmUsIGlmIG9uZSBpcyBjYXJlZnVsOg0KDQogICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAvIChpbiBSRkMgRWRpdG9y IFF1ZXVlKQ0KDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KRnJvbTogU3B1ZCBbbWFpbHRvOnNwdWQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IE1vbmRheSwg TWFyY2ggMTYsIDIwMTUgMTI6NTYgUE0NClRvOiBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNCkNj OiBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NwdWRdIEFkZGl0aW9uYWwgU1BVRCB1c2Ut Y2FzZXMNCg0KSGkgUMOlbC1FcmlrLA0KVGhhbmtzIGZvciB5b3VyIG1lc3NhZ2U7IHNvbWUgY29t bWVudHMgaW4tbGluZS4NCg0KT24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNDowNyBBTSwgUGFsIE1h cnRpbnNlbiAocGFsbWFydGkpIDxwYWxtYXJ0aUBjaXNjby5jb208bWFpbHRvOnBhbG1hcnRpQGNp c2NvLmNvbT4+IHdyb3RlOg0KSGksDQoNCkkgaGF2ZSBhIGZldyBhZGRpdGlvbmFsIFNQVUQgdXNl LWNhc2VzIEkgd2FudCB0byBicmluZyB0byB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4gU29tZSBv ZiB0aGVtIGhhdmUgYWxyZWFkeSBiZWVuIHNvbHZlZCBieSB1c2luZyBTVFVOIGFzIGEgc2lnbmFs bGluZyBwcm90b2NvbCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10 cmFtLWRpc2N1c3MtMDIudHh0KS4gSSB0aGluayBTUFVEIGlzIGEgbW9yZSBlZmZpY2llbnQgY2Fy cmllciBvZiB0aGUgYml0cyBuZWVkZWQgdG8gc29sdmUgc29tZSBvZiB0aGUgdXNlLWNhc2VzLiBC dXQgZm9yIG5vdyB0aGV5IGFyZSBqdXN0IHVzZS1jYXNlcywgYW5kIGRpc2N1c3Npb25zIG9uIGhv dyB0byBzb2x2ZSB0aGVtIHNob3VsZCBwcm9iYWJseSBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIHN0 YWdlLg0KDQoqIFJhdGUgQWRhcHRpb24gV2l0aCBDb25maWRlbmNlDQpUb2RheXMgZGVsYXkgc2Vu c2luZyByYXRlIGFkYXB0aW9uIG1lY2hhbmlzbXMgc2VlbXMgdG8gYmUgd29ya2luZyB2ZXJ5IHdl bGwgYW5kIGNhbiBwb3RlbnRpYWxseSByZWFjdCB3aXRoaW4gaGFsZiBhIFJUVCAoSXMgVFQsIFRy aXAgVGltZSwgbW9yZSBhY2N1cmF0ZSBvciBpbiB1c2UgYXMgYSB0ZXJtPykuIEhhdmluZyBleHBs aWNpdCBuZXR3b3JrIGZlZWRiYWNrIHNpZ25hbGxlZCBiYWNrIHRvIGVuZHBvaW50IGVuYWJsZWQg ZW5kcG9pbnRzIHRvIHBpY2sgYSBtb3JlIHJlYXNvbmFibGUgc3RhcnRpbmcgdmFsdWUgd2hlbiBz ZW5kaW5nIG1lZGlhLiBFeHBsaWNpdCBzaWduYWxsaW5nIGR1cmluZyB0aGUgY2FsbCBlbmFibGVz IHRoZSBuZXR3b3JrIGFzIHRvIHNpZ25hbCBpbmZvcm1hdGlvbiBiYWNrIHRvIHRoZSBlbmRwb2lu dCBiZWZvcmUgdGhlIHByb2JsZW1zIG9jY3VyIChFQ04pLiBVcC9kb3duIHNwZWVkaW5nIGNvdWxk IHBvdGVudGlhbGx5IGJlIGRvbmUgaW4gbGFyZ2VyIGNodW5rcyB3aXRoIGNvbmZpZGVuY2UuDQoN CiogRmlyc3QgQ29tZSwgRmlyc3QgU2VydmUNCkluIFdpRmkgd2UgaGF2ZSBzb21lIGxhYiB0ZXN0 cyB0aGF0IHNob3cgd2hlbiB5b3UgaGl0IGEgbGltaXQgeW91IGhpdCBpdCBoYXJkIGFuZCBldmVy eWJvZHkgb24gdGhhdCBsaW5rIHN1ZmZlcnMuIElmIDkgcGVvcGxlIGVuam95IHRoZWlyIHZpZGVv IGNvbnZlcnNhdGlvbnMgZ29pbmcgdGhyb3VnaCB0aGUgc2FtZSBXaUZpIEFQLCBpdCBpcyBhbm5v eWluZyBpZiBhIDEwdGggY2FsbCBpcyBhZGRlZCBjYXVzaW5nIGV2ZXJ5Ym9keSB0byBnZXQgYmFk IHZpZGVvLiBBIHBvc3NpYmxlIHNvbHV0aW9uIGlzIHRvIGxldCB0aGUgbmV0d29yayBzaWduYWwg YmFjayB0byB0aGUgMTB0aCBwYXJ0aWNpcGFudHMgdHJ5aW5nIHRvIHNlbmQgdmlkZW8gdGhhdCBi YW5kd2lkdGggaXMgbm90IGF2YWlsYWJsZTsg4oCcSSB3aWxsIHB1dCB5b3UgaW4gd29yc2UgdGhh biBiZXN0IGVmZm9ydCBxdWV1ZSBpZiB5b3UgdHJ5IHRvIHNlbmQgYXQgdGhhdCByYXRl4oCdLiBJ ZiBiYW5kd2lkdGggYmVjb21lIGF2YWlsYWJsZSB0aGUgbmV0d29yayB3aWxsIG5vdGlmeSB0aGUg dXNlci4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IFJTVlAgYW5kIHJlc291cmNlIGFsbG9jYXRpb24s IGp1c3QgaGludHMgZnJvbSB0aGUgbmV0d29yayB0aGF0IGlmIHlvdSB0cnksIHlvdSB3aWxsIHN1 ZmZlci4NCuKAiw0KDQrigItXaGVuIHlvdSBzYXkgInRoZSBuZXR3b3JrIiBoZXJlLCB0aGlzIHNl ZW1zIHRvIG1lIHRoZSBmaXJzdCBob3AtQVAuICBGb3IgY2FzZXMgd2hlcmUgdGhlIHJhZGlvIHJl c291cmNlcyBhcmUgYXQgaXNzdWUsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHlvdSBtaWdodCB3YW50 IHRvIGNvb3JkaW5hdGUgdGhpcyB3aXRoIHRoZSBvdGhlciA4MDIuMTEgZmFjaWxpdGllcywgc28g SSdtIG5vdCBzdXJlIHRoYXQgdGhpcyB0aGUgcmlnaHQgbGF5ZXIgdG8gZG8gdGhpcy4gIEluIHBh cnRpY3VsYXIsIG11bHRpLUFQIGRlcGxveW1lbnRzIG1pZ2h0IHJlcXVlc3QgdGhlIHN0YXRpb24g cmUtYXNzb2NpYXRlIHRvIGEgbGVzcy1idXN5IEFQIG9yIG1ha2Ugb3RoZXIgYWRqdXN0bWVudHMg dG8gdGhlIGNoYW5uZWwgaGFuZGxpbmcgb2YgZnJhbWUgbWFya2VkIHdpdGggdGhlIGhpZ2hlciBw cmlvcml0eSBXTU0gYml0cyAoZ2l2ZW4gdGhlIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBjcm9zcy10 YWxrLCBzaGlmdGluZyBBUHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFjZWEsIGJ1dCBteSBiZSBi ZXR0ZXIgdGhhbiB3aGF0IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRyb2wpLg0K4oCLDQoNCiog RHluYW1pYyBQZXIgVHlwZSBQYWNrZXQgUHJpb3JpdGlzYXRpb24gKERQVFBQICpzaWdoKikNClRo ZSBTUFVEIHVzZSBjYXNlIGRyYWZ0IG9wZW5zIHVwIGZvciB0dWJlIHByaW9yaXRpc2F0aW9uLiBJ dCBpcyBwb3NzaWJsZSB0byBwcmlvcml0aXNlIGFtb25nIGZvciBleGFtcGxlIGF1ZGlvLCB2aWRl byBhbmQgZGF0YSB0dWJlcyB3aGVuIG11bHRpcGxleGluZyAoQnVuZGxlKSBpcyBpbiB1c2UuIEl0 IGlzIGltcG9ydGFudCB0aGF0IHRoZSBwcmlvcml0aXNhdGlvbiBpcyBtYWRlIGR5bmFtaWMuIFdo ZW4gcnVubmluZyBhIHZpZGVvIGNvbmZlcmVuY2UgeW91IG1pZ2h0IHdhbnQgdG8gcHJpb3JpdGlz ZSB2aWRlbyBwYWNrZXRzLCBidXQgc3VkZGVubHkgdGhlcmUgaXMgYSBuZWVkIHRvIHVwbG9hZCBh IGxhcmdlIHByZXNlbnRhdGlvbiB0byBhbGwgdGhlIHBhcnRpY2lwYW50cy4gSW4gdGhhdCBjYXNl IGl0IG1pZ2h0IG5vdCBtYWtlIHNlbnNlIGZvciBwYXJ0aWNpcGFudHMgaGF2aW5nIHByaXN0aW5l IDEwODBwNjAgdmlkZW8gd2F0Y2hpbmcgZWFjaCBvdGhlciB3YWl0aW5nIGZvciB0aGUgc2xvdyB1 cGxvYWRpbmcgb2YgdGhlIHByZXNlbnRhdGlvbiB0byBmaW5pc2guDQoNCkFuZCB0aGUgcGFja2V0 IHR5cGUgcHJpb3JpdGlzYXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgc3RvcCBhdCBhdWRpbyBv ciB2aWRlbyBsZXZlbC4gVmlkZW8gcGFja2V0cyBjYW4gaGF2ZSBmb3IgZXhhbXBsZSBzcGF0aWFs IGxheWVycyB3aGVyZSBwYWNrZXRzIGJlbG9uZ2luZyB0byBhIHRlbXBvcmFsIGxheWVyIGNhbiBi ZSBkaXNjYXJkZWQgYnkgdGhlIG5ldHdvcmsgd2l0aG91dCB0byBtdWNoIGltcGFjdCBvbiB0aGUg dmlkZW8gcXVhbGl0eS4gRGlzY2FyZGluZyBhbiBJLUZyYW1lIHdvdWxkIGhhdmUgbXVjaCBtb3Jl IGltcGFjdCBvbiB0aGUgcXVhbGl0eS4NCg0KDQrigItJIHRoaW5rIG9yZGluYWwgcHJpb3JpdHkg YW1vbmcgdGhlIHR1YmVzIGNvbWluZyBmcm9tIHRoZSBzYW1lIHVzZXIgaXMgYSBiYXNlbGluZSB1 c2UgY2FzZS4gIFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMgdG8gbWFraW5nIHRo YXQgZHluYW1pYzogIG1pbnQgYSBuZXcgdHViZSBvciBzZXQgb2YgdHViZXMgb24gdGhlIHNhbWUg Ni10dXBsZSDigIt3aGVuIHRoZSBvcmRpbmFsIHByaW9yaXR5IGNoYW5nZXMgb3IgdXBkYXRlIHRo ZSBvcmRpbmFsIHByaW9yaXR5IG9uIHRoZSBleGlzdGluZyB0dWJlcy4gIEkgYW0gbm90IHN1cmUg b2YgdGhlIGNvbXBsZXhpdHkgdHJhZGUtb2ZmIGJldHdlZW4gdGhvc2UgdHdvIHlldCwgYW5kIEkn ZCBiZSBpbnRlcmVzdGVkIGluIGZvbGtzIHRob3VnaHRzIG9uIHRoYXQuDQoNCuKAi3JlZ2FyZHMs DQpUZWTigIsNCg0KDQoNCg0KQ29tbWVudHMsIGZsYW1lcyBhbmQgd2hhdCBub3QgYXJlIG9mIGNv dXJzZSB3ZWxjb21lLg0KDQouLS4NClDDpWwtRXJpaw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU3B1ZCBtYWlsaW5nIGxpc3QNClNwdWRAaWV0Zi5v cmc8bWFpbHRvOlNwdWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwdWQNCg0K --_000_CE03DB3D7B45C245BCA0D24327794936412E51MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhlcmUgYXJlIGZvdXIgcG90ZW50aWFsbHkgcmVsYXRl ZCBkcmFmdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4tLSBSYXRlIEFkYXB0YXRpb24gYmFz ZWQgb24gbmV0d29yayBmZWVkYmFjaywgYW5kICh0byBzb21lIGV4dGVudCkgRkNGUyAod2Vhaykg YWRtaXNzaW9uIGNvbnRyb2w6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHdvcmsgaXMg VENQIGJhc2VkLCBidXQgd2l0aCBzaW1pbGFyIGdvYWxzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaC8i Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwcmVjaGVyLW1vYmlsZS10 Zy1leHBvc3VyZS1yZXEtYXJjaC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mbGluY2st bW9iaWxlLXRocm91Z2hwdXQtZ3VpZGFuY2UvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1mbGluY2stbW9iaWxlLXRocm91Z2hwdXQtZ3VpZGFuY2UvPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+VGhlIGxhdHRlciBkcmFmdCBpcyAoSU1ITykgYmV0dGVyIHZpZXdl ZCBhcyBhIHByb29mLW9mLWNvbmNlcHQgZGVtb25zdHJhdGlvbiB0aGF0IHRoaXMgY2FuIHdvcmss IGFzIG9wcG9zZWQgdG8gYSBzcGVjaWZpYyBwcm90b2NvbCBkZXNpZ24gZm9yIGhvdyB0byBkbyBp dC4mbmJzcDsgRGVzaWduIGNvbmNlcm5zDQogaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB3aGF0IHdh cyBkb25lIHRoZXJlIChlLmcuLCBhZ2dyZXNzaXZlIHVzZSBvZiBUQ1Agb3B0aW9ucykuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4tLSBEeW5hbWljIFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXph dGlvbiAoRFBUUFAgKnNpZ2gqKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2ViIFJUQyB3YW50 cyB0byBkbyB0aGlzIGZyb20gdGhlIGFwcGxpY2F0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MvPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QW5kIGl0IGNhbiBiZSBkb25lLCBpZiBvbmUgaXMg Y2FyZWZ1bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kYXJ0LWRzY3AtcnRwLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLzwvYT4gKGluIFJGQyBFZGl0b3IgUXVldWUpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQotLURh dmlkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMTYsIDIw MTUgMTI6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKTxicj4N CjxiPkNjOjwvYj4gc3B1ZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1NwdWRd IEFkZGl0aW9uYWwgU1BVRCB1c2UtY2FzZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5IaSBQw6VsLUVyaWssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MgZm9yIHlvdXIg bWVzc2FnZTsgc29tZSBjb21tZW50cyBpbi1saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDE2LCAyMDE1IGF0IDQ6MDcg QU0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbG1hcnRp QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhbG1hcnRpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGZldyBh ZGRpdGlvbmFsIFNQVUQgdXNlLWNhc2VzIEkgd2FudCB0byBicmluZyB0byB0aGUgbGlzdCBiZWZv cmUgdGhlIEJvRi4gU29tZSBvZiB0aGVtIGhhdmUgYWxyZWFkeSBiZWVuIHNvbHZlZCBieSB1c2lu ZyBTVFVOIGFzIGEgc2lnbmFsbGluZyBwcm90b2NvbCAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIudHh0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1 c3MtMDIudHh0PC9hPikuDQogSSB0aGluayBTUFVEIGlzIGEgbW9yZSBlZmZpY2llbnQgY2Fycmll ciBvZiB0aGUgYml0cyBuZWVkZWQgdG8gc29sdmUgc29tZSBvZiB0aGUgdXNlLWNhc2VzLiBCdXQg Zm9yIG5vdyB0aGV5IGFyZSBqdXN0IHVzZS1jYXNlcywgYW5kIGRpc2N1c3Npb25zIG9uIGhvdyB0 byBzb2x2ZSB0aGVtIHNob3VsZCBwcm9iYWJseSBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIHN0YWdl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4q IFJhdGUgQWRhcHRpb24gV2l0aCBDb25maWRlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2RheXMgZGVsYXkgc2Vuc2luZyByYXRlIGFkYXB0 aW9uIG1lY2hhbmlzbXMgc2VlbXMgdG8gYmUgd29ya2luZyB2ZXJ5IHdlbGwgYW5kIGNhbiBwb3Rl bnRpYWxseSByZWFjdCB3aXRoaW4gaGFsZiBhIFJUVCAoSXMgVFQsIFRyaXAgVGltZSwgbW9yZSBh Y2N1cmF0ZSBvciBpbiB1c2UgYXMgYSB0ZXJtPykuIEhhdmluZyBleHBsaWNpdCBuZXR3b3JrIGZl ZWRiYWNrIHNpZ25hbGxlZCBiYWNrIHRvIGVuZHBvaW50DQogZW5hYmxlZCBlbmRwb2ludHMgdG8g cGljayBhIG1vcmUgcmVhc29uYWJsZSBzdGFydGluZyB2YWx1ZSB3aGVuIHNlbmRpbmcgbWVkaWEu IEV4cGxpY2l0IHNpZ25hbGxpbmcgZHVyaW5nIHRoZSBjYWxsIGVuYWJsZXMgdGhlIG5ldHdvcmsg YXMgdG8gc2lnbmFsIGluZm9ybWF0aW9uIGJhY2sgdG8gdGhlIGVuZHBvaW50IGJlZm9yZSB0aGUg cHJvYmxlbXMgb2NjdXIgKEVDTikuIFVwL2Rvd24gc3BlZWRpbmcgY291bGQgcG90ZW50aWFsbHkg YmUgZG9uZQ0KIGluIGxhcmdlciBjaHVua3Mgd2l0aCBjb25maWRlbmNlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIEZpcnN0IENv bWUsIEZpcnN0IFNlcnZlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiBXaUZpIHdlIGhhdmUgc29tZSBsYWIgdGVzdHMgdGhhdCBzaG93 IHdoZW4geW91IGhpdCBhIGxpbWl0IHlvdSBoaXQgaXQgaGFyZCBhbmQgZXZlcnlib2R5IG9uIHRo YXQgbGluayBzdWZmZXJzLiBJZiA5IHBlb3BsZSBlbmpveSB0aGVpciB2aWRlbyBjb252ZXJzYXRp b25zIGdvaW5nIHRocm91Z2ggdGhlIHNhbWUgV2lGaSBBUCwgaXQgaXMgYW5ub3lpbmcgaWYgYSAx MHRoIGNhbGwgaXMgYWRkZWQgY2F1c2luZw0KIGV2ZXJ5Ym9keSB0byBnZXQgYmFkIHZpZGVvLiBB IHBvc3NpYmxlIHNvbHV0aW9uIGlzIHRvIGxldCB0aGUgbmV0d29yayBzaWduYWwgYmFjayB0byB0 aGUgMTB0aCBwYXJ0aWNpcGFudHMgdHJ5aW5nIHRvIHNlbmQgdmlkZW8gdGhhdCBiYW5kd2lkdGgg aXMgbm90IGF2YWlsYWJsZTsg4oCcSSB3aWxsIHB1dCB5b3UgaW4gd29yc2UgdGhhbiBiZXN0IGVm Zm9ydCBxdWV1ZSBpZiB5b3UgdHJ5IHRvIHNlbmQgYXQgdGhhdCByYXRl4oCdLiBJZiBiYW5kd2lk dGgNCiBiZWNvbWUgYXZhaWxhYmxlIHRoZSBuZXR3b3JrIHdpbGwgbm90aWZ5IHRoZSB1c2VyLiBO b3RlIHRoYXQgdGhpcyBpcyBub3QgUlNWUCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlvbiwganVzdCBo aW50cyBmcm9tIHRoZSBuZXR3b3JrIHRoYXQgaWYgeW91IHRyeSwgeW91IHdpbGwgc3VmZmVyLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKAizxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7i gItXaGVuIHlvdSBzYXkgJnF1b3Q7dGhlIG5ldHdvcmsmcXVvdDsgaGVyZSwgdGhpcyBzZWVtcyB0 byBtZSB0aGUgZmlyc3QgaG9wLUFQLiZuYnNwOyBGb3IgY2FzZXMgd2hlcmUgdGhlIHJhZGlvIHJl c291cmNlcyBhcmUgYXQgaXNzdWUsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHlvdSBtaWdodCB3YW50 IHRvDQogY29vcmRpbmF0ZSB0aGlzIHdpdGggdGhlIG90aGVyIDgwMi4xMSBmYWNpbGl0aWVzLCBz byBJJ20gbm90IHN1cmUgdGhhdCB0aGlzIHRoZSByaWdodCBsYXllciB0byBkbyB0aGlzLiZuYnNw OyBJbiBwYXJ0aWN1bGFyLCBtdWx0aS1BUCBkZXBsb3ltZW50cyBtaWdodCByZXF1ZXN0IHRoZSBz dGF0aW9uIHJlLWFzc29jaWF0ZSB0byBhIGxlc3MtYnVzeSBBUCBvciBtYWtlIG90aGVyIGFkanVz dG1lbnRzIHRvIHRoZSBjaGFubmVsIGhhbmRsaW5nIG9mIGZyYW1lDQogbWFya2VkIHdpdGggdGhl IGhpZ2hlciBwcmlvcml0eSBXTU0gYml0cyAoZ2l2ZW4gdGhlIHBvdGVudGlhbCBpc3N1ZXMgd2l0 aCBjcm9zcy10YWxrLCBzaGlmdGluZyBBUHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFjZWEsIGJ1 dCBteSBiZSBiZXR0ZXIgdGhhbiB3aGF0IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRyb2wpLiZu YnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igIs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBEeW5hbWljIFBlciBUeXBl IFBhY2tldCBQcmlvcml0aXNhdGlvbiAoRFBUUFAgKnNpZ2gqKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFNQVUQgdXNlIGNhc2UgZHJhZnQg b3BlbnMgdXAgZm9yIHR1YmUgcHJpb3JpdGlzYXRpb24uIEl0IGlzIHBvc3NpYmxlIHRvIHByaW9y aXRpc2UgYW1vbmcgZm9yIGV4YW1wbGUgYXVkaW8sIHZpZGVvIGFuZCBkYXRhIHR1YmVzIHdoZW4g bXVsdGlwbGV4aW5nIChCdW5kbGUpIGlzIGluIHVzZS4gSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhl IHByaW9yaXRpc2F0aW9uIGlzIG1hZGUgZHluYW1pYy4gV2hlbiBydW5uaW5nDQogYSB2aWRlbyBj b25mZXJlbmNlIHlvdSBtaWdodCB3YW50IHRvIHByaW9yaXRpc2UgdmlkZW8gcGFja2V0cywgYnV0 IHN1ZGRlbmx5IHRoZXJlIGlzIGEgbmVlZCB0byB1cGxvYWQgYSBsYXJnZSBwcmVzZW50YXRpb24g dG8gYWxsIHRoZSBwYXJ0aWNpcGFudHMuIEluIHRoYXQgY2FzZSBpdCBtaWdodCBub3QgbWFrZSBz ZW5zZSBmb3IgcGFydGljaXBhbnRzIGhhdmluZyBwcmlzdGluZSAxMDgwcDYwIHZpZGVvIHdhdGNo aW5nIGVhY2ggb3RoZXIgd2FpdGluZw0KIGZvciB0aGUgc2xvdyB1cGxvYWRpbmcgb2YgdGhlIHBy ZXNlbnRhdGlvbiB0byBmaW5pc2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGUgcGFja2V0IHR5cGUgcHJpb3JpdGlzYXRpb24gZG9l cyBub3QgbmVjZXNzYXJpbHkgc3RvcCBhdCBhdWRpbyBvciB2aWRlbyBsZXZlbC4gVmlkZW8gcGFj a2V0cyBjYW4gaGF2ZSBmb3IgZXhhbXBsZSBzcGF0aWFsIGxheWVycyB3aGVyZSBwYWNrZXRzIGJl bG9uZ2luZyB0byBhIHRlbXBvcmFsIGxheWVyIGNhbiBiZSBkaXNjYXJkZWQgYnkgdGhlIG5ldHdv cmsgd2l0aG91dCB0byBtdWNoIGltcGFjdCBvbg0KIHRoZSB2aWRlbyBxdWFsaXR5LiBEaXNjYXJk aW5nIGFuIEktRnJhbWUgd291bGQgaGF2ZSBtdWNoIG1vcmUgaW1wYWN0IG9uIHRoZSBxdWFsaXR5 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLSSB0aGluayBvcmRpbmFsIHByaW9y aXR5IGFtb25nIHRoZSB0dWJlcyBjb21pbmcgZnJvbSB0aGUgc2FtZSB1c2VyIGlzIGEgYmFzZWxp bmUgdXNlIGNhc2UuJm5ic3A7IFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMgdG8g bWFraW5nIHRoYXQgZHluYW1pYzombmJzcDsgbWludCBhIG5ldyB0dWJlIG9yIHNldCBvZiB0dWJl cyBvbg0KIHRoZSBzYW1lIDYtdHVwbGUg4oCLd2hlbiB0aGUgb3JkaW5hbCBwcmlvcml0eSBjaGFu Z2VzIG9yIHVwZGF0ZSB0aGUgb3JkaW5hbCBwcmlvcml0eSBvbiB0aGUgZXhpc3RpbmcgdHViZXMu Jm5ic3A7IEkgYW0gbm90IHN1cmUgb2YgdGhlIGNvbXBsZXhpdHkgdHJhZGUtb2ZmIGJldHdlZW4g dGhvc2UgdHdvIHlldCwgYW5kIEknZCBiZSBpbnRlcmVzdGVkIGluIGZvbGtzIHRob3VnaHRzIG9u IHRoYXQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItyZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGVk4oCLPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzLCBmbGFtZXMg YW5kIHdoYXQgbm90IGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li0uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qw6VsLUVyaWs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KU3B1ZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 U3B1ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNwdWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D24327794936412E51MX104CL02corpemcc_-- From nobody Mon Mar 16 22:02:00 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2BD1A0072 for ; Mon, 16 Mar 2015 22:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EyQZNf6aHnYy for ; Mon, 16 Mar 2015 22:01:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F131A00D6 for ; Mon, 16 Mar 2015 22:01:52 -0700 (PDT) Received: from [192.168.0.154] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9A39022E1F4; Tue, 17 Mar 2015 01:01:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mark Nottingham In-Reply-To: Date: Tue, 17 Mar 2015 16:01:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <19F10DC6-ABB2-4990-996B-E30EE1811596@mnot.net> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch> To: Patrick McManus X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Brian Trammell , Ted Hardie , "spud@ietf.org" , Joe Hildebrand , "Philipp S. Schmidt" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 05:01:59 -0000 Catching up... > On 12 Mar 2015, at 1:52 am, Patrick McManus = wrote: >=20 > On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell = wrote: >=20 > Perhaps we can apply the question that led to the separation of TCP = and IP in the first place: does the path need to see it / can the path = do something universally useful with it? Put it in SPUD. Is it = end-to-end? Stick it above SPUD, encrypt it, and hide the key from the = path. >=20 > I like that as a guiding principle +1 here too. Nice way to avoid this becoming an application services = kitchen sink. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Mar 17 01:19:19 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B31A010F for ; Tue, 17 Mar 2015 01:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 vQYl7LasRtiF for ; Tue, 17 Mar 2015 01:18:39 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 53B6B1A0107 for ; Tue, 17 Mar 2015 01:18:22 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:7c22:2769:907:e4e2] (unknown [IPv6:2001:470:26:9c2:7c22:2769:907:e4e2]) by trammell.ch (Postfix) with ESMTPSA id 5AFEB1A0032; Tue, 17 Mar 2015 09:17:51 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D8173D95-32D2-4DEA-BE54-510CB6F2AE92"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: <19F10DC6-ABB2-4990-996B-E30EE1811596@mnot.net> Date: Tue, 17 Mar 2015 09:17:50 +0100 Message-Id: <8CBCE77C-9FF1-4967-8D73-3EDA0504C489@trammell.ch> References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch> <19F10DC6-ABB2-4990-996B-E30EE1811596@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Patrick McManus , Ted Hardie , "Philipp S. Schmidt" , Joe Hildebrand , "spud@ietf.org" Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 08:18:51 -0000 --Apple-Mail=_D8173D95-32D2-4DEA-BE54-510CB6F2AE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Mar 2015, at 06:01, Mark Nottingham wrote: >=20 > Catching up... >=20 >> On 12 Mar 2015, at 1:52 am, Patrick McManus = wrote: >>=20 >> On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell = wrote: >>=20 >> Perhaps we can apply the question that led to the separation of TCP = and IP in the first place: does the path need to see it / can the path = do something universally useful with it? Put it in SPUD. Is it = end-to-end? Stick it above SPUD, encrypt it, and hide the key from the = path. >>=20 >> I like that as a guiding principle >=20 > +1 here too. Nice way to avoid this becoming an application services = kitchen sink. If we really want to build a nice expansive vocabulary for end to end = metadata signaling, and we want to reuse chunks of the SPUD codebase to = do so (maybe so the app can take the same signals and selectively expose = them to the path or not) and we have a solution to the tube MTU problem = which works so we know how many bits we can burn, and we believe we can = restrict it to the point that it will ever interoperable -- this latter = part is where I get skeptical -- then we can do this very simply, inside = the crypto veil: +--------------------------+ | addr addr ttl stuff | IP +--------------------------+ | port port csum len | UDP +--------------------------+ | magic tube flags cbor | SPUD +--------------------------+ pathside | cbor 0: DTLS | ----------------------- +--------------------------+ appside | cbor | SPUD-lite +--------------------------+ | cbor 0: payload | your favorite transport +--------------------------+ Here SPUD-lite is *just* the CBOR part of SPUD. I'm not sure this is a good idea -- though the diagram above looks a = little less scary if you think of the goal of SPUD as a facility of = reduced-profile, future DTLS -- but this arrangement would give us the = flexibility to define things we want to say first then to freely move = them between pathside and appside contexts. On the appside, the trust = situation is easier because we presume we've solved the = key-and-trust-management problem in a way that makes sense for a given = application. Cheers, Brian > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_D8173D95-32D2-4DEA-BE54-510CB6F2AE92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVB+MuAAoJENt3nsOmbNJcomUH/1v319Taq7a3eiY8nuae9wcF 3C1hdCDUKfA2sZ+/iA5CV/W68dfPpcTHJlxwv0XMjjLlazQK9SeoAeCJGe8+2qdP Klu56uuYJZEPpeFJMa9bdty/JsJ2WPOtmGnWDTrL+t7SvhcSb4DpY0r3BwpkPm4N TagTQJ0i/hgadhNsRZ0lXzj4rSQkeSkkb0FfyiSEfBGV/ex2DACTuYtnK+di5qMC AWdpw3jstt4XlXK38ZoJfKPbMQl+iTYOmbGL5uRp8jeQugBAERethXd46XPStOsr bXVKaCcWcT72w1skQuWF/2pVdYQcpGMjrlGGwnQARlBFE4qZz6Y6s2aFBEY4edM= =biGd -----END PGP SIGNATURE----- --Apple-Mail=_D8173D95-32D2-4DEA-BE54-510CB6F2AE92-- From nobody Tue Mar 17 02:47:42 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97D91A01D5 for ; Tue, 17 Mar 2015 02:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 w9wxoaOIGKwe for ; Tue, 17 Mar 2015 02:47:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A5D1A01C6 for ; Tue, 17 Mar 2015 02:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43654; q=dns/txt; s=iport; t=1426585654; x=1427795254; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wMa+3O8RoKj+CilsRUKt1EOzlEnbauH2HaS5OsQezbg=; b=fQzkiE1CUEHl1CKR1seeh8hwJ5Sz26UuyV2aQ3qv2itbGoxTPHiDcOSO zw7fTQ4h4CYVrwN1iVI9GPg1HzdaoccRPwuI407JCMDGuwVnPOfFRLGwZ +jNUq1memMTqJwjCSBRxH83jpDnAosb2aw4y6pDk7pPJK5HorarBfMX3z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCBQB39wdV/40NJK1bgkNDUl6DBsA4LYEkGQELhW4CHIEYOBQBAQEBAQEBfIQPAQEBBAEBASAEQAEGBgUQAgEIEQQBASEBBgMCAgIlCxQJCAIEDgUbiBQNrgCZYwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKFH6EFzwXBAYBBoJiL4EUBY92g1+BV4QPgRo5hTiFd4MVgz4jggIcgVBvAYECQX8BAQE X-IronPort-AV: E=Sophos;i="5.11,415,1422921600"; d="scan'208,217";a="132616113" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 17 Mar 2015 09:47:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2H9lWOe009109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 09:47:33 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 04:47:32 -0500 From: "Pal Martinsen (palmarti)" To: "Black, David" Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fqEUAgABEwYCAANXxgA== Date: Tue, 17 Mar 2015 09:47:32 +0000 Message-ID: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.174.40] Content-Type: multipart/alternative; boundary="_000_73D46BA8DB33481FB0FBDDD3B1F0F7FBciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 09:47:38 -0000 --_000_73D46BA8DB33481FB0FBDDD3B1F0F7FBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxNiBNYXIgMjAxNSwgYXQgMjI6MDIsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1j LmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbT4+IHdyb3RlOg0KDQpIZXJlIGFyZSBmb3Vy IHBvdGVudGlhbGx5IHJlbGF0ZWQgZHJhZnRzOg0KDQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgdGhl bSBvdXQuIEludGVyZXN0aW5nIHJlYWQuDQoNCi0tIFJhdGUgQWRhcHRhdGlvbiBiYXNlZCBvbiBu ZXR3b3JrIGZlZWRiYWNrLCBhbmQgKHRvIHNvbWUgZXh0ZW50KSBGQ0ZTICh3ZWFrKSBhZG1pc3Np b24gY29udHJvbDoNCg0KVGhpcyB3b3JrIGlzIFRDUCBiYXNlZCwgYnV0IHdpdGggc2ltaWxhciBn b2FsczoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3ByZWNoZXIt bW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZmxpbmNrLW1vYmlsZS10aHJvdWdocHV0LWd1aWRhbmNlLw0KDQpUaGUgbGF0 dGVyIGRyYWZ0IGlzIChJTUhPKSBiZXR0ZXIgdmlld2VkIGFzIGEgcHJvb2Ytb2YtY29uY2VwdCBk ZW1vbnN0cmF0aW9uIHRoYXQgdGhpcyBjYW4gd29yaywgYXMgb3Bwb3NlZCB0byBhIHNwZWNpZmlj IHByb3RvY29sIGRlc2lnbiBmb3IgaG93IHRvIGRvIGl0LiAgRGVzaWduIGNvbmNlcm5zIGhhdmUg YmVlbiByYWlzZWQgYWJvdXQgd2hhdCB3YXMgZG9uZSB0aGVyZSAoZS5nLiwgYWdncmVzc2l2ZSB1 c2Ugb2YgVENQIG9wdGlvbnMpLg0KDQpGb3Igbm93IG15IGNvbmNsdXNpb24gaXM7IHRoZXJlIGlz IGludGVyZXN0IGluIHNvbHZpbmcgc2ltaWxhciBwcm9ibGVtcyBmb3IgVENQLCBzbyBhZGRpbmcg aXQgdG8gdGhlIFNQVUQgdXNlLWNhc2UgZGlzY3Vzc2lvbiBtYWtlIHNlbnNlLg0KDQoNCi0tIER5 bmFtaWMgUGVyIFR5cGUgUGFja2V0IFByaW9yaXRpemF0aW9uIChEUFRQUCAqc2lnaCopDQoNCldl YiBSVEMgd2FudHMgdG8gZG8gdGhpcyBmcm9tIHRoZSBhcHBsaWNhdGlvbjoNCg0KICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9z Lw0KDQpBbmQgaXQgY2FuIGJlIGRvbmUsIGlmIG9uZSBpcyBjYXJlZnVsOg0KDQogICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAvIChp biBSRkMgRWRpdG9yIFF1ZXVlKQ0KDQpXZSBoYXZlIGltcGxlbWVudGVkIGEgcHJvdG90eXBlIHNl dHRpbmcgZGlmZmVyZW50IERTQ1AgdmFsdWVzIG9uIGRpZmZlcmVudCB2aWRlbyBwYWNrZXRzIGEg ZmV3IHllYXJzIGJhY2suIFRoZSBwbGF0Zm9ybSB3ZSBkaWQgaXQgb24gd2FzIGEgYml0IHVuZGVy cG93ZXJlZCByZWdhcmRpbmcgbWFpbiBDUFUgdnMgdmlkZW8gZW5jL2RldiBwcm9jZXNzb3JzLiBU aGUgZXh0cmEgc2V0c29ja29wdCBjYWxsIHRvIGNoYW5nZSB0aGUgcHIgcGFja2V0IERTQ1AgdmFs dWUgY2F1c2VkIHByb2JsZW1zLiBXYXMgYWxzbyB1bnN1cmUgaWYgYW55IGJ1ZmZlcmluZyBpbiB0 aGUgT1MgY2F1c2UgdGhlIHJpZ2h0IG1hcmtpbmdzIHRvIGJlIHNldCBvbiB0aGUgcmlnaHQgcGFj a2V0LiBUaGUgc2VuZE1zZygpIGZ1bmN0aW9uIHdpbGwgcHJvYmFibHkgZW5zdXJlIHRoYXQsIGJ1 dCBhdCB0aGUgdGltZSB3ZSBkaWQgbm90IHJld3JpdGUgb3VyIHN0YWNrIHRvIHN1cHBvcnQgdGhh dC4NCg0KRG8gd2UgaGF2ZSBhbnkgaW5mb3JtYXRpb24gdGhhdCBuZXR3b3JrIGVsZW1lbnRzIGNh biBoYW5kbGUgZGlmZmVyZW50IERTQ1AgdmFsdWVzIHdpdGhpbiBhIDUtdHVwbGU/IFdvcmQgb24g dGhlIHN0cmVldCBhIGZldyB5ZWFycyBiYWNrIHdhcyB0aGF0IGl0IGNvdWxkIGJlIGRpZmZpY3Vs dCBmb3Igc29tZSBwbGF0Zm9ybXMuDQoNCkluIG15IGhlYWQgU1BVRCB3aWxsIGltcHJvdmUgdGhl IGFib3ZlIGRyYWZ0cyBieToNCg0KLSBQcm92aWRlIGVuZCB0byBlbmQgc2lnbmFsbGluZy4NCiAg KFdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtub3cgdGhlIHJhdGlvbmFsZSBvbiB3aHkgdGhlIG5l dHdvcmtzIHJlbWFya3MgdGhlIERTQ1AgdmFsdWVzIHNvIHdlIGNhbiBhdm9pZCB0aGF0IHdpdGgg U1BVRCkuDQoNCi0gRWFzaWVyIGZvciBhcHBsaWNhdGlvbnMuIEp1c3QgbWVtY3B5KCkgYSBzcHVk IGJ1ZmZlciBpbiBmcm9udCBvZiB5b3VyIFJUUCBwYWNrZXQgKE1ha2Ugc3VyZSB0byBzdGFydCB3 cml0aW5nIHlvdXIgUlRQIHBhY2tldCBhIGJpdCBpbnRvIHRoZSBidWZmZXLigKYpLCBhbmQgZmly ZSBvZmYgdGhlIHBhY2tldCBhcyB1c3VhbC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgYXNwZWN0IGFz IGl0IGVhc2VzIHRoZSBpbnRlZ3JhdGlvbiB3b3JrIG9mIFNQVUQuIElmIHRoZSBhcHBsaWNhdGlv biBhbHJlYWR5IHN1cHBvcnRzIElDRSBpdCBwcm9iYWJseSBkb2VzIGRvIHNpbWlsYXIgdHJpY2tz IGJlY2F1c2Ugb2YgVFVSTi4NCg0KLSBJdCBpcyBwb3NzaWJsZSB0byBidWlsZCBhIFNQVUQtPkRT Q1AgZ2F0ZXdheS4gVGhpcyBpcyBuaWNlIGFzIGN1c3RvbWVycyBjYW4gcGxhY2UgdGhhdCBnYXRl d2F5IGF0IHRoZSBlZGdlIGFuZCBzdGlsbCBoYXZlIHRoZSBvbGQgY2FyZWZ1bGx5IERTQ1AgY3Jh ZnRlZCBuZXR3b3JrIHByb3ZpZGUgdmFsdWUuDQoNCg0KLi0uDQpQw6VsLUVyaWsNCg0KDQoNClRo YW5rcywNCi0tRGF2aWQNCg0KRnJvbTogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IE1vbmRheSwgTWFyY2ggMTYsIDIwMTUg MTI6NTYgUE0NClRvOiBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNCkNjOiBzcHVkQGlldGYub3Jn PG1haWx0bzpzcHVkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTcHVkXSBBZGRpdGlvbmFsIFNQ VUQgdXNlLWNhc2VzDQoNCkhpIFDDpWwtRXJpaywNClRoYW5rcyBmb3IgeW91ciBtZXNzYWdlOyBz b21lIGNvbW1lbnRzIGluLWxpbmUuDQoNCk9uIE1vbiwgTWFyIDE2LCAyMDE1IGF0IDQ6MDcgQU0s IFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFydGlAY2lzY28uY29tPG1haWx0bzpwYWxt YXJ0aUBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpJIGhhdmUgYSBmZXcgYWRkaXRpb25hbCBT UFVEIHVzZS1jYXNlcyBJIHdhbnQgdG8gYnJpbmcgdG8gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0Yu IFNvbWUgb2YgdGhlbSBoYXZlIGFscmVhZHkgYmVlbiBzb2x2ZWQgYnkgdXNpbmcgU1RVTiBhcyBh IHNpZ25hbGxpbmcgcHJvdG9jb2wgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1tYXJ0 aW5zZW4tdHJhbS1kaXNjdXNzLTAyLnR4dCkuIEkgdGhpbmsgU1BVRCBpcyBhIG1vcmUgZWZmaWNp ZW50IGNhcnJpZXIgb2YgdGhlIGJpdHMgbmVlZGVkIHRvIHNvbHZlIHNvbWUgb2YgdGhlIHVzZS1j YXNlcy4gQnV0IGZvciBub3cgdGhleSBhcmUganVzdCB1c2UtY2FzZXMsIGFuZCBkaXNjdXNzaW9u cyBvbiBob3cgdG8gc29sdmUgdGhlbSBzaG91bGQgcHJvYmFibHkgYmUgZGVmZXJyZWQgdG8gYSBs YXRlciBzdGFnZS4NCg0KKiBSYXRlIEFkYXB0aW9uIFdpdGggQ29uZmlkZW5jZQ0KVG9kYXlzIGRl bGF5IHNlbnNpbmcgcmF0ZSBhZGFwdGlvbiBtZWNoYW5pc21zIHNlZW1zIHRvIGJlIHdvcmtpbmcg dmVyeSB3ZWxsIGFuZCBjYW4gcG90ZW50aWFsbHkgcmVhY3Qgd2l0aGluIGhhbGYgYSBSVFQgKElz IFRULCBUcmlwIFRpbWUsIG1vcmUgYWNjdXJhdGUgb3IgaW4gdXNlIGFzIGEgdGVybT8pLiBIYXZp bmcgZXhwbGljaXQgbmV0d29yayBmZWVkYmFjayBzaWduYWxsZWQgYmFjayB0byBlbmRwb2ludCBl bmFibGVkIGVuZHBvaW50cyB0byBwaWNrIGEgbW9yZSByZWFzb25hYmxlIHN0YXJ0aW5nIHZhbHVl IHdoZW4gc2VuZGluZyBtZWRpYS4gRXhwbGljaXQgc2lnbmFsbGluZyBkdXJpbmcgdGhlIGNhbGwg ZW5hYmxlcyB0aGUgbmV0d29yayBhcyB0byBzaWduYWwgaW5mb3JtYXRpb24gYmFjayB0byB0aGUg ZW5kcG9pbnQgYmVmb3JlIHRoZSBwcm9ibGVtcyBvY2N1ciAoRUNOKS4gVXAvZG93biBzcGVlZGlu ZyBjb3VsZCBwb3RlbnRpYWxseSBiZSBkb25lIGluIGxhcmdlciBjaHVua3Mgd2l0aCBjb25maWRl bmNlLg0KDQoqIEZpcnN0IENvbWUsIEZpcnN0IFNlcnZlDQpJbiBXaUZpIHdlIGhhdmUgc29tZSBs YWIgdGVzdHMgdGhhdCBzaG93IHdoZW4geW91IGhpdCBhIGxpbWl0IHlvdSBoaXQgaXQgaGFyZCBh bmQgZXZlcnlib2R5IG9uIHRoYXQgbGluayBzdWZmZXJzLiBJZiA5IHBlb3BsZSBlbmpveSB0aGVp ciB2aWRlbyBjb252ZXJzYXRpb25zIGdvaW5nIHRocm91Z2ggdGhlIHNhbWUgV2lGaSBBUCwgaXQg aXMgYW5ub3lpbmcgaWYgYSAxMHRoIGNhbGwgaXMgYWRkZWQgY2F1c2luZyBldmVyeWJvZHkgdG8g Z2V0IGJhZCB2aWRlby4gQSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0byBsZXQgdGhlIG5ldHdvcmsg c2lnbmFsIGJhY2sgdG8gdGhlIDEwdGggcGFydGljaXBhbnRzIHRyeWluZyB0byBzZW5kIHZpZGVv IHRoYXQgYmFuZHdpZHRoIGlzIG5vdCBhdmFpbGFibGU7IOKAnEkgd2lsbCBwdXQgeW91IGluIHdv cnNlIHRoYW4gYmVzdCBlZmZvcnQgcXVldWUgaWYgeW91IHRyeSB0byBzZW5kIGF0IHRoYXQgcmF0 ZeKAnS4gSWYgYmFuZHdpZHRoIGJlY29tZSBhdmFpbGFibGUgdGhlIG5ldHdvcmsgd2lsbCBub3Rp ZnkgdGhlIHVzZXIuIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBSU1ZQIGFuZCByZXNvdXJjZSBhbGxv Y2F0aW9uLCBqdXN0IGhpbnRzIGZyb20gdGhlIG5ldHdvcmsgdGhhdCBpZiB5b3UgdHJ5LCB5b3Ug d2lsbCBzdWZmZXIuDQrigIsNCg0K4oCLV2hlbiB5b3Ugc2F5ICJ0aGUgbmV0d29yayIgaGVyZSwg dGhpcyBzZWVtcyB0byBtZSB0aGUgZmlyc3QgaG9wLUFQLiAgRm9yIGNhc2VzIHdoZXJlIHRoZSBy YWRpbyByZXNvdXJjZXMgYXJlIGF0IGlzc3VlLCBpdCBzZWVtcyBsaWtlbHkgdGhhdCB5b3UgbWln aHQgd2FudCB0byBjb29yZGluYXRlIHRoaXMgd2l0aCB0aGUgb3RoZXIgODAyLjExIGZhY2lsaXRp ZXMsIHNvIEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgdGhlIHJpZ2h0IGxheWVyIHRvIGRvIHRoaXMu ICBJbiBwYXJ0aWN1bGFyLCBtdWx0aS1BUCBkZXBsb3ltZW50cyBtaWdodCByZXF1ZXN0IHRoZSBz dGF0aW9uIHJlLWFzc29jaWF0ZSB0byBhIGxlc3MtYnVzeSBBUCBvciBtYWtlIG90aGVyIGFkanVz dG1lbnRzIHRvIHRoZSBjaGFubmVsIGhhbmRsaW5nIG9mIGZyYW1lIG1hcmtlZCB3aXRoIHRoZSBo aWdoZXIgcHJpb3JpdHkgV01NIGJpdHMgKGdpdmVuIHRoZSBwb3RlbnRpYWwgaXNzdWVzIHdpdGgg Y3Jvc3MtdGFsaywgc2hpZnRpbmcgQVBzIGlzIGNlcnRhaW5seSBub3QgYSBwYW5hY2VhLCBidXQg bXkgYmUgYmV0dGVyIHRoYW4gd2hhdCBhbW91bnRzIHRvIGFkbWlzc2lvbiBjb250cm9sKS4NCuKA iw0KDQoqIER5bmFtaWMgUGVyIFR5cGUgUGFja2V0IFByaW9yaXRpc2F0aW9uIChEUFRQUCAqc2ln aCopDQpUaGUgU1BVRCB1c2UgY2FzZSBkcmFmdCBvcGVucyB1cCBmb3IgdHViZSBwcmlvcml0aXNh dGlvbi4gSXQgaXMgcG9zc2libGUgdG8gcHJpb3JpdGlzZSBhbW9uZyBmb3IgZXhhbXBsZSBhdWRp bywgdmlkZW8gYW5kIGRhdGEgdHViZXMgd2hlbiBtdWx0aXBsZXhpbmcgKEJ1bmRsZSkgaXMgaW4g dXNlLiBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgcHJpb3JpdGlzYXRpb24gaXMgbWFkZSBkeW5h bWljLiBXaGVuIHJ1bm5pbmcgYSB2aWRlbyBjb25mZXJlbmNlIHlvdSBtaWdodCB3YW50IHRvIHBy aW9yaXRpc2UgdmlkZW8gcGFja2V0cywgYnV0IHN1ZGRlbmx5IHRoZXJlIGlzIGEgbmVlZCB0byB1 cGxvYWQgYSBsYXJnZSBwcmVzZW50YXRpb24gdG8gYWxsIHRoZSBwYXJ0aWNpcGFudHMuIEluIHRo YXQgY2FzZSBpdCBtaWdodCBub3QgbWFrZSBzZW5zZSBmb3IgcGFydGljaXBhbnRzIGhhdmluZyBw cmlzdGluZSAxMDgwcDYwIHZpZGVvIHdhdGNoaW5nIGVhY2ggb3RoZXIgd2FpdGluZyBmb3IgdGhl IHNsb3cgdXBsb2FkaW5nIG9mIHRoZSBwcmVzZW50YXRpb24gdG8gZmluaXNoLg0KDQpBbmQgdGhl IHBhY2tldCB0eXBlIHByaW9yaXRpc2F0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IHN0b3AgYXQg YXVkaW8gb3IgdmlkZW8gbGV2ZWwuIFZpZGVvIHBhY2tldHMgY2FuIGhhdmUgZm9yIGV4YW1wbGUg c3BhdGlhbCBsYXllcnMgd2hlcmUgcGFja2V0cyBiZWxvbmdpbmcgdG8gYSB0ZW1wb3JhbCBsYXll ciBjYW4gYmUgZGlzY2FyZGVkIGJ5IHRoZSBuZXR3b3JrIHdpdGhvdXQgdG8gbXVjaCBpbXBhY3Qg b24gdGhlIHZpZGVvIHF1YWxpdHkuIERpc2NhcmRpbmcgYW4gSS1GcmFtZSB3b3VsZCBoYXZlIG11 Y2ggbW9yZSBpbXBhY3Qgb24gdGhlIHF1YWxpdHkuDQoNCg0K4oCLSSB0aGluayBvcmRpbmFsIHBy aW9yaXR5IGFtb25nIHRoZSB0dWJlcyBjb21pbmcgZnJvbSB0aGUgc2FtZSB1c2VyIGlzIGEgYmFz ZWxpbmUgdXNlIGNhc2UuICBUaGVyZSBzZWVtIHRvIGJlIHR3byBwb3NzaWJpbGl0aWVzIHRvIG1h a2luZyB0aGF0IGR5bmFtaWM6ICBtaW50IGEgbmV3IHR1YmUgb3Igc2V0IG9mIHR1YmVzIG9uIHRo ZSBzYW1lIDYtdHVwbGUg4oCLd2hlbiB0aGUgb3JkaW5hbCBwcmlvcml0eSBjaGFuZ2VzIG9yIHVw ZGF0ZSB0aGUgb3JkaW5hbCBwcmlvcml0eSBvbiB0aGUgZXhpc3RpbmcgdHViZXMuICBJIGFtIG5v dCBzdXJlIG9mIHRoZSBjb21wbGV4aXR5IHRyYWRlLW9mZiBiZXR3ZWVuIHRob3NlIHR3byB5ZXQs IGFuZCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBmb2xrcyB0aG91Z2h0cyBvbiB0aGF0Lg0KDQrigIty ZWdhcmRzLA0KVGVk4oCLDQoNCg0KDQoNCkNvbW1lbnRzLCBmbGFtZXMgYW5kIHdoYXQgbm90IGFy ZSBvZiBjb3Vyc2Ugd2VsY29tZS4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVk QGlldGYub3JnPG1haWx0bzpTcHVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHVkDQoNCg0K --_000_73D46BA8DB33481FB0FBDDD3B1F0F7FBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNiBN YXIgMjAxNSwgYXQgMjI6MDIsIEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlk LmJsYWNrQGVtYy5jb20iIGNsYXNzPSIiPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rp b24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj5IZXJlIGFyZSBmb3VyIHBvdGVudGlh bGx5IHJlbGF0ZWQgZHJhZnRzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpUaGFua3MgZm9yIHBvaW50aW5nIHRoZW0gb3V0LiBJbnRl cmVzdGluZyByZWFkLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNz PSIiPi0tIFJhdGUgQWRhcHRhdGlvbiBiYXNlZCBvbiBuZXR3b3JrIGZlZWRiYWNrLCBhbmQgKHRv IHNvbWUgZXh0ZW50KSBGQ0ZTICh3ZWFrKSBhZG1pc3Npb24gY29udHJvbDo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPlRoaXMgd29y ayBpcyBUQ1AgYmFzZWQsIGJ1dCB3aXRoIHNpbWlsYXIgZ29hbHM6PG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgdGV4dC1pbmRlbnQ6IDAuNWluOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNs YXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNw cmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaC8iIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJj aC88L2E+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgdGV4dC1pbmRlbnQ6IDAuNWluOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNs YXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZs aW5jay1tb2JpbGUtdGhyb3VnaHB1dC1ndWlkYW5jZS8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWZsaW5jay1tb2JpbGUtdGhyb3VnaHB1dC1ndWlkYW5jZS88L2E+ PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFz cz0iIj5UaGUgbGF0dGVyIGRyYWZ0IGlzIChJTUhPKSBiZXR0ZXIgdmlld2VkIGFzIGEgcHJvb2Yt b2YtY29uY2VwdCBkZW1vbnN0cmF0aW9uIHRoYXQgdGhpcyBjYW4gd29yaywgYXMgb3Bwb3NlZCB0 byBhIHNwZWNpZmljIHByb3RvY29sIGRlc2lnbiBmb3IgaG93IHRvIGRvIGl0LiZuYnNwOyBEZXNp Z24gY29uY2VybnMgaGF2ZSBiZWVuIHJhaXNlZA0KIGFib3V0IHdoYXQgd2FzIGRvbmUgdGhlcmUg KGUuZy4sIGFnZ3Jlc3NpdmUgdXNlIG9mIFRDUCBvcHRpb25zKS48bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Gb3Igbm93IG15IGNvbmNsdXNpb24gaXM7IHRoZXJlIGlz IGludGVyZXN0IGluIHNvbHZpbmcgc2ltaWxhciBwcm9ibGVtcyBmb3IgVENQLCBzbyBhZGRpbmcg aXQgdG8gdGhlIFNQVUQgdXNlLWNhc2UgZGlzY3Vzc2lvbiBtYWtlIHNlbnNlLjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24x OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4t LSBEeW5hbWljIFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXphdGlvbiAoRFBUUFAgKnNpZ2gqKTxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9 IiI+V2ViIFJUQyB3YW50cyB0byBkbyB0aGlzIGZyb20gdGhlIGFwcGxpY2F0aW9uOjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy88L2E+PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj5BbmQgaXQg Y2FuIGJlIGRvbmUsIGlmIG9uZSBpcyBjYXJlZnVsOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGFy dC1kc2NwLXJ0cC8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtZGFydC1kc2NwLXJ0cC88L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPihpbg0KIFJGQyBFZGl0b3IgUXVldWUpPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCldlIGhhdmUgaW1wbGVtZW50ZWQgYSBwcm90b3R5cGUgc2V0dGluZyBk aWZmZXJlbnQgRFNDUCB2YWx1ZXMgb24gZGlmZmVyZW50IHZpZGVvIHBhY2tldHMgYSBmZXcgeWVh cnMgYmFjay4gVGhlIHBsYXRmb3JtIHdlIGRpZCBpdCBvbiB3YXMgYSBiaXQgdW5kZXJwb3dlcmVk IHJlZ2FyZGluZyBtYWluIENQVSB2cyB2aWRlbyBlbmMvZGV2IHByb2Nlc3NvcnMuIFRoZSBleHRy YSBzZXRzb2Nrb3B0IGNhbGwgdG8gY2hhbmdlIHRoZSBwciBwYWNrZXQgRFNDUA0KIHZhbHVlIGNh dXNlZCBwcm9ibGVtcy4gV2FzIGFsc28gdW5zdXJlIGlmIGFueSBidWZmZXJpbmcgaW4gdGhlIE9T IGNhdXNlIHRoZSByaWdodCBtYXJraW5ncyB0byBiZSBzZXQgb24gdGhlIHJpZ2h0IHBhY2tldC4g VGhlIHNlbmRNc2coKSBmdW5jdGlvbiB3aWxsIHByb2JhYmx5IGVuc3VyZSB0aGF0LCBidXQgYXQg dGhlIHRpbWUgd2UgZGlkIG5vdCByZXdyaXRlIG91ciBzdGFjayB0byBzdXBwb3J0IHRoYXQuJm5i c3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5EbyB3ZSBoYXZlIGFu eSBpbmZvcm1hdGlvbiB0aGF0IG5ldHdvcmsgZWxlbWVudHMgY2FuIGhhbmRsZSBkaWZmZXJlbnQg RFNDUCB2YWx1ZXMgd2l0aGluIGEgNS10dXBsZT8gV29yZCBvbiB0aGUgc3RyZWV0IGEgZmV3IHll YXJzIGJhY2sgd2FzIHRoYXQgaXQgY291bGQgYmUgZGlmZmljdWx0IGZvciBzb21lIHBsYXRmb3Jt cy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkluIG15IGhlYWQgU1BV RCB3aWxsIGltcHJvdmUgdGhlIGFib3ZlIGRyYWZ0cyBieTo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2Pi0gUHJvdmlkZSBlbmQgdG8gZW5kIHNpZ25hbGxpbmcuJm5ic3A7 PC9kaXY+DQo8ZGl2PiZuYnNwOyAoV291bGQgYmUgaW50ZXJlc3RpbmcgdG8ga25vdyB0aGUgcmF0 aW9uYWxlIG9uIHdoeSB0aGUgbmV0d29ya3MgcmVtYXJrcyB0aGUgRFNDUCB2YWx1ZXMgc28gd2Ug Y2FuIGF2b2lkIHRoYXQgd2l0aCBTUFVEKS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2Pi0gRWFzaWVyIGZvciBhcHBsaWNhdGlvbnMuIEp1c3QgbWVtY3B5KCkgYSBzcHVk IGJ1ZmZlciBpbiBmcm9udCBvZiB5b3VyIFJUUCBwYWNrZXQgKE1ha2Ugc3VyZSB0byBzdGFydCB3 cml0aW5nIHlvdXIgUlRQIHBhY2tldCBhIGJpdCBpbnRvIHRoZSBidWZmZXLigKYpLCBhbmQgZmly ZSBvZmYgdGhlIHBhY2tldCBhcyB1c3VhbC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgYXNwZWN0IGFz IGl0IGVhc2VzIHRoZSBpbnRlZ3JhdGlvbiB3b3JrIG9mIFNQVUQuDQogSWYgdGhlIGFwcGxpY2F0 aW9uIGFscmVhZHkgc3VwcG9ydHMgSUNFIGl0IHByb2JhYmx5IGRvZXMgZG8gc2ltaWxhciB0cmlj a3MgYmVjYXVzZSBvZiBUVVJOLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+LSBJdCBpcyBwb3NzaWJsZSB0byBidWlsZCBhIFNQVUQtJmd0O0RTQ1AgZ2F0ZXdh eS4gVGhpcyBpcyBuaWNlIGFzIGN1c3RvbWVycyBjYW4gcGxhY2UgdGhhdCBnYXRld2F5IGF0IHRo ZSBlZGdlIGFuZCBzdGlsbCBoYXZlIHRoZSBvbGQgY2FyZWZ1bGx5IERTQ1AgY3JhZnRlZCBuZXR3 b3JrIHByb3ZpZGUgdmFsdWUuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8ZGl2PlDDpWwt RXJpazwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxl PSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0i Ij5UaGFua3MsPGJyIGNsYXNzPSIiPg0KLS1EYXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwaW4g MGluIDBpbiA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2 LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRh aG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNwdWQg WzxhIGhyZWY9Im1haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVy cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1haWx0bzpzcHVkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VGVkIEhhcmRpZTxiciBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5Nb25kYXksIE1hcmNoIDE2LCAyMDE1IDEyOjU2IFBNPGJyIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5QYWwgTWFydGluc2VuIChwYWxtYXJ0aSk8YnIgY2xhc3M9IiI+DQo8YiBj bGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzcHVkQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zcHVkQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW1NwdWRdIEFkZGl0aW9uYWwgU1BV RCB1c2UtY2FzZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ SGkgUMOlbC1FcmlrLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPlRoYW5rcyBmb3IgeW91ciBtZXNzYWdlOyBzb21lIGNvbW1lbnRzIGluLWxpbmUuPG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNDow NyBBTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpICZsdDs8YSBocmVmPSJtYWlsdG86cGFsbWFy dGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+cGFsbWFydGlAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSGksPHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KSSBoYXZlIGEgZmV3IGFkZGl0aW9uYWwgU1BVRCB1c2UtY2FzZXMgSSB3YW50 IHRvIGJyaW5nIHRvIHRoZSBsaXN0IGJlZm9yZSB0aGUgQm9GLiBTb21lIG9mIHRoZW0gaGF2ZSBh bHJlYWR5IGJlZW4gc29sdmVkIGJ5IHVzaW5nIFNUVU4gYXMgYSBzaWduYWxsaW5nIHByb3RvY29s ICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbWFydGluc2VuLXRyYW0t ZGlzY3Vzcy0wMi50eHQiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtbWFydGluc2VuLXRyYW0tZGlzY3Vzcy0wMi50eHQ8L2E+KS4NCiBJIHRoaW5rIFNQ VUQgaXMgYSBtb3JlIGVmZmljaWVudCBjYXJyaWVyIG9mIHRoZSBiaXRzIG5lZWRlZCB0byBzb2x2 ZSBzb21lIG9mIHRoZSB1c2UtY2FzZXMuIEJ1dCBmb3Igbm93IHRoZXkgYXJlIGp1c3QgdXNlLWNh c2VzLCBhbmQgZGlzY3Vzc2lvbnMgb24gaG93IHRvIHNvbHZlIHRoZW0gc2hvdWxkIHByb2JhYmx5 IGJlIGRlZmVycmVkIHRvIGEgbGF0ZXIgc3RhZ2UuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiogUmF0ZSBBZGFwdGlvbiBXaXRoIENvbmZpZGVuY2U8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRvZGF5cyBkZWxheSBzZW5zaW5nIHJhdGUgYWRh cHRpb24gbWVjaGFuaXNtcyBzZWVtcyB0byBiZSB3b3JraW5nIHZlcnkgd2VsbCBhbmQgY2FuIHBv dGVudGlhbGx5IHJlYWN0IHdpdGhpbiBoYWxmIGEgUlRUIChJcyBUVCwgVHJpcCBUaW1lLCBtb3Jl IGFjY3VyYXRlIG9yIGluIHVzZSBhcyBhIHRlcm0/KS4gSGF2aW5nIGV4cGxpY2l0IG5ldHdvcmsg ZmVlZGJhY2sgc2lnbmFsbGVkIGJhY2sgdG8gZW5kcG9pbnQgZW5hYmxlZCBlbmRwb2ludHMgdG8N CiBwaWNrIGEgbW9yZSByZWFzb25hYmxlIHN0YXJ0aW5nIHZhbHVlIHdoZW4gc2VuZGluZyBtZWRp YS4gRXhwbGljaXQgc2lnbmFsbGluZyBkdXJpbmcgdGhlIGNhbGwgZW5hYmxlcyB0aGUgbmV0d29y ayBhcyB0byBzaWduYWwgaW5mb3JtYXRpb24gYmFjayB0byB0aGUgZW5kcG9pbnQgYmVmb3JlIHRo ZSBwcm9ibGVtcyBvY2N1ciAoRUNOKS4gVXAvZG93biBzcGVlZGluZyBjb3VsZCBwb3RlbnRpYWxs eSBiZSBkb25lIGluIGxhcmdlciBjaHVua3Mgd2l0aA0KIGNvbmZpZGVuY2UuJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiogRmlyc3QgQ29tZSwgRmlyc3QgU2VydmUm bmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkluIFdpRmkg d2UgaGF2ZSBzb21lIGxhYiB0ZXN0cyB0aGF0IHNob3cgd2hlbiB5b3UgaGl0IGEgbGltaXQgeW91 IGhpdCBpdCBoYXJkIGFuZCBldmVyeWJvZHkgb24gdGhhdCBsaW5rIHN1ZmZlcnMuIElmIDkgcGVv cGxlIGVuam95IHRoZWlyIHZpZGVvIGNvbnZlcnNhdGlvbnMgZ29pbmcgdGhyb3VnaCB0aGUgc2Ft ZSBXaUZpIEFQLCBpdCBpcyBhbm5veWluZyBpZiBhIDEwdGggY2FsbCBpcyBhZGRlZCBjYXVzaW5n IGV2ZXJ5Ym9keSB0byBnZXQgYmFkDQogdmlkZW8uIEEgcG9zc2libGUgc29sdXRpb24gaXMgdG8g bGV0IHRoZSBuZXR3b3JrIHNpZ25hbCBiYWNrIHRvIHRoZSAxMHRoIHBhcnRpY2lwYW50cyB0cnlp bmcgdG8gc2VuZCB2aWRlbyB0aGF0IGJhbmR3aWR0aCBpcyBub3QgYXZhaWxhYmxlOyDigJxJIHdp bGwgcHV0IHlvdSBpbiB3b3JzZSB0aGFuIGJlc3QgZWZmb3J0IHF1ZXVlIGlmIHlvdSB0cnkgdG8g c2VuZCBhdCB0aGF0IHJhdGXigJ0uIElmIGJhbmR3aWR0aCBiZWNvbWUgYXZhaWxhYmxlIHRoZQ0K IG5ldHdvcmsgd2lsbCBub3RpZnkgdGhlIHVzZXIuIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBSU1ZQ IGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uLCBqdXN0IGhpbnRzIGZyb20gdGhlIG5ldHdvcmsgdGhh dCBpZiB5b3UgdHJ5LCB5b3Ugd2lsbCBzdWZmZXIuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K4oCLPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj7igItXaGVuIHlvdSBzYXkgJnF1b3Q7dGhl IG5ldHdvcmsmcXVvdDsgaGVyZSwgdGhpcyBzZWVtcyB0byBtZSB0aGUgZmlyc3QgaG9wLUFQLiZu YnNwOyBGb3IgY2FzZXMgd2hlcmUgdGhlIHJhZGlvIHJlc291cmNlcyBhcmUgYXQgaXNzdWUsIGl0 IHNlZW1zIGxpa2VseSB0aGF0IHlvdSBtaWdodCB3YW50IHRvIGNvb3JkaW5hdGUgdGhpcyB3aXRo IHRoZSBvdGhlciA4MDIuMTEgZmFjaWxpdGllcywNCiBzbyBJJ20gbm90IHN1cmUgdGhhdCB0aGlz IHRoZSByaWdodCBsYXllciB0byBkbyB0aGlzLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBtdWx0aS1B UCBkZXBsb3ltZW50cyBtaWdodCByZXF1ZXN0IHRoZSBzdGF0aW9uIHJlLWFzc29jaWF0ZSB0byBh IGxlc3MtYnVzeSBBUCBvciBtYWtlIG90aGVyIGFkanVzdG1lbnRzIHRvIHRoZSBjaGFubmVsIGhh bmRsaW5nIG9mIGZyYW1lIG1hcmtlZCB3aXRoIHRoZSBoaWdoZXIgcHJpb3JpdHkgV01NIGJpdHMg KGdpdmVuIHRoZQ0KIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBjcm9zcy10YWxrLCBzaGlmdGluZyBB UHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFjZWEsIGJ1dCBteSBiZSBiZXR0ZXIgdGhhbiB3aGF0 IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRyb2wpLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0 eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIw NCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0 OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGluOyIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K4oCLPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9y OiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBp biAwaW4gMGluIDZwdDsgbWFyZ2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBpbjsiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KKiBEeW5hbWljIFBlciBUeXBlIFBhY2tl dCBQcmlvcml0aXNhdGlvbiAoRFBUUFAgKnNpZ2gqKTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KVGhlIFNQVUQgdXNlIGNhc2UgZHJhZnQgb3BlbnMgdXAgZm9yIHR1 YmUgcHJpb3JpdGlzYXRpb24uIEl0IGlzIHBvc3NpYmxlIHRvIHByaW9yaXRpc2UgYW1vbmcgZm9y IGV4YW1wbGUgYXVkaW8sIHZpZGVvIGFuZCBkYXRhIHR1YmVzIHdoZW4gbXVsdGlwbGV4aW5nIChC dW5kbGUpIGlzIGluIHVzZS4gSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHByaW9yaXRpc2F0aW9u IGlzIG1hZGUgZHluYW1pYy4gV2hlbiBydW5uaW5nIGEgdmlkZW8gY29uZmVyZW5jZQ0KIHlvdSBt aWdodCB3YW50IHRvIHByaW9yaXRpc2UgdmlkZW8gcGFja2V0cywgYnV0IHN1ZGRlbmx5IHRoZXJl IGlzIGEgbmVlZCB0byB1cGxvYWQgYSBsYXJnZSBwcmVzZW50YXRpb24gdG8gYWxsIHRoZSBwYXJ0 aWNpcGFudHMuIEluIHRoYXQgY2FzZSBpdCBtaWdodCBub3QgbWFrZSBzZW5zZSBmb3IgcGFydGlj aXBhbnRzIGhhdmluZyBwcmlzdGluZSAxMDgwcDYwIHZpZGVvIHdhdGNoaW5nIGVhY2ggb3RoZXIg d2FpdGluZyBmb3IgdGhlIHNsb3cgdXBsb2FkaW5nDQogb2YgdGhlIHByZXNlbnRhdGlvbiB0byBm aW5pc2guPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkFuZCB0aGUgcGFja2V0 IHR5cGUgcHJpb3JpdGlzYXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgc3RvcCBhdCBhdWRpbyBv ciB2aWRlbyBsZXZlbC4gVmlkZW8gcGFja2V0cyBjYW4gaGF2ZSBmb3IgZXhhbXBsZSBzcGF0aWFs IGxheWVycyB3aGVyZSBwYWNrZXRzIGJlbG9uZ2luZyB0byBhIHRlbXBvcmFsIGxheWVyIGNhbiBi ZSBkaXNjYXJkZWQgYnkgdGhlIG5ldHdvcmsgd2l0aG91dCB0byBtdWNoIGltcGFjdCBvbiB0aGUg dmlkZW8gcXVhbGl0eS4NCiBEaXNjYXJkaW5nIGFuIEktRnJhbWUgd291bGQgaGF2ZSBtdWNoIG1v cmUgaW1wYWN0IG9uIHRoZSBxdWFsaXR5LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+4oCLSSB0aGluayBvcmRpbmFsIHByaW9yaXR5IGFtb25nIHRoZSB0 dWJlcyBjb21pbmcgZnJvbSB0aGUgc2FtZSB1c2VyIGlzIGEgYmFzZWxpbmUgdXNlIGNhc2UuJm5i c3A7IFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMgdG8gbWFraW5nIHRoYXQgZHlu YW1pYzombmJzcDsgbWludCBhIG5ldyB0dWJlIG9yIHNldCBvZiB0dWJlcyBvbiB0aGUgc2FtZSA2 LXR1cGxlDQog4oCLd2hlbiB0aGUgb3JkaW5hbCBwcmlvcml0eSBjaGFuZ2VzIG9yIHVwZGF0ZSB0 aGUgb3JkaW5hbCBwcmlvcml0eSBvbiB0aGUgZXhpc3RpbmcgdHViZXMuJm5ic3A7IEkgYW0gbm90 IHN1cmUgb2YgdGhlIGNvbXBsZXhpdHkgdHJhZGUtb2ZmIGJldHdlZW4gdGhvc2UgdHdvIHlldCwg YW5kIEknZCBiZSBpbnRlcmVzdGVkIGluIGZvbGtzIHRob3VnaHRzIG9uIHRoYXQuPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPuKAi3JlZ2FyZHMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+VGVk4oCLPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9y ZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFw dDsgcGFkZGluZzogMGluIDBpbiAwaW4gNnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1y aWdodDogMGluOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQ29tbWVudHMsIGZsYW1lcyBhbmQgd2hh dCBub3QgYXJlIG9mIGNvdXJzZSB3ZWxjb21lLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQouLS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NClDDpWwtRXJpazxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxiciBj bGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KU3B1ZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86U3B1ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPlNwdWRAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHVkIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHVkPC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_73D46BA8DB33481FB0FBDDD3B1F0F7FBciscocom_-- From nobody Tue Mar 17 03:02:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00061A01FA for ; Tue, 17 Mar 2015 03:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 bhBfQiLIZIf6 for ; Tue, 17 Mar 2015 03:02:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BD61A01F7 for ; Tue, 17 Mar 2015 03:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20396; q=dns/txt; s=iport; t=1426586539; x=1427796139; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qj06TduFaIBfC+dLSgfdRm3u+Zv2KppiQHjpG5YHRzc=; b=Q86AHeN+37GbH+/P+Qbb6/Q8VF7D5pRI4ZHZfwYGlmdic92zol63Im1o yF2u1cm7hm6WWt8SElUlcg4Mc0+E0xeWcv5vdcp4uZ8p1AhamvmXlE/D6 ul25b/UUHAl4JeBtfvWiLkHGpI0dSBub9H4QEZZuyj80fRJpWZY0PyF22 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEBgDA+gdV/4wNJK1bgwZSWgSDCMBpgXIBCYV1AhyBGUwBAQEBAQF9hBABAQQBAQEgRAEGBgUQAgEIPwMCAgIfBgsUEQIEDgUbiAADEQ2uBJVcDYU3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oYf4JEgVUBUwQHgmgvgRYFkD6DbIFkgk2BTIEbOotXTIJbg0cjg25vAYEBAR8ifwEBAQ X-IronPort-AV: E=Sophos;i="5.11,415,1422921600"; d="scan'208,217";a="404616614" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2015 10:02:18 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2HA2IJV032324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 10:02:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 05:02:17 -0500 From: "Pal Martinsen (palmarti)" To: Ted Hardie Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fqEUAgAEe0IA= Date: Tue, 17 Mar 2015 10:02:17 +0000 Message-ID: <3427E188-C99C-4E48-AF52-CEE9CC9F4CD6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.174.40] Content-Type: multipart/alternative; boundary="_000_3427E188C99C4E48AF52CEE9CC9F4CD6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:02:22 -0000 --_000_3427E188C99C4E48AF52CEE9CC9F4CD6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxNiBNYXIgMjAxNSwgYXQgMTc6NTUsIFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNv bTxtYWlsdG86dGVkLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIFDDpWwtRXJpaywNCg0K VGhhbmtzIGZvciB5b3VyIG1lc3NhZ2U7IHNvbWUgY29tbWVudHMgaW4tbGluZS4NCg0KT24gTW9u LCBNYXIgMTYsIDIwMTUgYXQgNDowNyBBTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIDxwYWxt YXJ0aUBjaXNjby5jb208bWFpbHRvOnBhbG1hcnRpQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGksDQoN CkkgaGF2ZSBhIGZldyBhZGRpdGlvbmFsIFNQVUQgdXNlLWNhc2VzIEkgd2FudCB0byBicmluZyB0 byB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4gU29tZSBvZiB0aGVtIGhhdmUgYWxyZWFkeSBiZWVu IHNvbHZlZCBieSB1c2luZyBTVFVOIGFzIGEgc2lnbmFsbGluZyBwcm90b2NvbCAoaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIudHh0KS4gSSB0 aGluayBTUFVEIGlzIGEgbW9yZSBlZmZpY2llbnQgY2FycmllciBvZiB0aGUgYml0cyBuZWVkZWQg dG8gc29sdmUgc29tZSBvZiB0aGUgdXNlLWNhc2VzLiBCdXQgZm9yIG5vdyB0aGV5IGFyZSBqdXN0 IHVzZS1jYXNlcywgYW5kIGRpc2N1c3Npb25zIG9uIGhvdyB0byBzb2x2ZSB0aGVtIHNob3VsZCBw cm9iYWJseSBiZSBkZWZlcnJlZCB0byBhIGxhdGVyIHN0YWdlLg0KDQoqIFJhdGUgQWRhcHRpb24g V2l0aCBDb25maWRlbmNlDQpUb2RheXMgZGVsYXkgc2Vuc2luZyByYXRlIGFkYXB0aW9uIG1lY2hh bmlzbXMgc2VlbXMgdG8gYmUgd29ya2luZyB2ZXJ5IHdlbGwgYW5kIGNhbiBwb3RlbnRpYWxseSBy ZWFjdCB3aXRoaW4gaGFsZiBhIFJUVCAoSXMgVFQsIFRyaXAgVGltZSwgbW9yZSBhY2N1cmF0ZSBv ciBpbiB1c2UgYXMgYSB0ZXJtPykuIEhhdmluZyBleHBsaWNpdCBuZXR3b3JrIGZlZWRiYWNrIHNp Z25hbGxlZCBiYWNrIHRvIGVuZHBvaW50IGVuYWJsZWQgZW5kcG9pbnRzIHRvIHBpY2sgYSBtb3Jl IHJlYXNvbmFibGUgc3RhcnRpbmcgdmFsdWUgd2hlbiBzZW5kaW5nIG1lZGlhLiBFeHBsaWNpdCBz aWduYWxsaW5nIGR1cmluZyB0aGUgY2FsbCBlbmFibGVzIHRoZSBuZXR3b3JrIGFzIHRvIHNpZ25h bCBpbmZvcm1hdGlvbiBiYWNrIHRvIHRoZSBlbmRwb2ludCBiZWZvcmUgdGhlIHByb2JsZW1zIG9j Y3VyIChFQ04pLiBVcC9kb3duIHNwZWVkaW5nIGNvdWxkIHBvdGVudGlhbGx5IGJlIGRvbmUgaW4g bGFyZ2VyIGNodW5rcyB3aXRoIGNvbmZpZGVuY2UuDQoNCiogRmlyc3QgQ29tZSwgRmlyc3QgU2Vy dmUNCkluIFdpRmkgd2UgaGF2ZSBzb21lIGxhYiB0ZXN0cyB0aGF0IHNob3cgd2hlbiB5b3UgaGl0 IGEgbGltaXQgeW91IGhpdCBpdCBoYXJkIGFuZCBldmVyeWJvZHkgb24gdGhhdCBsaW5rIHN1ZmZl cnMuIElmIDkgcGVvcGxlIGVuam95IHRoZWlyIHZpZGVvIGNvbnZlcnNhdGlvbnMgZ29pbmcgdGhy b3VnaCB0aGUgc2FtZSBXaUZpIEFQLCBpdCBpcyBhbm5veWluZyBpZiBhIDEwdGggY2FsbCBpcyBh ZGRlZCBjYXVzaW5nIGV2ZXJ5Ym9keSB0byBnZXQgYmFkIHZpZGVvLiBBIHBvc3NpYmxlIHNvbHV0 aW9uIGlzIHRvIGxldCB0aGUgbmV0d29yayBzaWduYWwgYmFjayB0byB0aGUgMTB0aCBwYXJ0aWNp cGFudHMgdHJ5aW5nIHRvIHNlbmQgdmlkZW8gdGhhdCBiYW5kd2lkdGggaXMgbm90IGF2YWlsYWJs ZTsg4oCcSSB3aWxsIHB1dCB5b3UgaW4gd29yc2UgdGhhbiBiZXN0IGVmZm9ydCBxdWV1ZSBpZiB5 b3UgdHJ5IHRvIHNlbmQgYXQgdGhhdCByYXRl4oCdLiBJZiBiYW5kd2lkdGggYmVjb21lIGF2YWls YWJsZSB0aGUgbmV0d29yayB3aWxsIG5vdGlmeSB0aGUgdXNlci4gTm90ZSB0aGF0IHRoaXMgaXMg bm90IFJTVlAgYW5kIHJlc291cmNlIGFsbG9jYXRpb24sIGp1c3QgaGludHMgZnJvbSB0aGUgbmV0 d29yayB0aGF0IGlmIHlvdSB0cnksIHlvdSB3aWxsIHN1ZmZlci4NCuKAiw0KDQrigItXaGVuIHlv dSBzYXkg4oCcdGhlIG5ldHdvcmsiIGhlcmUsIHRoaXMgc2VlbXMgdG8gbWUgdGhlIGZpcnN0IGhv cC1BUC4NCg0KVGhhdCBwcm9iYWJseSBwcm92aWRlcyBtb3N0IHZhbHVlLiBCdXQgdGhlIHVzZSBj YXNlIGlzIG5vdCBsaW1pdGVkIHRvIGp1c3Qgd2lyZWxlc3MuIEl0IGNhbiBiZSB1c2VmdWwgZm9y IGEgY29mZmVlc2hvcCB0byBoYXZlIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSBwZXJmb3JtZWQgYnkg dGhlIGdhdGV3YXkgZGV2aWNlLg0KDQpGb3IgY2FzZXMgd2hlcmUgdGhlIHJhZGlvIHJlc291cmNl cyBhcmUgYXQgaXNzdWUsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHlvdSBtaWdodCB3YW50IHRvIGNv b3JkaW5hdGUgdGhpcyB3aXRoIHRoZSBvdGhlciA4MDIuMTEgZmFjaWxpdGllcywgc28gSSdtIG5v dCBzdXJlIHRoYXQgdGhpcyB0aGUgcmlnaHQgbGF5ZXIgdG8gZG8gdGhpcy4gIEluIHBhcnRpY3Vs YXIsIG11bHRpLUFQIGRlcGxveW1lbnRzIG1pZ2h0IHJlcXVlc3QgdGhlIHN0YXRpb24gcmUtYXNz b2NpYXRlIHRvIGEgbGVzcy1idXN5IEFQIG9yIG1ha2Ugb3RoZXIgYWRqdXN0bWVudHMgdG8gdGhl IGNoYW5uZWwgaGFuZGxpbmcgb2YgZnJhbWUgbWFya2VkIHdpdGggdGhlIGhpZ2hlciBwcmlvcml0 eSBXTU0gYml0cyAoZ2l2ZW4gdGhlIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBjcm9zcy10YWxrLCBz aGlmdGluZyBBUHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFjZWEsIGJ1dCBteSBiZSBiZXR0ZXIg dGhhbiB3aGF0IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRyb2wpLg0KDQpZZXMuIENsb3NlIGNv b3JkaW5hdGlvbiB3aXRoIHRoZSBsYXllcnMgYmVuZWF0aCBhcmUgbmVlZGVkLiBUaGlzIGNhbiBh bHNvIGJlIHZpZXdlZCBhcyBhbiBhcHBsaWNhdGlvbiBmcmllbmRseSB0c3BlYyBzaWduYWxsaW5n LiBUc3BlYyBzaG91bGQgaGFuZGxlIHRoaXMsIGJ1dCBnZXR0aW5nIHRoYXQgaW5mb3JtYXRpb24g ZnJvbSB0aGUgd2lyZWxlc3MgZHJpdmVyIGFsbCB0aGUgd2F5IHVwIHRvIHRoZSBhcHBsaWNhdGlv biBtaWdodCBwcm92ZSBkaWZmaWN1bHQgd2l0aG91dCBhbnkgYWRtaW4gcHJpdmlsZWdlcy4NCg0K 4oCLDQoNCiogRHluYW1pYyBQZXIgVHlwZSBQYWNrZXQgUHJpb3JpdGlzYXRpb24gKERQVFBQICpz aWdoKikNClRoZSBTUFVEIHVzZSBjYXNlIGRyYWZ0IG9wZW5zIHVwIGZvciB0dWJlIHByaW9yaXRp c2F0aW9uLiBJdCBpcyBwb3NzaWJsZSB0byBwcmlvcml0aXNlIGFtb25nIGZvciBleGFtcGxlIGF1 ZGlvLCB2aWRlbyBhbmQgZGF0YSB0dWJlcyB3aGVuIG11bHRpcGxleGluZyAoQnVuZGxlKSBpcyBp biB1c2UuIEl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBwcmlvcml0aXNhdGlvbiBpcyBtYWRlIGR5 bmFtaWMuIFdoZW4gcnVubmluZyBhIHZpZGVvIGNvbmZlcmVuY2UgeW91IG1pZ2h0IHdhbnQgdG8g cHJpb3JpdGlzZSB2aWRlbyBwYWNrZXRzLCBidXQgc3VkZGVubHkgdGhlcmUgaXMgYSBuZWVkIHRv IHVwbG9hZCBhIGxhcmdlIHByZXNlbnRhdGlvbiB0byBhbGwgdGhlIHBhcnRpY2lwYW50cy4gSW4g dGhhdCBjYXNlIGl0IG1pZ2h0IG5vdCBtYWtlIHNlbnNlIGZvciBwYXJ0aWNpcGFudHMgaGF2aW5n IHByaXN0aW5lIDEwODBwNjAgdmlkZW8gd2F0Y2hpbmcgZWFjaCBvdGhlciB3YWl0aW5nIGZvciB0 aGUgc2xvdyB1cGxvYWRpbmcgb2YgdGhlIHByZXNlbnRhdGlvbiB0byBmaW5pc2guDQoNCkFuZCB0 aGUgcGFja2V0IHR5cGUgcHJpb3JpdGlzYXRpb24gZG9lcyBub3QgbmVjZXNzYXJpbHkgc3RvcCBh dCBhdWRpbyBvciB2aWRlbyBsZXZlbC4gVmlkZW8gcGFja2V0cyBjYW4gaGF2ZSBmb3IgZXhhbXBs ZSBzcGF0aWFsIGxheWVycyB3aGVyZSBwYWNrZXRzIGJlbG9uZ2luZyB0byBhIHRlbXBvcmFsIGxh eWVyIGNhbiBiZSBkaXNjYXJkZWQgYnkgdGhlIG5ldHdvcmsgd2l0aG91dCB0byBtdWNoIGltcGFj dCBvbiB0aGUgdmlkZW8gcXVhbGl0eS4gRGlzY2FyZGluZyBhbiBJLUZyYW1lIHdvdWxkIGhhdmUg bXVjaCBtb3JlIGltcGFjdCBvbiB0aGUgcXVhbGl0eS4NCg0KDQrigItJIHRoaW5rIG9yZGluYWwg cHJpb3JpdHkgYW1vbmcgdGhlIHR1YmVzIGNvbWluZyBmcm9tIHRoZSBzYW1lIHVzZXIgaXMgYSBi YXNlbGluZSB1c2UgY2FzZS4gIFRoZXJlIHNlZW0gdG8gYmUgdHdvIHBvc3NpYmlsaXRpZXMgdG8g bWFraW5nIHRoYXQgZHluYW1pYzogIG1pbnQgYSBuZXcgdHViZSBvciBzZXQgb2YgdHViZXMgb24g dGhlIHNhbWUgNi10dXBsZSDigIt3aGVuIHRoZSBvcmRpbmFsIHByaW9yaXR5IGNoYW5nZXMgb3Ig dXBkYXRlIHRoZSBvcmRpbmFsIHByaW9yaXR5IG9uIHRoZSBleGlzdGluZyB0dWJlcy4gIEkgYW0g bm90IHN1cmUgb2YgdGhlIGNvbXBsZXhpdHkgdHJhZGUtb2ZmIGJldHdlZW4gdGhvc2UgdHdvIHll dCwgYW5kIEknZCBiZSBpbnRlcmVzdGVkIGluIGZvbGtzIHRob3VnaHRzIG9uIHRoYXQuDQoNCklu c3RpbmN0aXZlbHkgSSB3b3VsZCBzYXkgbWFrZSBpdCBlYXN5IGZvciB0aGUgYXBwIGRldmVsb3Bl ci4gQW5kIEkgdGhpbmsgdXBkYXRpbmcgcHJpb3JpdGllcyBpbiBleGlzdGluZyB0dWJlcyBpcyB0 aGUgZWFzaWVzIHdheS4gVGhleSBhcmUgYWxyZWFkeSBzZXQgdXAsIGFuZCBtaWRkbGUgYm94ZXMg aGF2ZSBhY2NlcHRlZCB0aGUgdHViZXMuIFRlYXJpbmcgZG93biBhbmQgc2V0dGluZyB1cCBuZXcg dHViZXMgc2VlbXMgdG8gY2F1c2UgbW9yZSBwYWluIGZvciBhbGwgaW52b2x2ZWQgcGFydGllcy4N Cg0KQnV0IG1vcmUgY29uc2lkZXJhdGlvbnMgc2hvdWxkIGJlIGdpdmVuIHRvIGhvdyB0byBiZXN0 IHNvbHZlIHRoaXMgcHJvYmxlbS4NCg0KLi0uDQpQw6VsLUVyaWsNCg0K4oCLcmVnYXJkcywNCg0K VGVk4oCLDQoNCg0KDQoNCkNvbW1lbnRzLCBmbGFtZXMgYW5kIHdoYXQgbm90IGFyZSBvZiBjb3Vy c2Ugd2VsY29tZS4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVkQGlldGYub3Jn PG1haWx0bzpTcHVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHVkDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVkQGlldGYub3JnPG1haWx0bzpTcHVkQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQoNCg== --_000_3427E188C99C4E48AF52CEE9CC9F4CD6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNiBN YXIgMjAxNSwgYXQgMTc6NTUsIFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0 ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTp0YWhvbWEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K SGkgUMOlbC1FcmlrLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaGFua3MgZm9yIHlvdXIgbWVzc2FnZTsgc29tZSBjb21tZW50 cyBpbi1saW5lLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE1hciAxNiwg MjAxNSBhdCA0OjA3IEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNCjxzcGFuIGRpcj0ibHRy IiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbG1hcnRpQGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPnBhbG1hcnRpQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0 LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZCIgY2xhc3M9IiI+SGksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JIGhhdmUgYSBmZXcgYWRkaXRpb25hbCBTUFVEIHVzZS1jYXNlcyBJIHdhbnQg dG8gYnJpbmcgdG8gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuIFNvbWUgb2YgdGhlbSBoYXZlIGFs cmVhZHkgYmVlbiBzb2x2ZWQgYnkgdXNpbmcgU1RVTiBhcyBhIHNpZ25hbGxpbmcgcHJvdG9jb2wg KDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1k aXNjdXNzLTAyLnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1kaXNjdXNzLTAyLnR4dDwvYT4pLg0KIEkgdGhp bmsgU1BVRCBpcyBhIG1vcmUgZWZmaWNpZW50IGNhcnJpZXIgb2YgdGhlIGJpdHMgbmVlZGVkIHRv IHNvbHZlIHNvbWUgb2YgdGhlIHVzZS1jYXNlcy4gQnV0IGZvciBub3cgdGhleSBhcmUganVzdCB1 c2UtY2FzZXMsIGFuZCBkaXNjdXNzaW9ucyBvbiBob3cgdG8gc29sdmUgdGhlbSBzaG91bGQgcHJv YmFibHkgYmUgZGVmZXJyZWQgdG8gYSBsYXRlciBzdGFnZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiogUmF0ZSBBZGFwdGlvbiBXaXRo IENvbmZpZGVuY2U8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VG9kYXlzIGRlbGF5IHNlbnNpbmcgcmF0 ZSBhZGFwdGlvbiBtZWNoYW5pc21zIHNlZW1zIHRvIGJlIHdvcmtpbmcgdmVyeSB3ZWxsIGFuZCBj YW4gcG90ZW50aWFsbHkgcmVhY3Qgd2l0aGluIGhhbGYgYSBSVFQgKElzIFRULCBUcmlwIFRpbWUs IG1vcmUgYWNjdXJhdGUgb3IgaW4gdXNlIGFzIGEgdGVybT8pLiBIYXZpbmcgZXhwbGljaXQgbmV0 d29yayBmZWVkYmFjayBzaWduYWxsZWQgYmFjayB0byBlbmRwb2ludCBlbmFibGVkDQogZW5kcG9p bnRzIHRvIHBpY2sgYSBtb3JlIHJlYXNvbmFibGUgc3RhcnRpbmcgdmFsdWUgd2hlbiBzZW5kaW5n IG1lZGlhLiBFeHBsaWNpdCBzaWduYWxsaW5nIGR1cmluZyB0aGUgY2FsbCBlbmFibGVzIHRoZSBu ZXR3b3JrIGFzIHRvIHNpZ25hbCBpbmZvcm1hdGlvbiBiYWNrIHRvIHRoZSBlbmRwb2ludCBiZWZv cmUgdGhlIHByb2JsZW1zIG9jY3VyIChFQ04pLiBVcC9kb3duIHNwZWVkaW5nIGNvdWxkIHBvdGVu dGlhbGx5IGJlIGRvbmUgaW4gbGFyZ2VyDQogY2h1bmtzIHdpdGggY29uZmlkZW5jZS4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PiogRmlyc3QgQ29tZSwgRmlyc3QgU2VydmUmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4g V2lGaSB3ZSBoYXZlIHNvbWUgbGFiIHRlc3RzIHRoYXQgc2hvdyB3aGVuIHlvdSBoaXQgYSBsaW1p dCB5b3UgaGl0IGl0IGhhcmQgYW5kIGV2ZXJ5Ym9keSBvbiB0aGF0IGxpbmsgc3VmZmVycy4gSWYg OSBwZW9wbGUgZW5qb3kgdGhlaXIgdmlkZW8gY29udmVyc2F0aW9ucyBnb2luZyB0aHJvdWdoIHRo ZSBzYW1lIFdpRmkgQVAsIGl0IGlzIGFubm95aW5nIGlmIGEgMTB0aCBjYWxsIGlzIGFkZGVkIGNh dXNpbmcgZXZlcnlib2R5DQogdG8gZ2V0IGJhZCB2aWRlby4gQSBwb3NzaWJsZSBzb2x1dGlvbiBp cyB0byBsZXQgdGhlIG5ldHdvcmsgc2lnbmFsIGJhY2sgdG8gdGhlIDEwdGggcGFydGljaXBhbnRz IHRyeWluZyB0byBzZW5kIHZpZGVvIHRoYXQgYmFuZHdpZHRoIGlzIG5vdCBhdmFpbGFibGU7IOKA nEkgd2lsbCBwdXQgeW91IGluIHdvcnNlIHRoYW4gYmVzdCBlZmZvcnQgcXVldWUgaWYgeW91IHRy eSB0byBzZW5kIGF0IHRoYXQgcmF0ZeKAnS4gSWYgYmFuZHdpZHRoIGJlY29tZSBhdmFpbGFibGUN CiB0aGUgbmV0d29yayB3aWxsIG5vdGlmeSB0aGUgdXNlci4gTm90ZSB0aGF0IHRoaXMgaXMgbm90 IFJTVlAgYW5kIHJlc291cmNlIGFsbG9jYXRpb24sIGp1c3QgaGludHMgZnJvbSB0aGUgbmV0d29y ayB0aGF0IGlmIHlvdSB0cnksIHlvdSB3aWxsIHN1ZmZlci4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPuKAizwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs bDtkaXNwbGF5OmlubGluZSI+DQrigItXaGVuIHlvdSBzYXkg4oCcdGhlIG5ldHdvcmsmcXVvdDsg aGVyZSwgdGhpcyBzZWVtcyB0byBtZSB0aGUgZmlyc3QgaG9wLUFQLiZuYnNwOyA8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGF0IHByb2JhYmx5IHByb3ZpZGVzIG1vc3Qg dmFsdWUuIEJ1dCB0aGUgdXNlIGNhc2UgaXMgbm90IGxpbWl0ZWQgdG8ganVzdCB3aXJlbGVzcy4g SXQgY2FuIGJlIHVzZWZ1bCBmb3IgYSBjb2ZmZWVzaG9wIHRvIGhhdmUgc2ltaWxhciBmdW5jdGlv bmFsaXR5IHBlcmZvcm1lZCBieSB0aGUgZ2F0ZXdheSBkZXZpY2UuJm5ic3A7PC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dGFob21hLHNhbnMtc2VyaWY7Zm9udC1z aXplOnNtYWxsO2Rpc3BsYXk6aW5saW5lIj4NCkZvciBjYXNlcyB3aGVyZSB0aGUgcmFkaW8gcmVz b3VyY2VzIGFyZSBhdCBpc3N1ZSwgaXQgc2VlbXMgbGlrZWx5IHRoYXQgeW91IG1pZ2h0IHdhbnQg dG8gY29vcmRpbmF0ZSB0aGlzIHdpdGggdGhlIG90aGVyIDgwMi4xMSBmYWNpbGl0aWVzLCBzbyBJ J20gbm90IHN1cmUgdGhhdCB0aGlzIHRoZSByaWdodCBsYXllciB0byBkbyB0aGlzLiZuYnNwOyBJ biBwYXJ0aWN1bGFyLCBtdWx0aS1BUCBkZXBsb3ltZW50cyBtaWdodCByZXF1ZXN0IHRoZSBzdGF0 aW9uIHJlLWFzc29jaWF0ZQ0KIHRvIGEgbGVzcy1idXN5IEFQIG9yIG1ha2Ugb3RoZXIgYWRqdXN0 bWVudHMgdG8gdGhlIGNoYW5uZWwgaGFuZGxpbmcgb2YgZnJhbWUgbWFya2VkIHdpdGggdGhlIGhp Z2hlciBwcmlvcml0eSBXTU0gYml0cyAoZ2l2ZW4gdGhlIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBj cm9zcy10YWxrLCBzaGlmdGluZyBBUHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFjZWEsIGJ1dCBt eSBiZSBiZXR0ZXIgdGhhbiB3aGF0IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRyb2wpLiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Plllcy4gQ2xvc2UgY29vcmRp bmF0aW9uIHdpdGggdGhlIGxheWVycyBiZW5lYXRoIGFyZSBuZWVkZWQuIFRoaXMgY2FuIGFsc28g YmUgdmlld2VkIGFzIGFuIGFwcGxpY2F0aW9uIGZyaWVuZGx5IHRzcGVjIHNpZ25hbGxpbmcuIFRz cGVjIHNob3VsZCBoYW5kbGUgdGhpcywgYnV0IGdldHRpbmcgdGhhdCBpbmZvcm1hdGlvbiBmcm9t IHRoZSB3aXJlbGVzcyBkcml2ZXIgYWxsIHRoZSB3YXkgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIG1p Z2h0IHByb3ZlDQogZGlmZmljdWx0IHdpdGhvdXQgYW55IGFkbWluIHByaXZpbGVnZXMuPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPuKAizxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiogRHluYW1pYyBQ ZXIgVHlwZSBQYWNrZXQgUHJpb3JpdGlzYXRpb24gKERQVFBQICpzaWdoKik8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhlIFNQVUQgdXNlIGNhc2UgZHJhZnQgb3BlbnMgdXAgZm9yIHR1YmUgcHJpb3Jp dGlzYXRpb24uIEl0IGlzIHBvc3NpYmxlIHRvIHByaW9yaXRpc2UgYW1vbmcgZm9yIGV4YW1wbGUg YXVkaW8sIHZpZGVvIGFuZCBkYXRhIHR1YmVzIHdoZW4gbXVsdGlwbGV4aW5nIChCdW5kbGUpIGlz IGluIHVzZS4gSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHByaW9yaXRpc2F0aW9uIGlzIG1hZGUg ZHluYW1pYy4gV2hlbiBydW5uaW5nIGENCiB2aWRlbyBjb25mZXJlbmNlIHlvdSBtaWdodCB3YW50 IHRvIHByaW9yaXRpc2UgdmlkZW8gcGFja2V0cywgYnV0IHN1ZGRlbmx5IHRoZXJlIGlzIGEgbmVl ZCB0byB1cGxvYWQgYSBsYXJnZSBwcmVzZW50YXRpb24gdG8gYWxsIHRoZSBwYXJ0aWNpcGFudHMu IEluIHRoYXQgY2FzZSBpdCBtaWdodCBub3QgbWFrZSBzZW5zZSBmb3IgcGFydGljaXBhbnRzIGhh dmluZyBwcmlzdGluZSAxMDgwcDYwIHZpZGVvIHdhdGNoaW5nIGVhY2ggb3RoZXIgd2FpdGluZw0K IGZvciB0aGUgc2xvdyB1cGxvYWRpbmcgb2YgdGhlIHByZXNlbnRhdGlvbiB0byBmaW5pc2guPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5B bmQgdGhlIHBhY2tldCB0eXBlIHByaW9yaXRpc2F0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IHN0 b3AgYXQgYXVkaW8gb3IgdmlkZW8gbGV2ZWwuIFZpZGVvIHBhY2tldHMgY2FuIGhhdmUgZm9yIGV4 YW1wbGUgc3BhdGlhbCBsYXllcnMgd2hlcmUgcGFja2V0cyBiZWxvbmdpbmcgdG8gYSB0ZW1wb3Jh bCBsYXllciBjYW4gYmUgZGlzY2FyZGVkIGJ5IHRoZSBuZXR3b3JrIHdpdGhvdXQgdG8gbXVjaCBp bXBhY3Qgb24gdGhlIHZpZGVvDQogcXVhbGl0eS4gRGlzY2FyZGluZyBhbiBJLUZyYW1lIHdvdWxk IGhhdmUgbXVjaCBtb3JlIGltcGFjdCBvbiB0aGUgcXVhbGl0eS4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQrigItJ IHRoaW5rIG9yZGluYWwgcHJpb3JpdHkgYW1vbmcgdGhlIHR1YmVzIGNvbWluZyBmcm9tIHRoZSBz YW1lIHVzZXIgaXMgYSBiYXNlbGluZSB1c2UgY2FzZS4mbmJzcDsgVGhlcmUgc2VlbSB0byBiZSB0 d28gcG9zc2liaWxpdGllcyB0byBtYWtpbmcgdGhhdCBkeW5hbWljOiZuYnNwOyBtaW50IGEgbmV3 IHR1YmUgb3Igc2V0IG9mIHR1YmVzIG9uIHRoZSBzYW1lIDYtdHVwbGUg4oCLd2hlbiB0aGUgb3Jk aW5hbCBwcmlvcml0eSBjaGFuZ2VzIG9yIHVwZGF0ZSB0aGUgb3JkaW5hbA0KIHByaW9yaXR5IG9u IHRoZSBleGlzdGluZyB0dWJlcy4mbmJzcDsgSSBhbSBub3Qgc3VyZSBvZiB0aGUgY29tcGxleGl0 eSB0cmFkZS1vZmYgYmV0d2VlbiB0aG9zZSB0d28geWV0LCBhbmQgSSdkIGJlIGludGVyZXN0ZWQg aW4gZm9sa3MgdGhvdWdodHMgb24gdGhhdC4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+SW5zdGluY3RpdmVseSBJIHdvdWxkIHNheSBtYWtlIGl0IGVhc3kgZm9yIHRo ZSBhcHAgZGV2ZWxvcGVyLiBBbmQgSSB0aGluayB1cGRhdGluZyBwcmlvcml0aWVzIGluIGV4aXN0 aW5nIHR1YmVzIGlzIHRoZSBlYXNpZXMgd2F5LiBUaGV5IGFyZSBhbHJlYWR5IHNldCB1cCwgYW5k IG1pZGRsZSBib3hlcyBoYXZlIGFjY2VwdGVkIHRoZSB0dWJlcy4gVGVhcmluZyBkb3duIGFuZCBz ZXR0aW5nIHVwIG5ldyB0dWJlcyBzZWVtcyB0byBjYXVzZSBtb3JlDQogcGFpbiBmb3IgYWxsIGlu dm9sdmVkIHBhcnRpZXMuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj5CdXQgbW9yZSBjb25zaWRlcmF0aW9ucyBzaG91bGQgYmUgZ2l2ZW4gdG8gaG93IHRvIGJl c3Qgc29sdmUgdGhpcyBwcm9ibGVtLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Li0uPC9kaXY+DQo8ZGl2PlDDpWwtRXJpazwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQri gItyZWdhcmRzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQpUZWTigIs8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOzwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNvbW1lbnRzLCBmbGFtZXMgYW5kIHdo YXQgbm90IGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi4tLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTcHVkIG1h aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpTcHVkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+U3B1ZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQiIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwdWQ8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTcHVkIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpTcHVkQGlldGYub3JnIiBjbGFzcz0iIj5T cHVkQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3B1ZDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3427E188C99C4E48AF52CEE9CC9F4CD6ciscocom_-- From nobody Tue Mar 17 07:19:28 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31371A1A67 for ; Tue, 17 Mar 2015 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 neHfRY-Ci1de for ; Tue, 17 Mar 2015 07:19:23 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 0B8D61A1A7C for ; Tue, 17 Mar 2015 07:19:19 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2HEJBM8006225 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Mar 2015 10:19:14 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2HEJBM8006225 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1426601954; bh=rrL/vBoPSFsizFwlMoUZM1N0FzU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=WuQfffhiQxjq8lVYGXH7fPphqBUfsN/x8KPkX600BR/Uu8dRrxBB+ocWoQPR5Gqq7 KEwAWNQaoJYKvMp6K2cMhE+vttpTAVpxdIml6a3nsD1Ih+v+riWL71vjAWk+HPkaf9 pLrb+2ylBvvo1tnAgvpOJ2dsKw5AF+SgAXn+zqMY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2HEJBM8006225 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 17 Mar 2015 10:18:53 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2HEIrRI009375 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 10:18:53 -0400 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 17 Mar 2015 10:18:52 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0224.002; Tue, 17 Mar 2015 10:18:52 -0400 From: "Black, David" To: "Pal Martinsen (palmarti)" Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fl4EA///wybCAASnYAIAABnyw Date: Tue, 17 Mar 2015 14:18:51 +0000 Message-ID: References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> In-Reply-To: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.163] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936414CF2MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:19:28 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936414CF2MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAtLSBSYXRlIEFkYXB0YXRpb24gYmFzZWQgb24gbmV0d29yayBmZWVkYmFjaywgYW5kICh0byBz b21lIGV4dGVudCkgRkNGUyAod2VhaykgYWRtaXNzaW9uIGNvbnRyb2w6DQo+DQo+IFRoaXMgd29y ayBpcyBUQ1AgYmFzZWQsIGJ1dCB3aXRoIHNpbWlsYXIgZ29hbHM6DQpbLi4uIHNuaXAgLi4uXQ0K PiBGb3Igbm93IG15IGNvbmNsdXNpb24gaXM7IHRoZXJlIGlzIGludGVyZXN0IGluIHNvbHZpbmcg c2ltaWxhciBwcm9ibGVtcyBmb3IgVENQLCBzbyBhZGRpbmcgaXQgdG8gdGhlIFNQVUQgdXNlLWNh c2UgZGlzY3Vzc2lvbiBtYWtlIHNlbnNlLg0KDQorMSAtIHRoYXQgd2FzIHRoZSByZWFzb24gZm9y IHNlbmRpbmcgdGhvc2UgZHJhZnQgcG9pbnRlcnMuDQoNCj4gRG8gd2UgaGF2ZSBhbnkgaW5mb3Jt YXRpb24gdGhhdCBuZXR3b3JrIGVsZW1lbnRzIGNhbiBoYW5kbGUgZGlmZmVyZW50IERTQ1AgdmFs dWVzIHdpdGhpbiBhIDUtdHVwbGU/DQo+IFdvcmQgb24gdGhlIHN0cmVldCBhIGZldyB5ZWFycyBi YWNrIHdhcyB0aGF0IGl0IGNvdWxkIGJlIGRpZmZpY3VsdCBmb3Igc29tZSBwbGF0Zm9ybXMuDQoN ClRoZSBwcm9ibGVtcyBhcmVu4oCZdCBzbyBtdWNoIG5ldHdvcmsgZWxlbWVudHMsIGFzIHRoZXkg YXJlIHRyYW5zcG9ydCBwcm90b2NvbCBzaWRlIGVmZmVjdHMuICBTZWUgdGhlIERBUlQgZHJhZnQg Zm9yIG1vcmUuDQoNCj4gSW4gbXkgaGVhZCBTUFVEIHdpbGwgaW1wcm92ZSB0aGUgYWJvdmUgZHJh ZnRzIGJ5Og0KPg0KPiAtIFByb3ZpZGUgZW5kIHRvIGVuZCBzaWduYWxsaW5nLg0KPiAgKFdvdWxk IGJlIGludGVyZXN0aW5nIHRvIGtub3cgdGhlIHJhdGlvbmFsZSBvbiB3aHkgdGhlIG5ldHdvcmtz IHJlbWFya3MgdGhlIERTQ1AgdmFsdWVzIHNvIHdlIGNhbiBhdm9pZCB0aGF0IHdpdGggU1BVRCku DQoNCkxvc2luZyBiYXR0bGU7IHZhbHVlcyB0aGF0IGNhbuKAmXQgYmUgcmV3cml0dGVuIHdpbGwg YmUgaWdub3JlZC4gIElmIERTQ1AgdmFsdWVzIGFyZSB1c2VkIGZvciBRb1MsIHRoZXnigJlyZSBw YXJ0IG9mIHRoZSBuZXR3b3Jr4oCZcyB0cmFmZmljIGVuZ2luZWVyaW5nIGFuZCBoZW5jZSBoYXZl IHRvIGJlIHJld3JpdGFibGUgYnkgdGhlIG5ldHdvcmsgb3BlcmF0b3IgKHByaW9yIG9wdGltaXNt IHRoYXQgdGhlIHZhbHVlcyB3b3VsZCBzb21laG93IHBhc3MgdGhyb3VnaCBhbGwgbmV0d29ya3Mg dW5jaGFuZ2VkIHcvZWFjaCBuZXR3b3JrIGRvaW5nIHNvbWV0aGluZyByZWFzb25hYmxlIGhhcyBw cm92ZW4gdG8gYmUgbmHDr3ZlKTsgaWYgdGhleSBjYW7igJl0IGJlIHJld3JpdHRlbiwgdGhleSB3 aWxsIChoYXZlIHRvKSBiZSBpZ25vcmVkLCBJTUhPLiAgVGhpcyBkcmFmdCBwcm92aWRlcyBzb21l IGluZm8gYWJvdXQgYW4gYXBwcm9hY2ggd2l0aCBlbmQtdG8tZW5kIHBvc3NpYmlsaXRpZXMgdGhh dCBpcyBsaWtlbHkgdG8gd29yayBpZiBpdCBnZXRzIGFkb3B0ZWQgYW5kIHdpZGVseSBkZXBsb3ll ZDoNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRzdndnLWRp ZmZzZXJ2LWludGVyY29uLw0KDQpUaGFua3MsDQotLURhdmlkDQoNCkZyb206IFNwdWQgW21haWx0 bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDE1IDU6NDggQU0NClRvOiBCbGFjaywg RGF2aWQNCkNjOiBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NwdWRdIEFkZGl0aW9uYWwg U1BVRCB1c2UtY2FzZXMNCg0KDQpPbiAxNiBNYXIgMjAxNSwgYXQgMjI6MDIsIEJsYWNrLCBEYXZp ZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbT4+IHdyb3Rl Og0KDQpIZXJlIGFyZSBmb3VyIHBvdGVudGlhbGx5IHJlbGF0ZWQgZHJhZnRzOg0KDQoNClRoYW5r cyBmb3IgcG9pbnRpbmcgdGhlbSBvdXQuIEludGVyZXN0aW5nIHJlYWQuDQoNCg0KLS0gUmF0ZSBB ZGFwdGF0aW9uIGJhc2VkIG9uIG5ldHdvcmsgZmVlZGJhY2ssIGFuZCAodG8gc29tZSBleHRlbnQp IEZDRlMgKHdlYWspIGFkbWlzc2lvbiBjb250cm9sOg0KDQpUaGlzIHdvcmsgaXMgVENQIGJhc2Vk LCBidXQgd2l0aCBzaW1pbGFyIGdvYWxzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gvDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mbGluY2stbW9iaWxlLXRocm91Z2hwdXQt Z3VpZGFuY2UvDQoNClRoZSBsYXR0ZXIgZHJhZnQgaXMgKElNSE8pIGJldHRlciB2aWV3ZWQgYXMg YSBwcm9vZi1vZi1jb25jZXB0IGRlbW9uc3RyYXRpb24gdGhhdCB0aGlzIGNhbiB3b3JrLCBhcyBv cHBvc2VkIHRvIGEgc3BlY2lmaWMgcHJvdG9jb2wgZGVzaWduIGZvciBob3cgdG8gZG8gaXQuICBE ZXNpZ24gY29uY2VybnMgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB3aGF0IHdhcyBkb25lIHRoZXJl IChlLmcuLCBhZ2dyZXNzaXZlIHVzZSBvZiBUQ1Agb3B0aW9ucykuDQoNCkZvciBub3cgbXkgY29u Y2x1c2lvbiBpczsgdGhlcmUgaXMgaW50ZXJlc3QgaW4gc29sdmluZyBzaW1pbGFyIHByb2JsZW1z IGZvciBUQ1AsIHNvIGFkZGluZyBpdCB0byB0aGUgU1BVRCB1c2UtY2FzZSBkaXNjdXNzaW9uIG1h a2Ugc2Vuc2UuDQoNCg0KDQotLSBEeW5hbWljIFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXphdGlv biAoRFBUUFAgKnNpZ2gqKQ0KDQpXZWIgUlRDIHdhbnRzIHRvIGRvIHRoaXMgZnJvbSB0aGUgYXBw bGljYXRpb246DQoNCiAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdHN2d2ctcnRjd2ViLXFvcy8NCg0KQW5kIGl0IGNhbiBiZSBkb25lLCBpZiBvbmUgaXMg Y2FyZWZ1bDoNCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kYXJ0LWRzY3AtcnRwLyAoaW4gUkZDIEVkaXRvciBRdWV1ZSkNCg0KV2UgaGF2ZSBpbXBs ZW1lbnRlZCBhIHByb3RvdHlwZSBzZXR0aW5nIGRpZmZlcmVudCBEU0NQIHZhbHVlcyBvbiBkaWZm ZXJlbnQgdmlkZW8gcGFja2V0cyBhIGZldyB5ZWFycyBiYWNrLiBUaGUgcGxhdGZvcm0gd2UgZGlk IGl0IG9uIHdhcyBhIGJpdCB1bmRlcnBvd2VyZWQgcmVnYXJkaW5nIG1haW4gQ1BVIHZzIHZpZGVv IGVuYy9kZXYgcHJvY2Vzc29ycy4gVGhlIGV4dHJhIHNldHNvY2tvcHQgY2FsbCB0byBjaGFuZ2Ug dGhlIHByIHBhY2tldCBEU0NQIHZhbHVlIGNhdXNlZCBwcm9ibGVtcy4gV2FzIGFsc28gdW5zdXJl IGlmIGFueSBidWZmZXJpbmcgaW4gdGhlIE9TIGNhdXNlIHRoZSByaWdodCBtYXJraW5ncyB0byBi ZSBzZXQgb24gdGhlIHJpZ2h0IHBhY2tldC4gVGhlIHNlbmRNc2coKSBmdW5jdGlvbiB3aWxsIHBy b2JhYmx5IGVuc3VyZSB0aGF0LCBidXQgYXQgdGhlIHRpbWUgd2UgZGlkIG5vdCByZXdyaXRlIG91 ciBzdGFjayB0byBzdXBwb3J0IHRoYXQuDQoNCkRvIHdlIGhhdmUgYW55IGluZm9ybWF0aW9uIHRo YXQgbmV0d29yayBlbGVtZW50cyBjYW4gaGFuZGxlIGRpZmZlcmVudCBEU0NQIHZhbHVlcyB3aXRo aW4gYSA1LXR1cGxlPyBXb3JkIG9uIHRoZSBzdHJlZXQgYSBmZXcgeWVhcnMgYmFjayB3YXMgdGhh dCBpdCBjb3VsZCBiZSBkaWZmaWN1bHQgZm9yIHNvbWUgcGxhdGZvcm1zLg0KDQpJbiBteSBoZWFk IFNQVUQgd2lsbCBpbXByb3ZlIHRoZSBhYm92ZSBkcmFmdHMgYnk6DQoNCi0gUHJvdmlkZSBlbmQg dG8gZW5kIHNpZ25hbGxpbmcuDQogIChXb3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93IHRoZSBy YXRpb25hbGUgb24gd2h5IHRoZSBuZXR3b3JrcyByZW1hcmtzIHRoZSBEU0NQIHZhbHVlcyBzbyB3 ZSBjYW4gYXZvaWQgdGhhdCB3aXRoIFNQVUQpLg0KDQotIEVhc2llciBmb3IgYXBwbGljYXRpb25z LiBKdXN0IG1lbWNweSgpIGEgc3B1ZCBidWZmZXIgaW4gZnJvbnQgb2YgeW91ciBSVFAgcGFja2V0 IChNYWtlIHN1cmUgdG8gc3RhcnQgd3JpdGluZyB5b3VyIFJUUCBwYWNrZXQgYSBiaXQgaW50byB0 aGUgYnVmZmVy4oCmKSwgYW5kIGZpcmUgb2ZmIHRoZSBwYWNrZXQgYXMgdXN1YWwuIFRoaXMgaXMg YW4gaW1wb3J0YW50IGFzcGVjdCBhcyBpdCBlYXNlcyB0aGUgaW50ZWdyYXRpb24gd29yayBvZiBT UFVELiBJZiB0aGUgYXBwbGljYXRpb24gYWxyZWFkeSBzdXBwb3J0cyBJQ0UgaXQgcHJvYmFibHkg ZG9lcyBkbyBzaW1pbGFyIHRyaWNrcyBiZWNhdXNlIG9mIFRVUk4uDQoNCi0gSXQgaXMgcG9zc2li bGUgdG8gYnVpbGQgYSBTUFVELT5EU0NQIGdhdGV3YXkuIFRoaXMgaXMgbmljZSBhcyBjdXN0b21l cnMgY2FuIHBsYWNlIHRoYXQgZ2F0ZXdheSBhdCB0aGUgZWRnZSBhbmQgc3RpbGwgaGF2ZSB0aGUg b2xkIGNhcmVmdWxseSBEU0NQIGNyYWZ0ZWQgbmV0d29yayBwcm92aWRlIHZhbHVlLg0KDQoNCi4t Lg0KUMOlbC1FcmlrDQoNCg0KDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KRnJvbTogU3B1ZCBbbWFp bHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6 IE1vbmRheSwgTWFyY2ggMTYsIDIwMTUgMTI6NTYgUE0NClRvOiBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkNCkNjOiBzcHVkQGlldGYub3JnPG1haWx0bzpzcHVkQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtTcHVkXSBBZGRpdGlvbmFsIFNQVUQgdXNlLWNhc2VzDQoNCkhpIFDDpWwtRXJpaywNClRo YW5rcyBmb3IgeW91ciBtZXNzYWdlOyBzb21lIGNvbW1lbnRzIGluLWxpbmUuDQoNCk9uIE1vbiwg TWFyIDE2LCAyMDE1IGF0IDQ6MDcgQU0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFy dGlAY2lzY28uY29tPG1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpJ IGhhdmUgYSBmZXcgYWRkaXRpb25hbCBTUFVEIHVzZS1jYXNlcyBJIHdhbnQgdG8gYnJpbmcgdG8g dGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuIFNvbWUgb2YgdGhlbSBoYXZlIGFscmVhZHkgYmVlbiBz b2x2ZWQgYnkgdXNpbmcgU1RVTiBhcyBhIHNpZ25hbGxpbmcgcHJvdG9jb2wgKGh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1kaXNjdXNzLTAyLnR4dCkuIEkgdGhp bmsgU1BVRCBpcyBhIG1vcmUgZWZmaWNpZW50IGNhcnJpZXIgb2YgdGhlIGJpdHMgbmVlZGVkIHRv IHNvbHZlIHNvbWUgb2YgdGhlIHVzZS1jYXNlcy4gQnV0IGZvciBub3cgdGhleSBhcmUganVzdCB1 c2UtY2FzZXMsIGFuZCBkaXNjdXNzaW9ucyBvbiBob3cgdG8gc29sdmUgdGhlbSBzaG91bGQgcHJv YmFibHkgYmUgZGVmZXJyZWQgdG8gYSBsYXRlciBzdGFnZS4NCg0KKiBSYXRlIEFkYXB0aW9uIFdp dGggQ29uZmlkZW5jZQ0KVG9kYXlzIGRlbGF5IHNlbnNpbmcgcmF0ZSBhZGFwdGlvbiBtZWNoYW5p c21zIHNlZW1zIHRvIGJlIHdvcmtpbmcgdmVyeSB3ZWxsIGFuZCBjYW4gcG90ZW50aWFsbHkgcmVh Y3Qgd2l0aGluIGhhbGYgYSBSVFQgKElzIFRULCBUcmlwIFRpbWUsIG1vcmUgYWNjdXJhdGUgb3Ig aW4gdXNlIGFzIGEgdGVybT8pLiBIYXZpbmcgZXhwbGljaXQgbmV0d29yayBmZWVkYmFjayBzaWdu YWxsZWQgYmFjayB0byBlbmRwb2ludCBlbmFibGVkIGVuZHBvaW50cyB0byBwaWNrIGEgbW9yZSBy ZWFzb25hYmxlIHN0YXJ0aW5nIHZhbHVlIHdoZW4gc2VuZGluZyBtZWRpYS4gRXhwbGljaXQgc2ln bmFsbGluZyBkdXJpbmcgdGhlIGNhbGwgZW5hYmxlcyB0aGUgbmV0d29yayBhcyB0byBzaWduYWwg aW5mb3JtYXRpb24gYmFjayB0byB0aGUgZW5kcG9pbnQgYmVmb3JlIHRoZSBwcm9ibGVtcyBvY2N1 ciAoRUNOKS4gVXAvZG93biBzcGVlZGluZyBjb3VsZCBwb3RlbnRpYWxseSBiZSBkb25lIGluIGxh cmdlciBjaHVua3Mgd2l0aCBjb25maWRlbmNlLg0KDQoqIEZpcnN0IENvbWUsIEZpcnN0IFNlcnZl DQpJbiBXaUZpIHdlIGhhdmUgc29tZSBsYWIgdGVzdHMgdGhhdCBzaG93IHdoZW4geW91IGhpdCBh IGxpbWl0IHlvdSBoaXQgaXQgaGFyZCBhbmQgZXZlcnlib2R5IG9uIHRoYXQgbGluayBzdWZmZXJz LiBJZiA5IHBlb3BsZSBlbmpveSB0aGVpciB2aWRlbyBjb252ZXJzYXRpb25zIGdvaW5nIHRocm91 Z2ggdGhlIHNhbWUgV2lGaSBBUCwgaXQgaXMgYW5ub3lpbmcgaWYgYSAxMHRoIGNhbGwgaXMgYWRk ZWQgY2F1c2luZyBldmVyeWJvZHkgdG8gZ2V0IGJhZCB2aWRlby4gQSBwb3NzaWJsZSBzb2x1dGlv biBpcyB0byBsZXQgdGhlIG5ldHdvcmsgc2lnbmFsIGJhY2sgdG8gdGhlIDEwdGggcGFydGljaXBh bnRzIHRyeWluZyB0byBzZW5kIHZpZGVvIHRoYXQgYmFuZHdpZHRoIGlzIG5vdCBhdmFpbGFibGU7 IOKAnEkgd2lsbCBwdXQgeW91IGluIHdvcnNlIHRoYW4gYmVzdCBlZmZvcnQgcXVldWUgaWYgeW91 IHRyeSB0byBzZW5kIGF0IHRoYXQgcmF0ZeKAnS4gSWYgYmFuZHdpZHRoIGJlY29tZSBhdmFpbGFi bGUgdGhlIG5ldHdvcmsgd2lsbCBub3RpZnkgdGhlIHVzZXIuIE5vdGUgdGhhdCB0aGlzIGlzIG5v dCBSU1ZQIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uLCBqdXN0IGhpbnRzIGZyb20gdGhlIG5ldHdv cmsgdGhhdCBpZiB5b3UgdHJ5LCB5b3Ugd2lsbCBzdWZmZXIuDQrigIsNCg0K4oCLV2hlbiB5b3Ug c2F5ICJ0aGUgbmV0d29yayIgaGVyZSwgdGhpcyBzZWVtcyB0byBtZSB0aGUgZmlyc3QgaG9wLUFQ LiAgRm9yIGNhc2VzIHdoZXJlIHRoZSByYWRpbyByZXNvdXJjZXMgYXJlIGF0IGlzc3VlLCBpdCBz ZWVtcyBsaWtlbHkgdGhhdCB5b3UgbWlnaHQgd2FudCB0byBjb29yZGluYXRlIHRoaXMgd2l0aCB0 aGUgb3RoZXIgODAyLjExIGZhY2lsaXRpZXMsIHNvIEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgdGhl IHJpZ2h0IGxheWVyIHRvIGRvIHRoaXMuICBJbiBwYXJ0aWN1bGFyLCBtdWx0aS1BUCBkZXBsb3lt ZW50cyBtaWdodCByZXF1ZXN0IHRoZSBzdGF0aW9uIHJlLWFzc29jaWF0ZSB0byBhIGxlc3MtYnVz eSBBUCBvciBtYWtlIG90aGVyIGFkanVzdG1lbnRzIHRvIHRoZSBjaGFubmVsIGhhbmRsaW5nIG9m IGZyYW1lIG1hcmtlZCB3aXRoIHRoZSBoaWdoZXIgcHJpb3JpdHkgV01NIGJpdHMgKGdpdmVuIHRo ZSBwb3RlbnRpYWwgaXNzdWVzIHdpdGggY3Jvc3MtdGFsaywgc2hpZnRpbmcgQVBzIGlzIGNlcnRh aW5seSBub3QgYSBwYW5hY2VhLCBidXQgbXkgYmUgYmV0dGVyIHRoYW4gd2hhdCBhbW91bnRzIHRv IGFkbWlzc2lvbiBjb250cm9sKS4NCuKAiw0KDQoqIER5bmFtaWMgUGVyIFR5cGUgUGFja2V0IFBy aW9yaXRpc2F0aW9uIChEUFRQUCAqc2lnaCopDQpUaGUgU1BVRCB1c2UgY2FzZSBkcmFmdCBvcGVu cyB1cCBmb3IgdHViZSBwcmlvcml0aXNhdGlvbi4gSXQgaXMgcG9zc2libGUgdG8gcHJpb3JpdGlz ZSBhbW9uZyBmb3IgZXhhbXBsZSBhdWRpbywgdmlkZW8gYW5kIGRhdGEgdHViZXMgd2hlbiBtdWx0 aXBsZXhpbmcgKEJ1bmRsZSkgaXMgaW4gdXNlLiBJdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgcHJp b3JpdGlzYXRpb24gaXMgbWFkZSBkeW5hbWljLiBXaGVuIHJ1bm5pbmcgYSB2aWRlbyBjb25mZXJl bmNlIHlvdSBtaWdodCB3YW50IHRvIHByaW9yaXRpc2UgdmlkZW8gcGFja2V0cywgYnV0IHN1ZGRl bmx5IHRoZXJlIGlzIGEgbmVlZCB0byB1cGxvYWQgYSBsYXJnZSBwcmVzZW50YXRpb24gdG8gYWxs IHRoZSBwYXJ0aWNpcGFudHMuIEluIHRoYXQgY2FzZSBpdCBtaWdodCBub3QgbWFrZSBzZW5zZSBm b3IgcGFydGljaXBhbnRzIGhhdmluZyBwcmlzdGluZSAxMDgwcDYwIHZpZGVvIHdhdGNoaW5nIGVh Y2ggb3RoZXIgd2FpdGluZyBmb3IgdGhlIHNsb3cgdXBsb2FkaW5nIG9mIHRoZSBwcmVzZW50YXRp b24gdG8gZmluaXNoLg0KDQpBbmQgdGhlIHBhY2tldCB0eXBlIHByaW9yaXRpc2F0aW9uIGRvZXMg bm90IG5lY2Vzc2FyaWx5IHN0b3AgYXQgYXVkaW8gb3IgdmlkZW8gbGV2ZWwuIFZpZGVvIHBhY2tl dHMgY2FuIGhhdmUgZm9yIGV4YW1wbGUgc3BhdGlhbCBsYXllcnMgd2hlcmUgcGFja2V0cyBiZWxv bmdpbmcgdG8gYSB0ZW1wb3JhbCBsYXllciBjYW4gYmUgZGlzY2FyZGVkIGJ5IHRoZSBuZXR3b3Jr IHdpdGhvdXQgdG8gbXVjaCBpbXBhY3Qgb24gdGhlIHZpZGVvIHF1YWxpdHkuIERpc2NhcmRpbmcg YW4gSS1GcmFtZSB3b3VsZCBoYXZlIG11Y2ggbW9yZSBpbXBhY3Qgb24gdGhlIHF1YWxpdHkuDQoN Cg0K4oCLSSB0aGluayBvcmRpbmFsIHByaW9yaXR5IGFtb25nIHRoZSB0dWJlcyBjb21pbmcgZnJv bSB0aGUgc2FtZSB1c2VyIGlzIGEgYmFzZWxpbmUgdXNlIGNhc2UuICBUaGVyZSBzZWVtIHRvIGJl IHR3byBwb3NzaWJpbGl0aWVzIHRvIG1ha2luZyB0aGF0IGR5bmFtaWM6ICBtaW50IGEgbmV3IHR1 YmUgb3Igc2V0IG9mIHR1YmVzIG9uIHRoZSBzYW1lIDYtdHVwbGUg4oCLd2hlbiB0aGUgb3JkaW5h bCBwcmlvcml0eSBjaGFuZ2VzIG9yIHVwZGF0ZSB0aGUgb3JkaW5hbCBwcmlvcml0eSBvbiB0aGUg ZXhpc3RpbmcgdHViZXMuICBJIGFtIG5vdCBzdXJlIG9mIHRoZSBjb21wbGV4aXR5IHRyYWRlLW9m ZiBiZXR3ZWVuIHRob3NlIHR3byB5ZXQsIGFuZCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBmb2xrcyB0 aG91Z2h0cyBvbiB0aGF0Lg0KDQrigItyZWdhcmRzLA0KVGVk4oCLDQoNCg0KDQoNCkNvbW1lbnRz LCBmbGFtZXMgYW5kIHdoYXQgbm90IGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4NCg0KLi0uDQpQw6Vs LUVyaWsNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClNwdWQgbWFpbGluZyBsaXN0DQpTcHVkQGlldGYub3JnPG1haWx0bzpTcHVkQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQoNCg0K --_000_CE03DB3D7B45C245BCA0D24327794936414CF2MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUg bm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+LS0gUmF0ZSBBZGFwdGF0aW9uIGJhc2VkIG9uIG5ldHdvcmsgZmVlZGJhY2ssIGFuZCAo dG8gc29tZSBleHRlbnQpIEZDRlMgKHdlYWspIGFkbWlzc2lvbiBjb250cm9sOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7PC9zcGFuPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsg VGhpcyB3b3JrIGlzIFRDUCBiYXNlZCwgYnV0IHdpdGggc2ltaWxhciBnb2Fsczo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Wy4uLiBzbmlwIC4uLl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPkZvciBub3cgbXkgY29uY2x1c2lv biBpczsgdGhlcmUgaXMgaW50ZXJlc3QgaW4gc29sdmluZyBzaW1pbGFyIHByb2JsZW1zIGZvciBU Q1AsIHNvIGFkZGluZyBpdCB0byB0aGUgU1BVRCB1c2UtY2FzZSBkaXNjdXNzaW9uIG1ha2Ugc2Vu c2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7MSAtIHRoYXQgd2FzIHRoZSByZWFzb24gZm9yIHNl bmRpbmcgdGhvc2UgZHJhZnQgcG9pbnRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7 DQo8L3NwYW4+RG8gd2UgaGF2ZSBhbnkgaW5mb3JtYXRpb24gdGhhdCBuZXR3b3JrIGVsZW1lbnRz IGNhbiBoYW5kbGUgZGlmZmVyZW50IERTQ1AgdmFsdWVzIHdpdGhpbiBhIDUtdHVwbGU/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFdvcmQgb24gdGhlIHN0cmVldCBh IGZldyB5ZWFycyBiYWNrIHdhcyB0aGF0IGl0IGNvdWxkIGJlIGRpZmZpY3VsdCBmb3Igc29tZSBw bGF0Zm9ybXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGUgcHJvYmxlbXMgYXJlbuKAmXQgc28gbXVjaCBuZXR3b3JrIGVsZW1lbnRzLCBhcyB0aGV5IGFy ZSB0cmFuc3BvcnQgcHJvdG9jb2wgc2lkZSBlZmZlY3RzLiZuYnNwOyBTZWUgdGhlIERBUlQgZHJh ZnQgZm9yIG1vcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEluIG15IGhl YWQgU1BVRCB3aWxsIGltcHJvdmUgdGhlIGFib3ZlIGRyYWZ0cyBieTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IC0gUHJvdmlkZSBlbmQgdG8gZW5kIHNpZ25hbGxpbmcuJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7IChXb3VsZCBiZSBpbnRl cmVzdGluZyB0byBrbm93IHRoZSByYXRpb25hbGUgb24gd2h5IHRoZSBuZXR3b3JrcyByZW1hcmtz IHRoZSBEU0NQIHZhbHVlcyBzbyB3ZSBjYW4gYXZvaWQgdGhhdCB3aXRoIFNQVUQpLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5Mb3NpbmcgYmF0dGxlOyB2YWx1ZXMgdGhhdCBjYW7igJl0IGJlIHJld3JpdHRl biB3aWxsIGJlIGlnbm9yZWQuJm5ic3A7IElmIERTQ1AgdmFsdWVzIGFyZSB1c2VkIGZvciBRb1Ms IHRoZXnigJlyZSBwYXJ0IG9mIHRoZSBuZXR3b3Jr4oCZcyB0cmFmZmljIGVuZ2luZWVyaW5nIGFu ZCBoZW5jZSBoYXZlIHRvIGJlDQogcmV3cml0YWJsZSBieSB0aGUgbmV0d29yayBvcGVyYXRvciAo cHJpb3Igb3B0aW1pc20gdGhhdCB0aGUgdmFsdWVzIHdvdWxkIHNvbWVob3cgcGFzcyB0aHJvdWdo IGFsbCBuZXR3b3JrcyB1bmNoYW5nZWQgdy9lYWNoIG5ldHdvcmsgZG9pbmcgc29tZXRoaW5nIHJl YXNvbmFibGUgaGFzIHByb3ZlbiB0byBiZSBuYcOvdmUpOyBpZiB0aGV5IGNhbuKAmXQgYmUgcmV3 cml0dGVuLCB0aGV5IHdpbGwgKGhhdmUgdG8pIGJlIGlnbm9yZWQsIElNSE8uJm5ic3A7IFRoaXMN CiBkcmFmdCBwcm92aWRlcyBzb21lIGluZm8gYWJvdXQgYW4gYXBwcm9hY2ggd2l0aCBlbmQtdG8t ZW5kIHBvc3NpYmlsaXRpZXMgdGhhdCBpcyBsaWtlbHkgdG8gd29yayBpZiBpdCBnZXRzIGFkb3B0 ZWQgYW5kIHdpZGVseSBkZXBsb3llZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdHN2d2ctZGlmZnNlcnYtaW50ZXJjb24vIj5odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZGlmZnNlcnYtaW50ZXJjb24vPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPGJyPg0KLS1EYXZpZDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5QYWwgTWFydGluc2VuIChwYWxtYXJ0aSk8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgTWFyY2ggMTcsIDIwMTUgNTo0OCBBTTxicj4NCjxiPlRvOjwvYj4gQmxhY2ssIERhdmlk PGJyPg0KPGI+Q2M6PC9iPiBzcHVkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb U3B1ZF0gQWRkaXRpb25hbCBTUFVEIHVzZS1jYXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE2IE1hciAyMDE1LCBhdCAyMjowMiwgQmxhY2ss IERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSI+ZGF2aWQuYmxh Y2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhlcmUgYXJlIGZvdXIgcG90ZW50aWFsbHkgcmVsYXRl ZCBkcmFmdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBm b3IgcG9pbnRpbmcgdGhlbSBvdXQuIEludGVyZXN0aW5nIHJlYWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIFJh dGUgQWRhcHRhdGlvbiBiYXNlZCBvbiBuZXR3b3JrIGZlZWRiYWNrLCBhbmQgKHRvIHNvbWUgZXh0 ZW50KSBGQ0ZTICh3ZWFrKSBhZG1pc3Npb24gY29udHJvbDo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoaXMgd29yayBpcyBUQ1AgYmFzZWQsIGJ1dCB3aXRoIHNpbWlsYXIgZ29hbHM6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3ByZWNoZXIt bW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3ByZWNoZXItbW9iaWxlLXRn LWV4cG9zdXJlLXJlcS1hcmNoLzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1mbGluY2stbW9iaWxlLXRocm91Z2hwdXQtZ3VpZGFuY2UvIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mbGluY2stbW9i aWxlLXRocm91Z2hwdXQtZ3VpZGFuY2UvPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoZSBsYXR0ZXIgZHJhZnQgaXMgKElNSE8pIGJldHRlciB2aWV3ZWQgYXMgYSBw cm9vZi1vZi1jb25jZXB0IGRlbW9uc3RyYXRpb24gdGhhdCB0aGlzIGNhbiB3b3JrLCBhcyBvcHBv c2VkIHRvIGEgc3BlY2lmaWMgcHJvdG9jb2wgZGVzaWduIGZvciBob3cgdG8gZG8gaXQuJm5ic3A7 IERlc2lnbiBjb25jZXJucyBoYXZlIGJlZW4NCiByYWlzZWQgYWJvdXQgd2hhdCB3YXMgZG9uZSB0 aGVyZSAoZS5nLiwgYWdncmVzc2l2ZSB1c2Ugb2YgVENQIG9wdGlvbnMpLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3Igbm93IG15IGNvbmNsdXNpb24gaXM7IHRoZXJlIGlzIGludGVyZXN0IGluIHNvbHZpbmcgc2lt aWxhciBwcm9ibGVtcyBmb3IgVENQLCBzbyBhZGRpbmcgaXQgdG8gdGhlIFNQVUQgdXNlLWNhc2Ug ZGlzY3Vzc2lvbiBtYWtlIHNlbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLSBEeW5hbWlj IFBlciBUeXBlIFBhY2tldCBQcmlvcml0aXphdGlvbiAoRFBUUFAgKnNpZ2gqKTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+V2ViIFJUQyB3YW50cyB0byBkbyB0aGlzIGZyb20gdGhlIGFw cGxpY2F0aW9uOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcy8iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy88L3Nw YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW5kIGl0IGNhbiBiZSBkb25l LCBpZiBvbmUgaXMgY2FyZWZ1bDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAvIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAv PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+KGluDQogUkZDIEVkaXRvciBRdWV1ZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGltcGxlbWVudGVkIGEgcHJv dG90eXBlIHNldHRpbmcgZGlmZmVyZW50IERTQ1AgdmFsdWVzIG9uIGRpZmZlcmVudCB2aWRlbyBw YWNrZXRzIGEgZmV3IHllYXJzIGJhY2suIFRoZSBwbGF0Zm9ybSB3ZSBkaWQgaXQgb24gd2FzIGEg Yml0IHVuZGVycG93ZXJlZCByZWdhcmRpbmcgbWFpbiBDUFUgdnMgdmlkZW8gZW5jL2RldiBwcm9j ZXNzb3JzLiBUaGUgZXh0cmEgc2V0c29ja29wdCBjYWxsIHRvIGNoYW5nZQ0KIHRoZSBwciBwYWNr ZXQgRFNDUCB2YWx1ZSBjYXVzZWQgcHJvYmxlbXMuIFdhcyBhbHNvIHVuc3VyZSBpZiBhbnkgYnVm ZmVyaW5nIGluIHRoZSBPUyBjYXVzZSB0aGUgcmlnaHQgbWFya2luZ3MgdG8gYmUgc2V0IG9uIHRo ZSByaWdodCBwYWNrZXQuIFRoZSBzZW5kTXNnKCkgZnVuY3Rpb24gd2lsbCBwcm9iYWJseSBlbnN1 cmUgdGhhdCwgYnV0IGF0IHRoZSB0aW1lIHdlIGRpZCBub3QgcmV3cml0ZSBvdXIgc3RhY2sgdG8g c3VwcG9ydCB0aGF0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBoYXZlIGFueSBpbmZvcm1hdGlvbiB0aGF0IG5ldHdvcmsg ZWxlbWVudHMgY2FuIGhhbmRsZSBkaWZmZXJlbnQgRFNDUCB2YWx1ZXMgd2l0aGluIGEgNS10dXBs ZT8gV29yZCBvbiB0aGUgc3RyZWV0IGEgZmV3IHllYXJzIGJhY2sgd2FzIHRoYXQgaXQgY291bGQg YmUgZGlmZmljdWx0IGZvciBzb21lIHBsYXRmb3Jtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbXkgaGVhZCBTUFVEIHdpbGwgaW1wcm92 ZSB0aGUgYWJvdmUgZHJhZnRzIGJ5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFByb3ZpZGUgZW5kIHRvIGVuZCBzaWduYWxsaW5nLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7IChXb3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93IHRoZSByYXRpb25hbGUgb24gd2h5IHRo ZSBuZXR3b3JrcyByZW1hcmtzIHRoZSBEU0NQIHZhbHVlcyBzbyB3ZSBjYW4gYXZvaWQgdGhhdCB3 aXRoIFNQVUQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIEVhc2llciBmb3IgYXBwbGljYXRpb25zLiBKdXN0IG1lbWNweSgpIGEgc3B1ZCBi dWZmZXIgaW4gZnJvbnQgb2YgeW91ciBSVFAgcGFja2V0IChNYWtlIHN1cmUgdG8gc3RhcnQgd3Jp dGluZyB5b3VyIFJUUCBwYWNrZXQgYSBiaXQgaW50byB0aGUgYnVmZmVy4oCmKSwgYW5kIGZpcmUg b2ZmIHRoZSBwYWNrZXQgYXMgdXN1YWwuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGFzcGVjdCBhcyBp dCBlYXNlcyB0aGUgaW50ZWdyYXRpb24NCiB3b3JrIG9mIFNQVUQuIElmIHRoZSBhcHBsaWNhdGlv biBhbHJlYWR5IHN1cHBvcnRzIElDRSBpdCBwcm9iYWJseSBkb2VzIGRvIHNpbWlsYXIgdHJpY2tz IGJlY2F1c2Ugb2YgVFVSTi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJdCBpcyBwb3NzaWJsZSB0byBidWlsZCBhIFNQVUQtJmd0 O0RTQ1AgZ2F0ZXdheS4gVGhpcyBpcyBuaWNlIGFzIGN1c3RvbWVycyBjYW4gcGxhY2UgdGhhdCBn YXRld2F5IGF0IHRoZSBlZGdlIGFuZCBzdGlsbCBoYXZlIHRoZSBvbGQgY2FyZWZ1bGx5IERTQ1Ag Y3JhZnRlZCBuZXR3b3JrIHByb3ZpZGUgdmFsdWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li0uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qw6VsLUVyaWs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhhbmtzLDxicj4N Ci0tRGF2aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNwdWQNCiBbPGEgaHJlZj0ibWFpbHRvOnNwdWQt Ym91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnNwdWQt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5 LCBNYXJjaCAxNiwgMjAxNSAxMjo1NiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGFsIE1hcnRpbnNlbiAocGFsbWFydGkp PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3B1ZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+c3B1ZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbU3B1ZF0g QWRkaXRpb25hbCBTUFVEIHVzZS1jYXNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgUMOlbC1FcmlrLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRoYW5rcyBmb3IgeW91ciBtZXNzYWdlOyBzb21lIGNvbW1lbnRzIGluLWxp bmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNDow NyBBTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpICZsdDs8YSBocmVmPSJtYWlsdG86cGFsbWFy dGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ cGFsbWFydGlAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgaGF2ZSBhIGZldyBhZGRpdGlvbmFsIFNQVUQgdXNlLWNhc2VzIEkgd2FudCB0byBicmluZyB0 byB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4gU29tZSBvZiB0aGVtIGhhdmUgYWxyZWFkeSBiZWVu IHNvbHZlZCBieSB1c2luZyBTVFVOIGFzIGEgc2lnbmFsbGluZyBwcm90b2NvbCAoPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIu dHh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDIudHh0PC9zcGFu PjwvYT4pLg0KIEkgdGhpbmsgU1BVRCBpcyBhIG1vcmUgZWZmaWNpZW50IGNhcnJpZXIgb2YgdGhl IGJpdHMgbmVlZGVkIHRvIHNvbHZlIHNvbWUgb2YgdGhlIHVzZS1jYXNlcy4gQnV0IGZvciBub3cg dGhleSBhcmUganVzdCB1c2UtY2FzZXMsIGFuZCBkaXNjdXNzaW9ucyBvbiBob3cgdG8gc29sdmUg dGhlbSBzaG91bGQgcHJvYmFibHkgYmUgZGVmZXJyZWQgdG8gYSBsYXRlciBzdGFnZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBSYXRlIEFkYXB0aW9uIFdpdGggQ29uZmlkZW5jZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VG9kYXlzIGRlbGF5IHNlbnNpbmcgcmF0ZSBhZGFwdGlvbiBtZWNoYW5pc21zIHNlZW1z IHRvIGJlIHdvcmtpbmcgdmVyeSB3ZWxsIGFuZCBjYW4gcG90ZW50aWFsbHkgcmVhY3Qgd2l0aGlu IGhhbGYgYSBSVFQgKElzIFRULCBUcmlwIFRpbWUsIG1vcmUgYWNjdXJhdGUgb3IgaW4gdXNlIGFz IGEgdGVybT8pLiBIYXZpbmcgZXhwbGljaXQgbmV0d29yayBmZWVkYmFjayBzaWduYWxsZWQgYmFj ayB0byBlbmRwb2ludA0KIGVuYWJsZWQgZW5kcG9pbnRzIHRvIHBpY2sgYSBtb3JlIHJlYXNvbmFi bGUgc3RhcnRpbmcgdmFsdWUgd2hlbiBzZW5kaW5nIG1lZGlhLiBFeHBsaWNpdCBzaWduYWxsaW5n IGR1cmluZyB0aGUgY2FsbCBlbmFibGVzIHRoZSBuZXR3b3JrIGFzIHRvIHNpZ25hbCBpbmZvcm1h dGlvbiBiYWNrIHRvIHRoZSBlbmRwb2ludCBiZWZvcmUgdGhlIHByb2JsZW1zIG9jY3VyIChFQ04p LiBVcC9kb3duIHNwZWVkaW5nIGNvdWxkIHBvdGVudGlhbGx5IGJlIGRvbmUNCiBpbiBsYXJnZXIg Y2h1bmtzIHdpdGggY29uZmlkZW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KiBGaXJzdCBDb21lLCBGaXJzdCBTZXJ2ZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gV2lGaSB3ZSBoYXZl IHNvbWUgbGFiIHRlc3RzIHRoYXQgc2hvdyB3aGVuIHlvdSBoaXQgYSBsaW1pdCB5b3UgaGl0IGl0 IGhhcmQgYW5kIGV2ZXJ5Ym9keSBvbiB0aGF0IGxpbmsgc3VmZmVycy4gSWYgOSBwZW9wbGUgZW5q b3kgdGhlaXIgdmlkZW8gY29udmVyc2F0aW9ucyBnb2luZyB0aHJvdWdoIHRoZSBzYW1lIFdpRmkg QVAsIGl0IGlzIGFubm95aW5nIGlmIGEgMTB0aCBjYWxsIGlzIGFkZGVkIGNhdXNpbmcNCiBldmVy eWJvZHkgdG8gZ2V0IGJhZCB2aWRlby4gQSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0byBsZXQgdGhl IG5ldHdvcmsgc2lnbmFsIGJhY2sgdG8gdGhlIDEwdGggcGFydGljaXBhbnRzIHRyeWluZyB0byBz ZW5kIHZpZGVvIHRoYXQgYmFuZHdpZHRoIGlzIG5vdCBhdmFpbGFibGU7IOKAnEkgd2lsbCBwdXQg eW91IGluIHdvcnNlIHRoYW4gYmVzdCBlZmZvcnQgcXVldWUgaWYgeW91IHRyeSB0byBzZW5kIGF0 IHRoYXQgcmF0ZeKAnS4gSWYgYmFuZHdpZHRoDQogYmVjb21lIGF2YWlsYWJsZSB0aGUgbmV0d29y ayB3aWxsIG5vdGlmeSB0aGUgdXNlci4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IFJTVlAgYW5kIHJl c291cmNlIGFsbG9jYXRpb24sIGp1c3QgaGludHMgZnJvbSB0aGUgbmV0d29yayB0aGF0IGlmIHlv dSB0cnksIHlvdSB3aWxsIHN1ZmZlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igIs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij7igItXaGVuIHlvdSBzYXkgJnF1b3Q7dGhlIG5ldHdvcmsmcXVvdDsgaGVyZSwgdGhpcyBz ZWVtcyB0byBtZSB0aGUgZmlyc3QgaG9wLUFQLiZuYnNwOyBGb3IgY2FzZXMgd2hlcmUgdGhlIHJh ZGlvIHJlc291cmNlcyBhcmUgYXQgaXNzdWUsIGl0IHNlZW1zIGxpa2VseSB0aGF0IHlvdSBtaWdo dCB3YW50IHRvDQogY29vcmRpbmF0ZSB0aGlzIHdpdGggdGhlIG90aGVyIDgwMi4xMSBmYWNpbGl0 aWVzLCBzbyBJJ20gbm90IHN1cmUgdGhhdCB0aGlzIHRoZSByaWdodCBsYXllciB0byBkbyB0aGlz LiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBtdWx0aS1BUCBkZXBsb3ltZW50cyBtaWdodCByZXF1ZXN0 IHRoZSBzdGF0aW9uIHJlLWFzc29jaWF0ZSB0byBhIGxlc3MtYnVzeSBBUCBvciBtYWtlIG90aGVy IGFkanVzdG1lbnRzIHRvIHRoZSBjaGFubmVsIGhhbmRsaW5nIG9mIGZyYW1lDQogbWFya2VkIHdp dGggdGhlIGhpZ2hlciBwcmlvcml0eSBXTU0gYml0cyAoZ2l2ZW4gdGhlIHBvdGVudGlhbCBpc3N1 ZXMgd2l0aCBjcm9zcy10YWxrLCBzaGlmdGluZyBBUHMgaXMgY2VydGFpbmx5IG5vdCBhIHBhbmFj ZWEsIGJ1dCBteSBiZSBiZXR0ZXIgdGhhbiB3aGF0IGFtb3VudHMgdG8gYWRtaXNzaW9uIGNvbnRy b2wpLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igIs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogRHluYW1pYyBQZXIgVHlw ZSBQYWNrZXQgUHJpb3JpdGlzYXRpb24gKERQVFBQICpzaWdoKik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBTUFVE IHVzZSBjYXNlIGRyYWZ0IG9wZW5zIHVwIGZvciB0dWJlIHByaW9yaXRpc2F0aW9uLiBJdCBpcyBw b3NzaWJsZSB0byBwcmlvcml0aXNlIGFtb25nIGZvciBleGFtcGxlIGF1ZGlvLCB2aWRlbyBhbmQg ZGF0YSB0dWJlcyB3aGVuIG11bHRpcGxleGluZyAoQnVuZGxlKSBpcyBpbiB1c2UuIEl0IGlzIGlt cG9ydGFudCB0aGF0IHRoZSBwcmlvcml0aXNhdGlvbiBpcyBtYWRlIGR5bmFtaWMuIFdoZW4gcnVu bmluZw0KIGEgdmlkZW8gY29uZmVyZW5jZSB5b3UgbWlnaHQgd2FudCB0byBwcmlvcml0aXNlIHZp ZGVvIHBhY2tldHMsIGJ1dCBzdWRkZW5seSB0aGVyZSBpcyBhIG5lZWQgdG8gdXBsb2FkIGEgbGFy Z2UgcHJlc2VudGF0aW9uIHRvIGFsbCB0aGUgcGFydGljaXBhbnRzLiBJbiB0aGF0IGNhc2UgaXQg bWlnaHQgbm90IG1ha2Ugc2Vuc2UgZm9yIHBhcnRpY2lwYW50cyBoYXZpbmcgcHJpc3RpbmUgMTA4 MHA2MCB2aWRlbyB3YXRjaGluZyBlYWNoIG90aGVyIHdhaXRpbmcNCiBmb3IgdGhlIHNsb3cgdXBs b2FkaW5nIG9mIHRoZSBwcmVzZW50YXRpb24gdG8gZmluaXNoLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbmQgdGhlIHBhY2tldCB0eXBlIHByaW9yaXRpc2F0aW9uIGRvZXMgbm90IG5lY2Vz c2FyaWx5IHN0b3AgYXQgYXVkaW8gb3IgdmlkZW8gbGV2ZWwuIFZpZGVvIHBhY2tldHMgY2FuIGhh dmUgZm9yIGV4YW1wbGUgc3BhdGlhbCBsYXllcnMgd2hlcmUgcGFja2V0cyBiZWxvbmdpbmcgdG8g YSB0ZW1wb3JhbCBsYXllciBjYW4gYmUgZGlzY2FyZGVkIGJ5IHRoZSBuZXR3b3JrIHdpdGhvdXQg dG8gbXVjaCBpbXBhY3Qgb24NCiB0aGUgdmlkZW8gcXVhbGl0eS4gRGlzY2FyZGluZyBhbiBJLUZy YW1lIHdvdWxkIGhhdmUgbXVjaCBtb3JlIGltcGFjdCBvbiB0aGUgcXVhbGl0eS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuKAi0kgdGhpbmsgb3JkaW5hbCBwcmlvcml0eSBhbW9uZyB0aGUgdHViZXMgY29t aW5nIGZyb20gdGhlIHNhbWUgdXNlciBpcyBhIGJhc2VsaW5lIHVzZSBjYXNlLiZuYnNwOyBUaGVy ZSBzZWVtIHRvIGJlIHR3byBwb3NzaWJpbGl0aWVzIHRvIG1ha2luZyB0aGF0IGR5bmFtaWM6Jm5i c3A7IG1pbnQgYSBuZXcgdHViZSBvciBzZXQgb2YgdHViZXMgb24NCiB0aGUgc2FtZSA2LXR1cGxl IOKAi3doZW4gdGhlIG9yZGluYWwgcHJpb3JpdHkgY2hhbmdlcyBvciB1cGRhdGUgdGhlIG9yZGlu YWwgcHJpb3JpdHkgb24gdGhlIGV4aXN0aW5nIHR1YmVzLiZuYnNwOyBJIGFtIG5vdCBzdXJlIG9m IHRoZSBjb21wbGV4aXR5IHRyYWRlLW9mZiBiZXR3ZWVuIHRob3NlIHR3byB5ZXQsIGFuZCBJJ2Qg YmUgaW50ZXJlc3RlZCBpbiBmb2xrcyB0aG91Z2h0cyBvbiB0aGF0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLcmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UZWTigIs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzLCBmbGFtZXMgYW5kIHdoYXQgbm90 IGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Li0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Qw6VsLUVyaWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpTcHVkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTcHVkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+U3B1ZEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHVkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D24327794936414CF2MX104CL02corpemcc_-- From nobody Wed Mar 18 09:27:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691EC1A6F3C for ; Wed, 18 Mar 2015 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 SOfLWvl0e1uX for ; Wed, 18 Mar 2015 09:27:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1DF1A6F39 for ; Wed, 18 Mar 2015 09:27:06 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-50-5509a75803ef Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.83.28347.857A9055; Wed, 18 Mar 2015 17:27:04 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Wed, 18 Mar 2015 17:27:03 +0100 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: [Spud] Draft agenda for BoF Thread-Index: AQHQWoemuNVPhbbo7E6Xz7UuUgsWOJ0UVe2AgA4hOLA= Date: Wed, 18 Mar 2015 16:27:03 +0000 Message-ID: References: <54FDD743.7070204@cisco.com> In-Reply-To: <54FDD743.7070204@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23CBC4A1ESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RjdiOWeowa5VihZf/3WwWGxYPYXF YtGFp4wOzB5Tfm9k9Viy5CeTx7EPX9kCmKO4bFJSczLLUov07RK4Mh7/fsVU0PWYseLc6ROM DYw9dxm7GDk5JARMJLoO3IOyxSQu3FvP1sXIxSEkcIRRovHVRiYIZwmjxP2L59lAqtgELCQa Vm4Gs0UElCXW3lnEDmIzC2RKPNhxmbWLkYNDWEBDom0fP4gpIqApseGjPoRpJTHxSi5IMYuA qsS7W9dYQWxeAV+J1qmXmEFsIYEEiTlX+1hAbE6gzsmntzKB2IxAp30/tYYJYpG4xK0n85kg ThaQWLLnPDOELSrx8vE/VghbUaL9aQMjRH2+xI5Fb1kgdglKnJz5hGUCo+gsJKNmISmbhaRs FtDVzEBnrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmp JZsYgRF4cMtvgx2ML587HmIU4GBU4uE1eMURKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxvb5LxIM9q5f7B16znDRy/XbW19bnpSL0fxyWCTz9ve2uIDZ UxfIeMqEeqYeKNyeUcF0mzfueOg+B8+rTG1rPFm2m7kLMumuCawP57y9Nf6oVWZ/eVzkSi8m y4smZ5WKeTtneN+vmr/nwbx1xQvOFv+d6R93xfZw2zqNBz0brjZc5jur6h70TomlOCPRUIu5 qDgRAPxS+jyhAgAA Archived-At: Cc: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Eliot Lear Subject: Re: [Spud] Draft agenda for BoF X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:27:10 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23CBC4A1ESESSMB303erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldpdGggdGhlIGN1cnJlbnQgYXNzdW1wdGlvbnMgZm9yIFNQVUQgSSBpdCBpcyBoYXJk IGZvciBtZSB0byBmaW5kIHN1ZmZpY2llbnQgIGRlcGxveW1lbnQgaW5jZW50aXZlcyBmb3IgdGhl IG5ldHdvcmsuIEkgd2lsbCBtb3N0IGxpa2VseSBjb21tZW50IG9uIHRoaXMgYXQgdGhlIEJvRi4g SXQgZG9lcyBub3QgbG9vayBhIHNob3dzdG9wcGVyIGZvciBtZSwgdGhvdWdoIGl0IHdvdWxkIGJl IGdvb2QgdG8gZGlzY3VzcyB0aGUgYXNzdW1wdGlvbnMgZnVydGhlciBvciBmaW5kIGluY2VudGl2 ZXMgZm9yIHRoZSBuZXR3b3JrIHdpdGggdGhlIGN1cnJlbnQgYXNzdW1wdGlvbnMuDQoNCldlIHdy b3RlIGEgcGFydGx5IHJlbGF0ZWQgZHJhZnQsIHdoaWNoIEkgc2VudCB0byB0aGUgdHN2d2cgbGlz dC4gU29tZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9mIGl0IGNvdWxkIHJlc3VsdCBpbiB1c2UgY2Fz ZXMgZm9yIFNQVUQgYW5kIG1heWJlIG1vdGl2YXRpb24gZm9yIG5ldyBpbmZvcm1hdGlvbiBlbGVt ZW50cy4NCg0KQ2hlZXJzLA0KU3ppbHZlc3p0ZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KDQpGcm9tOiBTemlsdmVzenRlciBOYWRhcw0KDQpTZW50OiBXZWRuZXNkYXksIE1hcmNo IDExLCAyMDE1IDExOjI4DQoNClRvOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5v cmc+DQoNCkNjOiBBdHRpbGEgTWlow6FseQ0KDQpTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24tMDAu dHh0DQoNCg0KDQpIaSwNCg0KDQoNCldlIGNyZWF0ZWQgYSBkcmFmdCBhYm91dCBvdXIgdmlzaW9u IGhvdyB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGZyYW1ld29yayBzaG91bGQgbG9vayBpbiB0aGUg ZnV0dXJlLCB3aGVuIHVzZXIgcGxhbmUgaW1wbGVtZW50YXRpb25zIGFsbG93IG11Y2ggbW9yZSB2 YXJpZXR5IGFuZCBmYXN0ZXIgZXZvbHV0aW9uLiBUaGlzIHJlbGF0ZXMgdG8gc2V2ZXJhbCBvbmdv aW5nIGlldGYgYWN0aXZpdGllcy4gV2Ugd291bGQgYmUgaGFwcHkgdG8gcHJlc2VudCBpdCwgSSB0 aGluayB0c3Z3ZyBpcyB0aGUgcmlnaHQgcGxhY2UgZm9yIGl0LiBBbHNvIGRpc2N1c3Npb24gYW5k IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQoNCg0KQ2hlZXJzLA0KDQpTemlsdmVzenRlciBhbmQg QXR0aWxhDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQoNClNlbnQ6IE1vbmRheSwgTWFyY2ggMDksIDIw MTUgMTU6NTQNCg0KVG86IFN6aWx2ZXN6dGVyIE5hZGFzOyBBdHRpbGEgTWlow6FseTsgQXR0aWxh IE1paMOhbHk7IFN6aWx2ZXN6dGVyIE5hZGFzDQoNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbWloYWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLTAwLnR4 dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taWhhbHktZW5hYmxlcnMt Zm9yLXRscC1ldm9sdXRpb24tMDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgQXR0aWxhIE1paGFseSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Cg0KDQpOYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LW1paGFseS1lbmFibGVycy1mb3ItdGxw LWV2b2x1dGlvbg0KDQpSZXZpc2lvbjogICAgICAgICAgICAgIDAwDQoNClRpdGxlOiAgICAgICAg ICAgICAgICAgICAgICBFbmFibGVycyBmb3IgVHJhbnNwb3J0IExheWVyIFByb3RvY29sIEV2b2x1 dGlvbg0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgIDIwMTUtMDMtMDkNCg0KR3JvdXA6 ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAg ICAgICAgICAgICAxNg0KDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbWloYWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLTAwLnR4 dA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWloYWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLw0KDQpIdG1saXplZDogICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWloYWx5LWVuYWJsZXJzLWZvci10bHAt ZXZvbHV0aW9uLTAwDQoNCg0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIEluIHRoaXMgZG9jdW1lbnQg d2UgY29sbGVjdGVkIHJlcXVpcmVtZW50cyBmb3IgVExQIGV2b2x1dGlvbi4gVGhlc2UNCg0KICAg cmVxdWlyZW1lbnRzIGFyZSB0aGUgY29uc2VxdWVuY2Ugb2YgcmVtb3Zpbmcgb2JzdGFjbGVzIG9m IFRMUA0KDQogICBldm9sdXRpb24uIFRoaXMgcmVzdWx0cyBpbiBhIGhpZ2hlciB2YXJpZXR5IG9m IGV4cGVjdGVkIFRMUA0KDQogICBpbXBsZW1lbnRhdGlvbnMgYW5kIGxvd2VyIHRydXN0IGxldmVs IGluIHRoZXNlLiBDb25maWRlbnRpYWxpdHkgb2YNCg0KICAgY29tbXVuaWNhdGlvbiBhbmQgc2Vj dXJpdHkgaXMgbW9yZSBhbmQgbW9yZSBpbXBvcnRhbnQuIE1pZGRsZWJveGVzDQoNCiAgIHdoaWNo IHRvZGF5IGFyZSBvbmUgb2YgdGhlIG9ic3RhY2xlcyBvZiB0aGUgZXZvbHV0aW9uIHNoYWxsIGJl IHRha2VuDQoNCiAgIGludG8gYWNjb3VudCBhbmQgaW5jZW50aXZpemVkIHRvIGNvb3BlcmF0ZSBp biB0aGUgZnV0dXJlIGxhbmRzY2FwZS4NCg0KICAgUmVzdWx0aW5nIGZyb20gdGhlIHJlcXVpcmVt ZW50cyB3ZSBwcm9wb3NlIGFyZWFzIGZvciBmdXJ0aGVyDQoNCiAgIGludmVzdGlnYXRpb24uDQoN Cg0KDQoNCkZyb206IFNwdWQgW21haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBFbGlvdCBMZWFyDQpTZW50OiBNb25kYXksIE1hcmNoIDA5LCAyMDE1IDE4OjI0DQpUbzog TWlyamEgS8O8aGxld2luZDsgc3B1ZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTcHVkXSBEcmFm dCBhZ2VuZGEgZm9yIEJvRg0KDQpIaSBldmVyeW9uZSwNCg0KUGxlYXNlIG5vdyB0YWtlIGEgbG9v ayBhdCB0aGUgYWdlbmRhLiAgRHVyaW5nIHRoZSBzZXNzaW9uIHdlIGFyZSBwbGFubmluZyB0byBh c2sgYSBmZXcgcXVlc3Rpb25zLiAgVGhlIGNoYWlycyB0aGluayB0aGF0IHRoZSBmb2xsb3dpbmcg cXVlc3Rpb25zIGFyZSBnb29kIHN0YXJ0aW5nIHBvaW50czoNCg0KICAqICAgV2hhdCBhcmUgdGhl IGNhcGFiaWxpdGllcyB0aGF0IHdlIG5lZWQgYW5kIGRvbuKAmXQgaGF2ZSB0b2RheTsgYW5kIHdo eSBkbyB3ZSBuZWVkIHRoZW0/DQogICogICBBcmUgdXNlIGNhc2VzIHdlbGwgdW5kZXJzdG9vZCBh bmQgcmVsZXZhbnQ/DQogICogICBBcmUgdGhlcmUgc3VmZmljaWVudCBkZXBsb3ltZW50IGluY2Vu dGl2ZXMgb24gZW5kcG9pbnRzPyBJbiB0aGUgbmV0d29yaz8NCiAgKiAgIFNob3VsZCB0aGlzIGJl IGEgVURQLWJhc2VkIGFwcHJvYWNoPw0KICAqICAgV2hhdCBhcmUgdGhlIG5leHQgc3RlcHM/DQoN CldoYXQgb3RoZXIgcXVlc3Rpb25zIGFyZSBpbXBvcnRhbnQgdG8gdGhpbmsgYWJvdXQgZHVyaW5n IHRoZSBCb0YgYW5kIGFkZHJlc3MgYXQgdGhlIGVuZCBvZiB0aGUgQm9GPw0KDQpFbGlvdA0KDQoN Ck9uIDMvOS8xNSA1OjM4IFBNLCBNaXJqYSBLw7xobGV3aW5kIHdyb3RlOg0KDQpIaSBhbGwsDQoN Cg0KDQp3ZSB1cGxvYWRlZCBhIGRyYWZ0IGFnZW5kYSBmb3IgdGhlIEJvRjoNCg0KDQoNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvYWdlbmRhL2FnZW5kYS05Mi1zcHVkDQoNCg0K DQpFbGlvdCAmIE1pcmphDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpTcHVkIG1haWxpbmcgbGlzdA0KDQpTcHVkQGlldGYub3JnPG1haWx0 bzpTcHVkQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwdWQNCg0KDQoNCg0KDQo= --_000_EA4C43BE752A194597B002779DF69BAE23CBC4A1ESESSMB303erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMDBCMDUwO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxODIzOTYyMzEwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDc2MDI4Mzg2O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkhpLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+V2l0 aCB0aGUgY3VycmVudCBhc3N1bXB0aW9ucyBmb3IgU1BVRCBJIGl0IGlzIGhhcmQgZm9yIG1lIHRv IGZpbmQgc3VmZmljaWVudCAmbmJzcDtkZXBsb3ltZW50IGluY2VudGl2ZXMgZm9yIHRoZSBuZXR3 b3JrLiBJIHdpbGwgbW9zdCBsaWtlbHkgY29tbWVudCBvbiB0aGlzIGF0IHRoZQ0KIEJvRi4gSXQg ZG9lcyBub3QgbG9vayBhIHNob3dzdG9wcGVyIGZvciBtZSwgdGhvdWdoIGl0IHdvdWxkIGJlIGdv b2QgdG8gZGlzY3VzcyB0aGUgYXNzdW1wdGlvbnMgZnVydGhlciBvciBmaW5kIGluY2VudGl2ZXMg Zm9yIHRoZSBuZXR3b3JrIHdpdGggdGhlIGN1cnJlbnQgYXNzdW1wdGlvbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDBCMDUwIj5X ZSB3cm90ZSBhIHBhcnRseSByZWxhdGVkIGRyYWZ0LCB3aGljaCBJIHNlbnQgdG8gdGhlIHRzdndn IGxpc3QuIFNvbWUgb2YgdGhlIHJlcXVpcmVtZW50cyBvZiBpdCBjb3VsZCByZXN1bHQgaW4gdXNl IGNhc2VzIGZvciBTUFVEIGFuZCBtYXliZSBtb3RpdmF0aW9uIGZvcg0KIG5ldyBpbmZvcm1hdGlv biBlbGVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMEIwNTAiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1 MCI+U3ppbHZlc3p0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkZyb206IFN6 aWx2ZXN6dGVyIE5hZGFzIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMSwgMjAx NSAxMToyODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+VG86IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+DQp0 c3Z3Z0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNjOiBBdHRpbGEgTWlow6FseTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ U3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWloYWx5LWVu YWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+V2UgY3JlYXRlZCBhIGRyYWZ0IGFib3V0 IG91ciB2aXNpb24gaG93IHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgZnJhbWV3b3JrIHNob3VsZCBs b29rIGluIHRoZSBmdXR1cmUsIHdoZW4gdXNlciBwbGFuZSBpbXBsZW1lbnRhdGlvbnMgYWxsb3cg bXVjaCBtb3JlIHZhcmlldHkgYW5kIGZhc3RlciBldm9sdXRpb24uIFRoaXMgcmVsYXRlcyB0byBz ZXZlcmFsIG9uZ29pbmcNCiBpZXRmIGFjdGl2aXRpZXMuIFdlIHdvdWxkIGJlIGhhcHB5IHRvIHBy ZXNlbnQgaXQsIEkgdGhpbmsgdHN2d2cgaXMgdGhlIHJpZ2h0IHBsYWNlIGZvciBpdC4gQWxzbyBk aXNjdXNzaW9uIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U3ppbHZlc3p0ZXIgYW5kIEF0dGlsYTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RnJv bTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2Vu dDogTW9uZGF5LCBNYXJjaCAwOSwgMjAxNSAxNTo1NDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG86IFN6aWx2ZXN6dGVy IE5hZGFzOyBBdHRpbGEgTWlow6FseTsgQXR0aWxhIE1paMOhbHk7IFN6aWx2ZXN6dGVyIE5hZGFz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1p aGFseS1lbmFibGVycy1mb3ItdGxwLWV2b2x1dGlvbi0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlo YWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+aGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBdHRpbGEgTWloYWx5IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TmFtZTombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtbWloYWx5LWVuYWJs ZXJzLWZvci10bHAtZXZvbHV0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFbmFibGVycyBmb3IgVHJhbnNw b3J0IExheWVyIFByb3RvY29sIEV2b2x1dGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RG9jdW1lbnQgZGF0ZTombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNS0wMy0wOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+R3JvdXA6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlz c2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDE2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1paGFseS1lbmFibGVycy1mb3It dGxwLWV2b2x1dGlvbi0wMC50eHQiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbWloYWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLTAwLnR4dDwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlo YWx5LWVuYWJsZXJzLWZvci10bHAtZXZvbHV0aW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1taWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24vPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1paGFseS1lbmFibGVycy1m b3ItdGxwLWV2b2x1dGlvbi0wMCI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t aWhhbHktZW5hYmxlcnMtZm9yLXRscC1ldm9sdXRpb24tMDA8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJz cDsgSW4gdGhpcyBkb2N1bWVudCB3ZSBjb2xsZWN0ZWQgcmVxdWlyZW1lbnRzIGZvciBUTFAgZXZv bHV0aW9uLiBUaGVzZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVtZW50cyBhcmUgdGhl IGNvbnNlcXVlbmNlIG9mIHJlbW92aW5nIG9ic3RhY2xlcyBvZiBUTFA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OyZuYnNwOyBldm9sdXRpb24uIFRoaXMgcmVzdWx0cyBpbiBhIGhpZ2hlciB2YXJpZXR5IG9mIGV4 cGVjdGVkIFRMUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9ucyBhbmQgbG93 ZXIgdHJ1c3QgbGV2ZWwgaW4gdGhlc2UuIENvbmZpZGVudGlhbGl0eSBvZjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7Jm5ic3A7IGNvbW11bmljYXRpb24gYW5kIHNlY3VyaXR5IGlzIG1vcmUgYW5kIG1vcmUgaW1w b3J0YW50LiBNaWRkbGVib3hlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IHdoaWNoIHRvZGF5IGFy ZSBvbmUgb2YgdGhlIG9ic3RhY2xlcyBvZiB0aGUgZXZvbHV0aW9uIHNoYWxsIGJlIHRha2VuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDsmbmJzcDsgaW50byBhY2NvdW50IGFuZCBpbmNlbnRpdml6ZWQgdG8gY29v cGVyYXRlIGluIHRoZSBmdXR1cmUgbGFuZHNjYXBlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IFJl c3VsdGluZyBmcm9tIHRoZSByZXF1aXJlbWVudHMgd2UgcHJvcG9zZSBhcmVhcyBmb3IgZnVydGhl cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IGludmVzdGlnYXRpb24uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw QjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMEIwNTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwQjA1 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RWxpb3QgTGVhcjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE1hcmNoIDA5LCAyMDE1IDE4OjI0PGJyPg0KPGI+VG86PC9iPiBNaXJqYSBLw7xobGV3 aW5kOyBzcHVkQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3B1ZF0gRHJhZnQg YWdlbmRhIGZvciBCb0Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIGV2ZXJ5b25lLDxicj4NCjxicj4N ClBsZWFzZSBub3cgdGFrZSBhIGxvb2sgYXQgdGhlIGFnZW5kYS4mbmJzcDsgRHVyaW5nIHRoZSBz ZXNzaW9uIHdlIGFyZSBwbGFubmluZyB0byBhc2sgYSBmZXcgcXVlc3Rpb25zLiZuYnNwOyBUaGUg Y2hhaXJzIHRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgYXJlIGdvb2Qgc3RhcnRp bmcgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpXaGF0IGFyZSB0aGUgY2FwYWJp bGl0aWVzIHRoYXQgd2UgbmVlZCBhbmQgZG9u4oCZdCBoYXZlIHRvZGF5OyBhbmQgd2h5IGRvIHdl IG5lZWQgdGhlbT88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQpBcmUgdXNlIGNhc2VzIHdlbGwgdW5kZXJzdG9vZCBhbmQgcmVs ZXZhbnQ/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KQXJlIHRoZXJlIHN1ZmZpY2llbnQgZGVwbG95bWVudCBpbmNlbnRpdmVz IG9uIGVuZHBvaW50cz8gSW4gdGhlIG5ldHdvcms/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KU2hvdWxkIHRoaXMgYmUgYSBV RFAtYmFzZWQgYXBwcm9hY2g/PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KV2hhdCBhcmUgdGhlIG5leHQgc3RlcHM/PG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCldoYXQgb3RoZXIgcXVlc3Rpb25zIGFyZSBpbXBvcnRhbnQgdG8gdGhp bmsgYWJvdXQgZHVyaW5nIHRoZSBCb0YgYW5kIGFkZHJlc3MgYXQgdGhlIGVuZCBvZiB0aGUgQm9G Pzxicj4NCjxicj4NCkVsaW90PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMy85LzE1IDU6MzggUE0sIE1pcmphIEvDvGhsZXdp bmQgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaSBhbGwsPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+d2UgdXBsb2FkZWQg YSBkcmFmdCBhZ2VuZGEgZm9yIHRoZSBCb0Y6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85Mi9hZ2VuZGEvYWdlbmRhLTkyLXNwdWQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTIvYWdlbmRhL2FnZW5kYS05Mi1zcHVkPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkVsaW90ICZhbXA7IE1pcmphPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5TcHVkIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h aWx0bzpTcHVkQGlldGYub3JnIj5TcHVkQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3B1ZCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EA4C43BE752A194597B002779DF69BAE23CBC4A1ESESSMB303erics_-- From nobody Wed Mar 18 09:43:02 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F401A6F17 for ; Wed, 18 Mar 2015 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 TAtaCihEBSqt for ; Wed, 18 Mar 2015 09:42:59 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 B980A1A1BF5 for ; Wed, 18 Mar 2015 09:42:59 -0700 (PDT) Received: by igbue6 with SMTP id ue6so76678428igb.1 for ; Wed, 18 Mar 2015 09:42:59 -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:content-type; bh=gFUMWCwYMoV0ZAdpYk1YpovBZyvI2m1zM4oUL35Ki1w=; b=sE0IxWMWnuD0jxCxzU2T12wWiVwFuuTDghghmTl3EU8WO6HCAXXjJe2JYMi6S5qiW4 KN3tfw9G1uFsE1XOmO3Fts/RuROLzLtVXL1ah+EUfYzwlgxn7OFKKqHDBCX1Wy1U3jLi 1I0cy386Rv0PB8ZSdZjMZ59UU4XyjiTqeIy3vzHe3T7okAaAi/746ooYU9lPmYc4yzzQ 4Cc3eDCY5ZJ8V2QCHlgnQFIUNooeCNIuvV9rPN560XXOMIs+PVh96y4aIgLp+Nvetz91 zenLt+PLTwcThA1nf1CqhAEhLRja6RAYxpTrPdzAIQE0xxgOF+z6o2HjE27muQKdNtnW kCog== MIME-Version: 1.0 X-Received: by 10.107.149.210 with SMTP id x201mr35428783iod.33.1426696979181; Wed, 18 Mar 2015 09:42:59 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Wed, 18 Mar 2015 09:42:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 12:42:59 -0400 Message-ID: From: Aaron Falk To: "Black, David" Content-Type: multipart/alternative; boundary=001a1140fe66a5769d051192c629 Archived-At: Cc: Ted Hardie , "Pal Martinsen \(palmarti\)" , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:43:01 -0000 --001a1140fe66a5769d051192c629 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 5:02 PM, Black, David wrote: > Here are four potentially related drafts: > > > > -- Rate Adaptation based on network feedback, and (to some extent) FCFS > (weak) admission control: > > > > This work is TCP based, but with similar goals: > > > > > https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/ > > https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/ > > > > The latter draft is (IMHO) better viewed as a proof-of-concept > demonstration that this can work, as opposed to a specific protocol design > for how to do it. Design concerns have been raised about what was done > there (e.g., aggressive use of TCP options). > Hi David- Are the congestion control concerns being discussed within a working group? --aaron --001a1140fe66a5769d051192c629 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2015 at 5:02 PM, Black, David <david.black@emc.com> wrote:

Here are four potentially related drafts:

=C2=A0

-- Rate Adaptation based on network feedback, = and (to some extent) FCFS (weak) admission control:

=C2=A0

This work is TCP based, but with similar goals= :

=C2=A0

https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-expo= sure-req-arch/

https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput= -guidance/

=C2=A0

The latter draft is (IMHO) better viewed as a = proof-of-concept demonstration that this can work, as opposed to a specific= protocol design for how to do it.=C2=A0 Design concerns have been raised about what was done there (e.g., aggressive use of TCP op= tions).


Hi David-

Are the congestion control concerns being discussed = within a working group?=C2=A0

--aaron
<= /div>
--001a1140fe66a5769d051192c629-- From nobody Wed Mar 18 10:13:50 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E381A8771 for ; Wed, 18 Mar 2015 10:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IMMavV-Zlty6 for ; Wed, 18 Mar 2015 10:13:47 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB641A8769 for ; Wed, 18 Mar 2015 10:13:47 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id BDC3B1B00510; Wed, 18 Mar 2015 17:14:00 +0000 (GMT) Received: from 139.133.204.3 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 18 Mar 2015 17:13:17 -0000 Message-ID: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> In-Reply-To: References: Date: Wed, 18 Mar 2015 17:13:17 -0000 From: gorry@erg.abdn.ac.uk To: "Aaron Falk" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 17:13:49 -0000 David & I approved the talk as a presentation of current research. My own hopes are that this talk focusses on: - the existing experiments and running code, showing how this handles congestion-control. - Actual gains of a L2-enhanced approach, such as this, compared to a mechanism such as ECN. - How to handle speed-increases, previous attempts at explicit signals for speed increases at the IETF have all failed to progress. I am dubious that this signal is useful for a shared capacity bearer. - Explain the security requirements and model (which I do not understand). - Help understand if this useful outside of a single-bottleneck radio network. To avoid any confusion: This is an individual submission expected to start a discussion, this draft will not be considered as a candidate for adoption at this meeting. Gorry > On Mon, Mar 16, 2015 at 5:02 PM, Black, David wrote: > >> Here are four potentially related drafts: >> >> >> >> -- Rate Adaptation based on network feedback, and (to some extent) FCFS >> (weak) admission control: >> >> >> >> This work is TCP based, but with similar goals: >> >> >> >> >> https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/ >> >> https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/ >> >> >> >> The latter draft is (IMHO) better viewed as a proof-of-concept >> demonstration that this can work, as opposed to a specific protocol >> design >> for how to do it. Design concerns have been raised about what was done >> there (e.g., aggressive use of TCP options). >> > > Hi David- > > Are the congestion control concerns being discussed within a working > group? > > --aaron > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Wed Mar 18 10:34:56 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249AF1A8AE5 for ; Wed, 18 Mar 2015 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9Vm64DM5J8QE for ; Wed, 18 Mar 2015 10:34:52 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D61B1A8AE7 for ; Wed, 18 Mar 2015 10:34:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,423,1422950400"; d="scan'208";a="31089056" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx141-out.netapp.com with ESMTP; 18 Mar 2015 10:29:41 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Mar 2015 10:29:40 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Wed, 18 Mar 2015 10:29:40 -0700 From: "Eggert, Lars" To: Gorry Fairhust Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fycwAgABEwYCAAtxIgIAACHeAgAAEk4A= Date: Wed, 18 Mar 2015 17:29:39 +0000 Message-ID: <5D50880B-5739-43AC-ADCA-498617A6C0D7@netapp.com> References: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> In-Reply-To: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2090) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FB2E6ED83C60C4D867CA3DE708138D5@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Aaron Falk , "Pal Martinsen \(palmarti\)" , "Black, David" , Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 17:34:54 -0000 On 2015-3-18, at 18:13, gorry@erg.abdn.ac.uk wrote: > - How to handle speed-increases, previous attempts at explicit signals fo= r > speed increases at the IETF have all failed to progress. I am dubious tha= t > this signal is useful for a shared capacity bearer. +1 This is exactly why we decided to let https://eggert.org/papers/draft-egger= t-tcpm-tcp-retransmit-now-02.txt die. Lars= From nobody Wed Mar 18 10:37:27 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43011A00F5 for ; Wed, 18 Mar 2015 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 iK4G-si0oIyz for ; Wed, 18 Mar 2015 10:37:25 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 DF2CE1A003B for ; Wed, 18 Mar 2015 10:37:24 -0700 (PDT) Received: by igcqo1 with SMTP id qo1so51195647igc.0 for ; Wed, 18 Mar 2015 10:37:24 -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:content-type; bh=n65iidLL0kdgTwKDRrh+OzwGy+JkevRKHJZS3iM1sv0=; b=C2jy5GXkjpPADQM3bYmDg33RMgkVx01rxldzZjBliwbuI2/4uXBrle9s70XNHVytZc izjtTBZfBGiFVjGGwuCbMcAF6GZ0RYsfkeA5wDGcFokfyEBhXddvkjarmRzgqnV2RFeC NowMo/s+JPQ50jsVaRBXuNBDIAig5xdyo20x97f50t1G7dfimV30d16l78U8zQ9MUmTA VIYAp+88HndRB2GkWrEkAXvStf9eFGBRkHS15CFjRe6af1lepL+ZAcj5PssoRAhvPUhG EsMtUyhK/52d7I1xOANKgEfDbzWm0zHNk02wiM7dxtsdhzSFOVW+FQ2RjMGnls6nSmJ0 rxwg== MIME-Version: 1.0 X-Received: by 10.50.129.9 with SMTP id ns9mr9043258igb.24.1426700244425; Wed, 18 Mar 2015 10:37:24 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Wed, 18 Mar 2015 10:37:24 -0700 (PDT) In-Reply-To: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> References: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> Date: Wed, 18 Mar 2015 13:37:24 -0400 Message-ID: From: Aaron Falk To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=047d7b343c9c45236d05119389c4 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , Ted Hardie , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 17:37:27 -0000 --047d7b343c9c45236d05119389c4 Content-Type: text/plain; charset=UTF-8 Ah, so in TSVWG. +1 to your list of hopes. --aaron On Wed, Mar 18, 2015 at 1:13 PM, wrote: > David & I approved the talk as a presentation of current research. > > My own hopes are that this talk focusses on: > > - the existing experiments and running code, showing how this handles > congestion-control. > - Actual gains of a L2-enhanced approach, such as this, compared to a > mechanism such as ECN. > - How to handle speed-increases, previous attempts at explicit signals for > speed increases at the IETF have all failed to progress. I am dubious that > this signal is useful for a shared capacity bearer. > - Explain the security requirements and model (which I do not understand). > - Help understand if this useful outside of a single-bottleneck radio > network. > > To avoid any confusion: This is an individual submission expected to start > a discussion, this draft will not be considered as a candidate for > adoption at this meeting. > > Gorry > > > On Mon, Mar 16, 2015 at 5:02 PM, Black, David > wrote: > > > >> Here are four potentially related drafts: > >> > >> > >> > >> -- Rate Adaptation based on network feedback, and (to some extent) FCFS > >> (weak) admission control: > >> > >> > >> > >> This work is TCP based, but with similar goals: > >> > >> > >> > >> > >> > https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/ > >> > >> > https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/ > >> > >> > >> > >> The latter draft is (IMHO) better viewed as a proof-of-concept > >> demonstration that this can work, as opposed to a specific protocol > >> design > >> for how to do it. Design concerns have been raised about what was done > >> there (e.g., aggressive use of TCP options). > >> > > > > Hi David- > > > > Are the congestion control concerns being discussed within a working > > group? > > > > --aaron > > _______________________________________________ > > Spud mailing list > > Spud@ietf.org > > https://www.ietf.org/mailman/listinfo/spud > > > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --047d7b343c9c45236d05119389c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, so in TSVWG. =C2=A0+1 to your list of hopes.

<= /div>
--aaron

On Wed, Mar 18, 2015 at 1:13 PM, <gorry@erg.abdn.ac.uk= > wrote:
David & I=C2=A0 ap= proved the talk as a presentation of current research.

My own hopes are that this talk focusses on:

- the existing experiments and running code, showing how this handles
congestion-control.
- Actual gains of a L2-enhanced approach, such as this, compared to a
mechanism such as ECN.
- How to handle speed-increases, previous attempts at explicit signals for<= br> speed increases at the IETF have all failed to progress. I am dubious that<= br> this signal is useful for a shared capacity bearer.
- Explain the security requirements and model (which I do not understand).<= br> - Help understand if this useful outside of a single-bottleneck radio
network.

To avoid any confusion: This is an individual submission expected to start<= br> a discussion, this draft will not be considered as a candidate for
adoption at this meeting.

Gorry

> On Mon, Mar 16, 2015 at 5:02 PM, Black, David <david.black@emc.com> wrote:
>
>>=C2=A0 Here are four potentially related drafts:
>>
>>
>>
>> -- Rate Adaptation based on network feedback, and (to some extent)= FCFS
>> (weak) admission control:
>>
>>
>>
>> This work is TCP based, but with similar goals:
>>
>>
>>
>>
>> https://datatracker.ietf.org/doc/d= raft-sprecher-mobile-tg-exposure-req-arch/
>>
>> https://datatracker.ietf.org/doc/draf= t-flinck-mobile-throughput-guidance/
>>
>>
>>
>> The latter draft is (IMHO) better viewed as a proof-of-concept
>> demonstration that this can work, as opposed to a specific protoco= l
>> design
>> for how to do it.=C2=A0 Design concerns have been raised about wha= t was done
>> there (e.g., aggressive use of TCP options).
>>
>
> Hi David-
>
> Are the congestion control concerns being discussed within a working > group?
>
> --aaron
> __________________= _____________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>


_______________________________________________
Spud mailing list
Spud@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spud

--047d7b343c9c45236d05119389c4-- From nobody Wed Mar 18 14:16:37 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0ACB1A90E6 for ; Wed, 18 Mar 2015 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hdR61x-PBLbF for ; Wed, 18 Mar 2015 14:16:33 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 804221A88EB for ; Wed, 18 Mar 2015 14:16:33 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2ILGOAk005192 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Mar 2015 17:16:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t2ILGOAk005192 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1426713386; bh=omYI+CQ4dH42FQwsXUbW929xgR4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=K9z6RKxGDaKNPu4wzQHOJ5nvAQcCHC8dXOvf1qNdu/y12muwDLooTbeXBDgeD8HtY BTDP3d4b3f7xvuNj6d5GavXFYZZEdLu5VSJmlwpZYvwDZpgmWt1w6aXlNC3fWGYZes txGcxca+bBVYnOXjxFil4G+iGSE5C+TUA8xqfy8c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t2ILGOAk005192 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 18 Mar 2015 17:15:41 -0400 Received: from mxhub39.corp.emc.com (mxhub39.corp.emc.com [128.222.70.106]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2ILG6NG007942 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Mar 2015 17:16:06 -0400 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub39.corp.emc.com (128.222.70.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 18 Mar 2015 17:16:06 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0224.002; Wed, 18 Mar 2015 17:16:05 -0400 From: "Black, David" To: Aaron Falk , Gorry Fairhurst Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fl4EA///wybCAAzBAgIAACHeAgAAGvQD///f8cA== Date: Wed, 18 Mar 2015 21:16:04 +0000 Message-ID: References: <9b0c6afc92491c6dfe1b1401c02aa162.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.163] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936416D62MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 21:16:36 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936416D62MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAtIEV4cGxhaW4gdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhbmQgbW9kZWwgKHdoaWNoIEkg ZG8gbm90IHVuZGVyc3RhbmQpLg0KDQpJIGJlbGlldmUgdGhhdCBJIGRvIHVuZGVyc3RhbmQgdGhl IHNlY3VyaXR5IG1vZGVsLCBhbmQgSSBzZWUgc2VyaW91cyBwcm9ibGVtcyB3aXRoIGl0Lg0KDQpP dmVyYWxsLCBhcyBHb3JyeSBub3RlZCwgd2UgKHRzdndnIGNoYWlycykgcHV0IHRoaXMgdG9waWMg KHByaW1hcmlseSBkcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gpIG9u IHRoZSB0c3Z3ZyBEYWxsYXMgIGFnZW5kYSBiZWNhdXNlIHdlIHRoaW5rIHRoZXJl4oCZcyBhbiBp bnRlcmVzdGluZyBkaXNjdXNzaW9uIHRvIGJlIGhhZCBhYm91dCB3aGF0IGNvdWxkIGFuZCBzaG91 bGQgYmUgZG9uZSBpbiB0aGlzIGFyZWEuDQpTcGVha2luZyBmb3IgbXlzZWxmLCB1bmRlcnN0YW5k aW5nIHRoZSBwb3NzaWJpbGl0aWVzIGhlcmUgaXMgdXNlZnVsLCBzbyB0aGUgZXhwZXJpbWVudHMg YXJlIHZhbHVhYmxlLCBidXQgSSBkb27igJl0IHJlZ2FyZCB0aGUgcHJvdG9jb2wgdXNlZCB0byBy dW4gdGhlIGV4cGVyaW1lbnRzIGFzIHVzZWZ1bCBmb3IgbXVjaCBiZXlvbmQgdGhhbiBydW5uaW5n IGV4cGVyaW1lbnRzLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCkZyb206IEFhcm9uIEZhbGsgW21h aWx0bzphYXJvbi5mYWxrQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTgsIDIw MTUgMTozNyBQTQ0KVG86IEdvcnJ5IEZhaXJodXJzdA0KQ2M6IFBhbCBNYXJ0aW5zZW4gKHBhbG1h cnRpKTsgQmxhY2ssIERhdmlkOyBUZWQgSGFyZGllOyBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW1NwdWRdIEFkZGl0aW9uYWwgU1BVRCB1c2UtY2FzZXMNCg0KQWgsIHNvIGluIFRTVldHLiAg KzEgdG8geW91ciBsaXN0IG9mIGhvcGVzLg0KDQotLWFhcm9uDQoNCk9uIFdlZCwgTWFyIDE4LCAy MDE1IGF0IDE6MTMgUE0sIDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFi ZG4uYWMudWs+PiB3cm90ZToNCkRhdmlkICYgSSAgYXBwcm92ZWQgdGhlIHRhbGsgYXMgYSBwcmVz ZW50YXRpb24gb2YgY3VycmVudCByZXNlYXJjaC4NCg0KTXkgb3duIGhvcGVzIGFyZSB0aGF0IHRo aXMgdGFsayBmb2N1c3NlcyBvbjoNCg0KLSB0aGUgZXhpc3RpbmcgZXhwZXJpbWVudHMgYW5kIHJ1 bm5pbmcgY29kZSwgc2hvd2luZyBob3cgdGhpcyBoYW5kbGVzDQpjb25nZXN0aW9uLWNvbnRyb2wu DQotIEFjdHVhbCBnYWlucyBvZiBhIEwyLWVuaGFuY2VkIGFwcHJvYWNoLCBzdWNoIGFzIHRoaXMs IGNvbXBhcmVkIHRvIGENCm1lY2hhbmlzbSBzdWNoIGFzIEVDTi4NCi0gSG93IHRvIGhhbmRsZSBz cGVlZC1pbmNyZWFzZXMsIHByZXZpb3VzIGF0dGVtcHRzIGF0IGV4cGxpY2l0IHNpZ25hbHMgZm9y DQpzcGVlZCBpbmNyZWFzZXMgYXQgdGhlIElFVEYgaGF2ZSBhbGwgZmFpbGVkIHRvIHByb2dyZXNz LiBJIGFtIGR1YmlvdXMgdGhhdA0KdGhpcyBzaWduYWwgaXMgdXNlZnVsIGZvciBhIHNoYXJlZCBj YXBhY2l0eSBiZWFyZXIuDQotIEV4cGxhaW4gdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhbmQg bW9kZWwgKHdoaWNoIEkgZG8gbm90IHVuZGVyc3RhbmQpLg0KLSBIZWxwIHVuZGVyc3RhbmQgaWYg dGhpcyB1c2VmdWwgb3V0c2lkZSBvZiBhIHNpbmdsZS1ib3R0bGVuZWNrIHJhZGlvDQpuZXR3b3Jr Lg0KDQpUbyBhdm9pZCBhbnkgY29uZnVzaW9uOiBUaGlzIGlzIGFuIGluZGl2aWR1YWwgc3VibWlz c2lvbiBleHBlY3RlZCB0byBzdGFydA0KYSBkaXNjdXNzaW9uLCB0aGlzIGRyYWZ0IHdpbGwgbm90 IGJlIGNvbnNpZGVyZWQgYXMgYSBjYW5kaWRhdGUgZm9yDQphZG9wdGlvbiBhdCB0aGlzIG1lZXRp bmcuDQoNCkdvcnJ5DQoNCj4gT24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNTowMiBQTSwgQmxhY2ss IERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4g d3JvdGU6DQo+DQo+PiAgSGVyZSBhcmUgZm91ciBwb3RlbnRpYWxseSByZWxhdGVkIGRyYWZ0czoN Cj4+DQo+Pg0KPj4NCj4+IC0tIFJhdGUgQWRhcHRhdGlvbiBiYXNlZCBvbiBuZXR3b3JrIGZlZWRi YWNrLCBhbmQgKHRvIHNvbWUgZXh0ZW50KSBGQ0ZTDQo+PiAod2VhaykgYWRtaXNzaW9uIGNvbnRy b2w6DQo+Pg0KPj4NCj4+DQo+PiBUaGlzIHdvcmsgaXMgVENQIGJhc2VkLCBidXQgd2l0aCBzaW1p bGFyIGdvYWxzOg0KPj4NCj4+DQo+Pg0KPj4NCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaC8NCj4+DQo+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mbGluY2stbW9iaWxlLXRo cm91Z2hwdXQtZ3VpZGFuY2UvDQo+Pg0KPj4NCj4+DQo+PiBUaGUgbGF0dGVyIGRyYWZ0IGlzIChJ TUhPKSBiZXR0ZXIgdmlld2VkIGFzIGEgcHJvb2Ytb2YtY29uY2VwdA0KPj4gZGVtb25zdHJhdGlv biB0aGF0IHRoaXMgY2FuIHdvcmssIGFzIG9wcG9zZWQgdG8gYSBzcGVjaWZpYyBwcm90b2NvbA0K Pj4gZGVzaWduDQo+PiBmb3IgaG93IHRvIGRvIGl0LiAgRGVzaWduIGNvbmNlcm5zIGhhdmUgYmVl biByYWlzZWQgYWJvdXQgd2hhdCB3YXMgZG9uZQ0KPj4gdGhlcmUgKGUuZy4sIGFnZ3Jlc3NpdmUg dXNlIG9mIFRDUCBvcHRpb25zKS4NCj4+DQo+DQo+IEhpIERhdmlkLQ0KPg0KPiBBcmUgdGhlIGNv bmdlc3Rpb24gY29udHJvbCBjb25jZXJucyBiZWluZyBkaXNjdXNzZWQgd2l0aGluIGEgd29ya2lu Zw0KPiBncm91cD8NCj4NCj4gLS1hYXJvbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBTcHVkIG1haWxpbmcgbGlzdA0KPiBTcHVkQGlldGYub3Jn PG1haWx0bzpTcHVkQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwdWQNCj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KU3B1ZCBtYWlsaW5nIGxpc3QNClNwdWRAaWV0Zi5vcmc8bWFpbHRvOlNwdWRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCg0K --_000_CE03DB3D7B45C245BCA0D24327794936416D62MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlv bjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mZ3Q7DQo8L3NwYW4+LSBFeHBsYWluIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMg YW5kIG1vZGVsICh3aGljaCBJIGRvIG5vdCB1bmRlcnN0YW5kKS48Yj48bzpwPjwvbzpwPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSBiZWxpZXZlIHRoYXQg SSBkbyB1bmRlcnN0YW5kIHRoZSBzZWN1cml0eSBtb2RlbCwgYW5kIEkgc2VlIHNlcmlvdXMgcHJv YmxlbXMgd2l0aCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk92ZXJhbGwsIGFzIEdvcnJ5 IG5vdGVkLCB3ZSAodHN2d2cgY2hhaXJzKSBwdXQgdGhpcyB0b3BpYyAocHJpbWFyaWx5IGRyYWZ0 LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaCkgb24gdGhlIHRzdndnIERhbGxh cyAmbmJzcDthZ2VuZGEgYmVjYXVzZSB3ZSB0aGluayB0aGVyZeKAmXMgYW4NCiBpbnRlcmVzdGlu ZyBkaXNjdXNzaW9uIHRvIGJlIGhhZCBhYm91dCB3aGF0IGNvdWxkIGFuZCBzaG91bGQgYmUgZG9u ZSBpbiB0aGlzIGFyZWEuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+U3BlYWtpbmcgZm9yIG15c2VsZiwgdW5k ZXJzdGFuZGluZyB0aGUgcG9zc2liaWxpdGllcyBoZXJlIGlzIHVzZWZ1bCwgc28gdGhlIGV4cGVy aW1lbnRzIGFyZSB2YWx1YWJsZSwgYnV0IEkgZG9u4oCZdCByZWdhcmQgdGhlIHByb3RvY29sIHVz ZWQgdG8gcnVuIHRoZSBleHBlcmltZW50cyBhcyB1c2VmdWwNCiBmb3IgbXVjaCBiZXlvbmQgdGhh biBydW5uaW5nIGV4cGVyaW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo YW5rcyw8YnI+DQotLURhdmlkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBYXJvbiBGYWxrIFttYWlsdG86YWFyb24uZmFsa0BnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAxOCwgMjAxNSAxOjM3 IFBNPGJyPg0KPGI+VG86PC9iPiBHb3JyeSBGYWlyaHVyc3Q8YnI+DQo8Yj5DYzo8L2I+IFBhbCBN YXJ0aW5zZW4gKHBhbG1hcnRpKTsgQmxhY2ssIERhdmlkOyBUZWQgSGFyZGllOyBzcHVkQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3B1ZF0gQWRkaXRpb25hbCBTUFVEIHVzZS1j YXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BaCwgc28gaW4gVFNWV0cuICZuYnNwOyYjNDM7MSB0byB5b3VyIGxpc3Qgb2YgaG9wZXMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLWFhcm9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg TWFyIDE4LCAyMDE1IGF0IDE6MTMgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFi ZG4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQgJmFtcDsgSSZu YnNwOyBhcHByb3ZlZCB0aGUgdGFsayBhcyBhIHByZXNlbnRhdGlvbiBvZiBjdXJyZW50IHJlc2Vh cmNoLjxicj4NCjxicj4NCk15IG93biBob3BlcyBhcmUgdGhhdCB0aGlzIHRhbGsgZm9jdXNzZXMg b246PGJyPg0KPGJyPg0KLSB0aGUgZXhpc3RpbmcgZXhwZXJpbWVudHMgYW5kIHJ1bm5pbmcgY29k ZSwgc2hvd2luZyBob3cgdGhpcyBoYW5kbGVzPGJyPg0KY29uZ2VzdGlvbi1jb250cm9sLjxicj4N Ci0gQWN0dWFsIGdhaW5zIG9mIGEgTDItZW5oYW5jZWQgYXBwcm9hY2gsIHN1Y2ggYXMgdGhpcywg Y29tcGFyZWQgdG8gYTxicj4NCm1lY2hhbmlzbSBzdWNoIGFzIEVDTi48YnI+DQotIEhvdyB0byBo YW5kbGUgc3BlZWQtaW5jcmVhc2VzLCBwcmV2aW91cyBhdHRlbXB0cyBhdCBleHBsaWNpdCBzaWdu YWxzIGZvcjxicj4NCnNwZWVkIGluY3JlYXNlcyBhdCB0aGUgSUVURiBoYXZlIGFsbCBmYWlsZWQg dG8gcHJvZ3Jlc3MuIEkgYW0gZHViaW91cyB0aGF0PGJyPg0KdGhpcyBzaWduYWwgaXMgdXNlZnVs IGZvciBhIHNoYXJlZCBjYXBhY2l0eSBiZWFyZXIuPGJyPg0KLSBFeHBsYWluIHRoZSBzZWN1cml0 eSByZXF1aXJlbWVudHMgYW5kIG1vZGVsICh3aGljaCBJIGRvIG5vdCB1bmRlcnN0YW5kKS48YnI+ DQotIEhlbHAgdW5kZXJzdGFuZCBpZiB0aGlzIHVzZWZ1bCBvdXRzaWRlIG9mIGEgc2luZ2xlLWJv dHRsZW5lY2sgcmFkaW88YnI+DQpuZXR3b3JrLjxicj4NCjxicj4NClRvIGF2b2lkIGFueSBjb25m dXNpb246IFRoaXMgaXMgYW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGV4cGVjdGVkIHRvIHN0YXJ0 PGJyPg0KYSBkaXNjdXNzaW9uLCB0aGlzIGRyYWZ0IHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMg YSBjYW5kaWRhdGUgZm9yPGJyPg0KYWRvcHRpb24gYXQgdGhpcyBtZWV0aW5nLjxicj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5Hb3JyeTwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCiZndDsgT24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNTowMiBQTSwgQmxhY2ss IERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSI+ZGF2aWQuYmxh Y2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBI ZXJlIGFyZSBmb3VyIHBvdGVudGlhbGx5IHJlbGF0ZWQgZHJhZnRzOjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tIFJhdGUgQWRhcHRhdGlv biBiYXNlZCBvbiBuZXR3b3JrIGZlZWRiYWNrLCBhbmQgKHRvIHNvbWUgZXh0ZW50KSBGQ0ZTPGJy Pg0KJmd0OyZndDsgKHdlYWspIGFkbWlzc2lvbiBjb250cm9sOjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoaXMgd29yayBpcyBUQ1AgYmFz ZWQsIGJ1dCB3aXRoIHNpbWlsYXIgZ29hbHM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1 cmUtcmVxLWFyY2gvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gvPC9hPjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmxpbmNrLW1vYmlsZS10aHJvdWdocHV0LWd1aWRhbmNlLyIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmxp bmNrLW1vYmlsZS10aHJvdWdocHV0LWd1aWRhbmNlLzwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgbGF0dGVyIGRyYWZ0IGlzIChJ TUhPKSBiZXR0ZXIgdmlld2VkIGFzIGEgcHJvb2Ytb2YtY29uY2VwdDxicj4NCiZndDsmZ3Q7IGRl bW9uc3RyYXRpb24gdGhhdCB0aGlzIGNhbiB3b3JrLCBhcyBvcHBvc2VkIHRvIGEgc3BlY2lmaWMg cHJvdG9jb2w8YnI+DQomZ3Q7Jmd0OyBkZXNpZ248YnI+DQomZ3Q7Jmd0OyBmb3IgaG93IHRvIGRv IGl0LiZuYnNwOyBEZXNpZ24gY29uY2VybnMgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB3aGF0IHdh cyBkb25lPGJyPg0KJmd0OyZndDsgdGhlcmUgKGUuZy4sIGFnZ3Jlc3NpdmUgdXNlIG9mIFRDUCBv cHRpb25zKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEhpIERhdmlkLTxicj4N CiZndDs8YnI+DQomZ3Q7IEFyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGNvbmNlcm5zIGJlaW5n IGRpc2N1c3NlZCB3aXRoaW4gYSB3b3JraW5nPGJyPg0KJmd0OyBncm91cD88YnI+DQomZ3Q7PGJy Pg0KJmd0OyAtLWFhcm9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBTcHVkIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgPGEgaHJlZj0ibWFpbHRvOlNwdWRAaWV0Zi5vcmciPlNwdWRAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw dWQ8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU3B1ZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86U3B1ZEBpZXRmLm9yZyI+U3B1ZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQ8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D24327794936416D62MX104CL02corpemcc_-- From nobody Thu Mar 19 08:38:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80FE1A0174 for ; Thu, 19 Mar 2015 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ov31tPtH9gAT for ; Thu, 19 Mar 2015 08:38:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23071ACDDC for ; Thu, 19 Mar 2015 08:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 71BE2D9307; Thu, 19 Mar 2015 16:38:08 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Iqxs37obP0YV; Thu, 19 Mar 2015 16:38:08 +0100 (MET) Received: from 172-27-222-211.dynapool.nyu.edu (NYUFWA-BORDERNAT-GUEST-02.NET.NYU.EDU [192.76.177.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A158CD9309; Thu, 19 Mar 2015 16:38:07 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> Date: Thu, 19 Mar 2015 11:38:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> To: "Pal Martinsen (palmarti)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Black, David" , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:38:18 -0000 Hi all, just a quick though on our comment regarding basically =E2=80=9Awhy does = DSCP not work inter-domain=E2=80=98. One answer to this question is that = is it mostly used intra-domain and that=E2=80=99s okay. That=E2=80=99s = why we look at SPUD because we actually what something inter-domain (at = least to signal information without negotiation). Therefore the = questions for SPUD are for me: - How can we ensure that information provided by the end-point does not = get modified? and more complicated - How can we ensure that information a middlebox puts in is not = (wrongly) modified by another middlebox (as there are cases, we we want = one middlebox to override data of another middlebox=E2=80=A6?) Mirja > Am 17.03.2015 um 05:47 schrieb Pal Martinsen (palmarti) = : >=20 >=20 >> On 16 Mar 2015, at 22:02, Black, David wrote: >>=20 >> Here are four potentially related drafts: >> =20 >=20 > Thanks for pointing them out. Interesting read. >=20 >> -- Rate Adaptation based on network feedback, and (to some extent) = FCFS (weak) admission control: >> =20 >> This work is TCP based, but with similar goals: >> =20 >> = https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arc= h/ >> = https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/ >> =20 >> The latter draft is (IMHO) better viewed as a proof-of-concept = demonstration that this can work, as opposed to a specific protocol = design for how to do it. Design concerns have been raised about what = was done there (e.g., aggressive use of TCP options). >=20 > For now my conclusion is; there is interest in solving similar = problems for TCP, so adding it to the SPUD use-case discussion make = sense. >=20 >> =20 >> -- Dynamic Per Type Packet Prioritization (DPTPP *sigh*) >> =20 >> Web RTC wants to do this from the application: >> =20 >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ >> =20 >> And it can be done, if one is careful: >> =20 >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ (in = RFC Editor Queue) >=20 > We have implemented a prototype setting different DSCP values on = different video packets a few years back. The platform we did it on was = a bit underpowered regarding main CPU vs video enc/dev processors. The = extra setsockopt call to change the pr packet DSCP value caused = problems. Was also unsure if any buffering in the OS cause the right = markings to be set on the right packet. The sendMsg() function will = probably ensure that, but at the time we did not rewrite our stack to = support that.=20 >=20 > Do we have any information that network elements can handle different = DSCP values within a 5-tuple? Word on the street a few years back was = that it could be difficult for some platforms. >=20 > In my head SPUD will improve the above drafts by: >=20 > - Provide end to end signalling.=20 > (Would be interesting to know the rationale on why the networks = remarks the DSCP values so we can avoid that with SPUD). >=20 > - Easier for applications. Just memcpy() a spud buffer in front of = your RTP packet (Make sure to start writing your RTP packet a bit into = the buffer=E2=80=A6), and fire off the packet as usual. This is an = important aspect as it eases the integration work of SPUD. If the = application already supports ICE it probably does do similar tricks = because of TURN.=20 >=20 > - It is possible to build a SPUD->DSCP gateway. This is nice as = customers can place that gateway at the edge and still have the old = carefully DSCP crafted network provide value.=20 >=20 >=20 > .-. > P=C3=A5l-Erik >=20 >> =20 >> =20 >> Thanks, >> --David >> =20 >> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Ted Hardie >> Sent: Monday, March 16, 2015 12:56 PM >> To: Pal Martinsen (palmarti) >> Cc: spud@ietf.org >> Subject: Re: [Spud] Additional SPUD use-cases >> =20 >> Hi P=C3=A5l-Erik, >>=20 >> Thanks for your message; some comments in-line. >> =20 >> On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) = wrote: >> Hi,=20 >> =20 >> I have a few additional SPUD use-cases I want to bring to the list = before the BoF. Some of them have already been solved by using STUN as a = signalling protocol = (http://tools.ietf.org/id/draft-martinsen-tram-discuss-02.txt). I think = SPUD is a more efficient carrier of the bits needed to solve some of the = use-cases. But for now they are just use-cases, and discussions on how = to solve them should probably be deferred to a later stage. >> =20 >> * Rate Adaption With Confidence >> Todays delay sensing rate adaption mechanisms seems to be working = very well and can potentially react within half a RTT (Is TT, Trip Time, = more accurate or in use as a term?). Having explicit network feedback = signalled back to endpoint enabled endpoints to pick a more reasonable = starting value when sending media. Explicit signalling during the call = enables the network as to signal information back to the endpoint before = the problems occur (ECN). Up/down speeding could potentially be done in = larger chunks with confidence.=20 >> =20 >> * First Come, First Serve=20 >> In WiFi we have some lab tests that show when you hit a limit you hit = it hard and everybody on that link suffers. If 9 people enjoy their = video conversations going through the same WiFi AP, it is annoying if a = 10th call is added causing everybody to get bad video. A possible = solution is to let the network signal back to the 10th participants = trying to send video that bandwidth is not available; =E2=80=9CI will = put you in worse than best effort queue if you try to send at that = rate=E2=80=9D. If bandwidth become available the network will notify the = user. Note that this is not RSVP and resource allocation, just hints = from the network that if you try, you will suffer.=20 >> =E2=80=8B >> =20 >> =E2=80=8BWhen you say "the network" here, this seems to me the first = hop-AP. For cases where the radio resources are at issue, it seems = likely that you might want to coordinate this with the other 802.11 = facilities, so I'm not sure that this the right layer to do this. In = particular, multi-AP deployments might request the station re-associate = to a less-busy AP or make other adjustments to the channel handling of = frame marked with the higher priority WMM bits (given the potential = issues with cross-talk, shifting APs is certainly not a panacea, but my = be better than what amounts to admission control).=20 >>=20 >> =E2=80=8B >> =20 >> * Dynamic Per Type Packet Prioritisation (DPTPP *sigh*) >> The SPUD use case draft opens up for tube prioritisation. It is = possible to prioritise among for example audio, video and data tubes = when multiplexing (Bundle) is in use. It is important that the = prioritisation is made dynamic. When running a video conference you = might want to prioritise video packets, but suddenly there is a need to = upload a large presentation to all the participants. In that case it = might not make sense for participants having pristine 1080p60 video = watching each other waiting for the slow uploading of the presentation = to finish. >> =20 >> And the packet type prioritisation does not necessarily stop at audio = or video level. Video packets can have for example spatial layers where = packets belonging to a temporal layer can be discarded by the network = without to much impact on the video quality. Discarding an I-Frame would = have much more impact on the quality.=20 >> =20 >> =20 >> =E2=80=8BI think ordinal priority among the tubes coming from the = same user is a baseline use case. There seem to be two possibilities to = making that dynamic: mint a new tube or set of tubes on the same = 6-tuple =E2=80=8Bwhen the ordinal priority changes or update the ordinal = priority on the existing tubes. I am not sure of the complexity = trade-off between those two yet, and I'd be interested in folks thoughts = on that. >> =20 >> =E2=80=8Bregards, >>=20 >> Ted=E2=80=8B >>=20 >> =20 >> =20 >> =20 >> Comments, flames and what not are of course welcome.=20 >> =20 >> .-. >> P=C3=A5l-Erik >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >>=20 >> =20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Thu Mar 19 08:48:14 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291731A1A0C for ; Thu, 19 Mar 2015 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 3P3si4JQyjVG for ; Thu, 19 Mar 2015 08:48:12 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 C7B361A037B for ; Thu, 19 Mar 2015 08:48:11 -0700 (PDT) Received: by igcau2 with SMTP id au2so97542191igc.0 for ; Thu, 19 Mar 2015 08:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4wPNhyphrF97LvBuSe9etrnekskZ5phq+oqRi8h2UBY=; b=NCkxtzoE8IcxPGAPc//0i+g65c3ujGAxOcXvouBYn0GtEwsxQSvp0qyfvdi48kby/Z 4wO1DtayHDEnbsCVJTr2xdcGPIXi/aEIkkbuR69coNBBNgqnw0EIsYn2F8lXOv+BS0fH ZQeBsqpf8QNKcBcFn/VI759fsfdfJ1eDFE/1kxW7ZAesWs/JQhZll/ipK0WPp/we95Rx 8CU2N9UAWUoayvz4imLoKf9HzyJCDDr/uB2360JunVz2uz8MRRTvXEwJwUJCIXo7DJvB CbBjRS8Qi3vfHi59c0wur0pNJbu87QoP2pXZd1XFk5sg92dg01yY1eBi+4Ov8nvbIBG5 KdzQ== MIME-Version: 1.0 X-Received: by 10.42.88.205 with SMTP id d13mr103193225icm.16.1426780091287; Thu, 19 Mar 2015 08:48:11 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Thu, 19 Mar 2015 08:48:11 -0700 (PDT) Date: Thu, 19 Mar 2015 11:48:11 -0400 Message-ID: From: Aaron Falk To: "spud@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba614c26838e4a0511a6202f Archived-At: Subject: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:48:13 -0000 --90e6ba614c26838e4a0511a6202f Content-Type: text/plain; charset=UTF-8 The draft doesn't say much about how one efficiently determines whether the other end is SPUD-capable so that an application can know whether it can use it. Has anyone given thought to this? --aaron --90e6ba614c26838e4a0511a6202f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The draft doesn't say much about how one efficiently d= etermines whether the other end is SPUD-capable so that an application can = know whether it can use it.=C2=A0 Has anyone given thought to this?
--aaron
--90e6ba614c26838e4a0511a6202f-- From nobody Thu Mar 19 08:53:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83231A1A7D for ; Thu, 19 Mar 2015 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DUvvfe2P_Z48 for ; Thu, 19 Mar 2015 08:53:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9402B1A1A77 for ; Thu, 19 Mar 2015 08:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CCEF6D9305; Thu, 19 Mar 2015 16:53:34 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7uz9tJgAB94N; Thu, 19 Mar 2015 16:53:34 +0100 (MET) Received: from 172-27-222-211.dynapool.nyu.edu (NYUFWA-BORDERNAT-GUEST-02.NET.NYU.EDU [192.76.177.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3D049D9304; Thu, 19 Mar 2015 16:53:34 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 19 Mar 2015 11:53:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:53:38 -0000 Hi Aaron, yes and thanks for asking this question on the list. Don=E2=80=99t have the perfect answer though. But my current answer is: = negotiation is done in the higher layer; two clients of the same app = might know if the version the other end is using is Spud-enabled. However, curious to hear more ideas! Mirja > Am 19.03.2015 um 11:48 schrieb Aaron Falk : >=20 > The draft doesn't say much about how one efficiently determines = whether the other end is SPUD-capable so that an application can know = whether it can use it. Has anyone given thought to this? >=20 > --aaron > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Thu Mar 19 08:57:34 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0A81A1A6C for ; Thu, 19 Mar 2015 08:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pK_CsT0P4fbV for ; Thu, 19 Mar 2015 08:57:32 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580021A00FD for ; Thu, 19 Mar 2015 08:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=646; q=dns/txt; s=iport; t=1426780652; x=1427990252; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bL6VkR/7qNtKGtbIMmSZksDK/Vva7kt+8KDsqLJsq3k=; b=OcniKbq/suKLcVh4XXDW9Xx2zS3K0BFq4URg7EOR7HD+MBd5ss4qW6n/ YcD/+zBe2qiTdOYv1vXIhb6ACATf1nBgVKVPrOab89+fP6tFz3BI+ujdy iEr8jIfKXvYtZNfZq7O8podTd6Q3XAB4WwX4kJnJ511a/IjuCxz2ZZr48 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQBh8QpV/4sNJK1cgwaBMIMJySqBLEwBAQEBAQF9hBYjEVcBIgImAgQwFRIEiEKiXY9Mm38BAQEBAQUBAQEBAQEBG4EhkVYvgRYFhhWKNIltlCgig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="133544983" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 19 Mar 2015 15:57:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2JFvVN8014113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Mar 2015 15:57:31 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 10:57:31 -0500 From: "Pal Martinsen (palmarti)" To: "spud@ietf.org" Thread-Topic: Multipath UDP as a SPUD usecase? Thread-Index: AQHQYl1oy/a7HQ8YI0GdabFsia7XCg== Date: Thu, 19 Mar 2015 15:57:31 +0000 Message-ID: <20ACD661-4139-456B-AF61-38CA73BF0C0B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.115] Content-Type: text/plain; charset="utf-8" Content-ID: <29B200C4DCAB88429ABACD2A0CFE6FDB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Spud] Multipath UDP as a SPUD usecase? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:57:33 -0000 SGksDQoNCkFub3RoZXIgcG90ZW50aWFsIHVzZS1jYXNlIFNQVUQgY291bGQgaGVscCBzb2x2ZSBp cyBtdWx0aXBhdGggVURQLiBJIGRvIG5vdCBoYXZlIGVub3VnaCBpbnNpZ2h0IHJlZ2FyZGluZyBi aXRzIG9uIHRoZSB3aXJlIHRvIGFjY29tcGxpc2ggdGhpcyBidXQgdG8gbWUgaXQgd291bGQgYmUg YSBjb21wZWxsaW5nIHVzZWNhc2UuDQoNCkl0IG1pZ2h0Og0KICAtIFByb3ZpZGUgZWFzeSDigJxt ZWRpYSBtb2JpbGl0eeKAnSB3aGVuIGEgZGV2aWNlIHN3aXRjaGVzIG5ldHdvcmsuDQogIC0gQmV0 dGVyIHRocm91Z2hwdXQgKE5vdCBzdXJlIGFib3V0IHRoaXMuLikNCg0KU2luY2Ugd2UgYWxyZWFk eSBoYXZlIHRoaXMgZm9yIFRDUCBhbmQgdGhlcmUgaXMgYSBtdWx0aS1wYXRoIFJUUCBkcmFmdCB0 aGVyZSBzZWVtcyB0byBiZSBzb21lIGludGVyZXN0IGluIHNvbHZpbmcgdGhpcy4gDQoNCi4tLg0K UMOlbC1FcmlrDQoNCg== From nobody Thu Mar 19 09:19:22 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82B31ACE25 for ; Thu, 19 Mar 2015 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YKZ3Lv3DFU9F for ; Thu, 19 Mar 2015 09:19:18 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BD52B1ACE1D for ; Thu, 19 Mar 2015 09:19:18 -0700 (PDT) Received: from 172-27-222-66.dynapool.nyu.edu (NYUFWA-BORDERNAT-GUEST-02.NET.NYU.EDU [192.76.177.125]) by trammell.ch (Postfix) with ESMTPSA id F11081A0032; Thu, 19 Mar 2015 17:18:46 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CB08C4C6-26C8-4BEC-ACCA-9BE9EB42CC72"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: Date: Thu, 19 Mar 2015 12:18:45 -0400 Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:19:20 -0000 --Apple-Mail=_CB08C4C6-26C8-4BEC-ACCA-9BE9EB42CC72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Aaron, > On 19 Mar 2015, at 11:48, Aaron Falk wrote: >=20 > The draft ... where "the draft" is draft-hildebrand-spud-prototype ... > doesn't say much about how one efficiently determines whether the = other end is SPUD-capable so that an application can know whether it can = use it. No, it doesn't. > Has anyone given thought to this? Yes, I have... I think for the most part that this question is (1) very important but = (2) mostly orthogonal to that we're trying to answer in spud-prototype. Initially, I would expect that discovery works the same way that it does = for any other user of the transport layer: you either have a URL, or a = name and a port, or some information from your application-layer = protocol's discovery service, which includes "uses x-over-SPUD" in its = semantics. Dynamically discovering a SPUD endpoint might make sense if a server = port / URL schema is assigned to a service over X or a service over = x-over-SPUD. In this case, the magic number we've selected makes SPUD = server probing by the client possible: a SPUD packet is neither valid = UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or = Bittorrent. This is not an exhaustive list, but we haven't found a = protocol over UDP that is likely to consider d8 00 00 d8 as the first = four bytes anything other than an error. Maybe we should mention this in the draft, but I think it's the *next* = problem to solve. Cheers, Brian --Apple-Mail=_CB08C4C6-26C8-4BEC-ACCA-9BE9EB42CC72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVCvblAAoJENt3nsOmbNJcu/0H/jsoGeHTm3rq8WQtJ8jBW9Nn QaXEBBb88IBAUAD4Sn8Eu2ILtj04Su90eYE5zysgy2jSV8xwvTwII84IXzrwlVYb xm/V5tT9yoWFkIKcSG51ZRFwXSerfTr0RVBwIwc9MfNr3p2znCMof0KBQNiN0Di2 E/4E/JF7OhPIXRDrtZQlQXp5iy4wECCiNmfayJVvkZh+T8JjTRx5BVDPLtmRLSOk YC7b1gJLvcJlChySOzjw97Svic5QfbJJQR6EYwgbmKT6gQRH7dWkAv17DLwV2JRU KGSAL0khmxnPCKo9Yyb8DObxbuf/kO9JdUgNpBqJ5yOMaY5KyubXKOYrNlx1D10= =mObU -----END PGP SIGNATURE----- --Apple-Mail=_CB08C4C6-26C8-4BEC-ACCA-9BE9EB42CC72-- From nobody Thu Mar 19 10:02:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D71A1A47 for ; Thu, 19 Mar 2015 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vp6Dwr8lIJLA for ; Thu, 19 Mar 2015 10:02:08 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF351A1EF3 for ; Thu, 19 Mar 2015 10:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1192; q=dns/txt; s=iport; t=1426784528; x=1427994128; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OaT0qChyqSQTYe4gIHySi+QSkubnDp8aEjQToII0S5U=; b=VpGEVZK7u342Er096cgEit2PiyqUk44CcPkqUEvaEJuzOnAvnA2FJXW8 pUuc1tqDw0xTiidE6jOCBnoubw8nXjlvR3RnPik+ZT94AJrrC8qjvgkK+ l0p7DUyak4ijwWJdkG69z/k0cNM5EWTM9KzhJJFMFHHdsi8vlBSnu0C+R s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYCgDT/wpV/4UNJK1cgwaBLASDCcBdiC8CHIEwTAEBAQEBAX2EEAEBBCMRRRACAQgODAImAgICMBUQAgQBDQWIL7IunAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoQ+MweCaC+BFgEEjjuCDoltgRuPRoNHIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="133563352" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 19 Mar 2015 17:02:07 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2JH27q0032711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:02:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:02:06 -0500 From: "Joe Hildebrand (jhildebr)" To: Brian Trammell , Aaron Falk Thread-Topic: [Spud] discovery Thread-Index: AQHQYlwdY0g4PRrXtUWIpxnYDpPRSJ0kT9iA//+nhoA= Date: Thu, 19 Mar 2015 17:02:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <1A1EA83ED2D4AA46ADD15AD15E2DB444@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:02:12 -0000 T24gMy8xOS8xNSwgMTA6MTggQU0sICJCcmlhbiBUcmFtbWVsbCIgPGlldGZAdHJhbW1lbGwuY2g+ IHdyb3RlOg0KDQo+PmRvZXNuJ3Qgc2F5IG11Y2ggYWJvdXQgaG93IG9uZSBlZmZpY2llbnRseSBk ZXRlcm1pbmVzIHdoZXRoZXIgdGhlIG90aGVyIGVuZCBpcyBTUFVELWNhcGFibGUgc28gdGhhdCBh biBhcHBsaWNhdGlvbiBjYW4ga25vdyB3aGV0aGVyIGl0IGNhbiB1c2UgaXQuDQo+DQo+Tm8sIGl0 IGRvZXNuJ3QuDQo+DQo+PiBIYXMgYW55b25lIGdpdmVuIHRob3VnaHQgdG8gdGhpcz8NCj4NCj5Z ZXMsIEkgaGF2ZS4uLg0KPg0KPkkgdGhpbmsgZm9yIHRoZSBtb3N0IHBhcnQgdGhhdCB0aGlzIHF1 ZXN0aW9uIGlzICgxKSB2ZXJ5IGltcG9ydGFudCBidXQgKDIpIG1vc3RseSBvcnRob2dvbmFsIHRv IHRoYXQgd2UncmUgdHJ5aW5nIHRvIGFuc3dlciBpbiBzcHVkLXByb3RvdHlwZS4NCg0KQWdyZWUu DQoNCj5Jbml0aWFsbHksIEkgd291bGQgZXhwZWN0IHRoYXQgZGlzY292ZXJ5IHdvcmtzIHRoZSBz YW1lIHdheSB0aGF0IGl0IGRvZXMgZm9yIGFueSBvdGhlciB1c2VyIG9mIHRoZSB0cmFuc3BvcnQg bGF5ZXI6IHlvdSBlaXRoZXIgaGF2ZSBhIFVSTCwgb3IgYSBuYW1lIGFuZCBhIHBvcnQsIG9yIHNv bWUgaW5mb3JtYXRpb24gZnJvbSB5b3VyIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29sJ3MgZGlz Y292ZXJ5IHNlcnZpY2UsIHdoaWNoIGluY2x1ZGVzICJ1c2VzIHgtb3Zlci1TUFVEIiBpbiBpdHMg c2VtYW50aWNzLg0KDQpSRkMgMzI2MyBwcm92aWRlcyBhbiBleGlzdGVuY2UgcHJvb2YsIGJ1dCBw cm9iYWJseSBub3QgYSBkZXNpZ24gcGF0dGVybiB0byBmb2xsb3cuDQoNCi0tIA0KSm9lIEhpbGRl YnJhbmQNCg0KDQoNCg== From nobody Thu Mar 19 10:05:59 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803171A1EFF for ; Thu, 19 Mar 2015 10:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Mm1KlOQr72WW for ; Thu, 19 Mar 2015 10:05:57 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CEB1A1AFC for ; Thu, 19 Mar 2015 10:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1282; q=dns/txt; s=iport; t=1426784753; x=1427994353; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zv2dEMdlbJIffx13po5Rs/nMP8spD8mUuwuonBsPzcI=; b=CEgKIYE7U7016YnyVCnZHnEvGi/BWxWjAEyIJHcvQ1o1SC2pYY9gV/hX ZmCDSB0v5esvbXSGzWvcnpVSUPbN+lyQawJgcm+XJy+0Nhjs0TEZg6OFy 59z+XjRcPBmd95QMR2caA9Qx35LR+yErimboo7qld9/2pL+0tbMzCc8TZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUCgBVAQtV/4UNJK1cgwaBLASDCcBfiC8egTBMAQEBAQEBfYQQAgQjEVcBCBoCJgIEMBUSBAESiC+yMJwAAQEBAQEBBAEBAQEBAQEBGoEhiXaEPoMiL4EWBYYVijSJbZQoIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="405015925" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 19 Mar 2015 17:05:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2JH5q7Q002956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Mar 2015 17:05:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:05:52 -0500 From: "Joe Hildebrand (jhildebr)" To: "Pal Martinsen (palmarti)" , "spud@ietf.org" Thread-Topic: [Spud] Multipath UDP as a SPUD usecase? Thread-Index: AQHQYmb0I+k+DE334U20oTQe7OOZXA== Date: Thu, 19 Mar 2015 17:05:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Spud] Multipath UDP as a SPUD usecase? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:05:58 -0000 T24gMy8xOS8xNSwgOTo1NyBBTSwgIlBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSIgPHBhbG1hcnRp QGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5Bbm90aGVyIHBvdGVudGlhbCB1c2UtY2FzZSBTUFVEIGNv dWxkIGhlbHAgc29sdmUgaXMgbXVsdGlwYXRoIFVEUC4gSSBkbyBub3QgaGF2ZSBlbm91Z2ggaW5z aWdodCByZWdhcmRpbmcgYml0cyBvbiB0aGUgd2lyZSB0byBhY2NvbXBsaXNoIHRoaXMgYnV0IHRv IG1lIGl0IHdvdWxkIGJlIGEgY29tcGVsbGluZyB1c2VjYXNlLg0KPg0KPkl0IG1pZ2h0Og0KPiAg LSBQcm92aWRlIGVhc3kg4oCcbWVkaWEgbW9iaWxpdHnigJ0gd2hlbiBhIGRldmljZSBzd2l0Y2hl cyBuZXR3b3JrLg0KPiAgLSBCZXR0ZXIgdGhyb3VnaHB1dCAoTm90IHN1cmUgYWJvdXQgdGhpcy4u KQ0KPg0KPlNpbmNlIHdlIGFscmVhZHkgaGF2ZSB0aGlzIGZvciBUQ1AgYW5kIHRoZXJlIGlzIGEg bXVsdGktcGF0aCBSVFAgZHJhZnQgdGhlcmUgc2VlbXMgdG8gYmUgc29tZSBpbnRlcmVzdCBpbiBz b2x2aW5nIHRoaXMuDQoNClRoaXMgbWF5IGJlIG1vc3RseSBhbiBpc3N1ZSBmb3IgdGhlIHQnIGxh eWVyICh0JyA9ICJ0cmFuc3BvcnQgcHJpbWUiOyB0aGUgdHJhbnNwb3J0IHNlbWFudGljcyBpbnNp ZGUgb2YgU1BVRCksIHBhcnRpY3VsYXJseSBzaW5jZSB3ZSdyZSBsZWFuaW5nIHRvd2FyZCB0dWJl IElEJ3MgYmVpbmcgYm91bmQgdG8gYSA1LXR1cGxlLiAgVGhlIHQnIGNvZGUgd291bGQgY3JlYXRl IGEgbmV3IHR1YmUgKHByb2JhYmx5IHdpdGggYSBuZXcgdHViZSBJRCkgZm9yIGVhY2ggYWRkcmVz cyBwYWlyLiAgSW4gdGhlIGNhc2Ugb2YgbXB0Y3AnLCBldmVyeSB0aW1lIG1wdGNwIHdvdWxkIGhh dmUgc2VudCBhIG5ldyBTWU4sIG1wdGNwJyB3b3VsZCBzZW5kIGEgU1BVRCBPUEVOLg0KDQotLSAN CkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Thu Mar 19 10:17:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294A71A6EE9 for ; Thu, 19 Mar 2015 10:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3h0Af8SVSdNE for ; Thu, 19 Mar 2015 10:17:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD291A3BA6 for ; Thu, 19 Mar 2015 10:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1426785431; x=1427995031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9fnkhNenfDZEqSV0Veu030iJGdIw2lA10a2xlgqerkI=; b=Ba4hZDWr68UfPuCSarwl+5lPILzhCStRJd5lDJNY4JqSbURS2jQxMIz6 grYO2WBXLVymKiNNAI3J56NMdVNzdFUObEhhrCV8OHUJvMHjgL+HK8t3l 7Z+7OtzJwB8gbDJfOAQAWXkhpgV89SHInFAObxvD8kwVgpwqTAOaqGAck o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYCgA8AwtV/5pdJa1cgwaBLASDCcBfiC8CHIEwTAEBAQEBAX2EEAEBBCMRRRACAQgaAiYCAgIwFRACBAENBYgvsjacAAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hBklMweCaC+BFgEEkEmJbQGUJyKDbm8BgQFCfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="405372708" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2015 17:17:11 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2JHHA7G026975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:17:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:17:10 -0500 From: "Joe Hildebrand (jhildebr)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Pal Martinsen (palmarti)" , Carsten Bormann , Mike Jones , "Matt Miller (mamille2)" , Richard Barnes Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fqEUAgABEwYCAANXxgIADhomA//+2xAA= Date: Thu, 19 Mar 2015 17:17:10 +0000 Message-ID: References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> In-Reply-To: <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <8B184F6BE8B3414A9FC3CC396D625832@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Black, David" , "spud@ietf.org" Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:17:19 -0000 T24gMy8xOS8xNSwgOTozOCBBTSwgIk1pcmphIEvDvGhsZXdpbmQiIDxtaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCg0KPmp1c3QgYSBxdWljayB0aG91Z2ggb24gb3VyIGNv bW1lbnQgcmVnYXJkaW5nIGJhc2ljYWxseSDigJp3aHkgZG9lcyBEU0NQIG5vdCB3b3JrIGludGVy LWRvbWFpbuKAmC4gT25lIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIGlzIHRoYXQgaXMgaXQgbW9z dGx5IHVzZWQgaW50cmEtZG9tYWluIGFuZCB0aGF04oCZcyBva2F5LiBUaGF04oCZcyB3aHkgd2Ug bG9vayBhdCBTUFVEIGJlY2F1c2Ugd2UgYWN0dWFsbHkgd2hhdCBzb21ldGhpbmcgaW50ZXItZG9t YWluIChhdCBsZWFzdCB0byBzaWduYWwgaW5mb3JtYXRpb24gd2l0aG91dCBuZWdvdGlhdGlvbiku IFRoZXJlZm9yZSB0aGUgcXVlc3Rpb25zIGZvciBTUFVEIGFyZSBmb3IgbWU6DQo+DQo+LSBIb3cg Y2FuIHdlIGVuc3VyZSB0aGF0IGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBlbmQtcG9pbnQg ZG9lcyBub3QgZ2V0IG1vZGlmaWVkPw0KPg0KPmFuZCBtb3JlIGNvbXBsaWNhdGVkDQo+DQo+LSBI b3cgY2FuIHdlIGVuc3VyZSB0aGF0IGluZm9ybWF0aW9uIGEgbWlkZGxlYm94IHB1dHMgaW4gaXMg bm90ICh3cm9uZ2x5KSBtb2RpZmllZCBieSBhbm90aGVyIG1pZGRsZWJveCAoYXMgdGhlcmUgYXJl IGNhc2VzLCB3ZSB3ZSB3YW50IG9uZSBtaWRkbGVib3ggdG8gb3ZlcnJpZGUgZGF0YSBvZiBhbm90 aGVyIG1pZGRsZWJveOKApj8pDQoNCkknbSBDQydpbmcgaW4gc29tZSBwZW9wbGUgdGhhdCBJIGtu b3cgYXJlIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiAiQ09TRSIsIGEgcmVjb2Rpbmcgb2YgSk9T RSBpbnRvIENCT1IsIGJ1dCB3aG8gbWF5IG5vdCBiZSBzdWJzY3JpYmVkIHRvIHRoZSBTUFVEIGxp c3QuDQoNCk9uZSBhcHByb2FjaCB3ZSBjb3VsZCB0YWtlIGlzIGhhdmUgdGhlIGNsaWVudCBwdXQg YSAodHViZS1zcGVjaWZpYz8gdGltZS1saW1pdGVkPykgcHVibGljIGtleSBpbnRvIGVhY2ggT1BF TiBwYWNrZXQgaW4gYSBwYXRoLWFjY2Vzc2libGUgd2F5LiAgQXNzZXJ0aW9ucyBmcm9tIHRoZSBh cHBsaWNhdGlvbiBjb3VsZCBiZSBzaWduZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBwcml2YXRl IGtleSwgYXNzZXJ0aW9ucyBmcm9tIHRoZSBwYXRoIGNvdWxkIGJlIGVuY3J5cHRlZCB3aXRoIHRo ZSBwdWJsaWMga2V5LiAgDQoNCkknbSB3b3JyaWVkIGFib3V0IHRoZSBDUFUgb3ZlcmhlYWQgZm9y IG1pZGRsZWJveGVuLCBidXQgd2UgY291bGQgYm90aCBtYWtlIHRoaXMgb3B0aW9uYWwgaW4gdGhl IHByb3RvY29sIGFuZCByZXF1aXJlZC1ieS1kZWZhdWx0IGluIHRoZSBsaWJyYXJ5IHRvIHNlZSB3 aGF0IHRoZSBtYXJrZXQgc2hha2VzIG91dCBhcyB1c2UgY2FzZXMuDQoNCi0tIA0KSm9lIEhpbGRl YnJhbmQNCg0KDQoNCg== From nobody Thu Mar 19 11:01:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6B1A876B for ; Thu, 19 Mar 2015 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 76aT1hOdDmix for ; Thu, 19 Mar 2015 11:01:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F281A8743 for ; Thu, 19 Mar 2015 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=908; q=dns/txt; s=iport; t=1426788077; x=1427997677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uhzOcaBRPJiW5NJpNFmJ90KVbDhtKNWPsBGhwyCgf8s=; b=PlFDG/Qa8GjiMQaIZmIS2odMZKglsTSxLtE2EHDoqsIaO9nKc90E5AYa HqaE1/Zxhe+C3RH1Q/PG2c+3oOmF1KcAe3onJFU5yK1SHp0bOVDsP87yX Inda6Dqd4Xa9OItjWUyOG6VJqmPUf+DS5aq+18HyXutR/RGyeBJ1EqrgQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CyEgBaDgtV/4gNJK1cgwaBLASDCcBjiC8CHIExPBABAQEBAQEBfIQQAQEDASMRRQULAgEIDgwCJgICAjAVEAIEDgWIJwiyLJwCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaEGSUzB4JoL4EWAQSQTIltlCgig25vgQJCfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,431,1422921600"; d="scan'208";a="133482807" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 19 Mar 2015 18:01:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2JI1GlD015105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 18:01:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 13:01:16 -0500 From: "Joe Hildebrand (jhildebr)" To: Richard Barnes Thread-Topic: [Spud] Additional SPUD use-cases Thread-Index: AQHQX9ljbTPSFHtRgkqtPZO67VoMRZ0fqEUAgABEwYCAANXxgIADhomA//+2xACAAG/HAP//nOCA Date: Thu, 19 Mar 2015 18:01:15 +0000 Message-ID: <6E0B5FDA-326A-46E5-A833-D35D430A4953@cisco.com> References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , "spud@ietf.org" , Mike Jones , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Matt Miller \(mamille2\)" , Carsten Bormann Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:01:18 -0000 PiBPbmUgYXBwcm9hY2ggd2UgY291bGQgdGFrZSBpcyBoYXZlIHRoZSBjbGllbnQgcHV0IGEgKHR1 YmUtc3BlY2lmaWM/IHRpbWUtbGltaXRlZD8pIA0KPiBwdWJsaWMga2V5IGludG8gZWFjaCBPUEVO IHBhY2tldCBpbiBhIHBhdGgtYWNjZXNzaWJsZSB3YXkuICBBc3NlcnRpb25zIGZyb20gdGhlIA0K PiBhcHBsaWNhdGlvbiBjb3VsZCBiZSBzaWduZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBwcml2 YXRlIGtleSwgYXNzZXJ0aW9ucyBmcm9tIA0KPiB0aGUgcGF0aCBjb3VsZCBiZSBlbmNyeXB0ZWQg d2l0aCB0aGUgcHVibGljIGtleS4NCg0KT24gMy8xOS8xNSwgMTE6NTYgQU0sICJSaWNoYXJkIEJh cm5lcyIgPHJsYkBpcHYuc3g+IHdyb3RlOg0KDQo+SG9uZXN0bHksIHRoaXMgc2VlbXMgcXVpeG90 aWMuICBDYW4gd2UganVzdCBzcGVjaWZ5IHRoYXQgU1BVRCBoYXMgYSBzdGFjayBvZiBtZXNzYWdl cywgYW5kIGxlYXZlIGl0IGF0IHRoYXQ/DQoNCk5vZC4gIFBhcnRpY3VsYXJseSBpZiBTUFVEIGVu ZHMgdXAganVzdCBiZWluZyByZXF1aXJlbWVudHMgZm9yIERUTFMsIHRoZXJlJ3Mgbm8gcmVhc29u IHRvIGdvIGRvd24gdGhpcyBwYXRoLiAgSSd2ZSBnb3QgQ09TRSBvbiB0aGUgYnJhaW4gdG9kYXku IDopDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Thu Mar 19 11:02:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67D41A8907 for ; Thu, 19 Mar 2015 10:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Zt_w8tFNs0rx for ; Thu, 19 Mar 2015 10:56:04 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 CED7C1A88F6 for ; Thu, 19 Mar 2015 10:56:03 -0700 (PDT) Received: by ladw1 with SMTP id w1so68543313lad.0 for ; Thu, 19 Mar 2015 10:56:02 -0700 (PDT) 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:content-type; bh=gfckzfETLPxqPqPIO5bFQASWlpPoDwOd/mmRvR0gRm4=; b=WGkwuf/4Umm5GBsPOx0NmyPc5VccDDeLIdPijhhhd8EwPtwr5ZYaI/BtbYYSmZouTB XXMb0ioCaHB1Fq60yHL8RsuUe2o5u49EswvHPl1awZxhGltzecjFB+HuZq7NkVOWWOjL kc2inyUQLMDR6eS+8TcoVo2km8xwEsmfRy3bNGLTCZjon78P4SCiAsQpDxG94zvSZ5xY Rn6gVz1fQyKKBHWkRTiqIEjUFIuIpHCM/O5tnHiXiG3AfruEHMb6RwdZbK1mqXF79Ev2 CS8cS6oN1pWMFRpJzWXUE9meAqYmPu/+LjA4bDckj1bP89s/sXXFMsr+hVeRf7GIdnwa ogMw== X-Gm-Message-State: ALoCoQnzlCVrYbZDI9tpVwh+LeLS1raszXz6wERQP2UOQ8pl7uL6BE6DqGgvUFyamaJ9wjX8tHB9 MIME-Version: 1.0 X-Received: by 10.112.155.65 with SMTP id vu1mr40430068lbb.61.1426787762274; Thu, 19 Mar 2015 10:56:02 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 10:56:02 -0700 (PDT) In-Reply-To: References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> Date: Thu, 19 Mar 2015 13:56:02 -0400 Message-ID: From: Richard Barnes To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e01183042bd9d8d0511a7e92c Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 11:02:05 -0700 Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , "spud@ietf.org" , Mike Jones , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Matt Miller \(mamille2\)" , Carsten Bormann Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:56:11 -0000 --089e01183042bd9d8d0511a7e92c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Honestly, this seems quixotic. Can we just specify that SPUD has a stack of messages, and leave it at that? Since there's no authentication of the middleboxes, the endpoint can't tell the difference between a middlebox changing a value and just deleting it and replacing it, which it can still do in this scheme. You might think you could prevent middleboxes from seeing each others' messages, but since there's no authentication on the *endpoint* keys, a middlebox could just replace the key and send the messages on, then take things on the return path, snarf whatever messages it wants, and re-encrypt them to the real key. So there is very limited benefit here, if at all. On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 3/19/15, 9:38 AM, "Mirja K=C3=BChlewind" > wrote: > > >just a quick though on our comment regarding basically =E2=80=9Awhy does= DSCP not > work inter-domain=E2=80=98. One answer to this question is that is it mos= tly used > intra-domain and that=E2=80=99s okay. That=E2=80=99s why we look at SPUD = because we > actually what something inter-domain (at least to signal information > without negotiation). Therefore the questions for SPUD are for me: > > > >- How can we ensure that information provided by the end-point does not > get modified? > > > >and more complicated > > > >- How can we ensure that information a middlebox puts in is not (wrongly= ) > modified by another middlebox (as there are cases, we we want one middleb= ox > to override data of another middlebox=E2=80=A6?) > > I'm CC'ing in some people that I know are interested in working on "COSE"= , > a recoding of JOSE into CBOR, but who may not be subscribed to the SPUD > list. > > One approach we could take is have the client put a (tube-specific? > time-limited?) public key into each OPEN packet in a path-accessible way. > Assertions from the application could be signed with the corresponding > private key, assertions from the path could be encrypted with the public > key. > > I'm worried about the CPU overhead for middleboxen, but we could both mak= e > this optional in the protocol and required-by-default in the library to s= ee > what the market shakes out as use cases. > > -- > Joe Hildebrand > > > > --089e01183042bd9d8d0511a7e92c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Honestly, this seems quixotic.=C2=A0 Can we just= specify that SPUD has a stack of messages, and leave it at that?

Since there's no authentication of the middleboxes, the endpoint ca= n't tell the difference between a middlebox changing a value and just d= eleting it and replacing it, which it can still do in this scheme.=C2=A0
You might think you could prevent middleboxes from seeing each others= ' messages, but since there's no authentication on the *endpoint* k= eys, a middlebox could just replace the key and send the messages on, then = take things on the return path, snarf whatever messages it wants, and re-en= crypt them to the real key.

So there is very limited benefit h= ere, if at all.

On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) <jhild= ebr@cisco.com> wrote:
On 3/= 19/15, 9:38 AM, "Mirja K=C3=BChlewind" <mirja.kuehlewind@tik.ee.ethz.ch> wrote:=

>just a quick though on our comment regarding basically =E2=80=9Awhy doe= s DSCP not work inter-domain=E2=80=98. One answer to this question is that = is it mostly used intra-domain and that=E2=80=99s okay. That=E2=80=99s why = we look at SPUD because we actually what something inter-domain (at least t= o signal information without negotiation). Therefore the questions for SPUD= are for me:
>
>- How can we ensure that information provided by the end-point does not= get modified?
>
>and more complicated
>
>- How can we ensure that information a middlebox puts in is not (wrongl= y) modified by another middlebox (as there are cases, we we want one middle= box to override data of another middlebox=E2=80=A6?)

I'm CC'ing in some people that I know are interested in working on = "COSE", a recoding of JOSE into CBOR, but who may not be subscrib= ed to the SPUD list.

One approach we could take is have the client put a (tube-specific? time-li= mited?) public key into each OPEN packet in a path-accessible way.=C2=A0 As= sertions from the application could be signed with the corresponding privat= e key, assertions from the path could be encrypted with the public key.

I'm worried about the CPU overhead for middleboxen, but we could both m= ake this optional in the protocol and required-by-default in the library to= see what the market shakes out as use cases.

--
Joe Hildebrand




--089e01183042bd9d8d0511a7e92c-- From nobody Thu Mar 19 11:09:22 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA811A8A45 for ; Thu, 19 Mar 2015 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YsEC0iZ_Hjup for ; Thu, 19 Mar 2015 11:09:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0E01A8935 for ; Thu, 19 Mar 2015 11:09:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6E7C1D9305; Thu, 19 Mar 2015 19:09:15 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8K6z3dqAqFr7; Thu, 19 Mar 2015 19:09:15 +0100 (MET) Received: from 172-27-222-211.dynapool.nyu.edu (NYUFWA-BORDERNAT-GUEST-02.NET.NYU.EDU [192.76.177.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 36509D9304; Thu, 19 Mar 2015 19:09:14 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 19 Mar 2015 14:09:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <57464AD5-C804-4D94-B81A-842FAEF1A27A@tik.ee.ethz.ch> References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> To: Richard Barnes X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , "spud@ietf.org" , Mike Jones , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Carsten Bormann Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:09:19 -0000 Okay, the question is than rather, how can we avoid that non-spud-aware = middleboxes accidentally modify spud information which can hinder spud = deployment is the same way other approaches failed=E2=80=A6? I think we = should at least be somehow able to detect these kind of unintentional = modifications. Mirja > Am 19.03.2015 um 13:56 schrieb Richard Barnes : >=20 > Honestly, this seems quixotic. Can we just specify that SPUD has a = stack of messages, and leave it at that? >=20 > Since there's no authentication of the middleboxes, the endpoint can't = tell the difference between a middlebox changing a value and just = deleting it and replacing it, which it can still do in this scheme. =20 >=20 > You might think you could prevent middleboxes from seeing each others' = messages, but since there's no authentication on the *endpoint* keys, a = middlebox could just replace the key and send the messages on, then take = things on the return path, snarf whatever messages it wants, and = re-encrypt them to the real key. >=20 > So there is very limited benefit here, if at all. >=20 > On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) = wrote: > On 3/19/15, 9:38 AM, "Mirja K=C3=BChlewind" = wrote: >=20 > >just a quick though on our comment regarding basically =E2=80=9Awhy = does DSCP not work inter-domain=E2=80=98. One answer to this question is = that is it mostly used intra-domain and that=E2=80=99s okay. That=E2=80=99= s why we look at SPUD because we actually what something inter-domain = (at least to signal information without negotiation). Therefore the = questions for SPUD are for me: > > > >- How can we ensure that information provided by the end-point does = not get modified? > > > >and more complicated > > > >- How can we ensure that information a middlebox puts in is not = (wrongly) modified by another middlebox (as there are cases, we we want = one middlebox to override data of another middlebox=E2=80=A6?) >=20 > I'm CC'ing in some people that I know are interested in working on = "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to = the SPUD list. >=20 > One approach we could take is have the client put a (tube-specific? = time-limited?) public key into each OPEN packet in a path-accessible = way. Assertions from the application could be signed with the = corresponding private key, assertions from the path could be encrypted = with the public key. >=20 > I'm worried about the CPU overhead for middleboxen, but we could both = make this optional in the protocol and required-by-default in the = library to see what the market shakes out as use cases. >=20 > -- > Joe Hildebrand >=20 >=20 >=20 >=20 From nobody Thu Mar 19 12:03:58 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64041A878A for ; Thu, 19 Mar 2015 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 jFyoBXsUMjFf for ; Thu, 19 Mar 2015 12:03:55 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 43D041A8742 for ; Thu, 19 Mar 2015 12:03:55 -0700 (PDT) Received: by labjg1 with SMTP id jg1so70011430lab.2 for ; Thu, 19 Mar 2015 12:03:53 -0700 (PDT) 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:content-type; bh=aJmvJlv26Si3vj4/05foVGDodD010QoYAmb6i4yLngo=; b=A9u+yl0hfS40qx1GvZFSH9/c04cH2OLxvnyu8EJzPksXMNOuMAqWRRlH6f9PC85Qxz irFdalNj4HxjS0WNa5MoM/iY11a1uBlkVem0iect8eK+eTz8kbEkSUQmmIN6IItWD7Ac MvJJzGc62PoFLqLWMm0qdPSe+fgb6OWKRFyZOLlklV9tUSC0R31LKWTP1eM34vFayLrJ N1lY0aJCaGz16YeqflJ5R6QjNAkZ5HkP9aAknfsfLv+R0ZivI9Niv9PJZCDrVXjU2yyg WczeIzHyMZS+8YyRQVlAupZbQF/OlQxZ1NTOaPg3sMgMBqEpOn+nUgxRG+fUWO1jHbmn qcMw== X-Gm-Message-State: ALoCoQnxRSCh3h6aGGXmPrKNWST06LvUZUG9SxFXZTn1hOPi1uuBFKRvl1lGVAIfU24m2o+EHdxM MIME-Version: 1.0 X-Received: by 10.112.98.201 with SMTP id ek9mr70299309lbb.68.1426791833669; Thu, 19 Mar 2015 12:03:53 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 12:03:53 -0700 (PDT) In-Reply-To: <57464AD5-C804-4D94-B81A-842FAEF1A27A@tik.ee.ethz.ch> References: <73D46BA8-DB33-481F-B0FB-DDD3B1F0F7FB@cisco.com> <16D94942-1D53-4F7B-8098-29B52781EDA0@tik.ee.ethz.ch> <57464AD5-C804-4D94-B81A-842FAEF1A27A@tik.ee.ethz.ch> Date: Thu, 19 Mar 2015 15:03:53 -0400 Message-ID: From: Richard Barnes To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a11345c8c6a2af70511a8dc32 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "Black, David" , "spud@ietf.org" , Mike Jones , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Carsten Bormann Subject: Re: [Spud] Additional SPUD use-cases X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:03:57 -0000 --001a11345c8c6a2af70511a8dc32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see. That's a different question. Seems like some sort of basic consistency check / checksum would be sufficient? On Thu, Mar 19, 2015 at 2:09 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Okay, the question is than rather, how can we avoid that non-spud-aware > middleboxes accidentally modify spud information which can hinder spud > deployment is the same way other approaches failed=E2=80=A6? I think we s= hould at > least be somehow able to detect these kind of unintentional modifications= . > > Mirja > > > > Am 19.03.2015 um 13:56 schrieb Richard Barnes : > > > > Honestly, this seems quixotic. Can we just specify that SPUD has a > stack of messages, and leave it at that? > > > > Since there's no authentication of the middleboxes, the endpoint can't > tell the difference between a middlebox changing a value and just deletin= g > it and replacing it, which it can still do in this scheme. > > > > You might think you could prevent middleboxes from seeing each others' > messages, but since there's no authentication on the *endpoint* keys, a > middlebox could just replace the key and send the messages on, then take > things on the return path, snarf whatever messages it wants, and re-encry= pt > them to the real key. > > > > So there is very limited benefit here, if at all. > > > > On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > > On 3/19/15, 9:38 AM, "Mirja K=C3=BChlewind" > wrote: > > > > >just a quick though on our comment regarding basically =E2=80=9Awhy do= es DSCP > not work inter-domain=E2=80=98. One answer to this question is that is it= mostly > used intra-domain and that=E2=80=99s okay. That=E2=80=99s why we look at = SPUD because we > actually what something inter-domain (at least to signal information > without negotiation). Therefore the questions for SPUD are for me: > > > > > >- How can we ensure that information provided by the end-point does no= t > get modified? > > > > > >and more complicated > > > > > >- How can we ensure that information a middlebox puts in is not > (wrongly) modified by another middlebox (as there are cases, we we want o= ne > middlebox to override data of another middlebox=E2=80=A6?) > > > > I'm CC'ing in some people that I know are interested in working on > "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to th= e > SPUD list. > > > > One approach we could take is have the client put a (tube-specific? > time-limited?) public key into each OPEN packet in a path-accessible way. > Assertions from the application could be signed with the corresponding > private key, assertions from the path could be encrypted with the public > key. > > > > I'm worried about the CPU overhead for middleboxen, but we could both > make this optional in the protocol and required-by-default in the library > to see what the market shakes out as use cases. > > > > -- > > Joe Hildebrand > > > > > > > > > > --001a11345c8c6a2af70511a8dc32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see.=C2=A0 That's a different question.=C2=A0 Seems = like some sort of basic consistency check / checksum would be sufficient?

On Thu, M= ar 19, 2015 at 2:09 PM, Mirja K=C3=BChlewind <mirja.kuehlew= ind@tik.ee.ethz.ch> wrote:
= Okay, the question is than rather, how can we avoid that non-spud-aware mid= dleboxes accidentally modify spud information which can hinder spud deploym= ent is the same way other approaches failed=E2=80=A6? I think we should at = least be somehow able to detect these kind of unintentional modifications.<= br>
Mirja


> Am 19.03.2015 um 13:56 schrieb Richard Barnes <rlb@ipv.sx>:
>
> Honestly, this seems quixotic.=C2=A0 Can we just specify that SPUD has= a stack of messages, and leave it at that?
>
> Since there's no authentication of the middleboxes, the endpoint c= an't tell the difference between a middlebox changing a value and just = deleting it and replacing it, which it can still do in this scheme.
>
> You might think you could prevent middleboxes from seeing each others&= #39; messages, but since there's no authentication on the *endpoint* ke= ys, a middlebox could just replace the key and send the messages on, then t= ake things on the return path, snarf whatever messages it wants, and re-enc= rypt them to the real key.
>
> So there is very limited benefit here, if at all.
>
> On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
> On 3/19/15, 9:38 AM, "Mirja K=C3=BChlewind" <mirja.kuehlewind@tik.ee.ethz.ch&= gt; wrote:
>
> >just a quick though on our comment regarding basically =E2=80=9Awh= y does DSCP not work inter-domain=E2=80=98. One answer to this question is = that is it mostly used intra-domain and that=E2=80=99s okay. That=E2=80=99s= why we look at SPUD because we actually what something inter-domain (at le= ast to signal information without negotiation). Therefore the questions for= SPUD are for me:
> >
> >- How can we ensure that information provided by the end-point doe= s not get modified?
> >
> >and more complicated
> >
> >- How can we ensure that information a middlebox puts in is not (w= rongly) modified by another middlebox (as there are cases, we we want one m= iddlebox to override data of another middlebox=E2=80=A6?)
>
> I'm CC'ing in some people that I know are interested in workin= g on "COSE", a recoding of JOSE into CBOR, but who may not be sub= scribed to the SPUD list.
>
> One approach we could take is have the client put a (tube-specific? ti= me-limited?) public key into each OPEN packet in a path-accessible way.=C2= =A0 Assertions from the application could be signed with the corresponding = private key, assertions from the path could be encrypted with the public ke= y.
>
> I'm worried about the CPU overhead for middleboxen, but we could b= oth make this optional in the protocol and required-by-default in the libra= ry to see what the market shakes out as use cases.
>
> --
> Joe Hildebrand
>
>
>
>


--001a11345c8c6a2af70511a8dc32-- From nobody Thu Mar 19 13:27:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AD1A905F for ; Thu, 19 Mar 2015 13:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zlcdnjqWJnCQ for ; Thu, 19 Mar 2015 13:27:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DBB1A9064 for ; Thu, 19 Mar 2015 13:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1726; q=dns/txt; s=iport; t=1426796871; x=1428006471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WJzHZNvGEXBeGrPVc0pZOpnUBZ2V7Q/rR8t4yLfndtY=; b=Ojs6loG1/FX0CFI5ttB9/6TY/GvehFC0mFAB6XgqtwteLxV9DRHyDKEm zpKt2BKraVlhJLetXL+Z0rTG6JNjn0ioTA94KVa3xF6K0I0cRC9j3Jkxp vzy7DzBU+OuQeOVul70OVv1CyvWdf/yNaSrPHlXieCLkjahN0nldpi43u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQA5MAtV/40NJK1cgwaBIAwEgwnJGAIcgStMAQEBAQEBfYQPAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRACBA4FiCcIsjacBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hHEHgmgvgRYBBIYXijWJbZQoIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,432,1422921600"; d="scan'208";a="405030994" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2015 20:27:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2JKRor6007517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Mar 2015 20:27:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 15:27:50 -0500 From: "Pal Martinsen (palmarti)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [Spud] Multipath UDP as a SPUD usecase? Thread-Index: AQHQYmb0I+k+DE334U20oTQe7OOZXJ0klVoA Date: Thu, 19 Mar 2015 20:27:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.223.36] Content-Type: text/plain; charset="utf-8" Content-ID: <5EF7E0714FE77546B7293954E04A09E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Multipath UDP as a SPUD usecase? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:27:52 -0000 DQo+IE9uIDE5IE1hciAyMDE1LCBhdCAxODowNSwgSm9lIEhpbGRlYnJhbmQgKGpoaWxkZWJyKSA8 amhpbGRlYnJAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IE9uIDMvMTkvMTUsIDk6NTcgQU0sICJQ YWwgTWFydGluc2VuIChwYWxtYXJ0aSkiIDxwYWxtYXJ0aUBjaXNjby5jb20+IHdyb3RlOg0KPiAN Cj4+IEFub3RoZXIgcG90ZW50aWFsIHVzZS1jYXNlIFNQVUQgY291bGQgaGVscCBzb2x2ZSBpcyBt dWx0aXBhdGggVURQLiBJIGRvIG5vdCBoYXZlIGVub3VnaCBpbnNpZ2h0IHJlZ2FyZGluZyBiaXRz IG9uIHRoZSB3aXJlIHRvIGFjY29tcGxpc2ggdGhpcyBidXQgdG8gbWUgaXQgd291bGQgYmUgYSBj b21wZWxsaW5nIHVzZWNhc2UuDQo+PiANCj4+IEl0IG1pZ2h0Og0KPj4gLSBQcm92aWRlIGVhc3kg 4oCcbWVkaWEgbW9iaWxpdHnigJ0gd2hlbiBhIGRldmljZSBzd2l0Y2hlcyBuZXR3b3JrLg0KPj4g LSBCZXR0ZXIgdGhyb3VnaHB1dCAoTm90IHN1cmUgYWJvdXQgdGhpcy4uKQ0KPj4gDQo+PiBTaW5j ZSB3ZSBhbHJlYWR5IGhhdmUgdGhpcyBmb3IgVENQIGFuZCB0aGVyZSBpcyBhIG11bHRpLXBhdGgg UlRQIGRyYWZ0IHRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgaW50ZXJlc3QgaW4gc29sdmluZyB0aGlz Lg0KPiANCj4gVGhpcyBtYXkgYmUgbW9zdGx5IGFuIGlzc3VlIGZvciB0aGUgdCcgbGF5ZXIgKHQn ID0gInRyYW5zcG9ydCBwcmltZSI7IHRoZSB0cmFuc3BvcnQgc2VtYW50aWNzIGluc2lkZSBvZiBT UFVEKSwgcGFydGljdWxhcmx5IHNpbmNlIHdlJ3JlIGxlYW5pbmcgdG93YXJkIHR1YmUgSUQncyBi ZWluZyBib3VuZCB0byBhIDUtdHVwbGUuICBUaGUgdCcgY29kZSB3b3VsZCBjcmVhdGUgYSBuZXcg dHViZSAocHJvYmFibHkgd2l0aCBhIG5ldyB0dWJlIElEKSBmb3IgZWFjaCBhZGRyZXNzIHBhaXIu ICBJbiB0aGUgY2FzZSBvZiBtcHRjcOKAmSwgZXZlcnkgdGltZSBtcHRjcCB3b3VsZCBoYXZlIHNl bnQgYSBuZXcgU1lOLCBtcHRjcCcgd291bGQgc2VuZCBhIFNQVUQgT1BFTi4NCj4gDQpUaGF0IG1h a2Ugc2Vuc2UuIEFzIGxvbmcgYXMgd2Ugbm90IGRlY2lkZSBvbiBhbnl0aGluIHRoYXQgbWFrZSB0 aGlzIGhhcmQvaW1wb3NzaWJsZSBJIGFtIGhhcHB5Lk5vdCBldmVuIHN1cmUgaWYgdGhpcyBiZWxv bmdzIHRvIHRoZSBjb3JlIHNwZWMsIG1heWJlIGJldHRlciBzdWl0ZWQgYXMgYSBleHRlbnNpb24/ DQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KPiAtLSANCj4gSm9lIEhpbGRlYnJhbmQNCj4gDQo+IA0K PiANCg0K From nobody Thu Mar 19 13:32:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03281A9072 for ; Thu, 19 Mar 2015 13:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sO_7WDKEerKK for ; Thu, 19 Mar 2015 13:32:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71451A9067 for ; Thu, 19 Mar 2015 13:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1426797143; x=1428006743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eM3SbRBTUhUU5wXL7GvolktQmj8rzK4n10XrjqjDRq0=; b=aofbsZvXmQm88x8y+nV2DdmZuZh8A+2t45VKc0LA1p7jmJVU3BTX/XZ5 yj4hFQJCfHlkJ7i67kxvmwLzQ39pGxn35TNwzjS9Sk+xULsWEf+K93Qq2 87b5it0JnOdguFFfxsVlTKz0ZirigH6QxBQw1SR0arUqVH9F4cc30+pX4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApDwAPMQtV/4wNJK1cgwaBIAwEgwnAaYgvAhyBK0wBAQEBAQF9hBABAQQjEUUQAgEIGgImAgICMBUQAgQOBYgvsjecBAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hHEHgmgvgRYBBJBMiW2UKCKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,432,1422921600"; d="scan'208";a="405144150" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 19 Mar 2015 20:32:22 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2JKWMBb018855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Mar 2015 20:32:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 15:32:21 -0500 From: "Joe Hildebrand (jhildebr)" To: "Pal Martinsen (palmarti)" Thread-Topic: [Spud] Multipath UDP as a SPUD usecase? Thread-Index: AQHQYmb0I+k+DE334U20oTQe7OOZXJ0klVoA//+croA= Date: Thu, 19 Mar 2015 20:32:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.1.150311 x-originating-ip: [10.24.165.130] Content-Type: text/plain; charset="utf-8" Content-ID: <09EEAF712EBC26429422D629EB56274E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Multipath UDP as a SPUD usecase? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:32:24 -0000 T24gMy8xOS8xNSwgMjoyNyBQTSwgIlBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSIgPHBhbG1hcnRp QGNpc2NvLmNvbT4gd3JvdGU6DQoNCj4+IA0KPj4gVGhpcyBtYXkgYmUgbW9zdGx5IGFuIGlzc3Vl IGZvciB0aGUgdCcgbGF5ZXIgKHQnID0gInRyYW5zcG9ydCBwcmltZSI7IHRoZSB0cmFuc3BvcnQg c2VtYW50aWNzIGluc2lkZSBvZiBTUFVEKSwgcGFydGljdWxhcmx5IHNpbmNlIHdlJ3JlIGxlYW5p bmcgdG93YXJkIHR1YmUgSUQncyBiZWluZyBib3VuZCB0byBhIDUtdHVwbGUuICBUaGUgdCcgY29k ZSB3b3VsZCBjcmVhdGUgYSBuZXcgdHViZSAocHJvYmFibHkgd2l0aCBhIG5ldyB0dWJlIElEKSBm b3IgZWFjaCBhZGRyZXNzIHBhaXIuICBJbiB0aGUgY2FzZSBvZiBtcHRjcOKAmSwgZXZlcnkgdGlt ZSBtcHRjcCB3b3VsZCBoYXZlIHNlbnQgYSBuZXcgU1lOLCBtcHRjcCcgd291bGQgc2VuZCBhIFNQ VUQgT1BFTi4NCj4+IA0KPlRoYXQgbWFrZSBzZW5zZS4gQXMgbG9uZyBhcyB3ZSBub3QgZGVjaWRl IG9uIGFueXRoaW4gdGhhdCBtYWtlIHRoaXMgaGFyZC9pbXBvc3NpYmxlIEkgYW0gaGFwcHkuTm90 IGV2ZW4gc3VyZSBpZiB0aGlzIGJlbG9uZ3MgdG8gdGhlIGNvcmUgc3BlYywgbWF5YmUgYmV0dGVy IHN1aXRlZCBhcyBhIGV4dGVuc2lvbj8NCg0KSSB0aGluayB3ZSdsbCBsZWFybiBhIGxvdCBtb3Jl IGFzIHdlIGdldCBhIG1wdGNwJyBpbXBsZW1lbnRhdGlvbiBzdGFydGVkLiAgTXkgZ3V0IGZlZWwg aXMgdGhhdCB3ZSBqdXN0IG5lZWQgYSBleHRyYSBwYXJhZ3JhcGggaW4gdGhlIHNwZWMgdGhhdCBz YXlzIHdoYXQgdGhlIHNjb3BlIG9mIGEgdHViZSBJRCBpcywgYW5kIHdoZW4gdG8gc3RhcnQgYSBu ZXcgdHViZS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Thu Mar 19 16:22:01 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303A71A0231 for ; Thu, 19 Mar 2015 16:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9EzZ42CqqFmx for ; Thu, 19 Mar 2015 16:21:57 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 C06BE1A00D4 for ; Thu, 19 Mar 2015 16:21:11 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YYjkS-0006CX-S2; Fri, 20 Mar 2015 00:21:08 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1YYjkS-0002gE-9P; Fri, 20 Mar 2015 00:21:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Fri, 20 Mar 2015 00:21:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Trammell X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 4 total rcpts 26595 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 116590568C914FE80307AB9B2DEA96B6AE321D31 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 457 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 23:21:59 -0000 > On 19. mar. 2015, at 17.18, Brian Trammell wrote: >=20 > hi Aaron, >=20 >> On 19 Mar 2015, at 11:48, Aaron Falk wrote: >>=20 >> The draft >=20 > ... where "the draft" is draft-hildebrand-spud-prototype ... >=20 >> doesn't say much about how one efficiently determines whether the = other end is SPUD-capable so that an application can know whether it can = use it. >=20 > No, it doesn't. >=20 >> Has anyone given thought to this? >=20 > Yes, I have... >=20 > I think for the most part that this question is (1) very important but = (2) mostly orthogonal to that we're trying to answer in spud-prototype. >=20 > Initially, I would expect that discovery works the same way that it = does for any other user of the transport layer: you either have a URL, = or a name and a port, or some information from your application-layer = protocol's discovery service, which includes "uses x-over-SPUD" in its = semantics. >=20 > Dynamically discovering a SPUD endpoint might make sense if a server = port / URL schema is assigned to a service over X or a service over = x-over-SPUD. In this case, the magic number we've selected makes SPUD = server probing by the client possible: a SPUD packet is neither valid = UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or = Bittorrent. This is not an exhaustive list, but we haven't found a = protocol over UDP that is likely to consider d8 00 00 d8 as the first = four bytes anything other than an error. - but that won't tell you if SPUD actually does work across the path... > Maybe we should mention this in the draft, but I think it's the *next* = problem to solve. to me, this has a "famous last words" feel to it... Cheers, Michael From nobody Thu Mar 19 19:01:18 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6455B1A912F for ; Thu, 19 Mar 2015 19:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 f1fdKzhH5Zag for ; Thu, 19 Mar 2015 19:01:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3386B1A9129 for ; Thu, 19 Mar 2015 19:01:15 -0700 (PDT) Received: from [10.120.1.181] (rrcs-184-75-115-252.nyc.biz.rr.com [184.75.115.252]) by trammell.ch (Postfix) with ESMTPSA id AE9991A01AC; Fri, 20 Mar 2015 03:00:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Trammell In-Reply-To: Date: Thu, 19 Mar 2015 22:00:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8996D749-9936-4BB3-B494-08556CE8D41C@trammell.ch> References: To: Michael Welzl X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Aaron Falk , "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 02:01:17 -0000 > On 19 Mar 2015, at 19:21, Michael Welzl wrote: >=20 >=20 >> On 19. mar. 2015, at 17.18, Brian Trammell wrote: >>=20 >> hi Aaron, >>=20 >>> On 19 Mar 2015, at 11:48, Aaron Falk wrote: >>>=20 >>> The draft >>=20 >> ... where "the draft" is draft-hildebrand-spud-prototype ... >>=20 >>> doesn't say much about how one efficiently determines whether the = other end is SPUD-capable so that an application can know whether it can = use it. >>=20 >> No, it doesn't. >>=20 >>> Has anyone given thought to this? >>=20 >> Yes, I have... >>=20 >> I think for the most part that this question is (1) very important = but (2) mostly orthogonal to that we're trying to answer in = spud-prototype. >>=20 >> Initially, I would expect that discovery works the same way that it = does for any other user of the transport layer: you either have a URL, = or a name and a port, or some information from your application-layer = protocol's discovery service, which includes "uses x-over-SPUD" in its = semantics. >>=20 >> Dynamically discovering a SPUD endpoint might make sense if a server = port / URL schema is assigned to a service over X or a service over = x-over-SPUD. In this case, the magic number we've selected makes SPUD = server probing by the client possible: a SPUD packet is neither valid = UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or = Bittorrent. This is not an exhaustive list, but we haven't found a = protocol over UDP that is likely to consider d8 00 00 d8 as the first = four bytes anything other than an error. >=20 > - but that won't tell you if SPUD actually does work across the = path... True. But discovery (is there an endpoint there?) is a separate question = from path transparency (once you've found the endpoint, can you actually = talk to it?) This would be an argument for specifying a dynamic discovery method, = though -- not for determining whether you should use SPUD, but whether = you can. Cheers, Brian >> Maybe we should mention this in the draft, but I think it's the = *next* problem to solve. >=20 > to me, this has a "famous last words" feel to it... >=20 > Cheers, > Michael >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Mar 20 01:20:01 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786581B2C75 for ; Fri, 20 Mar 2015 01:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B1X-gYlZ1tcu for ; Fri, 20 Mar 2015 01:19:55 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 E32F91B2C72 for ; Fri, 20 Mar 2015 01:19:54 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YYs9o-0006lD-Nd; Fri, 20 Mar 2015 09:19:52 +0100 Received: from mail-ex13.exprod.uio.no ([129.240.120.75]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YYs9o-0000UB-4i; Fri, 20 Mar 2015 09:19:52 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex13.exprod.uio.no (2001:700:100:120::75) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Mar 2015 09:19:51 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Fri, 20 Mar 2015 09:19:51 +0100 From: Michael Welzl To: Brian Trammell Thread-Topic: [Spud] discovery Thread-Index: AQHQYuaikdm5b2wk00WGXC5oI03XxQ== Date: Fri, 20 Mar 2015 08:19:50 +0000 Message-ID: <7D4541ED-80A7-4C53-9386-58E755BF8375@ifi.uio.no> References: <8996D749-9936-4BB3-B494-08556CE8D41C@trammell.ch> In-Reply-To: <8996D749-9936-4BB3-B494-08556CE8D41C@trammell.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <15628D193FD2BB4CB21DEF2719CCFEDE@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 26601 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 82561F8EB4BB63036F3738314272DB696254CC67 X-UiO-SPAM-Test: remote_host: 129.240.120.75 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 79 total 653076 max/h 493 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 08:20:00 -0000 > On 20 Mar 2015, at 03:00, Brian Trammell wrote: >=20 >>=20 >> On 19 Mar 2015, at 19:21, Michael Welzl wrote: >>=20 >>=20 >>> On 19. mar. 2015, at 17.18, Brian Trammell wrote: >>>=20 >>> hi Aaron, >>>=20 >>>> On 19 Mar 2015, at 11:48, Aaron Falk wrote: >>>>=20 >>>> The draft >>>=20 >>> ... where "the draft" is draft-hildebrand-spud-prototype ... >>>=20 >>>> doesn't say much about how one efficiently determines whether the othe= r end is SPUD-capable so that an application can know whether it can use it= . >>>=20 >>> No, it doesn't. >>>=20 >>>> Has anyone given thought to this? >>>=20 >>> Yes, I have... >>>=20 >>> I think for the most part that this question is (1) very important but = (2) mostly orthogonal to that we're trying to answer in spud-prototype. >>>=20 >>> Initially, I would expect that discovery works the same way that it doe= s for any other user of the transport layer: you either have a URL, or a na= me and a port, or some information from your application-layer protocol's d= iscovery service, which includes "uses x-over-SPUD" in its semantics. >>>=20 >>> Dynamically discovering a SPUD endpoint might make sense if a server po= rt / URL schema is assigned to a service over X or a service over x-over-SP= UD. In this case, the magic number we've selected makes SPUD server probing= by the client possible: a SPUD packet is neither valid UTF-8, UTF-16, UTF-= 32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or Bittorrent. This is no= t an exhaustive list, but we haven't found a protocol over UDP that is like= ly to consider d8 00 00 d8 as the first four bytes anything other than an e= rror. >>=20 >> - but that won't tell you if SPUD actually does work across the path... >=20 > True. But discovery (is there an endpoint there?) is a separate question = from path transparency (once you've found the endpoint, can you actually ta= lk to it?) Not entirely I think - see below: > This would be an argument for specifying a dynamic discovery method, thou= gh -- not for determining whether you should use SPUD, but whether you can. So I think, as much as some folks seem to hate it, there really isn't a way= around happy-eyeballing... the reason I say it's not entirely separate ifrom discovery s that happy ey= eballs can check availability both on the path and the other end in one go.= However, having a separate method that really only deals with the other en= d can limit how much happy eyeballing one needs to do (i.e.: no point even = trying SPUD if the other side doesn't use it). Cheers, Michael From nobody Fri Mar 20 04:47:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA21B2CAB for ; Fri, 20 Mar 2015 04:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e-1XrKRtmkTN for ; Fri, 20 Mar 2015 04:47:05 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD31A8973 for ; Fri, 20 Mar 2015 04:47:04 -0700 (PDT) Received: from [10.120.1.181] (rrcs-184-75-115-252.nyc.biz.rr.com [184.75.115.252]) by trammell.ch (Postfix) with ESMTPSA id 4FE761A0111; Fri, 20 Mar 2015 12:47:03 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Trammell In-Reply-To: <7D4541ED-80A7-4C53-9386-58E755BF8375@ifi.uio.no> Date: Fri, 20 Mar 2015 07:47:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8996D749-9936-4BB3-B494-08556CE8D41C@trammell.ch> <7D4541ED-80A7-4C53-9386-58E755BF8375@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Aaron Falk , "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 11:47:07 -0000 > On 20 Mar 2015, at 04:19, Michael Welzl wrote: >=20 >=20 >> On 20 Mar 2015, at 03:00, Brian Trammell wrote: >>=20 >>>=20 >>> On 19 Mar 2015, at 19:21, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 19. mar. 2015, at 17.18, Brian Trammell = wrote: >>>>=20 >>>> hi Aaron, >>>>=20 >>>>> On 19 Mar 2015, at 11:48, Aaron Falk wrote: >>>>>=20 >>>>> The draft >>>>=20 >>>> ... where "the draft" is draft-hildebrand-spud-prototype ... >>>>=20 >>>>> doesn't say much about how one efficiently determines whether the = other end is SPUD-capable so that an application can know whether it can = use it. >>>>=20 >>>> No, it doesn't. >>>>=20 >>>>> Has anyone given thought to this? >>>>=20 >>>> Yes, I have... >>>>=20 >>>> I think for the most part that this question is (1) very important = but (2) mostly orthogonal to that we're trying to answer in = spud-prototype. >>>>=20 >>>> Initially, I would expect that discovery works the same way that it = does for any other user of the transport layer: you either have a URL, = or a name and a port, or some information from your application-layer = protocol's discovery service, which includes "uses x-over-SPUD" in its = semantics. >>>>=20 >>>> Dynamically discovering a SPUD endpoint might make sense if a = server port / URL schema is assigned to a service over X or a service = over x-over-SPUD. In this case, the magic number we've selected makes = SPUD server probing by the client possible: a SPUD packet is neither = valid UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, = TFTP, or Bittorrent. This is not an exhaustive list, but we haven't = found a protocol over UDP that is likely to consider d8 00 00 d8 as the = first four bytes anything other than an error. >>>=20 >>> - but that won't tell you if SPUD actually does work across the = path... >>=20 >> True. But discovery (is there an endpoint there?) is a separate = question from path transparency (once you've found the endpoint, can you = actually talk to it?) >=20 > Not entirely I think - see below: The questions are absolutely separate. The way you answer them, not = necessarily. >> This would be an argument for specifying a dynamic discovery method, = though -- not for determining whether you should use SPUD, but whether = you can. >=20 > So I think, as much as some folks seem to hate it, there really isn't = a way around happy-eyeballing... In general, I don't disagree with this -- let me rephrase it to make = sure we're saying the same thing: "Dynamic discovery mechanisms are necessary at both endpoints to = determine both far-endpoint and path-modulated availability of [a new = protocol]." > the reason I say it's not entirely separate ifrom discovery s that = happy eyeballs can check availability both on the path and the other end = in one go. Since the point of happy/angry eyeballs is low connection setup latency, = yes: the more stuff you can do with the fewer packets the better. > However, having a separate method that really only deals with the = other end can limit how much happy eyeballing one needs to do (i.e.: no = point even trying SPUD if the other side doesn't use it). There's an engineering tradeoff here between robustness and complexity, = and I really hope that HOPS and related efforts get us some better = insight as to what the exponents are on the types of impairments we hope = to see.=20 We're trying to run some measurements right now to get some numbers on = how likely UDP-based encaps are to make it through the network, and how = likely differential treatment of UDP and TCP packets will cause = performance issues, as it's the UDP-ness of SPUD that is likely to cause = us the most problems initially. (If anyone knows of studies to this = question or available data to measure, please let us know. :) ) Cheers, Brian From nobody Fri Mar 20 06:02:29 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7242A1B2CF5 for ; Fri, 20 Mar 2015 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eYiKOz1q9WhR for ; Fri, 20 Mar 2015 06:02:25 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::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 0C9F61B2CF3 for ; Fri, 20 Mar 2015 06:02:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YYwZC-0001nu-QY; Fri, 20 Mar 2015 14:02:22 +0100 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YYwZC-0002mT-4o; Fri, 20 Mar 2015 14:02:22 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Mar 2015 14:02:21 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Fri, 20 Mar 2015 14:02:21 +0100 From: Michael Welzl To: Brian Trammell Thread-Topic: [Spud] discovery Thread-Index: AQHQYuaikdm5b2wk00WGXC5oI03XxQ== Date: Fri, 20 Mar 2015 13:02:21 +0000 Message-ID: References: <8996D749-9936-4BB3-B494-08556CE8D41C@trammell.ch> <7D4541ED-80A7-4C53-9386-58E755BF8375@ifi.uio.no> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A9A8F1B506FD74AB5A0BC50838324F5@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 12 sum msgs/h 4 total rcpts 26634 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7CDFAA1AE9F13CECEA8CE490E289949822D18E3D X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 13 total 650636 max/h 480 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "spud@ietf.org" Subject: Re: [Spud] discovery X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 13:02:27 -0000 > On 20 Mar 2015, at 12:47, Brian Trammell wrote: >=20 >=20 >> On 20 Mar 2015, at 04:19, Michael Welzl wrote: >>=20 >>=20 >>> On 20 Mar 2015, at 03:00, Brian Trammell wrote: >>>=20 >>>>=20 >>>> On 19 Mar 2015, at 19:21, Michael Welzl wrote: >>>>=20 >>>>=20 >>>>> On 19. mar. 2015, at 17.18, Brian Trammell wrote: >>>>>=20 >>>>> hi Aaron, >>>>>=20 >>>>>> On 19 Mar 2015, at 11:48, Aaron Falk wrote: >>>>>>=20 >>>>>> The draft >>>>>=20 >>>>> ... where "the draft" is draft-hildebrand-spud-prototype ... >>>>>=20 >>>>>> doesn't say much about how one efficiently determines whether the ot= her end is SPUD-capable so that an application can know whether it can use = it. >>>>>=20 >>>>> No, it doesn't. >>>>>=20 >>>>>> Has anyone given thought to this? >>>>>=20 >>>>> Yes, I have... >>>>>=20 >>>>> I think for the most part that this question is (1) very important bu= t (2) mostly orthogonal to that we're trying to answer in spud-prototype. >>>>>=20 >>>>> Initially, I would expect that discovery works the same way that it d= oes for any other user of the transport layer: you either have a URL, or a = name and a port, or some information from your application-layer protocol's= discovery service, which includes "uses x-over-SPUD" in its semantics. >>>>>=20 >>>>> Dynamically discovering a SPUD endpoint might make sense if a server = port / URL schema is assigned to a service over X or a service over x-over-= SPUD. In this case, the magic number we've selected makes SPUD server probi= ng by the client possible: a SPUD packet is neither valid UTF-8, UTF-16, UT= F-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or Bittorrent. This is = not an exhaustive list, but we haven't found a protocol over UDP that is li= kely to consider d8 00 00 d8 as the first four bytes anything other than an= error. >>>>=20 >>>> - but that won't tell you if SPUD actually does work across the path..= . >>>=20 >>> True. But discovery (is there an endpoint there?) is a separate questio= n from path transparency (once you've found the endpoint, can you actually = talk to it?) >>=20 >> Not entirely I think - see below: >=20 > The questions are absolutely separate. The way you answer them, not neces= sarily. >=20 >>> This would be an argument for specifying a dynamic discovery method, th= ough -- not for determining whether you should use SPUD, but whether you ca= n. >>=20 >> So I think, as much as some folks seem to hate it, there really isn't a = way around happy-eyeballing... >=20 > In general, I don't disagree with this -- let me rephrase it to make sure= we're saying the same thing: >=20 > "Dynamic discovery mechanisms are necessary at both endpoints to determin= e both far-endpoint and path-modulated availability of [a new protocol]." >=20 >> the reason I say it's not entirely separate ifrom discovery s that happy= eyeballs can check availability both on the path and the other end in one = go. >=20 > Since the point of happy/angry eyeballs is low connection setup latency, = yes: the more stuff you can do with the fewer packets the better. >=20 >> However, having a separate method that really only deals with the other = end can limit how much happy eyeballing one needs to do (i.e.: no point eve= n trying SPUD if the other side doesn't use it). >=20 > There's an engineering tradeoff here between robustness and complexity, a= nd I really hope that HOPS and related efforts get us some better insight a= s to what the exponents are on the types of impairments we hope to see.=20 - I think we agree on everything here. > We're trying to run some measurements right now to get some numbers on ho= w likely UDP-based encaps are to make it through the network, and how likel= y differential treatment of UDP and TCP packets will cause performance issu= es, as it's the UDP-ness of SPUD that is likely to cause us the most proble= ms initially. (If anyone knows of studies to this question or available dat= a to measure, please let us know. :) ) I don't but I think this is a very cool thing to test! Curious to see the r= esults! Cheers, Michael From nobody Mon Mar 23 17:26:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792221A90DB for ; Mon, 23 Mar 2015 17:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Fv4JWkOnSY21 for ; Mon, 23 Mar 2015 17:26:09 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 203B31A90C7 for ; Mon, 23 Mar 2015 17:26:09 -0700 (PDT) Received: by oiag65 with SMTP id g65so155127828oia.2 for ; Mon, 23 Mar 2015 17:26:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=hhTohoHm7s+FZTm23MTxa9YvihGcAbYAu3vMQ24jrLg=; b=Bcj3hfoHCRAak6p6Qryb/xPckMnIw4wNRcKunZbzBcVZyi1aUdoHNbxCXBISjBox3U AHfW8MPLWL6NluEza5hzigZlilbpY0BYdZsR3Q+Dr30A4z6BvF8PEyakNCNNLEkvOKO9 0fG0vTLtJg4Ng4uK1aVqWgq7kjjey1yUvq5nF0oeG5TdyWfnNOKOf0Xxy31U9Jt3VqGS 1CxE5fd7lRtgjlD0gQQqorC1ivh0idz48XRd3g0mplnFFHwJyuzTwoVve7ePc6+Z7n3r o3UZhMYYFwFGpEv1beQSuqUIIOkf96uF5HrfS0wAlOJA8zaC3DQ5D02pUcvSMyjYoPJ0 rDwQ== X-Gm-Message-State: ALoCoQm5Y8NpcvELGB+G9yYvpSTxPWAAYfMkH9ju8jeyZNVGfAUes2vaEqwyL6P7N2lSDPQC0M+h X-Received: by 10.60.42.171 with SMTP id p11mr1308510oel.41.1427156768562; Mon, 23 Mar 2015 17:26:08 -0700 (PDT) Received: from Macintosh.local (rrcs-64-183-197-98.sw.biz.rr.com. [64.183.197.98]) by mx.google.com with ESMTPSA id bc12sm1316708obd.21.2015.03.23.17.26.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 17:26:07 -0700 (PDT) Message-ID: <5510AF1F.4090802@nexenta.com> Date: Mon, 23 Mar 2015 17:26:07 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Spud] multicast spud X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 00:26:10 -0000 The requirements section includes multicast in the list, but the details need some more work. For example: "A tube may be closed by either endpoint." A multicast session does not have a pair of endpoints. it has an initiator (or maybe more) and zero or more receivers. The opening of a multicast session obviously needs a different procedure than what is used for unicast. Nexenta's object cluster systems using multicast UDP to replicate storage chunks within a data center. This relies upon a concept of "Transactional multicast" that is described in draft-bestler-transactional-multicast-00. This approach to multicast addressing is very compatible with SPUD, although the specific project did not need it because multicasting is limited to a single subnet. But SPUD could enable verifying path details for a wider range transactional multicast delivery. Confirming the MTU, for example, would be essential for delivering across middleboxes. Other comments: The "CBOR Map" is unclear as described. I presume that this is the balance of the UDP payload that is somehow mutually exclusive from user-content. That should be explicitly stated and probably made clear in the diagram. There is a rationale that is not explained. If a tube is a specific set of datagrams there is obviously some method of enumerating what is a complete set. SPUD is deliberately limiting its knowledge of this to knowing the first and last datagram because the middleboxes do not need to know how to validate the payload. Therefore while this information is needed, the protocol will not constrain how it is encoded. From nobody Wed Mar 25 05:31:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E83E1ACE46 for ; Wed, 25 Mar 2015 05:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 cwR_gC6DRwYH for ; Wed, 25 Mar 2015 05:31:03 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 647C31AC425 for ; Wed, 25 Mar 2015 05:31:03 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so21667904wib.0 for ; Wed, 25 Mar 2015 05:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CDxcOA/alm7thLTMV8AXpJJpUqImEVEdoEt3TXEYRpc=; b=JDBCCmwvSFJFBK8zbM1Vt5xSNKUoScVhPkM2K5QzQYfm/ynhT5FUcJ+APeh1mCLrfi uYrg0F+4N4AnxJRzCcafcPudqsOA9JAp5haCDZPj5IATVhUtx3fP724KXn0Sn4HaSY3Z PJwSkbqnM9+PvYuLH52WTjL7rD24WmYLRHUMxjMOuxG5X9us+7WjVLmP0yZLw253jhWD txxEmEilp7BXeLprhkiph23YZTh+pK38JICFEA1x34Vnbj//krTfa6Zjkjtgt4xkItyd 0n6lh08cnMOT7y1qwjigTVm/x/hE4vzP/ASRLehW23eQNFsHZdGzZUgI6z/XbmrmdS5J fFaA== X-Received: by 10.194.156.133 with SMTP id we5mr17916454wjb.37.1427286662136; Wed, 25 Mar 2015 05:31:02 -0700 (PDT) Received: from dhcp-9c7e.meeting.ietf.org ([2001:67c:370:152:78ac:1619:194c:ae22]) by mx.google.com with ESMTPSA id n6sm3509799wjy.8.2015.03.25.05.31.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 05:31:01 -0700 (PDT) Message-ID: <5512AA84.80107@gmail.com> Date: Wed, 25 Mar 2015 07:31:00 -0500 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Spud] Numbers... X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 12:31:04 -0000 Hi all, I am just going through the slides for today's BOF and just got stuck on slide 5 of which says: "Today UDP is often blocked (“99% of UDP is garbage”) but volume of (good) UDP traffic grows, e.g. RTCWEB uses UDP for data and media" Is there reliable data that underscores UDP is often blocked? I can see cases, e.g., enterprises where this is true, but in most other settings my UDP traffic is just making it to the other end, by today. Was different a couple of years ago, when there was no stateful filtering of UDP traffic implemented. Thanks, Martin From nobody Wed Mar 25 05:52:18 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5422E1AC438 for ; Wed, 25 Mar 2015 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 TCIOJSzUq50m for ; Wed, 25 Mar 2015 05:52:16 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (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 C5A001A88BF for ; Wed, 25 Mar 2015 05:52:15 -0700 (PDT) Received: by wgra20 with SMTP id a20so26178004wgr.3 for ; Wed, 25 Mar 2015 05:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gapHceFN4FDryr2SmHfh/0WK//MRy+eSCRd7yW3fnWE=; b=ZBSF2O4jg4jqYe5HF/TaIyuM/tZHYmlEfIW86iBtjcJSd72opvOR1d0wO+B+j4Byd5 N3qk8r1dO1JQASW9VwZKb+I8SDtjAGpnAXxkX/tNxhYBeJcoP+P19sfAIOLxzz+JvxeB PFVDsA/n3rhqr/4a9Lzg5ewHxLGthWywjfiiGqgiAKASuokIVR/43xHFWRudzIKjAcNL XOw8ibcSx2r5OAkHrN6ChJ4g1qIA8elRz6w1QIdLw9vlM7fsytY3WJeefKlpsG/rboaD FJJP4Y2nG51N00KLPnZFyt96HECircPZ0lZD+GM2a6m68lSswuaU1KW9gNvd09P9H7D7 SkGQ== X-Gm-Message-State: ALoCoQkMyu7IPpXU7g88OuZ97xHj2M8giWe+8RUrj32ygZAUP6hC+Hymtgwg+odCHJI1mn+mtpLg X-Received: by 10.180.14.7 with SMTP id l7mr38329031wic.40.1427287934452; Wed, 25 Mar 2015 05:52:14 -0700 (PDT) Received: from dhcp-b60c.meeting.ietf.org ([2001:67c:370:176:152e:34a2:46f8:4c64]) by mx.google.com with ESMTPSA id eo1sm4163062wib.16.2015.03.25.05.52.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 05:52:13 -0700 (PDT) Message-ID: <5512AF7C.8090509@nexenta.com> Date: Wed, 25 Mar 2015 05:52:12 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spud] [SPUD] Multipath UDP as a SPUD usecase? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 12:52:17 -0000 Is there anything different about setting up a point-to-point SPUD session that is different from forming an SCTP association? Why not just adopt the SCTP work for point-to-point and work on multi-destination (as in multiple receivers, not multiple network endpoints)? From nobody Wed Mar 25 05:55:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0C1ACE9C for ; Wed, 25 Mar 2015 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4SM-GfhfH56k for ; Wed, 25 Mar 2015 05:55:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A46E1A1A0B for ; Wed, 25 Mar 2015 05:55:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1869BD9316; Wed, 25 Mar 2015 13:55:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UMHM-GrRLEuN; Wed, 25 Mar 2015 13:54:59 +0100 (MET) Received: from dhcp-892f.meeting.ietf.org (dhcp-892f.meeting.ietf.org [31.133.137.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 73EC7D931B; Wed, 25 Mar 2015 13:54:59 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5512AA84.80107@gmail.com> Date: Wed, 25 Mar 2015 07:54:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7276B84D-7540-4DFC-82EC-1246EF96EFF0@tik.ee.ethz.ch> References: <5512AA84.80107@gmail.com> To: Martin Stiemerling X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Numbers... X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 12:55:04 -0000 Hi Martin, this sentence is in quotes because that=E2=80=99s stuff people did = actually say to me or others. 99% is not true but there are currently no = number publicly available to our knowledge. We just started measurements = on this and we are also currently talking to people who might have some = numbers e.g. for chrome/QUIC (that=E2=80=99s part of the hops activity). Mirja > Am 25.03.2015 um 07:31 schrieb Martin Stiemerling = : >=20 > Hi all, >=20 > I am just going through the slides for today's BOF and just got stuck = on slide 5 of which says: > "Today UDP is often blocked (=E2=80=9C99% of UDP is garbage=E2=80=9D) = but volume of > (good) UDP traffic grows, e.g. RTCWEB uses UDP for data and media" >=20 > Is there reliable data that underscores UDP is often blocked? >=20 > I can see cases, e.g., enterprises where this is true, but in most = other settings my UDP traffic is just making it to the other end, by = today. Was different a couple of years ago, when there was no stateful = filtering of UDP traffic implemented. >=20 > Thanks, >=20 > Martin >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Wed Mar 25 11:57:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3B01B2ACA for ; Wed, 25 Mar 2015 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 thm8tnCeNzBh for ; Wed, 25 Mar 2015 11:57:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7721B2AEA for ; Wed, 25 Mar 2015 11:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2088; q=dns/txt; s=iport; t=1427309806; x=1428519406; h=message-id:date:from:mime-version:to:subject; bh=iarQ6K6mRGfVhRDJOqKUaKczcX7ox9C/hrvBQaxLe+c=; b=HFPcN3L7iUk15qR/5Ta1JuNo+J3UM31fsU2BAJb7FF8VddTmMpcsuIx5 2W2xu/WASK7yls56wUQIRnQ7hmKw0wSrvNSs/01HT8vZ+6pAOL1C5nEkh 5Hl8CHHHgUT11f4s8B1zx/lcqyI8dujcyIOEFLbOxZwBulq3/kjt8pCfg M=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQB3BBNV/49dJa1cgwaEPslSTAEBAQEBAX2EPlU9FgsCCwMCAQIBPxkIAQGIK6AMj0yaR5A0glKBRQWLE4cmgTKGVIcDjSkihAwggnQBAQE X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="asc'?scan'208";a="135373328" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 25 Mar 2015 18:56:46 +0000 Received: from [10.89.7.249] (rcdn-vpn-client-10-89-7-249.cisco.com [10.89.7.249]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2PIujit027354 for ; Wed, 25 Mar 2015 18:56:45 GMT Message-ID: <551304ED.7080601@cisco.com> Date: Wed, 25 Mar 2015 13:56:45 -0500 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kvxkcL2KjXsnuuQFg6lVvaPnEKT9C70dH" Archived-At: Subject: [Spud] on trust and lying X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 18:57:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kvxkcL2KjXsnuuQFg6lVvaPnEKT9C70dH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A comment was made at the microphone that middle boxes will lie to end hosts and end hosts will lie to middle boxes. That is not strictly true, and we have an existence proof of when it is not: that is TCP.=20 The intended point of Joe's slide to map SPUD states to TCP wasn't just a simple example. The behavior of TCP on the hosts can be observed by the middle box and based on that behavior the middlebox can make appropriate decisions. The most classic example of this is simply blocking inbound SYNs to block opening of new connections. New connections do not establish absent that first naked SYN. Similarly, the network can assume that only connections that are already open will contain an ACK, knowing that a host will reject an unsolicited packet that contains that flag. That three way handshake is in effect an implicit behavior contract between the end host and middle boxes. Whatever SPUD becomes, it has to establish, at the very least, that implicit behavior contract for UDP. Today it simply doesn't exist in the general sense, although there are may be a higher few protocols that allow for that. Eliot --kvxkcL2KjXsnuuQFg6lVvaPnEKT9C70dH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJVEwTtAAoJEIe2a0bZ0noz5bIIANuamj774G7n59/GySyZU6Kd RCRjMguPIBCd0Zd7ajNmUimI5nbrXCPZo+20Bzs+83083VDtviygm6tfz+5o4oHU VVbeCakJbaxMwVu+DHVF9U3szjPswiUCTmu1zXjqf/Z4Q2alrnwOxILh4VcTBhoM QEjzuPjA3eLIjR92Td9RsNXWWTvs5rCsZYMa8+24ImVbnZUxpeh6q2HGetEHvgp7 M5St0Z8SZYCHVWPIb8CGYLJ7FuPF+JzwiAtlAh6xJMDZQqzUpgHjej3lJ8qdGQNM 9+qxev1YgINzei7FmgAuIxFvykNHjA9UgtxEIMJ4o51HaUr1H31VLT4rMF1kQYw= =vP66 -----END PGP SIGNATURE----- --kvxkcL2KjXsnuuQFg6lVvaPnEKT9C70dH-- From nobody Wed Mar 25 12:20:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7F21B2A38 for ; Wed, 25 Mar 2015 12:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Mn4j9KQ8a7O9 for ; Wed, 25 Mar 2015 12:20:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28381B2ACA for ; Wed, 25 Mar 2015 12:20:01 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-da-55130a5fec56 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.30.01716.F5A03155; Wed, 25 Mar 2015 20:20:00 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.246]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Wed, 25 Mar 2015 20:19:59 +0100 From: Salvatore Loreto To: Eliot Lear Thread-Topic: [Spud] on trust and lying Thread-Index: AQHQZy2GvCD/AF7sBUm9j9wy38KslJ0tgj2A Date: Wed, 25 Mar 2015 19:19:59 +0000 Message-ID: <95859196-9247-4162-B175-6A1E4405BE0C@ericsson.com> References: <551304ED.7080601@cisco.com> In-Reply-To: <551304ED.7080601@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <44A71BFF42D17949A60421D8C73FFBE8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RjeBSzjUYOJNTouv/zpYLBZdeMro wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWcuvOfteAqT0Xvh/nsDYwTuLoYOTgkBEwk lh4v72LkBDLFJC7cW8/WxcjFISRwhFHi7o2HrBDOEkaJ+/9eMoNUsQmYSTx/uAXMFhGQl2g9 u58VxGYWUJaYsXAXI4gtLKAmcez9RkaIGnWJvifzoeqNJGYvfMMCYrMIqErcWfoBrJdXwF7i w48N7CC2kICGROu6HrB6TgFNiT8Pr4PVMwJd9/3UGiaIXeISt57MZ4K4WkBiyZ7zzBC2qMTL x/9YIWwlibWHt7NA1OtILNj9iQ3Ctpb4+mg5VFxbYtnC18wQNwhKnJz5hGUCo/gsJCtmIWmf haR9FpL2WUjaFzCyrmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLeDW37r7mBc/drxEKMA B6MSD+9GFaFQIdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw xt0V92V4lSl4ZYGjcMW0gohCteKU1voPF4Q517A5yxY9StfsbcwU4lLZIWfF+qftzacYnSNi 3FHql/Q6rFTMgwpfHrilveSRn69O3Bn2B2LF1i+KMw50mau+22THdNb+g8rswoKidQk67wxD S5aI7nudxj5B1r8sxE6aV8r9lafzZYc9v5RYijMSDbWYi4oTASwf4TaYAgAA Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] on trust and lying X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:20:03 -0000 I do think that we need a way to establish a trust relationship=20 not only between the endpoints but also among the end points and the middle boxes as well as among the middle boxes=20 br Salvatore > On 25 Mar 2015, at 13:56, Eliot Lear wrote: >=20 > A comment was made at the microphone that middle boxes will lie to end > hosts and end hosts will lie to middle boxes. That is not strictly > true, and we have an existence proof of when it is not: that is TCP.=20 > The intended point of Joe's slide to map SPUD states to TCP wasn't just > a simple example. The behavior of TCP on the hosts can be observed by > the middle box and based on that behavior the middlebox can make > appropriate decisions. The most classic example of this is simply > blocking inbound SYNs to block opening of new connections. New > connections do not establish absent that first naked SYN. Similarly, > the network can assume that only connections that are already open will > contain an ACK, knowing that a host will reject an unsolicited packet > that contains that flag. That three way handshake is in effect an > implicit behavior contract between the end host and middle boxes. >=20 > Whatever SPUD becomes, it has to establish, at the very least, that > implicit behavior contract for UDP. Today it simply doesn't exist in > the general sense, although there are may be a higher few protocols that > allow for that. >=20 > Eliot >=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Wed Mar 25 12:27:49 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7273D1A8A45 for ; Wed, 25 Mar 2015 12:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 OnFHYp5orCbe for ; Wed, 25 Mar 2015 12:27:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F921A89A0 for ; Wed, 25 Mar 2015 12:27:43 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-ce-55130c2ea6d8 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.E0.01716.E2C03155; Wed, 25 Mar 2015 20:27:42 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.246]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Wed, 25 Mar 2015 20:27:42 +0100 From: Salvatore Loreto To: "spud@ietf.org" Thread-Topic: network/middle boxes information Thread-Index: AQHQZzHD+it0eZCqGUCsdpg+RDfRuQ== Date: Wed, 25 Mar 2015 19:27:41 +0000 Message-ID: <1FEB0782-16E8-4AE0-8FF5-2B824EF89F24@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <93322A647F602D4184C64EA1D485442F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja4ej3Cowa9VChaLLjxldGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqN/5xgL1rFULDjH2sC4lbmLkYNDQsBE4vsnyS5GTiBTTOLC vfVsXYxcHEICRxgl9l1rZ4RwljBKzN3+lwWkik3ATOL5wy3MILaIgLLE2juL2EFsYQFNiZ7J sxhBhooI6EnsPGQPUaInsfz8MUYQm0VAVeLUr0NsIDavgL3El1cTmEBsRqDF30+tAbOZBcQl bj2ZzwRxkIDEkj3nmSFsUYmXj/+xQthKEmsPb2eBqNeRWLD7ExuEbS3xZMIZKFtbYtnC18wQ uwQlTs58wjKBUWQWkhWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWW bGIExsPBLb91dzCufu14iFGAg1GJh3ejilCoEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYM/8liZpIpIu5zJj1xq59V6DwTlnH6wynTNVmFWU6bkoLfSt6 QfZdz3+tn0wHsg1S7e/kzEjeVFGoHdTnVlezwuDh5cnliwuNP4UHGX69+4z/gJnltWOxPy9M uNjoGD99sumEsiUr+t5Pv+Vd7CEnrpHVezh/w7oVrY988g7ryW0ocLV1edynxFKckWioxVxU nAgAF8l7KGgCAAA= Archived-At: Subject: [Spud] network/middle boxes information X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:27:48 -0000 During the open discussion Andrew expressed the fact that the networks have= a lot of information that can be of interest (or even useful) to the end points (we have seen a = proof of this already in tsvwg yesterday). I want make clear that privacy and security is also important the network n= ot only for the endpoints. We have to make sure that the middle box that is requested to share some in= fo with the endpoint can do that in a secure/encrypted way (i.e. be able to decide who will be a= ble to see the info in clear) br Salvatore= From nobody Wed Mar 25 12:53:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A001D1B2B66 for ; Wed, 25 Mar 2015 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 vYxQJ8E4jc_Y for ; Wed, 25 Mar 2015 12:53:13 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.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 DD54A1B2B65 for ; Wed, 25 Mar 2015 12:53:12 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1YarMV-0006Xb-D5 for ; Wed, 25 Mar 2015 20:53:11 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 11DEAB002B8 for ; Wed, 25 Mar 2015 20:53:10 +0100 (CET) Message-ID: <55131225.6040609@kit.edu> Date: Wed, 25 Mar 2015 20:53:09 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: spud@ietf.org References: <551304ED.7080601@cisco.com> In-Reply-To: <551304ED.7080601@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1427313191. Archived-At: Subject: Re: [Spud] on trust and lying X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:53:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Eliot Lear wrote: > Whatever SPUD becomes, it has to establish, at the very least, that > implicit behavior contract for UDP. Today it simply doesn't exist > in the general sense, although there are may be a higher few > protocols that allow for that. Especially for future protocols, the middleboxes have to believe/trust on the information given in the SPUD encapsulation, since they may not be able to check what the protocol is actually doing inside due to encryption. Regards, Roland -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUTEiUACgkQ1YyfLd659keyzgCg5OD70mR11FirBuErRNEuMCac fVcAoPMt0wEziQbvkuwHn24tqaRXr0O8 =0NN3 -----END PGP SIGNATURE----- From nobody Wed Mar 25 14:29:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376371A87BE for ; Wed, 25 Mar 2015 14:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4TMszc7-VchL for ; Wed, 25 Mar 2015 14:29:04 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E291A039A for ; Wed, 25 Mar 2015 14:29:03 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 25 Mar 2015 21:29:02 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 25 Mar 2015 21:29:01 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 25 Mar 2015 21:29:00 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.176.200]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id t2PLSvGt003818; Wed, 25 Mar 2015 21:28:58 GMT Message-ID: <201503252128.t2PLSvGt003818@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Mar 2015 21:28:57 +0000 To: Eliot Lear From: Bob Briscoe In-Reply-To: <551304ED.7080601@cisco.com> References: <551304ED.7080601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] on trust and lying X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:29:06 -0000 Eliot, At 18:56 25/03/2015, Eliot Lear wrote: >A comment was made at the microphone that middle boxes will lie to end >hosts and end hosts will lie to middle boxes. That is not strictly >true, and we have an existence proof of when it is not: that is TCP. We cannot naively rely on TCP experience though, because part of the security that firewalls attribute to TCP's connection life-cycle controls (SYN, SYN/ACK, FIN, RST etc) derives from being able to assume their universal support on all hosts. SPUD doesn't have that luxury. For instance, any TCP host will always discard a data segment that was not preceded by a SYN. But UDP hosts out there today without a firewall in their stack will accept a UDP datagram whether or not it is preceded by a SPUD open command (because they don't recognise SPUD commands). So if a perimeter firewall today is blocking all UDP from red-side (to protect such unprotected hosts), it is not going to allow through UDP datagrams to any green-side host, just because the datagram says "SPUD-open". At best the firewall will be reprogrammed to allow SPUD-open through to green-side hosts that have previously registered that they support SPUD. The firewall policy might be more restrictive, e.g. it might allow SPUD-open from only specific red-side hosts to certain green-side SPUD hosts. That's why I said, at the mic today, that the SPUD-ack-open command is the significant one in security terms. You can think of that as either of two dual functions: i) the command that a green-side host uses to register its SPUD support to the firewall within a long-term security context. ii) Or you can think of it as equivalent to a "SYN/ACK preceding a SYN" for the short-term security context of a tube. It should be possible for one command to support either type of context. I am not disagreeing with your general point that TCP is an exsistence proof of a protocol that has sufficient hooks to be able to mitigate the effects of lying. I'm just saying we have to think about SPUD security from scratch, not just rely on mimicking TCP, because SPUD has the additional dimension of incremental deployment. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Wed Mar 25 14:38:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53971A01A5 for ; Wed, 25 Mar 2015 14:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 QJaUErqWTIM4 for ; Wed, 25 Mar 2015 14:38:04 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 81CD71A017D for ; Wed, 25 Mar 2015 14:38:04 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so37557878igb.1 for ; Wed, 25 Mar 2015 14:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KmlsqsjPCQQCX2uOa7USDDhkBzDrsORibK1fPTtnBrE=; b=AvDMYCpX5vigi9lOnamLQrPOTQzQmpS0ILCIKi++ErKPaVlg4Bsg8Ht8QZtRTRot/a dQy72uXqIcirfCArfHaopvILz1tRYzPDzPaM0oOC92cuyDU7yHvGeTCIL4vnXPDWLcug uuO1vOCms6LxPqiTygQIt6kmFqgpeoxuuopKFPYqd8TNgz52qmThPqj2dhfZn3T0bHMM sJostn4h0N57dDncil7YNEZi2JbF1dsDlyFfhbZwf1C3wMKRbln+0Bzo5WUtOcf75XIV G1O8uYAGECcHBROWWI/HROpTQO/+ZKAzI4sz2kFXM7WGCh3K+x8tgkRRhcwJ/+m3mxvj iB/g== MIME-Version: 1.0 X-Received: by 10.43.69.68 with SMTP id yb4mr34016187icb.96.1427319484064; Wed, 25 Mar 2015 14:38:04 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Wed, 25 Mar 2015 14:38:04 -0700 (PDT) Date: Wed, 25 Mar 2015 16:38:04 -0500 Message-ID: From: Aaron Falk To: "spud@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51b1be9d44847051223b6b2 Archived-At: Subject: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:38:05 -0000 --bcaec51b1be9d44847051223b6b2 Content-Type: text/plain; charset=UTF-8 If we take SPUD's goals at their most minimal, as expressed by Ted, of enabling passage of encrypted traffic through middleboxes, can someone explain why PCP is not sufficient? --aaron --bcaec51b1be9d44847051223b6b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we take SPUD's goals at their most minimal, as expr= essed by Ted, of enabling passage of encrypted traffic through middleboxes,= can someone explain why PCP is not sufficient? =C2=A0

-= -aaron
--bcaec51b1be9d44847051223b6b2-- From nobody Wed Mar 25 15:31:10 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA621A06E9 for ; Wed, 25 Mar 2015 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 EkZlCgrcmI4G for ; Wed, 25 Mar 2015 15:31:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2690E1A1A1D for ; Wed, 25 Mar 2015 15:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1068; q=dns/txt; s=iport; t=1427322667; x=1428532267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fX1FqXsNFfku1wvjSSRFn6D8xWVfJMfQQ5346GeCOmE=; b=b2nPXbOY2J/4ARaizEbXXQWw+zSCZ2OHJnjH9m2I5yUYYIKB2BRXKoSd ri3GKBziw4UZ5C0IA4USqjDFD5501xFQU/TpcP/YDG04CzRU0exvzqx9g QTXNuwSQTQJLuLkLvgyIuyEob9tbj6E0qJiQ/S0O1VXPA6FTWGERS7q6P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQB/NhNV/5RdJa1cgwZSWgSDDsF6CoV1AhyBP0wBAQEBAQF9hBQBAQEDAQEBASAROgsFCwIBCBgCAiYCAgIfBgsVEAIEDgWIGwMJCA2vcpRQDYVFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoAgkeCLweCaC+BFgEEkFCIIoFNjgOGKSKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,467,1422921600"; d="scan'208";a="135428740" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 25 Mar 2015 22:31:07 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2PMV6N8007046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 22:31:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 17:31:06 -0500 From: "Pal Martinsen (palmarti)" To: Aaron Falk Thread-Topic: [Spud] PCP vs. SPUD Thread-Index: AQHQZ0P9x7+U+KTJTk2JT2k0tuzn3J0uHAqA Date: Wed, 25 Mar 2015 22:31:06 +0000 Message-ID: <2A7D5F44-133C-467E-A3FE-15556E8EC35D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.190] Content-Type: text/plain; charset="utf-8" Content-ID: <919766AE00C23A4597CE76348D56C053@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:31:08 -0000 DQo+IE9uIDI1IE1hciAyMDE1LCBhdCAxNjozOCwgQWFyb24gRmFsayA8YWFyb24uZmFsa0BnbWFp bC5jb20+IHdyb3RlOg0KPiANCj4gSWYgd2UgdGFrZSBTUFVEJ3MgZ29hbHMgYXQgdGhlaXIgbW9z dCBtaW5pbWFsLCBhcyBleHByZXNzZWQgYnkgVGVkLCBvZiBlbmFibGluZyBwYXNzYWdlIG9mIGVu Y3J5cHRlZCB0cmFmZmljIHRocm91Z2ggbWlkZGxlYm94ZXMsIGNhbiBzb21lb25lIGV4cGxhaW4g d2h5IFBDUCBpcyBub3Qgc3VmZmljaWVudD8gIA0KPiANClNQVUQgY2FuIGVhc2lseSByZXBsYWNl IFNUVU4gYXMgdGhlIGNvbm5lY3Rpdml0eSBjaGVjayBwcm90b2NvbCB3aGVuIGRvaW5nIElDRSB3 aXRob3V0IGFkZGluZyBtb3JlIHBhY2tldHMgdG8gdGhlIOKAnHRyYW5zYWN0aW9u4oCdLiBZb3Ug d291bGQgZG8gdGhlIOKAnHBpbmhvbGXigJ0gZnVuY3Rpb25hbGl0eSBhbmQgb3BlbiB1cCB0aGUg dHViZShzKSB3aXRoIG9uZSBwYWNrZXQuIA0KDQpXaXRoIFBDUCAsIEkgdGhpbmssIHlvdSB3b3Vs ZCBmaXJzdCBuZWVkIHRvIHRhbGsgdG8gdGhlIEZXIHRvIG9wZW4gdGhlIHBpbmhvbGUsIGFuZCB0 aGVuIHlvdSBjYW4gcnVuIElDRS9TVFVOIGFzIG5vcm1hbC4NCg0KLi0uDQpQw6VsLUVyaWsgDQoN Cg0KDQo+IC0tYWFyb24NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4gU3B1ZEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCg0K From nobody Wed Mar 25 21:34:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847581A90F5; Wed, 25 Mar 2015 21:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SE2WFSJPUuSO; Wed, 25 Mar 2015 21:34:37 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99D51A8A07; Wed, 25 Mar 2015 21:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6278; q=dns/txt; s=iport; t=1427344476; x=1428554076; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AJTNKB8VT2QpgfSSck/lCT7Dy66MiYYQj2LTpuaGabo=; b=Fi5+1EqrJoCfmBJvNJAprvjxW8GhhjWin41E6ZRHYTO9vlLZdNbJjTE3 7bBBPPpprhkzUiDdId+n7ecNnsjk8oXpvgYf+upr6e5DWDmRksZM/OF/0 ooeDNba7Ofc4Vz0WgqrNqS3EDcaj1fBi6XtWvkmDswz2UTqafZ97/7END g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DACQATjBNV/5NdJa1cgkNDUloEgw6/fYgwAhyBRUwBAQEBAQF9hBQBAQEEIwpMEAIBCBEEAQELHQMCAgIwFAkIAgQBDQUIiCewEJogAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4shhEUxBgGCaC+BFgWQUJ4bIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,469,1422921600"; d="scan'208,217";a="135495946" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 26 Mar 2015 04:34:24 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2Q4YOid029764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 04:34:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 23:34:24 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Aaron Falk , "spud@ietf.org" Thread-Topic: [Spud] PCP vs. SPUD Thread-Index: AQHQZ0P9fkfGXDN/UUCaOAQAWpF0oZ0uK8Ow Date: Thu, 26 Mar 2015 04:34:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.161] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D0A57xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "pcp@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:34:38 -0000 --_000_913383AAA69FF945B8F946018B75898A366D0A57xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBQQ1AgY2FuIGJlIHVzZWQgdG8gY29tbXVuaWNhdGUgd2l0aCBtaWRkbGUgYm94ZXMgdG8g b3BlbiBhbmQgY2xvc2UgcGluaG9sZXM7IFBDUCBhbHNvIGhhbmRsZXMgYXR0YWNrcyBsaWtlIGF0 dGFja2VyIGNsb3NpbmcgdGhlIHBpbmhvbGVzIG9wZW5lZCBieSB0aGUgdmljdGltIG9yIGF0dGFj a2VyIG9wZW5pbmcgcGluaG9sZXMgb24gYmVoYWxmIG9mIHZpY3RpbSB0byBsYXVuY2ggRERPUyBh dHRhY2tzLCBhbGxvdyBvbmx5IGF1dGhvcml6ZWQgZW5kcG9pbnRzIHRvIG9wZW4vY2xvc2UgcGlu aG9sZXMgZXRjLg0KDQotVGlydQ0KDQoNCkZyb206IFNwdWQgW21haWx0bzpzcHVkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYXJvbiBGYWxrDQpTZW50OiBUaHVyc2RheSwgTWFyY2gg MjYsIDIwMTUgMzowOCBBTQ0KVG86IHNwdWRAaWV0Zi5vcmcNClN1YmplY3Q6IFtTcHVkXSBQQ1Ag dnMuIFNQVUQNCg0KSWYgd2UgdGFrZSBTUFVEJ3MgZ29hbHMgYXQgdGhlaXIgbW9zdCBtaW5pbWFs LCBhcyBleHByZXNzZWQgYnkgVGVkLCBvZiBlbmFibGluZyBwYXNzYWdlIG9mIGVuY3J5cHRlZCB0 cmFmZmljIHRocm91Z2ggbWlkZGxlYm94ZXMsIGNhbiBzb21lb25lIGV4cGxhaW4gd2h5IFBDUCBp cyBub3Qgc3VmZmljaWVudD8NCg0KLS1hYXJvbg0K --_000_913383AAA69FF945B8F946018B75898A366D0A57xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBQQ1AgY2FuIGJl IHVzZWQgdG8gY29tbXVuaWNhdGUgd2l0aCBtaWRkbGUgYm94ZXMgdG8gb3BlbiBhbmQgY2xvc2Ug cGluaG9sZXM7IFBDUCBhbHNvIGhhbmRsZXMgYXR0YWNrcyBsaWtlIGF0dGFja2VyIGNsb3Npbmcg dGhlIHBpbmhvbGVzIG9wZW5lZCBieSB0aGUNCiB2aWN0aW0gb3IgYXR0YWNrZXIgb3BlbmluZyBw aW5ob2xlcyBvbiBiZWhhbGYgb2YgdmljdGltIHRvIGxhdW5jaCBERE9TIGF0dGFja3MsIGFsbG93 IG9ubHkgYXV0aG9yaXplZCBlbmRwb2ludHMgdG8gb3Blbi9jbG9zZSBwaW5ob2xlcyBldGMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3B1ZCBbbWFpbHRvOnNwdWQt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWFyb24gRmFsazxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMzowOCBBTTxicj4NCjxiPlRvOjwv Yj4gc3B1ZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbU3B1ZF0gUENQIHZzLiBTUFVE PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IHdlIHRha2UgU1BVRCdzIGdvYWxzIGF0IHRoZWlyIG1vc3QgbWluaW1hbCwgYXMgZXhwcmVzc2Vk IGJ5IFRlZCwgb2YgZW5hYmxpbmcgcGFzc2FnZSBvZiBlbmNyeXB0ZWQgdHJhZmZpYyB0aHJvdWdo IG1pZGRsZWJveGVzLCBjYW4gc29tZW9uZSBleHBsYWluIHdoeSBQQ1AgaXMgbm90IHN1ZmZpY2ll bnQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS1hYXJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A366D0A57xmbrcdx10ciscoc_-- From nobody Thu Mar 26 05:02:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653151B2CB7 for ; Thu, 26 Mar 2015 05:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 e4kmvZJ7a4cb for ; Thu, 26 Mar 2015 05:02:45 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA7D1B2CA7 for ; Thu, 26 Mar 2015 05:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3818; q=dns/txt; s=iport; t=1427371364; x=1428580964; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=E6jbtTf4Nn+Nwr2cea09L3yyHQyVmWVOgZi50VQ04WY=; b=f+kayGc1JCVrV4iS9TckBl/8oLEDSXJ3/nHLuyTdzO8vEvLPxVU6rvQm p5h4loWvaW8HfjNpj5ipSuCDfQu0gt1B1w6sZNKLwxbdTE4EuvlaYV9nE s/RycOmgkZ3yKo+Kixtmh7LSvgxtWijO6RCgHs+PW9PGbLhlKajVGM1H7 Y=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHBQBY9BNV/4ENJK1cgwZSWoMSwg4BCYV1AoFcTAEBAQEBAX2EFQEBBAEBASBLGwsEFAkhAgIPAhYwBgEMBgIBAYgrDbAnmiEBAQEBAQEBAQEBAQEBAQEBAQEBARQEiyGEfYJogUUFixOHJoEyhlSHA40pIoQMIDGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,471,1422921600"; d="asc'?scan'208,217";a="135593031" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 26 Mar 2015 12:02:44 +0000 Received: from [10.89.15.80] ([10.89.15.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2QC2i81012891; Thu, 26 Mar 2015 12:02:44 GMT Message-ID: <5513F563.50702@cisco.com> Date: Thu, 26 Mar 2015 07:02:43 -0500 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Aaron Falk , "spud@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2po0AwXVmeCxMPBJOApcxsBnbXfIDFB1J" Archived-At: Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 12:02:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2po0AwXVmeCxMPBJOApcxsBnbXfIDFB1J Content-Type: multipart/alternative; boundary="------------050805020806060106090702" This is a multi-part message in MIME format. --------------050805020806060106090702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aaron, I view this stuff differently. It's not whether an extra protocol can do the job, but whether there can be another implicit contract built, at least in the case of directionality. That could be a tradeoff between signaling delay and packet overhead, but we don't yet really know what that packet overhead looks like. If this is all DTLS then maybe apps want to eat that anyway. Eliot On 3/25/15 4:38 PM, Aaron Falk wrote: > If we take SPUD's goals at their most minimal, as expressed by Ted, of > enabling passage of encrypted traffic through middleboxes, can someone > explain why PCP is not sufficient? =20 > > --aaron > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --------------050805020806060106090702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aaron,

I view this stuff differently.=C2=A0 It's not whether an extra protoc= ol can do the job, but whether there can be another implicit contract built, at least in the case of directionality.=C2=A0 That could be a tradeoff between signaling delay and packet overhead, but we don't yet really know what that packet overhead looks like.=C2=A0 If this i= s all DTLS then maybe apps want to eat that anyway.

Eliot


On 3/25/15 4:38 PM, Aaron Falk wrote:<= br>
If we take SPUD's goals at their most minimal, as expressed by Ted, of enabling passage of encrypted traffic through middleboxes, can someone explain why PCP is not sufficient? =C2=A0

--aaron


_______________________________________________
Spud mailing list
Spud@=
ietf.org
https://www.ietf.org/mailman/listinfo/spud

--------------050805020806060106090702-- --2po0AwXVmeCxMPBJOApcxsBnbXfIDFB1J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJVE/VjAAoJEIe2a0bZ0nozdncIAND/X3jJkjcF2AssL7VE6u8P lSbQqlCnOsnRkJsinMYx7ATy/yxAXOG6bpwG3SXxb0kk9kjORo9zcS/kChbvA3Wo z7yD94iq+e9WjQaaXFCwyYBz8fk48wpLa8OYDeUdAt4DQHq4/I5PSkOL26jfC6cF afXaIPl8loZcGaVVU72592PAagdUot1O4LFxBX9j7E6OHYGJK0IjUdpSWM7su7Dh 8J9469nGbLpRKC095La/HcVOAkYL8ZWUoc+iv63iQoP2BB2hzpYhcXjD2iyG2oRi bZmQfAjV17rAIGUvou6610BtjdmOYo4sc4iJt/52thrJoJjbmkS1J6TtoBSBGis= =QUeR -----END PGP SIGNATURE----- --2po0AwXVmeCxMPBJOApcxsBnbXfIDFB1J-- From nobody Thu Mar 26 09:06:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6C1A87A3 for ; Thu, 26 Mar 2015 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 VgvIwu-OkQPh for ; Thu, 26 Mar 2015 09:06:37 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 118A91AD190 for ; Thu, 26 Mar 2015 09:06:37 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so70310402wib.0 for ; Thu, 26 Mar 2015 09:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=DgvSFCAnOcj2V0adwEJO42D2Xo21HMR62IsPXIvB43o=; b=FTWNRMzvoSvp1Jtx6DU0wSs+bpXtNhFedVTlNyq8MXI/Fs/7k/FY3rF+DVBeXpascI 2HeQiWMUA5jWSL8fYCn/Yi6tBqeloUTCw6dRqfkvZHJ2+q6bGdIBzKyE4yrDV+L9uEPF gpv8xSchWFIY6ctI89/yZQffbm0GI9TsPCO2j+x5TtthDKwFIqKniMY6GS2kUq0XOjj2 N3j3oxOTjwnNRTE0gUxrcz2F1D1JzYB4ZejiVdmXFDF1LdvCs26bW7dFL+LBrs0n83N8 BLZdgFMJpsK5JdfF87hVqi+jd/MXMQ/zZGhGESpi4LLlcz3EmthxAkUjXCSRaRA4deJC HQyw== X-Gm-Message-State: ALoCoQkwyFFl8E40t43WtW4mWG4ZR8fJ/NOSIY414YVfFP8Otvrj1rqcFcX/t69s42YJ65VEpNu7 X-Received: by 10.180.35.97 with SMTP id g1mr48079712wij.17.1427385995628; Thu, 26 Mar 2015 09:06:35 -0700 (PDT) Received: from dhcp-b60c.meeting.ietf.org ([2001:67c:370:176:ec1a:8de7:e4b3:d35f]) by mx.google.com with ESMTPSA id u16sm9015664wjr.5.2015.03.26.09.06.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 09:06:34 -0700 (PDT) Message-ID: <55142E8A.1000509@nexenta.com> Date: Thu, 26 Mar 2015 09:06:34 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Spud] SPUD for Datacenters X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:06:38 -0000 Almost all of the SPUD discussion deals with long-haul networking, but virtually all of the infrormational declarations discussed would be just as applicable for datacenter switches, rbridges and routers. This is especially important when you consider that the same application might be run either on a machine in a home network or on a virtual machine in a datacenter. From nobody Thu Mar 26 12:07:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903891A9300 for ; Thu, 26 Mar 2015 12:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 1jFCZ4aBnD_l for ; Thu, 26 Mar 2015 12:07:50 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (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 DB4EB1A923C for ; Thu, 26 Mar 2015 12:07:38 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so60962789ied.1 for ; Thu, 26 Mar 2015 12:07:38 -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:content-type; bh=X0X+1hr9Lrm7o5zZ/ve0gGU2QxGcCLJsuC6sHCPWyzo=; b=tatqLASaNYap+OLPiMmlcigXq1mjhsVIoOMiz8jtgSSc4mG/Xe0DDdDVrYnryFi0By VhA4cPvibGYMA6fpPmPKyn8t0z7I1jDdXZhe0Ula8ON1xOyejHpEJD9+VFT9V+VXNjSg nkJrieqb706QWl2/Q69eNUwagwZuDU9XkiQ3AcnOjB6wVXzp9hqXD9Np9QXx/M/ycZKN rk2ng1q7zpcxKPB2qo9pFF7dxGqkNtHj+WvIVQ+9D0eLKel+rvD3UxNumeeFxJ/FPSuO N80aUb9V/wzS905NMxk5fErBaHSiH+8Ga6/AE1o55c+Cq6KqjKtufsiRvTIr6fsNnEyQ YaZg== MIME-Version: 1.0 X-Received: by 10.107.14.141 with SMTP id 135mr23405395ioo.15.1427396858409; Thu, 26 Mar 2015 12:07:38 -0700 (PDT) Received: by 10.64.113.196 with HTTP; Thu, 26 Mar 2015 12:07:38 -0700 (PDT) In-Reply-To: <5513F563.50702@cisco.com> References: <5513F563.50702@cisco.com> Date: Thu, 26 Mar 2015 14:07:38 -0500 Message-ID: From: Aaron Falk To: Eliot Lear Content-Type: multipart/alternative; boundary=001a113fefc2b2f88a051235ba57 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:07:51 -0000 --001a113fefc2b2f88a051235ba57 Content-Type: text/plain; charset=UTF-8 HI Eliot- I don't understand your response. Could you expand on it a little? Are you saying they both solve the problem but SPUD is more efficient? --aaron On Thu, Mar 26, 2015 at 7:02 AM, Eliot Lear wrote: > Aaron, > > I view this stuff differently. It's not whether an extra protocol can do > the job, but whether there can be another implicit contract built, at least > in the case of directionality. That could be a tradeoff between signaling > delay and packet overhead, but we don't yet really know what that packet > overhead looks like. If this is all DTLS then maybe apps want to eat that > anyway. > > Eliot > > > On 3/25/15 4:38 PM, Aaron Falk wrote: > > If we take SPUD's goals at their most minimal, as expressed by Ted, of > enabling passage of encrypted traffic through middleboxes, can someone > explain why PCP is not sufficient? > > --aaron > > > _______________________________________________ > Spud mailing listSpud@ietf.orghttps://www.ietf.org/mailman/listinfo/spud > > > --001a113fefc2b2f88a051235ba57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI Eliot-

I don't understand your r= esponse.=C2=A0 Could you expand on it a little?=C2=A0 Are you saying they b= oth solve the problem but SPUD is more efficient?

= --aaron

On Thu, Mar 26, 2015 at 7:02 AM, Eliot Lear <lear@cisco.com> = wrote:
=20 =20 =20
Aaron,

I view this stuff differently.=C2=A0 It's not whether an extra prot= ocol can do the job, but whether there can be another implicit contract built, at least in the case of directionality.=C2=A0 That could be a tradeoff between signaling delay and packet overhead, but we don't yet really know what that packet overhead looks like.=C2=A0 If this is all DTLS then maybe apps want to eat that anyway.

Eliot


On 3/25/15 4:38 PM, Aaron Falk wrote:
=20
If we take SPUD's goals at their most minimal, a= s expressed by Ted, of enabling passage of encrypted traffic through middleboxes, can someone explain why PCP is not sufficient? =C2=A0

--aaron


________________________________________=
_______
Spud mailing list
Spud@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/spud


--001a113fefc2b2f88a051235ba57-- From nobody Thu Mar 26 12:31:41 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006EF1B2DDC for ; Thu, 26 Mar 2015 12:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qET-RG3In6YN for ; Thu, 26 Mar 2015 12:31:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CCD1B2B38 for ; Thu, 26 Mar 2015 12:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3328; q=dns/txt; s=iport; t=1427398279; x=1428607879; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ywE8SRspsp1zgD41eUl7djMCRNyFJvBBw2UVbkE92LE=; b=LlTS4REUHdBTEeLhYBGp8XBlryFLzDAV0uWyyMcVKkm+DDX6dlV5CwKj 9He7hPegMColJn+W9sWlnQldzHL1gUTmRjjGSe/6GMEbYCv29tjIvm/qn 5VJOUBLDyxCVQZcGdVZT+fwDmTkk+IHubbGX/urjYo0pdIxPRX3bQnxgV s=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQAnXhRV/5hdJa1cgwaEPsgUAoFeTAEBAQEBAX2EFQEBBCNVARALBAETCRYLAgIJAwIBAgFFBg0BBwEBiCuyB5o4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sohHgHgmiBRQEEixOHJoEyhlSBG4VpiWKDRyKEDCCCdAEBAQ X-IronPort-AV: E=Sophos;i="5.11,474,1422921600"; d="asc'?scan'208,217";a="407312293" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 26 Mar 2015 19:31:19 +0000 Received: from [10.89.6.58] (rcdn-vpn-client-10-89-6-58.cisco.com [10.89.6.58]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2QJVHRJ011414; Thu, 26 Mar 2015 19:31:17 GMT Message-ID: <55145E83.9090608@cisco.com> Date: Thu, 26 Mar 2015 14:31:15 -0500 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Aaron Falk References: <5513F563.50702@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="83aMTJ8hj9cGAsXsiG2xfTDK8xAxuGDDt" Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --83aMTJ8hj9cGAsXsiG2xfTDK8xAxuGDDt Content-Type: multipart/alternative; boundary="------------010006010801050105000107" This is a multi-part message in MIME format. --------------010006010801050105000107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/26/15 2:07 PM, Aaron Falk wrote: > HI Eliot- > > I don't understand your response. Could you expand on it a little?=20 > Are you saying they both solve the problem but SPUD is more efficient? There are potential efficiency tradeoffs, depending on whether the results of the work lead to additional packet overhead or not (we cannot yet say what that tradeoff is). PCP requires setup but there is no packet overhead. The reason that SPUD doesn't require setup is that it is implicit and observable in the same way TCP is, and the intentions are clear to everyone. That has been a good way to protect hosts from some forms of attack, such as DOS/DDOS. Eliot --------------010006010801050105000107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 3/26/15 2:07 PM, Aaron Falk wrote:<= br>
HI Eliot-

I don't understand your response.=C2=A0 Could you expand on = it a little?=C2=A0 Are you saying they both solve the problem but SP= UD is more efficient?

There are potential efficiency tradeoffs, depending on whether the results of the work lead to additional packet overhead or not (we cannot yet say what that tradeoff is).=C2=A0 PCP requires setup but t= here is no packet overhead.=C2=A0 The reason that SPUD doesn't require set= up is that it is implicit and observable in the same way TCP is, and the intentions are clear to everyone.=C2=A0 That has been a good way = to protect hosts from some forms of attack, such as DOS/DDOS.

Eliot
--------------010006010801050105000107-- --83aMTJ8hj9cGAsXsiG2xfTDK8xAxuGDDt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJVFF6DAAoJEIe2a0bZ0nozFEMH/jaTWQ7nw37MhviSr0f//i2E GNKc3uwkvM/79UL1ZIMTtWOk35DYFYwdwt5ShYGwd8L3Z0naui4tmz91cwEjQt18 S4SAE/PJsNl8va/ysZXS6b2dievosQ5UwR98cs/b+Ipv3zNc3lO0wYu0mVAJh2i5 DrJxiPstlY5pTLAfRD0317gEx8v0jzKEnSQm79dSDD3kXjB2CsXgI0A+xhlMD0Wh 6fm4nU4dShdv7wJXDXfu5Cf1dAKt18oKWjr8MkeO/n8F9TBIhzUlZDRsdmtaDLx8 xvYgXkChxV2DHN2qhWIKqHYZWzHiFVVSa1Si3uMSI9JYlHgiyI5yrVN+a+925OE= =pa0V -----END PGP SIGNATURE----- --83aMTJ8hj9cGAsXsiG2xfTDK8xAxuGDDt-- From nobody Thu Mar 26 12:55:46 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED32E1B2B87 for ; Thu, 26 Mar 2015 12:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 wLHwDueI-OyH for ; Thu, 26 Mar 2015 12:55:44 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 97B361A00E0 for ; Thu, 26 Mar 2015 12:55:40 -0700 (PDT) Received: by lagg8 with SMTP id g8so54465645lag.1 for ; Thu, 26 Mar 2015 12:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Y7OjdbdNP+j5+9qYHihZi3MB6x35OrxFb5ZW64ea64A=; b=drsTLrgsJbno94F8zNt4/odOeRsUbAFt6pKfeBiTNYlR4WO9dD5odBFS0QstOYzrXn z0wzdW7lCcqCvR5s0h2Y8z2tLl2Z7uh1kLPO7hP8WgElFSAzK1xXPIK74fCuK7vRFKCT 0YrOC3g4DlwdXJVyrI/Um5lBSRKKedJSnyOv60nKksOdP0s9kvjJKGUrsvrI9iJb3ID4 XRBJyab//Msl3e+NIi0TlKAI5ka4QH84th+Ohrc2lQeaktUUYMTwF01wZXLbnFrOPwFQ Moc718IhlLwbK2VVVnr/qm3hvcXOxAQ2w1Ox6za5Tg/IHphTqnL35Jdkc72+ZytwQogu dA5w== MIME-Version: 1.0 X-Received: by 10.152.4.136 with SMTP id k8mr14790798lak.103.1427399739040; Thu, 26 Mar 2015 12:55:39 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Thu, 26 Mar 2015 12:55:38 -0700 (PDT) Date: Thu, 26 Mar 2015 14:55:38 -0500 X-Google-Sender-Auth: 0WzGHIG5r9cw3LeWuLVfvX2Py9U Message-ID: From: Phillip Hallam-Baker To: Spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] Types of flow pattern and NAT impact? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:55:45 -0000 Different applications have different flow patterns and the differences make a difference when it comes to a middlebox deciding when to tear down a NAT association or the endpoints are striving to keep it open. I think it is useful to enumerate the various flow patterns and to take into account that these are typically directed. In the home network we have 1-150 IP addresses on one side and one IP address on the other. In the enterprise or 'carrier grade NAT' setting we have a larger pool of IP addresses that are being mapped to, but the choice of address within a pool is typically random. While it is possible to use multiple layers of NAT and even NAT that does not involve Internet addresses at all, I find it easiest to get my head round a problem thinking in terms of a 'local' network and the 'remote' and to focus on the NAT box on the local side. For many interesting cases (peer to peer voip, audio, etc) we will have NAT boxen on both sides of course. There are two basic cases: 1) The communication session is initiated by the local party 2) The communication session is initiated by the remote party The second case requires some form of Port Control (e.g. RFC6887) which is an explicit interaction with the local NAT (or else how does the first packet know where to go?). But this does not mean that there is no SPUD implication as SPUD traffic might well be an implicit keep alive on the port control. For message types, I see an important distinction between idempotent and statefull sessions. There are some protocols where UDP is used to effect a stateless interaction with one server from a pool, which server is chosen does not matter. The main use for an idempotent UDP interaction is of course DNS. But fast idempotent protocol is useful in many other circumstances: OCSP lookup, Peer-to-peer discovery, content routing, certificate directories, key servers etc. etc. The DNS protocol limits transactions to a single request and a single response. Fitting a request into one UDP packet is much easier than fitting a response into one packet. So an idempotent UDP transaction might consist of one request packet followed by 0-16 (say) response packets. There is obviously a limit to the number of packets that can be returned without some sort of mechanism to detect and retransmit dropped packets which will require state. And obviously in the modern internet, any stateless service that requires any significant effort and does not authenticate requests is going to result in wailing and gnashing of teeth as it gets DoSed or used as an attack proxy. For stateful flows we can have one tube or many. But is that something the NAT box needs to know about? If not, I want the data in my encrypted payload. From nobody Fri Mar 27 07:23:12 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B753F1A8700; Thu, 26 Mar 2015 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 qIeFwwDIQeN8; Thu, 26 Mar 2015 07:06:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778581A88C8; Thu, 26 Mar 2015 07:06:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EE58F3B430B; Thu, 26 Mar 2015 15:06:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C799927C058; Thu, 26 Mar 2015 15:06:51 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 15:06:51 +0100 From: To: "Tirumaleswar Reddy (tireddy)" , Aaron Falk , "spud@ietf.org" Thread-Topic: [Spud] PCP vs. SPUD Thread-Index: AQHQZ0P9fkfGXDN/UUCaOAQAWpF0oZ0uK8OwgAChdFA= Date: Thu, 26 Mar 2015 14:06:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330052DBD45OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 07:23:10 -0700 Cc: "pcp@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:06:55 -0000 --_000_787AE7BB302AE849A7480A190F8B9330052DBD45OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGlydSwgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgUENQIHNvbHZlcyBhbm90 aGVyIHByb2JsZW0gdGhhdCB3ZSByZWNvcmRlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYm91Y2FkYWlyLXRyYW5zcG9ydC1wcm90b2NvbHMtMDENCg0KICAgICAgRXZlbiBp ZiBwcm90b2NvbHMgZW5jYXBzdWxhdGVkIG92ZXIgVURQIGNhbiBtYWtlIHVzZSBvZiBOQVQNCiAg ICAgIHRyYXZlcnNhbCB0ZWNobmlxdWVzLCB0aGVzZSBwcm90b2NvbHMgYXJlIHN0aWxsIHN1ZmZl cmluZyBmcm9tDQogICAgICBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgcHJlc2VuY2Ugb2YgTkFUcyBh bmQgZmlyZXdhbGxzLiAgRm9yDQogICAgICBleGFtcGxlLCB0aGVyZSBpcyBubyBtZWNoYW5pc20g dG8gbm90aWZ5IGVuZHBvaW50cyB0aGF0IGFuIGVudHJ5DQogICAgICBpcyBubyBtb3JlIGFjdGl2 ZSBpbiB0aGUgTkFUL0ZpcmV3YWxsLiAgSW1tZWRpYXRlIG5vdGlmaWNhdGlvbiBhbmQNCiAgICAg IHN0YXRlIHJlY292ZXJ5IGNhbiBiZSBzb2x2ZWQgYnkgYWN0aXZhdGluZyBzcGVjaWZpYyBQb3J0 IENvbnRyb2wNCiAgICAgIFByb3RvY29sIChQQ1ApIGZlYXR1cmU6IChQQ1AgQU5OT1VOQ0UgT1BD T0RFLCBbUkZDNjg4NzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjg4Nz5dKS4NCg0K Q2hlZXJzLA0KTWVkDQoNCkRlIDogcGNwIFttYWlsdG86cGNwLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KRW52b3nDqSA6IG1lcmNy ZWRpIDI1IG1hcnMgMjAxNSAyMzozNA0Kw4AgOiBBYXJvbiBGYWxrOyBzcHVkQGlldGYub3JnDQpD YyA6IHBjcEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3BjcF0gW1NwdWRdIFBDUCB2cy4gU1BVRA0K DQpZZXMsIFBDUCBjYW4gYmUgdXNlZCB0byBjb21tdW5pY2F0ZSB3aXRoIG1pZGRsZSBib3hlcyB0 byBvcGVuIGFuZCBjbG9zZSBwaW5ob2xlczsgUENQIGFsc28gaGFuZGxlcyBhdHRhY2tzIGxpa2Ug YXR0YWNrZXIgY2xvc2luZyB0aGUgcGluaG9sZXMgb3BlbmVkIGJ5IHRoZSB2aWN0aW0gb3IgYXR0 YWNrZXIgb3BlbmluZyBwaW5ob2xlcyBvbiBiZWhhbGYgb2YgdmljdGltIHRvIGxhdW5jaCBERE9T IGF0dGFja3MsIGFsbG93IG9ubHkgYXV0aG9yaXplZCBlbmRwb2ludHMgdG8gb3Blbi9jbG9zZSBw aW5ob2xlcyBldGMuDQoNCi1UaXJ1DQoNCg0KRnJvbTogU3B1ZCBbbWFpbHRvOnNwdWQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFhcm9uIEZhbGsNClNlbnQ6IFRodXJzZGF5LCBNYXJj aCAyNiwgMjAxNSAzOjA4IEFNDQpUbzogc3B1ZEBpZXRmLm9yZzxtYWlsdG86c3B1ZEBpZXRmLm9y Zz4NClN1YmplY3Q6IFtTcHVkXSBQQ1AgdnMuIFNQVUQNCg0KSWYgd2UgdGFrZSBTUFVEJ3MgZ29h bHMgYXQgdGhlaXIgbW9zdCBtaW5pbWFsLCBhcyBleHByZXNzZWQgYnkgVGVkLCBvZiBlbmFibGlu ZyBwYXNzYWdlIG9mIGVuY3J5cHRlZCB0cmFmZmljIHRocm91Z2ggbWlkZGxlYm94ZXMsIGNhbiBz b21lb25lIGV4cGxhaW4gd2h5IFBDUCBpcyBub3Qgc3VmZmljaWVudD8NCg0KLS1hYXJvbg0K --_000_787AE7BB302AE849A7480A190F8B9330052DBD45OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGV4 dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZv cm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFRpcnUsIGFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgUENQ IHNvbHZlcyBhbm90aGVyIHByb2JsZW0gdGhhdCB3ZSByZWNvcmRlZCBpbg0KPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci10cmFuc3BvcnQtcHJvdG9j b2xzLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXRyYW5z cG9ydC1wcm90b2NvbHMtMDE8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV2ZW4gaWYgcHJvdG9jb2xzIGVu Y2Fwc3VsYXRlZCBvdmVyIFVEUCBjYW4gbWFrZSB1c2Ugb2YgTkFUPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhdmVyc2FsIHRlY2huaXF1ZXMsIHRoZXNlIHByb3Rv Y29scyBhcmUgc3RpbGwgc3VmZmVyaW5nIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgcHJlc2VuY2Ugb2YgTkFUcyBhbmQg ZmlyZXdhbGxzLiZuYnNwOyBGb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBleGFtcGxlLCB0aGVyZSBpcyBubyBtZWNoYW5pc20gdG8gbm90aWZ5IGVuZHBvaW50cyB0 aGF0IGFuIGVudHJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMg bm8gbW9yZSBhY3RpdmUgaW4gdGhlIE5BVC9GaXJld2FsbC4mbmJzcDsgSW1tZWRpYXRlIG5vdGlm aWNhdGlvbiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdGF0 ZSByZWNvdmVyeSBjYW4gYmUgc29sdmVkIGJ5IGFjdGl2YXRpbmcgc3BlY2lmaWMgUG9ydCBDb250 cm9sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJvdG9jb2wgKFBD UCkgZmVhdHVyZTogKFBDUCBBTk5PVU5DRSBPUENPREUsIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODg3IiB0aXRsZT0iJnF1b3Q7UG9y dCBDb250cm9sIFByb3RvY29sIChQQ1ApJnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjg4 Nzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XSkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHBjcCBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4g VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBt ZXJjcmVkaSAyNSBtYXJzIDIwMTUgMjM6MzQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEFhcm9uIEZh bGs7IHNwdWRAaWV0Zi5vcmc8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IHBjcEBpZXRmLm9yZzxicj4N CjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtwY3BdIFtTcHVkXSBQQ1AgdnMuIFNQVUQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgUENQIGNhbiBiZSB1 c2VkIHRvIGNvbW11bmljYXRlIHdpdGggbWlkZGxlIGJveGVzIHRvIG9wZW4gYW5kIGNsb3NlIHBp bmhvbGVzOyBQQ1AgYWxzbyBoYW5kbGVzIGF0dGFja3MgbGlrZSBhdHRhY2tlciBjbG9zaW5nIHRo ZSBwaW5ob2xlcyBvcGVuZWQNCiBieSB0aGUgdmljdGltIG9yIGF0dGFja2VyIG9wZW5pbmcgcGlu aG9sZXMgb24gYmVoYWxmIG9mIHZpY3RpbSB0byBsYXVuY2ggRERPUyBhdHRhY2tzLCBhbGxvdyBv bmx5IGF1dGhvcml6ZWQgZW5kcG9pbnRzIHRvIG9wZW4vY2xvc2UgcGluaG9sZXMgZXRjLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFNwdWQgWzxhIGhyZWY9Im1haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHVk LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BYXJvbiBGYWxrPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjA4IEFNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c3B1ZEBpZXRmLm9yZyI+c3B1ZEBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1NwdWRdIFBDUCB2cy4gU1BVRDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB3ZSB0YWtlIFNQVUQncyBnb2FscyBhdCB0aGVp ciBtb3N0IG1pbmltYWwsIGFzIGV4cHJlc3NlZCBieSBUZWQsIG9mIGVuYWJsaW5nIHBhc3NhZ2Ug b2YgZW5jcnlwdGVkIHRyYWZmaWMgdGhyb3VnaCBtaWRkbGVib3hlcywgY2FuIHNvbWVvbmUgZXhw bGFpbiB3aHkgUENQIGlzIG5vdCBzdWZmaWNpZW50PyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLWFhcm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330052DBD45OPEXCLILMA3corp_-- From nobody Fri Mar 27 07:51:38 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93071A8834; Fri, 27 Mar 2015 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 uJBHWG0TvXer; Fri, 27 Mar 2015 07:46:46 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 4BFDE1ACEB4; Fri, 27 Mar 2015 07:46:19 -0700 (PDT) Received: by oifl3 with SMTP id l3so77808366oif.0; Fri, 27 Mar 2015 07:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UrWVLF7biWWpgVmUNwuvFhaAwb7XPZovA5P3hLWf+4=; b=GXcf10XsxXJJLTNrtPgWz4L6h/Ux0LoWnw3T1+ojTAEQF89fVn4GNmaWdi/rm69ikF SvCD0F7+ZszqZc2+4MTlMtnNRq04PlcL5xxLFjks+SfiP7tHkASd8E0s8V3ef18sim36 USp580Zv/TPT2Tl2srjzyobuLsedfXzQzN+IRTDyPoXWfWpPIZnwAK3ZNwCXDvFn7+Yj L716EErR84Mry6drtnyQIm5zoYBuW+0X9mPsXcmKBBtzDtzXnjZ5qKbCTjKFOVC7EBnJ 7eSIYOenSDJOxgtR+IDLFGzfJpGiPcUZxYUi/YmJBSNoS5jGUuwKI63BVu4Ws0f363OU SqRg== X-Received: by 10.60.103.116 with SMTP id fv20mr2501294oeb.2.1427467578828; Fri, 27 Mar 2015 07:46:18 -0700 (PDT) Received: from [10.197.51.160] ([166.177.122.219]) by mx.google.com with ESMTPSA id v4sm1098074oec.7.2015.03.27.07.46.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 07:46:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A473137B-C234-40A1-A143-F36613BA3251 Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPhone Mail (12B436) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 27 Mar 2015 09:46:19 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1A23686B-6089-4A72-86E3-6703648B783D@gmail.com> References: <913383AAA69FF945B8F946018B75898A366D0A57@xmb-rcd-x10.cisco.com> <787AE7BB302AE849A7480A190F8B9330052DBD45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: "" Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 07:51:36 -0700 Cc: Aaron Falk , "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , "spud@ietf.org" Subject: Re: [Spud] PCP vs. SPUD X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 14:46:49 -0000 --Apple-Mail-A473137B-C234-40A1-A143-F36613BA3251 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The question I think needs to be considered is whether spud layers on Pcp or= is an alternative way of obtaining that functionality If the second, to what extent can we reuse ? Opening inbound ports is clearly one aspect of the spud problem but only one= Sent from my difference engine > On Mar 26, 2015, at 09:06, wrote: >=20 > Hi Tiru, all, > =20 > I would like to add that PCP solves another problem that we recorded in ht= tps://tools.ietf.org/html/draft-boucadair-transport-protocols-01 > =20 > Even if protocols encapsulated over UDP can make use of NAT > traversal techniques, these protocols are still suffering from > issues related to the presence of NATs and firewalls. For > example, there is no mechanism to notify endpoints that an entry > is no more active in the NAT/Firewall. Immediate notification and > state recovery can be solved by activating specific Port Control > Protocol (PCP) feature: (PCP ANNOUNCE OPCODE, [RFC6887]). > =20 > Cheers, > Med > =20 > De : pcp [mailto:pcp-bounces@ietf.org] De la part de Tirumaleswar Reddy (t= ireddy) > Envoy=C3=A9 : mercredi 25 mars 2015 23:34 > =C3=80 : Aaron Falk; spud@ietf.org > Cc : pcp@ietf.org > Objet : Re: [pcp] [Spud] PCP vs. SPUD > =20 > Yes, PCP can be used to communicate with middle boxes to open and close pi= nholes; PCP also handles attacks like attacker closing the pinholes opened b= y the victim or attacker opening pinholes on behalf of victim to launch DDOS= attacks, allow only authorized endpoints to open/close pinholes etc. > =20 > -Tiru > =20 > =20 > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Aaron Falk > Sent: Thursday, March 26, 2015 3:08 AM > To: spud@ietf.org > Subject: [Spud] PCP vs. SPUD > =20 > If we take SPUD's goals at their most minimal, as expressed by Ted, of ena= bling passage of encrypted traffic through middleboxes, can someone explain w= hy PCP is not sufficient? =20 > =20 > --aaron > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail-A473137B-C234-40A1-A143-F36613BA3251 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The question I think needs to be consi= dered is whether spud layers on Pcp or is an alternative way of obtaining th= at functionality

If the second, to what extent can w= e reuse ?

Opening inbound ports is clearly one aspe= ct of the spud problem but only one



Sent fr= om my difference engine


On Mar 26, 2015, at 09:= 06, <mohamed.boucadair@or= ange.com> <mohamed= .boucadair@orange.com> wrote:

=

Hi Tiru, all,

 

I would like to add that PCP solv= es another problem that we recorded in https://tools.ietf.org/html/draft-boucadair-transport-protocols-01

 

      Even if protoc= ols encapsulated over UDP can make use of NAT

      traversal tech= niques, these protocols are still suffering from

      issues related= to the presence of NATs and firewalls.  For

      example, there= is no mechanism to notify endpoints that an entry

      is no more act= ive in the NAT/Firewall.  Immediate notification and<= /p>

      state recovery= can be solved by activating specific Port Control

      Protocol (PCP)= feature: (PCP ANNOUNCE OPCODE, [= RFC6887]).

 

Cheers,

Med

 

De : pcp [mailto:pcp-bounces@ietf.org] De la part de Tirumaleswar Reddy (tireddy)
Envoy=C3=A9 : mercredi 25 mars 2015 23:34
=C3=80 : Aaron Falk; spud@ietf.= org
Cc : pcp@ietf.org
Objet : Re: [pcp] [Spud] PCP vs. SPUD

 

Yes, PCP can= be used to communicate with middle boxes to open and close pinholes; PCP al= so handles attacks like attacker closing the pinholes opened by the victim or attacker opening pinholes on behalf of victim to launch DD= OS attacks, allow only authorized endpoints to open/close pinholes etc.=

 <= /o:p>

-Tiru

 <= /o:p>

 <= /o:p>

From: Spud [mailto:spu= d-bounces@ietf.org] On Behalf Of Aaron Falk
Sent: Thursday, March 26, 2015 3:08 AM
To: spud@ietf.org
Subject: [Spud] PCP vs. SPUD

 

If we take SPUD's goals at their= most minimal, as expressed by Ted, of enabling passage of encrypted traffic= through middleboxes, can someone explain why PCP is not sufficient?  <= o:p>

 

--aaron

____________________= ___________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman= /listinfo/spud
= --Apple-Mail-A473137B-C234-40A1-A143-F36613BA3251-- From nobody Sat Mar 28 17:17:27 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7071A90CE for ; Sat, 28 Mar 2015 17:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GoDKYgeZXaI3 for ; Sat, 28 Mar 2015 17:17:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326951A90D4 for ; Sat, 28 Mar 2015 17:17:21 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (25.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 29 Mar 2015 00:17:19 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.01.0118.022; Sun, 29 Mar 2015 00:17:19 +0000 From: Christian Huitema To: "spud@ietf.org" Thread-Topic: The reset middleboxes attack Thread-Index: AdBps0lZieRUM/cCRaqTbV+IIDrJUw== Date: Sun, 29 Mar 2015 00:17:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.156.113] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(87936001)(62966003)(76576001)(66066001)(54356999)(77156002)(50986999)(2656002)(102836002)(40100003)(86362001)(86612001)(122556002)(92566002)(99286002)(2900100001)(229853001)(2501003)(74316001)(46102003)(2351001)(33656002)(110136001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 0530FCB552 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 00:17:18.6186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: Jana Iyengar , Eric Rescorla Subject: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:17:26 -0000 A key design element out of the SEMI workshop was a request to expose sessi= on "start and stop" to the path. The rationale is that middleboxes could th= en do a more efficient state management than the current timer-based soluti= ons. The hosts would also benefit if they can do away with fewer keep alive= packets to maintain the state open in the middleboxes.=20 But there is a big issue. The end systems can distinguish between valid and= invalid headers because the crypto ensures authentication of the clear tex= t header. An attacker capable of packet injection cannot affect the state o= f the end systems, because the injected packets will fail the crypto checks= um verification and be discarded. But if the hosts are protected, the middl= eboxes are not. They do not have access to the application credentials, and= they cannot perform the crypto checksum verification. This opens the gates= for two attacks. The first and obvious attack is the "middlebox reset" attack. An attacker i= njects a packet with a "stop" mark. Middleboxes on the path see that, and f= ree the state associated with the session. NAT mapping disappear and firewa= ll opening are closed. Even if the hosts are capable of rejecting the fake = reset, their connection is still gone, because further packets will be disc= arded by the middleboxes. One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation, = which reminded me of the old "S-Key" scheme. Suppose that the "open" packet= carries a "hash target" T, composed of an algorithm ID (say SHA256) and a = binary string (32 bytes in the case of SHA256). The middleboxes remember th= at value as part of their state. We then require that the "stop" packets ca= rry a "hash result" R, a binary string of arbitrary size. When the middlebo= xes on path see a reset packet, they check that H(R) =3D T. If it does not,= they detect a spoofed reset, and discard the packet. I can see that implementers may not be enthusiastic with the additional com= plexity. But we would be na=EFve to just dismiss the attack. We do see atta= ckers capable of eavesdropping traffic, and then injecting packets "from th= e side." I am sure that these attackers would find good use of a capability= to nuke connections at will.=20 -- Christian Huitema From nobody Sat Mar 28 19:27:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781F51A1AC1; Sat, 28 Mar 2015 19:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4UpyOXYFgeCx; Sat, 28 Mar 2015 19:27:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87701A9135; Sat, 28 Mar 2015 19:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3209; q=dns/txt; s=iport; t=1427596055; x=1428805655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7+0phH6TSQp8vTpRJj6IIiEJ8avw0Og7h7sDY8R0Pno=; b=UokxKVUb+4Ul13j+s6zp0+FdCwf3XIBKYxG8VQ11pw9dmoM8KUb2VA5N MbHoeFTWbn384MTFMcrx+AmLK91NoYNI/kaKXK6Ww1jZ0gJLbU5CsckLK ia5D+G0SsCvPUDenD62kT+G6d6SR68Ca4OUCIekkF7Ip1NJyKGf+3xoiE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiBQCUYhdV/5NdJa1cgwZSXATDJYIxCoVzAoEfTAEBAQEBAX2EFAEBAQQBAQFkBwsMBAIBCBEEAQELHQcnCxQJCAEBBAENBQgTiBQNym8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymERzEHBoMRgRYFimmFc4Nxh1mSXyKBfwIdgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,486,1422921600"; d="scan'208";a="136324692" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 29 Mar 2015 02:27:35 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2T2RY7w021732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Mar 2015 02:27:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Sat, 28 Mar 2015 21:27:34 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christian Huitema , "spud@ietf.org" Thread-Topic: The reset middleboxes attack Thread-Index: AdBps0lZieRUM/cCRaqTbV+IIDrJUwAE3IjA Date: Sun, 29 Mar 2015 02:27:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D2FB6@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , Eric Rescorla , "pcp@ietf.org" Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 02:27:37 -0000 These two problems are already addressed in PCP. PCP authentication http://= tools.ietf.org/html/draft-ietf-pcp-authentication-07 ensures that only the = authenticated and authorized endpoint can open and close firewall pin-holes= .=20 PCP https://tools.ietf.org/html/draft-ietf-pcp-optimize-keepalives-05 can a= lso help reduce the NAT and firewall keepalive messages. -Tiru > -----Original Message----- > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Christian Huitema > Sent: Sunday, March 29, 2015 5:47 AM > To: spud@ietf.org > Cc: Jana Iyengar; Eric Rescorla > Subject: [Spud] The reset middleboxes attack >=20 > A key design element out of the SEMI workshop was a request to expose ses= sion > "start and stop" to the path. The rationale is that middleboxes could the= n do a > more efficient state management than the current timer-based solutions. T= he > hosts would also benefit if they can do away with fewer keep alive packet= s to > maintain the state open in the middleboxes. >=20 > But there is a big issue. The end systems can distinguish between valid a= nd invalid > headers because the crypto ensures authentication of the clear text heade= r. An > attacker capable of packet injection cannot affect the state of the end s= ystems, > because the injected packets will fail the crypto checksum verification a= nd be > discarded. But if the hosts are protected, the middleboxes are not. They = do not > have access to the application credentials, and they cannot perform the c= rypto > checksum verification. This opens the gates for two attacks. >=20 > The first and obvious attack is the "middlebox reset" attack. An attacker= injects a > packet with a "stop" mark. Middleboxes on the path see that, and free the= state > associated with the session. NAT mapping disappear and firewall opening a= re > closed. Even if the hosts are capable of rejecting the fake reset, their = connection > is still gone, because further packets will be discarded by the middlebox= es. >=20 > One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation= , > which reminded me of the old "S-Key" scheme. Suppose that the "open" pack= et > carries a "hash target" T, composed of an algorithm ID (say SHA256) and a= binary > string (32 bytes in the case of SHA256). The middleboxes remember that va= lue as > part of their state. We then require that the "stop" packets carry a "has= h result" > R, a binary string of arbitrary size. When the middleboxes on path see a = reset > packet, they check that H(R) =3D T. If it does not, they detect a spoofed= reset, and > discard the packet. >=20 > I can see that implementers may not be enthusiastic with the additional > complexity. But we would be na=EFve to just dismiss the attack. We do see > attackers capable of eavesdropping traffic, and then injecting packets "f= rom the > side." I am sure that these attackers would find good use of a capability= to nuke > connections at will. >=20 > -- Christian Huitema >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Sat Mar 28 20:02:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0045E1A9104 for ; Sat, 28 Mar 2015 18:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8dgzYgBvJx7Z for ; Sat, 28 Mar 2015 18:07:25 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 01D061A9100 for ; Sat, 28 Mar 2015 18:07:25 -0700 (PDT) Received: by wibg7 with SMTP id g7so65061428wib.1 for ; Sat, 28 Mar 2015 18:07:23 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=AbgzsJzyLHHhlGBxVP/CJzDDWD6LSHxbYMdui4SZKgQ=; b=FXkA6/8+TAB45iVo6LJKB0jbctmqkP+sqP8Qu1dbhs9MOpaKAZYnmgklmnmqgpmb4R 46PxNqZRIEsV8c3ZFd1CGUxfL6JneNA4CMBlUHmuh8jxOcgC3z+TgfEB1EKD3QB3gXrN M1XTa7rtM/vYJkkWSJ8QSxnazyxPrYn4k6jSIOHRnK1+N+IKetAf+Ljo3o1YgNNZitYl JiefdwKekOmCzHDlW9CJnFVkkmetvZkwLmYvvtL/hsPU6yn9hJQ7zfUo3iiFuTx4VYD2 Ni0nAUTAJzvLjAtFQb2IRL00GzmE7Ikd041r2/yj6kxLBoEisziCaRtj7spg7VdqYZZ1 cCbw== X-Gm-Message-State: ALoCoQnSyYe8Rg/r3ucaCoaAzGFkrkDfPUBszTf0rZvkN2L0MOnrf39ZgJpdIp7ONWyqUXbajfth X-Received: by 10.194.190.10 with SMTP id gm10mr50142234wjc.91.1427591243631; Sat, 28 Mar 2015 18:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 28 Mar 2015 18:06:43 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 28 Mar 2015 18:06:43 -0700 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=047d7bea39f4f62637051262fc26 Archived-At: X-Mailman-Approved-At: Sat, 28 Mar 2015 20:02:39 -0700 Cc: Jana Iyengar , "spud@ietf.org" Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 01:07:27 -0000 --047d7bea39f4f62637051262fc26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2015 at 5:17 PM, Christian Huitema wrote: > A key design element out of the SEMI workshop was a request to expose > session "start and stop" to the path. The rationale is that middleboxes > could then do a more efficient state management than the current > timer-based solutions. The hosts would also benefit if they can do away > with fewer keep alive packets to maintain the state open in the middlebox= es. > > But there is a big issue. The end systems can distinguish between valid > and invalid headers because the crypto ensures authentication of the clea= r > text header. An attacker capable of packet injection cannot affect the > state of the end systems, because the injected packets will fail the cryp= to > checksum verification and be discarded. But if the hosts are protected, t= he > middleboxes are not. They do not have access to the application > credentials, and they cannot perform the crypto checksum verification. Th= is > opens the gates for two attacks. > > The first and obvious attack is the "middlebox reset" attack. An attacker > injects a packet with a "stop" mark. Middleboxes on the path see that, an= d > free the state associated with the session. NAT mapping disappear and > firewall opening are closed. Even if the hosts are capable of rejecting t= he > fake reset, their connection is still gone, because further packets will = be > discarded by the middleboxes. > > One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation= , > which reminded me of the old "S-Key" scheme. Suppose that the "open" pack= et > carries a "hash target" T, composed of an algorithm ID (say SHA256) and a > binary string (32 bytes in the case of SHA256). The middleboxes remember > that value as part of their state. We then require that the "stop" packet= s > carry a "hash result" R, a binary string of arbitrary size. When the > middleboxes on path see a reset packet, they check that H(R) =3D T. If it > does not, they detect a spoofed reset, and discard the packet. > Actually it was AGL. -Ekr > I can see that implementers may not be enthusiastic with the additional > complexity. But we would be na=C3=AFve to just dismiss the attack. We do = see > attackers capable of eavesdropping traffic, and then injecting packets > "from the side." I am sure that these attackers would find good use of a > capability to nuke connections at will. > > -- Christian Huitema > > --047d7bea39f4f62637051262fc26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 28, 2015 at 5:17 PM, Christian Huitema &l= t;huitema@micros= oft.com> wrote:
A key desig= n element out of the SEMI workshop was a request to expose session "st= art and stop" to the path. The rationale is that middleboxes could the= n do a more efficient state management than the current timer-based solutio= ns. The hosts would also benefit if they can do away with fewer keep alive = packets to maintain the state open in the middleboxes.

But there is a big issue. The end systems can distinguish between valid and= invalid headers because the crypto ensures authentication of the clear tex= t header. An attacker capable of packet injection cannot affect the state o= f the end systems, because the injected packets will fail the crypto checks= um verification and be discarded. But if the hosts are protected, the middl= eboxes are not. They do not have access to the application credentials, and= they cannot perform the crypto checksum verification. This opens the gates= for two attacks.

The first and obvious attack is the "middlebox reset" attack. An = attacker injects a packet with a "stop" mark. Middleboxes on the = path see that, and free the state associated with the session. NAT mapping = disappear and firewall opening are closed. Even if the hosts are capable of= rejecting the fake reset, their connection is still gone, because further = packets will be discarded by the middleboxes.

One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation, = which reminded me of the old "S-Key" scheme. Suppose that the &qu= ot;open" packet carries a "hash target" T, composed of an al= gorithm ID (say SHA256) and a binary string (32 bytes in the case of SHA256= ). The middleboxes remember that value as part of their state. We then requ= ire that the "stop" packets carry a "hash result" R, a = binary string of arbitrary size. When the middleboxes on path see a reset p= acket, they check that H(R) =3D T. If it does not, they detect a spoofed re= set, and discard the packet.

Actually i= t was AGL.

-Ekr
=C2=A0
I can see that implementers may not be enthusiastic with the additional com= plexity. But we would be na=C3=AFve to just dismiss the attack. We do see a= ttackers capable of eavesdropping traffic, and then injecting packets "= ;from the side." I am sure that these attackers would find good use of= a capability to nuke connections at will.

-- Christian Huitema


--047d7bea39f4f62637051262fc26-- From nobody Sun Mar 29 01:28:10 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1F1A00C3 for ; Sun, 29 Mar 2015 01:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 4yYmBHwKXKRr for ; Sun, 29 Mar 2015 01:28:07 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 80C521A007C for ; Sun, 29 Mar 2015 01:28:07 -0700 (PDT) Received: by wiaa2 with SMTP id a2so85429792wia.0 for ; Sun, 29 Mar 2015 01:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1aWR4cBF3sMGOg1mxEcWL5VLIXT2WEESx/2p00XCvA4=; b=OAQopWdo/Ushle2C9aslUgAAwQIPSrbLqypr9/c6+eCe1yq8RfIWFhAaVtiPdOdfBQ zs2HZDXc1VU/wFQk9tmJaYS8wlygp1PcfCjvnI5dVfHuS6ZMGA2qHMcs9T/RhJybWRIe m+DTUZbA/mx1qjDeuL2UsYNsR4Ie6edyciKU0m28hdHnbfirh8ffQ0DrpqnhIsWnRLgw R3iAlcEVIuTRS64c9N43iAdwIL9P/nfmvL2gcYFLDUPnAKrh75orFM/qMs4olSZyY/6/ rDgw0BOX4VZBeN2a3yeA6APSPc81n4VUcQH/vfKmzzSeQ0K9Lqcol/YomH3ZCyYfBL8S QIGw== X-Received: by 10.194.222.197 with SMTP id qo5mr51621815wjc.142.1427617686096; Sun, 29 Mar 2015 01:28:06 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id i10sm10265874wja.40.2015.03.29.01.28.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 01:28:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 29 Mar 2015 11:28:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> References: To: Christian Huitema X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Jana Iyengar , Eric Rescorla , "spud@ietf.org" Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 08:28:09 -0000 > On Mar 29, 2015, at 3:17 AM, Christian Huitema = wrote: >=20 > A key design element out of the SEMI workshop was a request to expose = session "start and stop" to the path. The rationale is that middleboxes = could then do a more efficient state management than the current = timer-based solutions. The hosts would also benefit if they can do away = with fewer keep alive packets to maintain the state open in the = middleboxes.=20 >=20 > But there is a big issue. The end systems can distinguish between = valid and invalid headers because the crypto ensures authentication of = the clear text header. An attacker capable of packet injection cannot = affect the state of the end systems, because the injected packets will = fail the crypto checksum verification and be discarded. But if the hosts = are protected, the middleboxes are not. They do not have access to the = application credentials, and they cannot perform the crypto checksum = verification. This opens the gates for two attacks. >=20 > The first and obvious attack is the "middlebox reset" attack. An = attacker injects a packet with a "stop" mark. Middleboxes on the path = see that, and free the state associated with the session. NAT mapping = disappear and firewall opening are closed. Even if the hosts are capable = of rejecting the fake reset, their connection is still gone, because = further packets will be discarded by the middleboxes. >=20 > One of my coauthors (EKR or Jana, cannot remember) suggested a = mitigation, which reminded me of the old "S-Key" scheme. Suppose that = the "open" packet carries a "hash target" T, composed of an algorithm ID = (say SHA256) and a binary string (32 bytes in the case of SHA256). The = middleboxes remember that value as part of their state. We then require = that the "stop" packets carry a "hash result" R, a binary string of = arbitrary size. When the middleboxes on path see a reset packet, they = check that H(R) =3D T. If it does not, they detect a spoofed reset, and = discard the packet. >=20 > I can see that implementers may not be enthusiastic with the = additional complexity. But we would be na=EFve to just dismiss the = attack. We do see attackers capable of eavesdropping traffic, and then = injecting packets "from the side." I am sure that these attackers would = find good use of a capability to nuke connections at will.=20 Hi, Christian I understand the issue. Is this something we are really worried about? = It has always been possible to do this with TCP by sending a RST, and = that worked on the endpoints as well, and TLS has never protected us = from that attack. To get the solution to work, presumably the initiator generates a secret = and sends its has in the OPEN command. This allows the initiator to = close the connection by sending the pre-image. But what if we want both = sides to be able to close the connection? We either need to transmit the = pre-image in the encrypted part of the protocol (what Joe=92s = architecture diagram calls =93transport=94), or we need a per-endpoint = hash, requiring the responder to also send a hash in the ACK command. = The latter doubles the state on the middlebox. Yoav= From nobody Sun Mar 29 04:59:01 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F101A8750 for ; Sun, 29 Mar 2015 04:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ZyD3hFJ84ZA9 for ; Sun, 29 Mar 2015 04:59:00 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 AB08F1A874E for ; Sun, 29 Mar 2015 04:58:59 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so90155493lbc.0 for ; Sun, 29 Mar 2015 04:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=otH/IXZqQkPvygXpJwdEtGJcxUNCVKgBN01wOEmeZUk=; b=Soe6G7Ras9kOwcU3s9byfOSHGUjNvWLoo0CeN3pxvi8/UeptwQ92HmBeuEDATjFI5C rW3WoAK8B+JEp2M6crz+TfcYfMFvqzlxfuzlaW2/S9JWP+9Tp6T5Mxhn9uosCeUfMa4f 8hQ/pfHOy16RlejtuuD5DNYhbVJPqNKkfs87hIfpgAf0zPs6hzWhFevlGtmEtTgTJXvT 80KKhNga0ZnX3Oc5bIcLC4ac3R2QF1FDgRb0JmnHJjN0CXmHOEZlFeJktA5J6SiiebHN BzmCZV8eIifSr12Ktsb8HFs4sT3lAfppIR3RkLlETd/cITScbXhOkvAfMgyV2c8MPhZu hSrQ== MIME-Version: 1.0 X-Received: by 10.112.13.7 with SMTP id d7mr24882327lbc.79.1427630338206; Sun, 29 Mar 2015 04:58:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Sun, 29 Mar 2015 04:58:58 -0700 (PDT) In-Reply-To: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> References: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> Date: Sun, 29 Mar 2015 07:58:58 -0400 X-Google-Sender-Auth: aRozHhDoNWIUQUFGjiYi5QwNvLY Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christian Huitema , Eric Rescorla , "spud@ietf.org" , Jana Iyengar Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 11:59:01 -0000 On Sun, Mar 29, 2015 at 4:28 AM, Yoav Nir wrote: > Hi, Christian > > I understand the issue. Is this something we are really worried about? It= has always been possible to do this with TCP by sending a RST, and that wo= rked on the endpoints as well, and TLS has never protected us from that att= ack. > > To get the solution to work, presumably the initiator generates a secret = and sends its has in the OPEN command. This allows the initiator to close t= he connection by sending the pre-image. But what if we want both sides to b= e able to close the connection? We either need to transmit the pre-image in= the encrypted part of the protocol (what Joe=E2=80=99s architecture diagra= m calls =E2=80=9Ctransport=E2=80=9D), or we need a per-endpoint hash, requi= ring the responder to also send a hash in the ACK command. The latter doubl= es the state on the middlebox. The problem with state these days is not size. It is the fact you need state because once a path is stateful it is fixed. If I have a stateless protocol like DNS over UDP, it does not matter which server/host my packets end up at. If I have to keep one byte of state then it does. That is what causes problems. Here we have already accepted that the middleboxen is stateful Raspberry Pi 2 comes with 1GB of RAM for $40. The chip is much cheaper. It is going to run out of horsepower long before it runs out of RAM. RST attacks are real and are used as attacks against TCP. So it is worth the freight From nobody Sun Mar 29 09:15:38 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9590A1A890E for ; Sun, 29 Mar 2015 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 pZkTZIuqPKIg for ; Sun, 29 Mar 2015 09:15:35 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 13C621A890B for ; Sun, 29 Mar 2015 09:15:35 -0700 (PDT) Received: by wibg7 with SMTP id g7so72636420wib.1 for ; Sun, 29 Mar 2015 09:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o43m5JIcMLmtmBgq5GevCvs/D1W8guFnRoR/VvJRSjI=; b=JBqsdBcQpD40IVDGBxrmBqJ/5Vm3z61GlwKb+bh/hmsE2NDf3ViULQ/nCZoFaigsqv h2P+pv49aRtx+z3L0IdjyS4pyGXRTRJBtSbBVS44HH17hNn36cqkb6+l30p9duB28Lxi CnVuhecboQuGwYtmSpuzJnWS5rCvoH2HFyh5fguGbUWiE1nv6mu+NCAlJZhxwFXyBrIN /THFKoRM+nR3Ts/92wHA/1nrFlOeHu49WhKrSTajzZ7PuI6UUpENSx+M8Tej9OHrTWKR dUgW0VtlEJWrWncOR8wmOZbOdOvXA87lQ9gbyUzeVoS3QhpCpO1+XYfVCsBGJ2U5yiK9 zxhQ== X-Received: by 10.180.102.130 with SMTP id fo2mr14353665wib.30.1427645733770; Sun, 29 Mar 2015 09:15:33 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fm10sm11774245wib.7.2015.03.29.09.15.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 09:15:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 29 Mar 2015 19:15:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com> References: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Christian Huitema , Eric Rescorla , "spud@ietf.org" , Jana Iyengar Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 16:15:36 -0000 > On Mar 29, 2015, at 2:58 PM, Phillip Hallam-Baker = wrote: >=20 > On Sun, Mar 29, 2015 at 4:28 AM, Yoav Nir wrote: >=20 >> Hi, Christian >>=20 >> I understand the issue. Is this something we are really worried = about? It has always been possible to do this with TCP by sending a RST, = and that worked on the endpoints as well, and TLS has never protected us = from that attack. >>=20 >> To get the solution to work, presumably the initiator generates a = secret and sends its has in the OPEN command. This allows the initiator = to close the connection by sending the pre-image. But what if we want = both sides to be able to close the connection? We either need to = transmit the pre-image in the encrypted part of the protocol (what = Joe=E2=80=99s architecture diagram calls =E2=80=9Ctransport=E2=80=9D), = or we need a per-endpoint hash, requiring the responder to also send a = hash in the ACK command. The latter doubles the state on the middlebox. >=20 > The problem with state these days is not size. It is the fact you need > state because once a path is stateful it is fixed. Routing on the internet can change at any time, so you can=E2=80=99t = trust that for a particular TCP connection, a UDP flow or a =E2=80=9Ctube=E2= =80=9D all packets are going to follow the same path and pass through = the same intermediaries. Fortunately, the stateful intermediaries, such a firewalls, QoS boxes = and NATs tend to be placed at such choke points that all packets do flow = through them. The exception is when one endpoint gets reconfigured, such = as a mobile device moving from one network to another. TCP handles this = gracefully by closing the connection (OK, that=E2=80=99s not really = =E2=80=9Cgracefully=E2=80=9D), and for UDP it didn=E2=80=99t matter, = because there was no meta-data in the packets. With SPUD the =E2=80=9Ctube=E2=80=9D will have meta-data in the packet, = so either we copy TCP=E2=80=99s breakage when something changes, or we = do something else. In the BoF we talked about the intermediaries being = able to inject packets into the tube. I guess we could have them inject = a =E2=80=9Cneed-state=E2=80=9D command when they detect what appears to = be an already-open tube. In response the endpoints can send a special = packet with the parameters needed at the OPEN command, affirming that = this is indeed an open tube. endpoints whose address has changed could = proactively send such packets to avoid getting blocked for a round-trip. Yoav From nobody Sun Mar 29 11:38:59 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21521A7022 for ; Sun, 29 Mar 2015 11:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zx0_RTeD0TNs for ; Sun, 29 Mar 2015 11:38:57 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id F12FE1A702D for ; Sun, 29 Mar 2015 11:38:53 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Sun, 29 Mar 2015 14:38:53 -0400 From: Dave Dolson To: Yoav Nir , Christian Huitema Thread-Topic: [Spud] The reset middleboxes attack Thread-Index: AdBps0lZieRUM/cCRaqTbV+IIDrJUwAaIMQAAAzzhiA= Date: Sun, 29 Mar 2015 18:38:52 +0000 Message-ID: <20150329183851.4935767.64500.6234@sandvine.com> References: , <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> In-Reply-To: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , Eric Rescorla , "spud@ietf.org" Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 18:38:58 -0000 Recall =FDhttps://tools.ietf.org/html/rfc5925 This protects TCP sessions against RST attacks done by guessing sequence nu= mbers. Originally used to protect long-lived BGP connections. Of course this was to protect the end-points, not middle boxes. David Dolson Senior Software Architect, Sandvine Inc. Original Message From: Yoav Nir Sent: Sunday, March 29, 2015 4:28 AM To: Christian Huitema Cc: Jana Iyengar; Eric Rescorla; spud@ietf.org Subject: Re: [Spud] The reset middleboxes attack=FD > On Mar 29, 2015, at 3:17 AM, Christian Huitema wr= ote: > > A key design element out of the SEMI workshop was a request to expose ses= sion "start and stop" to the path. The rationale is that middleboxes could = then do a more efficient state management than the current timer-based solu= tions. The hosts would also benefit if they can do away with fewer keep ali= ve packets to maintain the state open in the middleboxes. > > But there is a big issue. The end systems can distinguish between valid a= nd invalid headers because the crypto ensures authentication of the clear t= ext header. An attacker capable of packet injection cannot affect the state= of the end systems, because the injected packets will fail the crypto chec= ksum verification and be discarded. But if the hosts are protected, the mid= dleboxes are not. They do not have access to the application credentials, a= nd they cannot perform the crypto checksum verification. This opens the gat= es for two attacks. > > The first and obvious attack is the "middlebox reset" attack. An attacker= injects a packet with a "stop" mark. Middleboxes on the path see that, and= free the state associated with the session. NAT mapping disappear and fire= wall opening are closed. Even if the hosts are capable of rejecting the fak= e reset, their connection is still gone, because further packets will be di= scarded by the middleboxes. > > One of my coauthors (EKR or Jana, cannot remember) suggested a mitigation= , which reminded me of the old "S-Key" scheme. Suppose that the "open" pack= et carries a "hash target" T, composed of an algorithm ID (say SHA256) and = a binary string (32 bytes in the case of SHA256). The middleboxes remember = that value as part of their state. We then require that the "stop" packets = carry a "hash result" R, a binary string of arbitrary size. When the middle= boxes on path see a reset packet, they check that H(R) =3D T. If it does no= t, they detect a spoofed reset, and discard the packet. > > I can see that implementers may not be enthusiastic with the additional c= omplexity. But we would be na=EFve to just dismiss the attack. We do see at= tackers capable of eavesdropping traffic, and then injecting packets "from = the side." I am sure that these attackers would find good use of a capabili= ty to nuke connections at will. Hi, Christian I understand the issue. Is this something we are really worried about? It h= as always been possible to do this with TCP by sending a RST, and that work= ed on the endpoints as well, and TLS has never protected us from that attac= k. To get the solution to work, presumably the initiator generates a secret an= d sends its has in the OPEN command. This allows the initiator to close the= connection by sending the pre-image. But what if we want both sides to be = able to close the connection? We either need to transmit the pre-image in t= he encrypted part of the protocol (what Joe=92s architecture diagram calls = =93transport=94), or we need a per-endpoint hash, requiring the responder t= o also send a hash in the ACK command. The latter doubles the state on the = middlebox. Yoav _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Sun Mar 29 11:46:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDAD1A86E8 for ; Sun, 29 Mar 2015 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 RJtvFQ0Of2vk for ; Sun, 29 Mar 2015 11:46:50 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (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 7A7DE1A86E4 for ; Sun, 29 Mar 2015 11:46:50 -0700 (PDT) Received: by pdbni2 with SMTP id ni2so152321863pdb.1 for ; Sun, 29 Mar 2015 11:46:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WOqIcLqtfLI7CvrNFmWGthPGbOVSs8bRA5oSr66GOxc=; b=aUEM6S9NPH5uXIN7SAv+wqwVP13PvIb3uAt0bKNQBO2Uwv93H7NK1s/bFGmy8T2sM+ TgSBFxid105dcnGzn87Ycwk84ByzegpkjAnRA5siIoYgX9VWqNmMo4sGTYnXqtdBKaFy fAn/RhBkO2EfpSPhjPW2BlcmPU/6zQmX0I6ibrukRRhTO7/52w7loGaHYonaB+lqY9Jv j6OhRZVcjff9rEaXPkL0oafITivmv1jLxRT77V5ZYnRQuhbLOVVY6djwfkER3ACHQdxU Mfi/ohTd6xv+JwTig4DuPP2bgNcf7HOvQ1ayzpQMsjazXfhmbfvkHsg9KnDY6XevMTp/ pYog== X-Gm-Message-State: ALoCoQkuJ3PHpNi0+9sIX4rJK39f5luiefJgHdWAqyK5EdcQGPvfTQUnWS/tPCrSCwQV/PpH0PLR X-Received: by 10.68.182.132 with SMTP id ee4mr20503204pbc.24.1427654810136; Sun, 29 Mar 2015 11:46:50 -0700 (PDT) Received: from Macintosh-2.local (50-1-59-15.dsl.static.fusionbroadband.com. [50.1.59.15]) by mx.google.com with ESMTPSA id nm1sm8154232pbc.50.2015.03.29.11.46.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2015 11:46:48 -0700 (PDT) Message-ID: <55184896.70504@nexenta.com> Date: Sun, 29 Mar 2015 11:46:46 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: spud@ietf.org References: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> <5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com> In-Reply-To: <5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 18:46:52 -0000 On 3/29/15 9:15 AM, Yoav Nir wrote: > Routing on the internet can change at any time, so you can’t trust that for a particular TCP connection, a UDP flow or a “tube” all packets are going to follow the same path and pass through the same intermediaries. > > Fortunately, the stateful intermediaries, such a firewalls, QoS boxes and NATs tend to be placed at such choke points that all packets do flow through them. The exception is when one endpoint gets reconfigured, such as a mobile device moving from one network to another. TCP handles this gracefully by closing the connection (OK, that’s not really “gracefully”), and for UDP it didn’t matter, because there was no meta-data in the packets. > > With SPUD the “tube” will have meta-data in the packet, so either we copy TCP’s breakage when something changes, or we do something else. In the BoF we talked about the intermediaries being able to inject packets into the tube. I guess we could have them inject a “need-state” command when they detect what appears to be an already-open tube. In response the endpoints can send a special packet with the parameters needed at the OPEN command, affirming that this is indeed an open tube. endpoints whose address has changed could proactively send such packets to avoid getting blocked for a round-trip. > > If a middlebox is doing something stateful then routing an existing TCP connection through it will not work. That is how middleboxes work today. I cannot think of why a middlebox would be doing something stateful if they were not at some form of check point. Middleboxes do not take on per-connection state because they are bored. Having a set of middleboxes somehow be aware that they form alternative routes to a protected domain, and automatically share state and responsibility for protecting said domain is, to put it mildly, too ambitious of a project for standardization. From nobody Sun Mar 29 13:11:25 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EF1A88C1 for ; Sun, 29 Mar 2015 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 FEnwTmwK_AeJ for ; Sun, 29 Mar 2015 13:11:22 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 95D861A88BD for ; Sun, 29 Mar 2015 13:11:22 -0700 (PDT) Received: by wgbgs4 with SMTP id gs4so58791692wgb.0 for ; Sun, 29 Mar 2015 13:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3WXQYfWsWlZYqx/0ZKfBRonWRyR/plJE518sBkIOTg=; b=thzi4VC5kNIH/vScSGwVnOWtbaWNrVjli+Tr/47gl81NGrhF4IJ4j5RPjc2SA9MhCe CQ3wOVZ4p8+jaDpw41Lj9Wy15JeJ8dPzePclMtY1ZrBAUCkvlnFkLfbidJURAiuuQk1W jpBIQPrA/wfSvu/jU1iaKwce2Uh8C1ew1muoR62ja6BiVtiFmM81Tl2p2VTElUHfCW3j XzjhZTYxv5wMPG+S0PFkdwwW1tn99BIIMmh6iHK8Qr/Mr3XAIUJX9qcdTNlduMAe0Dt4 1mnpHHtei0i+1X8muJQOP0X6yyVvteb17O2GyzgnJzCmkvTu183FbI7G8oXQpH9/7YWr sQqA== X-Received: by 10.194.78.231 with SMTP id e7mr54988612wjx.33.1427659881370; Sun, 29 Mar 2015 13:11:21 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id gt4sm12535639wib.21.2015.03.29.13.11.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 13:11:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <55184896.70504@nexenta.com> Date: Sun, 29 Mar 2015 23:11:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4166DC99-D326-48EB-A3A8-EB752669CBE7@gmail.com> References: <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> <5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com> <55184896.70504@nexenta.com> To: Caitlin Bestler X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 20:11:24 -0000 > On Mar 29, 2015, at 9:46 PM, Caitlin Bestler = wrote: >=20 >=20 >=20 > On 3/29/15 9:15 AM, Yoav Nir wrote: >> Routing on the internet can change at any time, so you can=E2=80=99t = trust that for a particular TCP connection, a UDP flow or a =E2=80=9Ctube=E2= =80=9D all packets are going to follow the same path and pass through = the same intermediaries. >>=20 >> Fortunately, the stateful intermediaries, such a firewalls, QoS boxes = and NATs tend to be placed at such choke points that all packets do flow = through them. The exception is when one endpoint gets reconfigured, such = as a mobile device moving from one network to another. TCP handles this = gracefully by closing the connection (OK, that=E2=80=99s not really = =E2=80=9Cgracefully=E2=80=9D), and for UDP it didn=E2=80=99t matter, = because there was no meta-data in the packets. >>=20 >> With SPUD the =E2=80=9Ctube=E2=80=9D will have meta-data in the = packet, so either we copy TCP=E2=80=99s breakage when something changes, = or we do something else. In the BoF we talked about the intermediaries = being able to inject packets into the tube. I guess we could have them = inject a =E2=80=9Cneed-state=E2=80=9D command when they detect what = appears to be an already-open tube. In response the endpoints can send a = special packet with the parameters needed at the OPEN command, affirming = that this is indeed an open tube. endpoints whose address has changed = could proactively send such packets to avoid getting blocked for a = round-trip. >>=20 >>=20 > If a middlebox is doing something stateful then routing an existing = TCP connection through it will not work. > That is how middleboxes work today. Right, but endpoints help along by resetting the connections when their = IP address changes. SPUD being UDP, this will not happen unless we = require it. > I cannot think of why a middlebox would be doing something stateful if = they were not at some form of > check point. Middleboxes do not take on per-connection state because = they are bored. True, but not all =E2=80=9Cstateful=E2=80=9D means having to see all = packets from the start. One of the use cases mentioned at the BoF was a = video stream specifying its bitrate. If the address of an endpoint = changes, that information can be retransmitted. Of course an anti-virus = box scanning QUIC streams will not be able to continue from the middle. > Having a set of middleboxes somehow be aware that they form = alternative routes to a protected domain, > and automatically share state and responsibility for protecting said = domain is, to put it mildly, too ambitious > of a project for standardization. I hope nobody is suggesting that. Yoav= From nobody Mon Mar 30 07:35:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F385B1A1EEA for ; Mon, 30 Mar 2015 07:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 SIOINFOIHbah for ; Mon, 30 Mar 2015 07:35:21 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.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 6E3471A1BFE for ; Mon, 30 Mar 2015 07:35:19 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Ycamb-0002ox-O1; Mon, 30 Mar 2015 16:35:17 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id A821DB0073B; Mon, 30 Mar 2015 16:35:17 +0200 (CEST) Message-ID: <55195F25.8000007@kit.edu> Date: Mon, 30 Mar 2015 16:35:17 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christian Huitema , "spud@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1427726117. Archived-At: Cc: Jana Iyengar , Eric Rescorla Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:35:26 -0000 Hi, > I can see that implementers may not be enthusiastic with the > additional complexity. But we would be nave to just dismiss the > attack. We do see attackers capable of eavesdropping traffic, and > then injecting packets "from the side." I am sure that these > attackers would find good use of a capability to nuke connections at > will. The described approach would be still vulnerable to on-path attackers, right? Furthermore, middleboxes must be prepared that route changes may occur and they may see only the start packet and maybe some data packets, but never the end packet. Regards, Roland From nobody Mon Mar 30 11:24:17 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2831A92AE for ; Mon, 30 Mar 2015 11:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 667olwkcmCI4 for ; Mon, 30 Mar 2015 11:24:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8091A9170 for ; Mon, 30 Mar 2015 11:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A97BAD9374; Mon, 30 Mar 2015 20:24:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gieTdpvxoCfO; Mon, 30 Mar 2015 20:24:12 +0200 (MEST) Received: from [10.21.66.96] (unknown [68.65.174.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 61C31D931B; Mon, 30 Mar 2015 20:24:11 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <55142E8A.1000509@nexenta.com> Date: Mon, 30 Mar 2015 11:24:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39481497-0304-4B99-863B-BC78364FB59A@tik.ee.ethz.ch> References: <55142E8A.1000509@nexenta.com> To: Caitlin Bestler X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD for Datacenters X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 18:24:17 -0000 Hi Caitlin, just a quick response. To my experience designing thing for the Internet = is usually harder that for data centers. However, what works in the = Internet should usually also work in data centers. (If that=E2=80=99s = the most efficient way to do things in a data center, is a different = question). However, I think it is most important that we can come up = with something that can be use in the Internet. And as this is today = hard problem, I=E2=80=99d prefer to focus on this part. Mirja =20 > Am 26.03.2015 um 09:06 schrieb Caitlin Bestler = : >=20 > Almost all of the SPUD discussion deals with long-haul networking, but = virtually > all of the infrormational declarations discussed would be just as = applicable for > datacenter switches, rbridges and routers. >=20 > This is especially important when you consider that the same = application might be > run either on a machine in a home network or on a virtual machine in a = datacenter. >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Mar 30 11:34:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F161A923C for ; Mon, 30 Mar 2015 11:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tOzIWfL2mzjo for ; Mon, 30 Mar 2015 11:34:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9FC1AC3A1 for ; Mon, 30 Mar 2015 11:34:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5F3EBD931B; Mon, 30 Mar 2015 20:34:00 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CUO4fJBOZSLV; Mon, 30 Mar 2015 20:34:00 +0200 (MEST) Received: from [10.21.66.96] (unknown [68.65.174.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 91532D9307; Mon, 30 Mar 2015 20:33:59 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <1FEB0782-16E8-4AE0-8FF5-2B824EF89F24@ericsson.com> Date: Mon, 30 Mar 2015 11:33:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FEB0782-16E8-4AE0-8FF5-2B824EF89F24@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] network/middle boxes information X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 18:34:04 -0000 Hi Salvatore, we are currently focusing on use case where you =E2=80=9Amay trust but = verify=E2=80=98 (see constraints). If you want to establish an explicit = trust relationship with the middlebox, I personally thing that is = currently out of scope. I believe there is information that both, middle = and end, are willing to release without a trust relation and which could = already provide useful input to e.g. better support certain app = requirements. Often these kind of information is already available today = by DPI (or at least assumptions are taken based on DPI, which might or = might not be true). Providing control which information should be = exposed (while encrypting the rest) actually provides better control of = information leakage and privacy than we often have today. Further, as = these information are only declarative, you can anyway never rely on = them: that means you should for all your action always take into account = that the information might be wrong (or alter by another entity). = However, having some information as a starting point is very often = extremely useful, if the alternative is having no information at all. That=E2=80=99s just my view on scoping. Mirja =20 > Am 25.03.2015 um 12:27 schrieb Salvatore Loreto = : >=20 >=20 > During the open discussion Andrew expressed the fact that the networks = have a lot of information > that can be of interest (or even useful) to the end points (we have = seen a proof of this already in tsvwg yesterday). >=20 > I want make clear that privacy and security is also important the = network not only for the endpoints. > We have to make sure that the middle box that is requested to share = some info with the endpoint > can do that in a secure/encrypted way (i.e. be able to decide who will = be able to see the info in clear) >=20 > br > Salvatore > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Mar 30 13:06:30 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57391AD35F for ; Mon, 30 Mar 2015 13:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Co29cyMqncrw for ; Mon, 30 Mar 2015 13:06:16 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (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 20DAF1AD365 for ; Mon, 30 Mar 2015 13:06:16 -0700 (PDT) Received: by pacgg7 with SMTP id gg7so47652575pac.0 for ; Mon, 30 Mar 2015 13:06:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EcR4Ik0oYOE2f5pC095b3t1La9EANbo9yF7NTFqWOLw=; b=h1TRTk7849oJn5o9UUcFf2d/+mcTGmsUXEQ4UwcKQR+TU1kCK5C8khYeBXUWCM7msT 6z5wlGJ+JwzANfsc7esi6d9ILDi9uZS4YoneAoOjCteAT0fKi5sIOenwxt7qi9UTWeYH GyovmlS2kzoGlx6bmwK9hfqaRknI+PqPtuDiIoFCx8Tb/i2B6XjGkWlPzhF1re2x5Z3G kU1i4UQTaNsm4bS3OE0iE2fh9TCDKlwNCTKZF9XBzznsIN7QOmm1EUdDPHSX5d+g76SH bSlKeKQ0iKEQSQaAaM7yEkerumq88kTmwXymrM1H+bqJ+w1rheS4OoFSkwdAJRzFKGFq L4KQ== X-Gm-Message-State: ALoCoQksX7CAfjthLI7g2m2NDhDc8Q5jCpOJxKOwMxI2aMRE5awRH4yH+ZZjDSBZJzTXI6ic9Zmd X-Received: by 10.66.235.169 with SMTP id un9mr60044223pac.45.1427745975800; Mon, 30 Mar 2015 13:06:15 -0700 (PDT) Received: from Macintosh-2.local (67-207-110-172.static.wiline.com. [67.207.110.172]) by mx.google.com with ESMTPSA id zd14sm10913039pab.20.2015.03.30.13.06.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 13:06:14 -0700 (PDT) Message-ID: <5519ACB5.6060900@nexenta.com> Date: Mon, 30 Mar 2015 13:06:13 -0700 From: Caitlin Bestler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <55142E8A.1000509@nexenta.com> <39481497-0304-4B99-863B-BC78364FB59A@tik.ee.ethz.ch> In-Reply-To: <39481497-0304-4B99-863B-BC78364FB59A@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] SPUD for Datacenters X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 20:06:28 -0000 On 3/30/15 11:24 AM, Mirja Kühlewind wrote: > Hi Caitlin, > > just a quick response. To my experience designing thing for the Internet is usually harder that for data centers. However, what works in the Internet should usually also work in data centers. (If that’s the most efficient way to do things in a data center, is a different question). However, I think it is most important that we can come up with something that can be use in the Internet. And as this is today hard problem, I’d prefer to focus on this part. > > Mirja > > I would agree that getting things to work for the Internet is harder. What I am suggesting is that we at least think about the datacenter impact for each specific method we come up with. Careful phrasing of requirements can result in no additional work for the Internet deployment but enable an efficient datacenter implementation as well. But if we don't do that check before we freeze language we will end up forcing some inefficiency for datacenter implementations. Datacenter specific optimizations, such as enhanced interactions for short round-trip-times, should be deferred. Make it work everywhere first. From nobody Mon Mar 30 13:36:52 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6131A87BB for ; Mon, 30 Mar 2015 13:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PXCZMwRvijHm for ; Mon, 30 Mar 2015 13:36:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C321A87BA for ; Mon, 30 Mar 2015 13:36:50 -0700 (PDT) Received: from DM2PR0301MB0653.namprd03.prod.outlook.com (25.160.96.15) by DM2PR0301MB0846.namprd03.prod.outlook.com (25.160.215.144) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 20:36:49 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (25.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 20:36:48 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.01.0118.022; Mon, 30 Mar 2015 20:36:48 +0000 From: Christian Huitema To: "Bless, Roland (TM)" , "spud@ietf.org" Thread-Topic: [Spud] The reset middleboxes attack Thread-Index: AdBps0lZieRUM/cCRaqTbV+IIDrJUwBQ3ROAAAwSmEA= Date: Mon, 30 Mar 2015 20:36:48 +0000 Message-ID: References: <55195F25.8000007@kit.edu> In-Reply-To: <55195F25.8000007@kit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: kit.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0846; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(86612001)(2171001)(99286002)(19580405001)(46102003)(86362001)(33656002)(77156002)(2501003)(102836002)(2950100001)(2656002)(122556002)(92566002)(76176999)(62966003)(87936001)(54356999)(2900100001)(50986999)(19580395003)(76576001)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 05315CBE52 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2015 20:36:48.0337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: Jana Iyengar , Eric Rescorla Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 20:36:51 -0000 > On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM) [mailto:roland.= bless@kit.edu] wrote: > ... > > I can see that implementers may not be enthusiastic with the > > additional complexity. But we would be na=EFve to just dismiss the > > attack. We do see attackers capable of eavesdropping traffic, and then > > injecting packets "from the side." I am sure that these attackers > > would find good use of a capability to nuke connections at will. >=20 > The described approach would be still vulnerable to on-path attackers, ri= ght? If we add a cryptographic protection on the reset packets, then it will pre= vent the reset injection attack by anyone, including on path attackers. Of course, on path middleboxes have the possibility to just drop all packet= s for a connection. That's a different attack, and it is possible to find o= ut the culprit by looking at where packets are dropped. It is much harder t= o get away undetected with a blocking attack than with a single packet inje= ction attack.=20 > Furthermore, middleboxes must be prepared that route changes may occur an= d > they may see only the start packet and maybe some data packets, but never= the > end packet. The route changes issue is probably worth its own thread. =20 I am worried that even if routing does not change, SPUD expose end points t= o new attacks. The root cause is that SPUD middleboxes are expected to make= decisions based on unauthenticated data in the packet headers. The reset a= ttack is just one of those, probably the most obvious one. Quick brainstorm= comes up with other possible attacks: * Inject lots of "open" packets with different context ID, targeting the sa= me five tuple. These will be discarded by the end points, but for the middl= e boxes they are the equivalent of a "SYN Flooding" attack. * Inject packets with creative values for declared bandwidth and other para= meters. Depending on parameter values, this can be either a DOS against the= end point (e.g., fake requirement of 100 bps for a video stream) or a DOS = attack against the network (e.g., stack a lot of bandwidth reservations for= nonexistent flows). I understand how to protect against the reset attack, but I am not sure wha= t to do about these other attacks. -- Christian Huitema From nobody Mon Mar 30 20:49:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301731A1A6A for ; Mon, 30 Mar 2015 20:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 bKblg7zpsPw4 for ; Mon, 30 Mar 2015 20:49:00 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 180901A1A69 for ; Mon, 30 Mar 2015 20:48:59 -0700 (PDT) Received: by iecxy8 with SMTP id xy8so3892380iec.0 for ; Mon, 30 Mar 2015 20:48:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kzmtXg/uHZJd51pOE8mTvbz0M5z0kIrh86qSqrzunS4=; b=S3DY4ljI25VVEXGxcOXRt8wJFS++fHYdQU9q/Iax4u/nhy5TDJVmlgqE7QAn0BLPSZ AFjpS67yE6FSIF8BH4gDQEHplD1wrusb+/LwUjXEC+Ew8T5r2l2Isy64sVCODues1vAG C+sYtN5t4cFU0ZANfsgOKLjALCPCpQynSo0jPZfe2GUVpwCKT5dPFVl6UTkRSqyKThC6 JuSku5+ZusZ7dPbKl6H9Olmn1fFXPo/MQg3K1M9KjIgr2s8WWnp4XFTYVPmJ6puT0UTz dvlQk8L44KkVqdiYRWqskA/N4XsYg1cInvB7XHYdoMMBJX4EsUHC/NP9I+uiONA12zWK SrKw== X-Gm-Message-State: ALoCoQkYG+/P+eY9kwLHhbxAp7qoEs39AelbC6vaigHjNGotof7x7kSMjGuH4a2AAiHP859xBByJ MIME-Version: 1.0 X-Received: by 10.50.36.104 with SMTP id p8mr1342954igj.16.1427773739292; Mon, 30 Mar 2015 20:48:59 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Mon, 30 Mar 2015 20:48:59 -0700 (PDT) Date: Mon, 30 Mar 2015 20:48:59 -0700 Message-ID: From: Tom Herbert To: spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] Unified UDP transport and tunnel protocol? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 03:49:04 -0000 Hello, As I mentioned at the SPUD BOF last week, it would be nice if the SPUD effort and other efforts for UDP encapsulation (such as work being done in NVO3) were somehow coordinated. Looking at the prototype protocol for SPUD I do believe that there are some opportunities here. In particular, I think that the features of SPUD (session control, magic number, DTLS, and some coded optional data) are also features we want in UDP encapsulation. There might also be features being defined on the encapsulation side that may be of interest to SPUD. We have proposed Generic UDP Encapsulation (GUE presented in int-area last week) to provide a simple and extensible UDP encapsulation protocol. The base protocol as well as several extensions have been defined. We are planning to define a session identifier option and I think it makes sense to define that in light of the SPUD model. The magic number and DTLS can also supported. GUE is designed for tunneling (encapsulation of IP protocol), but could be defined as a more general "substrate" protocol to conceivably provide a common header for both UDP encapsulation and UDP transports. If you are interested, the GUE draft is draft-herbert-gue-03. I hope have a draft on the session identifier option for GUE soon. Thanks, Tom From nobody Tue Mar 31 00:03:17 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873891B2AFF for ; Tue, 31 Mar 2015 00:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 cy8ZL5GPRL3X for ; Tue, 31 Mar 2015 00:03:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1EE1B2AF7 for ; Tue, 31 Mar 2015 00:02:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-58-551a46882b7e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.77.28835.8864A155; Tue, 31 Mar 2015 09:02:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.246]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 09:02:31 +0200 From: Salvatore Loreto To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] network/middle boxes information Thread-Index: AQHQZzHD+it0eZCqGUCsdpg+RDfRuZ01QDsAgADRKAA= Date: Tue, 31 Mar 2015 07:02:31 +0000 Message-ID: References: <1FEB0782-16E8-4AE0-8FF5-2B824EF89F24@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <51A946B0B333B24E96DC02DEDAE13E1E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+JvjW6Hm1SowYLvYhYbVk9hsVh04Smj A5PHkiU/mTyOffjKFsAUxWWTkpqTWZZapG+XwJXR9/kve8E3lYptG3ewNDD+Ue5i5OSQEDCR uH7tGyOELSZx4d56NhBbSOAoo8SEftMuRi4gewmjxNlvx5hAEmwCZhLPH25h7mLk4BAR8JL4 /CkQJMwsoCwxY+EusDnCQDPPLjzBAlFiKvHkhQtIWETASuJ/0092EJtFQFXi95eJLCA2r4C9 xObl+1kh1pZLXN6zEmwTp4CTxJ+5XWBxRqDTvp9awwSxSlzi1pP5TBAnC0gs2XOeGcIWlXj5 +B8rhK0ksWL7JUaQE5gFNCXW79KHMK0lpj1Xg5iiKDGl+yE7xAWCEidnPmGZwCg+C8mCWQjN sxCaZyFpnoWkeQEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwBg7uOW31Q7Gg88dDzEK cDAq8fAu+C8ZKsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xkXer+5VuX/r/fiowOOI37aojyVzomyznCp01+6af2XDszLOP2x55ddXqIr/zc+IWhIjerxZ zndqQuikTWxrdhSck4x/v1bYo2Pj9tWx3++9u5biUB6/Vk7xLvf2hpvZN3lCKwu9t1QxXV7y MdNXYHupGsucnhWb3tSIfs38XiZhuyHo56MKGSWW4oxEQy3mouJEAAI9jviSAgAA Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] network/middle boxes information X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 07:03:16 -0000 SGkgTWlyamENCg0KdGhhbmtzIGEgbG90IGZvciB0aGUgYW5zd2VyLg0KDQpJIGRvIGFncmUgdGhh dCBoYXZpbmcgc29tZSBpbmZvcm1hdGlvbiBpcyBhIGJldHRlciBhbHRlcm5hdGl2ZSB0aGF0IGFu eXRoaW5nDQphbmQgSSBhbSBoYXBweSB0byBzZWUgZmluYWxseSBTUFVEIGhhcHBlbmluZyANCg0K SSBhbSBzdXJlIHRoYXQgd2UgY2FuIGZpbmQgYSBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uIHRo YXQgYm90aCwgbWlkZGxlIGFuZCBlbmQgYXJlDQp3aWxsaW5nIHRvIHJlbGVhc2Ugd2l0aG91dCBh IHRydXN0IHJlbGF0aW9uIGFuZCB3aGljaCBjb3VsZCBhbHJlYWR5IGltcHJvdmUgdGhlIHN0YXR1 cyBxdW8NCk15IGNvbmNlcm4gaXMgdGhhdCB0aGlzIHNldCwgdGhlIHNldCBtaWRkbGUgYW5kIGVu ZCBhcmUgd2lsbGluZyB0byByZWxlYXNlIHdpdGhvdXQgYSB0cnVzdCByZWxhdGlvbiwNCmVuZCB1 cCB0byBiZSBzbyBtaW5pbWFsaXN0aWMgdGhhdCB3b3VsZCBiZSBleHRyZW1lbHkgZGlmZmljdWx0 IHRvIGluY2x1ZGUgYW55dGhpbmcgZWxzZSB0aGVuDQpzdGFydCBhbmQgc3RvcCB3aXRob3V0IGF0 IGxlYXN0IGEgY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9uDQoNCkFueXdheSBmcm9tIHlvdXIgYW5z d2VyIEkgdW5kZXJzdGFuZCB0aGF0IGF0IG1vbWVudCBpbiB5b3VyIHZpZXcgaXQgd291bGRuJ3Qg YmUgcG9zc2libGUNCnRvIHVzZSAoZXh0ZW5kPykgU1BVRCB0byBzaGFyZSBuZXR3b3JrIGluZm9y bWF0aW9uIHdpdGggZW5kcG9pbnQgbGlrZSBmb3IgZXhhbXBsZQ0KYSAibW9iaWxlIHRocm91Z2hw dXQgZ3VpZGFuY2UiIFsxXSANCm9yIG90aGVyIG5ldCBpbmZvIHRoYXQgd291bGQgaGVscCB0aGUg ZW5kcG9pbnRzIGJ1dCB0b2RheSBhcmUgbm90IGF2YWlsYWJsZSB0byB0aGVtIGF0IGFsbC4NCg0K QlRXIEkgc2VlIGEgY29udHJhZGljdGlvbiBpbiB0aGUgZmFjdCB0aGF0IHdlIGFyZSBmb2N1c2lu ZyB0aGUgU1BVRCBvbiB0aGUg4oCYbWF5IHRydXN0IGJ1dCB2ZXJpZnnigJkNCmFzc3VtcHRpb24g YW5kIGF0IHNhbWUgdGltZSB3ZSBhcmUgaG9waW5nIHRoYXQgU1BVRCB3aWxsIGhlbHAgdG8gZ2V0 IHJpZCBvZiBEUEkuDQpJIHRoaW5rIHRoYXQgdW5mb3J0dW5hdGVseSBpZiB3ZSByZWxheSBvbiB0 aGUg4oCYbWF5IHRydXN0IGJ1dCB2ZXJpZnnigJkgYXNzdW1wdGlvbg0KdGhlIG5ldHdvcmsgd2ls bCBjb250aW51ZSB0byBtYWtlIHVzZSBvZiBEUEkgYXQgbGVhc3QgdG8gdmVyaWZ5IHRoZSBkZWNs YXJhdGl2ZSBpbmZvLg0KDQpbMV0gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zcHJlY2hl ci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gtMDEudHh0DQoNCmJyDQpTYWwNCg0KPiBPbiAz MCBNYXIgMjAxNSwgYXQgMjA6MzMsIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g+IHdyb3RlOg0KPiANCj4gSGkgU2FsdmF0b3JlLA0KPiANCj4gd2UgYXJl IGN1cnJlbnRseSBmb2N1c2luZyBvbiB1c2UgY2FzZSB3aGVyZSB5b3Ug4oCabWF5IHRydXN0IGJ1 dCB2ZXJpZnnigJggKHNlZSBjb25zdHJhaW50cykuIElmIHlvdSB3YW50IHRvIGVzdGFibGlzaCBh biBleHBsaWNpdCB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCB0aGUgbWlkZGxlYm94LCBJIHBlcnNv bmFsbHkgdGhpbmcgdGhhdCBpcyBjdXJyZW50bHkgb3V0IG9mIHNjb3BlLiBJIGJlbGlldmUgdGhl cmUgaXMgaW5mb3JtYXRpb24gdGhhdCBib3RoLCBtaWRkbGUgYW5kIGVuZCwgYXJlIHdpbGxpbmcg dG8gcmVsZWFzZSB3aXRob3V0IGEgdHJ1c3QgcmVsYXRpb24gYW5kIHdoaWNoIGNvdWxkIGFscmVh ZHkgcHJvdmlkZSB1c2VmdWwgaW5wdXQgdG8gZS5nLiBiZXR0ZXIgc3VwcG9ydCBjZXJ0YWluIGFw cCByZXF1aXJlbWVudHMuIE9mdGVuIHRoZXNlIGtpbmQgb2YgaW5mb3JtYXRpb24gaXMgYWxyZWFk eSBhdmFpbGFibGUgdG9kYXkgYnkgRFBJIChvciBhdCBsZWFzdCBhc3N1bXB0aW9ucyBhcmUgdGFr ZW4gYmFzZWQgb24gRFBJLCB3aGljaCBtaWdodCBvciBtaWdodCBub3QgYmUgdHJ1ZSkuIFByb3Zp ZGluZyBjb250cm9sIHdoaWNoIGluZm9ybWF0aW9uIHNob3VsZCBiZSBleHBvc2VkICh3aGlsZSBl bmNyeXB0aW5nIHRoZSByZXN0KSBhY3R1YWxseSBwcm92aWRlcyBiZXR0ZXIgY29udHJvbCBvZiBp bmZvcm1hdGlvbiBsZWFrYWdlIGFuZCBwcml2YWN5IHRoYW4gd2Ugb2Z0ZW4gaGF2ZSB0b2RheS4g RnVydGhlciwgYXMgdGhlc2UgaW5mb3JtYXRpb24gYXJlIG9ubHkgZGVjbGFyYXRpdmUsIHlvdSBj YW4gYW55d2F5IG5ldmVyIHJlbHkgb24gdGhlbTogdGhhdCBtZWFucyB5b3Ugc2hvdWxkIGZvciBh bGwgeW91ciBhY3Rpb24gYWx3YXlzIHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlIGluZm9ybWF0 aW9uIG1pZ2h0IGJlIHdyb25nIChvciBhbHRlciBieSBhbm90aGVyIGVudGl0eSkuIEhvd2V2ZXIs IGhhdmluZyBzb21lIGluZm9ybWF0aW9uIGFzIGEgc3RhcnRpbmcgcG9pbnQgaXMgdmVyeSBvZnRl biBleHRyZW1lbHkgdXNlZnVsLCBpZiB0aGUgYWx0ZXJuYXRpdmUgaXMgaGF2aW5nIG5vIGluZm9y bWF0aW9uIGF0IGFsbC4NCj4gDQo+IFRoYXTigJlzIGp1c3QgbXkgdmlldyBvbiBzY29waW5nLg0K PiANCj4gTWlyamENCj4gDQo+IA0KPj4gQW0gMjUuMDMuMjAxNSB1bSAxMjoyNyBzY2hyaWViIFNh bHZhdG9yZSBMb3JldG8gPHNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPjoNCj4+IA0KPj4g DQo+PiBEdXJpbmcgdGhlIG9wZW4gZGlzY3Vzc2lvbiBBbmRyZXcgZXhwcmVzc2VkIHRoZSBmYWN0 IHRoYXQgdGhlIG5ldHdvcmtzIGhhdmUgYSBsb3Qgb2YgaW5mb3JtYXRpb24NCj4+IHRoYXQgY2Fu IGJlIG9mIGludGVyZXN0IChvciBldmVuIHVzZWZ1bCkgdG8gdGhlIGVuZCBwb2ludHMgKHdlIGhh dmUgc2VlbiBhIHByb29mIG9mIHRoaXMgYWxyZWFkeSBpbiB0c3Z3ZyB5ZXN0ZXJkYXkpLg0KPj4g DQo+PiBJIHdhbnQgbWFrZSBjbGVhciB0aGF0IHByaXZhY3kgYW5kIHNlY3VyaXR5IGlzIGFsc28g aW1wb3J0YW50IHRoZSBuZXR3b3JrIG5vdCBvbmx5IGZvciB0aGUgZW5kcG9pbnRzLg0KPj4gV2Ug aGF2ZSB0byBtYWtlIHN1cmUgdGhhdCB0aGUgbWlkZGxlIGJveCB0aGF0IGlzIHJlcXVlc3RlZCB0 byBzaGFyZSBzb21lIGluZm8gd2l0aCB0aGUgZW5kcG9pbnQNCj4+IGNhbiBkbyB0aGF0IGluIGEg c2VjdXJlL2VuY3J5cHRlZCB3YXkgKGkuZS4gYmUgYWJsZSB0byBkZWNpZGUgd2hvIHdpbGwgYmUg YWJsZSB0byBzZWUgdGhlIGluZm8gaW4gY2xlYXIpDQo+PiANCj4+IGJyDQo+PiBTYWx2YXRvcmUN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBT cHVkIG1haWxpbmcgbGlzdA0KPj4gU3B1ZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo+IA0KDQo= From nobody Tue Mar 31 01:23:10 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F431A90F1 for ; Tue, 31 Mar 2015 01:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fL30IShaSMAd for ; Tue, 31 Mar 2015 01:23:06 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 55ADE1A90E8 for ; Tue, 31 Mar 2015 01:23:06 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:311b:a423:9727:554d] (unknown [IPv6:2001:470:26:9c2:311b:a423:9727:554d]) by trammell.ch (Postfix) with ESMTPSA id 168201A0161; Tue, 31 Mar 2015 10:23:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3146ADB8-51C1-415F-A593-7F81AE8C9A3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: Date: Tue, 31 Mar 2015 10:23:04 +0200 Message-Id: <30721F17-412D-4DD9-9E73-15B46BC08C29@trammell.ch> References: <1FEB0782-16E8-4AE0-8FF5-2B824EF89F24@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] network/middle boxes information X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 08:23:09 -0000 --Apple-Mail=_3146ADB8-51C1-415F-A593-7F81AE8C9A3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Mar 2015, at 09:02, Salvatore Loreto = wrote: >=20 > Hi Mirja >=20 > thanks a lot for the answer. >=20 > I do agre that having some information is a better alternative that = anything > and I am happy to see finally SPUD happening >=20 > I am sure that we can find a common set of information that both, = middle and end are > willing to release without a trust relation and which could already = improve the status quo > My concern is that this set, the set middle and end are willing to = release without a trust relation, > end up to be so minimalistic that would be extremely difficult to = include anything else then > start and stop without at least a cryptographic protection ...and stop might need cryptographic protection, too (on which I'll = reply once the jetlag subsides...) > Anyway from your answer I understand that at moment in your view it = wouldn't be possible > to use (extend?) SPUD to share network information with endpoint like = for example > a "mobile throughput guidance" [1] > or other net info that would help the endpoints but today are not = available to them at all. >=20 > BTW I see a contradiction in the fact that we are focusing the SPUD on = the =E2=80=98may trust but verify=E2=80=99 > assumption and at same time we are hoping that SPUD will help to get = rid of DPI. > I think that unfortunately if we relay on the =E2=80=98may trust but = verify=E2=80=99 assumption > the network will continue to make use of DPI at least to verify the = declarative info. This whole effort is, in essence, an exercise in balancing = contradictions. Let's be clear: SPUD isn't going to be what gets rid of DPI. End-to-end = encryption with key management to detect and prohibit TLS MTIM is what = gets rid of DPI, at the application layer and below. This is happening, = and will happen, without SPUD, for reasons that are entirely unrelated = to transport ossification. Yes, SPUD makes it possible to encrypt the transport layer headers, as = well, which in turn makes it possible for the transport protocols to = make explicit the contract between the endpoints and the path, and to be = explicit about the division between the endpoint's role in making = transport work and the path's. Selective exposure within SPUD makes it = possible to do some of the things we're doing with DPI now, for which = DPI is a wholly inappropriate tool, without doing DPI. I would strenuously warn against treating DPI as "ground truth" in = today's environment, much less as verification in a more explicit = environment such as that we hope to build with SPUD. We need to = recognize that much of the DPI that's out there is by necessity pretty = simple, and therefore reasonably easy for endpoints cooperating with = each other to spoof. And much of what DPI can tell you *directly* is = really not interesting from a traffic classification and engineering = standpoint in an Internet context. Cheers, Brian > [1] = http://www.ietf.org/id/draft-sprecher-mobile-tg-exposure-req-arch-01.txt >=20 > br > Sal >=20 >> On 30 Mar 2015, at 20:33, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi Salvatore, >>=20 >> we are currently focusing on use case where you =E2=80=9Amay trust = but verify=E2=80=98 (see constraints). If you want to establish an = explicit trust relationship with the middlebox, I personally thing that = is currently out of scope. I believe there is information that both, = middle and end, are willing to release without a trust relation and = which could already provide useful input to e.g. better support certain = app requirements. Often these kind of information is already available = today by DPI (or at least assumptions are taken based on DPI, which = might or might not be true). Providing control which information should = be exposed (while encrypting the rest) actually provides better control = of information leakage and privacy than we often have today. Further, as = these information are only declarative, you can anyway never rely on = them: that means you should for all your action always take into account = that the information might be wrong (or alter by another entity). = However, having some information as a starting point is very often = extremely useful, if the alternative is having no information at all. >>=20 >> That=E2=80=99s just my view on scoping. >>=20 >> Mirja >>=20 >>=20 >>> Am 25.03.2015 um 12:27 schrieb Salvatore Loreto = : >>>=20 >>>=20 >>> During the open discussion Andrew expressed the fact that the = networks have a lot of information >>> that can be of interest (or even useful) to the end points (we have = seen a proof of this already in tsvwg yesterday). >>>=20 >>> I want make clear that privacy and security is also important the = network not only for the endpoints. >>> We have to make sure that the middle box that is requested to share = some info with the endpoint >>> can do that in a secure/encrypted way (i.e. be able to decide who = will be able to see the info in clear) >>>=20 >>> br >>> Salvatore >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_3146ADB8-51C1-415F-A593-7F81AE8C9A3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVGlloAAoJENt3nsOmbNJck3MH/i3e6iDbwuveYA9gtVUugFrg GSO8hu6I5b1lykg6U7ZetO/mfeXMfyA0+2IhfOfxQrc4iq6bsZsMDrp/8J4QvbAu CF0MKShmuEoksv16sKRR5kVGP3TaBjmHUihF4xrggHuxy4Q9T+BXfHLT1iQdZVWU ePMoicCtMGtTT4MeG5WsYrHknEFEbjRBw5kKQ6Hxt4DkuQqLAtJDLjQxySTioO37 rzOlACaooNYwANgBzOHXd1PY3Lh1wpo4Q7sDY+XKt6+OCo8WeeVO50p23aBUmAqF bS3BBhf6z/Mo0gwYs6UYnuhl4SOXGQj/6c1c0H5fuFVAPqcc+V2ClLH1711VvJQ= =hpwf -----END PGP SIGNATURE----- --Apple-Mail=_3146ADB8-51C1-415F-A593-7F81AE8C9A3F-- From nobody Tue Mar 31 01:25:22 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513BA1B2B34 for ; Tue, 31 Mar 2015 01:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 asJnaXmjEdr5 for ; Tue, 31 Mar 2015 01:25:18 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.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 02D531B2B33 for ; Tue, 31 Mar 2015 01:25:18 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1YcrU3-0004zq-UE; Tue, 31 Mar 2015 10:25:15 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id D6F4BB000BA; Tue, 31 Mar 2015 10:25:15 +0200 (CEST) Message-ID: <551A59EB.3070501@kit.edu> Date: Tue, 31 Mar 2015 10:25:15 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christian Huitema , "spud@ietf.org" References: <55195F25.8000007@kit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1427790316. Archived-At: Cc: Jana Iyengar , Eric Rescorla Subject: Re: [Spud] The reset middleboxes attack X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 08:25:20 -0000 Hi Christian, comments inline. On 30.03.2015 at 22:36 Christian Huitema wrote: >> On Monday, March 30, 2015, at 7:35 AM, Bless, Roland (TM) >> wrote: ... >>> I can see that implementers may not be enthusiastic with the >>> additional complexity. But we would be nave to just dismiss the >>> attack. We do see attackers capable of eavesdropping traffic, and >>> then injecting packets "from the side." I am sure that these >>> attackers would find good use of a capability to nuke connections >>> at will. >> >> The described approach would be still vulnerable to on-path >> attackers, right? > > If we add a cryptographic protection on the reset packets, then it > will prevent the reset injection attack by anyone, including on path > attackers. Sorry, I was confused by the term "hash result" R in your previous mail, and reread the mail again. So R is the preimage that comes with the CLOSE, while T comes with the OPEN and therefore the middlebox can verify that H(R)=T. > Of course, on path middleboxes have the possibility to just drop all > packets for a connection. That's a different attack, and it is > possible to find out the culprit by looking at where packets are > dropped. It is much harder to get away undetected with a blocking > attack than with a single packet injection attack. Yep. However, there is little you can do against such a DoS attack anyway. >> Furthermore, middleboxes must be prepared that route changes may >> occur and they may see only the start packet and maybe some data >> packets, but never the end packet. > > The route changes issue is probably worth its own thread. > > I am worried that even if routing does not change, SPUD expose end > points to new attacks. The root cause is that SPUD middleboxes are > expected to make decisions based on unauthenticated data in the > packet headers. The reset attack is just one of those, probably the > most obvious one. Quick brainstorm comes up with other possible > attacks: > > * Inject lots of "open" packets with different context ID, targeting > the same five tuple. These will be discarded by the end points, but > for the middle boxes they are the equivalent of a "SYN Flooding" > attack. Yes. > * Inject packets with creative values for declared bandwidth and > other parameters. Depending on parameter values, this can be either a > DOS against the end point (e.g., fake requirement of 100 bps for a > video stream) or a DOS attack against the network (e.g., stack a lot > of bandwidth reservations for nonexistent flows). IMHO resource reservation is a different game and doesn't make much sense without some form of authorization. That's why I don't buy the argument that SPUD will cause no harm because of its purely indicative nature (like a flow + traffic specification): if such indicative values would have no effect on middlebox operation, you could simply dismiss them. Otherwise if middleboxes take them seriously it may lead to attack vectors just as you described. > I understand how to protect against the reset attack, but I am not > sure what to do about these other attacks. It is possible to create some protection schemes, but usually that will end up in 3-way handshakes and the like, which isn't lightweight anymore. Regards, Roland From nobody Tue Mar 31 18:15:53 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD98A1B2BBF for ; Tue, 31 Mar 2015 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 dA9lOYIA1zz9 for ; Tue, 31 Mar 2015 18:15:48 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 1DD691A1A97 for ; Tue, 31 Mar 2015 18:15:48 -0700 (PDT) Received: by igbud6 with SMTP id ud6so35162202igb.1 for ; Tue, 31 Mar 2015 18:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Xkw9Liw1JVGRUaj2uJ4vCtExxIuMgs1CvcVrV/dgpl4=; b=A7uU5/WCumK+uFx5PeSmNlL/ChtTrS5h3gKr1OgYZakMk145VAo9lvgSz0djp6ty5v ijYhVU2PBew8ylUZZT62+2k7/Y9Nzp8865Cl9cqNlf2XcNI03LNwpX/JBmDYmL4k2fLZ 7azaIjcboOM1VkN2bzPdIkLDecWrKQU6qdfAgACzb2w7AIVnR4vtVPL4jSUxxDV/z6IO RjuEY3aaH91Xq0iaan8zqU29PZsTJen8HcVo/hI8nF5sapWV5WFMPrODg/zyJoVCzrT+ wQkYq6hq8RX+hKHtITCzGytTmv5M4lBtZvk00MyWRzMt09/2U/hk3d6/WJfqkl5EQRYS hHXg== X-Gm-Message-State: ALoCoQmJxuSR4c4f0S+8NYjSWNrV437rthV9hNkh3vhEeHSwB4ZWjaPdmrFc8j4P+UtqrprdbJXs MIME-Version: 1.0 X-Received: by 10.42.199.75 with SMTP id er11mr39284231icb.43.1427850947322; Tue, 31 Mar 2015 18:15:47 -0700 (PDT) Received: by 10.107.149.15 with HTTP; Tue, 31 Mar 2015 18:15:47 -0700 (PDT) Date: Tue, 31 Mar 2015 18:15:47 -0700 Message-ID: From: Tom Herbert To: jhildebr@cisco.com, spud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spud] Comments on draft-hildebrand-spud-prototype-03 X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:15:53 -0000 Hi Joe, I was looking at the state machine in the SPU prototype protocol, especially with regards of how a TCP connection might be mapped to it. Here are a few comments. 1. For a session it seems like one side is delegated to be the initiator. The initiator sends the open and sets the session ID which is reflected by it's peer. We can use an additional bit in the header to indicate if the sender (source IP address) is the initiator or not. 2. Assuming that there is a clear initiator, the state machine viewpoint can always be from the initiator and then is common for both endpoints and any intermediate nodes. So there shouldn't be a need to consider active or passive opens, or simultaneous opens. sopen would just be open, and the transition from unknown to running would not be needed.. 3. If the underlying protocol does allow simultaneous opens so that two sessions are created, presumably some method would be needed by the underlying protocol to select which session to use for the connection and close the session. 4. I think there should be an additional opening state. With transition flow: 1) When open is seen from initiator, go to first opening state. 2) When open-ack is seen from peer, go to second opening state. 3) When open-ack is seen from initiator, go to running. This then matches the completion 3WHS of TCP. For instance, in a SYN attack the created session states would only get to the second open state (assuming SYN=>open and then SYN-ACK=>open-ack), so this way we can differentiate these with sessions with the ones fully established ones in the underlying protocol. Thanks, Tom