From nobody Mon Oct 1 00:26:57 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FDF130DE7; Mon, 1 Oct 2018 00:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGBsoXpOBY_Y; Mon, 1 Oct 2018 00:26:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A80A130DE3; Mon, 1 Oct 2018 00:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4044; q=dns/txt; s=iport; t=1538378814; x=1539588414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rmOdOMWUaDP5HuWWePU27saF3ipiCo1VRZ26aDtnbA0=; b=cZ8v4KqYZYRaQ4iQSGtTlJ+nlnfKhqKN6Rtvo0Gu/ceUkDmSCzNgBuHh Ft7D+Ba6hlcH7xLPgTuzZuS9wC8TcrM8jkXgYl7F6VqZAAODg10hZaWsa 3msQkVxbNsEcqHPP/12jkABYvCqayMoViFNQVvBfpkdVvLzUC5EBf7mSH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAADFy7Fb/51dJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOgWUyg2qIFYwwgg14gkWTHYF6C4RsAheDbCE0GAE?= =?us-ascii?q?DAQECAQECbSiFOAEBAQECASMRMxIFCwIBCA4ECAImAgICMBUCDgIEAQ0NhRM?= =?us-ascii?q?Io0GBLooIgQuJdxeBQT+BEoJdNYRYgyeCVwKIe5NiTAkCkCofgUeEW4Zegk+?= =?us-ascii?q?VCgIRFIElHTiBVXAVgyiQU4wLgS2BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,327,1534809600"; d="scan'208";a="241667048" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 07:26:53 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w917QrhL009627 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2018 07:26:53 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 02:26:52 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Mon, 1 Oct 2018 02:26:52 -0500 From: "Pascal Thubert (pthubert)" To: Ines Robles , "rtg-dir@ietf.org" CC: "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-problem-statement.all@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-detnet-problem-statement-06 Thread-Index: AQHUWPtHUK6sOqQa+0Kg+dXUUubEVKUJ6N6g Date: Mon, 1 Oct 2018 07:26:36 +0000 Deferred-Delivery: Mon, 1 Oct 2018 07:26:17 +0000 Message-ID: References: <153833893256.13335.17089954204593908870@ietfa.amsl.com> In-Reply-To: <153833893256.13335.17089954204593908870@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Detnet] Rtgdir last call review of draft-ietf-detnet-problem-statement-06 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 07:26:56 -0000 SGVsbG8gSW5lcw0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuIA0KDQpJIHNlZSB0aGlz IHJlY3VycmluZyBwb2ludCBvZiBhZGRpbmcgcmVmZXJlbmNlcyB0byB0aGUgb3RoZXIgZGV0bmV0 IGRvY3VtZW50czsgSSdtIGhhcHB5IHRvIGZvbGxvdyB0aGlzIGFkdmljZSwgbm90aW5nIHRob3Vn aCB0aGF0IHRoZXNlIGFyZSBmb3J3YXJkIHBvaW50ZXJzIHNpbmNlIHRoZSBwcm9ibGVtIHN0YXRl bWVudCBjb21lcyBmaXJzdC4gDQoNClBsZWFzZSBzZWUgYmVsb3c6DQogDQo+IEkgYmVsaWV2ZSB0 aGUgZHJhZnQgaXMgdGVjaG5pY2FsbHkgZ29vZC4gVGhpcyBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0 ZW4gYW5kIGNsZWFyIHRvDQo+IHVuZGVyc3RhbmQuDQo+IA0KPiBUaGUgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBuZWVkcyBpbiB2YXJpb3VzIGluZHVzdHJpZXMgdG8gZXN0YWJsaXNoIG11bHRpLWhv cA0KPiBwYXRocyBmb3IgY2hhcmFjdGVyaXplZCBmbG93cyB3aXRoIGRldGVybWluaXN0aWMgcHJv cGVydGllcy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJs aWNhdGlvbiwgYnV0IEkgaGF2ZSBzb21lIG1pbm9yDQo+IHF1ZXN0aW9ucyB0aGF0IHNob3VsZCBi ZSBjb25zaWRlcmVkIHByaW9yIHRvIGJlaW5nIHN1Ym1pdHRlZCB0byB0aGUgSUVTRy4NCj4gDQo+ IENvbW1lbnRzOg0KPiANCj4gMSktIEluIHNlY3Rpb24gMSB5b3UgbWVudGlvbjogIi4uLi5hIG5l dyBtb2RlbCBtdXN0IGJlIHByb3Bvc2VkIHRvIGludGVncmF0ZQ0KPiBkZXRlcm1pbmlzbSBpbiBJ VCB0ZWNobm9sb2d5Li4uIiBEbyB5b3UgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIG1lbnRpb24gZHJh ZnQtaWV0Zi0NCj4gZGV0bmV0LWFyY2hpdGVjdHVyZSBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0 aGUgbW9kZWw/DQo+IA0KW1BUPl0gd2hhdCBhYm91dDoNCiINCiAgICAgIEZvcndhcmQgbm90ZTog VGhlIDx4cmVmIHRhcmdldD0nSS1ELmlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSc+DQogICAgICBE ZXROZXQgQXJjaGl0ZWN0dXJlPC94cmVmPiBpcyB0aGUgZG9jdW1lbnQgcHJvZHVjZWQgYnkgdGhl IERldE5ldCBXRyB0byANCiAgICAgIGRlc2NyaWJlIHRoYXQgbW9kZWwuDQoiDQoNCj4gMiktIElu IFNlY3Rpb24gMTogInRoZSBtb2RlbCBzaG91bGQgbm90IGNvbXByb21pc2UgdGhlIGFiaWxpdHkg b2YgYSBuZXR3b3JrIHRvDQo+IGtlZXAgY2FycnlpbmcgdGhlIHNvcnRzIG9mIHRyYWZmaWMgdGhh dCBpcyBhbHJlYWR5IGNhcnJpZWQgdG9kYXkgaW4gY29uanVuY3Rpb24NCj4gd2l0aCBuZXcsIG1v cmUgZGV0ZXJtaW5pc3RpYyBmbG93cy4iLCBhbmQgaW4gU2VjdGlvbiAyICJUaGUgZ29hbHMgb2YN Cj4gRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIChEZXROZXQpIGFyZSAuLi4uIGFuZCB0byBzdXBw b3J0IGJvdGggdGhlc2UgbmV3DQo+IGFwcGxpY2F0aW9ucywgYW5kIGV4aXN0aW5nIHBhY2tldCBu ZXR3b3JrIGFwcGxpY2F0aW9ucywgb3ZlciB0aGUgc2FtZSBwaHlzaWNhbA0KPiBuZXR3b3JrLiIg VGhvc2Ugc2VudGVuY2VzIHNlZW1zIHRvIGJlIHJlbGF0ZWQgd2l0aCBJbnRlcm9wZXJhYmlsaXR5 LCBidXQNCj4gSW50ZXJvcGVyYWJpbGl0eSBpcyBub3QgZXhwbGljaXRseSBtZW50aW9uZWQgaW4g dGhlIGRvY3VtZW50LiBEbyB5b3UgdGhpbmsgdGhhdCBpdA0KPiBzaG91bGQgYmU/DQpbUFQ+XSBD YW4gd2UgYWRkIGFmdGVyIHRoZSBsYXR0ZXIgc2VudGVuY2U6DQoNCiINCkluIG90aGVyIHdvcmRz LCBhIERldGVybWluaXN0aWMgTmV0d29yayBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIC0g Y2FwYWJsZQ0Kb2YgdHJhbnNwb3J0aW5nIC0gc3RhdGlzdGljYWxseSBtdWx0aXBsZXhlZCB0cmFm ZmljIHdoaWxlIHByZXNlcnZpbmcgdGhlDQpwcm9wZXJ0aWVzIG9mIHRoZSBhY2NlcHRlZCBkZXRl cm1pbmlzdGljIGZsb3dzLg0KIg0KDQo+IA0KPiAzKS0gSW4gU2VjdGlvbiAyOiAiTXVsdGlwbGUg bWV0aG9kcyB0byBzY2hlZHVsZSwgc2hhcGUsIGxpbWl0LCBhbmQgb3RoZXJ3aXNlDQo+IGNvbnRy b2wgdGhlIHRyYW5zbWlzc2lvbiBvZiBjcml0aWNhbCBwYWNrZXRzIGF0IGVhY2ggaG9wIHRocm91 Z2ggdGhlIG5ldHdvcmsNCj4gZGF0YSBwbGFuZTsiIERvIHlvdSB0aGluayB0aGF0IGl0IHdvdWxk IGJlIGdvb2QgdG8gYWRkIHNvbWV0aGluZyBsaWtlOiAiRGV0bmV0DQo+IGlzIHdvcmtpbmcgb24g SVAgRGF0YSBQbGFuZSBFbmNhcHN1bGF0aW9uIFtyZWYuXSBhbmQgb24gTVBMUyBEYXRhIFBsYW5l DQo+IEVuY2Fwc3VsYXRpb24gW3JlZl0/Ig0KW1BUPl0gSSdtIG5vdCB0b28gaW5jbGluZWQgYmVj YXVzZSB0aGlzIHNlbnRlbmNlIGlzIGFib3V0IGEgbG90IG1vcmUgdGhhbiBEUCANCmVuY29kaW5n LCBhZCBiZWNhdXNlIHRoaXMgaXMgcmVhbGx5IGZhc3QgZm9yd2FyZGluZyBhIGxvdC4NCg0KPiAN Cj4gNCktIEluIFNlY3Rpb24gMjogIlJvYnVzdCBkZWZlbnNlcyBhZ2FpbnN0IG1pc2JlaGF2aW5n IGhvc3RzLCByb3V0ZXJzLCBvcg0KPiBicmlkZ2VzLGJvdGggaW4gdGhlIGRhdGEgYW5kIGNvbnRy b2wgcGxhbmVzLi4uLiIgRG8geW91IHRoaW5rIHRoYXQgaXQgd291bGQgYmUNCj4gZ29vZCB0byBh ZGQgaGVyZSBvciBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAobWF5YmUg YmV0dGVyKSBhDQo+IHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eT8NCj4g DQpbUFQ+XSBZb3UncmUgcmlnaHQsIHRoYXQgZml0IGluIGJvdGggcGxhY2VzLg0KDQo+IE5pdHM6 DQo+IA0KPiBJdCB3b3VsZCBiZSBuaWNlIHRvIGV4cGFuZCBEZXROZXQgaW4gU2VjdGlvbiAxLCBz aW5jZSBpdCBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IGl0IGlzDQo+IG1lbnRpb25lZC4NCj4gDQpb UFQ+XSBkb25lDQoNCk1hbnkgVGhhbmtzLCBJbmVzIDogKQ0KDQpQYXNjYWwNCg0K From nobody Mon Oct 1 05:05:31 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733D130DF0; Mon, 1 Oct 2018 05:05:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JklziLdb6-jE; Mon, 1 Oct 2018 05:05:24 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 9D948120072; Mon, 1 Oct 2018 05:05:21 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id w200-v6so10973632itc.4; Mon, 01 Oct 2018 05:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ro7hbx3nyqWLvdwGgg24APXdQcBl2heZW+JScJ/9CJw=; b=gSu/2srQxYoETgDosfq0tvcWzCH6DRIL1ONHH7S4hjCSwFD615QtsVZms8NQv1v4ED kLFoyqriIGUrSyc+8va8BDwP0vj0kYKRddscqUT81AgZbm9L/cK3NrtaVxSuYE9Gv0/X RemVquc3C89jkT7Od6Q3DERo9brM2YB99bF8Fc8D27EkJYGIDmwUJb0FrqL92fGXXd5s B9OFYXMdTJQXgP5QQW9Vf7V2zbG4ufHxUHhkUJs0wX7xzSSHdAruvYI0XXTOrTwscyDF d/vvcoVczXf+ar0KLyYH8qgDhGEMAHaxQkdxUMqDV/Ug5N7o0uHAKoLMp9KUBsyvItvs wp9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ro7hbx3nyqWLvdwGgg24APXdQcBl2heZW+JScJ/9CJw=; b=GYAABGhuqDKooW+x2Odkpv+Lej5qSKt92jb7kwNCf4sSuU6v9B8YgBrab/SlGxyVMk r+jG4LqHh5IAdgyONfHktxfL9dJ5sBWP0aYHyjjfSIeTWwXl5sL+Z+MT/NPvOK9lZj4I IX7IaJGsSyoIqhDHPS2onIT3ZecopjgxB2vBIasy/Kmk7Mwp72A2/zSPHaMntIOhTNP+ Md6wFLUC0vIxYxmlhjbXMgQy7h6AssacN6GtmAkhH0BLV8wtqNRm+svQcvZ4y2hRw5tl dQWeULfF0giVrvr1+rIDqJxVMjq6NEyjGxKpa/FkU6eBLoc3PvKGxkD2FKr9RyiPCq0q 9XlA== X-Gm-Message-State: ABuFfohvFJe/GaUjosv4RbWcd64L6xwGck9tBQ+vBak3iy8UC1aMvniB AuS8PTcCiFNBe8sAswvGz85JKxZg/E+NmKQ7x9M= X-Google-Smtp-Source: ACcGV61U8ecy+p7GabuIodOcUQ78/mdeuGHoOjboG6s/ggtrr2Wsm+nhJA5KkU/uMTeF82tseeaZ2c/1rU3LOaH3eVY= X-Received: by 2002:a24:9147:: with SMTP id i68-v6mr819963ite.129.1538395519353; Mon, 01 Oct 2018 05:05:19 -0700 (PDT) MIME-Version: 1.0 References: <153833893256.13335.17089954204593908870@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Mon, 1 Oct 2018 15:05:07 +0300 Message-ID: To: "Pascal Thubert (pthubert)" Cc: rtg-dir@ietf.org, detnet@ietf.org, ietf , draft-ietf-detnet-problem-statement.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000074860e0577299eb6" Archived-At: Subject: Re: [Detnet] Rtgdir last call review of draft-ietf-detnet-problem-statement-06 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 12:05:29 -0000 --00000000000074860e0577299eb6 Content-Type: text/plain; charset="UTF-8" Hi Pascal, Thank you for your reply. I agree with your suggestions. Cheers, Ines. On Mon, Oct 1, 2018 at 10:26 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Ines > > Many thanks for your review. > > I see this recurring point of adding references to the other detnet > documents; I'm happy to follow this advice, noting though that these are > forward pointers since the problem statement comes first. > > Please see below: > > > I believe the draft is technically good. This document is well written > and clear to > > understand. > > > > The document describes the needs in various industries to establish > multi-hop > > paths for characterized flows with deterministic properties. > > > > This document is basically ready for publication, but I have some minor > > questions that should be considered prior to being submitted to the IESG. > > > > Comments: > > > > 1)- In section 1 you mention: "....a new model must be proposed to > integrate > > determinism in IT technology..." Do you think it is useful to mention > draft-ietf- > > detnet-architecture as a starting point for the model? > > > [PT>] what about: > " > Forward note: The > DetNet Architecture is the document produced by the DetNet WG > to > describe that model. > " > > > 2)- In Section 1: "the model should not compromise the ability of a > network to > > keep carrying the sorts of traffic that is already carried today in > conjunction > > with new, more deterministic flows.", and in Section 2 "The goals of > > Deterministic Networking (DetNet) are .... and to support both these new > > applications, and existing packet network applications, over the same > physical > > network." Those sentences seems to be related with Interoperability, but > > Interoperability is not explicitly mentioned in the document. Do you > think that it > > should be? > [PT>] Can we add after the latter sentence: > > " > In other words, a Deterministic Network is backwards compatible with - > capable > of transporting - statistically multiplexed traffic while preserving the > properties of the accepted deterministic flows. > " > > > > > 3)- In Section 2: "Multiple methods to schedule, shape, limit, and > otherwise > > control the transmission of critical packets at each hop through the > network > > data plane;" Do you think that it would be good to add something like: > "Detnet > > is working on IP Data Plane Encapsulation [ref.] and on MPLS Data Plane > > Encapsulation [ref]?" > [PT>] I'm not too inclined because this sentence is about a lot more than > DP > encoding, ad because this is really fast forwarding a lot. > > > > > 4)- In Section 2: "Robust defenses against misbehaving hosts, routers, or > > bridges,both in the data and control planes...." Do you think that it > would be > > good to add here or in the security considerations section (maybe > better) a > > reference to draft-ietf-detnet-security? > > > [PT>] You're right, that fit in both places. > > > Nits: > > > > It would be nice to expand DetNet in Section 1, since it is the first > time that it is > > mentioned. > > > [PT>] done > > Many Thanks, Ines : ) > > Pascal > > --00000000000074860e0577299eb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Thank you for your reply. I = agree with your suggestions.

Cheers,
Ines.

On Mon, Oct 1, 2018 at 10:26 AM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hello Ines

Many thanks for your review.

I see this recurring point of adding references to the other detnet documen= ts; I'm happy to follow this advice, noting though that these are forwa= rd pointers since the problem statement comes first.

Please see below:

> I believe the draft is technically good. This document is well written= and clear to
> understand.
>
> The document describes the needs in various industries to establish mu= lti-hop
> paths for characterized flows with deterministic properties.
>
> This document is basically ready for publication, but I have some mino= r
> questions that should be considered prior to being submitted to the IE= SG.
>
> Comments:
>
> 1)- In section 1 you mention: "....a new model must be proposed t= o integrate
> determinism in IT technology..." Do you think it is useful to men= tion draft-ietf-
> detnet-architecture as a starting point for the model?
>
[PT>] what about:
"
=C2=A0 =C2=A0 =C2=A0 Forward note: The <xref target=3D'I-D.ietf-detn= et-architecture'>
=C2=A0 =C2=A0 =C2=A0 DetNet Architecture</xref> is the document produ= ced by the DetNet WG to
=C2=A0 =C2=A0 =C2=A0 describe that model.
"

> 2)- In Section 1: "the model should not compromise the ability of= a network to
> keep carrying the sorts of traffic that is already carried today in co= njunction
> with new, more deterministic flows.", and in Section 2 "The = goals of
> Deterministic Networking (DetNet) are .... and to support both these n= ew
> applications, and existing packet network applications, over the same = physical
> network." Those sentences seems to be related with Interoperabili= ty, but
> Interoperability is not explicitly mentioned in the document. Do you t= hink that it
> should be?
[PT>] Can we add after the latter sentence:

"
In other words, a Deterministic Network is backwards compatible with - capa= ble
of transporting - statistically multiplexed traffic while preserving the properties of the accepted deterministic flows.
"

>
> 3)- In Section 2: "Multiple methods to schedule, shape, limit, an= d otherwise
> control the transmission of critical packets at each hop through the n= etwork
> data plane;" Do you think that it would be good to add something = like: "Detnet
> is working on IP Data Plane Encapsulation [ref.] and on MPLS Data Plan= e
> Encapsulation [ref]?"
[PT>] I'm not too inclined because this sentence is about a lot more= than DP
encoding, ad because this is really fast forwarding a lot.

>
> 4)- In Section 2: "Robust defenses against misbehaving hosts, rou= ters, or
> bridges,both in the data and control planes...." Do you think tha= t it would be
> good to add here or in the security considerations section (maybe bett= er) a
> reference to draft-ietf-detnet-security?
>
[PT>] You're right, that fit in both places.

> Nits:
>
> It would be nice to expand DetNet in Section 1, since it is the first = time that it is
> mentioned.
>
[PT>] done

Many Thanks, Ines : )

Pascal

--00000000000074860e0577299eb6-- From nobody Mon Oct 1 07:40:44 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249AC130DC9 for ; Mon, 1 Oct 2018 07:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8mjCZnuSpyO for ; Mon, 1 Oct 2018 07:40:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6C480130DDC for ; Mon, 1 Oct 2018 07:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538404829; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RZgVXXcQsP2dyNA/T473wj7u+G9zWGD9T/S/UUq8sPM=; b=QTRAWVLarmzAATpJsyOnjRTo+TaoR8dp1x4Yteog4JjlsJ7+qecX90AcqqTX9mIj Lm+56No5zv+EtVJc6oLFMW3rN02/CWJ31BHK+Tkeuhij21wNs5U9v/CcWGWuxCPb E/5qm9Si//Liy/9FpU85paIS9sddwFvyuCRAf4rNX/Q=; X-AuditID: c1b4fb25-cd2929c0000013ad-bb-5bb231dc4bbc Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.E9.05037.CD132BB5; Mon, 1 Oct 2018 16:40:29 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 1 Oct 2018 16:40:14 +0200 Received: from [159.107.143.203] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.188) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Mon, 1 Oct 2018 16:40:14 +0200 To: "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" References: <48ed7921-102a-daaf-2470-7ba87d5fa8ca@ericsson.com> <78f9a420-4bb7-d474-ed46-f7206230e959@ericsson.com> CC: "detnet-chairs@ietf.org" , "ieee-ietf-coord@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <60b64350-396a-0263-9be5-e48c706673e6@ericsson.com> Date: Mon, 1 Oct 2018 16:40:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8F5FA54C404CCC3EFEE8B8C2" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2J7me5dw03RBp3bmCyu9f9gsfj9aTaL xaU1/5gsVt/ydmDxWLLkJ5NHy7dTzAFMUVw2Kak5mWWpRfp2CVwZB4/MZi14dYWl4uSMo6wN jKt3MHcxcnJICJhIrJr+gamLkYtDSOAoo8TRA3+ZIZyvjBJ3pyxhhsusvP+WFaRFWCBd4s3b v2C2iECOxK+7vxlBbCGBY8wS824og9jMAnkSf2buZwKx2QTsJe5e2gC2jhfI/rGkH8xmEVCR +P3zH1AvB4eoQIzE+r4EiBJBiZMzn7CA2JwCDhJnH9xnhhgZJvHjzwpWiFVqEp/ePmSfwCgw C0nLLCRlELaFxOI3B9khbHmJ5q2zmSFsDYkFd/YxIosvYGRbxShanFqclJtuZKyXWpSZXFyc n6eXl1qyiREY9ge3/FbdwXj5jeMhRgEORiUe3tqPG6OFWBPLiitzDzFKcDArifDulN8ULcSb klhZlVqUH19UmpNafIhRmoNFSZz3ofnmKCGB9MSS1OzU1ILUIpgsEwenVANj33pRl7N3PsvI 6CcXO/9Yw/0iUPXvAr3tFd+lYrc/PCCfWzVBS+fL8omZ5z+2mZaUnD3inv7WxCVwpvrpIOaW GZkLr7i+C12UsHPmIoVa0QCFfU/DbRJzDjdPEpXf/GP/FzknmT3mDQ07z+mZhO9duWbpb5Xz BXsM/0q9fPznYjhz0gutk97VSizFGYmGWsxFxYkA1L378HcCAAA= Archived-At: Subject: Re: [Detnet] =?utf-8?q?=5Bieee-ietf-coord=5D_DetNet_=E2=80=93_TSN_jo?= =?utf-8?q?int_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:40:35 -0000 --------------8F5FA54C404CCC3EFEE8B8C2 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, Initial draft agenda is available at: https://1.ieee802.org/tsn/tsn-task-group-agenda/#Sunday_DetNet_8211_TSN_joint_session Please note that remote participation is not possible. Best regards, Janos On 9/27/2018 11:32 PM, János Farkas wrote: > Hi, > > As discussed earlier, we have separate registration for the joint > sessions in Bangkok during the weekend between IETF 103 and the IEEE > 802 Plenary. Registration is requited to attend these sessions. There > is no registration fee. > > > Please Register your planned attendance with the registration link for > the November 2018 IEEE 802 IETF Joint meetings: > > https://www.regonline.com/builder/site/Default.aspx?EventID=2534613 > > (No cost to register, but registration will allow to plan > appropriately for the 3 meetings to be held Saturday or Sunday.) > > *IEEE 802 - IETF Joint Meetings are sponsored by IEEE 802 and IETF. * > > *Registration for the meetings is required. * > > * There is no registration fee. > > > Saturday November 10th 8:00 AM - 12:00 PM > > *IEEE 802/IETF Leadership* > > Saturday November 10th 1:30 PM - 5:30 PM > > *IEEE802/IETF Workshop: Data Center Workshop* > > *Open Invitation* > > Sunday November 11th 8:00 AM - 18:00 PM > > *DetNet - TSN Workshop* > > *Open Invitation* > > > > Many thanks to all who made it possible! > > Best regards, > Janos > > ps: > If you are also attending the 802 Plenary, then please note that the > deadline for early registration is 6:00 PM Pacific Time, Friday, > September 28, 2018 > > > On 9/12/2018 5:39 PM, Andrew G. Malis wrote: >> János, >> >> Thanks, much appreciated. Enjoy the 802 meeting! >> >> Cheers, >> Andy >> >> >> On Wed, Sep 12, 2018 at 11:38 AM, János Farkas >> > wrote: >> >> The plan is to have separate registration for Sunday. I'll email >> the link as soon as I have it. >> Regards, >> Janos >> >> >> >> On 9/11/2018 3:28 PM, Andrew G. Malis wrote: >>> János, >>> >>> I just extended my IETF reservation to go through Monday. >>> >>> If you're only attending the Sunday meeting, is IEEE >>> registration required? Or will there be a separate registration >>> for Sunday? >>> >>> Thanks, >>> Andy >>> >>> >>> On Mon, Sep 10, 2018 at 8:45 AM, János Farkas >>> > >>> wrote: >>> >>> Hi, >>> >>> It is possible to make hotel reservation and register for >>> the Bangkok IEEE 802 Plenary in November 2018: >>> http://802world.org/plenary/ >>> >>> Best regards, >>> János >>> >>> >>> >>> On 8/6/2018 11:20 PM, Janos Farkas wrote: >>> >>> Hi, >>> >>> Please note that hotel reservation for IETF 103 is >>> possible: https://www.ietf.org/how/meetings/103/hotel/ >>> . >>> >>> My understanding of the cancellation policy for >>> reservations at Bangkok Marriott Marquis Queen's Park is >>> that cancellation is free up to 72 hours prior to >>> arrival, however, it is not possible to change the >>> reservation. I may be wrong. (This is what I saw after >>> making a reservation.) >>> >>> Note that hotel room booking via IEEE 802 is needed in >>> order to get a discount from the IEEE 802 Plenary >>> registration fee. At least one night is needed. (As far >>> as I recall, the discount is usually USD 300.) >>> >>> IEEE 802 hotel reservation is not yet available, but it >>> will be soon: >>> http://802world.org/plenary/ieee-802-group-hotel/ >>> >>> >>> Best regards, >>> János >>> >>> -----Original Message----- >>> From: János Farkas >> > >>> Sent: Tuesday, July 31, 2018 10:32 AM >>> To: detnet@ietf.org ; >>> STDS-802-1-L@LISTSERV.IEEE.ORG >>> >>> Cc: detnet-chairs@ietf.org >>> Subject: DetNet – TSN joint session in Bangkok >>> >>> Hi, >>> >>> We will have a DetNet – TSN joint session in Bangkok on >>> November 11 Sunday, which is between IETF 103 and the >>> IEEE 802 Plenary. The two meetings are back to back in >>> the same hotel: Marriott Marquis Queen’s Park, Bangkok, >>> Thailand (https://www.ietf.org/how/meetings/upcoming >>> , >>> http://802world.org/plenary/future-plenary-sessions >>> ). >>> The joint session will be from 9am to 5pm with a lunch >>> break. >>> Meeting room is being arranged by IEEE 802. >>> There will be a web page for registration. Registration >>> will be required; work is ongoing to make it free. >>> >>> We propose the following topics for the joint session >>> both for DetNet and TSN: >>> - current status >>> - ongoing work >>> - future plans >>> - related activities, e.g., TEAS, IoT for DetNet; IEC, >>> IEEE for TSN >>> >>> Please send agenda requests to detnet-chairs@ietf. >>> >>> Agenda will be worked after August holidays. >>> >>> We will provide updates, e.g., on registration, agenda, >>> etc., as they become available. >>> >>> The co-located meetings give the opportunity to >>> participate the meeting of the other group, the group >>> one usually not attends or haven’t attended yet. We have >>> collected some information to help navigation, making >>> decision, e.g., agendas of the last meetings. >>> >>> IETF DetNet WG info: >>> Web page: https://datatracker.ietf.org/wg/detnet/about/ >>> >>> Documents: >>> https://datatracker.ietf.org/wg/detnet/documents/ >>> >>> DetNet WG at IETF 102: >>> - Agenda: >>> https://datatracker.ietf.org/wg/detnet/documents/ >>> >>> - Presentations: >>> https://datatracker.ietf.org/meeting/102/session/detnet >>> >>> - Minutes: >>> https://datatracker.ietf.org/doc/minutes-102-detnet/ >>> >>> IETF 102 overall agenda: >>> https://datatracker.ietf.org/meeting/102/agenda.html >>> >>> IETF 102 general information: >>> https://www.ietf.org/how/meetings/102/ >>> >>> IETF 103 registration: >>> https://www.ietf.org/how/meetings/103/ >>> >>> >>> IEEE 802.1TSN TG info: >>> Web page: http://ieee802.org/1/tsn >>> Documents are available via the links provided at the TG >>> page, e.g., via the project pages. >>> TSN TG at the July 2018 IEEE 802 Plenary: >>> - Agenda: >>> https://1.ieee802.org/july-2018-plenary-meeting-in-san-diego-ca-usa-tsn-tg-agenda/ >>> >>> >>> - Presentations are linked from the agenda >>> - Minutes: >>> https://1.ieee802.org/category/current-and-former-meetings/ >>> >>> IEEE 802 Plenary overall schedule: >>> http://schedule.802world.com/schedule/schedule/show# >>> , >>> July Plenary is saved at: >>> http://www.ieee802.org/1/files/public/docs2018/admin-802-schedule-0718.pdf >>> .) >>> IEEE 802 Plenary general information: >>> http://802world.org/plenary/ IEEE >>> 802 Plenary registration: >>> http://802world.org/plenary/registration-information/ >>> >>> Note that the Plenary pages show the July Plenary at the >>> moment; they will be updated to the November Plenary as >>> we are getting closer. >>> >>> If you are new to TSN, then the IEC/IEEE 60802 Joint >>> Project may be of >>> interest: >>> http://ieee802.org/1/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation >>> . >>> The Joint Project has been formed to specify how to use >>> TSN for industrial automation. The meetings of the joint >>> project are listed on the web page. The joint project >>> will meet November 12-14 in Bangkok. >>> >>> If you have questions, don’t hesitate to ask us. >>> >>> Best regards, >>> János and Lou >>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >>> >>> >> >> > > > > _______________________________________________ > ieee-ietf-coord mailing list > ieee-ietf-coord@ietf.org > https://www.ietf.org/mailman/listinfo/ieee-ietf-coord --------------8F5FA54C404CCC3EFEE8B8C2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi,

Initial draft agenda is available at:
https://1.ieee802.org/tsn/tsn-task-group-agenda/#Sunday_DetNet_8211_TSN_joint_session

Please note that remote participation is not possible.

Best regards,
Janos


On 9/27/2018 11:32 PM, János Farkas wrote:
Hi,

As discussed earlier, we have separate registration for the joint sessions in Bangkok during the weekend between IETF 103 and the IEEE 802 Plenary. Registration is requited to attend these sessions. There is no registration fee.


Please Register your planned attendance with the registration link for the November 2018 IEEE 802 IETF Joint meetings:

https://www.regonline.com/builder/site/Default.aspx?EventID=2534613

 

(No cost to register, but registration will allow to plan appropriately for the 3 meetings to be held Saturday or Sunday.)

IEEE 802 - IETF Joint Meetings are sponsored by IEEE 802 and IETF.  

Registration for the meetings is required. 

  • There is no registration fee.


Saturday November 10th 8:00 AM - 12:00 PM

IEEE 802/IETF Leadership

 

Saturday November 10th 1:30 PM - 5:30 PM

IEEE802/IETF Workshop: Data Center Workshop

Open Invitation

 

Sunday November 11th 8:00 AM - 18:00 PM

DetNet - TSN Workshop

Open Invitation



Many thanks to all who made it possible!

Best regards,
Janos

ps:
If you are also attending the 802 Plenary, then please note that the deadline for early registration is 6:00 PM Pacific Time, Friday, September 28, 2018


On 9/12/2018 5:39 PM, Andrew G. Malis wrote:
János,

Thanks, much appreciated. Enjoy the 802 meeting!

Cheers,
Andy


On Wed, Sep 12, 2018 at 11:38 AM, János Farkas <janos.farkas@ericsson.com> wrote:
The plan is to have separate registration for Sunday. I'll email the link as soon as I have it.
Regards,
Janos



On 9/11/2018 3:28 PM, Andrew G. Malis wrote:
János,

I just extended my IETF reservation to go through Monday.

If you're only attending the Sunday meeting, is IEEE registration required? Or will there be a separate registration for Sunday?

Thanks,
Andy


On Mon, Sep 10, 2018 at 8:45 AM, János Farkas <janos.farkas@ericsson.com> wrote:
Hi,

It is possible to make hotel reservation and register for the Bangkok IEEE 802 Plenary in November 2018:
http://802world.org/plenary/

Best regards,
János



On 8/6/2018 11:20 PM, Janos Farkas wrote:
Hi,

Please note that hotel reservation for IETF 103 is possible: https://www.ietf.org/how/meetings/103/hotel/.

My understanding of the cancellation policy for reservations at Bangkok Marriott Marquis Queen's Park is that cancellation is free up to 72 hours prior to arrival, however, it is not possible to change the reservation. I may be wrong. (This is what I saw after making a reservation.)

Note that hotel room booking via IEEE 802 is needed in order to get a discount from the IEEE 802 Plenary registration fee. At least one night is needed. (As far as I recall, the discount is usually USD 300.)

IEEE 802 hotel reservation is not yet available, but it will be soon: http://802world.org/plenary/ieee-802-group-hotel/

Best regards,
János

-----Original Message-----
From: János Farkas <janos.farkas@ericsson.com>
Sent: Tuesday, July 31, 2018 10:32 AM
To: detnet@ietf.org; STDS-802-1-L@LISTSERV.IEEE.ORG
Cc: detnet-chairs@ietf.org
Subject: DetNet – TSN joint session in Bangkok

Hi,

We will have a DetNet – TSN joint session in Bangkok on November 11 Sunday, which is between IETF 103 and the IEEE 802 Plenary. The two meetings are back to back in the same hotel: Marriott Marquis Queen’s Park, Bangkok, Thailand (https://www.ietf.org/how/meetings/upcoming,
http://802world.org/plenary/future-plenary-sessions).
The joint session will be from 9am to 5pm with a lunch break.
Meeting room is being arranged by IEEE 802.
There will be a web page for registration. Registration will be required; work is ongoing to make it free.

We propose the following topics for the joint session both for DetNet and TSN:
- current status
- ongoing work
- future plans
- related activities, e.g., TEAS, IoT for DetNet; IEC, IEEE for TSN

Please send agenda requests to detnet-chairs@ietf.

Agenda will be worked after August holidays.

We will provide updates, e.g., on registration, agenda, etc., as they become available.

The co-located meetings give the opportunity to participate the meeting of the other group, the group one usually not attends or haven’t attended yet. We have collected some information to help navigation, making decision, e.g., agendas of the last meetings.

IETF DetNet WG info:
Web page: https://datatracker.ietf.org/wg/detnet/about/
Documents: https://datatracker.ietf.org/wg/detnet/documents/
DetNet WG at IETF 102:
     - Agenda: https://datatracker.ietf.org/wg/detnet/documents/
     - Presentations:
https://datatracker.ietf.org/meeting/102/session/detnet
     - Minutes: https://datatracker.ietf.org/doc/minutes-102-detnet/
IETF 102 overall agenda:
https://datatracker.ietf.org/meeting/102/agenda.html
IETF 102 general information: https://www.ietf.org/how/meetings/102/
IETF 103 registration: https://www.ietf.org/how/meetings/103/

IEEE 802.1TSN TG info:
Web page: http://ieee802.org/1/tsn
Documents are available via the links provided at the TG page, e.g., via the project pages.
TSN TG at the July 2018 IEEE 802 Plenary:
     - Agenda:
https://1.ieee802.org/july-2018-plenary-meeting-in-san-diego-ca-usa-tsn-tg-agenda/

     - Presentations are linked from the agenda
     - Minutes: https://1.ieee802.org/category/current-and-former-meetings/
IEEE 802 Plenary overall schedule:
http://schedule.802world.com/schedule/schedule/show#, July Plenary is saved at:
http://www.ieee802.org/1/files/public/docs2018/admin-802-schedule-0718.pdf.)
IEEE 802 Plenary general information: http://802world.org/plenary/ IEEE
802 Plenary registration:
http://802world.org/plenary/registration-information/
Note that the Plenary pages show the July Plenary at the moment; they will be updated to the November Plenary as we are getting closer.

If you are new to TSN, then the IEC/IEEE 60802 Joint Project may be of
interest:
http://ieee802.org/1/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation.
The Joint Project has been formed to specify how to use TSN for industrial automation. The meetings of the joint project are listed on the web page. The joint project will meet November 12-14 in Bangkok.

If you have questions, don’t hesitate to ask us.

Best regards,
János and Lou


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet






_______________________________________________
ieee-ietf-coord mailing list
ieee-ietf-coord@ietf.org
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

--------------8F5FA54C404CCC3EFEE8B8C2-- From nobody Mon Oct 1 10:51:27 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D91130E74 for ; Mon, 1 Oct 2018 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 3UizUHUURgKf for ; Mon, 1 Oct 2018 10:51:23 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 E5A57128C65 for ; Mon, 1 Oct 2018 10:51:22 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 150701E1A04 for ; Mon, 1 Oct 2018 11:51:20 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 72LngANEJd20T72LngA1NR; Mon, 01 Oct 2018 11:51:20 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=tSxSimaBuXkFi2NgoNPQSVngzSDkSWPI6nM8r45uJn0=; b=gR61r9CI0bFk//zDT4ndkJS/vu MBNX4Ir3reVvrcjsB6YxXw9rIB/CfchMcS1x30SHOTEk/kDlqagsEdioTWB8i+8mPOtsLr4TFjdRy oTeqowMrvSRKGLJ/q2xDSYGGp; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:56652 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g72Ln-002Lgs-Hb for detnet@ietf.org; Mon, 01 Oct 2018 11:51:19 -0600 To: detnet@ietf.org References: <2123314461.8933.1538215441698.JavaMail.nobody@jva2tc204.webex.com> From: Lou Berger Message-ID: Date: Mon, 1 Oct 2018 13:51:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2123314461.8933.1538215441698.JavaMail.nobody@jva2tc204.webex.com> Content-Type: multipart/alternative; boundary="------------9E6AC903725C9044C37516E1" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g72Ln-002Lgs-Hb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:56652 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Webex meeting invitation: Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 17:51:26 -0000 This is a multi-part message in MIME format. --------------9E6AC903725C9044C37516E1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello,     Please note  -- these webex's are for informal author's working meetings that are open to all. These meetings are *not* formal WG interims. Lou On 9/29/2018 6:04 AM, DetNet Working Group wrote: > Hello, > DetNet Working Group invites you to join this Webex meeting. > > *Detnet DP working meeting* > Thursday, October 11, 2018 > 4:30 pm  |  Sweden Summer Time (Stockholm, GMT+02:00)  |  1 hr 30 mins > > Meeting number (access code): 643 755 067 > > Meeting password: RjRmkCsJ > > > > Add to Calendar > > > > > When it's time, join the meeting > . > > > *Join by phone* > *1-650-479-3208 > * Call-in toll number > (US/Canada) > > Can't join the meeting? > > > IMPORTANT NOTICE: Please note that this Webex service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you > automatically consent to such recordings. If you do not consent to > being recorded, discuss your concerns with the host or do not join the > session. > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------9E6AC903725C9044C37516E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

    Please note  -- these webex's are for informal author's working meetings that are open to all.

These meetings are *not* formal WG interims.

Lou

On 9/29/2018 6:04 AM, DetNet Working Group wrote:
Hello,
DetNet Working Group invites you to join this Webex meeting.
 
Detnet DP working meeting
Thursday, October 11, 2018
4:30 pm  |  Sweden Summer Time (Stockholm, GMT+02:00)  |  1 hr 30 mins
Meeting number (access code): 643 755 067
Meeting password: RjRmkCsJ


 
Add to Calendar
When it's time, join the meeting.
 
Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
 
Can't join the meeting?
 
IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. 


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

--------------9E6AC903725C9044C37516E1-- From nobody Tue Oct 2 10:19:31 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1EA1311D0 for ; Tue, 2 Oct 2018 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=VMLQsR8j; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YDTJY8E6 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 TRMRqdV-Uoqw for ; Tue, 2 Oct 2018 10:19:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C42A913125B for ; Tue, 2 Oct 2018 10:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538500614; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sjg7fSBhVZF0A6kmArHBEn1jrkUBCuohblFsupUl7Ys=; b=VMLQsR8jo0DK886UUNkhuMFq9xIQY0ywlkqX2X8cSsH7b3T91dS2/98nHKiOzyt/ 0mutpM3UkGRXWJXfq3mbCXNSdOe2x6Wqgt4BzPWdLUmyoD2DDw70ufb1VW8BP5rI kIA8NXLstks1bLETDFexgahl+PNIw49m/IEUWZRYSIQ=; X-AuditID: c1b4fb30-fe1ff700000055da-96-5bb3a805de19 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.85.21978.608A3BB5; Tue, 2 Oct 2018 19:16:54 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 2 Oct 2018 19:16:53 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 2 Oct 2018 19:16:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sjg7fSBhVZF0A6kmArHBEn1jrkUBCuohblFsupUl7Ys=; b=YDTJY8E6ij9wn40X7eIN2EoAiDoIY0hQRQN0h+9pzsFfCEARJrcYX8Le11LbDa1bGONLe8KNmwIj0x7Dy17F+spwSVUc8QZVH6w/UR0juQbcV20ABIRQUVUUiSk9fdF3ei/tMnQ4KZZjWzdnpiyWygrVh79imqCftbRd3yZF0lg= Received: from VI1PR0701MB2525.eurprd07.prod.outlook.com (10.168.139.138) by VI1PR0701MB2046.eurprd07.prod.outlook.com (10.167.209.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Tue, 2 Oct 2018 17:16:51 +0000 Received: from VI1PR0701MB2525.eurprd07.prod.outlook.com ([fe80::d5c4:d250:2cdb:ee17]) by VI1PR0701MB2525.eurprd07.prod.outlook.com ([fe80::d5c4:d250:2cdb:ee17%4]) with mapi id 15.20.1207.018; Tue, 2 Oct 2018 17:16:51 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: Lou Berger , "detnet@ietf.org" Thread-Topic: Input for 3th Oct, Detnet DP working meeting Thread-Index: AdRac7P71lXjzG9vQQi1vE3V3aN68A== Date: Tue, 2 Oct 2018 17:16:51 +0000 Message-ID: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [94.21.144.147] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2046; 6:daV9nmJoZZAXohXQGZPoiZPzHtLSO/EJr83T1o+jEJSOxE9u3hjQlNlumIUe4l0mwoaBM94mn7MbtQ8NpGLXhnELo6Gf+rqiTgVBEBeb7NjgDMuUYlfCpBZuqWeX2Dj5mzuacy1O51xRpHu3N07m1apjlherVHgGUbCFUEOdTfN/7wV9B/clqExSznBeAQfuQXmtIOtQ2DFZSVIQ1DGoVUXLexHhn5S8bfa/0zdMtPf7jDB5nE3Jak09/UHyv0Y4v/arn0dN6jUXbmBmfy++yxPAyFua3esinhaKOGpeSAbHa/oUgrPhJfnVJyHQLmf3UCYGoISN1KWsSt5hb2YKSdjwHcGUuySsh8EI+BzzcGegInCL3tQJl+aH1RsCKNH6/Au40DGCKrrTADzwWlfarc/TyEVnQ5t6iSMq67zw6gPYSb+fhiEXMpnvmX3ISuxFCMg0Ru/S556N0cbQA22ZLg==; 5:9NnIxosDt18ab82CAcbVrArVyA+wSxa2/14FEzhcOOQUgOVXR7c6k3vVeiD/bJnjc8nNNi/gVrl/DpRPjoeIdJ/EtSKtTNw9AV4gyIHAOotnAkwgGaZI48FcINghZSGk+RjHVfU2XTCCXvtgUHtAfPB2hM3mjhpO3InKLWA+4f0=; 7:9/sCEJitIwiACbrBUL1Ta1yCif68I8x49Hr+9vlqSYpoJDzjnupn29dV7tKx1E7Hs7flwGn/q1VRmc4ij3qD/lHg71Pe9KcA4AOg5qO+bMjjA2uQG/flxZIL1ko0Hc19mpG5R/JOALFMQK5IwleGYeIAuuZhqrc+aQtx5gMofeM5SfdtyL3xi8+ws1UQl7JjTtrlFc3ow6AbTklTmDZ03l4ljeH53sBH0Bf4S/lAVulu7l+6gI1W7ybrBMO3AVY4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8c053f5f-2f12-4c5e-a5dd-08d6288ad807 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2046; x-ms-traffictypediagnostic: VI1PR0701MB2046: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(94707916325470)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:VI1PR0701MB2046; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2046; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(25786009)(54896002)(106356001)(6306002)(9686003)(105586002)(85202003)(236005)(55016002)(5660300001)(53936002)(14454004)(478600001)(97736004)(6116002)(790700001)(3846002)(53546011)(6506007)(966005)(99286004)(7696005)(110136005)(33656002)(2900100001)(6436002)(71190400001)(71200400001)(2906002)(5250100002)(551544002)(2501003)(86362001)(66066001)(606006)(476003)(486006)(8676002)(16799955002)(68736007)(14444005)(19627405001)(256004)(81166006)(81156014)(85182001)(66574008)(74316002)(8936002)(7736002)(26005)(102836004)(316002)(186003)(9326002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2046; H:VI1PR0701MB2525.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eQOBffww7xoLLLgSL0pH4CERED6rA1HscQilPrkdEZnCvGcaziC5gKi98RyKjKLctTJbyUuvvjO7YJvTcYnK810uQltR6z3tjpnd/bv5voz9W/w5tRRIBUuCbk02hPOaet/bwMRb0uxHtPqNgkWk//wNyW0fkS65V934Zqj4udP17CyYJVl80FBHqJpCxpy6kERMaX/iQhZHPg/2YORWZxkiz6aBsqOPjYkKD9eAChBiMf5eLuenfsDsJawDMT51PIGZ0qqjVPXYpFNVmGwC3JK7R8VC5S3aGFGwcYEB2nPVWJUiV7o51MZPREsCwGy91OszL8YFfC35U9UWb6wSKfIp+15XRaXAs24A+6hS5pY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2525DFC9F6C0C9C2C6F9BDB0ACE80VI1PR0701MB2525_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c053f5f-2f12-4c5e-a5dd-08d6288ad807 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2018 17:16:51.3100 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2046 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc85Oztag9el+WBauCLXxUtiMaRCIcQvSgSCKKRTD7rmrR01 jYyRBV4qJl7QpSx0go3Z1papEaQLQQVRpNIyL7OV+sFYZoSXNLezwG//5///vTwXXoYUGwWB jKKgmFUVyPMktA/VktJ7K4zusqZFvuoiZFtrTyhZVeUqFUsk6PUbRILTUklfJVJ9LmazeYpS VhVxOcMnd6xuky5yrKOyxWEDrUbGH6gGeTOAo6H6i0FQg3wYMR5C8H57VsgXvxE0/FqkXJQY dxBgtSW6AgprSBhwtJM81UzA8+kpxBffENx7N0a7ntD4CvRZWgUu7YfjYa7uI+HSh/B5+Plh V8j7MTBs/oR4HQ76UY2bofAJsHS3uX0RzoAhq3mvG8MgHAz2bpnLJnEAfHboCH4HDPo34ySv /WHl6467LcLXYeut2uOHQLO13aODYVJX654Z8IAQenecFB+EgbOx0QMlgqG/XshDIwjWHm56 oLOw4FxDroEAF8KEOZln2hC8ePbdc9WjYHhkp/ign4T+eiPNB0EwW1kl4IN2GrSdW7QGhWn3 rcTrQtBZF0mt+wK+MNLioLR7DUl8CkyvI3gkBBpq7UJeS+FBa5twv/8UCQ3In2O5zPycqKhw VqXI4rjCgvACttiC9v7Q4MutyD60shRnQ5hBkoOiM+3WNLFAXsqV59sQMKTET/RYvmeJsuXl t1lVYbqqJI/lbOgIQ0kCRLIka6oY58iLWSXLFrGq/ynBeAeqUVaEUReZPam/1mNUz1VJ78fM Z86sVhB9XqhHYzd1t8QfPkneaPFNVyvnp8cNJUH6Dq+NC8lJ9cqlutHmqRRFeOKyPflP2cKl opvcbtBE63ZTgrlJelcZqo8+4HvMYJo6vhM7U1ERmigjtEySbn1oOW7pb7V5ULo2cqfTq8ck obhc+bnTpIqT/wNfE3+iPwMAAA== Archived-At: Subject: [Detnet] Input for 3th Oct, Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 17:19:30 -0000 --_000_VI1PR0701MB2525DFC9F6C0C9C2C6F9BDB0ACE80VI1PR0701MB2525_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRvbW9ycm93IHdlIHdpbGwgZm9jdXMgb24gdGhlIElQIGRvY3VtZW50Lg0KSSBoYXZl IHVwZGF0ZWQgZHJhZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLTAxIGZvciB0aGUgY2FsbC4NCg0K aHR0cHM6Ly9naXRodWIuY29tL2RldG5ldC13Zy9kcmFmdC1pZXRmLWRldG5ldC1kcC1zb2wtaXAN Cg0KQ2hlZXJzDQpCYWxh4oCZenMNCg0KRnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IDIwMTguIG9rdMOzYmVyIDEuIDE5 OjUxDQpUbzogZGV0bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RldG5ldF0gV2ViZXggbWVl dGluZyBpbnZpdGF0aW9uOiBEZXRuZXQgRFAgd29ya2luZyBtZWV0aW5nDQoNCg0KSGVsbG8sDQoN CiAgICBQbGVhc2Ugbm90ZSAgLS0gdGhlc2Ugd2ViZXgncyBhcmUgZm9yIGluZm9ybWFsIGF1dGhv cidzIHdvcmtpbmcgbWVldGluZ3MgdGhhdCBhcmUgb3BlbiB0byBhbGwuDQoNClRoZXNlIG1lZXRp bmdzIGFyZSAqbm90KiBmb3JtYWwgV0cgaW50ZXJpbXMuDQoNCkxvdQ0KT24gOS8yOS8yMDE4IDY6 MDQgQU0sIERldE5ldCBXb3JraW5nIEdyb3VwIHdyb3RlOg0KDQpIZWxsbywNCg0KRGV0TmV0IFdv cmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuDQoNCg0K DQoNCg0KRGV0bmV0IERQIHdvcmtpbmcgbWVldGluZw0KDQpUaHVyc2RheSwgT2N0b2JlciAxMSwg MjAxOA0KDQo0OjMwIHBtICB8ICBTd2VkZW4gU3VtbWVyIFRpbWUgKFN0b2NraG9sbSwgR01UKzAy OjAwKSAgfCAgMSBociAzMCBtaW5zDQoNCg0KTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTog NjQzIDc1NSAwNjcNCg0KDQpNZWV0aW5nIHBhc3N3b3JkOiBSalJta0NzSg0KDQoNCg0KDQoNCkFk ZCB0byBDYWxlbmRhcjxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNWZj M2Q2NGEwZDc0MWI2YmVlMGY0YTRlMmVhYzc3Njk+DQoNCg0KV2hlbiBpdCdzIHRpbWUsIGpvaW4g dGhlIG1lZXRpbmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTIxNmM0 ZTQzYmNjZWUxNzg2OWEyOTVmZGY2ZjZiMDhkPi4NCg0KDQoNCg0KDQoNCkpvaW4gYnkgcGhvbmUN Cg0KMS02NTAtNDc5LTMyMDg8dGVsOisxLTY1MC00NzktMzIwOCwsKjAxKjY0Mzc1NTA2NyUyMyUy MyowMSo+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCg0KDQoNCg0KDQpDYW4ndCBq b2luIHRoZSBtZWV0aW5nPyA8aHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0 aWNsZS9XQlgwMDAwMjkwNTU+DQoNCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5v dGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1h dGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJl IGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24s IHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8g bm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRo IHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLg0KDQoNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkZXRuZXQgbWFp bGluZyBsaXN0DQoNCmRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KDQo= --_000_VI1PR0701MB2525DFC9F6C0C9C2C6F9BDB0ACE80VI1PR0701MB2525_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsN Cgljb2xvcjojNjY2NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiM2NjY2 NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub21vcnJvdyB3ZSB3aWxsIGZvY3VzIG9uIHRoZSBJUCBk b2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSB1cGRh dGVkIGRyYWZ0LWlldGYtZGV0bmV0LWRwLXNvbC1pcC0wMSBmb3IgdGhlIGNhbGwuPHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+aHR0cHM6Ly9naXRodWIuY29tL2RldG5ldC13Zy9kcmFmdC1pZXRmLWRldG5ldC1k cC1zb2wtaXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkNoZWVy czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij5CYWxh4oCZenM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBkZXRuZXQgJmx0O2Rl dG5ldC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3UgQmVyZ2Vy PGJyPg0KPGI+U2VudDo8L2I+IDIwMTguIG9rdMOzYmVyIDEuIDE5OjUxPGJyPg0KPGI+VG86PC9i PiBkZXRuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRdIFdlYmV4 IG1lZXRpbmcgaW52aXRhdGlvbjogRGV0bmV0IERQIHdvcmtpbmcgbWVldGluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFBsZWFzZSBub3RlJm5ic3A7IC0tIHRoZXNlIHdlYmV4J3MgYXJlIGZvciBpbmZvcm1h bCBhdXRob3IncyB3b3JraW5nIG1lZXRpbmdzIHRoYXQgYXJlIG9wZW4gdG8gYWxsLjxvOnA+PC9v OnA+PC9wPg0KPHA+VGhlc2UgbWVldGluZ3MgYXJlICpub3QqIGZvcm1hbCBXRyBpbnRlcmltcy48 bzpwPjwvbzpwPjwvcD4NCjxwPkxvdTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gOS8yOS8yMDE4IDY6MDQgQU0sIERldE5ldCBXb3JraW5nIEdyb3VwIHdyb3RlOjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxl PSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMuNzVw dCAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5 My43NXB0O21hcmdpbi1sZWZ0OjMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0i d2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5IZWxsbywNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjcuNXB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPkRldE5ldCBXb3JraW5nIEdy b3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJo ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+RGV0 bmV0IERQIHdvcmtpbmcgbWVldGluZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0 RDREIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5U aHVyc2RheSwgT2N0b2JlciAxMSwgMjAxOA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPjQ6MzAgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7U3dlZGVu IFN1bW1lciBUaW1lIChTdG9ja2hvbG0sIEdNVCYjNDM7MDI6MDApJm5ic3A7Jm5ic3A7fCZuYnNw OyZuYnNwOzEgaHIgMzAgbWlucw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25l Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBj bTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgbnVt YmVyIChhY2Nlc3MgY29kZSk6IDY0MyA3NTUgMDY3DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2Njtk aXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHls ZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ TWVldGluZyBwYXNzd29yZDogUmpSbWtDc0o8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dp ZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO2JhY2tncm91bmQ6IzA0OENCRjtib3JkZXI6c29saWQg IzA0OENCRiAxLjVwdDt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg c3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MTAuNXB0IDE1LjBwdCAxMC41cHQgMTUuMHB0O3dp ZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMTg2cHghaW1wb3J0YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW01ZmMzZDY0YTBkNzQxYjZiZWUwZjRhNGUyZWFjNzc2OSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PkFkZCB0byBDYWxlbmRhcjwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDox ODZweCFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDEyLjBwdDt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHghaW1wb3J0 YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPldoZW4gaXQncyB0aW1lLA0KPGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTIxNmM0ZTQzYmNjZWUxNzg2 OWEyOTVmZGY2ZjZiMDhkIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3Jh dGlvbjpub25lIj5qb2luIHRoZSBtZWV0aW5nPC9zcGFuPjwvYT4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43 NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2 NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5Kb2luIGJ5IHBob25lPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJ0ZWw6JiM0MzsxLTY1MC00NzktMzIwOCwsKjAxKjY0 Mzc1NTA2NyUyMyUyMyowMSoiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3Jh dGlvbjpub25lIj4xLTY1MC00NzktMzIwODwvc3Bhbj48L2E+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwO0NhbGwtaW4NCiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4N Cjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij48YSBocmVmPSJodHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRp Y2xlL1dCWDAwMDAyOTA1NSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIg d2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjcuNXB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0 OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0 OjcuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZw0KIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGV0bmV0IG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPmRldG5ldEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k ZXRuZXQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGV0bmV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_VI1PR0701MB2525DFC9F6C0C9C2C6F9BDB0ACE80VI1PR0701MB2525_-- From nobody Tue Oct 2 11:25:16 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6429C130FBD for ; Tue, 2 Oct 2018 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nO5FcUViNDV for ; Tue, 2 Oct 2018 11:25:12 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 69AC5130EF5 for ; Tue, 2 Oct 2018 11:25:11 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id f8-v6so2697681ljk.1 for ; Tue, 02 Oct 2018 11:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FDhsI/P56EJQz7dZ/7dOWK7un0+s0AD2M8rD5Q7gZPc=; b=u1MSw19u8VbT/ug28YifL1Z1AclhUEM98XoNj6WbzJZgNOew/SRzeqEKci34tC3rJM o0l/ZoK5hIfYG5yiq5WEA2qqoPrjHvjewn11nOWef+nV66aYLUGv1jnssy8XelUSbM4J HY6oYAbYbLMtSpPmZ/vYJmw7fxxNjR5Sngf1+JrG+qy8UpftO2hm6RFojOSegDQc0+y5 utCpTN7r8haAaAhYUcnyAdf+UwGti+mqVz3JaG4llbKtdE+adoeAfLWf6IsmbqV4Llk5 f+VmblhruMfgF4WwA/79WT7NejqDMqxVKAJIgX6LARmSjTqH6Jwf7ppDetZHVuYf4oSd /u5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FDhsI/P56EJQz7dZ/7dOWK7un0+s0AD2M8rD5Q7gZPc=; b=kCSy/1AMasOZENlnBjI/I2Y/XwK5PZNO22pX0GjRhUGYhX7DP9Wa7Gdl3gxnEAxsI+ Z7BAacKGfARiz14MvSkTMHEqDR+tEDMjHUd0lPvBwrzoZeI78dhj7AZSQR5UcbUF4Ey0 +beaUfj4FjmDTGlGX7HFlpxlwzHUyBXQ8eFB6zPBfkvfL8WOjXzFKpCO45Sb09rC46h8 5rKneAVQScfnCMvzbxkkVWmmDn1/2svo18g+vLqHQOotKIeZWaa9EuIc7/NzzZtKdpu4 oXCncXY356xSrZRS4ljWm1vAvs/eOn9TkSNU4dzSsDA0dbsilzrip4r0ZhbOc7P/o5ul Qelw== X-Gm-Message-State: ABuFfoiJlK/TC87VH2g2/UG9B3p+aDUlPUtM2rDc05uCtAaMT/3N9vTQ kFiG7oUOvBmJgfL85vrVm6cdJNW5LN4XVeq4dFA= X-Google-Smtp-Source: ACcGV60RCNy3UxQJrLUvrOkvnGl40GZdOGezT9yjhjw9l9/s4L9ksrmYwVIB0BZqco2WMIGivGiDTTNZwrm8DSlWZBc= X-Received: by 2002:a2e:9448:: with SMTP id o8-v6mr10363228ljh.34.1538504709399; Tue, 02 Oct 2018 11:25:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 2 Oct 2018 21:24:56 +0300 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Varga?= Cc: Lou Berger , DetNet WG Content-Type: multipart/alternative; boundary="000000000000b06ab70577430a9f" Archived-At: Subject: Re: [Detnet] Input for 3th Oct, Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 18:25:16 -0000 --000000000000b06ab70577430a9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Balazs, sorry, I'll miss the call tomorrow. Would be great if the summary of the discussion will be available. Or the recording. Regards, Greg On Tue, Oct 2, 2018, 20:21 Bal=C3=A1zs Varga A wrote: > Hi, > > > > Tomorrow we will focus on the IP document. > > I have updated draft-ietf-detnet-dp-sol-ip-01 for the call. > > > > https://github.com/detnet-wg/draft-ietf-detnet-dp-sol-ip > > > > Cheers > > Bala=E2=80=99zs > > > > *From:* detnet *On Behalf Of *Lou Berger > *Sent:* 2018. okt=C3=B3ber 1. 19:51 > *To:* detnet@ietf.org > *Subject:* Re: [Detnet] Webex meeting invitation: Detnet DP working > meeting > > > > Hello, > > Please note -- these webex's are for informal author's working > meetings that are open to all. > > These meetings are *not* formal WG interims. > > Lou > > On 9/29/2018 6:04 AM, DetNet Working Group wrote: > > Hello, > > DetNet Working Group invites you to join this Webex meeting. > > > > > > > > *Detnet DP working meeting* > > Thursday, October 11, 2018 > > 4:30 pm | Sweden Summer Time (Stockholm, GMT+02:00) | 1 hr 30 mins > > > > Meeting number (access code): 643 755 067 > > > > Meeting password: RjRmkCsJ > > > > > > > > Add to Calendar > > > When it's time, join the meeting > > . > > > > > > > > *Join by phone* > > *1-650-479-3208 <+1-650-479-3208,,*01*643755067%23%23*01*>* Call-in toll > number (US/Canada) > > > > > > > > Can't join the meeting? > > > > > > > > > IMPORTANT NOTICE: Please note that this Webex service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automaticall= y > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --000000000000b06ab70577430a9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Balazs,
sorry, I'll miss the call= tomorrow. Would be great if the summary of the discussion will be availabl= e. Or the recording.=C2=A0

Regards,=C2=A0
Greg=C2=A0

On Tue, Oct 2, 2018, 20:21 Bal=C3=A1zs = Varga A <balazs.a.varga@e= ricsson.com> wrote:

Hi,

=C2=A0

Tomorrow we will focus on the IP document.=

I have updated draft-ietf-detnet-dp-sol-ip-01 for th= e call.

=C2=A0

https://github.com/detnet-wg/draft-ietf-detnet-dp-sol-ip=

=C2=A0

Cheers

Bala=E2=80=99zs<= /u>

=C2=A0

From:= detnet <detnet-bounces@ietf.org> On Behalf Of Lou Berger
Sent: 2018. okt=C3=B3ber 1. 19:51
To: detnet@ietf.org
Subject: Re: [Detnet] Webex meeting invitation: Detnet DP working me= eting

=C2=A0

Hello,

=C2=A0=C2=A0=C2=A0 Please note=C2=A0 -- these webex's are for inform= al author's working meetings that are open to all.

These meetings are *not* formal WG interims.

Lou

On 9/29/2018 6:04 AM, DetNet Working Group wrote:

Hello,

DetNet Working Group invites you to join this Webex meeting.

=C2=A0

=C2=A0

=C2=A0

Detnet DP working meeting

Thursday, October 11, 2018

4:30 pm=C2=A0=C2=A0|=C2=A0=C2=A0Sweden Summer Time (Stockholm,= GMT+02:00)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins

=C2=A0

Meeting number (access code): 643 755 067

=C2=A0

Meeting password: RjRmkCsJ

=C2=A0

=C2=A0

=C2=A0

Add to Calendar

When it's time, join the meeting<= /a>.

=C2=A0

=C2=A0

=C2=A0

Join by phone<= /p>

1-650-479-3208=C2=A0Call-in toll number (US/Canada)

=C2=A0

=C2=A0

=C2=A0

Can't join the meeting?

=C2=A0

=C2=A0

=C2=A0

IMPORTANT NOTICE: Please note that this Webex service allows au= dio and other information sent during the session to be recorded, which may= be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not jo= in the session.

 




_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet<=
/a>

=C2=A0

_______________________________________________
detnet mailing list
det= net@ietf.org
https://www.ietf.org/mailman/listinfo/detnet<= /a>
--000000000000b06ab70577430a9f-- From nobody Tue Oct 2 15:15:01 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C51313A3 for ; Tue, 2 Oct 2018 15:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX8X-ZfxhAo8 for ; Tue, 2 Oct 2018 15:14:55 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4e::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA37A131182 for ; Tue, 2 Oct 2018 15:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/vNWX8qv7jXj4T3COX4bJE+MKAS7DUDyDIRJ8u6ESXI=; b=X/l5S9kYBXNLVJJorRIEA9fq0j07Be6+WKLgqMUOgDmfuTrxwZF7Ae2Zd7U8lnD5OnGBgbKlCwJpKn4GWo1a8R8a97BlsIZUCDK5jxf+W7Q4YmtGLP5hiqiu1iy7b3vsQaMf5I9d/onAGIJVWYKMm2nLMM+e/GzvAuETvYfpcMg= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4481.namprd06.prod.outlook.com (20.177.145.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.25; Tue, 2 Oct 2018 22:14:30 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%2]) with mapi id 15.20.1185.024; Tue, 2 Oct 2018 22:14:30 +0000 From: "Grossman, Ethan A." To: Greg Mirsky , =?utf-8?B?QmFsw6F6cyBWYXJnYQ==?= CC: DetNet WG , Lou Berger Thread-Topic: [Detnet] Input for 3th Oct, Detnet DP working meeting Thread-Index: AdRac7P71lXjzG9vQQi1vE3V3aN68AACYQoAAAf8/AA= Date: Tue, 2 Oct 2018 22:14:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4481; 6:0uwoO7qZhPXV/F85EOAHo/p9SxUBT4Ocy3vCilYdWkNbiH0fYXtKvznNe1+k2NY/kpsDB4A6un5HYjaXviFxQGP3YHr/KKEJSAFSoBu1txkCqQr4QePUtYT8Kf8lfRR1kM9/iTYftvFxUQbhEINk52sqw4BFQ4SSwKDrxwI1qGoL2tHVEL2qAv3PWfzRyG3INpY0o4eAWgEy/31B5nDc2UgW0Vwnhm6ETciBGxo9SKkQaYXDUuA8FVQCVACFZ4QX3wECjTwCMeRuq8LrMDwHd0+iXiPX6fT11ip/fKfL4oHeUiBdKwwK2G6zrKay9e+x8NbfBZUfzxD8V9f1BLafob1OXOfyNig2zC27f7ZyYYqqG3kBlK6kWC/CBIW1bS6atPE+GJVfTKEJZwm30F7+4Pbp8FVJrBoPS8Ch86Z3KZOnKQV04dgzf2CpmHKEAhiaXdKdLq7GnFpq3rdZW02dvQ==; 5:FRVxZ58oXyeDVIH9Z5XHpOYSP7oC/F7Bf/FRsh2uoP5ctYRiGDyLgo3NA01MbeG7je8Ms0vCZ/Uogu/Az1rjcIOTpAGH5a3DccpfwLKRbgCJZqOTVqtcDuHAnMQYlideEqcsW3KH1XSq0k/EJEyX1duk2LR//KXX2weM7F9oQAI=; 7:cnF8E6TyVuGH9CcWAruOY/+4Yckgifs4TXZl9i4p7k4F7IJYiY47CzzWzglSJqgkOkyggsX5Ki/5sYU7UBhZd3+udkT2L4v28NvwaWijguHufkXvqlYjFKyg5LwvGI8Kkdw41RXjmEXF/fH6qGngaT+5o/k16D7fvnccCzi0kqA1CP48BulbEuvSW0QiKpDVsGAb9FaJhovQdZk/3T7n9YRIMD96pRY6JHAT1Ru+NzVSYYkAxXIfjQI/Uv4rliDH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 97936962-efbd-4183-76b6-08d628b46d20 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4481; x-ms-traffictypediagnostic: BL0PR06MB4481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944)(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(10436049006162)(163750095850)(94707916325470); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991048); SRVR:BL0PR06MB4481; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4481; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(396003)(376002)(136003)(189003)(199004)(106356001)(486006)(81156014)(186003)(14444005)(66066001)(102836004)(19609705001)(476003)(478600001)(14454004)(26005)(446003)(316002)(97736004)(66574008)(76176011)(256004)(105586002)(6246003)(39060400002)(5250100002)(25786009)(4326008)(966005)(6436002)(606006)(229853002)(8676002)(11346002)(8936002)(33656002)(2906002)(68736007)(54896002)(71190400001)(71200400001)(2900100001)(6116002)(3846002)(790700001)(7736002)(5660300001)(55016002)(551544002)(9686003)(6306002)(7696005)(54906003)(236005)(86362001)(53936002)(74316002)(6506007)(53546011)(110136005)(99286004)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4481; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: yK1HFkQwGUYtRtRoDlgG7bJguzoAZe6HceQaTPStdSipvrnsdXxp5+SD/bQDKkjmWX4ZDq61uio7STwjfVsD6JhbwIsgMjzzhazsxos+QgucZlWqLBcNH1X9HlsnNp6odVsiMng1k/20W7spaAYDdR57Nsig+a6GCExXO4YmhgbrPWPhifhZ+jSePC7c5OWADlwJNM/Ml8x+ruJdjcodHtSP0RNS8BNpXg/cAznzEFmyARDZSfubMVW9pV729rqETuxr/vhQjQglrQCczxxjOnE6Qk78wOivdu2uuqhA/z5jCkbtscyw1qMLoIn/E6J5wnXuOQdwm/wlOpYN1uEUEazV1dmVYWzIS5zblXp6Ys4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR06MB4548D0C6B9AD636DED42FE65C4E80BL0PR06MB4548namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97936962-efbd-4183-76b6-08d628b46d20 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2018 22:14:30.8009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4481 Archived-At: Subject: Re: [Detnet] Input for 3th Oct, Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 22:14:59 -0000 --_000_BL0PR06MB4548D0C6B9AD636DED42FE65C4E80BL0PR06MB4548namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXN1YWxseSBJIHdvdWxkIGJlIHRha2luZyBub3RlcyBhdCB0aGVzZSBtZWV0aW5ncywgaG93ZXZl ciB1bmZvcnR1bmF0ZWx5IEkgY2Fu4oCZdCBhdHRlbmQgdGhpcyBvbmUuDQpFdGhhbi4NCg0KRnJv bTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEdyZWcgTWly c2t5DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDE4IDExOjI1IEFNDQpUbzogQmFsw6F6 cyBWYXJnYSA8YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPg0KQ2M6IERldE5ldCBXRyA8ZGV0 bmV0QGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NClN1YmplY3Q6IFJl OiBbRGV0bmV0XSBJbnB1dCBmb3IgM3RoIE9jdCwgRGV0bmV0IERQIHdvcmtpbmcgbWVldGluZw0K DQpIaSBCYWxhenMsDQpzb3JyeSwgSSdsbCBtaXNzIHRoZSBjYWxsIHRvbW9ycm93LiBXb3VsZCBi ZSBncmVhdCBpZiB0aGUgc3VtbWFyeSBvZiB0aGUgZGlzY3Vzc2lvbiB3aWxsIGJlIGF2YWlsYWJs ZS4gT3IgdGhlIHJlY29yZGluZy4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gVHVlLCBPY3QgMiwg MjAxOCwgMjA6MjEgQmFsw6F6cyBWYXJnYSBBIDxiYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb208 bWFpbHRvOmJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRvbW9y cm93IHdlIHdpbGwgZm9jdXMgb24gdGhlIElQIGRvY3VtZW50Lg0KSSBoYXZlIHVwZGF0ZWQgZHJh ZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLTAxIGZvciB0aGUgY2FsbC4NCg0KaHR0cHM6Ly9naXRo dWIuY29tL2RldG5ldC13Zy9kcmFmdC1pZXRmLWRldG5ldC1kcC1zb2wtaXA8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2RldG5l dC0yRHdnX2RyYWZ0LTJEaWV0Zi0yRGRldG5ldC0yRGRwLTJEc29sLTJEaXAmZD1Ed01GYVEmYz1s SThaYjZUek0zZDF0WDRpRXU3YnBnJnI9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPXlTZTFMd0Np YWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmcz1pRllFb3FUREVRQWJfOHNZR25s UGRwcmFjNWlMVHNKZVdhbTBWYkhLV21nJmU9Pg0KDQpDaGVlcnMNCkJhbGHigJl6cw0KDQpGcm9t OiBkZXRuZXQgPGRldG5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91bmNlc0Bp ZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQpTZW50OiAyMDE4LiBva3TDs2JlciAx LiAxOTo1MQ0KVG86IGRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtEZXRuZXRdIFdlYmV4IG1lZXRpbmcgaW52aXRhdGlvbjogRGV0bmV0IERQIHdv cmtpbmcgbWVldGluZw0KDQoNCkhlbGxvLA0KDQogICAgUGxlYXNlIG5vdGUgIC0tIHRoZXNlIHdl YmV4J3MgYXJlIGZvciBpbmZvcm1hbCBhdXRob3IncyB3b3JraW5nIG1lZXRpbmdzIHRoYXQgYXJl IG9wZW4gdG8gYWxsLg0KDQpUaGVzZSBtZWV0aW5ncyBhcmUgKm5vdCogZm9ybWFsIFdHIGludGVy aW1zLg0KDQpMb3UNCk9uIDkvMjkvMjAxOCA2OjA0IEFNLCBEZXROZXQgV29ya2luZyBHcm91cCB3 cm90ZToNCkhlbGxvLA0KDQpEZXROZXQgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2lu IHRoaXMgV2ViZXggbWVldGluZy4NCg0KDQoNCg0KDQpEZXRuZXQgRFAgd29ya2luZyBtZWV0aW5n DQoNClRodXJzZGF5LCBPY3RvYmVyIDExLCAyMDE4DQoNCjQ6MzAgcG0gIHwgIFN3ZWRlbiBTdW1t ZXIgVGltZSAoU3RvY2tob2xtLCBHTVQrMDI6MDApICB8ICAxIGhyIDMwIG1pbnMNCg0KDQpNZWV0 aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMgNzU1IDA2Nw0KDQoNCk1lZXRpbmcgcGFzc3dv cmQ6IFJqUm1rQ3NKDQoNCg0KDQoNCg0KQWRkIHRvIENhbGVuZGFyPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0Zl9q LnBocC0zRk1USUQtM0RtNWZjM2Q2NGEwZDc0MWI2YmVlMGY0YTRlMmVhYzc3NjkmZD1Ed01GYVEm Yz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJnI9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPXlTZTFM d0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmcz1KQzlrOHVKeDBsLUhqcTR4 SkFYb0R4dnRFSElCd1g1RjgwM3VQVF8ycW5nJmU9Pg0KDQoNCldoZW4gaXQncyB0aW1lLCBqb2lu IHRoZSBtZWV0aW5nPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0Zl9qLnBocC0zRk1USUQtM0RtMjE2YzRlNDNiY2Nl ZTE3ODY5YTI5NWZkZjZmNmIwOGQmZD1Ed01GYVEmYz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJnI9 WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPXlTZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6 aFE5UExTLXd2SmMmcz1nUlhMSVhiWTl4U2VLSkZkOXNnNDY5dEpBZm55QnJpWHVyU0FCSWhWRE5v JmU9Pi4NCg0KDQoNCg0KDQoNCkpvaW4gYnkgcGhvbmUNCg0KMS02NTAtNDc5LTMyMDg8dGVsOisx LTY1MC00NzktMzIwOCwsKjAxKjY0Mzc1NTA2NyUyMyUyMyowMSo+IENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkNCg0KDQoNCg0KDQpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyA8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19jb2xsYWJvcmF0 aW9uaGVscC5jaXNjby5jb21fYXJ0aWNsZV9XQlgwMDAwMjkwNTUmZD1Ed01GYVEmYz1sSThaYjZU ek0zZDF0WDRpRXU3YnBnJnI9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPXlTZTFMd0NpYWJRYTNl VkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmcz1DUWtOUFlMSE5EeDlIS2NfZkNWdFV4R1ZK OHVvRm1nMVQ5ZWdPTkpZajNZJmU9Pg0KDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4NCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmRldG5ldCBt YWlsaW5nIGxpc3QNCg0KZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fZGV0bmV0JmQ9RHdNRmFRJmM9bEk4WmI2VHpNM2QxdFg0aUV1N2JwZyZy PVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmbT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhY emhROVBMUy13dkpjJnM9cGtMQl91R2h6LUgzS0NpbnZuTF9ZM2xGYzFiOXllelMtMWtTSWFZdDZr ZyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19kZXRuZXQmZD1Ed01GYVEmYz1sSThaYjZUek0zZDF0WDRpRXU3 YnBnJnI9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZtPXlTZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdB UzhXOFh6aFE5UExTLXd2SmMmcz1wa0xCX3VHaHotSDNLQ2ludm5MX1kzbEZjMWI5eWV6Uy0xa1NJ YVl0NmtnJmU9Pg0K --_000_BL0PR06MB4548D0C6B9AD636DED42FE65C4E80BL0PR06MB4548namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlVzdWFsbHkgSSB3b3VsZCBiZSB0YWtpbmcgbm90ZXMgYXQgdGhlc2UgbWVldGluZ3MsIGhvd2V2 ZXIgdW5mb3J0dW5hdGVseSBJIGNhbuKAmXQgYXR0ZW5kIHRoaXMgb25lLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdGhhbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IGRldG5ldCAmbHQ7ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9u IEJlaGFsZiBPZg0KPC9iPkdyZWcgTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9j dG9iZXIgMDIsIDIwMTggMTE6MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IEJhbMOhenMgVmFyZ2EgJmx0 O2JhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERldE5ldCBX RyAmbHQ7ZGV0bmV0QGlldGYub3JnJmd0OzsgTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5l dCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRdIElucHV0IGZvciAzdGggT2N0 LCBEZXRuZXQgRFAgd29ya2luZyBtZWV0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBCYWxhenMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ c29ycnksIEknbGwgbWlzcyB0aGUgY2FsbCB0b21vcnJvdy4gV291bGQgYmUgZ3JlYXQgaWYgdGhl IHN1bW1hcnkgb2YgdGhlIGRpc2N1c3Npb24gd2lsbCBiZSBhdmFpbGFibGUuIE9yIHRoZSByZWNv cmRpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDIsIDIwMTgsIDIwOjIxIEJh bMOhenMgVmFyZ2EgQSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5hLnZhcmdhQGVyaWNzc29u LmNvbSI+YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ub21vcnJvdyB3ZSB3aWxs IGZvY3VzIG9uIHRoZSBJUCBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSBoYXZlIHVwZGF0ZWQgZHJhZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLTAxIGZv ciB0aGUgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9k ZXRuZXQtMkR3Z19kcmFmdC0yRGlldGYtMkRkZXRuZXQtMkRkcC0yRHNvbC0yRGlwJmFtcDtkPUR3 TUZhUSZhbXA7Yz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJmFtcDtyPVpjSEM2d1hfZ0R3UERjZk1h Rk5aaVEmYW1wO209eVNlMUx3Q2lhYlFhM2VWTFZjOEtCeXpiN0FTOFc4WHpoUTlQTFMtd3ZKYyZh bXA7cz1pRllFb3FUREVRQWJfOHNZR25sUGRwcmFjNWlMVHNKZVdhbTBWYkhLV21nJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9kZXRuZXQtd2cvZHJhZnQtaWV0Zi1k ZXRuZXQtZHAtc29sLWlwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhbGHigJl6czxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy b206PC9iPiBkZXRuZXQgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9u IEJlaGFsZiBPZiA8L2I+TG91IEJlcmdlcjxicj4NCjxiPlNlbnQ6PC9iPiAyMDE4LiBva3TDs2Jl ciAxLiAxOTo1MTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmRldG5ldEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtEZXRuZXRdIFdlYmV4IG1lZXRpbmcgaW52aXRhdGlvbjogRGV0bmV0IERQIHdvcmtp bmcgbWVldGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5IZWxsbyw8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBQbGVhc2Ugbm90ZSZuYnNwOyAtLSB0aGVzZSB3ZWJleCdz IGFyZSBmb3IgaW5mb3JtYWwgYXV0aG9yJ3Mgd29ya2luZyBtZWV0aW5ncyB0aGF0IGFyZSBvcGVu IHRvIGFsbC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZXNlIG1lZXRpbmdzIGFyZSAqbm90KiBmb3Jt YWwgV0cgaW50ZXJpbXMuPG86cD48L286cD48L3A+DQo8cD5Mb3U8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+T24gOS8yOS8yMDE4IDY6MDQgQU0sIERldE5ldCBXb3JraW5nIEdyb3Vw IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxl PSJ3aWR0aDoxMDAuMCU7bWFyZ2luLWxlZnQ6My4uNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg c3R5bGU9InBhZGRpbmc6My43NXB0IDBpbiAwaW4gMGluIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0i NTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9 IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4g MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+SGVsbG8sDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzo3LjVwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5EZXROZXQgV29ya2luZyBHcm91cCBpbnZpdGVz IHlvdSB0byBqb2luIHRoaXMgV2ViZXggbWVldGluZy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1 cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1o ZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5EZXRuZXQg RFAgd29ya2luZyBtZWV0aW5nPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQi Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPlRodXJzZGF5LCBP Y3RvYmVyIDExLCAyMDE4DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+NDozMCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtTd2VkZW4gU3VtbWVyIFRpbWUgKFN0 b2NraG9sbSwgR01UJiM0MzswMjowMCkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBociAzMCBt aW5zDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjAiIHN0eWxlPSJ3aWR0aDowaW47d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMgNzU1IDA2Nw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0i d2lkdGg6MGluO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBw YXNzd29yZDogUmpSbWtDc0o8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGlu O3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowaW4gMGluIDBpbiAwaW47d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGluO2JhY2tncm91bmQ6IzA0OENCRjtib3JkZXI6c29s aWQgIzA0OENCRiAxLjVwdDt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MTAuNXB0IDE1LjBwdCAxMC41cHQgMTUuMHB0 O3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0Zl9qLnBocC0zRk1USUQt M0RtNWZjM2Q2NGEwZDc0MWI2YmVlMGY0YTRlMmVhYzc3NjkmYW1wO2Q9RHdNRmFRJmFtcDtjPWxJ OFpiNlR6TTNkMXRYNGlFdTdicGcmYW1wO3I9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZhbXA7bT15 U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhYemhROVBMUy13dkpjJmFtcDtzPUpDOWs4dUp4 MGwtSGpxNHhKQVhvRHh2dEVISUJ3WDVGODAzdVBUXzJxbmcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPkFkZA0KIHRvIENhbGVuZGFyPC9zcGFuPjwvYT4gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0YWJsZSBj bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRk aW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBpbjt3aWR0aDphdXRvIWltcG9ydGFudDtt aW4td2lkdGg6MTg2cHghaW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gMGluIDBpbiAxMi4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4 NnB4IWltcG9ydGFudCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5XaGVuIGl0J3MgdGltZSwNCjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f aWV0Zi53ZWJleC5jb21faWV0Zl9qLnBocC0zRk1USUQtM0RtMjE2YzRlNDNiY2NlZTE3ODY5YTI5 NWZkZjZmNmIwOGQmYW1wO2Q9RHdNRmFRJmFtcDtjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmYW1w O3I9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZhbXA7bT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3 QVM4VzhYemhROVBMUy13dkpjJmFtcDtzPWdSWExJWGJZOXhTZUtKRmQ5c2c0Njl0SkFmbnlCcmlY dXJTQUJJaFZETm8mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+ Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43 NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkpvaW4g YnkgcGhvbmU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PjxhIGhyZWY9InRlbDomIzQzOzEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQzNzU1MDY3JTIzJTIzKjAx KiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3Jh dGlvbjpub25lIj4xLTY1MC00NzktMzIwODwvc3Bhbj48L2E+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwO0NhbGwtaW4NCiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i NTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6 MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjE1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb21fYXJ0aWNsZV9X QlgwMDAwMjkwNTUmYW1wO2Q9RHdNRmFRJmFtcDtjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmYW1w O3I9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZhbXA7bT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3 QVM4VzhYemhROVBMUy13dkpjJmFtcDtzPUNRa05QWUxITkR4OUhLY19mQ1Z0VXhHVko4dW9GbWcx VDllZ09OSllqM1kmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkNhbid0DQogam9pbiB0aGUgbWVldGluZz8gPC9z cGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIg d2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjcuNXB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0 OjcuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZw0KIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZXRuZXQgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmRldG5ldEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19kZXRuZXQm YW1wO2Q9RHdNRmFRJmFtcDtjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmYW1wO3I9WmNIQzZ3WF9n RHdQRGNmTWFGTlppUSZhbXA7bT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhYemhROVBM Uy13dkpjJmFtcDtzPXBrTEJfdUdoei1IM0tDaW52bkxfWTNsRmMxYjl5ZXpTLTFrU0lhWXQ2a2cm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGV0bmV0IG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRu ZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19k ZXRuZXQmYW1wO2Q9RHdNRmFRJmFtcDtjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmYW1wO3I9WmNI QzZ3WF9nRHdQRGNmTWFGTlppUSZhbXA7bT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhY emhROVBMUy13dkpjJmFtcDtzPXBrTEJfdUdoei1IM0tDaW52bkxfWTNsRmMxYjl5ZXpTLTFrU0lh WXQ2a2cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kZXRuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR06MB4548D0C6B9AD636DED42FE65C4E80BL0PR06MB4548namp_-- From nobody Tue Oct 2 18:08:15 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1841310A7; Tue, 2 Oct 2018 18:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPzVDcMdDQ58; Tue, 2 Oct 2018 18:08:10 -0700 (PDT) Received: from dggwg11-dlp.huawei.com (lhrrg11-dlp.huawei.com [185.176.76.241]) (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 98888131181; Tue, 2 Oct 2018 18:08:09 -0700 (PDT) Received: from dfwpml705-chm.exmail.huawei.com (unknown [172.18.7.65]) by Forcepoint Email with ESMTP id D7A40173D76C4; Wed, 3 Oct 2018 02:08:00 +0100 (IST) Received: from DFWPML704-CHM.exmail.huawei.com ([169.254.1.87]) by dfwpml705-chm.exmail.huawei.com ([169.254.2.220]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 18:08:01 -0700 From: Norman Finn To: "detnet-chairs@ietf.org" , "detnet@ietf.org" Thread-Topic: [Detnet] Webex meeting invitation: Detnet DP working meeting Thread-Index: AQHUV9vRVusjezjCSUKtYlscaCkLUKUMu0IY Date: Wed, 3 Oct 2018 01:08:00 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F8D52B45@DFWPML704-CHM.exmail.huawei.com> References: <2123314461.8933.1538215441698.JavaMail.nobody@jva2tc204.webex.com> In-Reply-To: <2123314461.8933.1538215441698.JavaMail.nobody@jva2tc204.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.4.35] Content-Type: multipart/alternative; boundary="_000_3DF0466E9510274382F5B74499ACD6F8D52B45DFWPML704CHMexmai_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] Webex meeting invitation: Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 01:08:13 -0000 --_000_3DF0466E9510274382F5B74499ACD6F8D52B45DFWPML704CHMexmai_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Will be on an airplane. Can't make it. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of DetNet Working Group [m= essenger@webex.com] Sent: Saturday, September 29, 2018 3:04 AM To: detnet@ietf.org Subject: [Detnet] Webex meeting invitation: Detnet DP working meeting Hello, DetNet Working Group invites you to join this Webex meeting. Detnet DP working meeting Thursday, October 11, 2018 4:30 pm | Sweden Summer Time (Stockholm, GMT+02:00) | 1 hr 30 mins Meeting number (access code): 643 755 067 Meeting password: RjRmkCsJ Add to Calendar When it's time, join the meeting. Join by phone 1-650-479-3208 Call-in toll n= umber (US/Canada) Can't join the meeting? IMPORTANT NOTICE: Please note that this Webex service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. --_000_3DF0466E9510274382F5B74499ACD6F8D52B45DFWPML704CHMexmai_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Will be on an airplane.  Can't make it.

-- Norm

From: detnet [detnet-bounces@ietf.org] on= behalf of DetNet Working Group [messenger@webex.com]
Sent: Saturday, September 29, 2018 3:04 AM
To: detnet@ietf.org
Subject: [Detnet] Webex meeting invitation: Detnet DP working meetin= g

Hello,
DetNet Working Group invites you to join this Webex meeting.
 
Detnet DP working meeting
Thursday, October 11, 2018
4:30 pm  |  Sweden Summer Time (Stockholm, GMT+= 02:00)  |  1 hr 30 mins
Meeting number (access code): 643 755 067
Meeting password: RjRmkCsJ


 
Add to Calendar
When it's time,  
Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
 
Can't join the meeting?
 
IMPORTANT NOTICE: Please note t= hat this Webex service allows audio and other information sent during the s= ession to be recorded, which may be discoverable in a legal matter. By join= ing this session, you automatically consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.
--_000_3DF0466E9510274382F5B74499ACD6F8D52B45DFWPML704CHMexmai_-- From nobody Tue Oct 2 19:16:40 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE5B131197; Tue, 2 Oct 2018 19:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shwetha Bhandari To: Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-problem-statement.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153853299102.10857.11626484037321735833@ietfa.amsl.com> Date: Tue, 02 Oct 2018 19:16:31 -0700 Archived-At: Subject: [Detnet] Opsdir last call review of draft-ietf-detnet-problem-statement-06 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 02:16:31 -0000 Reviewer: Shwetha Bhandari Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This is a problem statement draft for deterministic networks. This draft documents the requirements to establish multi-hop paths for flows that need deterministic network services with latency guarantees and ultra-low packet loss. While there is no dedicated Manageability Consideration section, Section 3.3 of the draft lists requirements and recommends DetNet to produce a high level interaction and data models that cover the manageability and operational considerations. From nobody Wed Oct 3 00:42:52 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C301310F8; Wed, 3 Oct 2018 00:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmEeI6KKlFS0; Wed, 3 Oct 2018 00:42:40 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F28131090; Wed, 3 Oct 2018 00:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2020; q=dns/txt; s=iport; t=1538552560; x=1539762160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4UIchQYgpBmIDQiL7xt8PQjCQc9TdluYU9gnkzMdOQ4=; b=fIagzAbnJhezU6rQ5XkucLDFRX6nf5sh99hySNm4AzPKtv+XjSQVGePS YXoRzvrH5vzZOelcaczKSik3WJjQmns+h1ZFchd9OfE83tzp0FM0PJ5BS y9amhFKUJcns1NRLokJivtHh80/198Gqd2aaVC1KY4oypwQXYj0lynwrp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAAC8crRb/4MNJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOgWUoCoNqiBWMIIINgz2TH4F6C4RsAheEAiE0GAE?= =?us-ascii?q?DAQECAQECbSiFOAEBAQEDIxFFDAQCAQgRBAEBAwImAgICMBUICAIEAQ0FCIU?= =?us-ascii?q?bpQaBLooPgQuKFBeBQT+BEoMSh3+CVwKdSQkCkDMfj2KVJgIRFIElHTiBPBE?= =?us-ascii?q?IcBWDJ5BUb40+gR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,335,1534809600"; d="scan'208";a="179751461" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 07:42:31 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w937gVRA023621 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 07:42:31 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 02:42:30 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 02:42:30 -0500 From: "Pascal Thubert (pthubert)" To: "Shwetha Bhandari (shwethab)" , "ops-dir@ietf.org" CC: "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-problem-statement.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-detnet-problem-statement-06 Thread-Index: AQHUWr8b7qWpJV1p2ky87L5mzLB9GqUNIuRA Date: Wed, 3 Oct 2018 07:42:13 +0000 Deferred-Delivery: Wed, 3 Oct 2018 07:41:57 +0000 Message-ID: References: <153853299102.10857.11626484037321735833@ietfa.amsl.com> In-Reply-To: <153853299102.10857.11626484037321735833@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Detnet] Opsdir last call review of draft-ietf-detnet-problem-statement-06 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 07:42:43 -0000 TWFueSB0aGFua3MgU2h3ZXRoYSA6ICkNCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXMgbm8g YWN0aW9uIGV4cGVjdGVkIG9uIG91ciBwYXJ0LCBhbmQgcHVibGlzaGVkIDA3Lg0KDQpUYWtlIGNh cmUsDQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNo d2V0aGEgQmhhbmRhcmkgKHNod2V0aGFiKQ0KPiBTZW50OiBtZXJjcmVkaSAzIG9jdG9icmUgMjAx OCAwNDoxNw0KPiBUbzogb3BzLWRpckBpZXRmLm9yZw0KPiBDYzogZGV0bmV0QGlldGYub3JnOyBp ZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLWRldG5ldC1wcm9ibGVtLQ0KPiBzdGF0ZW1lbnQuYWxs QGlldGYub3JnDQo+IFN1YmplY3Q6IE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWll dGYtZGV0bmV0LXByb2JsZW0tc3RhdGVtZW50LTA2DQo+IA0KPiBSZXZpZXdlcjogU2h3ZXRoYSBC aGFuZGFyaQ0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUncyBvbmdv aW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBp bnRlbnQgb2YgaW1wcm92aW5nIHRoZSBvcGVyYXRpb25hbCBhc3BlY3RzIG9mDQo+IHRoZSBJRVRG IGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5 IGJlIGluY2x1ZGVkIGluDQo+IEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCj4gdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBTdW1tYXJ5 Og0KPiBUaGlzIGlzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgZm9yIGRldGVybWluaXN0aWMg bmV0d29ya3MuIFRoaXMgZHJhZnQNCj4gZG9jdW1lbnRzIHRoZSByZXF1aXJlbWVudHMgdG8gZXN0 YWJsaXNoICBtdWx0aS1ob3AgcGF0aHMgZm9yIGZsb3dzIHRoYXQgbmVlZA0KPiBkZXRlcm1pbmlz dGljIG5ldHdvcmsgc2VydmljZXMgd2l0aCAgbGF0ZW5jeSBndWFyYW50ZWVzIGFuZCB1bHRyYS1s b3cgcGFja2V0DQo+IGxvc3MuDQo+IFdoaWxlIHRoZXJlIGlzIG5vIGRlZGljYXRlZCBNYW5hZ2Vh YmlsaXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbiwgU2VjdGlvbiAzLjMgb2YNCj4gdGhlIGRyYWZ0 IGxpc3RzIHJlcXVpcmVtZW50cyBhbmQgcmVjb21tZW5kcyBEZXROZXQgdG8gcHJvZHVjZSBhICBo aWdoIGxldmVsDQo+IGludGVyYWN0aW9uIGFuZCBkYXRhIG1vZGVscyB0aGF0IGNvdmVyIHRoZSBt YW5hZ2VhYmlsaXR5IGFuZCBvcGVyYXRpb25hbA0KPiBjb25zaWRlcmF0aW9ucy4NCg0K From nobody Wed Oct 3 00:45:18 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82D51310F1 for ; Wed, 3 Oct 2018 00:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.965 X-Spam-Level: X-Spam-Status: No, score=-12.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWvIC6IxH3m1 for ; Wed, 3 Oct 2018 00:45:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92B5131090 for ; Wed, 3 Oct 2018 00:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44130; q=dns/txt; s=iport; t=1538552702; x=1539762302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W0hDfsHUDvl58mQqZQTx/t+pTUg/P9WROEtf/FHvmRE=; b=FhsIdNL8XYerErou9zXuQii3OPvsnWwAlZQ0NNhU8KBdFjLG6ihAuDGh hDWSiIQmxnSrrjIIv9t85aa9cqvRAiv3muZdEDZW+vJ6pawmd34Ok/VI3 VA/Vhf2wUWC8PJARaqTfaRrUDdFuXQs//RzPNyjYbzRXFh/Q94+pKoxJS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAC8crRb/4wNJK1AFwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRgRd3Zn8oCoNqiBWMIIINiGKNeoF3AwsYAQmEBEY?= =?us-ascii?q?CF4QCITQYAQMBAQIBAQJtHAyFOAEBAQEDAQEhCjkICxACAQgRBAEBFQQIAQM?= =?us-ascii?q?DAwICAh8GCxQJBwEBAQQBDQUIgxqBHUwDFQ80pEOBLoM/g3INglGLHxeBQT+?= =?us-ascii?q?DD2cuglZFAQECGIE4JgoVCAkIggsngjwbAohahSiFfokdLAkChgw7hh84gxU?= =?us-ascii?q?fgUoiKYQXiTaMFHGIIQIRFIElHTgngS5wFTuCbAkKgWKBboIfhRSFPm8BAQG?= =?us-ascii?q?MMYEKgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,335,1534809600"; d="scan'208,217";a="179752146" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 07:45:01 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w937j12C006720 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 07:45:01 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 02:45:00 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 02:45:00 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , Greg Mirsky , =?utf-8?B?QmFsw6F6cyBWYXJnYQ==?= CC: DetNet WG , Lou Berger Thread-Topic: [Detnet] Input for 3th Oct, Detnet DP working meeting Thread-Index: AdRac7P71lXjzG9vQQi1vE3V3aN68AAM20AAAAgEfAAACWG98A== Date: Wed, 3 Oct 2018 07:44:42 +0000 Deferred-Delivery: Wed, 3 Oct 2018 07:44:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.22] Content-Type: multipart/alternative; boundary="_000_cf3c9a064c2e4b0c9d3ab9c8afda5362XCHRCD001ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Detnet] Input for 3th Oct, Detnet DP working meeting X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 07:45:07 -0000 --_000_cf3c9a064c2e4b0c9d3ab9c8afda5362XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGhhdmUgYSBjb2xsaXNpb24sIHNvcnJ5IGZvciB0aGF0Lg0KDQpQYXNjYWwNCg0KRnJv bTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEdyb3NzbWFu LCBFdGhhbiBBLg0KU2VudDogbWVyY3JlZGkgMyBvY3RvYnJlIDIwMTggMDA6MTUNClRvOiBHcmVn IE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsgQmFsw6F6cyBWYXJnYSA8YmFsYXpzLmEu dmFyZ2FAZXJpY3Nzb24uY29tPg0KQ2M6IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3JnPjsgTG91 IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBJbnB1dCBm b3IgM3RoIE9jdCwgRGV0bmV0IERQIHdvcmtpbmcgbWVldGluZw0KDQpVc3VhbGx5IEkgd291bGQg YmUgdGFraW5nIG5vdGVzIGF0IHRoZXNlIG1lZXRpbmdzLCBob3dldmVyIHVuZm9ydHVuYXRlbHkg SSBjYW7igJl0IGF0dGVuZCB0aGlzIG9uZS4NCkV0aGFuLg0KDQpGcm9tOiBkZXRuZXQgPGRldG5l dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJl aGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxOCAxMToy NSBBTQ0KVG86IEJhbMOhenMgVmFyZ2EgPGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTxtYWls dG86YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPj4NCkNjOiBEZXROZXQgV0cgPGRldG5ldEBp ZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPj47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFi bi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KU3ViamVjdDogUmU6IFtEZXRuZXRdIElu cHV0IGZvciAzdGggT2N0LCBEZXRuZXQgRFAgd29ya2luZyBtZWV0aW5nDQoNCkhpIEJhbGF6cywN CnNvcnJ5LCBJJ2xsIG1pc3MgdGhlIGNhbGwgdG9tb3Jyb3cuIFdvdWxkIGJlIGdyZWF0IGlmIHRo ZSBzdW1tYXJ5IG9mIHRoZSBkaXNjdXNzaW9uIHdpbGwgYmUgYXZhaWxhYmxlLiBPciB0aGUgcmVj b3JkaW5nLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE9jdCAyLCAyMDE4LCAyMDoyMSBC YWzDoXpzIFZhcmdhIEEgPGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpz LmEudmFyZ2FAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KVG9tb3Jyb3cgd2Ugd2lsbCBm b2N1cyBvbiB0aGUgSVAgZG9jdW1lbnQuDQpJIGhhdmUgdXBkYXRlZCBkcmFmdC1pZXRmLWRldG5l dC1kcC1zb2wtaXAtMDEgZm9yIHRoZSBjYWxsLg0KDQpodHRwczovL2dpdGh1Yi5jb20vZGV0bmV0 LXdnL2RyYWZ0LWlldGYtZGV0bmV0LWRwLXNvbC1pcDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fZGV0bmV0LTJEd2dfZHJhZnQt MkRpZXRmLTJEZGV0bmV0LTJEZHAtMkRzb2wtMkRpcCZkPUR3TUZhUSZjPWxJOFpiNlR6TTNkMXRY NGlFdTdicGcmcj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJm09eVNlMUx3Q2lhYlFhM2VWTFZjOEtC eXpiN0FTOFc4WHpoUTlQTFMtd3ZKYyZzPWlGWUVvcVRERVFBYl84c1lHbmxQZHByYWM1aUxUc0pl V2FtMFZiSEtXbWcmZT0+DQoNCkNoZWVycw0KQmFsYeKAmXpzDQoNCkZyb206IGRldG5ldCA8ZGV0 bmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnPj4gT24g QmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IDIwMTguIG9rdMOzYmVyIDEuIDE5OjUxDQpUbzog ZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Rl dG5ldF0gV2ViZXggbWVldGluZyBpbnZpdGF0aW9uOiBEZXRuZXQgRFAgd29ya2luZyBtZWV0aW5n DQoNCg0KSGVsbG8sDQoNCiAgICBQbGVhc2Ugbm90ZSAgLS0gdGhlc2Ugd2ViZXgncyBhcmUgZm9y IGluZm9ybWFsIGF1dGhvcidzIHdvcmtpbmcgbWVldGluZ3MgdGhhdCBhcmUgb3BlbiB0byBhbGwu DQoNClRoZXNlIG1lZXRpbmdzIGFyZSAqbm90KiBmb3JtYWwgV0cgaW50ZXJpbXMuDQoNCkxvdQ0K T24gOS8yOS8yMDE4IDY6MDQgQU0sIERldE5ldCBXb3JraW5nIEdyb3VwIHdyb3RlOg0KSGVsbG8s DQoNCkRldE5ldCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBt ZWV0aW5nLg0KDQoNCg0KDQoNCkRldG5ldCBEUCB3b3JraW5nIG1lZXRpbmcNCg0KVGh1cnNkYXks IE9jdG9iZXIgMTEsIDIwMTgNCg0KNDozMCBwbSAgfCAgU3dlZGVuIFN1bW1lciBUaW1lIChTdG9j a2hvbG0sIEdNVCswMjowMCkgIHwgIDEgaHIgMzAgbWlucw0KDQoNCk1lZXRpbmcgbnVtYmVyIChh Y2Nlc3MgY29kZSk6IDY0MyA3NTUgMDY3DQoNCg0KTWVldGluZyBwYXNzd29yZDogUmpSbWtDc0oN Cg0KDQoNCg0KDQpBZGQgdG8gQ2FsZW5kYXI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19pZXRmLndlYmV4LmNvbV9pZXRmX2oucGhwLTNGTVRJRC0z RG01ZmMzZDY0YTBkNzQxYjZiZWUwZjRhNGUyZWFjNzc2OSZkPUR3TUZhUSZjPWxJOFpiNlR6TTNk MXRYNGlFdTdicGcmcj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJm09eVNlMUx3Q2lhYlFhM2VWTFZj OEtCeXpiN0FTOFc4WHpoUTlQTFMtd3ZKYyZzPUpDOWs4dUp4MGwtSGpxNHhKQVhvRHh2dEVISUJ3 WDVGODAzdVBUXzJxbmcmZT0+DQoNCg0KV2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIG1lZXRpbmc8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19pZXRm LndlYmV4LmNvbV9pZXRmX2oucGhwLTNGTVRJRC0zRG0yMTZjNGU0M2JjY2VlMTc4NjlhMjk1ZmRm NmY2YjA4ZCZkPUR3TUZhUSZjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmcj1aY0hDNndYX2dEd1BE Y2ZNYUZOWmlRJm09eVNlMUx3Q2lhYlFhM2VWTFZjOEtCeXpiN0FTOFc4WHpoUTlQTFMtd3ZKYyZz PWdSWExJWGJZOXhTZUtKRmQ5c2c0Njl0SkFmbnlCcmlYdXJTQUJJaFZETm8mZT0+Lg0KDQoNCg0K DQoNCg0KSm9pbiBieSBwaG9uZQ0KDQoxLTY1MC00NzktMzIwODx0ZWw6KzEtNjUwLTQ3OS0zMjA4 LCwqMDEqNjQzNzU1MDY3JTIzJTIzKjAxKj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KQ0KDQoNCg0KDQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IDxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2NvbGxhYm9yYXRpb25oZWxwLmNpc2Nv LmNvbV9hcnRpY2xlX1dCWDAwMDAyOTA1NSZkPUR3TUZhUSZjPWxJOFpiNlR6TTNkMXRYNGlFdTdi cGcmcj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJm09eVNlMUx3Q2lhYlFhM2VWTFZjOEtCeXpiN0FT OFc4WHpoUTlQTFMtd3ZKYyZzPUNRa05QWUxITkR4OUhLY19mQ1Z0VXhHVko4dW9GbWcxVDllZ09O SllqM1kmZT0+DQoNCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50 IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVy YWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0 IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmRldG5ldCBtYWlsaW5nIGxpc3QNCg0K ZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f ZGV0bmV0JmQ9RHdNRmFRJmM9bEk4WmI2VHpNM2QxdFg0aUV1N2JwZyZyPVpjSEM2d1hfZ0R3UERj Zk1hRk5aaVEmbT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhYemhROVBMUy13dkpjJnM9 cGtMQl91R2h6LUgzS0NpbnZuTF9ZM2xGYzFiOXllelMtMWtTSWFZdDZrZyZlPT4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRldG5ldCBtYWlsaW5n IGxpc3QNCmRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19kZXRuZXQmZD1Ed01GYVEmYz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJnI9WmNIQzZ3WF9n RHdQRGNmTWFGTlppUSZtPXlTZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2 SmMmcz1wa0xCX3VHaHotSDNLQ2ludm5MX1kzbEZjMWI5eWV6Uy0xa1NJYVl0NmtnJmU9Pg0K --_000_cf3c9a064c2e4b0c9d3ab9c8afda5362XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNvbm9ybWFsMCwg bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkkgYWxzbyBoYXZlIGEgY29sbGlzaW9uLCBzb3JyeSBmb3IgdGhhdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBkZXRuZXQgJmx0O2RldG5ldC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhh bGYgT2YNCjwvYj5Hcm9zc21hbiwgRXRoYW4gQS48YnI+DQo8Yj5TZW50OjwvYj4gbWVyY3JlZGkg MyBvY3RvYnJlIDIwMTggMDA6MTU8YnI+DQo8Yj5Ubzo8L2I+IEdyZWcgTWlyc2t5ICZsdDtncmVn aW1pcnNreUBnbWFpbC5jb20mZ3Q7OyBCYWzDoXpzIFZhcmdhICZsdDtiYWxhenMuYS52YXJnYUBl cmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBEZXROZXQgV0cgJmx0O2RldG5ldEBpZXRm Lm9yZyZndDs7IExvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbRGV0bmV0XSBJbnB1dCBmb3IgM3RoIE9jdCwgRGV0bmV0IERQIHdvcmtp bmcgbWVldGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXN1YWxs eSBJIHdvdWxkIGJlIHRha2luZyBub3RlcyBhdCB0aGVzZSBtZWV0aW5ncywgaG93ZXZlciB1bmZv cnR1bmF0ZWx5IEkgY2Fu4oCZdCBhdHRlbmQgdGhpcyBvbmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkV0aGFuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gZGV0bmV0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmci PmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3Jl ZyBNaXJza3k8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAwMiwgMjAxOCAxMToy NSBBTTxicj4NCjxiPlRvOjwvYj4gQmFsw6F6cyBWYXJnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJh bGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbSI+YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IERldE5ldCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRldG5l dEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZndDs7IExvdSBCZXJnZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRdIElucHV0IGZvciAzdGggT2N0LCBEZXRuZXQg RFAgd29ya2luZyBtZWV0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCYWxh enMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c29ycnksIEkn bGwgbWlzcyB0aGUgY2FsbCB0b21vcnJvdy4gV291bGQgYmUgZ3JlYXQgaWYgdGhlIHN1bW1hcnkg b2YgdGhlIGRpc2N1c3Npb24gd2lsbCBiZSBhdmFpbGFibGUuIE9yIHRoZSByZWNvcmRpbmcuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HcmVnJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDIsIDIwMTgsIDIwOjIxIEJhbMOhenMgVmFy Z2EgQSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbSI+YmFs YXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VG9tb3Jyb3cgd2Ugd2lsbCBmb2N1cyBvbiB0aGUgSVAgZG9jdW1lbnQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSB1cGRhdGVkIGRyYWZ0 LWlldGYtZGV0bmV0LWRwLXNvbC1pcC0wMSBmb3IgdGhlIGNhbGwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fZGV0bmV0LTJEd2dfZHJhZnQtMkRpZXRmLTJEZGV0 bmV0LTJEZHAtMkRzb2wtMkRpcCZhbXA7ZD1Ed01GYVEmYW1wO2M9bEk4WmI2VHpNM2QxdFg0aUV1 N2JwZyZhbXA7cj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJmFtcDttPXlTZTFMd0NpYWJRYTNlVkxW YzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmYW1wO3M9aUZZRW9xVERFUUFiXzhzWUdubFBkcHJh YzVpTFRzSmVXYW0wVmJIS1dtZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1 Yi5jb20vZGV0bmV0LXdnL2RyYWZ0LWlldGYtZGV0bmV0LWRwLXNvbC1pcDwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5CYWxh4oCZenM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gZGV0bmV0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXQtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvdSBCZXJnZXI8YnI+ DQo8Yj5TZW50OjwvYj4gMjAxOC4gb2t0w7NiZXIgMS4gMTk6NTE8YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGV0bmV0XSBXZWJleCBtZWV0aW5n IGludml0YXRpb246IERldG5ldCBEUCB3b3JraW5nIG1lZXRpbmc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHA+SGVsbG8sPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNl IG5vdGUmbmJzcDsgLS0gdGhlc2Ugd2ViZXgncyBhcmUgZm9yIGluZm9ybWFsIGF1dGhvcidzIHdv cmtpbmcgbWVldGluZ3MgdGhhdCBhcmUgb3BlbiB0byBhbGwuPG86cD48L286cD48L3A+DQo8cD5U aGVzZSBtZWV0aW5ncyBhcmUgKm5vdCogZm9ybWFsIFdHIGludGVyaW1zLjxvOnA+PC9vOnA+PC9w Pg0KPHA+TG91PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDkvMjkvMjAxOCA2 OjA0IEFNLCBEZXROZXQgV29ya2luZyBHcm91cCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2Vs bHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4w JTttYXJnaW4tbGVmdDozLi43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzozLjc1cHQgMGNtIDBjbSAwY20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0 aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjQiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5IZWxsbywNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjcuNXB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuM3B0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+RGV0TmV0IFdvcmtpbmcg R3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI0IiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdo dDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0i d2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5EZXRuZXQgRFAgd29ya2luZyBtZWV0aW5n PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+VGh1cnNkYXksIE9jdG9iZXIgMTEsIDIwMTgNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6 MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjNwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjQ6MzAgcG0mbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7U3dlZGVuIFN1bW1lciBUaW1lIChTdG9ja2hvbG0sIEdNVCYjNDM7MDI6 MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgMzAgbWlucw0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIw IiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5N ZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMgNzU1IDA2Nw0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIw IiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5N ZWV0aW5nIHBhc3N3b3JkOiBSalJta0NzSjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjNwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjQiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0 Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI0IiBjZWxscGFk ZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTt3aWR0 aDphdXRvIWltcG9ydGFudCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjEiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0 aDowY207YmFja2dyb3VuZDojMDQ4Q0JGO2JvcmRlcjpzb2xpZCAjMDQ4Q0JGIDEuNXB0O3dpZHRo OmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7 cGFkZGluZzoxMC41cHQgMTUuMHB0IDEwLjVwdCAxNS4wcHQ7d2lkdGg6YXV0byFpbXBvcnRhbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVy O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X2lldGYud2ViZXguY29tX2lldGZfai5waHAtM0ZNVElELTNEbTVmYzNkNjRhMGQ3NDFiNmJlZTBm NGE0ZTJlYWM3NzY5JmFtcDtkPUR3TUZhUSZhbXA7Yz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJmFt cDtyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmYW1wO209eVNlMUx3Q2lhYlFhM2VWTFZjOEtCeXpi N0FTOFc4WHpoUTlQTFMtd3ZKYyZhbXA7cz1KQzlrOHVKeDBsLUhqcTR4SkFYb0R4dnRFSElCd1g1 RjgwM3VQVF8ycW5nJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTUuMHB0O2NvbG9yOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5BZGQNCiB0byBDYWxl bmRhcjwvc3Bhbj48L2E+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxl PSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQ7bWluLXdpZHRoOjE4NnB4IWltcG9ydGFu dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMTIuMHB0 O3dpZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDoxODZweCFpbXBvcnRhbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2Ij5XaGVuIGl0J3MgdGltZSwNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faWV0Zi53ZWJleC5jb21faWV0Zl9qLnBo cC0zRk1USUQtM0RtMjE2YzRlNDNiY2NlZTE3ODY5YTI5NWZkZjZmNmIwOGQmYW1wO2Q9RHdNRmFR JmFtcDtjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmYW1wO3I9WmNIQzZ3WF9nRHdQRGNmTWFGTlpp USZhbXA7bT15U2UxTHdDaWFiUWEzZVZMVmM4S0J5emI3QVM4VzhYemhROVBMUy13dkpjJmFtcDtz PWdSWExJWGJZOXhTZUtKRmQ5c2c0Njl0SkFmbnlCcmlYdXJTQUJJaFZETm8mYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246 bm9uZSI+am9pbiB0aGUgbWVldGluZzwvc3Bhbj48L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI0 IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJv ZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEu M3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjNwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkpvaW4g YnkgcGhvbmU8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ PGEgaHJlZj0idGVsOiYjNDM7MS02NTAtNDc5LTMyMDgsLCowMSo2NDM3NTUwNjclMjMlMjMqMDEq IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjEtNjUwLTQ3OS0zMjA4PC9zcGFuPjwvYT48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7Q2FsbC1pbg0KIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0 eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207 aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjNwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToxLjNwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjQiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIg c3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2NvbGxhYm9yYXRpb25o ZWxwLmNpc2NvLmNvbV9hcnRpY2xlX1dCWDAwMDAyOTA1NSZhbXA7ZD1Ed01GYVEmYW1wO2M9bEk4 WmI2VHpNM2QxdFg0aUV1N2JwZyZhbXA7cj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJmFtcDttPXlT ZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmYW1wO3M9Q1FrTlBZTEhO RHg5SEtjX2ZDVnRVeEdWSjh1b0ZtZzFUOWVnT05KWWozWSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Q2FuJ3QN CiBqb2luIHRoZSBtZWV0aW5nPyA8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjNwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHNwYWNpbmc9IjQiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9Indp ZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjcuNXB0Ij4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjcuNXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4z cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4zcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1z b05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI0IiBjZWxscGFkZGluZz0iMCIg d2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjEuM3B0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTBBMEEwIj5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nDQogdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmRldG5ldCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+ZGV0bmV0QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2RldG5ldCZhbXA7ZD1Ed01GYVEmYW1w O2M9bEk4WmI2VHpNM2QxdFg0aUV1N2JwZyZhbXA7cj1aY0hDNndYX2dEd1BEY2ZNYUZOWmlRJmFt cDttPXlTZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmYW1wO3M9cGtM Ql91R2h6LUgzS0NpbnZuTF9ZM2xGYzFiOXllelMtMWtTSWFZdDZrZyZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RldG5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpkZXRuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOmRldG5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRldG5ldEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2RldG5ldCZhbXA7ZD1Ed01G YVEmYW1wO2M9bEk4WmI2VHpNM2QxdFg0aUV1N2JwZyZhbXA7cj1aY0hDNndYX2dEd1BEY2ZNYUZO WmlRJmFtcDttPXlTZTFMd0NpYWJRYTNlVkxWYzhLQnl6YjdBUzhXOFh6aFE5UExTLXd2SmMmYW1w O3M9cGtMQl91R2h6LUgzS0NpbnZuTF9ZM2xGYzFiOXllelMtMWtTSWFZdDZrZyZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5l dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cf3c9a064c2e4b0c9d3ab9c8afda5362XCHRCD001ciscocom_-- From nobody Wed Oct 3 00:46:46 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E491310F1; Wed, 3 Oct 2018 00:46:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <153855280490.9204.3556087673236750483@ietfa.amsl.com> Date: Wed, 03 Oct 2018 00:46:44 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-problem-statement-07.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 07:46:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Problem Statement Authors : Norman Finn Pascal Thubert Filename : draft-ietf-detnet-problem-statement-07.txt Pages : 11 Date : 2018-10-03 Abstract: This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-problem-statement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-problem-statement-07 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-problem-statement-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-problem-statement-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 4 11:02:40 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0CF130E7E; Thu, 4 Oct 2018 11:02:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Pete Resnick To: Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153867614355.4541.14267222448061822810@ietfa.amsl.com> Date: Thu, 04 Oct 2018 11:02:23 -0700 Archived-At: Subject: [Detnet] Genart last call review of draft-ietf-detnet-use-cases-18 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 18:02:24 -0000 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-detnet-use-cases-18 Reviewer: Pete Resnick Review Date: 2018-10-04 IETF LC End Date: 2018-10-03 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits This was a really cool document to read simply because of the breadth of the industries involved. It clearly is going to need a good grammatical editing pass by the RFC Editor, but none of the errors are the kind that make the text hard to understand. All of my comments below are editorial in nature. Major issues: None Minor issues: None Nits/editorial comments: For all of the below, the world does not end if you don't fix them, but please consider: ---- Abstract: The first paragraph of intro seems like a better abstract. I don't think the abstract needs as much detail as you've got in there. ---- The Intro says: For DetNet, use cases explicitly do not define requirements; The DetNet WG will consider the use cases, decide which elements are in scope for DetNet, and the results will be incorporated into future drafts. Then why was 2.1.4 removed? It seems like it might be useful for historical context. ---- In general, I don't like using "we" in consensus documents because it makes it ambiguous whether the "we" is the "the author(s), "the detnet WG"", "the IETF", or "this document". Additionally, using phrases like "we believe" or "we think" are superfluous in most cases. Search for " we" and think about how to get rid of such uses. A few examples: 2.2 I think you can simply just delete "we believe that". This document is making a statement; no reason to hedge. 4.3 "In the future we expect". Changing to the passive voice solves the problem: "It is expected that in the future" 5.3.2.1 "We would like to see DetNet define such a protocol". Detnet is the author of this document, so "we" here seems really weird. There are many other examples. Doing a search for " we " and seeing if you can clean them up would be useful. ---- Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be "###µs". I believe I-Ds are now allowed to have such characters. ---- In 3.3.2.3, there is no discussion about how this relates to NTP. I'm not sure if that is necessary, but it seems odd for an IETF document. ---- I like that you have security considerations sprinkled throughout the document instead of trying to combine them into one big section. However, some of the sections are missing security considerations. For example, I think even I could come up with some security considerations for the mining industry case. SECDIR might have more to say, but I think it's worth adding these. ---- The FQDN idnit is because of Juergen Schmitt's email address, and it is fine. From nobody Fri Oct 5 11:50:38 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B7130E77; Fri, 5 Oct 2018 11:50:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdnbgMI8vK2m; Fri, 5 Oct 2018 11:50:29 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0101.outbound.protection.outlook.com [104.47.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C657B127133; Fri, 5 Oct 2018 11:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=flVFflerXVutB8kJLSpvwc8OgEpQmMovCyv8r/ZYZ00=; b=mDhYPh/Uerg9W2gwy/BUe1uu4zyr3st/xBwviWYx66o3m3g8UCdWY2Wn6l+hcGIOKnIyIkjqr3MM5ITBEyQM+XtvXFD0B081ZlLJL8iJxZQQUrkxvo8yh5FhrwHYIxctD5TTWHFVLn9aL0rLFCZiXykUW+GMlHHd3SA2P4Px/Ns= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4787.namprd06.prod.outlook.com (10.167.241.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.21; Fri, 5 Oct 2018 18:50:23 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%2]) with mapi id 15.20.1185.024; Fri, 5 Oct 2018 18:50:23 +0000 From: "Grossman, Ethan A." To: Pete Resnick , "gen-art@ietf.org" CC: "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-use-cases.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-detnet-use-cases-18 Thread-Index: AQHUXAxqWRsyVyrSIk6uQDZR+p0AfqUQ8TiA Date: Fri, 5 Oct 2018 18:50:23 +0000 Message-ID: References: <153867614355.4541.14267222448061822810@ietfa.amsl.com> In-Reply-To: <153867614355.4541.14267222448061822810@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4787; 6:MBKureEZDqxYFLhr/VEdESsIEUcdZEsfz/LPMW43F/1Ap7oti4Yb23D0yKI1hNlbCWBkPNTl8Gtaqx+oDMvGeT5MTUigDtEfGnTbVjQxSrIHMv1FSNlb9vC57i0upa7jq5bn4ol56Rxy+r5HpAsE5m+12Vqn52HyD9oezx8i6is7gOw85MZTz8tjLH9Ck3GtPpqWts7TpzFOH/HDaQvQnprqgif6lgdscSM5cLF58YtFuQLbOg0jzoz5hl09A7ta8XNvqLSzpdsCmJ9B+R0EMaLtkfLyU18k+LY8e/BG69kQ5jzFHyPDMqmpRF9tCgmnisrA+j3ba1A4atk0TXMYe9V4vXqvboqKVaV6wpdyQrk3umw4karJUYRAVjEAF8tGq2XXgLwHTx/5akAEsCadlr8/OddqxM3wWgLN7KjHfJPOt7grB2sJD2aeiZy9r0VVMRmbs40J5I20wBlt4cY9PQ==; 5:40BVu5cse4w0mW5i0FoiOljwB0fw/VgfUVIxW0BS1pNd41zDv7+uTuZH9kC+8jel4KEWb//XqogH4ClcxDkzEkKCqG4nFm++w5jADqGxQ8zL7/U5A/jwvV3BAtkOOGNdr0LERrt+i7bRosoWVADw9ZtCTqxmZ+lwRwcBayyXiTA=; 7:QPWpGkfhr3eNWZo/hXT2vMjr3XfyKDXynkM0AUBm9Glx2ddEDSSYk3ZMnryDPqRQhXUwiUBYr1gS8IQbK2faTu4BIYqNLnrL3XYnWDGssREW4vgTJZWJTcHpLUFYSXonjm41aQtHOd+T0NHFL+bjftfVRNqnFnWWyrR3QWfDSKz37c6b1HoEtebSdhwfzXP0aWL3nTj3+Nk2UPME5OdBnbQHPL03RDk9ySVvv55G63agoXlFtlZ/t5roZ0UMriaO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 265e18d3-7ce9-4c6f-5075-08d62af36848 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4787; x-ms-traffictypediagnostic: BL0PR06MB4787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089)(192374486261705)(120809045254105)(131327999870524)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991048); SRVR:BL0PR06MB4787; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4787; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(136003)(39850400004)(396003)(189003)(199004)(13464003)(2900100001)(316002)(14444005)(110136005)(256004)(106356001)(55016002)(105586002)(5250100002)(5660300001)(9686003)(486006)(86362001)(476003)(11346002)(74316002)(305945005)(6306002)(66066001)(6436002)(2501003)(54906003)(446003)(25786009)(71190400001)(8676002)(68736007)(53936002)(53546011)(76176011)(7696005)(81156014)(99286004)(81166006)(8936002)(229853002)(71200400001)(6246003)(14454004)(33656002)(966005)(2906002)(26005)(7736002)(6116002)(97736004)(4326008)(6506007)(3846002)(186003)(102836004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4787; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oYu2uuVy7V/skxbbRz2oieQ/jDzzW6FhAj0fK/VGUp0P1a3p934M6/hJmU/PRWleCKiowgrE18v2jye7NykNDKwyjNC4OHSGOcOau5o25phcvRxepoZu80iIMuJIE62PUgowvO8KVBKHcudZlGQBMn5YV0iV8d85OwHlcPW9AH6xFdr2pqXLUfM2hB0PMV0Br/1YOx45RUV5NHdhdXPK80SgIFKI5naSEbknePQOqj7faQk+kOjbv50NweJZ+5gy2Xd1cSrFMbkYdHTmBnCU5lgk8RN+lWOlfO/krU0KUHXhCTMTjkEYk1c0aPcPiBFu7g3V2z6cGJEwYdV/tdOBLpuwklhfeZUEUHPn8TnaQOc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 265e18d3-7ce9-4c6f-5075-08d62af36848 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2018 18:50:23.2305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4787 Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-use-cases-18 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 18:50:34 -0000 SGkgUGV0ZSwNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3IGlucHV0LiBBcyBl ZGl0b3Igb2YgdGhpcyBkcmFmdCwgaGVyZSBhcmUgbXkgY29tbWVudHMsIHF1ZXN0aW9ucyBhbmQg c29tZSBwcm9wb3NlZCByZXNvbHV0aW9ucy4gUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgeW91IHRo aW5rLg0KDQoxLiBBYnN0cmFjdDogT0ssIEkgd2lsbCBsb29rIGF0IHN0cmVhbWxpbmluZyBpdCwg b25lIHdheSBvciBhbm90aGVyLg0KDQoyLiBTZWMgMi4xLjQgKGRldGVybWluaXN0aWMgdGltZSB0 byBzdGFydCBzdHJlYW1pbmcpOiBJIGFncmVlIHRoYXQga2VlcGluZyBzb21lIHRoaW5ncyBmb3Ig aGlzdG9yaWNhbCBjb250ZXh0IGlzIHVzZWZ1bCwgYW5kIEkgZGlkIG5vdCByZW1vdmUgdGhlIHNl Y3Rpb24gZW50aXJlbHkgZm9yIGV4YWN0bHkgdGhhdCByZWFzb247IEkgd2FzIGF0dGVtcHRpbmcg dG8ga2VlcCB0aGUgZ2VuZXJhbCB0b3BpYyBidXQganVzdCByZWZlciB0byB0aGUgZWFybGllciBk cmFmdCBmb3IgYWRkaXRpb25hbCBpbmZvLCB3aGljaCB0aGUgcmVhZGVyIGNvdWxkIGxvb2sgdXAg aWYgdGhleSB3ZXJlIGludGVyZXN0ZWQuIFRoZSBkb3duc2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlz IHRoYXQgc3VjaCB0ZXh0IGNhbid0IGJlIGZvcm1hbGx5IHJlZmVyZW5jZWQuIEluIHRoaXMgY2Fz ZSBJIHN0aWxsIHRoaW5rIHRoaXMgaXMgYXBwcm9wcmlhdGUgLSBkbyB5b3Uga25vdyBvZiBvdGhl ciByZWFzb25zIHdoeSB5b3UgZG9uJ3QgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBzdWZmaWNpZW50 IGluIHRoaXMgY2FzZT8gSGF2aW5nIHNhaWQgYWxsIHRoYXQsIEkgd291bGRuJ3QgbWluZCBwdXR0 aW5nIGJhY2sgdGhlIHN1cHBvcnRpbmcgdGV4dCwgaW4gYWRkaXRpb24gdG8gdGhlICJvdXQgb2Yg c2NvcGUiIG1lc3NhZ2UsIGlmIHlvdSBmZWVsIHRoYXQgd291bGQgYmUgd29ydGh3aGlsZS4gDQoN CjMuIFVzZSBvZiAid2UiOiBHb29kIHBvaW50LCBJIGFncmVlIGFuZCB3aWxsIHJldmlldyB0aGF0 IHZvaWNpbmcgdGhyb3VnaG91dCB0aGUgZHJhZnQuIFRoZSByZWFzb24gaXQgY2FtZSBhYm91dCB3 YXMgdGhhdCB0aGUgb3JpZ2luYWwgZnJhbWluZyBvZiB0aGUgZHJhZnQgd2FzICJ3aGF0IGRvZXMg eW91ciBpbmR1c3RyeSB3YW50IGZyb20gRGV0TmV0IiwgYW5kIGVhY2ggdXNlIGNhc2Ugd2FzIHdy aXR0ZW4gYnkgYSB0ZWFtIGZyb20gdGhhdCBpbmR1c3RyeS4gU28gdGhlICJ3ZSIgaXNuJ3QgZXhh Y3RseSAiRGV0TmV0IiBpdCBpcyBtb3JlIGxpa2UgInRoZSBwcm9wb25lbnRzIG9mIHRoaXMgc3Bl Y2lmaWMgdXNlIGNhc2UiLiBCdXQgc3RpbGwgSSBhZ3JlZSB0aGF0ICJ3ZSIgc2hvdWxkIGJlIGV4 cHVuZ2VkLiANCg0KNC4gbWljcm9zZWNvbmRzOiBPSywgSSB3aWxsIHJlcGxhY2UgdXNlIG9mICJ1 c2VjIiBvciAidXMiIHdpdGggIsK1c2VjIi4gDQoNCjUuIFJlbGF0aW9uIHRvIE5UUDogRnJvbSB0 aGUgRGV0TmV0IHBlcnNwZWN0aXZlIHRpbWVrZWVwaW5nIGlzIGNvbnNpZGVyZWQgcGFydCBvZiBu ZXR3b3JrIGltcGxlbWVudGF0aW9uIGFuZCBpcyBub3Qgc3BlY2lmaWVkIGJ5IERldE5ldC4gVGhl IGZhY3QgdGhhdCB0aGUgVXRpbGl0aWVzIHVzZSBjYXNlIG1lbnRpb25zIFBUUCBhdCBhbGwsIGxl YXZlIGFsb25lIG5vdCBtZW50aW9uaW5nIE5UUCwgaXMgaW5jaWRlbnRhbCB0byB0aGF0IHVzZSBj YXNlLiBTbyBJIHdvdWxkIG5vdCBiZSBpbmNsaW5lZCB0byBjaGFuZ2UgYW55dGhpbmcgaGVyZSwg YnV0IGlmIGFueW9uZSBlbHNlIHdhbnRzIHRvIGNoaW1lIGluLCBwbGVhc2UgZG8uIA0KDQo2LiBT ZWN1cml0eTogSW5kaXZpZHVhbCB1c2UgY2FzZXMgbWF5IG1ha2Ugc29tZSByZWZlcmVuY2UgdG8g dGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiB0aGVpciBwYXJ0aWN1bGFyIHVzZSBjYXNlLCBi dXQgdGhpcyBsaXN0IG9mIHVzZSBjYXNlcyBpcyBieSBubyBtZWFucyBleGhhdXN0aXZlOyB0aGVy ZSB3aWxsIGluZXZpdGFibHkgYmUgbmV3IG9uZXMuIEkgbm90ZSB0aGF0IHlvdSBhcHByZWNpYXRl IGluY2x1ZGluZyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBzZXBhcmF0ZSBzZWN0aW9ucyA6 LSApIGJ1dCB0aHVzIGZhciB3ZSBoYXZlIG9wdGVkIHRvIGdhdGhlciB0aGUgRGV0TmV0IHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGludG8gYSBzZXBhcmF0ZSBkcmFmdCB0aGF0IGFwcGxpZXMgdG8g RGV0TmV0IG5ldHdvcmtzIGluIGFnZ3JlZ2F0ZTsgaWYgeW91IGhhdmVuJ3QgYWxyZWFkeSwgcGxl YXNlIHNlZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5l dC1zZWN1cml0eS8uIFJlZ2FyZGluZyBzcGVjaWZpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBm b3IgZWFjaCB1c2UgY2FzZSAoZS5nLiBNaW5pbmcpIG15IHRha2UgKGFzIGVkaXRvciBvZiB0aGUg RGV0TmV0IFNlY3VyaXR5IGRyYWZ0KSBpcyB0aGF0IHNlY3VyaXR5IGRlc2lnbiBpcyBwYXJ0IG9m IHRoZSBvdmVyYWxsIG5ldHdvcmsgZGVzaWduLCBhbmQgdGhhdCB0aGUgRGV0TmV0IFNlY3VyaXR5 IGRyYWZ0IGF0dGVtcHRzIHRvIGFkZHJlc3Mgb25seSB0aGUgYXNwZWN0cyBvZiBuZXR3b3JrIHNl Y3VyaXR5IHRoYXQgYXJlIHNwZWNpZmljIHRvIHRpbWUgc2Vuc2l0aXZlIElQIGJhc2VkIG5ldHdv cmtzLCB3aGljaCBtaWdodCBiZSAibmV3IiB0byBJUCBiYXNlZCBuZXR3b3JrIGRlc2lnbmVycywg YW5kIHRodXMgbWlnaHQgbm90IGJlIGFkZHJlc3NlZCBlbHNld2hlcmUuIEkgZG9uJ3QgZmVlbCB0 aGF0IHJlcXVpcmluZyB0aGUgdXNlIGNhc2UgYXV0aG9ycyB0byBlYWNoIGNvbnRyaWJ1dGUgYSB0 aG9yb3VnaCBzZWN1cml0eSBkaXNjdXNzaW9uIGZvciB0aGVpciBhcHBsaWNhdGlvbiBzZWVtcyBh cHByb3ByaWF0ZSwgYnV0IHRoYXQncyBqdXN0IG15IHRha2UuDQoNCjcuIEdyYW1tYXI6IEVhY2gg dXNlIGNhc2Ugd2FzIGNvbnRyaWJ1dGVkIGJ5IGEgZGlmZmVyZW50IGdyb3VwIG9mIGF1dGhvcnMs IHdpdGggd2lkZWx5IHZhcnlpbmcgd3JpdGluZyBzdHlsZXMuIEFzIGVkaXRvciBJIGF0dGVtcHRl ZCB0byBjbGFyaWZ5IHRoZSBpbnRlbmRlZCBtZWFuaW5nLCB3aGljaCBpdCBzZWVtcyBwZXIgeW91 ciBjb21tZW50IHRoYXQgSSBkaWQgc3VjY2VlZCBpbiBkb2luZywgaG93ZXZlciBJIGRpZG4ndCBh dHRlbXB0IHRvIGZpeCBldmVyeSBncmFtbWF0aWNhbCBpc3N1ZS4gU29tZXRpbWVzIHRoaXMgd2Fz IGR1ZSB0byBteSBjb25jZXJuIGFib3V0IGluYWR2ZXJ0ZW50bHkgY2hhbmdpbmcgdGhlIG1lYW5p bmcgb2YgdGhlIHN0YXRlbWVudHMsIHNvbWV0aW1lcyBJIGp1c3QgZGVjaWRlZCB0byBsZWF2ZSBp biBwbGFjZSB0aGUgb3JpZ2luYWwgYXV0aG9yJ3Mgd29yZGluZyBhbmQgc3R5bGUgaWYgaXQgZGlk bid0IG1hdGVyaWFsbHkgY29tcHJvbWlzZSBjb21wcmVoZW5zaW9uLiBJIGFtIG5vdCBzdXJlIHdo YXQgdGhlIFJGQyBFZGl0b3Igd291bGQgZG8gd2l0aCB0aGlzIG1hdGVyaWFsLCBhbmQgSSdtIG5v dCBzdXJlIHRvIHdoYXQgZXh0ZW50IEkgc2hvdWxkIG1ha2UgYW5vdGhlciBwYXNzIGF0ICJmaXhp bmcgZ3JhbW1hciIgcmF0aGVyIHRoYW4gbGVhdmluZyBpdCB0byB0aGUgUkZDIEVkaXRvciwgaWYg dGhleSBhcmUgZ29pbmcgdG8gdGFrZSB0aGF0IG9uLiBJJ20gb3BlbiB0byBpbnB1dCBvbiB0aGlz LiANCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldyBpbnB1dCwgYW5kIHBs ZWFzZSBsZXQgbWUga25vdyBpZiB0aGUgYWJvdmUgcmVzb2x1dGlvbnMgbWFrZSBzZW5zZSB0byB5 b3UuIA0KQmVzdCwNCkV0aGFuIChhcyBlZGl0b3Igb2YgdGhlIERldE5ldCBVc2UgQ2FzZXMgZHJh ZnQpLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZSBSZXNuaWNrIDxy ZXNuaWNrQGVwaXN0ZW1lLm5ldD4gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNCwgMjAxOCAx MTowMiBBTQ0KVG86IGdlbi1hcnRAaWV0Zi5vcmcNCkNjOiBkZXRuZXRAaWV0Zi5vcmc7IGlldGZA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy5hbGxAaWV0Zi5vcmcNClN1Ympl Y3Q6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNl cy0xOA0KDQpSZXZpZXdlcjogUGV0ZSBSZXNuaWNrDQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRo IE5pdHMNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFp ci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4NCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZB USBhdA0KDQo8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4N Cg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOA0KUmV2aWV3ZXI6IFBl dGUgUmVzbmljaw0KUmV2aWV3IERhdGU6IDIwMTgtMTAtMDQNCklFVEYgTEMgRW5kIERhdGU6IDIw MTgtMTAtMDMNCklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hh dA0KDQpTdW1tYXJ5OiBSZWFkeSB3aXRoIE5pdHMNCg0KVGhpcyB3YXMgYSByZWFsbHkgY29vbCBk b2N1bWVudCB0byByZWFkIHNpbXBseSBiZWNhdXNlIG9mIHRoZSBicmVhZHRoIG9mIHRoZSBpbmR1 c3RyaWVzIGludm9sdmVkLiBJdCBjbGVhcmx5IGlzIGdvaW5nIHRvIG5lZWQgYSBnb29kIGdyYW1t YXRpY2FsIGVkaXRpbmcgcGFzcyBieSB0aGUgUkZDIEVkaXRvciwgYnV0IG5vbmUgb2YgdGhlIGVy cm9ycyBhcmUgdGhlIGtpbmQgdGhhdCBtYWtlIHRoZSB0ZXh0IGhhcmQgdG8gdW5kZXJzdGFuZC4g QWxsIG9mIG15IGNvbW1lbnRzIGJlbG93IGFyZSBlZGl0b3JpYWwgaW4gbmF0dXJlLg0KDQpNYWpv ciBpc3N1ZXM6IE5vbmUNCg0KTWlub3IgaXNzdWVzOiBOb25lDQoNCk5pdHMvZWRpdG9yaWFsIGNv bW1lbnRzOiBGb3IgYWxsIG9mIHRoZSBiZWxvdywgdGhlIHdvcmxkIGRvZXMgbm90IGVuZCBpZiB5 b3UgZG9uJ3QgZml4IHRoZW0sIGJ1dCBwbGVhc2UgY29uc2lkZXI6DQoNCi0tLS0NCg0KQWJzdHJh Y3Q6IFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgaW50cm8gc2VlbXMgbGlrZSBhIGJldHRlciBhYnN0 cmFjdC4gSSBkb24ndCB0aGluayB0aGUgYWJzdHJhY3QgbmVlZHMgYXMgbXVjaCBkZXRhaWwgYXMg eW91J3ZlIGdvdCBpbiB0aGVyZS4NCg0KLS0tLQ0KDQpUaGUgSW50cm8gc2F5czoNCg0KICAgRm9y IERldE5ldCwgdXNlIGNhc2VzIGV4cGxpY2l0bHkgZG8gbm90IGRlZmluZSByZXF1aXJlbWVudHM7 IFRoZQ0KICAgRGV0TmV0IFdHIHdpbGwgY29uc2lkZXIgdGhlIHVzZSBjYXNlcywgZGVjaWRlIHdo aWNoIGVsZW1lbnRzIGFyZSBpbg0KICAgc2NvcGUgZm9yIERldE5ldCwgYW5kIHRoZSByZXN1bHRz IHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGludG8gZnV0dXJlDQogICBkcmFmdHMuDQoNClRoZW4gd2h5 IHdhcyAyLjEuNCByZW1vdmVkPyBJdCBzZWVtcyBsaWtlIGl0IG1pZ2h0IGJlIHVzZWZ1bCBmb3Ig aGlzdG9yaWNhbCBjb250ZXh0Lg0KDQotLS0tDQoNCkluIGdlbmVyYWwsIEkgZG9uJ3QgbGlrZSB1 c2luZyAid2UiIGluIGNvbnNlbnN1cyBkb2N1bWVudHMgYmVjYXVzZSBpdCBtYWtlcyBpdCBhbWJp Z3VvdXMgd2hldGhlciB0aGUgIndlIiBpcyB0aGUgInRoZSBhdXRob3IocyksICJ0aGUgZGV0bmV0 IFdHIiIsICJ0aGUgSUVURiIsIG9yICJ0aGlzIGRvY3VtZW50Ii4gQWRkaXRpb25hbGx5LCB1c2lu ZyBwaHJhc2VzIGxpa2UgIndlIGJlbGlldmUiIG9yICJ3ZSB0aGluayINCmFyZSBzdXBlcmZsdW91 cyBpbiBtb3N0IGNhc2VzLiBTZWFyY2ggZm9yICIgd2UiIGFuZCB0aGluayBhYm91dCBob3cgdG8g Z2V0IHJpZCBvZiBzdWNoIHVzZXMuIEEgZmV3IGV4YW1wbGVzOg0KDQoyLjIgSSB0aGluayB5b3Ug Y2FuIHNpbXBseSBqdXN0IGRlbGV0ZSAid2UgYmVsaWV2ZSB0aGF0Ii4gVGhpcyBkb2N1bWVudCBp cyBtYWtpbmcgYSBzdGF0ZW1lbnQ7IG5vIHJlYXNvbiB0byBoZWRnZS4NCg0KNC4zICJJbiB0aGUg ZnV0dXJlIHdlIGV4cGVjdCIuIENoYW5naW5nIHRvIHRoZSBwYXNzaXZlIHZvaWNlIHNvbHZlcyB0 aGUNCnByb2JsZW06ICJJdCBpcyBleHBlY3RlZCB0aGF0IGluIHRoZSBmdXR1cmUiDQoNCjUuMy4y LjEgIldlIHdvdWxkIGxpa2UgdG8gc2VlIERldE5ldCBkZWZpbmUgc3VjaCBhIHByb3RvY29sIi4g RGV0bmV0IGlzIHRoZSBhdXRob3Igb2YgdGhpcyBkb2N1bWVudCwgc28gIndlIiBoZXJlIHNlZW1z IHJlYWxseSB3ZWlyZC4NCg0KVGhlcmUgYXJlIG1hbnkgb3RoZXIgZXhhbXBsZXMuIERvaW5nIGEg c2VhcmNoIGZvciAiIHdlICIgYW5kIHNlZWluZyBpZiB5b3UgY2FuIGNsZWFuIHRoZW0gdXAgd291 bGQgYmUgdXNlZnVsLg0KDQotLS0tDQoNClRocm91Z2hvdXQgMy4xLjEsIDYuMS4yLCA3LjMsIDcu NDogSSBwcmVzdW1lICIjIyN1cyIgaXMgbWVhbnQgdG8gYmUgIiMjI8K1cyIuIEkgYmVsaWV2ZSBJ LURzIGFyZSBub3cgYWxsb3dlZCB0byBoYXZlIHN1Y2ggY2hhcmFjdGVycy4NCg0KLS0tLQ0KDQpJ biAzLjMuMi4zLCB0aGVyZSBpcyBubyBkaXNjdXNzaW9uIGFib3V0IGhvdyB0aGlzIHJlbGF0ZXMg dG8gTlRQLiBJJ20gbm90IHN1cmUgaWYgdGhhdCBpcyBuZWNlc3NhcnksIGJ1dCBpdCBzZWVtcyBv ZGQgZm9yIGFuIElFVEYgZG9jdW1lbnQuDQoNCi0tLS0NCg0KSSBsaWtlIHRoYXQgeW91IGhhdmUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3ByaW5rbGVkIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50 IGluc3RlYWQgb2YgdHJ5aW5nIHRvIGNvbWJpbmUgdGhlbSBpbnRvIG9uZSBiaWcgc2VjdGlvbi4g SG93ZXZlciwgc29tZSBvZiB0aGUgc2VjdGlvbnMgYXJlIG1pc3Npbmcgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMuIEZvciBleGFtcGxlLCBJIHRoaW5rIGV2ZW4gSSBjb3VsZCBjb21lIHVwIHdpdGgg c29tZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlIG1pbmluZyBpbmR1c3RyeSBjYXNl LiBTRUNESVIgbWlnaHQgaGF2ZSBtb3JlIHRvIHNheSwgYnV0IEkgdGhpbmsgaXQncyB3b3J0aCBh ZGRpbmcgdGhlc2UuDQoNCi0tLS0NCg0KVGhlIEZRRE4gaWRuaXQgaXMgYmVjYXVzZSBvZiBKdWVy Z2VuIFNjaG1pdHQncyBlbWFpbCBhZGRyZXNzLCBhbmQgaXQgaXMgZmluZS4NCg0K From nobody Sun Oct 7 09:54:55 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DD7130DC6; Sun, 7 Oct 2018 09:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0uuod2HDpUY; Sun, 7 Oct 2018 09:54:50 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id 639AA127333; Sun, 7 Oct 2018 09:54:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 1D11969EB05A; Sun, 7 Oct 2018 11:54:47 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsRbCsXVJ_MI; Sun, 7 Oct 2018 11:54:42 -0500 (CDT) Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id C8CDB69EB051; Sun, 7 Oct 2018 11:54:41 -0500 (CDT) From: "Pete Resnick" To: "Grossman, Ethan A." Cc: gen-art@ietf.org, detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org Date: Sun, 07 Oct 2018 11:54:41 -0500 X-Mailer: MailMate (1.12r5523) Message-ID: In-Reply-To: References: <153867614355.4541.14267222448061822810@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-use-cases-18 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 16:54:53 -0000 On 5 Oct 2018, at 13:50, Grossman, Ethan A. wrote: > Hi Pete, > Thank you very much for your review input. As editor of this draft, > here are my comments, questions and some proposed resolutions. Please > let me know what you think. > > 1. Abstract: OK, I will look at streamlining it, one way or another. Cool, thanks. > 2. Sec 2.1.4 (deterministic time to start streaming): I agree that > keeping some things for historical context is useful, and I did not > remove the section entirely for exactly that reason; I was attempting > to keep the general topic but just refer to the earlier draft for > additional info, which the reader could look up if they were > interested. The downside of this approach is that such text can't be > formally referenced. In this case I still think this is appropriate - > do you know of other reasons why you don't think this approach is > sufficient in this case? Having said all that, I wouldn't mind putting > back the supporting text, in addition to the "out of scope" message, > if you feel that would be worthwhile. The RFC Editor is not going to be onboard with a reference to what is officially a non-existent document. That said, I am not insistent that you put it back in; I don't know if it's worth mentioning. But I don't think this sort-of-in-sort-of-out state is a good idea. > 3. Use of "we": Good point, I agree and will review that voicing > throughout the draft. The reason it came about was that the original > framing of the draft was "what does your industry want from DetNet", > and each use case was written by a team from that industry. So the > "we" isn't exactly "DetNet" it is more like "the proponents of this > specific use case". But still I agree that "we" should be expunged. I figured as much. Not a huge deal, but nice if you can do it. > 4. microseconds: OK, I will replace use of "usec" or "us" with > "µsec". Ack. > 5. Relation to NTP: From the DetNet perspective timekeeping is > considered part of network implementation and is not specified by > DetNet. The fact that the Utilities use case mentions PTP at all, > leave alone not mentioning NTP, is incidental to that use case. So I > would not be inclined to change anything here, but if anyone else > wants to chime in, please do. Ack. > 6. Security: Individual use cases may make some reference to the > security implications of their particular use case, but this list of > use cases is by no means exhaustive; there will inevitably be new > ones. I note that you appreciate including security considerations in > separate sections :- ) but thus far we have opted to gather the DetNet > security considerations into a separate draft that applies to DetNet > networks in aggregate; if you haven't already, please see > https://datatracker.ietf.org/doc/draft-ietf-detnet-security/. > Regarding specific security considerations for each use case (e.g. > Mining) my take (as editor of the DetNet Security draft) is that > security design is part of the overall network design, and that the > DetNet Security draft attempts to address only the aspects of network > security that are specific to time sensitive IP based networks, which > might be "new" to IP based network designers, and thus might not be > addressed elsewhere. I don't feel that requiring the use case authors > to each contribute a thorough security discussion for their > application seems appropriate, but that's just my take. Ah, I hadn't realized there was a separate security document. A reference would be good. A simple suggestion then: Make a "Security Considerations" section in this document that simply says something like: "Specific discussions of security considerations for particular use cases are noted throughout this document. A more complete discussion of security considerations can be found in [draft-ietf-detnet-security]." > 7. Grammar: Each use case was contributed by a different group of > authors, with widely varying writing styles. As editor I attempted to > clarify the intended meaning, which it seems per your comment that I > did succeed in doing, however I didn't attempt to fix every > grammatical issue. Sometimes this was due to my concern about > inadvertently changing the meaning of the statements, sometimes I just > decided to leave in place the original author's wording and style if > it didn't materially compromise comprehension. I am not sure what the > RFC Editor would do with this material, and I'm not sure to what > extent I should make another pass at "fixing grammar" rather than > leaving it to the RFC Editor, if they are going to take that on. I'm > open to input on this. Totally understood. Leaving the grammar corrections to the RFC Editor is fine, and they'll be able to make it all consistent across the sections. And they're very good about avoiding breaking meanings when they do their edits. > Thanks again for your valuable review input, and please let me know if > the above resolutions make sense to you. > Best, > Ethan (as editor of the DetNet Use Cases draft). Thanks for the complete response. pr > -----Original Message----- > From: Pete Resnick > Sent: Thursday, October 04, 2018 11:02 AM > To: gen-art@ietf.org > Cc: detnet@ietf.org; ietf@ietf.org; > draft-ietf-detnet-use-cases.all@ietf.org > Subject: Genart last call review of draft-ietf-detnet-use-cases-18 > > Reviewer: Pete Resnick > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-detnet-use-cases-18 > Reviewer: Pete Resnick > Review Date: 2018-10-04 > IETF LC End Date: 2018-10-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready with Nits > > This was a really cool document to read simply because of the breadth > of the industries involved. It clearly is going to need a good > grammatical editing pass by the RFC Editor, but none of the errors are > the kind that make the text hard to understand. All of my comments > below are editorial in nature. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: For all of the below, the world does not end > if you don't fix them, but please consider: > > ---- > > Abstract: The first paragraph of intro seems like a better abstract. I > don't think the abstract needs as much detail as you've got in there. > > ---- > > The Intro says: > > For DetNet, use cases explicitly do not define requirements; The > DetNet WG will consider the use cases, decide which elements are in > scope for DetNet, and the results will be incorporated into future > drafts. > > Then why was 2.1.4 removed? It seems like it might be useful for > historical context. > > ---- > > In general, I don't like using "we" in consensus documents because it > makes it ambiguous whether the "we" is the "the author(s), "the detnet > WG"", "the IETF", or "this document". Additionally, using phrases like > "we believe" or "we think" > are superfluous in most cases. Search for " we" and think about how to > get rid of such uses. A few examples: > > 2.2 I think you can simply just delete "we believe that". This > document is making a statement; no reason to hedge. > > 4.3 "In the future we expect". Changing to the passive voice solves > the > problem: "It is expected that in the future" > > 5.3.2.1 "We would like to see DetNet define such a protocol". Detnet > is the author of this document, so "we" here seems really weird. > > There are many other examples. Doing a search for " we " and seeing if > you can clean them up would be useful. > > ---- > > Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be > "###µs". I believe I-Ds are now allowed to have such characters. > > ---- > > In 3.3.2.3, there is no discussion about how this relates to NTP. I'm > not sure if that is necessary, but it seems odd for an IETF document. > > ---- > > I like that you have security considerations sprinkled throughout the > document instead of trying to combine them into one big section. > However, some of the sections are missing security considerations. For > example, I think even I could come up with some security > considerations for the mining industry case. SECDIR might have more to > say, but I think it's worth adding these. > > ---- > > The FQDN idnit is because of Juergen Schmitt's email address, and it > is fine. From nobody Mon Oct 8 02:24:06 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1A31292F1; Mon, 8 Oct 2018 02:23:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <153899063895.31716.16567779534084601616@ietfa.amsl.com> Date: Mon, 08 Oct 2018 02:23:58 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-19.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 09:23:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Use Cases Author : Ethan Grossman Filename : draft-ietf-detnet-use-cases-19.txt Pages : 87 Date : 2018-10-08 Abstract: This draft presents use cases from diverse industries which have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for DetNet. For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. The Use Case Common Themes section then extracts and enumerates the set of common properties implied by these use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-19 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-cases-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 8 02:24:51 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB7130E6A; Mon, 8 Oct 2018 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHw-TVqu-Jmd; Mon, 8 Oct 2018 02:24:29 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9E5130E5E; Mon, 8 Oct 2018 02:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JWLBdj/ghbvkyGwF8pjpr5CmKMBRuJm7SAxrEhRvyx4=; b=LA+kPexUmJYf1bpmipvS8FmF6lqKRgDusXpt4xEx4dlCkf84Viz3sETmavck5mW/hWfBTH/5IjPQLCULI1bHcg0ZUBTVMKU4Uecgj1YQaCBJviFkA753panRoVb5Y8FaXpqDjUqwNITUm6+3epm0uQcSPl+IHbmaD7mEZAnbSz4= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4211.namprd06.prod.outlook.com (10.167.179.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.20; Mon, 8 Oct 2018 09:24:25 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%2]) with mapi id 15.20.1185.029; Mon, 8 Oct 2018 09:24:25 +0000 From: "Grossman, Ethan A." To: Pete Resnick CC: "gen-art@ietf.org" , "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-use-cases.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-detnet-use-cases-18 Thread-Index: AQHUXAxqWRsyVyrSIk6uQDZR+p0AfqUQ8TiAgAMTkICAANiCkA== Date: Mon, 8 Oct 2018 09:24:24 +0000 Message-ID: References: <153867614355.4541.14267222448061822810@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [136.179.10.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4211; 6:Ay08sCaV1B8BP3Ea60dknjGkEfNIt7Dh1IujdJm/TF9LFyo5ahEwUOHOy3dkotWz3geNfjZdSsOt9Y2q/myCXacnUzyD8v4QntfhHgUJPvIVIUi2Q7DyWxxvxI0LaLd9FfavMIqW212n6muLWLU0PxgFwUHiyAJas6687YBiKokdrOrwz/vm/iM+JNBX7zOUBmn8MYMnd4WSuxMDuINbVvv41101xEf53OSAOKjyu77+zPMGPh1coRtCk68OtDynH0MZqsj9NDTZBueY9wSi87cLAaxb3rtcihx8DxPy+5yq5qE2zweRjOFrLC8XXOmQ0EVe+NYSrssSS4N3Sdiy0PQ0kbX0cELcGDuJ+6K5hJmXUWkhKGvyXJfyTp38qq4ogqfdvr9DAph99uzV7lHFo+I5vTOyTlwzvgsVyR+QA5g4Yp3v07Ipm/9JicoGcM+r+s7LuqQcPXIKQEvj0pQtFg==; 5:PMopOzh0TsAG6NXjkqUQBOVEoBZQqHerq8pCFKtOuwF5XW90iA4MZ6NYXI/L4aBs8GHFf2zVxGJVnUHmy392AZ93f/zBgowHu5v9Kw+DfTmqUPh8rtAIpiiNOZxNIJ0zeCPR0CM7W1fwbutsho5MuaGaEF4SPc+ASuMjmvGib68=; 7:natMX/h4Lp70IU3UdBrsnjIt1CcIYSFyHYADS69zfPC+E8VjeOQU9ROdL8zJm0K/7cxdCQraWsjqoVXoNGHHReKwD0f8pr8JprHDUXkhWk2ftX405woSkDH4V7/ZAVQts+8dWvcMYmPKd310hEdPRjge2JxrLADigvPR75fEmBM2ItvlVP6ja4NAThzMa9bVIQXiuGh3dMl8njoAtAJwGPeVyamyRbv+nhE8D9dEC/is0PgnLiE/3EYWrgnuRYIW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8f9d7abf-63f5-4ed6-3626-08d62cffd6b9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4211; x-ms-traffictypediagnostic: BL0PR06MB4211: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089)(192374486261705)(120809045254105)(131327999870524)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201708071742011)(7699051); SRVR:BL0PR06MB4211; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4211; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39850400004)(366004)(376002)(346002)(51914003)(13464003)(189003)(199004)(33656002)(55016002)(486006)(966005)(6916009)(102836004)(316002)(71190400001)(71200400001)(478600001)(7696005)(76176011)(9686003)(11346002)(25786009)(6506007)(53936002)(99286004)(4326008)(476003)(6306002)(53546011)(446003)(256004)(2900100001)(74316002)(2906002)(106356001)(14444005)(7736002)(81156014)(81166006)(6436002)(6246003)(186003)(97736004)(8936002)(54906003)(229853002)(86362001)(26005)(5660300001)(68736007)(8676002)(5250100002)(66066001)(105586002)(14454004)(305945005)(3846002)(6116002)(4744004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4211; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vx7KHp4dIylHvtwZiu/GXQU3lp6NXE9qMdE7Yo5eCZLw8DIp9FhlfFb+9YJsD30O+E7n/bQWyduvKwjxKlaXPG4sSpRCelINyIHm1nAuUDdUCXWjt0Pl2sjOS1ngIhOno/qPYse+DcKv+Ig5jUyjM98LOdy5c8ck9OE58YNendC8BUwBT9v2Y446WTa5qH5AROb0tSk3p6MT7tb7byOtD9J9mbJLsF/bjLuDJ3O0gLKwgr0VfK9HFBQwapTZa/Pr24XuhErkHVnAPl4zfpjizYn0LHad5Y0QtWR+Wkr8gI4Ry3fls/MI9+gXDt0yIP/0c4bGc3/7twVuIYQAZCjlDeOnECDRelxL8cTVs3lhW88= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f9d7abf-63f5-4ed6-3626-08d62cffd6b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 09:24:24.8686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4211 Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-use-cases-18 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 09:24:41 -0000 SGkgUGV0ZSwNCkV4ZWN1dGl2ZSBzdW1tYXJ5OiBJIGhhdmUgZGV0ZXJtaW5lZCB0aGF0ICLCtSIg aXMgbm90IGFjY2VwdGVkIGluIEktRHMgc28gSSBkaWQgbm90IGltcGxlbWVudCB5b3VyIHJlcXVl c3RlZCBjaGFuZ2UgdG8gdGhhdCBlZmZlY3QuIERldGFpbHMgYmVsb3cuIElmIHlvdSBmaW5kIGV2 aWRlbmNlIHRvIHRoZSBjb250cmFyeSBwbGVhc2UgbGV0IG1lIGtub3cuDQpUaGFua3MsDQpFdGhh bi4NCg0KRGV0YWlsczogDQoNClJlZ2FyZGluZyAiSSBwcmVzdW1lICIjIyN1cyIgaXMgbWVhbnQg dG8gYmUgIiMjI8K1cyIuIEkgYmVsaWV2ZSBJLURzIGFyZSBub3cgYWxsb3dlZCB0byBoYXZlIHN1 Y2ggY2hhcmFjdGVycy4iDQoNClN0YWNrb3ZlcmZsb3cgc2F5cyAiIDctYml0IEFTQ0lJIG9ubHkg aW5jbHVkZXMgMTI4IGNoYXJhY3RlcnMgKDAwLTdGIG9yIDAtMTI3IGluIGRlY2ltYWwpLiA3LWJp dCBBU0NJSSBpcyBhbHNvIHJlZmVycmVkIHRvIGFzIFVTLUFTQ0lJLiBVVEYtOCBlbmNvZGluZyB1 c2VzIHRoZSBzYW1lIGVuY29kaW5nIGFzIDctYml0IEFTQ0lJIGZvciBpdHMgZmlyc3QgMTI4IGNo YXJhY3RlcnMuIg0KDQpUaGUgZmlyc3QgbGluZSBvZiB0aGUgYm9pbGVycGxhdGUgdGhhdCBJIGlu aGVyaXRlZCBmb3IgdGhlIERldE5ldCBVc2UgQ2FzZXMgZHJhZnQgc2F5cw0KDQo8P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVUy1BU0NJSSI/Pg0KDQpQcmVzdW1hYmx5IGZvciB0aGlzIHJl YXNvbiBteSBYTUwgZWRpdG9yIChvWHlnZW4pIHJlamVjdHMgdXNlIG9mIMK1IGFzIG5vdCBBU0NJ SS4gSSB0cmllZCB0byBkbyBzb21lIHNlYXJjaGVzIHRvIGZpZ3VyZSBvdXQgaWYgSS1EcyBhcmUg aW5kZWVkIGFsbG93ZWQgdG8gdXNlIFVURi04LCBidXQgc28gZmFyIEkgZG9uJ3Qgc2VlIGFueXRo aW5nIHRoYXQgaW5kaWNhdGVzIHRoaXMuIA0KDQpGb3IgZXhhbXBsZSwgdGhlIHhtbDJyZmMgcGFn ZSBzYXlzICJ4bWwycmZjIHdpbGwgYWxsb3cgeW91IHRvIHRha2UgeW91ciBYTUwgc291cmNlIHVz aW5nIHRoZSBmb3JtYXQgZGVmaW5lZCBpbiBSRkMgNzc0OS4uLiIgaW4gd2hpY2ggUkZDIDc3NDkg c2F5cyAoZXNzZW50aWFsbHkpICIgdGhlIGN1cnJlbnQgUkZDIGZvcm1hdCBkb2VzIG5vdCBhbGxv dyBub24tQVNDSUkgVW5pY29kZSBjaGFyYWN0ZXJzIiAoZXhjZXB0aW9ucyBmb2xsb3csIGhvd2V2 ZXIgdGhleSBkbyBub3QgaW5jbHVkZSBjaGFyYWN0ZXJzIHN1Y2ggYXMgwrUpLiANCg0KQW5vdGhl ciBleGFtcGxlIGlzIGZyb20gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWV0Zi1mdHAvMWlkLWd1aWRl bGluZXMudHh0OiANCiAgICJJLURzIG11c3QgYmUgaW4gQVNDSUkuICBObyA4LWJpdCBjaGFyYWN0 ZXJzIGFyZSBhbGxvd2VkLiINCg0KQnV0IGp1c3QgZm9yIGxhdWdocyBJIHRyaWVkIHN3aXRjaGlu ZyB0aGUgYWJvdmUgbGluZSB0bw0KPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4NCg0KT25jZSBJIGRpZCB0aGlzIHRoZSBYTUwgZWRpdG9yIG5vIGxvbmdlciBjb21wbGFpbnMs IGFuZCAodG8gbWUgc2VlbWluZ2x5IHN0cmFuZ2VseSkgaHR0cHM6Ly94bWwycmZjLnRvb2xzLmll dGYub3JnLyBkaWQgbm90IGNvbXBsYWluIGVpdGhlciwgbm9yIGRpZCB0aGUgaWRuaXRzIHRvb2wu IA0KDQpIb3dldmVyIHdoZW4gSSBsb29rIGF0IHRoZSBnZW5lcmF0ZWQgLnR4dCBmaWxlIG91dHB1 dCBvZiB4bWwycmZjIEkgc2VlIHRoYXQgdGhlICIxMCDCtXMiIEkgcHV0IGluIHRoZXJlIGhhcyBi ZWVuIHJlbmRlcmVkIGFzICIxMCBbbWljcm9dcyIuIFNvIHRoYXQgZXhwbGFpbnMgaXQ7IGF0IHRo aXMgcG9pbnQgSSBjbGFpbSB0aGF0IMK1IGlzIG5vdCBhbGxvd2VkIHNvIEkgYW0gbGVhdmluZyB0 aGF0IHRleHQgYXMgaXMuIElmIHlvdSBoYXZlIGEgYmV0dGVyIGlkZWEgcGxlYXNlIGxldCBtZSBr bm93Lg0KDQpCZXN0LA0KRXRoYW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBQZXRlIFJlc25pY2sgPHJlc25pY2tAZXBpc3RlbWUubmV0PiANClNlbnQ6IFN1bmRheSwgT2N0 b2JlciAwNywgMjAxOCA5OjU1IEFNDQpUbzogR3Jvc3NtYW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9s YnkuY29tPg0KQ2M6IGdlbi1hcnRAaWV0Zi5vcmc7IGRldG5ldEBpZXRmLm9yZzsgaWV0ZkBpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLmFsbEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNl cy0xOA0KDQpPbiA1IE9jdCAyMDE4LCBhdCAxMzo1MCwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3Rl Og0KDQo+IEhpIFBldGUsDQo+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3IGlu cHV0LiBBcyBlZGl0b3Igb2YgdGhpcyBkcmFmdCwgDQo+IGhlcmUgYXJlIG15IGNvbW1lbnRzLCBx dWVzdGlvbnMgYW5kIHNvbWUgcHJvcG9zZWQgcmVzb2x1dGlvbnMuIFBsZWFzZSANCj4gbGV0IG1l IGtub3cgd2hhdCB5b3UgdGhpbmsuDQo+DQo+IDEuIEFic3RyYWN0OiBPSywgSSB3aWxsIGxvb2sg YXQgc3RyZWFtbGluaW5nIGl0LCBvbmUgd2F5IG9yIGFub3RoZXIuDQoNCkNvb2wsIHRoYW5rcy4N Cg0KPiAyLiBTZWMgMi4xLjQgKGRldGVybWluaXN0aWMgdGltZSB0byBzdGFydCBzdHJlYW1pbmcp OiBJIGFncmVlIHRoYXQgDQo+IGtlZXBpbmcgc29tZSB0aGluZ3MgZm9yIGhpc3RvcmljYWwgY29u dGV4dCBpcyB1c2VmdWwsIGFuZCBJIGRpZCBub3QgDQo+IHJlbW92ZSB0aGUgc2VjdGlvbiBlbnRp cmVseSBmb3IgZXhhY3RseSB0aGF0IHJlYXNvbjsgSSB3YXMgYXR0ZW1wdGluZyANCj4gdG8ga2Vl cCB0aGUgZ2VuZXJhbCB0b3BpYyBidXQganVzdCByZWZlciB0byB0aGUgZWFybGllciBkcmFmdCBm b3IgDQo+IGFkZGl0aW9uYWwgaW5mbywgd2hpY2ggdGhlIHJlYWRlciBjb3VsZCBsb29rIHVwIGlm IHRoZXkgd2VyZSANCj4gaW50ZXJlc3RlZC4gVGhlIGRvd25zaWRlIG9mIHRoaXMgYXBwcm9hY2gg aXMgdGhhdCBzdWNoIHRleHQgY2FuJ3QgYmUgDQo+IGZvcm1hbGx5IHJlZmVyZW5jZWQuIEluIHRo aXMgY2FzZSBJIHN0aWxsIHRoaW5rIHRoaXMgaXMgYXBwcm9wcmlhdGUgLSANCj4gZG8geW91IGtu b3cgb2Ygb3RoZXIgcmVhc29ucyB3aHkgeW91IGRvbid0IHRoaW5rIHRoaXMgYXBwcm9hY2ggaXMg DQo+IHN1ZmZpY2llbnQgaW4gdGhpcyBjYXNlPyBIYXZpbmcgc2FpZCBhbGwgdGhhdCwgSSB3b3Vs ZG4ndCBtaW5kIHB1dHRpbmcgDQo+IGJhY2sgdGhlIHN1cHBvcnRpbmcgdGV4dCwgaW4gYWRkaXRp b24gdG8gdGhlICJvdXQgb2Ygc2NvcGUiIG1lc3NhZ2UsIA0KPiBpZiB5b3UgZmVlbCB0aGF0IHdv dWxkIGJlIHdvcnRod2hpbGUuDQoNClRoZSBSRkMgRWRpdG9yIGlzIG5vdCBnb2luZyB0byBiZSBv bmJvYXJkIHdpdGggYSByZWZlcmVuY2UgdG8gd2hhdCBpcyBvZmZpY2lhbGx5IGEgbm9uLWV4aXN0 ZW50IGRvY3VtZW50LiBUaGF0IHNhaWQsIEkgYW0gbm90IGluc2lzdGVudCB0aGF0IHlvdSBwdXQg aXQgYmFjayBpbjsgSSBkb24ndCBrbm93IGlmIGl0J3Mgd29ydGggbWVudGlvbmluZy4gQnV0IEkg ZG9uJ3QgdGhpbmsgdGhpcyBzb3J0LW9mLWluLXNvcnQtb2Ytb3V0IHN0YXRlIGlzIGEgZ29vZCBp ZGVhLg0KDQo+IDMuIFVzZSBvZiAid2UiOiBHb29kIHBvaW50LCBJIGFncmVlIGFuZCB3aWxsIHJl dmlldyB0aGF0IHZvaWNpbmcgDQo+IHRocm91Z2hvdXQgdGhlIGRyYWZ0LiBUaGUgcmVhc29uIGl0 IGNhbWUgYWJvdXQgd2FzIHRoYXQgdGhlIG9yaWdpbmFsIA0KPiBmcmFtaW5nIG9mIHRoZSBkcmFm dCB3YXMgIndoYXQgZG9lcyB5b3VyIGluZHVzdHJ5IHdhbnQgZnJvbSBEZXROZXQiLCANCj4gYW5k IGVhY2ggdXNlIGNhc2Ugd2FzIHdyaXR0ZW4gYnkgYSB0ZWFtIGZyb20gdGhhdCBpbmR1c3RyeS4g U28gdGhlIA0KPiAid2UiIGlzbid0IGV4YWN0bHkgIkRldE5ldCIgaXQgaXMgbW9yZSBsaWtlICJ0 aGUgcHJvcG9uZW50cyBvZiB0aGlzIA0KPiBzcGVjaWZpYyB1c2UgY2FzZSIuIEJ1dCBzdGlsbCBJ IGFncmVlIHRoYXQgIndlIiBzaG91bGQgYmUgZXhwdW5nZWQuDQoNCkkgZmlndXJlZCBhcyBtdWNo LiBOb3QgYSBodWdlIGRlYWwsIGJ1dCBuaWNlIGlmIHlvdSBjYW4gZG8gaXQuDQoNCj4gNC4gbWlj cm9zZWNvbmRzOiBPSywgSSB3aWxsIHJlcGxhY2UgdXNlIG9mICJ1c2VjIiBvciAidXMiIHdpdGgg IsK1c2VjIi4NCg0KQWNrLg0KDQo+IDUuIFJlbGF0aW9uIHRvIE5UUDogRnJvbSB0aGUgRGV0TmV0 IHBlcnNwZWN0aXZlIHRpbWVrZWVwaW5nIGlzIA0KPiBjb25zaWRlcmVkIHBhcnQgb2YgbmV0d29y ayBpbXBsZW1lbnRhdGlvbiBhbmQgaXMgbm90IHNwZWNpZmllZCBieSANCj4gRGV0TmV0LiBUaGUg ZmFjdCB0aGF0IHRoZSBVdGlsaXRpZXMgdXNlIGNhc2UgbWVudGlvbnMgUFRQIGF0IGFsbCwgDQo+ IGxlYXZlIGFsb25lIG5vdCBtZW50aW9uaW5nIE5UUCwgaXMgaW5jaWRlbnRhbCB0byB0aGF0IHVz ZSBjYXNlLiBTbyBJIA0KPiB3b3VsZCBub3QgYmUgaW5jbGluZWQgdG8gY2hhbmdlIGFueXRoaW5n IGhlcmUsIGJ1dCBpZiBhbnlvbmUgZWxzZSANCj4gd2FudHMgdG8gY2hpbWUgaW4sIHBsZWFzZSBk by4NCg0KQWNrLg0KDQo+IDYuIFNlY3VyaXR5OiBJbmRpdmlkdWFsIHVzZSBjYXNlcyBtYXkgbWFr ZSBzb21lIHJlZmVyZW5jZSB0byB0aGUgDQo+IHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiB0aGVp ciBwYXJ0aWN1bGFyIHVzZSBjYXNlLCBidXQgdGhpcyBsaXN0IG9mIA0KPiB1c2UgY2FzZXMgaXMg Ynkgbm8gbWVhbnMgZXhoYXVzdGl2ZTsgdGhlcmUgd2lsbCBpbmV2aXRhYmx5IGJlIG5ldyANCj4g b25lcy4gSSBub3RlIHRoYXQgeW91IGFwcHJlY2lhdGUgaW5jbHVkaW5nIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGluIA0KPiBzZXBhcmF0ZSBzZWN0aW9ucyA6LSApIGJ1dCB0aHVzIGZhciB3ZSBo YXZlIG9wdGVkIHRvIGdhdGhlciB0aGUgRGV0TmV0IA0KPiBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBpbnRvIGEgc2VwYXJhdGUgZHJhZnQgdGhhdCBhcHBsaWVzIHRvIERldE5ldCANCj4gbmV0d29y a3MgaW4gYWdncmVnYXRlOyBpZiB5b3UgaGF2ZW4ndCBhbHJlYWR5LCBwbGVhc2Ugc2VlIA0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0 eS8uDQo+IFJlZ2FyZGluZyBzcGVjaWZpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgZWFj aCB1c2UgY2FzZSAoZS5nLiANCj4gTWluaW5nKSBteSB0YWtlIChhcyBlZGl0b3Igb2YgdGhlIERl dE5ldCBTZWN1cml0eSBkcmFmdCkgaXMgdGhhdCANCj4gc2VjdXJpdHkgZGVzaWduIGlzIHBhcnQg b2YgdGhlIG92ZXJhbGwgbmV0d29yayBkZXNpZ24sIGFuZCB0aGF0IHRoZSANCj4gRGV0TmV0IFNl Y3VyaXR5IGRyYWZ0IGF0dGVtcHRzIHRvIGFkZHJlc3Mgb25seSB0aGUgYXNwZWN0cyBvZiBuZXR3 b3JrIA0KPiBzZWN1cml0eSB0aGF0IGFyZSBzcGVjaWZpYyB0byB0aW1lIHNlbnNpdGl2ZSBJUCBi YXNlZCBuZXR3b3Jrcywgd2hpY2ggDQo+IG1pZ2h0IGJlICJuZXciIHRvIElQIGJhc2VkIG5ldHdv cmsgZGVzaWduZXJzLCBhbmQgdGh1cyBtaWdodCBub3QgYmUgDQo+IGFkZHJlc3NlZCBlbHNld2hl cmUuIEkgZG9uJ3QgZmVlbCB0aGF0IHJlcXVpcmluZyB0aGUgdXNlIGNhc2UgYXV0aG9ycyANCj4g dG8gZWFjaCBjb250cmlidXRlIGEgdGhvcm91Z2ggc2VjdXJpdHkgZGlzY3Vzc2lvbiBmb3IgdGhl aXIgDQo+IGFwcGxpY2F0aW9uIHNlZW1zIGFwcHJvcHJpYXRlLCBidXQgdGhhdCdzIGp1c3QgbXkg dGFrZS4NCg0KQWgsIEkgaGFkbid0IHJlYWxpemVkIHRoZXJlIHdhcyBhIHNlcGFyYXRlIHNlY3Vy aXR5IGRvY3VtZW50LiBBIHJlZmVyZW5jZSB3b3VsZCBiZSBnb29kLiBBIHNpbXBsZSBzdWdnZXN0 aW9uIHRoZW46IE1ha2UgYSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gaW4gdGhp cyBkb2N1bWVudCB0aGF0IHNpbXBseSBzYXlzIHNvbWV0aGluZw0KbGlrZTogIlNwZWNpZmljIGRp c2N1c3Npb25zIG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBwYXJ0aWN1bGFyIHVzZSBj YXNlcyBhcmUgbm90ZWQgdGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LiBBIG1vcmUgY29tcGxldGUg ZGlzY3Vzc2lvbiBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBjYW4gYmUgZm91bmQgaW4gW2Ry YWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5XS4iDQoNCj4gNy4gR3JhbW1hcjogRWFjaCB1c2UgY2Fz ZSB3YXMgY29udHJpYnV0ZWQgYnkgYSBkaWZmZXJlbnQgZ3JvdXAgb2YgDQo+IGF1dGhvcnMsIHdp dGggd2lkZWx5IHZhcnlpbmcgd3JpdGluZyBzdHlsZXMuIEFzIGVkaXRvciBJIGF0dGVtcHRlZCB0 byANCj4gY2xhcmlmeSB0aGUgaW50ZW5kZWQgbWVhbmluZywgd2hpY2ggaXQgc2VlbXMgcGVyIHlv dXIgY29tbWVudCB0aGF0IEkgDQo+IGRpZCBzdWNjZWVkIGluIGRvaW5nLCBob3dldmVyIEkgZGlk bid0IGF0dGVtcHQgdG8gZml4IGV2ZXJ5IA0KPiBncmFtbWF0aWNhbCBpc3N1ZS4gU29tZXRpbWVz IHRoaXMgd2FzIGR1ZSB0byBteSBjb25jZXJuIGFib3V0IA0KPiBpbmFkdmVydGVudGx5IGNoYW5n aW5nIHRoZSBtZWFuaW5nIG9mIHRoZSBzdGF0ZW1lbnRzLCBzb21ldGltZXMgSSBqdXN0IA0KPiBk ZWNpZGVkIHRvIGxlYXZlIGluIHBsYWNlIHRoZSBvcmlnaW5hbCBhdXRob3IncyB3b3JkaW5nIGFu ZCBzdHlsZSBpZiANCj4gaXQgZGlkbid0IG1hdGVyaWFsbHkgY29tcHJvbWlzZSBjb21wcmVoZW5z aW9uLiBJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIA0KPiBSRkMgRWRpdG9yIHdvdWxkIGRvIHdpdGgg dGhpcyBtYXRlcmlhbCwgYW5kIEknbSBub3Qgc3VyZSB0byB3aGF0IA0KPiBleHRlbnQgSSBzaG91 bGQgbWFrZSBhbm90aGVyIHBhc3MgYXQgImZpeGluZyBncmFtbWFyIiByYXRoZXIgdGhhbiANCj4g bGVhdmluZyBpdCB0byB0aGUgUkZDIEVkaXRvciwgaWYgdGhleSBhcmUgZ29pbmcgdG8gdGFrZSB0 aGF0IG9uLiBJJ20gDQo+IG9wZW4gdG8gaW5wdXQgb24gdGhpcy4NCg0KVG90YWxseSB1bmRlcnN0 b29kLiBMZWF2aW5nIHRoZSBncmFtbWFyIGNvcnJlY3Rpb25zIHRvIHRoZSBSRkMgRWRpdG9yIGlz IGZpbmUsIGFuZCB0aGV5J2xsIGJlIGFibGUgdG8gbWFrZSBpdCBhbGwgY29uc2lzdGVudCBhY3Jv c3MgdGhlIHNlY3Rpb25zLiANCkFuZCB0aGV5J3JlIHZlcnkgZ29vZCBhYm91dCBhdm9pZGluZyBi cmVha2luZyBtZWFuaW5ncyB3aGVuIHRoZXkgZG8gdGhlaXIgZWRpdHMuDQoNCj4gVGhhbmtzIGFn YWluIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldyBpbnB1dCwgYW5kIHBsZWFzZSBsZXQgbWUga25v dyBpZiANCj4gdGhlIGFib3ZlIHJlc29sdXRpb25zIG1ha2Ugc2Vuc2UgdG8geW91Lg0KPiBCZXN0 LA0KPiBFdGhhbiAoYXMgZWRpdG9yIG9mIHRoZSBEZXROZXQgVXNlIENhc2VzIGRyYWZ0KS4NCg0K VGhhbmtzIGZvciB0aGUgY29tcGxldGUgcmVzcG9uc2UuDQoNCnByDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlIFJlc25pY2sgPHJlc25pY2tAZXBpc3RlbWUu bmV0Pg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNCwgMjAxOCAxMTowMiBBTQ0KPiBUbzog Z2VuLWFydEBpZXRmLm9yZw0KPiBDYzogZGV0bmV0QGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0K PiBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMuYWxsQGlldGYub3JnDQo+IFN1YmplY3Q6IEdl bmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOA0K Pg0KPiBSZXZpZXdlcjogUGV0ZSBSZXNuaWNrDQo+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGgg Tml0cw0KPg0KPiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0LiBUaGUgR2VuZXJhbCBBcmVhIA0KPiBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IA0KPiB0aGUgSUVTRyBmb3IgdGhl IElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIA0KPiBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPg0KPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwg cGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+DQo+IDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9n ZW4vd2lraS9HZW5BcnRmYXE+Lg0KPg0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1kZXRuZXQtdXNl LWNhc2VzLTE4DQo+IFJldmlld2VyOiBQZXRlIFJlc25pY2sNCj4gUmV2aWV3IERhdGU6IDIwMTgt MTAtMDQNCj4gSUVURiBMQyBFbmQgRGF0ZTogMjAxOC0xMC0wMw0KPiBJRVNHIFRlbGVjaGF0IGRh dGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQNCj4NCj4gU3VtbWFyeTogUmVhZHkgd2l0 aCBOaXRzDQo+DQo+IFRoaXMgd2FzIGEgcmVhbGx5IGNvb2wgZG9jdW1lbnQgdG8gcmVhZCBzaW1w bHkgYmVjYXVzZSBvZiB0aGUgYnJlYWR0aCANCj4gb2YgdGhlIGluZHVzdHJpZXMgaW52b2x2ZWQu IEl0IGNsZWFybHkgaXMgZ29pbmcgdG8gbmVlZCBhIGdvb2QgDQo+IGdyYW1tYXRpY2FsIGVkaXRp bmcgcGFzcyBieSB0aGUgUkZDIEVkaXRvciwgYnV0IG5vbmUgb2YgdGhlIGVycm9ycyBhcmUgDQo+ IHRoZSBraW5kIHRoYXQgbWFrZSB0aGUgdGV4dCBoYXJkIHRvIHVuZGVyc3RhbmQuIEFsbCBvZiBt eSBjb21tZW50cyANCj4gYmVsb3cgYXJlIGVkaXRvcmlhbCBpbiBuYXR1cmUuDQo+DQo+IE1ham9y IGlzc3VlczogTm9uZQ0KPg0KPiBNaW5vciBpc3N1ZXM6IE5vbmUNCj4NCj4gTml0cy9lZGl0b3Jp YWwgY29tbWVudHM6IEZvciBhbGwgb2YgdGhlIGJlbG93LCB0aGUgd29ybGQgZG9lcyBub3QgZW5k IA0KPiBpZiB5b3UgZG9uJ3QgZml4IHRoZW0sIGJ1dCBwbGVhc2UgY29uc2lkZXI6DQo+DQo+IC0t LS0NCj4NCj4gQWJzdHJhY3Q6IFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgaW50cm8gc2VlbXMgbGlr ZSBhIGJldHRlciBhYnN0cmFjdC4gSSANCj4gZG9uJ3QgdGhpbmsgdGhlIGFic3RyYWN0IG5lZWRz IGFzIG11Y2ggZGV0YWlsIGFzIHlvdSd2ZSBnb3QgaW4gdGhlcmUuDQo+DQo+IC0tLS0NCj4NCj4g VGhlIEludHJvIHNheXM6DQo+DQo+ICAgIEZvciBEZXROZXQsIHVzZSBjYXNlcyBleHBsaWNpdGx5 IGRvIG5vdCBkZWZpbmUgcmVxdWlyZW1lbnRzOyBUaGUNCj4gICAgRGV0TmV0IFdHIHdpbGwgY29u c2lkZXIgdGhlIHVzZSBjYXNlcywgZGVjaWRlIHdoaWNoIGVsZW1lbnRzIGFyZSBpbg0KPiAgICBz Y29wZSBmb3IgRGV0TmV0LCBhbmQgdGhlIHJlc3VsdHMgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW50 byBmdXR1cmUNCj4gICAgZHJhZnRzLg0KPg0KPiBUaGVuIHdoeSB3YXMgMi4xLjQgcmVtb3ZlZD8g SXQgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSB1c2VmdWwgZm9yIA0KPiBoaXN0b3JpY2FsIGNvbnRl eHQuDQo+DQo+IC0tLS0NCj4NCj4gSW4gZ2VuZXJhbCwgSSBkb24ndCBsaWtlIHVzaW5nICJ3ZSIg aW4gY29uc2Vuc3VzIGRvY3VtZW50cyBiZWNhdXNlIGl0IA0KPiBtYWtlcyBpdCBhbWJpZ3VvdXMg d2hldGhlciB0aGUgIndlIiBpcyB0aGUgInRoZSBhdXRob3IocyksICJ0aGUgZGV0bmV0IA0KPiBX RyIiLCAidGhlIElFVEYiLCBvciAidGhpcyBkb2N1bWVudCIuIEFkZGl0aW9uYWxseSwgdXNpbmcg cGhyYXNlcyBsaWtlIA0KPiAid2UgYmVsaWV2ZSIgb3IgIndlIHRoaW5rIg0KPiBhcmUgc3VwZXJm bHVvdXMgaW4gbW9zdCBjYXNlcy4gU2VhcmNoIGZvciAiIHdlIiBhbmQgdGhpbmsgYWJvdXQgaG93 IHRvIA0KPiBnZXQgcmlkIG9mIHN1Y2ggdXNlcy4gQSBmZXcgZXhhbXBsZXM6DQo+DQo+IDIuMiBJ IHRoaW5rIHlvdSBjYW4gc2ltcGx5IGp1c3QgZGVsZXRlICJ3ZSBiZWxpZXZlIHRoYXQiLiBUaGlz IA0KPiBkb2N1bWVudCBpcyBtYWtpbmcgYSBzdGF0ZW1lbnQ7IG5vIHJlYXNvbiB0byBoZWRnZS4N Cj4NCj4gNC4zICJJbiB0aGUgZnV0dXJlIHdlIGV4cGVjdCIuIENoYW5naW5nIHRvIHRoZSBwYXNz aXZlIHZvaWNlIHNvbHZlcyANCj4gdGhlDQo+IHByb2JsZW06ICJJdCBpcyBleHBlY3RlZCB0aGF0 IGluIHRoZSBmdXR1cmUiDQo+DQo+IDUuMy4yLjEgIldlIHdvdWxkIGxpa2UgdG8gc2VlIERldE5l dCBkZWZpbmUgc3VjaCBhIHByb3RvY29sIi4gRGV0bmV0IA0KPiBpcyB0aGUgYXV0aG9yIG9mIHRo aXMgZG9jdW1lbnQsIHNvICJ3ZSIgaGVyZSBzZWVtcyByZWFsbHkgd2VpcmQuDQo+DQo+IFRoZXJl IGFyZSBtYW55IG90aGVyIGV4YW1wbGVzLiBEb2luZyBhIHNlYXJjaCBmb3IgIiB3ZSAiIGFuZCBz ZWVpbmcgaWYgDQo+IHlvdSBjYW4gY2xlYW4gdGhlbSB1cCB3b3VsZCBiZSB1c2VmdWwuDQo+DQo+ IC0tLS0NCj4NCj4gVGhyb3VnaG91dCAzLjEuMSwgNi4xLjIsIDcuMywgNy40OiBJIHByZXN1bWUg IiMjI3VzIiBpcyBtZWFudCB0byBiZSANCj4gIiMjI8K1cyIuIEkgYmVsaWV2ZSBJLURzIGFyZSBu b3cgYWxsb3dlZCB0byBoYXZlIHN1Y2ggY2hhcmFjdGVycy4NCj4NCj4gLS0tLQ0KPg0KPiBJbiAz LjMuMi4zLCB0aGVyZSBpcyBubyBkaXNjdXNzaW9uIGFib3V0IGhvdyB0aGlzIHJlbGF0ZXMgdG8g TlRQLiBJJ20gDQo+IG5vdCBzdXJlIGlmIHRoYXQgaXMgbmVjZXNzYXJ5LCBidXQgaXQgc2VlbXMg b2RkIGZvciBhbiBJRVRGIGRvY3VtZW50Lg0KPg0KPiAtLS0tDQo+DQo+IEkgbGlrZSB0aGF0IHlv dSBoYXZlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB0aHJvdWdob3V0IHRoZSAN Cj4gZG9jdW1lbnQgaW5zdGVhZCBvZiB0cnlpbmcgdG8gY29tYmluZSB0aGVtIGludG8gb25lIGJp ZyBzZWN0aW9uLg0KPiBIb3dldmVyLCBzb21lIG9mIHRoZSBzZWN0aW9ucyBhcmUgbWlzc2luZyBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gRm9yIA0KPiBleGFtcGxlLCBJIHRoaW5rIGV2ZW4gSSBj b3VsZCBjb21lIHVwIHdpdGggc29tZSBzZWN1cml0eSANCj4gY29uc2lkZXJhdGlvbnMgZm9yIHRo ZSBtaW5pbmcgaW5kdXN0cnkgY2FzZS4gU0VDRElSIG1pZ2h0IGhhdmUgbW9yZSB0byANCj4gc2F5 LCBidXQgSSB0aGluayBpdCdzIHdvcnRoIGFkZGluZyB0aGVzZS4NCj4NCj4gLS0tLQ0KPg0KPiBU aGUgRlFETiBpZG5pdCBpcyBiZWNhdXNlIG9mIEp1ZXJnZW4gU2NobWl0dCdzIGVtYWlsIGFkZHJl c3MsIGFuZCBpdCANCj4gaXMgZmluZS4NCg== From nobody Mon Oct 8 02:48:57 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370E1130DC0 for ; Mon, 8 Oct 2018 02:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TOcf_QKCVz6 for ; Mon, 8 Oct 2018 02:48:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0128.outbound.protection.outlook.com [104.47.36.128]) (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 5B7941293FB for ; Mon, 8 Oct 2018 02:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tbfd/NVDYBdpZtfqb0KAe+FHOgr+4jYT83H7m9IGXsc=; b=DWwd57+BdDB45JstU9KaQr73dauqv2/Dtl1ZEGz8OvjGU63fV+90TsbnTV9dm5UvGX0gD90iuqS7n5q2TGG6Ma6BeN2BmvNIiR3PuwpK9vO3TkhtncoIqhoGh4GVtSsd6Jryk7DfsnGhWpkqiY12ikQFQnHSMuhjTKoMCJSWPlM= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4211.namprd06.prod.outlook.com (10.167.179.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.20; Mon, 8 Oct 2018 09:48:50 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%2]) with mapi id 15.20.1185.029; Mon, 8 Oct 2018 09:48:50 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-use-cases-19.txt Thread-Index: AQHUXujOPQ0Bd+2ekUiug5bXg4x//aUVGE1Q Date: Mon, 8 Oct 2018 09:48:50 +0000 Message-ID: References: <153899063895.31716.16567779534084601616@ietfa.amsl.com> In-Reply-To: <153899063895.31716.16567779534084601616@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [136.179.10.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4211; 6:Y5vc4CxFCPfFmAChhoKOY0cjdLJKd2o1v1l5S2l6xObLniyAunsrwC0Np48hoEki6V+T+R0QNvmkKkTcIXnMOxpr8o7yY2crh7gn4AljkaC7ZMYwdWJ310qsxsmE1tk8SSNdvIZB0X4HAnKCuYlYRdv7fTNk0RHVwIoRdflsNRrhTSRoMOmj8JxWq5kCF6Tfe4qgY4DeEUKd9jSb+ZeOAtLpFLOBH/+wG0ApzV3pD0qCV03PZ5UakImORpBlhaeRD15yya+Mh2EU0CqrhemL7HM7E/nBTyhQSQ4NxrbIB5+T52Bz3Plg8jkLKvIsYfvmzYEC81GuGLrOl7dobT7JWp1wr4d2zYCd9TVXUrYzASzURhDdJznJMY34XZBaIWJQhYBYCteR2nLD/dYucaIh0rpawapTEplVEecSs2mFyARDFDUNcyQPsgmLqCg0XdyA9w/m3XpTN0lNhUe4+e/r5w==; 5:GhHhq1lM7Uiy6DZ2FJu9QzaENZfKqRJ5G9DL2OvD3tPNegB2pOiPkMuKP5VLo0A4E44vibTEMEtO1o+maui/YWhO2GRGhyoxQiDeHvMYw56IYxlVrGqICqsqLBOPC2CDnpYKqNBuiocUGdPs2cs/8bVXY1moDNT4qKuYTovUGA8=; 7:U++WcBkPau2/KQRFuQ1Vc5hcCTXRK+rL8OhRBvrTbMfEL3Ijmuinc2y3RrbvDKva20AyQBDwrPaVfKhw2YqCtBSEbH33s1at+FUwdyWblJi30ABAO0ebjWZtPrMxJa5t6y9zTVsG+jcOAuZ/q7Y2nA4Td6grAVYCMecpv8438FWEg0pUS+nG4f2OqVAUFSJdX7kf7gyKzK+S8D1QhQ6bNdt/NfmnW6XbHBogTnRYFybvi8NM1t5FcVxjFOXmS+OF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 560da8e3-7c8d-4fd7-a986-08d62d034079 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4211; x-ms-traffictypediagnostic: BL0PR06MB4211: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201708071742011)(7699051); SRVR:BL0PR06MB4211; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4211; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(136003)(39850400004)(396003)(13464003)(53754006)(189003)(199004)(8936002)(97736004)(229853002)(186003)(26005)(5660300001)(86362001)(106356001)(2906002)(7736002)(14444005)(74316002)(256004)(2900100001)(2501003)(6436002)(6246003)(81156014)(81166006)(1730700003)(305945005)(14454004)(105586002)(3846002)(6116002)(2351001)(8676002)(68736007)(66066001)(5250100002)(6916009)(102836004)(71200400001)(71190400001)(316002)(55016002)(33656002)(5640700003)(486006)(966005)(6506007)(53936002)(11346002)(25786009)(476003)(53546011)(446003)(6306002)(99286004)(7696005)(76176011)(478600001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4211; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LWpiQjoThNy0OrULNCT4IDMrnFg2Jn7RLiYQYvY3u8AM3Wx2hU0Z90DlJmRtwws2sPPYjG+dskLC9sqorpLYfYx2otQJg0ZYlDBH5k78pfnRHntLS7oIS1J5j839rHwail2NYIV02vX0em1f8/0U2fTzt1JX0JYbD8u+2ThCicpHrcoSrpxvcklX4+XZ8yLw9uefRIXV+GeP1gCCFKhnZtu9bqgLLbVZR/S1c4Q1iJrhSZL0Oh/OMN1TuznGfVWbniTzX7f0PdyJpHen3ji+mNvBYZs/yz/gpcP1F8gEOHkvM0SfGtNODcemiFdcDK4hhJAmS6rPsBLyRuSpRpefK+a7uArK1F9RHmv3EDS8GP0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 560da8e3-7c8d-4fd7-a986-08d62d034079 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 09:48:50.8433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4211 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-use-cases-19.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 09:48:55 -0000 Hi All, This DetNet Use Cases draft update addresses: 1) gen-ART review items (refactor Abstract and Introduction sections, move = "Time to Stream" item to "out of scope" section, expunge use of "we" voice)= .=20 2) Add Common Themes for "Bounded Jitter" and "Scalability for Number of Fl= ows" 3) Addition of a Security section referencing the Security draft AFAIK that's all the input I have for this draft as of today. If I forgot a= nything please let me know.=20 Ethan (as DetNet Use Cases draft editor). -----Original Message----- From: detnet On Behalf Of internet-drafts@ietf.or= g Sent: Monday, October 08, 2018 2:24 AM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-19.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Use Cases Author : Ethan Grossman Filename : draft-ietf-detnet-use-cases-19.txt Pages : 87 Date : 2018-10-08 Abstract: This draft presents use cases from diverse industries which have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for DetNet. For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. The Use Case Common Themes section then extracts and enumerates the set of common properties implied by these use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-19 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-use-cases-19 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Oct 8 09:01:08 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3625130E7C for ; Mon, 8 Oct 2018 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WChT0V3Z_xYp for ; Mon, 8 Oct 2018 09:01:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 34F3B130E3F for ; Mon, 8 Oct 2018 09:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539014461; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oX8I2vyVyG+Tb4Em3u14QQyzngrGuyOKNYaJlEHyRN4=; b=aJIN5TC52wmlZeHFxIvJWw/qc3KLSSgbhP0mNzxD3PRXly0qy6KbFOMrdDwexxrI K8njktVEufXIifZBfNydBxOxAHXyIBG2L3vyRKe9b/pDyEYEFFc0T7TafMB2Jq4U HnGly08++WdcjJ/DwTyR+gblvuLOWvPICMdRkByhAzo=; X-AuditID: c1b4fb25-cd2929c0000013ad-18-5bbb7f3def54 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.33.05037.D3F7BBB5; Mon, 8 Oct 2018 18:01:01 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 8 Oct 2018 18:01:01 +0200 Received: from [159.107.143.205] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Mon, 8 Oct 2018 18:01:01 +0200 To: "detnet@ietf.org" CC: "detnet-chairs@ietf.org" References: From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <1ff1fb7a-1a40-0e6c-30c1-408fb04098bc@ericsson.com> Date: Mon, 8 Oct 2018 18:01:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E80178DD9FFE847A5808C755" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2J7ia5t/e5og3nzdCyu9f9gsfj9aTaL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyZrScYyxoUqu4MuEDYwPjKdkuRk4OCQETic072li6 GLk4hASOMkqc3LkbyvnKKLFywX5muMyezXPZQVqEBSwl3k29xwxiiwioS7S9ucYIYjMLmEr8 eLcTLC4kkCDRseg9E4jNJmAvcffSBrA4L5D98OxrMJtFQEVi6/8zrCC2qECsxKcri6FqBCVO znzCAmJzCiRKLNlxnwlifpjE9y+PmSFscYlbT+YzQexSk/j09iH7BEbBWUjaZyFpmYWkZRYj B5BtL/FgaxlEWF6ieetsqBJ9iet37rMiiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJ ERgHB7f8Vt3BePmN4yFGAQ5GJR7eiord0UKsiWXFlbmHGCU4mJVEeEW374oW4k1JrKxKLcqP LyrNSS0+xCjNwaIkzvvQfHOUkEB6YklqdmpqQWoRTJaJg1OqgdF09v9GMd35pe2fb867JH9/ TqHv7FUVVye4f3SvbprYeuQdd/Zupv51L9ZG1O+ZsqQi47ZEuoziyafyGTtFjmj5vQ7i+HNB 5fiazgviC2Y/87ba4PjxTf3KUsmeTwtupZ26+dX+pEHH61nbJ8YVz9d5dTQq12E/v3hZx5zd zxxPRXvuNJ/H+GOJEktxRqKhFnNRcSIATAoju38CAAA= Archived-At: Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:01:06 -0000 --------------E80178DD9FFE847A5808C755 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi, The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended. Overall, there is support for the adoption of the draft; however, some concerns have been raised. Technical details, for instance, open items related to data plane, can be addressed after WG adoption. However, inter-SDO related concerns should be addressed before WG adoption. Authors, Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO concerns raised during the adoption poll. Please remove YANG data model items that overlap with IEEE 802.1 work. Having the inter-SDO concerns resolved, the WG can continue the work on the document as a WG document. Regards, Janos and Lou On 9/18/2018 9:02 PM, Janos Farkas wrote: > > Dear all, > > This is start of a two week poll on making draft-geng-detnet-conf-yang-04 > a working group document. Please send email to the list indicating > "yes/support" or "no/do not support".  If indicating no, please state > your reservations with the document.  If yes, please also feel free to > provide comments you'd like to see addressed once the document is a WG > document. > > The poll ends Oct 3. > > Thanks, > János and Lou > --------------E80178DD9FFE847A5808C755 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi,

The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended.

Overall, there is support for the adoption of the draft; however, some concerns have been raised.
Technical details, for instance, open items related to data plane, can be addressed after WG adoption.
However, inter-SDO related concerns should be addressed before WG adoption.

Authors,
Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO concerns raised during the adoption poll. Please remove YANG data model items that overlap with IEEE 802.1 work.

Having the inter-SDO concerns resolved, the WG can continue the work on the document as a WG document.

Regards,
Janos and Lou


On 9/18/2018 9:02 PM, Janos Farkas wrote:

Dear all,

This is start of a two week poll on making draft-geng-detnet-conf-yang-04
a working group document. Please send email to the list indicating
"yes/support" or "no/do not support".  If indicating no, please state
your reservations with the document.  If yes, please also feel free to
provide comments you'd like to see addressed once the document is a WG
document.

The poll ends Oct 3.

Thanks,
János and Lou


--------------E80178DD9FFE847A5808C755-- From nobody Mon Oct 8 10:57:07 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB81130E36; Mon, 8 Oct 2018 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F0h6-4gXnRa; Mon, 8 Oct 2018 10:56:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51902129C6A; Mon, 8 Oct 2018 10:56:50 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w98HudA3086175 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Oct 2018 12:56:41 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Pete Resnick , gen-art@ietf.org Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org References: <153867614355.4541.14267222448061822810@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Mon, 8 Oct 2018 12:56:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <153867614355.4541.14267222448061822810@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Detnet] Non-ASCII in documents (was Re: Genart last call review of draft-ietf-detnet-use-cases-18) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:56:53 -0000 [speaking with my RSOC hat on] On 10/4/18 1:02 PM, Pete Resnick wrote: > Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be "###µs". I > believe I-Ds are now allowed to have such characters. To be clear, I-Ds are currently prevented from being submitted with non-ASCII characters -- at least, when submitted using the normal mechanisms. This will be changed in the fairly near future to allow such characters, in anticipation of the upcoming transition to the new RFC format. However, there will be no additional RFCs published with non-ASCII characters until the new format tools are put into production. This was announced in September of last year, after an experiment was run to test the RFC Production Center's tool suite as it pertains to handling non-ASCII characters: https://mailarchive.ietf.org/arch/msg/ietf/jic8bRvwu8cJB0EgFtoHVQq14TM For more information, see the RFC Format Change FAQ at https://www.rfc-editor.org/rse/format-faq/ /a From nobody Wed Oct 10 06:14:31 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589C4130EB9 for ; Wed, 10 Oct 2018 06:14:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FizD3Bmj2pt for ; Wed, 10 Oct 2018 06:14:28 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 4FACC130EFC for ; Wed, 10 Oct 2018 06:14:28 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id r8-v6so4844152ljc.10 for ; Wed, 10 Oct 2018 06:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=NTcHmiu6R7ziYoSch+7pVCLu+0r0T2SLi/Is3IJmNck=; b=j8UfU9l0/hI38FAcj1+9X1q/dJPmoFoDlRdMhRTMhKdrpCgOKpXQe8MuxpQQvOt9AH GC8wUBJ7AWrm8MXC1zoQQ9i63FD3ctGRLeKXf4ne/mSqfz46rEnoPlVdLlyJ0WEa91YI heDBGlWDEix+67SjJGhKLDoI+itaVnYpL84auIzGuV1WJG9SP0WYIgyYQFVpxwALP2/p MPd1vbEZnsnfkuGWdLe+V0fVtlviSSW7Bqb+bRZbXIwS1SREOBGnN2zCVlTUHP/012aJ YiPdiID1asxuSpwYY0Lvc6AvpvyGZAldO5vdxPahFJQ/YkNo4kk9+xdnMfZzVulTfmdP 08ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NTcHmiu6R7ziYoSch+7pVCLu+0r0T2SLi/Is3IJmNck=; b=RaKvhPdy9XhoGasaT4HqkzIOltHvv1IW6FOzXOt2UNzz3jRrEv3F4U+/RaXniWJlxy SOdVu60L20+4jMdD/gwHfI93+55w7bG8B/VUhMe+Xqo2FqcLrE6rZOYqfiap0EXSGNX7 /OpLpTSpby9xS2Cxx+kg0jN1BBJXEPmJsCbh4OCTbM29gHAyD4yRueCnvso08wraSf4N r4ROi8lqX39PjRQ30aFEkynU8oRpfNYCBlx+E//co6/BUYUnXc36rHFKjYyH83ql+Sje xfnpR+dEZggv8lpd98XwJdetnktshf4ed5AayqA8kf2WxK6Lt475TKo2kFgXfpEe5y6w UgwA== X-Gm-Message-State: ABuFfogIZiEXl5vF7DuzgPedsHTtawwaQWsnAB7H6lcskcq3Bzte0hxU 5otCuyQddyunUU9y9/U7GCwVls8w6XKDI+CxM62e85C+ X-Google-Smtp-Source: ACcGV636/1TGzVSp142mwO5+OI/MrlwLEIn8lJCbJBFIY9dnM1XR5CkiKNNcbC5ds8YUyEJgkYLQUy0AX4gdakIUtF0= X-Received: by 2002:a2e:8457:: with SMTP id u23-v6mr16309282ljh.154.1539177265733; Wed, 10 Oct 2018 06:14:25 -0700 (PDT) MIME-Version: 1.0 From: Henning Rogge Date: Wed, 10 Oct 2018 15:13:58 +0200 Message-ID: To: detnet@ietf.org Cc: norman.finn@mail01.huawei.com, "Pascal Thubert (pthubert)" , balazs.a.varga@ericsson.com, janos.farkas@ericsson.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Detnet] Last Call Review for ietf-detnet architecture X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:14:30 -0000 Hi, I was asked to do a last-call review for the detnet architecture 08 draft... sorry for the delay. I think the draft provides a good overview what detnet wants to do. When read in order, some chapters seem to skip a few points that get included in later chapters (in a different context), but I think this should be easy to fix. Here are some comments to the draft that came to my mind during reading it: Detnet Relay Node (Page 5) can be bridge (which should be layer2), but Detnet operates on IP layer? Congestion Protection (Page 8) Does Detnet differenciate between limited network capabilities because of media access and datarate? In some networks you might hit a "packet per time" limit before you hit the "byte per time" limit, which is mostly solved by aggregating multiple packets. Explicit Routes (Page 8) Does this mean DetNet normally uses a "frozen" state of a route, e.g. a snapshot of a routing protocol? What happens if the route does not apply anymore (maybe this is out-of-scope for DetNet)? Sufficient buffer (Page 10) "Sufficient buffer" also can give you a higher amount of latency. If for whatever reason a packet arrives "too late", it might be better to drop it to recover the realtime behavior of the following packets (assuming more allocated bandwidth than necessary). This is explained in page 15 (3.3.2. Fault Mitigation) I think. Extra Buffering for different-length paths (Page 13) This sounds like another point where additional latency might appear. Reduction of available bandwidth for non-DetNet packets (Page 15) ... and increased latency. (Mixing DetNet and non-DetNet packets sounds quite difficult if you want to keep all guarantees of DetNet) DetNet data plane protocol stack (Page 18) How does this diagram mesh with the standard stack layers? Are IP/MAC all "lower Layers" ? DetNet adaptation to data plane (Page 19) Figure 4 reads like the combination of UDP and IP (with static routes set) would be okay for DetNet under certain circumstances... no "hop-by-hop" userspace (DetNet)-processing required? Synchronous DetNet (Page 24) I feel that the most important advantage of this would be the collision-free usage of the shared links between the DetNet nodes, which helps to keep the Latency to a lower limit. Henning Rogge From nobody Fri Oct 12 09:20:54 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E4130DF7; Fri, 12 Oct 2018 09:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp31h0wvaBEo; Fri, 12 Oct 2018 09:20:47 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC62130E36; Fri, 12 Oct 2018 09:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nY0YEEMrNq0XQ9zSNyGJHxQUiUp0IDgIfwIbzKBY+Kk=; b=QZLcsJ3+CvAfpqAdSSyspMT4tT5jtAFgz42NUZ4gFYsNv4l7uv92mHmQB1p5L6W2V2OATiKfx5sVJaKhcZc7fFevOfjSaSHJxfwtYOOjUyJwDluHMF6oWhd9SP+DGHu54o8IPP2RrMLvY01SLbdIGu99iFeYnQIGbaGN5WDvy/8= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4914.namprd06.prod.outlook.com (10.167.234.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.25; Fri, 12 Oct 2018 16:20:40 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 16:20:40 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" CC: "detnet-chairs@ietf.org" Thread-Topic: IETF 103 Bangkok - DetNet Meeting Slot Requests Thread-Index: AdRiR4Gv6YTl6S6xQF+b1knHzb/QXg== Date: Fri, 12 Oct 2018 16:20:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4914; 6:B6E96s5xFLdHIAzp0so7GSNBOREUVndJRANe8WnM+gHQ+dl3IrfgjAJv4jvxxElPdpZrdXLNOV4su8WGR5HMoDYe+lPt8rXvfjbKp9efat9KTn2U6IOqSoJFJ6oHpxwt/LxPmaaM0lTyPdIwdvVj7gMM3StGSPXInYPUbb1EQkXxffXZ+Qh3y/fIKxlVhpYyPosbtzzOwHu8QoAyzgHhiPP8V4mYt5gQ87vMxY0clfoAbl78yjIMkSm++h6X/qRN9aWA2ExxzhKhstdrY0LPIzwDyr+wjv1pa1l3uAlu8ksXk/HdlFgq0bx/eh/grTOaDqrhBG6+gXKy8bzA+e3qSy0tyair1BGANDt2fVNgniSowo9Bg9Ii6RE19XY4ZYYCoKKszt8zDCT/CJHIDj2Lu7++q7uqBGttWP8fkqBdycSk0dGBIvc3DpJScMhh6aDHXQal8LsxbXf1MVQ0JzDIWA==; 5:Hnz1zwaBCnuJqWYojcev/LUeJoadmDz+6jdV+lDOWxli8GOwngYER8vWkFsG+ZGLdQdr23baA0u0Tj+KN70iJpjHTTqgsO51Z81m8ueA0lumWTCxDefU5jQ32P8ScK9LSp388BauHaeRuM5uCBrbliMxpvJdAWWP10/ZQGFpc48=; 7:JUap4ULupQhcIPmAl2y2kYsUPrvbzzHex4AUs8861WDGzpWuPE9uYWsLs/8HD8+f0vIms2Rnt5ASEgH37p3lwjHRn7ffhexeo+zwz1JJDGJWO3GG6DRkJNG0EISgyzQXhxMPspiAb1WdVuQ+cQybdJu1tIt+s+/fa+r1yTzTRidYLSJDmg98aK00tCiBepHITXvY408CDTBjVzW/rPSnAd/jwmvcMqKDhqS7ft/nNWG1rOqKjkw1OuVPt1kW5x1g x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 300564be-ed2b-4221-603f-08d6305ea6b5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4914; x-ms-traffictypediagnostic: BL0PR06MB4914: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(10436049006162)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991067); SRVR:BL0PR06MB4914; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4914; x-forefront-prvs: 0823A5777B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(396003)(376002)(346002)(53754006)(54014002)(189003)(199004)(256004)(55016002)(3846002)(106356001)(97736004)(66066001)(790700001)(7736002)(6116002)(14454004)(74316002)(105586002)(2351001)(236005)(54896002)(186003)(486006)(6916009)(476003)(25786009)(86362001)(9686003)(966005)(2906002)(6436002)(81156014)(1730700003)(606006)(33656002)(2900100001)(5640700003)(71200400001)(99286004)(102836004)(81166006)(6306002)(5630700001)(8676002)(26005)(4326008)(9326002)(68736007)(6506007)(450100002)(53936002)(316002)(478600001)(5250100002)(14444005)(5660300001)(2501003)(8936002)(7696005)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4914; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: KpL4xq4+Vj/yLSDJNQbwg9rIoKY9FxqRjt7qLuT0jT8ar3A9dGoCE2HWWUwnGCtW+MoCvN1Z4yHo2KjsHbHCiJBl+y6d1Mb0n8nCRgrXQL2xLSwS6AuqP3Q1n31LuB8AQEZhjeceQgsn2Fwy2+wVEgXExptaxjxvG84bHlj8HNhgeFzH3zOvbBECzo5/fU/jG08R68LVvqhi8en4uXzvVHiC7eGZEnw+P3YSPBHiUpTswlphyHBRQgedaBk+tc+0+TAVpFaSUFhV8lclvWDvuDXJK9eox7c5v4K6oJoBeGIgI+S7gif6NfYnZn6eQdgJquFI8PiCYT2E1TUKAvSrREuy/6hgZ9XC7B0U9+d6AtI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR06MB45483959DBD10BBC353D381FC4E20BL0PR06MB4548namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 300564be-ed2b-4221-603f-08d6305ea6b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 16:20:39.7975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4914 Archived-At: Subject: [Detnet] IETF 103 Bangkok - DetNet Meeting Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:20:52 -0000 --_000_BL0PR06MB45483959DBD10BBC353D381FC4E20BL0PR06MB4548namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The IETF 103 Bangkok agenda has been posted: https://datatracker.ietf.org/meeting/103/agenda.html We're scheduled to meet: Thursday, November 8, 2018 (+07) 13:50-15:50 Thursday Afternoon session I Please send any slot requests to the chairs email alias (see above) no late= r than Monday October 22nd. Please include draft names(s), presenter and d= esired slot length. Please keep in mind that priority for presentation slo= ts is given to WG drafts and other drafts/topics discussed on the mailing l= ist. The cutoff date for draft submissions is also Monday October 22nd, see http= s://datatracker.ietf.org/meeting/important-dates/ Best, Ethan (as DetNet WG Secretary). --_000_BL0PR06MB45483959DBD10BBC353D381FC4E20BL0PR06MB4548namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The IETF 103 Bangkok agenda has been po= sted:

 

    https://datatracker.ietf.org/meeting/103/agenda.htm= l

 

We're scheduled to meet:

Thursday, November 8, 2018 (+07)

13:50-15:50 Thursday Afternoon session = I

 

Please send any slot requests to the ch= airs email alias (see above) no later than Monday October 22nd.  = Please include draft names(s), presenter and desired slot length.  Please keep in mind that priority for presentation slots is = given to WG drafts and other drafts/topics discussed on the mailing li= st.

 

The cutoff date for draft submissions i= s also Monday October 22nd, see https://datatracker.ietf.org/mee= ting/important-dates/

 

Best,

Ethan (as DetNet WG Secretary).<= o:p>

 

--_000_BL0PR06MB45483959DBD10BBC353D381FC4E20BL0PR06MB4548namp_-- From nobody Fri Oct 12 09:34:38 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D462C130E37; Fri, 12 Oct 2018 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naiyOYSiutN7; Fri, 12 Oct 2018 09:34:34 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 DBA2A130DF4; Fri, 12 Oct 2018 09:34:33 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id x3-v6so11872811lji.13; Fri, 12 Oct 2018 09:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EqwhlY7bE1lCGLzvlqq29Dej8d+1AVRsVgMR0fRsE04=; b=QRmidS7v65Rbaz8UvJo77s2TkySppir8s40KVymDQ8q2qeFtGcl4gqnfi8bMiZSu3l XOkTYPicrlBQuRAkEEYFQhvFVPlAzYgtYmvUsSiJPp7l8GWVjmZaWu1csbN8Tm9n29jW oP8TzSWi12ubo3xfvAgnJAtgqM6JhVK/q5LJiUzi2w0AmuztvMeEckZKBh1U0zQueg/N Xp3UAvd6Y1gxU+kB4GsqVW62svONcg+ooOGdundhwk7DjWZBajiQ9bUpx5+9ISKdDFjH XtZPp1bOB9zKQT82Yd8L1frkKNwrzIRcmHAgTMZ/Bdb0lw/i5XX1KWkif8Nkuf0x0zA4 32gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EqwhlY7bE1lCGLzvlqq29Dej8d+1AVRsVgMR0fRsE04=; b=KycbaiNn95/pLzpYgKjF6fPeboE+3J97PC03hkPwGrF9PztnwPujRjiQ657wYPz/QF pLIBNz5dRlHylazHEM04kbkVfGLRKQLAzGYjR++KWalPLDao2LVQG0JOVoiDE1s6W5NW jWznprnVrrkrjJAI0EXhAcuB83+JfU+0dtvK8C/d/GI4XRCBnYhpUiVGmQdxLbwpwyKI aG5xunNvyjXwdjANoguXyrmDHCKdLkO291Rmm2nf3Zydt3R451Pz+MrmrQkHwTIlfp/7 WkZ7AUElDGxNT0H9gp/BfstJIL1Wtxh3k8Iy+tqWf8LdS/rrskvd3nRjUzR/lgycqAH1 ALBw== X-Gm-Message-State: ABuFfoh0IrPF+7A7VsFX1Xkt1iv4HnEDqDfgrUe2CmO0NIg6AWk/Z6K9 duXJ6NFKOaMMhndA12Uzelmubs2hylF2US3gyQJ/7Wgm X-Google-Smtp-Source: ACcGV62YU/caLKcNGYf6fcp9AiceFQy7UQYoCyq99LzYf3148ktg5Tff7biLGJFV95qvA0IzTQkAekTMmEQGyDzayUI= X-Received: by 2002:a2e:800e:: with SMTP id j14-v6mr4436302ljg.114.1539362071792; Fri, 12 Oct 2018 09:34:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 12 Oct 2018 09:34:19 -0700 Message-ID: To: "Grossman, Ethan A." Cc: DetNet WG , detnet-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000785eef05780aa9a3" Archived-At: Subject: Re: [Detnet] IETF 103 Bangkok - DetNet Meeting Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:34:37 -0000 --000000000000785eef05780aa9a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ethan, Mach and I would appreciate the opportunity to present and engage in discussion of the new version of draft-mirsky-detnet-oam. Here's the formal request: - OAM for DetNet Greg Mirsky 15 min Please let us know if you have any further questions. Regards, Greg On Fri, Oct 12, 2018 at 9:21 AM Grossman, Ethan A. wrote= : > Hi All, > > > > The IETF 103 Bangkok agenda has been posted: > > > > *https://datatracker.ietf.org/meeting/103/agenda.html > * > > > > We're scheduled to meet: > > Thursday, November 8, 2018 (+07) > > 13:50-15:50 Thursday Afternoon session I > > > > Please send any slot requests to the chairs email alias (see above) no > later than Monday October 22nd. Please include draft names(s), presenter > and desired slot length. Please keep in mind that priority for > presentation slots is given to WG drafts and other drafts/topics discusse= d > on the mailing list. > > > > The cutoff date for draft submissions is also Monday October 22nd, see > https://datatracker.ietf.org/meeting/important-dates/ > > > > > Best, > > Ethan (as DetNet WG Secretary). > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --000000000000785eef05780aa9a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ethan,
Mach and I would appreciate= the opportunity to present and engage in discussion of the new version of= =C2=A0draft-mirsky-detnet-oam. Here's the formal request:
  • OAM for DetNet=C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg Mirsky=C2=A0 =C2=A015 m= in

    • Please let us know if you have an= y further questions.

    Regards,
    Greg
    =

    On Fri, Oct 12,= 2018 at 9:21 AM Grossman, Ethan A. <eagros@dolby.com> wrote:

    Hi All,

    =C2=A0

    The IETF 103 Bangkok agenda has been po= sted:

    =C2=A0

    =C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/meet= ing/103/agenda.html

    =C2=A0

    We're scheduled to meet:<= /u>

    Thursday, November 8, 2018 (+07)=

    13:50-15:50 Thursday Afternoon session = I

    =C2=A0

    Please send any slot requests to the ch= airs email alias (see above)=C2=A0no later than Monday October 22nd.=C2=A0 = Please include draft names(s), presenter and=C2=A0desired slot length.=C2=A0 Please keep in mind that priority for presentation slots is = given to WG drafts and=C2=A0other drafts/topics discussed on the mailing li= st.

    =C2=A0

    The cutoff date for draft submissions i= s also Monday October 22nd, see=C2=A0https://datatr= acker.ietf.org/meeting/important-dates/

    =C2=A0

    Best,

    Ethan (as DetNet WG Secretary).<= u>

    =C2=A0

    _______________________________________________
    detnet mailing list
    detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
    --000000000000785eef05780aa9a3-- From nobody Tue Oct 16 05:55:47 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C14130DE4 for ; Tue, 16 Oct 2018 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyExMieygPKB for ; Tue, 16 Oct 2018 05:55:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A8E25130DE1 for ; Tue, 16 Oct 2018 05:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539694538; x=1542286538; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3nEdkJxtin1p5egG0bY17DAXpCP37hOb+dtRMlIU16Y=; b=eXJ83hPBGAKFi8or2ENWEuImeUs3db33DcTJO0diHGWWoBl4IRgQEpWd3ZdPVzRR sCwwGELvpahZVUjxpd74DcxSFZzywXwkj4yPTONzK6/aj0FLbEFMCMAspiCMAXS+ AYF88cjLL83m46HLi3v6Oz8S1sjTNrL0B8DKAK2BlvI=; X-AuditID: c1b4fb30-776849e0000047d2-8a-5bc5dfcaa49f Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.F8.18386.ACFD5CB5; Tue, 16 Oct 2018 14:55:38 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 16 Oct 2018 14:55:28 +0200 Received: from [131.160.183.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 16 Oct 2018 14:55:28 +0200 From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: , "detnet@ietf.org" CC: "detnet-chairs@ietf.org" References: <1ff1fb7a-1a40-0e6c-30c1-408fb04098bc@ericsson.com> Message-ID: Date: Tue, 16 Oct 2018 14:55:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1ff1fb7a-1a40-0e6c-30c1-408fb04098bc@ericsson.com> Content-Type: multipart/alternative; boundary="------------9133B73A57479F534AA1B3C2" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7ue6p+0ejDQ4v17G41v+DxeL3p9ks Fm9br7I6MHssWfKTKYAxissmJTUnsyy1SN8ugSvjzo5ljAWTzCpeTprE1MA4X7OLkYNDQsBE 4sgKty5GLg4hgaOMEuv3b2WDcL4xSlw8/4cVwjnGKLH3UB9jFyMnh7CApcS7qfeYQWw2AXuJ u5c2gNkiAoESUzfuYwexmQVMJX6828kM0TyNUWLRsyWMIOt4gRq27uMGqWERUJVYsOgZWL2o QKzEpyuLwebwCghKnJz5hAWknFPAQeLtWROIkWESZ7efZYawxSVuPZnPBGILCahJfHr7kH0C o+AsJN2zkLTMQtIyC2gqM9ARD7aWQYTlJZq3zoYq0Ze4fuc+K7L4Akb2VYyixanFSbnpRkZ6 qUWZycXF+Xl6eaklmxiB0XBwy2+DHYwvnzseYhTgYFTi4W3bcjRaiDWxrLgy9xCjBAezkghv +iWgEG9KYmVValF+fFFpTmrxIUZpDhYlcV4Lv81RQgLpiSWp2ampBalFMFkmDk6pBkaFojzu ur+dd5fsd9D5ZjH1uPFmRxPegwwXp2zeoFTjk7JEMZpLcnPNr88avH/uzZS8M+3gqilhJ81+ z+GJeJT6TOPcK6Msf4OTt/lib6zlnaT8/8+MV+JRG9+ZTOg/9MtaY/UrvRXyrV1nTuccL5Fp CDcO65RUZ49i4NmkZ786S/HGmnplkQQlluKMREMt5qLiRADXMh4gggIAAA== Archived-At: Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 12:55:45 -0000 --------------9133B73A57479F534AA1B3C2 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Authors, WG,     To address the issues raised during the adoption poll, we'd like to ask that the following be done before publishing a WG-00 version of draft-geng-detnet-conf-yang: 1) remove the leaves within the detnet-queuing-algorithms grouping, and change the description to be "Relationship with IEEE 802.1 TSN YANG models is TBD" 2) Add an open issues section that contains a list of all issues raised during the adoption poll.  Including:     The Relationship with 802.1 TSN YANG models is TBD. Once these, and only these, changes are published as a new version of draft-geng-detnet-conf-yang, we will ask the document be published as draft-ietf-detnet-yang-00. Thank you, Janos and Lou On 10/8/2018 6:01 PM, János Farkas wrote: > Hi, > > The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended. > > Overall, there is support for the adoption of the draft; however, some > concerns have been raised. > Technical details, for instance, open items related to data plane, can > be addressed after WG adoption. > However, inter-SDO related concerns should be addressed before WG > adoption. > > Authors, > Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO > concerns raised during the adoption poll. Please remove YANG data > model items that overlap with IEEE 802.1 work. > > Having the inter-SDO concerns resolved, the WG can continue the work > on the document as a WG document. > > Regards, > Janos and Lou > > > On 9/18/2018 9:02 PM, Janos Farkas wrote: >> >> Dear all, >> >> This is start of a two week poll on making >> draft-geng-detnet-conf-yang-04 >> a working group document. Please send email to the list indicating >> "yes/support" or "no/do not support".  If indicating no, please state >> your reservations with the document.  If yes, please also feel free to >> provide comments you'd like to see addressed once the document is a WG >> document. >> >> The poll ends Oct 3. >> >> Thanks, >> János and Lou >> > --------------9133B73A57479F534AA1B3C2 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Authors, WG,

        To address the issues raised during the adoption poll, we'd like to ask that the following be done before publishing a WG-00 version of draft-geng-detnet-conf-yang:

    1) remove the leaves within the detnet-queuing-algorithms grouping, and change the description to be "Relationship with IEEE 802.1 TSN YANG models is TBD"

    2) Add an open issues section that contains a list of all issues raised during the adoption poll.  Including:

        The Relationship with 802.1 TSN YANG models is TBD.

    Once these, and only these, changes are published as a new version of draft-geng-detnet-conf-yang, we will ask the document be published as draft-ietf-detnet-yang-00.

    Thank you,
    Janos and Lou


    On 10/8/2018 6:01 PM, János Farkas wrote:
    Hi,

    The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended.

    Overall, there is support for the adoption of the draft; however, some concerns have been raised.
    Technical details, for instance, open items related to data plane, can be addressed after WG adoption.
    However, inter-SDO related concerns should be addressed before WG adoption.

    Authors,
    Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO concerns raised during the adoption poll. Please remove YANG data model items that overlap with IEEE 802.1 work.

    Having the inter-SDO concerns resolved, the WG can continue the work on the document as a WG document.

    Regards,
    Janos and Lou


    On 9/18/2018 9:02 PM, Janos Farkas wrote:

    Dear all,

    This is start of a two week poll on making draft-geng-detnet-conf-yang-04
    a working group document. Please send email to the list indicating
    "yes/support" or "no/do not support".  If indicating no, please state
    your reservations with the document.  If yes, please also feel free to
    provide comments you'd like to see addressed once the document is a WG
    document.

    The poll ends Oct 3.

    Thanks,
    János and Lou



    --------------9133B73A57479F534AA1B3C2-- From nobody Tue Oct 16 19:00:55 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BB126F72; Tue, 16 Oct 2018 19:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAsJUCk7uCRR; Tue, 16 Oct 2018 19:00:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CA4B81252B7; Tue, 16 Oct 2018 19:00:50 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B9A9DA60318AA; Wed, 17 Oct 2018 03:00:44 +0100 (IST) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 03:00:45 +0100 Received: from DGGEMA521-MBX.china.huawei.com ([169.254.6.230]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0399.000; Wed, 17 Oct 2018 10:00:39 +0800 From: "Gengxuesong (Geng Xuesong)" To: =?iso-8859-1?Q?J=E1nos_Farkas?= , "draft-geng-detnet-conf-yang@ietf.org" , "detnet@ietf.org" CC: "detnet-chairs@ietf.org" Thread-Topic: WG adoption poll draft-geng-detnet-conf-yang Thread-Index: AQHUZU+Sn5/nykUJxUqX9E6TRD7WM6UirdjA Date: Wed, 17 Oct 2018 02:00:39 +0000 Message-ID: References: <1ff1fb7a-1a40-0e6c-30c1-408fb04098bc@ericsson.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: multipart/alternative; boundary="_000_F1C1D5B02EA3FA4A8AF54C86BA4F325C237F938Edggema521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 02:00:54 -0000 --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325C237F938Edggema521mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Chairs, Thank you for your suggestion, and we will modify the draft and upload it s= oon. Best Regards Xuesong From: J=E1nos Farkas [mailto:janos.farkas@ericsson.com] Sent: Tuesday, October 16, 2018 8:55 PM To: draft-geng-detnet-conf-yang@ietf.org; detnet@ietf.org Cc: detnet-chairs@ietf.org Subject: Re: WG adoption poll draft-geng-detnet-conf-yang Authors, WG, To address the issues raised during the adoption poll, we'd like to ask= that the following be done before publishing a WG-00 version of draft-geng= -detnet-conf-yang: 1) remove the leaves within the detnet-queuing-algorithms grouping, and cha= nge the description to be "Relationship with IEEE 802.1 TSN YANG models is = TBD" 2) Add an open issues section that contains a list of all issues raised dur= ing the adoption poll. Including: The Relationship with 802.1 TSN YANG models is TBD. Once these, and only these, changes are published as a new version of draft= -geng-detnet-conf-yang, we will ask the document be published as draft-ietf= -detnet-yang-00. Thank you, Janos and Lou On 10/8/2018 6:01 PM, J=E1nos Farkas wrote: Hi, The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended. Overall, there is support for the adoption of the draft; however, some conc= erns have been raised. Technical details, for instance, open items related to data plane, can be a= ddressed after WG adoption. However, inter-SDO related concerns should be addressed before WG adoption. Authors, Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO conc= erns raised during the adoption poll. Please remove YANG data model items t= hat overlap with IEEE 802.1 work. Having the inter-SDO concerns resolved, the WG can continue the work on the= document as a WG document. Regards, Janos and Lou On 9/18/2018 9:02 PM, Janos Farkas wrote: Dear all, This is start of a two week poll on making draft-geng-detnet-conf-yang-04 a working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends Oct 3. Thanks, J=E1nos and Lou --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325C237F938Edggema521mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Dear Chairs,

     

    Thank you for your suggestion, and we will modify the draft and u= pload it soon.

     

    Best Regards

     

    Xuesong

     

    F= rom: J=E1nos Far= kas [mailto:janos.farkas@ericsson.com]
    Sent: Tuesday, October 16, 2018 8:55 PM
    To: draft-geng-detnet-conf-yang@ietf.org; detnet@ietf.org
    Cc: detnet-chairs@ietf.org
    Subject: Re: WG adoption poll draft-geng-detnet-conf-yang=

     

    = Authors, WG,

        To address the issues raised during the adoption poll, w= e'd like to ask that the following be done before publishing a WG-00 versio= n of draft-geng-detnet-conf-yang:

    1) remove the leaves within the detnet-queuing-algorithms grouping, and cha= nge the description to be "Relationship with IEEE 802.1 TSN YANG model= s is TBD"

    2) Add an open issues section that contains a list of all issues raised dur= ing the adoption poll.  Including:

        The Relationship with 802.1 TSN YANG models is TBD.

    Once these, and only these, changes are published as a new version of draft= -geng-detnet-conf-yang, we will ask the document be published as draft-ietf= -detnet-yang-00.

    Thank you,
    Janos and Lou

    On 10/8/2018 6:01 PM, J=E1nos F= arkas wrote:

    = Hi,

    The poll on the WG adoption of draft-geng-detnet-conf-yang-04 has ended.
    Overall, there is support for the adoption of the draft; however, some conc= erns have been raised.
    Technical details, for instance, open items related to data plane, can be a= ddressed after WG adoption.
    However, inter-SDO related concerns should be addressed before WG adoption.=

    Authors,
    Please prepare draft-geng-detnet-conf-yang-05 to address the inter-SDO conc= erns raised during the adoption poll. Please remove YANG data model items t= hat overlap with IEEE 802.1 work.

    Having the inter-SDO concerns resolved, the WG can continue the work on the= document as a WG document.

    Regards,
    Janos and Lou

    On 9/18/2018 9:02 PM, Janos Far= kas wrote:

    Dear all,

    This is start of a two week poll on making draft-geng-detnet-conf-yang-04 <= br> a working group document. Please send email to the list indicating
    "yes/support" or "no/do not support".  If indicati= ng no, please state
    your reservations with the document.  If yes, please also feel free to=
    provide comments you'd like to see addressed once the document is a WG
    document.

    The poll ends Oct 3.

    Thanks,
    J=E1nos and Lou

     

     

    --_000_F1C1D5B02EA3FA4A8AF54C86BA4F325C237F938Edggema521mbxchi_-- From nobody Tue Oct 16 19:50:59 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5F1252B7; Tue, 16 Oct 2018 19:50:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <153974465064.9437.4758753762024096110@ietfa.amsl.com> Date: Tue, 16 Oct 2018 19:50:50 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-geng-detnet-conf-yang-05.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 02:50:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet Configuration YANG Model Authors : Xuesong Geng Mach(Guoyi) Chen Zhenqiang Li Reshad Rahman Filename : draft-geng-detnet-conf-yang-05.txt Pages : 51 Date : 2018-10-16 Abstract: This document defines a YANG data model for Deterministic Networking (DetNet), which includes the DetNet topology YANG module, DetNet flow configuration YANG module and DetNet Transport QoS YANG Module. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-geng-detnet-conf-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-geng-detnet-conf-yang-05 https://datatracker.ietf.org/doc/html/draft-geng-detnet-conf-yang-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-geng-detnet-conf-yang-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 16 20:51:29 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE468127AC2; Tue, 16 Oct 2018 20:51:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <153974828679.9449.14033266463915630968@ietfa.amsl.com> Date: Tue, 16 Oct 2018 20:51:26 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 03:51:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking (DetNet) Security Considerations Authors : Tal Mizrahi Ethan Grossman Andrew J. Hacker Subir Das John Dowdell Henrik Austad Kevin Stanton Norman Finn Filename : draft-ietf-detnet-security-03.txt Pages : 40 Date : 2018-10-16 Abstract: A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-security-03 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 16 21:05:54 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA23127B92 for ; Tue, 16 Oct 2018 21:05:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HuJ1aSMXbuu for ; Tue, 16 Oct 2018 21:05:48 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0119.outbound.protection.outlook.com [104.47.32.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013B12785F for ; Tue, 16 Oct 2018 21:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y+ZgtTAx83G1sv4ZU+lejG6VPpOdfA517oFBcQdMMYk=; b=PrmTEyRqfdqUd3nFlsCaPsPDGTKlf+TzsbOwS10Pd/v6FeBq9sN0YnQSkSXINyaognAk3N9u44hBsjAM07q+OqAdbtWE/a6sy3wm/oS+HZgR1u5vkE83zs7D0/6hRfJie0mGUpkduuI33XYLjnWJFxEcHNwxgtFzNFLPHQgBYB4= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4721.namprd06.prod.outlook.com (52.132.15.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Wed, 17 Oct 2018 04:05:45 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.027; Wed, 17 Oct 2018 04:05:45 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQ Date: Wed, 17 Oct 2018 04:05:45 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> In-Reply-To: <153974828679.9449.14033266463915630968@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4721; 6:60z+g7wN7cqdrBUFJNI8YJI1GcjJB4XarhtlMCLzCbt3jgQLrwORNSljbK1fXiKe4Ui87cmxWkt+by7vQXtSqsBMObk348QT3zRZZuR88r6Jk8g0N+tkTEx/GKQl+IZdDf/OCX6qNfV/cWWkKgcbxMWu+B4zESPXxbDti3W+ZBG3231zMLgjp5s38uo4fWL7jeippHLtMDjBGtr3lodRWgO9ZkmVGCbp2TzCzB2nhR5wHPxG4Yflo67TdOrt0y5+XJyp638RYWJzdP2rw4ZuLJIywY8+Alo+oI5w57d5r3OtJ1yMVWdzaKszY2WBqW7VnKDKVoPpkywvkDqFKpzKQjEbsHbxg4yWuHhHN4qMvPMSTEkdK3RfeYk/CTI0mUY+L5l3C2rf8HjexLSYDotJQUQT8eZavbY9jpF3yqGsPKqR+2WsqBQgMXDrXuYwXmfQ8CNAOekT4XmXElyq0uRxqA==; 5:RFh/7SHJ2VTfGPzZNfbpwb3LW8DSTiUegldSeAzlPyp+yhjTrhzh8/Gbmx9d3gqzwozdjS8lLgDkTGg7AoKRRDH21cnB8ll5qy53f3xmuazbZqm2lQLqSM2MZ8MF+sXq8WQ1bFBIJDLq0BzI/PkEAUceoFQWUZtt2Xv8BZILZ7Q=; 7:PNYnz5/nyepyMMye1d/9aKxjF8m7PiYfHQ1rZRcjYPAVv6VD5i+5IMUPW0QL5Op1iyzdikv4dBx3TZcgLMnZK6MVzKeGB5On/+MHwcCDAApoEVgfBcEvhmqaDKo2iitIcSrm3NkeuIY7SOWZM0wCXTuNtXr6FURVW2iQBeTrNgc0bOZ/BuMUaGEx3/+T9EDEnUqL4iUggpZISvyYAEEwEcldmywgB9HnqP5YG6LWeFqdLIoT6rmrZFCw9saCHf94 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 09c7fee8-4938-487e-e073-08d633e5d093 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4721; x-ms-traffictypediagnostic: BL0PR06MB4721: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991089); SRVR:BL0PR06MB4721; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4721; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(346002)(376002)(396003)(13464003)(189003)(53754006)(199004)(486006)(476003)(446003)(53546011)(6506007)(11346002)(5660300001)(33656002)(316002)(229853002)(6436002)(25786009)(7696005)(1730700003)(76176011)(68736007)(8676002)(5250100002)(81166006)(26005)(102836004)(2351001)(5640700003)(55016002)(8936002)(478600001)(4001150100001)(81156014)(2900100001)(106356001)(74316002)(7736002)(305945005)(6116002)(14454004)(3846002)(2501003)(66066001)(99286004)(966005)(71200400001)(2906002)(105586002)(71190400001)(97736004)(14444005)(9686003)(6916009)(186003)(6306002)(15650500001)(86362001)(53936002)(6246003)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4721; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HzfTxiaTlmEJs/HxRSw8Dqfyhy0ytM8vTcWRZrNacd6t3zVP1RuSgZsdMpGKX1gMTP/zOL3zHKEJDuOFoRt7ucI8ENw+cMwCwsjDVDmJUsJyzbSrNXLalklaHgHHp1M8TLQf61bHG8t+rQf3s39j0kzbbnDGICHB6aNE32r+dDMMQHr2H1rg3lMsiT2Yd25faoOJLxih6Qe5d5NO6gsc/t+eM/Oho7xeDxxdtYu26s+bWN0kf1r5bE7kC22tbOlpNd3SnjnyDmKbWXCSV6tNQzH/nUQCYh2HpN2KxHIwtTcso+zl3/MBDk3AzThzHgT8dfZZ9g8mzhwse9UwxPDoQLuMxQCllOc5FqGxofQLn3E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09c7fee8-4938-487e-e073-08d633e5d093 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 04:05:45.8492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4721 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 04:05:51 -0000 Hi All, This note is the status update for the DetNet Security Considerations draft= in advance of IETF 103, in lieu of a presentation slot for it at IETF 103.= =20 A new version has been posted which includes the discussion on OAM traffic = and incorporates the "Bounded Jitter" Use Case Common Theme.=20 These are minor changes; no substantial work has been done since the last D= etNet session, so we do not plan to have a slot for this draft at the IETF = 103 DetNet session (though Tal will be presenting on it at the DetNet-TSN m= eeting on the following Sunday).=20 I expect that we will convene as many of the authors (and any other interes= ted parties) as we have available at IETF 103 to discuss DetNet-data-plane-= technology-specific security considerations and how to incorporate them int= o the draft as our next steps. If you would like to participate in (be noti= fied about) this conversation, please let me know.=20 Best, Ethan (as DetNet Security Considerations draft editor) -----Original Message----- From: detnet On Behalf Of internet-drafts@ietf.or= g Sent: Tuesday, October 16, 2018 8:51 PM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking (DetNet) Security Consid= erations Authors : Tal Mizrahi Ethan Grossman Andrew J. Hacker Subir Das John Dowdell Henrik Austad Kevin Stanton Norman Finn Filename : draft-ietf-detnet-security-03.txt Pages : 40 Date : 2018-10-16 Abstract: A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-security-03 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-security-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Oct 17 00:09:52 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC6130E7A for ; Wed, 17 Oct 2018 00:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R22yiCkUl_1O for ; Wed, 17 Oct 2018 00:09:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F922129AB8 for ; Wed, 17 Oct 2018 00:09:47 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.168.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D18E7180121E; Wed, 17 Oct 2018 09:09:43 +0200 (CEST) To: "Grossman, Ethan A." References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> From: Loa Andersson Cc: "detnet@ietf.org" Message-ID: <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> Date: Wed, 17 Oct 2018 15:09:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:09:50 -0000 Ethan, I have just had a quick look, but what I see looks good, and certainly gives a good overview of the detnet security issues. One question, is it the intention that this document should be used as a general reference when writing security considerations for detnet documents? /Loa On 2018-10-17 12:05, Grossman, Ethan A. wrote: > Hi All, > This note is the status update for the DetNet Security Considerations draft in advance of IETF 103, in lieu of a presentation slot for it at IETF 103. > > A new version has been posted which includes the discussion on OAM traffic and incorporates the "Bounded Jitter" Use Case Common Theme. > > These are minor changes; no substantial work has been done since the last DetNet session, so we do not plan to have a slot for this draft at the IETF 103 DetNet session (though Tal will be presenting on it at the DetNet-TSN meeting on the following Sunday). > > I expect that we will convene as many of the authors (and any other interested parties) as we have available at IETF 103 to discuss DetNet-data-plane-technology-specific security considerations and how to incorporate them into the draft as our next steps. If you would like to participate in (be notified about) this conversation, please let me know. > > Best, > Ethan (as DetNet Security Considerations draft editor) > > -----Original Message----- > From: detnet On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, October 16, 2018 8:51 PM > To: i-d-announce@ietf.org > Cc: detnet@ietf.org > Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Deterministic Networking WG of the IETF. > > Title : Deterministic Networking (DetNet) Security Considerations > Authors : Tal Mizrahi > Ethan Grossman > Andrew J. Hacker > Subir Das > John Dowdell > Henrik Austad > Kevin Stanton > Norman Finn > Filename : draft-ietf-detnet-security-03.txt > Pages : 40 > Date : 2018-10-16 > > Abstract: > A deterministic network is one that can carry data flows for real- > time applications with extremely low data loss rates and bounded > latency. Deterministic networks have been successfully deployed in > real-time operational technology (OT) applications for some years > (for example [ARINC664P7]). However, such networks are typically > isolated from external access, and thus the security threat from > external attackers is low. IETF Deterministic Networking (DetNet) > specifies a set of technologies that enable creation of deterministic > networks on IP-based networks of potentially wide area (on the scale > of a corporate network) potentially bringing the OT network into > contact with Information Technology (IT) traffic and security threats > that lie outside of a tightly controlled and bounded area (such as > the internals of an aircraft). These DetNet technologies have not > previously been deployed together on a wide area IP-based network, > and thus can present security considerations that may be new to IP- > based wide area network designers. This draft, intended for use by > DetNet network designers, provides insight into these security > considerations. In addition, this draft collects all security- > related statements from the various DetNet drafts (Architecture, Use > Cases, etc) into a single location Section 7. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-detnet-security-03 > https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Oct 17 00:54:17 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2638130E84 for ; Wed, 17 Oct 2018 00:54:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sagl21UYdGvr for ; Wed, 17 Oct 2018 00:54:13 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::728]) (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 38989130E83 for ; Wed, 17 Oct 2018 00:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=etYvgG7mHlcFpycbtwgxcWhuICK6+PVrQhdkHAqvPrk=; b=g7DYdhBU3FyDGE/t/nd+6f8oKHP93UENF9bLNNbsVTQuUlXyLbtm2jGjIccBSTnFHg5cOmhnWUfGrt6GzIup5npOsQ9QM3YwBPx0CDfGcvVh6zHbtFkFFS5nKAAJexrzwyftaZKaGau2zC8zUxNjv9GiuenbK1LkONT68xNa6Hc= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4563.namprd06.prod.outlook.com (20.177.145.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Wed, 17 Oct 2018 07:54:10 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.027; Wed, 17 Oct 2018 07:54:10 +0000 From: "Grossman, Ethan A." To: Loa Andersson CC: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQgAA3NYCAAAlfoA== Date: Wed, 17 Oct 2018 07:54:10 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> In-Reply-To: <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4563; 6:iuO2Y1h/yVaHAAIgT7N28dKCnVm/Dc2fUbJm1tG8UpcrUYH8ocv9ePObc5jUMV4tGFaiMPPAylBeGAyB64BbWz0YVXI7mqJZ2aiJFqTPThhDBH3uSKUScinrDImuzwgriuBpYO98Iofx9ehQQa8adz4GvO2MXxxuFZFY3HX3L4aNP/cgauKxGRSKmjc45sgNHfHOlX3opuNB8dTGJzBul/U9W2LT7hPWTUu6H0cd4REidDQO2cL8qzI/tOdCWQ7vNg4HRZ1JdKmzvPLHi7ZFytiEQp8s5o2pkaq9zLoooMMzQdldOAB4s87aOLQ3prIP6EImLb/xFNERtQZoolNfMMZeUn8VxisgjG6nDrhqXg19+1kSCuR9opZOsS2yx23pMUsWbBj9+8SDYQG08xdvcR7GS+xnO6IW1KAkwewKMK2KMzwFhnGm72bh7sAGKUx1oOQqbWuC9PuVLrTJNBTsCg==; 5:eV5TGbb7/vVh2Km+yvKDChXQ08Ty4YE/EavTZPoz5B5/U0BAebGJBkUXwBSCVdYPobh/rNVjkutboREKVCOLzMQ72cAwX839AVAbC4JRrUMKsizPnZQsgZVtDax+gHa70gogjWfCQp4TvDeiZYpaeKYmaqnXUkeECNX14EG5DtI=; 7:MdfjPCvQLtS5trEFCQG7a8OGODq7Guo8kga2ncVGyEdsxXK+pP3tUEDIYz2+e0EXvDH22ayYA4NSzsm83ntmlvBZv/U/hCGhVycpNS/RrpTdNKEn6dcpgPtKjv1ux8Z79AHDnXGPFcszjbcutCKXvlPupXeGYzPLjNlKwxaKqveZk4dSj7DmVX5uR76hKrjQ8V4SafEPI82K32aNSOhCiQqvindEaBPwxXxFFZNkLzZfWep5HXgWU4xL+KBcALxm x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0f2ff6f0-658d-44a3-16b9-08d63405b954 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4563; x-ms-traffictypediagnostic: BL0PR06MB4563: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4563; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4563; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(346002)(376002)(366004)(252514010)(199004)(189003)(53754006)(13464003)(33656002)(6116002)(7696005)(256004)(486006)(15650500001)(8936002)(476003)(5660300001)(5250100002)(68736007)(3846002)(99286004)(9686003)(14444005)(316002)(11346002)(6916009)(2900100001)(446003)(66066001)(478600001)(97736004)(55016002)(6306002)(105586002)(25786009)(74316002)(14454004)(966005)(71200400001)(6436002)(305945005)(6246003)(7736002)(71190400001)(229853002)(106356001)(4001150100001)(53936002)(186003)(81156014)(81166006)(6506007)(8676002)(6346003)(102836004)(86362001)(76176011)(2906002)(53546011)(26005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4563; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-microsoft-antispam-message-info: ReTLSZuGGblk3spvPOk2cYdWJCSFrkBCwTGWz5OD+C6pHrHM1I/0Ce3sCoKFOwA6QLI73Tlp9UhEOF13BWLzfaus5pykEwl+iZkgelmwEYhL1CUm2X54fCE75wlCdf9H2gziBxUL9fJ8MHQT/djEzWJIpju9cSeJV/cvsS9EOwU5Jx9IFaIW3wLcUVz8wDHCADFCt8Fdb0+Z96boyuNJlEvQZBW5Eq7ay8ytI0l0AU+VImJXnrn0tJHysz5SkwOZX0OKONZbOEMfG9mQZ0OX6rgG3YrFSN+zwOKl4VIA7q/AyCQuP4ASSvefomSFgP43Znota67Ozq8zE3xvX1ZBTgnqu8LTMi4DV3g40hxcGAc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f2ff6f0-658d-44a3-16b9-08d63405b954 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 07:54:10.3347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4563 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:54:16 -0000 SGkgTG9hLA0KVmFyaW91cyBzdHJhdGVnaWVzIGFyZSBwb3NzaWJsZS4gT25lIHBvc3NpYmlsaXR5 IGlzIHRoYXQgdGhlIG90aGVyIGRyYWZ0cyAoaS5lLiBub3QgdGhlIFNlY3VyaXR5IGRyYWZ0KSBj b3VsZCBqdXN0IHBvaW50IGF0IHRoZSBTZWN1cml0eSBkcmFmdCBzdWNoIHRoYXQgdGhlcmUgd291 bGQgYmUgYSAic2luZ2xlIGNsZWFyaW5nIGhvdXNlIiBmb3IgRGV0TmV0LXNwZWNpZmljIHNlY3Vy aXR5IGluZm8uICBUaGF0J3Mgd2hhdCB0aGUgVXNlIENhc2VzIGRyYWZ0IGRvZXMsIGhvd2V2ZXIg dGhlcmUgaXMgYWxzbyBzb21lIHNlY3VyaXR5LXJlbGF0ZWQgdGV4dCBpbiB0aGUgdmFyaW91cyB1 c2UgY2FzZXMuIA0KDQpBdCBvbmUgcG9pbnQgSSAoYXMgU2VjdXJpdHkgZHJhZnQgZWRpdG9yKSBh dHRlbXB0ZWQgdG8gYnJpbmcgdG9nZXRoZXIgYWxsIG9mIHRoZSBzZWN1cml0eS1yZWxhdGVkIHRl eHQgZnJvbSB0aGUgdmFyaW91cyBvdGhlciBkcmFmdHMgYnkgY29weWluZyBpdCBhbGwgaW50byBh biBhcHBlbmRpeCBvZiB0aGUgU2VjdXJpdHkgZHJhZnQsIHNpbmNlIGl0IGlzIHNvcnQgb2YgaGFu ZHkgdG8gaGF2ZSBpdCBhbGwgaW4gb25lIHBsYWNlLiBCdXQgYXMgTG91IHBvaW50ZWQgb3V0IHRv IG1lLCB3ZSBkb24ndCB3YW50IHRvIG1ha2UgdGhlIGRyYWZ0cyBkZXBlbmRlbnQgb24gZWFjaCBv dGhlciBpZiB3ZSBjYW4gYXZvaWQgaXQsIGFuZCBpZiBzdWNoIHRleHQgZ290IGVkaXRlZCB0aGVu IGl0IHdvdWxkIGhhdmUgdG8gYmUgZml4ZWQgaW4gdHdvIHBsYWNlcywgc28gaXQgaXNuJ3QgYSBw ZXJmZWN0IHNjaGVtZS4gSSB3b3VsZCBzYXkgdGhhdCBpZiBhIGRyYWZ0IGF1dGhvciB3YW50cyB0 byB3cml0ZSB0aGVpciBvd24gc2VjdXJpdHktcmVsYXRlZCB0ZXh0IGluIHRoZWlyIG93biBkcmFm dCBtb3JlIHBvd2VyIHRvIHRoZW0sIGJ1dCBwZXJoYXBzIGV2ZW4gbW9yZSBwb3dlciBpZiB0aGV5 IGJyaW5nIGl0IHRvIHRoZSBTZWN1cml0eSBkcmFmdCA6LSApIA0KDQpTb3JyeSBsb25nIGFuc3dl ciB0byBhIHNob3J0IHF1ZXN0aW9uLiBBbmQgSSdtIHN1cmUgdGhlcmUgYXJlIG90aGVyIHN0cmF0 ZWdpZXMuLi4gSWYgeW91IGhhdmUgYW55IHRob3VnaHRzIG9uIHRoZSBtYXR0ZXIgSSdkIGxvdmUg dG8gaGVhciB0aGVtLCBlaXRoZXIgb24gdGhlIGxpc3Qgb3IgYXQgSUVURiAxMDMuDQpFdGhhbi4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvYSBBbmRlcnNzb24gPGxvYUBw aS5udT4gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTggMTI6MTAgQU0NClRvOiBH cm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb20+DQpDYzogZGV0bmV0QGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0RldG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2Vj dXJpdHktMDMudHh0DQoNCkV0aGFuLA0KDQpJIGhhdmUganVzdCBoYWQgYSBxdWljayBsb29rLCBi dXQgd2hhdCBJIHNlZSBsb29rcyBnb29kLCBhbmQgY2VydGFpbmx5IGdpdmVzIGEgZ29vZCBvdmVy dmlldyBvZiB0aGUgZGV0bmV0IHNlY3VyaXR5IGlzc3Vlcy4NCg0KT25lIHF1ZXN0aW9uLCBpcyBp dCB0aGUgaW50ZW50aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgdXNlZCBhcyBhIGdl bmVyYWwgcmVmZXJlbmNlIHdoZW4gd3JpdGluZyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Ig ZGV0bmV0IGRvY3VtZW50cz8NCg0KL0xvYQ0KDQpPbiAyMDE4LTEwLTE3IDEyOjA1LCBHcm9zc21h biwgRXRoYW4gQS4gd3JvdGU6DQo+IEhpIEFsbCwNCj4gVGhpcyBub3RlIGlzIHRoZSBzdGF0dXMg dXBkYXRlIGZvciB0aGUgRGV0TmV0IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGRyYWZ0IGluIGFk dmFuY2Ugb2YgSUVURiAxMDMsIGluIGxpZXUgb2YgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgaXQg YXQgSUVURiAxMDMuDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCB3aGljaCBp bmNsdWRlcyB0aGUgZGlzY3Vzc2lvbiBvbiBPQU0gdHJhZmZpYyBhbmQgaW5jb3Jwb3JhdGVzIHRo ZSAiQm91bmRlZCBKaXR0ZXIiIFVzZSBDYXNlIENvbW1vbiBUaGVtZS4NCj4gDQo+IFRoZXNlIGFy ZSBtaW5vciBjaGFuZ2VzOyBubyBzdWJzdGFudGlhbCB3b3JrIGhhcyBiZWVuIGRvbmUgc2luY2Ug dGhlIGxhc3QgRGV0TmV0IHNlc3Npb24sIHNvIHdlIGRvIG5vdCBwbGFuIHRvIGhhdmUgYSBzbG90 IGZvciB0aGlzIGRyYWZ0IGF0IHRoZSBJRVRGIDEwMyBEZXROZXQgc2Vzc2lvbiAodGhvdWdoIFRh bCB3aWxsIGJlIHByZXNlbnRpbmcgb24gaXQgYXQgdGhlIERldE5ldC1UU04gbWVldGluZyBvbiB0 aGUgZm9sbG93aW5nIFN1bmRheSkuDQo+IA0KPiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgY29udmVu ZSBhcyBtYW55IG9mIHRoZSBhdXRob3JzIChhbmQgYW55IG90aGVyIGludGVyZXN0ZWQgcGFydGll cykgYXMgd2UgaGF2ZSBhdmFpbGFibGUgYXQgSUVURiAxMDMgdG8gZGlzY3VzcyBEZXROZXQtZGF0 YS1wbGFuZS10ZWNobm9sb2d5LXNwZWNpZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBo b3cgdG8gaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBkcmFmdCBhcyBvdXIgbmV4dCBzdGVwcy4g SWYgeW91IHdvdWxkIGxpa2UgdG8gcGFydGljaXBhdGUgaW4gKGJlIG5vdGlmaWVkIGFib3V0KSB0 aGlzIGNvbnZlcnNhdGlvbiwgcGxlYXNlIGxldCBtZSBrbm93Lg0KPiANCj4gQmVzdCwNCj4gRXRo YW4gKGFzIERldE5ldCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBkcmFmdCBlZGl0b3IpDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkZXRuZXQgPGRldG5ldC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgDQo+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE2LCAyMDE4IDg6NTEgUE0NCj4gVG86IGktZC1hbm5v dW5jZUBpZXRmLm9yZw0KPiBDYzogZGV0bmV0QGlldGYub3JnDQo+IFN1YmplY3Q6IFtEZXRuZXRd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzLnR4dA0KPiANCj4gDQo+ IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIFdHIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIChEZXROZXQpIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zDQo+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRhbCBN aXpyYWhpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGFuIEdyb3NzbWFuDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJldyBKLiBIYWNrZXINCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgU3ViaXIgRGFzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpv aG4gRG93ZGVsbA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBIZW5yaWsgQXVzdGFkDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEtldmluIFN0YW50b24NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgTm9ybWFuIEZpbm4NCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtZGV0bmV0LXNlY3VyaXR5LTAzLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogNDANCj4gCURh dGUgICAgICAgICAgICA6IDIwMTgtMTAtMTYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgQSBkZXRl cm1pbmlzdGljIG5ldHdvcmsgaXMgb25lIHRoYXQgY2FuIGNhcnJ5IGRhdGEgZmxvd3MgZm9yIHJl YWwtDQo+ICAgICB0aW1lIGFwcGxpY2F0aW9ucyB3aXRoIGV4dHJlbWVseSBsb3cgZGF0YSBsb3Nz IHJhdGVzIGFuZCBib3VuZGVkDQo+ICAgICBsYXRlbmN5LiAgRGV0ZXJtaW5pc3RpYyBuZXR3b3Jr cyBoYXZlIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkIGluDQo+ICAgICByZWFsLXRpbWUgb3Bl cmF0aW9uYWwgdGVjaG5vbG9neSAoT1QpIGFwcGxpY2F0aW9ucyBmb3Igc29tZSB5ZWFycw0KPiAg ICAgKGZvciBleGFtcGxlIFtBUklOQzY2NFA3XSkuICBIb3dldmVyLCBzdWNoIG5ldHdvcmtzIGFy ZSB0eXBpY2FsbHkNCj4gICAgIGlzb2xhdGVkIGZyb20gZXh0ZXJuYWwgYWNjZXNzLCBhbmQgdGh1 cyB0aGUgc2VjdXJpdHkgdGhyZWF0IGZyb20NCj4gICAgIGV4dGVybmFsIGF0dGFja2VycyBpcyBs b3cuICBJRVRGIERldGVybWluaXN0aWMgTmV0d29ya2luZyAoRGV0TmV0KQ0KPiAgICAgc3BlY2lm aWVzIGEgc2V0IG9mIHRlY2hub2xvZ2llcyB0aGF0IGVuYWJsZSBjcmVhdGlvbiBvZiBkZXRlcm1p bmlzdGljDQo+ICAgICBuZXR3b3JrcyBvbiBJUC1iYXNlZCBuZXR3b3JrcyBvZiBwb3RlbnRpYWxs eSB3aWRlIGFyZWEgKG9uIHRoZSBzY2FsZQ0KPiAgICAgb2YgYSBjb3Jwb3JhdGUgbmV0d29yaykg cG90ZW50aWFsbHkgYnJpbmdpbmcgdGhlIE9UIG5ldHdvcmsgaW50bw0KPiAgICAgY29udGFjdCB3 aXRoIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgKElUKSB0cmFmZmljIGFuZCBzZWN1cml0eSB0aHJl YXRzDQo+ICAgICB0aGF0IGxpZSBvdXRzaWRlIG9mIGEgdGlnaHRseSBjb250cm9sbGVkIGFuZCBi b3VuZGVkIGFyZWEgKHN1Y2ggYXMNCj4gICAgIHRoZSBpbnRlcm5hbHMgb2YgYW4gYWlyY3JhZnQp LiAgVGhlc2UgRGV0TmV0IHRlY2hub2xvZ2llcyBoYXZlIG5vdA0KPiAgICAgcHJldmlvdXNseSBi ZWVuIGRlcGxveWVkIHRvZ2V0aGVyIG9uIGEgd2lkZSBhcmVhIElQLWJhc2VkIG5ldHdvcmssDQo+ ICAgICBhbmQgdGh1cyBjYW4gcHJlc2VudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IG1h eSBiZSBuZXcgdG8gSVAtDQo+ICAgICBiYXNlZCB3aWRlIGFyZWEgbmV0d29yayBkZXNpZ25lcnMu ICBUaGlzIGRyYWZ0LCBpbnRlbmRlZCBmb3IgdXNlIGJ5DQo+ICAgICBEZXROZXQgbmV0d29yayBk ZXNpZ25lcnMsIHByb3ZpZGVzIGluc2lnaHQgaW50byB0aGVzZSBzZWN1cml0eQ0KPiAgICAgY29u c2lkZXJhdGlvbnMuICBJbiBhZGRpdGlvbiwgdGhpcyBkcmFmdCBjb2xsZWN0cyBhbGwgc2VjdXJp dHktDQo+ICAgICByZWxhdGVkIHN0YXRlbWVudHMgZnJvbSB0aGUgdmFyaW91cyBEZXROZXQgZHJh ZnRzIChBcmNoaXRlY3R1cmUsIFVzZQ0KPiAgICAgQ2FzZXMsIGV0YykgaW50byBhIHNpbmdsZSBs b2NhdGlvbiBTZWN0aW9uIDcuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5Lw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMw0KPiANCj4gQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMN Cj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+IGRl dG5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rl dG5ldA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPiBkZXRuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCj4gDQoNCi0tIA0KDQoNCkxvYSBB bmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQpTZW5pb3Ig TVBMUyBFeHBlcnQNCkJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTog KzQ2IDczOSA4MSAyMSA2NA0K From nobody Wed Oct 17 01:28:50 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE36E130DC8 for ; Wed, 17 Oct 2018 01:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPkZNoNmBq-3 for ; Wed, 17 Oct 2018 01:28:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 51887129AB8 for ; Wed, 17 Oct 2018 01:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539764906; x=1542356906; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0SC1NrKOtNdcJPB3pCDe0nl15NYnAlXfhxXhDZWcPsA=; b=RpCYkOmV1D3q7EgX2WjpyTfANr5fmWo1X3Kw8N3o9np008tKB1yQQxZUYVUOKqFr fZQZ9XIZ9nUxyI+Sq0pwqo7uhkbsAlzmrYpUU/alIKwS8uka5B02IuKFCVqQ2vpc VWsaGwIw6AOpJr9sLkYv4WQDeE95o/EtbXU9E036xqU=; X-AuditID: c1b4fb2d-b37ff70000003a27-06-5bc6f2aa0cc2 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.55.14887.AA2F6CB5; Wed, 17 Oct 2018 10:28:26 +0200 (CEST) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 10:28:26 +0200 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 10:28:26 +0200 Received: from [131.160.183.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 17 Oct 2018 10:28:25 +0200 References: To: Daniel Harkins CC: "iesg@ietf.org" , "secdir@ietf.org" , , DetNet WG From: =?UTF-8?Q?J=c3=a1nos_Farkas?= X-Forwarded-Message-Id: Message-ID: Date: Wed, 17 Oct 2018 10:28:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7CA1B052BC73CFD1832EC37D" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2J7te6qT8eiDSYek7f4/Wk2i8XSf19Y LPbN2sRiMePPRGaLDwsfsjiweixZ8pPJ49nulywBTFFcNimpOZllqUX6dglcGYf2yxa8dql4 c2YnSwPjYdMuRk4OCQETiXdNL1i6GLk4hASOMkosv/WeCcL5xijx4sUlBOfM7LVQZccYJfbO mckM0i8sYC/RdWMCE4gtBGTfW/gZzBYR0JDo3LaYDaSBWWAao8SUm4/YQRJsQEV3L21ghlju LbFo8lFGEJsXKH7x33GwZhYBVYnLnZ/YQGxRgViJT1cWM0PUCEqcnPmEBcTmFHCQeLt+FVgv s0CYxJ4/R9kgbHGJW0/mQx2kJvG+4Q7jBEbhWUjaZyFpmYWkBcK2kJg5/zwjhC0v0bx1NjOE rSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBMXZwy2/dHYyrXzseYhTg YFTi4Y38eCxaiDWxrLgy9xCjBAezkghv5mKgEG9KYmVValF+fFFpTmrxIUZpDhYlcV69VXui hATSE0tSs1NTC1KLYLJMHJxSDYwGSz0PsQU+itgVdK3Xxu75plZOl/RLy6w+N5k4b9RZ4Ccw 4e+0wIjPea4JHo8WSfyVuuB9n30P94NN289Mdlm7ZrFWzOrEPIcP3dO6T512T/35y+bxmamX dznO8Erw33j3VuMcGb2l5q809L/bXdX43N62ctL9d2ypr4JedijnrGuvZbkbwSCpxFKckWio xVxUnAgASQl7b60CAAA= Archived-At: Subject: Re: [Detnet] secdir review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 08:28:36 -0000 --------------7CA1B052BC73CFD1832EC37D Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, Thank you very much for your review! Please find below how we plan to update the draft to address your comments. Best regards, Janos On 9/25/2018 2:58 AM, Daniel Harkins wrote: > >   Hello, > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is ready with issues. > > This draft describes an architecture for deterministic networking > that provides for delivery of packet flows with low packet loss and > with a maximum amount of latency. > > A nit first. The terminology seems a bit overblown. We have DetNet > Intermediate nodes that could be relay nodes or transit nodes; and a > DetNet system that is a DetNet aware system or transit node or > relay node; and DetNet edge nodes that are relay nodes; and DetNet > relay nodes that can be bridges, firewalls, or anything else that > participates in DetNet. Finally, to translate between 802.1 TSN and > DetNet we have a "relay system" that is an 802.1 term for a DetNet > intermediate node which, as we have seen, is a DetNet relay node. This > can be simplified considerably. The definition of DetNet relay node will be updated. "A DetNet relay node can be a bridge, a router, a firewall, or any other system" will be delated. OLD: A DetNet node including a service layer function that interconnects different DetNet transport layer paths to provide service protection. A DetNet relay node can be a bridge, a router, a firewall, or any other system that participates in the DetNet service layer. It typically incorporates DetNet transport layer functions as well, in which case it is collocated with a transit node. NEW: A DetNet node including a service layer function that interconnects different DetNet transport layer paths to provide service protection. A DetNet relay node operates at the service layer. It typically incorporates DetNet transport layer functions as well, in which case it is collocated with a DetNet transit node. > The Security Considerations is thin, especially for an architecture > draft that is going to be referred to by subsequent drafts which will > just say something along the lines of, "as an instance of the DetNet > FooBar, these Security Considerations are those from [ARCH]", where > ARCH is the RFC that comes out of this I-D. I think there needs to be > a description of the various points in the architecture that an attacker > could exploit, and if a point is not exploitable it should say so. For > instance: > > - is it possible for an attacker to launch a DoS attack by manipulating > member flows of a DetNet flow in order to force DetNet nodes to > consume buffers they allocated to deal with the DetNet flow? > > - If an end system is not DetNet aware there needs to be a DetNet edge > node to handle the encaps of the flow into the DetNet system. Can an > attacker in that case introduce packets that shouldn't be part of the > DetNet flow into the flow by getting the edge node to encaps them as > such? > > If there are any assumptions being made-- e.g. "insider attacks are not > being considered"-- they should be mentioned. > > regards, > > Dan. > > Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security. Reference will be added to the DetNet security document. --------------7CA1B052BC73CFD1832EC37D Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Daniel,

    Thank you very much for your review!

    Please find below how we plan to update the draft to address your comments.

    Best regards,
    Janos


    On 9/25/2018 2:58 AM, Daniel Harkins wrote:
     
      Hello,
      I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

  The summary of the review is ready with issues.

  This draft describes an architecture for deterministic networking
that provides for delivery of packet flows with low packet loss and
with a maximum amount of latency. 

  A nit first. The terminology seems a bit overblown. We have DetNet
Intermediate nodes that could be relay nodes or transit nodes; and a
DetNet system that is a DetNet aware system or transit node or
relay node; and DetNet edge nodes that are relay nodes; and DetNet
relay nodes that can be bridges, firewalls, or anything else that
participates in DetNet. Finally, to translate between 802.1 TSN and
DetNet we have a "relay system" that is an 802.1 term for a DetNet
intermediate node which, as we have seen, is a DetNet relay node. This
can be simplified considerably.
    The definition of DetNet relay node will be updated.
    "A DetNet relay node can be a bridge, a router, a firewall, or any other system" will be delated.

    OLD:
    A DetNet node including a service layer function that
    interconnects different DetNet transport layer paths to
    provide service protection. A DetNet relay node can be a
    bridge, a router, a firewall, or any other system that
    participates in the DetNet service layer. It typically
    incorporates DetNet transport layer functions as well, in
    which case it is collocated with a transit node.

    NEW:
    A DetNet node including a service layer function that
    interconnects different DetNet transport layer paths to
    provide service protection. A DetNet relay node operates
    at the service layer. It typically incorporates DetNet
    transport layer functions as well, in which case it is
    collocated with a DetNet transit node.



      The Security Considerations is thin, especially for an architecture
draft that is going to be referred to by subsequent drafts which will
just say something along the lines of, "as an instance of the DetNet
FooBar, these Security Considerations are those from [ARCH]", where
ARCH is the RFC that comes out of this I-D. I think there needs to be
a description of the various points in the architecture that an attacker
could exploit, and if a point is not exploitable it should say so. For
instance:

  - is it possible for an attacker to launch a DoS attack by manipulating
    member flows of a DetNet flow in order to force DetNet nodes to
    consume buffers they allocated to deal with the DetNet flow?

  - If an end system is not DetNet aware there needs to be a DetNet edge
    node to handle the encaps of the flow into the DetNet system. Can an
    attacker in that case introduce packets that shouldn't be part of the
    DetNet flow into the flow by getting the edge node to encaps them as
    such?

If there are any assumptions being made-- e.g. "insider attacks are not
being considered"-- they should be mentioned. 

  regards,

  Dan.

    Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security.
    Reference will be added to the DetNet security document.
    --------------7CA1B052BC73CFD1832EC37D-- From nobody Wed Oct 17 01:56:36 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28208130DE0 for ; Wed, 17 Oct 2018 01:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-5-Nj-ZBHNV for ; Wed, 17 Oct 2018 01:56:26 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 70DF6130DC0 for ; Wed, 17 Oct 2018 01:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539766579; x=1542358579; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CH17s1qfgGjGC+1Z28GQEjesGXd0uKH7Hat5p3OJtd0=; b=LTr41qj2GJv+TGlUIIDwkFUTeC7NHSWzxU+B23Di+x6Dqe2w8LFBcR6lbKCLEqYr n7fwrqRYeFv9dN0qG2DpJh/XrgGNjh/XLZRJzsI6m5fT8pALm40I245D26kGE0Ob piUOVD0P3e9TuOo7+4k+MFE9CDjNHIsKhx0uV2yfrJA=; X-AuditID: c1b4fb3a-159ff700000012ff-e8-5bc6f9335bae Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.E9.04863.339F6CB5; Wed, 17 Oct 2018 10:56:19 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 10:56:18 +0200 Received: from [131.160.183.116] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.187) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 17 Oct 2018 10:56:18 +0200 References: <0bb7176c-c386-b863-a4f8-06254f4627ab@ericsson.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Michael Scharf CC: , , DetNet WG X-Forwarded-Message-Id: <0bb7176c-c386-b863-a4f8-06254f4627ab@ericsson.com> Message-ID: <1705d15c-c7ba-c76f-88db-c75f1a88db0f@ericsson.com> Date: Wed, 17 Oct 2018 10:56:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0bb7176c-c386-b863-a4f8-06254f4627ab@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7ka7xz2PRBg0vuS1+f5rNYrFv1iYg sbiZ3WLWnkUsDiweTa/+sXosWfKTKYApissmJTUnsyy1SN8ugSvj/uHAgtOnGSve7NzA0sC4 bAljFyMnh4SAicT6W2vYuxi5OIQEjjJKLG5awALhfGOUeDzpJTNIlZDAMUaJ1r3FXYwcQLa9 xPkvbCBhNiDz7qUNYCUiAsYSy9cuZQGxmQVSJNb/es4EYgsLeEqcuj6bDaRVQsBbYtvfYJAw L1Drr40XwMpZBFQl5t/vBxspKhAr8enKYmaIGkGJkzOfgNVwCjhINP/phBpvITFz/nlGCFte onnrbGYIW1zi1pP5TBAXq0l8evuQfQKj8Cwko2YhaZ+FpH0WkvYFjCyrGEWLU4uLc9ONjPRS izKTi4vz8/TyUks2MQJj4eCW31Y7GA8+dzzEKMDBqMTD+/7jsWgh1sSy4srcQ4wSHMxKIryZ i4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1KzU1MLUotgskwcnFINjBbJn2qb TwU//LBBPk/50PU3AfUuuktSOD+X+R/fXcXw3HnSpeV9EpYiFRUijzjlb7o/f5f0mF85mJ/Z Kkv1h+gZcZ4XE+f/Nz6usy449luIxE2p8z5TzK6yJbHMu/3c0Wp36vn2qR5GXxJNJ8/l5mQU 1Pbstpp4XejTwuuqQYLFB+4/u8B/SomlOCPRUIu5qDgRAOsfr1SBAgAA Archived-At: Subject: Re: [Detnet] Tsvart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 08:56:31 -0000 Hi Michael, Thank you very much for the thorough review and good comments! Please find below in-line responses and how we plan to update the draft to resolve your comments. Best regards, Janos On 9/29/2018 12:24 AM, Michael Scharf wrote: > Reviewer: Michael Scharf > Review result: Ready with Issues > > The document "Deterministic Networking Architecture" > (draft-ietf-detnet-architecture-08) defines an overall framework for > Deterministic Networking. > > As TSV-ART reviewer, I believe that this document has issues as > detailed below. > > Michael > > Major issues: > > * It seems that DetNet cannot easily be deployed in the Internet without > additional means. Thus, for a baseline document, one could expect some > explanation on the requirements of deploying DetNet in a network. DetNet is not for the Internet. You are right, it should be clarified. I suggest to extend the fist sentence of the Abstract: OLD: This document provides the overall Architecture for Deterministic Networking (DetNet), which provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to- end delivery latency. NEW: This document provides the overall Architecture for Deterministic Networking (DetNet), which provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to- end delivery latency within a network domain. Change the first paragraph of the Introduction: OLD: This document provides the overall Architecture for Deterministic Networking (DetNet), which provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to- end delivery latency. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 TSN. DetNet accomplishes these goals by dedicating network resources such as link bandwidth and buffer space to DetNet flows and/or classes of DetNet flows, and by replicating packets along multiple paths. Unused reserved resources are available to non-DetNet packets. NEW: This document provides the overall Architecture for Deterministic Networking (DetNet), which provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to- end delivery latency within a network domain. DetNet is for networks that are under a single administrative control or within a closed group of administrative control; these include campus-wide networks and private WANs. DetNet is not for large groups of domains such as the Internet. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 TSN. DetNet accomplishes these goals by dedicating network resources such as link bandwidth and buffer space to DetNet flows and/or classes of DetNet flows, and by replicating packets along multiple paths. Unused reserved resources are available to non-DetNet packets. > DetNet > basically requires support in (almost) all network devices > transporting DetNet > traffic. That assumption should be explicitly spelt out early in the > document, > e.g., in the introduction. Actually, some form of DetNet support is required from each node that transports DetNet traffic. For instance, DetNet flows have to be recognized in order not to spoil their QoS at the minimum. The Introduction could be extended to clarify, e.g., the third paragraph: OLD: A goal of DetNet is a converged network in all respects. That is, the presence of DetNet flows does not preclude non-DetNet flows, and the benefits offered DetNet flows should not, except in extreme cases, prevent existing QoS mechanisms from operating in a normal fashion, subject to the bandwidth required for the DetNet flows. A single source-destination pair can trade both DetNet and non-DetNet flows. End systems and applications need not instantiate special interfaces for DetNet flows. Networks are not restricted to certain topologies; connectivity is not restricted. Any application that generates a data flow that can be usefully characterized as having a maximum bandwidth should be able to take advantage of DetNet, as long as the necessary resources can be reserved. Reservations can be made by the application itself, via network management, by an application’s controller, or by other means, e.g., a dynamic control plane (e.g., [RFC2205]). NEW: A goal of DetNet is a converged network in all respects. That is, the presence of DetNet flows does not preclude non-DetNet flows, and the benefits offered DetNet flows should not, except in extreme cases, prevent existing QoS mechanisms from operating in a normal fashion, subject to the bandwidth required for the DetNet flows. A single source-destination pair can trade both DetNet and non-DetNet flows. End systems and applications need not instantiate special interfaces for DetNet flows. Networks are not restricted to certain topologies; connectivity is not restricted. Any application that generates a data flow that can be usefully characterized as having a maximum bandwidth should be able to take advantage of DetNet, as long as the necessary resources can be reserved. Reservations can be made by the application itself, via network management, by an application’s controller, or by other means, e.g., a dynamic control plane (e.g., [RFC2205]). Network nodes supporting DetNet flows have to implement some of the DetNet capabilities (not necessarily all) in order to treat DetNet flows such that their QoS requirements are met. > There also needs to be an explicit discussion of the > implications if not the whole network is aware of or supports DetNet. > There is > some text in Section 4.2.2 and Section 4.3.3, but I believe additional > explicit > discussion is needed at a prominant place. For instance, can use of > DetNet do > harm to parts of a network not supporting DetNet? As a side note, when > TCPM > published RFC 8257, the following disclaimer was added: "DCTCP, as > described in > this specification, is applicable to deployments in controlled > environments > like data centers, but it must not be deployed over the public > Internet without > additional measures." I wonder if a similar disclaimer is needed for > DetNet. If > there is an implicit assumption that DetNet will be used in homogenous > environments with mostly DetNet-aware devices within the same > organization, > such an assumption should be made explicit. I think the suggested changes to the Abstract and the Introduction make it clear. > * It is surprising that there is hardly any discussion on network > robustness > and safety; this probably also relates to security. For instance, > misconfiguration or errors of functions performing packet replication > could > severely and permantly congest a network and cause harm. How does the > DetNet > architecture ensure that a network stays fully operational e.g. if the > topology > changes or there are equipment failures? Probably this can be solved by > implementations (e.g., dynamic control plane), but why are corresponding > requirements not spelt out? Section 3.3.2 speculates that filters and > policers > can help, and that may be true, but that probably still assumes > consistently > and correctly configured (and well-behaving) devices. And Section 3.3.2 is > vague and mentions a "infinite variety of possible failures" without > stating > any requirements or recommendations. There may be further solutions, > such as > circuit breakers and the like. Why are such topics not discussed? Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security. Reference to the  DetNet Security draft will be added. There will be a document dedicated to Operations, Administration and Maintenance (OAM), which will address operational, misconfiguration, and failure detection issues. The topology changes have to be solved by the control plane, either centralized or distributed. The filters and policers described in Section 3.3.2 also provide robustness by eliminating/mitigating traffic coming from malfunctioning devices. RFC2475 is recommended for traffic policing functions to increase robustness. The text  in Section 3.3.2 could be made clearer, e.g., by updating the first paragraph to: OLD: One key to building robust real-time systems is to reduce the infinite variety of possible failures to a number that can be analyzed with reasonable confidence. DetNet aids in the process by allowing for filters and policers to detect DetNet packets received on the wrong interface, or at the wrong time, or in too great a volume, and to then take actions such as discarding the offending packet, shutting down the offending DetNet flow, or shutting down the offending interface. NEW: Robust real-time systems require to reduce the number of possible failures. Filters and policers should be used in a DetNet network to detect if DetNet packets are received on the wrong interface, or at the wrong time, or in too great volume. Furthermore, filters and policers can take action to discard offending packets or flows, or trigger shutting down the offending DetNet flow, or shutting down the offending interface. > * Somewhat related, the document only looks at impact of failures to > the QoS of > DetNet traffic. What is missing is a discussion how to protect > non-DetNet parts > of a network from any harm caused by DetNet mechanisms. Solutions to this > probably exist. But why is the impact on non-DetNet traffic (e.g., in > case of > topology changes or failures of DetNet functions) not discussed at all > in the > document? Actually the regulation of DetNet traffic by polices and filters protects both other DetNet traffic and non-DetNet traffic. Section 3.3.1 could be extended to make it clear, e.g., by extending the last paragraph: OLD: Ideally, the net effect of the presence of DetNet flows in a network on the non-DetNet packets is primarily a reduction in the available bandwidth. NEW: Traffic policing functions (e.g. [RFC2475]) are used to avoid the starvation of non-DetNet traffic. Thus, the net effect of the presence of DetNet flows in a network on non-DetNet flows is primarily a reduction in the available bandwidth. > * Regarding security, an architecture like DetNet probably requires > that only > authenticated and authorized end systems have access to the data > plane. The > security considerations only briefly mention the control aspect ("the > authentication and authorization of the controlling systems"). Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security. Reference to the DetNet Security draft will be added. > * For an architecture document, the lack of clarity and consistency > regarding > terminology is concerning. This specifically applies to the case of > incomplete > networks (as per Section 4.2.2 and 4.3.3) that include "DetNet-unaware > nodes". > The document introduces terms such as "DetNet intermediate nodes" but then > repeatedly uses generic terms such as "node" or "hop" that may include > DetNet-unaware nodes. For instance, for incomplete networks, a > sentence such as > "The primary means by which DetNet achieves its QoS assurances is to > reduce, or > even completely eliminate, congestion within a node as a cause of > packet loss" > seems to only apply to "DetNet transit nodes" but not "DetNet-unaware > nodes". > Similar ambiguity exist for other use of the terms "hop" and "node", > which may > or may not include DetNet-unaware nodes. It is unclear why the > document does > not consistently use the terminology introduced in Section 2.1 in all > sections > and clearly distinguishes cases with and without DetNet support. Each occurrence of "node" will be checked and updated to make it clear what type of node is meant. Each occurrence of "hop" will be double checked and updated as necessary and possible to make it clear, preferably replaced with the appropriate type of node. Note that, for instance, "Per-Hop Behavior" cannot be changed. > * Section 4.4 refers to RFC 7426, which is an informational RFC on > IRTF stream, > and the document uses the concepts introduced there (e.g., "planes"). > This is > very confusing. First, an IETF Proposed Standard should probably refer to > documents having IETF consensus. An example would be RFC 7491, albeit > there is > other related work as well, e.g., in the TEAS WG. Second, Section 4.4 > is by and > large decoupled from the rest of the document and not specific to DetNet. > Neither do other sections of the document refer to the concepts > introduced in > Section 4.4, nor does Section 4.4 use the DetNet terminology or discuss > applicability to DetNet. Section 4.4 even mentions explicitly at the > end that > it discusses aspects that are orthogonal to the DetNet architecture. > It is not > at all clear why Section 4.4 is in this document. Section 4.4 could be > removed > from the document without impacting the rest of the document. The document should point out to traffic engineering and centralized control plane aspects, so it is better to keep Section 4.4. RFC 7426 provides the full picture of SDN architecture, which needs to be referred from the DetNet architecture. No other RFC provides such detailed picture. Therefore, we need to keep the reference to RFC 7426, which is an informative reference. The related work in TEAS is already referred to. > Minor issues: > > * Terminology "DetNet transport layer" > > The term "transport layer" has a well-defined meaning in the IETF, e.g. > originating from RFC 1122. While "transport" and e.g. "transport > network" is > used in the IETF for different technologies in different areas, I > think the > term "transport layer" is typically understood to refer to transport > protocols such as TCP and UDP. As such, I personally find the term "DetNet > transport layer" misleading and confusing. The confusion is easy to > see e.g. > in Figure 4, where UDP (which is a transport protocol as per RFC 1122) > sits > on top of "transport". > > Based on the document it also may be solution/implementation specific > whether > the "DetNet transport layer" is actually a separate protocol layer > compared > to the "DetNet service layer". Thus it is not clear to me why the word > "layer" has to be used, specifically in combination "transport layer". > > To me as, the word "transport layer" (and "transport protocol") should be > used for protocols defined in TSV area, consistent with RFC 1122. But > this is > probably a question to be sorted out by the IESG. "transport" is used here as in "packet transport networks" not as OSI L4 transport. I suggest to use the terms "DetNet transport sub-layer" and "DetNet service sub-layer" throughout the document, which would hopefully avoid confusion. For instance, in 4.1.2 below Figure 3: OLD: Distinguishing the function of two DetNet data plane layers, the DetNet service layer and the DetNet transport layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4. This separation of DetNet layers, while helpful, should not be considered as formal requirement. For example, some technologies may violate these strict layers and still be able to deliver a DetNet service. NEW: Distinguishing the function of two DetNet data plane layers, the DetNet service sub-layer and the DetNet transport sub-layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4. This separation of DetNet data plane layers, while helpful, should not be considered as formal requirement. For example, some technologies may violate these strict layers and still be able to deliver a DetNet service. > * Page 9 > > A DetNet node may have other resources requiring allocation and/or > scheduling, > > This is just one of several examples for inconsistent use of terminology. > What is a "DetNet node"? That term is not introduced in Section 2.1 DetNet node is an umbrella term when it is not needed to specify which type of DetNet node is mentioned. A definition will be added: DetNet node    A DetNet intermediate node, a DetNet edge node, a DetNet relay node, or a DetNet transport node. > * Page 14 > > A DetNet network supports the dedication of a high proportion (e.g. > 75%) of the network bandwidth to DetNet flows. > > The 75% value is not reasoned. What prevents using 99% of the > bandwidth for > DetNet traffic? The point is that even the majority of the flows can be DetNet flows not just a minority. The example will be deleted: OLD: A DetNet network supports the dedication of a high proportion (e.g. 75%) of the network bandwidth to DetNet flows. NEW: A DetNet network supports the dedication of a high proportion of  the network bandwidth to DetNet flows. > * Page 15: Figure 2 > > If the term "transport layer" cannot be avoided, the labels in this figure > should at least be expanded to "DetNet transport layer". Suggest to use "DetNet transport sub-layer" as described above. > * Page 18: Figure 4 > > As already mentioned earlier, Figure 4 is confusing. UDP is a transport > protocol. If the term "transport" cannot be avoided, the labels in this > figure should at least be expanded to "DetNet transport". Suggest to use "DetNet transport sub-layer"as described above. > * Page 23 > > If the source transmits less data than this limit > allows, the unused resource such as link bandwidth can be made > available by the system to non-DetNet packets. > > Could there be additional requirements on the use of unused resources by > non-DetNet packets, e.g., regarding preemption? I am just wondering... If > that was possible, a statement like "... can be made available by the > system > to non-DetNet packets as long as all guarantees are fulfilled" would be on > the safe side, no? The text will be updated as suggested, i.e., using: "... can be made available by the system to non-DetNet packets as long as all guarantees are fulfilled" > * Page 27: > > DetNet achieves congestion protection and bounded delivery latency by > reserving bandwidth and buffer resources at every hop along the path > of the DetNet flow. > > Why does this sentence use the word "hop"? As far as I understand, in > DetNet > bandwidth and buffer resources are reserved in each DetNet > intermediate node. > If there were hops over IP routers not being DetNet intermediate nodes, no > resources would be reserved there. As per Section 4.3.3, it is possible to > deploy DetNet this way. And obviously there can be resource > bottlenecks below > IP, on devices that are not routers... So does "hop" here refer to IP > router > hops or also to devices not processing IP (or IP/MPLS)? IP/MPLS is meant as it is in scope of DetNet. The sentence will be updated to OLD: DetNet achieves congestion protection and bounded delivery latency by reserving bandwidth and buffer resources at every hop along the path of the DetNet flow. NEW: DetNet achieves congestion protection and bounded delivery latency by reserving bandwidth and buffer resources at each DetNet node along the path of the DetNet flow. > * Page 27: > > Standard queuing and transmission selection algorithms allow a > central controller to compute the latency contribution of each > transit node to the end-to-end latency, ... > > The text does not explain why a _central_ controller is needed for this > computation. Why would a distributed control plane not be able to realize > this computation. Isn't this implementation-specific? It depends on the mechanism used whether or not a distributed control plane can be used. For instance, IEEE 802.1Qbv requires central control to compute the time-based schedule at each node. As traffic engineering is needed, some entity has to perform the necessary computations, which is typically centralized. It can be a management entity if distributed control is applied. Another aspect is that standard queuing algorithms are needed to be able to do it. To make it clearer, the sentence will be updated to: OLD: Standard queuing and transmission selection algorithms allow a central controller to compute the latency contribution of each transit node to the end-to-end latency, to compute the amount of buffer space required in each transit node for each incremental DetNet flow, and most importantly, to translate from a flow specification to a set of values for the managed objects that control each relay or end system. NEW: Standard queuing and transmission selection algorithms allow traffic engineering (Section 4.4.) to compute the latency contribution of each DetNet node to the end-to-end latency, to compute the amount of buffer space required in each DetNet node for each incremental DetNet flow, and most importantly, to translate from a flow specification to a set of values for the managed objects that control each DetNet relay or end system. > * Page 32 > > To somebody who is not deeply familiar with DetNet, it is impossible > to parse > the description of the examples in Section 4.7.3. For instance, "VID + > multicast MAC address" is not introduced. I think this example must be > expaned with additional context and explanation to be useful to readers. "ETH-ID" is used as generic Ethernet ID, e.g., in the figure. In order to avoid the use of terms not explained in detail, the text will be updated to OLD: End system "IP-A" uses the original App-flow specific ID ("L3-ID"), but as it is connected to an Ethernet domain it has to push an Ethernet-domain specific flow-ID ("VID + multicast MAC address", referred as "ETH-ID") before sending the packet to "ETH-1" node. NEW: End system "IP-A" uses the original App-flow specific ID ("L3-ID"), but as it is connected to an Ethernet domain it has to push an Ethernet-domain specific flow-ID ("ETH-ID") before sending the packet to "ETH-1" node. > * Page 34 > > There are three classes of information that a central controller or > distributed control plane needs to know that can only be obtained > from the end systems and/or nodes in the network. > > Wouldn't it be sufficient to state "Provisioning of DetNet requires > knowledge > about ...". Does it matter in this context whether the provisioning is > done > by a central controller or a distributed control plane? For instance, > could > the same paragraph also apply to a network that uses _multiple_ central > controllers, or hybrid combinations of central controllers and distributed > control planes? In general, an architecture document should be agnostic to > implementation aspects unless there is a specific need. In this specific > case, I fail to see a need to discuss the realization of the control > plane of > a network. The text will be updated as suggested: OLD: There are three classes of information that a central controller or distributed control plane needs to know that can only be obtained from the end systems and/or nodes in the network. When using a peerto- peer control plane, some of this information may be required by a system’s neighbors in the network. o Details of the system’s capabilities ... NEW: Provisioning of DetNet requires knowledge about: o Details of the system’s capabilities ... > Editorial nits: > > * Page 9: > > The low-level mechanisms described in Section 4.5 provide the > necessary regulation of transmissions by an end system or > intermediate node to provide congestion protection. The allocation > of the bandwidth and buffers for a DetNet flow requires provisioning > A DetNet node may have other resources requiring allocation and/or > scheduling, that might otherwise be over-subscribed and trigger the > rejection of a reservation. > > Probably a full stop is missing after "provisioning". Full stop will be added. > * Page 11: "... along separate (disjoint non-SRLG) paths ..." > > I find this confusing. I would understand e.g. "along separate > (SRLG-disjoint) paths". The text will be updated as suggested. > * Page 34: > > When using a peer- > to-peer control plane, some of this information may be required by a > system's neighbors in the network. > > Would "acquired" be a better term? This text goes away with the update to "Provisioning of DetNet requires knowledge about" > * Page 34: > > o The identity of the system's neighbors, and the characteristics of > the link(s) between the systems, including the length (in > nanoseconds) of the link(s). > > "Latency" or "delay" would probably be a better terms if the value is > measured in nanoseconds. the text will be updated to: OLD: The identity of the system’s neighbors, and the characteristics of the link(s) between the systems, including the length (in nanoseconds) of the link(s). NEW: The identity of the system’s neighbors, and the characteristics of the link(s) between the systems, including the latency of the link(s) (in nanoseconds) . > * Page 35: > > DetNet is provides a Quality of Service (QoS), and as such, does not > directly raise any new privacy considerations. > > Broken sentence "is" will be deleted > * Please expand acronyms on first use (e.g., OTN) > acronyms will be resolved at first occurrence From nobody Wed Oct 17 02:57:04 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4555012DD85 for ; Wed, 17 Oct 2018 02:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFaSRohD1_9U for ; Wed, 17 Oct 2018 02:56:59 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F5312D4EA for ; Wed, 17 Oct 2018 02:56:59 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.168.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4BB48180121E; Wed, 17 Oct 2018 11:56:56 +0200 (CEST) To: "Grossman, Ethan A." Cc: "detnet@ietf.org" References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> From: Loa Andersson Message-ID: <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> Date: Wed, 17 Oct 2018 17:56:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 09:57:02 -0000 Ethan, Working Group, I don't think there is a one size fits all approach possible for the Security Considerations in all DetNet documents. My understanding is that the Security Directorate and Security ADs require that each document have an independent treatment of the specific threats and concerns for a particular document. Whatever strategy we decide on, please make sure that it is agreed on by the Security ADs and Directorate. /Loa On 2018-10-17 15:54, Grossman, Ethan A. wrote: > Hi Loa, > Various strategies are possible. One possibility is that the other drafts (i.e. not the Security draft) could just point at the Security draft such that there would be a "single clearing house" for DetNet-specific security info. That's what the Use Cases draft does, however there is also some security-related text in the various use cases. > > At one point I (as Security draft editor) attempted to bring together all of the security-related text from the various other drafts by copying it all into an appendix of the Security draft, since it is sort of handy to have it all in one place. But as Lou pointed out to me, we don't want to make the drafts dependent on each other if we can avoid it, and if such text got edited then it would have to be fixed in two places, so it isn't a perfect scheme. I would say that if a draft author wants to write their own security-related text in their own draft more power to them, but perhaps even more power if they bring it to the Security draft :- ) > > Sorry long answer to a short question. And I'm sure there are other strategies... If you have any thoughts on the matter I'd love to hear them, either on the list or at IETF 103. > Ethan. > > -----Original Message----- > From: Loa Andersson > Sent: Wednesday, October 17, 2018 12:10 AM > To: Grossman, Ethan A. > Cc: detnet@ietf.org > Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt > > Ethan, > > I have just had a quick look, but what I see looks good, and certainly gives a good overview of the detnet security issues. > > One question, is it the intention that this document should be used as a general reference when writing security considerations for detnet documents? > > /Loa > > On 2018-10-17 12:05, Grossman, Ethan A. wrote: >> Hi All, >> This note is the status update for the DetNet Security Considerations draft in advance of IETF 103, in lieu of a presentation slot for it at IETF 103. >> >> A new version has been posted which includes the discussion on OAM traffic and incorporates the "Bounded Jitter" Use Case Common Theme. >> >> These are minor changes; no substantial work has been done since the last DetNet session, so we do not plan to have a slot for this draft at the IETF 103 DetNet session (though Tal will be presenting on it at the DetNet-TSN meeting on the following Sunday). >> >> I expect that we will convene as many of the authors (and any other interested parties) as we have available at IETF 103 to discuss DetNet-data-plane-technology-specific security considerations and how to incorporate them into the draft as our next steps. If you would like to participate in (be notified about) this conversation, please let me know. >> >> Best, >> Ethan (as DetNet Security Considerations draft editor) >> >> -----Original Message----- >> From: detnet On Behalf Of >> internet-drafts@ietf.org >> Sent: Tuesday, October 16, 2018 8:51 PM >> To: i-d-announce@ietf.org >> Cc: detnet@ietf.org >> Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Deterministic Networking WG of the IETF. >> >> Title : Deterministic Networking (DetNet) Security Considerations >> Authors : Tal Mizrahi >> Ethan Grossman >> Andrew J. Hacker >> Subir Das >> John Dowdell >> Henrik Austad >> Kevin Stanton >> Norman Finn >> Filename : draft-ietf-detnet-security-03.txt >> Pages : 40 >> Date : 2018-10-16 >> >> Abstract: >> A deterministic network is one that can carry data flows for real- >> time applications with extremely low data loss rates and bounded >> latency. Deterministic networks have been successfully deployed in >> real-time operational technology (OT) applications for some years >> (for example [ARINC664P7]). However, such networks are typically >> isolated from external access, and thus the security threat from >> external attackers is low. IETF Deterministic Networking (DetNet) >> specifies a set of technologies that enable creation of deterministic >> networks on IP-based networks of potentially wide area (on the scale >> of a corporate network) potentially bringing the OT network into >> contact with Information Technology (IT) traffic and security threats >> that lie outside of a tightly controlled and bounded area (such as >> the internals of an aircraft). These DetNet technologies have not >> previously been deployed together on a wide area IP-based network, >> and thus can present security considerations that may be new to IP- >> based wide area network designers. This draft, intended for use by >> DetNet network designers, provides insight into these security >> considerations. In addition, this draft collects all security- >> related statements from the various DetNet drafts (Architecture, Use >> Cases, etc) into a single location Section 7. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-detnet-security-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03 >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Oct 17 10:19:05 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376A6130DF2 for ; Wed, 17 Oct 2018 10:19:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2cbYmb9frSZ for ; Wed, 17 Oct 2018 10:18:59 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.104]) (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 9A987130E1D for ; Wed, 17 Oct 2018 10:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ub0eHMDWr/2qpU4sPo5btcg2DW12XcihUnJ0hZHT/Dg=; b=WCsN/e5TMBcbwUR/sHnizYIPZD1nPBy0mvfVcwBZuBplo3cL3upoIbrP7ng6ncL4m2dqc5/b9D+SANfRlHkI4xY6uOYmqnNYuIFqXgIi2rxp3q/3WWV7aOQL0YVDwUO9oNCKhoTItdAtEgZ5TV3ZRxyyDQXU/aXK57cYaj4PtIo= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4658.namprd06.prod.outlook.com (52.132.15.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Wed, 17 Oct 2018 17:18:56 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.027; Wed, 17 Oct 2018 17:18:56 +0000 From: "Grossman, Ethan A." To: Loa Andersson , Lou Berger , Deborah Brungard CC: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQgAA3NYCAAAlfoIAAJVkAgAB5JdA= Date: Wed, 17 Oct 2018 17:18:56 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> In-Reply-To: <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4658; 6:l7F5hR+dq+sY9e4A/QJxBdQiVPI1vzSnPRpJLQf+mjXYRrtVN69Qxa6rrUrJZm5Klqv7FXqr66Cc8WBseWz6QfQ1NPJcA7V1G30pnKd8Y3kTDb/9nRBSEU3MscIWXy60cA76BSx1iQ+eyR8nBD5ZxoHVBAvysuiAEeI6mD0gtrvDODi+yePIa/YBW8jk29O9H7M7duXtvYpYFWb0QF3wYwI5StlBPUOFzYxu77SWfA0l1zIHGp/QIVQhMenStJo1U4vIlLw6H9IfkLlNj5iYkL/OUW7S79EJicknX8+sPUhV+Kx+79s3OZPGvM97UT4vk11RZJsG4u3utKLxlEnBId1DCBBSqphDfiu71XCfxWeEMib+HHQqRM6T3bqdXXncex7k//1wyPa1OwjLT6SI66PVVUoLTZ53xG2DTD11NSGqOcolMqImIyg2OX+NEuOCnNkDfHarEhhoY0gqNfsW8w==; 5:nWjAeZbY36Bu5qzgHsZx7Ay7DFy/Fv1DF4UgxCibfrtNIO6mIcnjCFlJHrsUmygmYKXYUCTKXIuqdaSgEgHqorzqEYpg5TRtlQLuQV7fiSIuK+HwqhiDqXorJlJUUzRdlMIqTVWSK/niLn28MeMkq2IN7v9qzli9iklzbbnsplM=; 7:COuYJ6dHlMAe2kJYYJ59IrFuTkz/YBiKIiR9VS5Hy2i4igJ5HeLlj43pAcqT3+T0s2AFAobuEX9tfIM/hlrWKn/yZvS5GYWKEIElzzD2/dhK2KcV8MMVhafbfPCJDv64udYo/96hGCE0alOlTbRy0sr/DkKL7AYIJc+fvE4VSK72pFxA2m+M4oFn9KfpH8s67SNYukI+BW1/V0OxqVPRdpJK8QP5/JSOTYhV3IbKJhWMdjMMv1ZaSKD069l76UPj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ec7305dc-e91a-4d67-c3b3-08d634549eb9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4658; x-ms-traffictypediagnostic: BL0PR06MB4658: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4658; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4658; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(376002)(366004)(396003)(53754006)(199004)(189003)(252514010)(13464003)(15650500001)(93886005)(14444005)(6116002)(3846002)(99286004)(6246003)(316002)(86362001)(2900100001)(229853002)(25786009)(5660300001)(186003)(66066001)(8936002)(110136005)(26005)(4326008)(256004)(486006)(4001150100001)(305945005)(7736002)(102836004)(74316002)(53546011)(33656002)(7696005)(76176011)(2906002)(71200400001)(71190400001)(9686003)(6436002)(446003)(6506007)(6306002)(81156014)(105586002)(106356001)(11346002)(476003)(81166006)(8676002)(14454004)(966005)(478600001)(55016002)(68736007)(53936002)(97736004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4658; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: i+FW5omajJKkGQxMB7SNtA7Po9c/RBVTyjeGNA7V2qvVL4iY0OeA5JbIN7yjtIY15RhHhTUiWUNGuwV7MfW46VKCgplTjBhRri6G4JB6+oLEgz2RJx+RydIG5JgF6WBhZDnrUQBL4L86rD52yHryPsMha34KRnHi8QriYMFm/3n+ig275+8wx19Znkn4y8sAkdAqxCecYDlSlsMFqJraFHDtb7hN9xzwFBRhEnHH+rEIKezIdVWq6RDfH8mr/7dI1TCWK0xdbmkQ9hzcW1Y1FnTd7+tOadA33b02fMKOdKSaSxJ/2h8C738WYkXHytS6sfGWrC3jj3UIXdkV3fgM+XwBCLS6fysfqT0PJZV9KII= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec7305dc-e91a-4d67-c3b3-08d634549eb9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 17:18:56.3052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4658 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 17:19:03 -0000 VGhhbmtzIExvYSAoYWRkaW5nIExvdSBhbmQgRGVib3JhaCkuIA0KDQpTbyBmYXIsIHRoZSByZXZp ZXdlcnMgb2YgdGhlIGxhc3QgVXNlIENhc2VzIGRyYWZ0IGhhdmUgc2FpZCAiSGV5IHdoZXJlJ3Mg dGhlIFNlY3VyaXR5IHNlY3Rpb24/IiBhbmQgTG91IGFuZCBJIGFkZGVkIGEgU2VjdXJpdHkgc2Vj dGlvbiB0aGF0IHBvaW50cyB0aGVtIGF0IHRoZSBTZWN1cml0eSBkcmFmdCwgYW5kIHRoZXkgc2Vl bWVkIHRvIGJlIE9LIHdpdGggdGhhdC4gSSBkb24ndCBrbm93IGlmIHRoYXQgd291bGQgYmUgdGhl IGNhc2UgZm9yIG91ciBvdGhlciBkcmFmdHMuICANCg0KSSB3b3VsZCB2ZXJ5IG11Y2ggbGlrZSB0 byBoYXZlIHRoaXMgY29udmVyc2F0aW9uIHdpdGggdGhlIFNlY3VyaXR5IEFEJ3MgYW5kIERpcmVj dG9yYXRlOyBhdCBwcmVzZW50LCBJIHBlcnNvbmFsbHkgZG9uJ3Qga25vdyB0aGUgbW9zdCBhcHBy b3ByaWF0ZSBpbmRpdmlkdWFscyB0byBlbmdhZ2Ugd2l0aCBvbiB0aGlzIHRvcGljIC0gaWYgb25l IG9mIHknYWxsIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBtZSBzb21lIGtpbmQgb2YgaW50cm9kdWN0 aW9uLCBJJ20gaGFwcHkgdG8gdHJ5IHRvIGRyaXZlIHNvbWUgcmVzb2x1dGlvbiBvbiBvdXIgc3Ry YXRlZ3kgaGVyZSwgZWl0aGVyIG9uIHRoZSBsaXN0IG9yIGluIEJhbmdrb2suIA0KDQpFdGhhbi4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvYSBBbmRlcnNzb24gPGxvYUBw aS5udT4gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTggMjo1NyBBTQ0KVG86IEdy b3NzbWFuLCBFdGhhbiBBLiA8ZWFncm9zQGRvbGJ5LmNvbT4NCkNjOiBkZXRuZXRAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRldG5ldC1zZWN1 cml0eS0wMy50eHQNCg0KRXRoYW4sIFdvcmtpbmcgR3JvdXAsDQoNCkkgZG9uJ3QgdGhpbmsgdGhl cmUgaXMgYSBvbmUgc2l6ZSBmaXRzIGFsbCBhcHByb2FjaCBwb3NzaWJsZSBmb3IgdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIGluIGFsbCBEZXROZXQgZG9jdW1lbnRzLiBNeSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgdGhlIFNlY3VyaXR5IERpcmVjdG9yYXRlIGFuZCBTZWN1cml0eSBBRHMgcmVx dWlyZSB0aGF0IGVhY2ggZG9jdW1lbnQgaGF2ZSBhbiBpbmRlcGVuZGVudCB0cmVhdG1lbnQgb2Yg dGhlIHNwZWNpZmljIHRocmVhdHMgYW5kIGNvbmNlcm5zIGZvciBhIHBhcnRpY3VsYXIgZG9jdW1l bnQuDQoNCldoYXRldmVyIHN0cmF0ZWd5IHdlIGRlY2lkZSBvbiwgcGxlYXNlIG1ha2Ugc3VyZSB0 aGF0IGl0IGlzIGFncmVlZCBvbiBieSB0aGUgU2VjdXJpdHkgQURzIGFuZCBEaXJlY3RvcmF0ZS4N Cg0KL0xvYQ0KDQpPbiAyMDE4LTEwLTE3IDE1OjU0LCBHcm9zc21hbiwgRXRoYW4gQS4gd3JvdGU6 DQo+IEhpIExvYSwNCj4gVmFyaW91cyBzdHJhdGVnaWVzIGFyZSBwb3NzaWJsZS4gT25lIHBvc3Np YmlsaXR5IGlzIHRoYXQgdGhlIG90aGVyIGRyYWZ0cyAoaS5lLiBub3QgdGhlIFNlY3VyaXR5IGRy YWZ0KSBjb3VsZCBqdXN0IHBvaW50IGF0IHRoZSBTZWN1cml0eSBkcmFmdCBzdWNoIHRoYXQgdGhl cmUgd291bGQgYmUgYSAic2luZ2xlIGNsZWFyaW5nIGhvdXNlIiBmb3IgRGV0TmV0LXNwZWNpZmlj IHNlY3VyaXR5IGluZm8uICBUaGF0J3Mgd2hhdCB0aGUgVXNlIENhc2VzIGRyYWZ0IGRvZXMsIGhv d2V2ZXIgdGhlcmUgaXMgYWxzbyBzb21lIHNlY3VyaXR5LXJlbGF0ZWQgdGV4dCBpbiB0aGUgdmFy aW91cyB1c2UgY2FzZXMuDQo+IA0KPiBBdCBvbmUgcG9pbnQgSSAoYXMgU2VjdXJpdHkgZHJhZnQg ZWRpdG9yKSBhdHRlbXB0ZWQgdG8gYnJpbmcgdG9nZXRoZXIgDQo+IGFsbCBvZiB0aGUgc2VjdXJp dHktcmVsYXRlZCB0ZXh0IGZyb20gdGhlIHZhcmlvdXMgb3RoZXIgZHJhZnRzIGJ5IA0KPiBjb3B5 aW5nIGl0IGFsbCBpbnRvIGFuIGFwcGVuZGl4IG9mIHRoZSBTZWN1cml0eSBkcmFmdCwgc2luY2Ug aXQgaXMgDQo+IHNvcnQgb2YgaGFuZHkgdG8gaGF2ZSBpdCBhbGwgaW4gb25lIHBsYWNlLiBCdXQg YXMgTG91IHBvaW50ZWQgb3V0IHRvIA0KPiBtZSwgd2UgZG9uJ3Qgd2FudCB0byBtYWtlIHRoZSBk cmFmdHMgZGVwZW5kZW50IG9uIGVhY2ggb3RoZXIgaWYgd2UgY2FuIA0KPiBhdm9pZCBpdCwgYW5k IGlmIHN1Y2ggdGV4dCBnb3QgZWRpdGVkIHRoZW4gaXQgd291bGQgaGF2ZSB0byBiZSBmaXhlZCAN Cj4gaW4gdHdvIHBsYWNlcywgc28gaXQgaXNuJ3QgYSBwZXJmZWN0IHNjaGVtZS4gSSB3b3VsZCBz YXkgdGhhdCBpZiBhIA0KPiBkcmFmdCBhdXRob3Igd2FudHMgdG8gd3JpdGUgdGhlaXIgb3duIHNl Y3VyaXR5LXJlbGF0ZWQgdGV4dCBpbiB0aGVpciANCj4gb3duIGRyYWZ0IG1vcmUgcG93ZXIgdG8g dGhlbSwgYnV0IHBlcmhhcHMgZXZlbiBtb3JlIHBvd2VyIGlmIHRoZXkgDQo+IGJyaW5nIGl0IHRv IHRoZSBTZWN1cml0eSBkcmFmdCA6LSApDQo+IA0KPiBTb3JyeSBsb25nIGFuc3dlciB0byBhIHNo b3J0IHF1ZXN0aW9uLiBBbmQgSSdtIHN1cmUgdGhlcmUgYXJlIG90aGVyIHN0cmF0ZWdpZXMuLi4g SWYgeW91IGhhdmUgYW55IHRob3VnaHRzIG9uIHRoZSBtYXR0ZXIgSSdkIGxvdmUgdG8gaGVhciB0 aGVtLCBlaXRoZXIgb24gdGhlIGxpc3Qgb3IgYXQgSUVURiAxMDMuDQo+IEV0aGFuLg0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51Pg0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTggMTI6MTAgQU0NCj4gVG86 IEdyb3NzbWFuLCBFdGhhbiBBLiA8ZWFncm9zQGRvbGJ5LmNvbT4NCj4gQ2M6IGRldG5ldEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW0RldG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRu ZXQtc2VjdXJpdHktMDMudHh0DQo+IA0KPiBFdGhhbiwNCj4gDQo+IEkgaGF2ZSBqdXN0IGhhZCBh IHF1aWNrIGxvb2ssIGJ1dCB3aGF0IEkgc2VlIGxvb2tzIGdvb2QsIGFuZCBjZXJ0YWlubHkgZ2l2 ZXMgYSBnb29kIG92ZXJ2aWV3IG9mIHRoZSBkZXRuZXQgc2VjdXJpdHkgaXNzdWVzLg0KPiANCj4g T25lIHF1ZXN0aW9uLCBpcyBpdCB0aGUgaW50ZW50aW9uIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91 bGQgYmUgdXNlZCBhcyBhIGdlbmVyYWwgcmVmZXJlbmNlIHdoZW4gd3JpdGluZyBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBmb3IgZGV0bmV0IGRvY3VtZW50cz8NCj4gDQo+IC9Mb2ENCj4gDQo+IE9u IDIwMTgtMTAtMTcgMTI6MDUsIEdyb3NzbWFuLCBFdGhhbiBBLiB3cm90ZToNCj4+IEhpIEFsbCwN Cj4+IFRoaXMgbm90ZSBpcyB0aGUgc3RhdHVzIHVwZGF0ZSBmb3IgdGhlIERldE5ldCBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyBkcmFmdCBpbiBhZHZhbmNlIG9mIElFVEYgMTAzLCBpbiBsaWV1IG9m IGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIGl0IGF0IElFVEYgMTAzLg0KPj4NCj4+IEEgbmV3IHZl cnNpb24gaGFzIGJlZW4gcG9zdGVkIHdoaWNoIGluY2x1ZGVzIHRoZSBkaXNjdXNzaW9uIG9uIE9B TSB0cmFmZmljIGFuZCBpbmNvcnBvcmF0ZXMgdGhlICJCb3VuZGVkIEppdHRlciIgVXNlIENhc2Ug Q29tbW9uIFRoZW1lLg0KPj4NCj4+IFRoZXNlIGFyZSBtaW5vciBjaGFuZ2VzOyBubyBzdWJzdGFu dGlhbCB3b3JrIGhhcyBiZWVuIGRvbmUgc2luY2UgdGhlIGxhc3QgRGV0TmV0IHNlc3Npb24sIHNv IHdlIGRvIG5vdCBwbGFuIHRvIGhhdmUgYSBzbG90IGZvciB0aGlzIGRyYWZ0IGF0IHRoZSBJRVRG IDEwMyBEZXROZXQgc2Vzc2lvbiAodGhvdWdoIFRhbCB3aWxsIGJlIHByZXNlbnRpbmcgb24gaXQg YXQgdGhlIERldE5ldC1UU04gbWVldGluZyBvbiB0aGUgZm9sbG93aW5nIFN1bmRheSkuDQo+Pg0K Pj4gSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGNvbnZlbmUgYXMgbWFueSBvZiB0aGUgYXV0aG9ycyAo YW5kIGFueSBvdGhlciBpbnRlcmVzdGVkIHBhcnRpZXMpIGFzIHdlIGhhdmUgYXZhaWxhYmxlIGF0 IElFVEYgMTAzIHRvIGRpc2N1c3MgRGV0TmV0LWRhdGEtcGxhbmUtdGVjaG5vbG9neS1zcGVjaWZp YyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgaG93IHRvIGluY29ycG9yYXRlIHRoZW0gaW50 byB0aGUgZHJhZnQgYXMgb3VyIG5leHQgc3RlcHMuIElmIHlvdSB3b3VsZCBsaWtlIHRvIHBhcnRp Y2lwYXRlIGluIChiZSBub3RpZmllZCBhYm91dCkgdGhpcyBjb252ZXJzYXRpb24sIHBsZWFzZSBs ZXQgbWUga25vdy4NCj4+DQo+PiBCZXN0LA0KPj4gRXRoYW4gKGFzIERldE5ldCBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBkcmFmdCBlZGl0b3IpDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IGRldG5ldCA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiANCj4+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4gU2VudDogVHVlc2RheSwgT2N0 b2JlciAxNiwgMjAxOCA4OjUxIFBNDQo+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+PiBD YzogZGV0bmV0QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMy50eHQNCj4+DQo+Pg0KPj4gQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KPj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRGV0ZXJtaW5pc3Rp YyBOZXR3b3JraW5nIFdHIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAgICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMNCj4+ICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBUYWwgTWl6cmFoaQ0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV0aGFuIEdyb3NzbWFuDQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQW5kcmV3IEouIEhhY2tlcg0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFN1YmlyIERhcw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4g RG93ZGVsbA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhlbnJpayBBdXN0YWQNCj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLZXZpbiBTdGFudG9uDQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTm9ybWFuIEZpbm4NCj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMy50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiA0MA0K Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTgtMTAtMTYNCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAg ICAgQSBkZXRlcm1pbmlzdGljIG5ldHdvcmsgaXMgb25lIHRoYXQgY2FuIGNhcnJ5IGRhdGEgZmxv d3MgZm9yIHJlYWwtDQo+PiAgICAgIHRpbWUgYXBwbGljYXRpb25zIHdpdGggZXh0cmVtZWx5IGxv dyBkYXRhIGxvc3MgcmF0ZXMgYW5kIGJvdW5kZWQNCj4+ICAgICAgbGF0ZW5jeS4gIERldGVybWlu aXN0aWMgbmV0d29ya3MgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBkZXBsb3llZCBpbg0KPj4gICAg ICByZWFsLXRpbWUgb3BlcmF0aW9uYWwgdGVjaG5vbG9neSAoT1QpIGFwcGxpY2F0aW9ucyBmb3Ig c29tZSB5ZWFycw0KPj4gICAgICAoZm9yIGV4YW1wbGUgW0FSSU5DNjY0UDddKS4gIEhvd2V2ZXIs IHN1Y2ggbmV0d29ya3MgYXJlIHR5cGljYWxseQ0KPj4gICAgICBpc29sYXRlZCBmcm9tIGV4dGVy bmFsIGFjY2VzcywgYW5kIHRodXMgdGhlIHNlY3VyaXR5IHRocmVhdCBmcm9tDQo+PiAgICAgIGV4 dGVybmFsIGF0dGFja2VycyBpcyBsb3cuICBJRVRGIERldGVybWluaXN0aWMgTmV0d29ya2luZyAo RGV0TmV0KQ0KPj4gICAgICBzcGVjaWZpZXMgYSBzZXQgb2YgdGVjaG5vbG9naWVzIHRoYXQgZW5h YmxlIGNyZWF0aW9uIG9mIGRldGVybWluaXN0aWMNCj4+ICAgICAgbmV0d29ya3Mgb24gSVAtYmFz ZWQgbmV0d29ya3Mgb2YgcG90ZW50aWFsbHkgd2lkZSBhcmVhIChvbiB0aGUgc2NhbGUNCj4+ICAg ICAgb2YgYSBjb3Jwb3JhdGUgbmV0d29yaykgcG90ZW50aWFsbHkgYnJpbmdpbmcgdGhlIE9UIG5l dHdvcmsgaW50bw0KPj4gICAgICBjb250YWN0IHdpdGggSW5mb3JtYXRpb24gVGVjaG5vbG9neSAo SVQpIHRyYWZmaWMgYW5kIHNlY3VyaXR5IHRocmVhdHMNCj4+ICAgICAgdGhhdCBsaWUgb3V0c2lk ZSBvZiBhIHRpZ2h0bHkgY29udHJvbGxlZCBhbmQgYm91bmRlZCBhcmVhIChzdWNoIGFzDQo+PiAg ICAgIHRoZSBpbnRlcm5hbHMgb2YgYW4gYWlyY3JhZnQpLiAgVGhlc2UgRGV0TmV0IHRlY2hub2xv Z2llcyBoYXZlIG5vdA0KPj4gICAgICBwcmV2aW91c2x5IGJlZW4gZGVwbG95ZWQgdG9nZXRoZXIg b24gYSB3aWRlIGFyZWEgSVAtYmFzZWQgbmV0d29yaywNCj4+ICAgICAgYW5kIHRodXMgY2FuIHBy ZXNlbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhhdCBtYXkgYmUgbmV3IHRvIElQLQ0KPj4g ICAgICBiYXNlZCB3aWRlIGFyZWEgbmV0d29yayBkZXNpZ25lcnMuICBUaGlzIGRyYWZ0LCBpbnRl bmRlZCBmb3IgdXNlIGJ5DQo+PiAgICAgIERldE5ldCBuZXR3b3JrIGRlc2lnbmVycywgcHJvdmlk ZXMgaW5zaWdodCBpbnRvIHRoZXNlIHNlY3VyaXR5DQo+PiAgICAgIGNvbnNpZGVyYXRpb25zLiAg SW4gYWRkaXRpb24sIHRoaXMgZHJhZnQgY29sbGVjdHMgYWxsIHNlY3VyaXR5LQ0KPj4gICAgICBy ZWxhdGVkIHN0YXRlbWVudHMgZnJvbSB0aGUgdmFyaW91cyBEZXROZXQgZHJhZnRzIChBcmNoaXRl Y3R1cmUsIFVzZQ0KPj4gICAgICBDYXNlcywgZXRjKSBpbnRvIGEgc2luZ2xlIGxvY2F0aW9uIFNl Y3Rpb24gNy4NCj4+DQo+Pg0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWRldG5ldC1zZWN1cml0eS8NCj4+DQo+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMNCj4+DQo+PiBBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMNCj4+ DQo+Pg0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+ IGRldG5ldEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kZXRuZXQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPj4gZGV0bmV0QGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPj4NCj4gDQoNCi0t IA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBp Lm51DQpTZW5pb3IgTVBMUyBFeHBlcnQNCkJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAg ICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K From nobody Wed Oct 17 11:17:29 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECBE130DC7 for ; Wed, 17 Oct 2018 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4990Pjrx06N for ; Wed, 17 Oct 2018 11:17:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 76D291293FB for ; Wed, 17 Oct 2018 11:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539800242; x=1542392242; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hHDh4Ix+l+VaaM/BV7qq1+aQx66pyp28A/D9x2GI3ws=; b=PB9XaRNTvSdKL2qF2x0R8RdofObEF/0IbsFfqLnC4ds4NGElO98eDEDhXpvYHejO o4Wki3JZ7B0nTWP8zW8tsJeNnRmGqeybRMWMKGngvxrSIfn4PPpxfhP7yiPVDt2d +LJ+kqpZvgh1nnKC6OA+rW2N11jcrc7b+896sjbwPv0=; X-AuditID: c1b4fb25-a0b8c9e0000018b4-fd-5bc77cb2e510 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.1A.06324.2BC77CB5; Wed, 17 Oct 2018 20:17:22 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 17 Oct 2018 20:17:08 +0200 Received: from [100.94.48.146] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.188) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 17 Oct 2018 20:17:08 +0200 To: DetNet WG References: <2d6d8f85-a283-eb43-6bea-323b7af661f2@ericsson.com> <3DF0466E9510274382F5B74499ACD6F8D38234@DFWPML704-CHM.exmail.huawei.com> <37d1fcb7-110c-5ec9-99b6-3269cc5ac76d@labn.net> <3DF0466E9510274382F5B74499ACD6F8D38291@DFWPML704-CHM.exmail.huawei.com> <3719f94c-55fa-1f7f-316d-e2a62f2a3e56@labn.net> <3DF0466E9510274382F5B74499ACD6F8D38506@DFWPML704-CHM.exmail.huawei.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Wed, 17 Oct 2018 20:17:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8D38506@DFWPML704-CHM.exmail.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2J7ue6mmuPRBr13tCx+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH3/LrMXdGVXfN/VztTA+D6si5GDQ0LAROLcefsuRk4OIYGj jBITpwV1MXIB2d8YJZovn2GHSBxhlHg5jQnEFhawl/g8bz0jiC0iIC/R2PuZHaKhhVni+vMJ zCAJNqCiu5c2gNm8QPb7F4tZQWwWAVWJNfOugsVFBWIlPl1ZDFUjKHFy5hMWEJtTIFTi4dat 7CDHMQP1PthaBhJmFtCWWLbwNTOELS5x68l8Jojb1CQ+vX3IPoFRcBaSSbMQumch6Z6FpHsB I8sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBwPbjlt+oOxstvHA8xCnAwKvHwhpQcjxZi TSwrrsw9xCjBwawkwlulCBTiTUmsrEotyo8vKs1JLT7EKM3BoiTO+9B8c5SQQHpiSWp2ampB ahFMlomDU6qBMWxtrEtFte/TBR3rKvOkZuhcsd7xsmnxi93HJ736qnHoiIukdbHMj/Td07tL 9AQvsLQduH2laell1SVH/Xjk5brOv2ZcqlO0pOzGl6BSUf9Vpx7LeoYWptcVmPVOVNrb0Pa7 umORilXyXea0H0LV7959KZO3MZz19uzqnn1Cnd//3pzplJPqo8RSnJFoqMVcVJwIAKJm7HRT AgAA Archived-At: Subject: Re: [Detnet] updating the flow information model draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:17:28 -0000 Hi, Coming back to this. In order delivery is one of the service parameters. As such, it reflects = how much out of order delivery the application running in the end system = can tolerate. If it is zero, then the application cannot tolerate=20 misordering at all. A non-zero value indicates how many packets received = out of order can be handled by the application. Violation of service parameters implies that the application cannot=20 handle (drops) the packets received. For instance, if the maximum=20 tolerable end to end latency is violated, then the packet arrives too=20 late for the application to be able to process. Similarly, if=20 misordering is violated, the application cannot process the packet. The service parameters are input to the DetNet network, which only=20 accepts a request to establish a new flow if the network can meet the=20 service parameters, otherwise rejects the request. The comments received on the document in this discussion are actually on = Section 5.2 Service parameters, e.g., delay and delay variation=20 parameters, misordering etc. In order to make progress, as a contribution to the WG, Section 5.2 will = be updated and a new revision of the draft will be submitted by the=20 submission deadline to address the comments to our best. The WG=20 discussion can be then continued taking it as an input, and fruther=20 updates will be made based on the discussions. Best regards, Janos On 7/20/2018 8:50 PM, Norman Finn wrote: > Lou: Perhaps you could expand on your "different technologies" comment= =2E > > Short explanation: > > The amount of misordering, and hence the resources (including choice of= algorithm) required to re-order packets, is known the the network, not t= he listener. The application already specifies a min/max latency in orde= r to bound his receive buffer requirements. I would favor 1) adding the = ability of the network to report the worst-case misordering, 2) keeping t= he binary "application can/cannot tolerate misordering" parameter, 3) hav= ing a binary "network can/cannot ensure ordering". > > Long explanation: > > I stand by my arguments about 5/100 vs. no/yes. If it's possible for t= he network to misorder packets, the resources required to reorder them, g= iven the path and the bandwidth/packet size spec for the flow, is certain= ly known to the network, but probably not to the application. Reporting = the worst-case misordering to the application would be useful. But, allo= wing the application to specify "5" when the network is likely to deliver= 100 simply complicates the reservation process. Of course, it's easy to= compare the application's requirement to the network's number, but that = is not the issue. Having the parameter merely begs a pile of questions f= or the application: > > - What number do I specify to maximize my chances of success? > - How many buffers might the network want me to have? > - Does that mean I need to know the topology? Line lengths? > - How do I compare my need for receiver buffers to my other needs fo= r memory space? > - Which device, me or the edge node, would find it easier/cheaper to= increase the number of reordering buffers? > - Does the edge node even have reordering capability? > - Will the network configuration produce misordering, at all? > > My claim is that most of these questions are settled much more easily w= ith the current yes/no requirement plus a report from the network on wors= t-case misordering, and we can see a path for negotiating/refusing/remaki= ng the reservation. I further claim that turning the yes/no into a numbe= r will complicate the process without bringing anything significant to th= e range of results available. > > For example, are we suggesting that the network could buffer just enoug= h to reduce the 100 to 5? I don't think it worthwhile to support the (I = think infrequent) case where the listener's capabilities to handle some m= isordering would make a significant difference in the resources required = for the network to reduce misordering to that level, but not eliminate it= =2E > > I would rather not add a "misordering limit" parameter. It will inevit= ably generate requirements for the control protocols support it, and I cl= aim there is no clear use for that information. Yes/no parameters for ne= twork and application capabilities, and a report on the possible misorder= ing number from the network, is sufficient. > > -- Norm > > ________________________________________ > From: detnet [detnet-bounces@ietf.org] on behalf of Lou Berger [lberger= @labn.net] > Sent: Thursday, July 19, 2018 7:27 AM > To: Norman Finn; J=E1nos Farkas; DetNet WG > Subject: Re: [Detnet] updating the flow information model draft > > On 7/17/2018 7:01 PM, Norman Finn wrote: >> Binary "reordering is/not acceptable" I can see some use for. It's th= e numbers that I don't know how to deal with. > There are different technology related/specific solutions here. The > fundamental point is to allow for it in the architecture and modeling.= > > Lou > >> -- Norm >> >> ________________________________________ >> From: Lou Berger [lberger@labn.net] >> Sent: Tuesday, July 17, 2018 1:39 PM >> To: Norman Finn; J=E1nos Farkas; DetNet WG >> Subject: Re: [Detnet] updating the flow information model draft >> >> Norm, >> >> In the IP case, worst-case packet misordering can also impact >> multi-path forwarding behavior. An implementation (IP or MPLS data >> planes) can always satisfy a non-zero reordering requirement with path= s >> that don't reorder. >> >> Lou >> >> On 7/17/2018 4:33 PM, Norman Finn wrote: >>> I have a problem with the idea of the user expressing a requirement f= or worst-case packet misordering. My problem is that I'm not sure what t= he network can do with that information. >>> >>> Either you are using PR/PE or not. If you are NOT using PR/PE, then = you are presumably using some routing/bridging protocol to heal the netwo= rk after a failure. The out-of-order problem will occur when, some time = after a failure caused a loss of packets and the use of a long path A-->B= , healing the failure and thus opening a shorter path causes early delive= ries and hence out-of-order packets. In order to predict the worst-case = scenario for out-of-order delivery, so that the network can pass or fail = the reservation request, one would have to determine the worst-case packe= ts in flight for the longest path A-->B after multiple failures in the ne= twork, and then look at the fastest possible healing to the shortest poss= ible path to get the worst-case out-of-order difference. It might be pos= sible to calculate this in a single-ring topology, but in a more complex = topology, I have my doubts that it can be performed reliably. Without a = reliable way to calculate the worst case, the user's misordering requirem= ents are irrelevant. >>> >>> If you ARE using PR/PE, then either you are using a bandwidth reserva= tion or you are not. If you are NOT using a bandwidth reservation, then = all bets are off. It is difficult to predict the worst-case difference i= n packets-in-flight for the two paths, and hence the worst-case sequence = delta. With nothing to compare the user's misording requirements to, the= requirements are irrelevant. >>> >>> If you ARE using PR/PE and you ARE using bandwidth reservations, then= as you are making the reservations, you can determine the worst-case tim= e differential on the different paths before a merge point, you know the = maximum data rates, and you can determine the buffer space needed to put = the packets in order. If the merge system has insufficient buffer spac= e to accomplish the merge, then the user's misordering requirements are i= rrelevant. That buffer space is required in order to both a) prevent ove= rloading the bandwidth reservation of the merged stream and b) not drop p= ackets due to congestion of the merge port, whether or not in-order deliv= ery is desired. If the merge buffer space is available, then there is = no problem with full in-order delivery, and the user's misordering requir= ements are irrelevant. >>> >>> Finally, what do we imagine the network to do other than refuse the r= eservation in the very few cases where this is possible? If it discards = packets with larger differences, then you are doing nothing that the rece= iver cannot do for itself. You also are taking on the problem of knowing= when to resume transmission, detecting when the sequence number is reset= , etc. These are not trivial problems, and wind up needing help from the= sequencing source. This is better left to the application to sort out. >>> >>> To sum up, I think that user requirements are much better expressed, = and the network's ability to conform to those requirements are better mea= sured, in terms of best- and worst-case latency and latency variation. >>> >>> -- Norm >>> ________________________________________ >>> From: detnet [detnet-bounces@ietf.org] on behalf of J=E1nos Farkas [j= anos.farkas@ericsson.com] >>> Sent: Wednesday, July 04, 2018 11:12 AM >>> To: DetNet WG >>> Subject: [Detnet] updating the flow information model draft >>> >>> Dear all, >>> >>> I think the flow information model draft needs some updates to bring = it >>> in-line with the recent developments in the WG. I=92d like to have WG= >>> discussion on the list and at IETF 102 before making any updates. >>> >>> 1, Current version of draft-ietf-detnet-flow-information-model-01 >>> >>> Section 5.2 Service Parameters includes in order delivery, which is a= >>> binary value in draft-ietf-detnet-flow-information-model-01 depending= on >>> whether or not in order delivery is required for the given service. T= his >>> requires refinements based on the developments we had in >>> draft-ietf-detnet-architecture-06. >>> >>> The refinement would involve introducing a numerical service paramete= r, >>> which could be called =93MisorderingTolerance=94 or alike to replace = the >>> current binary parameter. >>> >>> >>> 2, Recent updates of draft-ietf-detnet-architecture-06 >>> >>> draft-ietf-detnet-architecture-06 provides a finer grade DetNet QoS >>> parameter by introducing : >>> >>> Section 3.1: >>> =93o An upper bound on out-of-order packet delivery. It is worth >>> noting that some DetNet applications are unable to tolerate any >>> out-of-order delivery.=94 >>> >>> Section 3.2.2.1. In-Order Delivery: >>> =93Out-of-order packet delivery can be a side effect of service >>> protection. Packets delivered out-of-order impact the amount of >>> buffering needed at the destination to properly process the received >>> data. Such packets also influence the jitter of a flow. The DetNet >>> service includes maximum allowed misordering as a constraint. Zero >>> misordering would be a valid service constraint to reflect that the >>> end system(s) of the flow cannot tolerate any out-of-order delivery. >>> Service protection may provide a mechanism to support in-order >>> delivery.=94 >>> >>> The architecture document does not provide further details on purpose= =2E >>> It is the job of the flow information model draft to go into the deta= ils. >>> >>> >>> 3, =93MisorderingTolerance=94 related thoughts >>> >>> The DetNet QoS requirements are correlated to each other. For instanc= e, >>> a packet received with a too big delay or jitter is practically a los= t >>> packet for the application. As for misordering, it is related, e.g., = to >>> jitter as explained in the architecture document. (Well, misordering >>> above the tolerable limit can be considered loss.) The correlations c= an >>> be taken into account when defining the QoS requirements for a DetNet= >>> service, and also when providing the given DetNet service by the DetN= et >>> network. >>> >>> Actually, misordering and jitter can be decreased with a similar tool= , >>> e.g., a playout buffer. It is a bit more complex for reordering and >>> requires sequencing information carried in the packets. >>> >>> I see two approaches to express maximum allowed misordering: >>> a) number of misordered packets >>> b) time >>> >>> Both of them have their pros and cons. >>> >>> I propose to follow a) for multiple reasons. >>> >>> Maximum allowed/tolerable misordering could be defined along: >>> =93maximum number of misordered packets, e.g., a delta of sequence nu= mbers >>> between the highest sequence number that was just received and the >>> lowest sequence that is acceptable=94 >>> (credit goes to Pascal for initial wording!) >>> >>> This is a relatively simple definition and also simple to measure, >>> detect, and verify. Furthermore, timing requirement is already define= d >>> as part of the jitter requirement, no need to duplicate. In addition,= >>> timing may not be as important as the order of packets for some >>> applications. >>> >>> What do you think? >>> >>> Regards, >>> Janos >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Oct 17 16:02:57 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D684130E36 for ; Wed, 17 Oct 2018 16:02:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UKjyrkyk1u0 for ; Wed, 17 Oct 2018 16:02:51 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0126.outbound.protection.outlook.com [104.47.42.126]) (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 AB50F130E2A for ; Wed, 17 Oct 2018 16:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N5kvtRqBsNfBrpaDyYFTgvq4jGAL+w7lqWRnMt6CinE=; b=emAXMpmUYukt2TbELA7+vyIQU2WlaqxGeIsSOrJ5KBh4vzRy1+QtTmA8T7xDFYreM2IW08f4OrJSJAFhQSDjT0QDgftGKsdS5ubTOxrB6DJSKq+OT69swoSyhAQ/2E2ABoY/KBUHY8SJnHPsFseRr0capbCChrH2FnYNxc6roU8= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4355.namprd06.prod.outlook.com (10.167.181.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Wed, 17 Oct 2018 23:02:50 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.027; Wed, 17 Oct 2018 23:02:49 +0000 From: "Grossman, Ethan A." To: Loa Andersson , Lou Berger , Deborah Brungard CC: "detnet@ietf.org" , Daniel Harkins Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQgAA3NYCAAAlfoIAAJVkAgAB5JdCAAGFhcA== Date: Wed, 17 Oct 2018 23:02:49 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4355; 6:JVAxRlmjisDu6dMUqRP50ubYtxfULSubba+LAhsULPCrPUu1eqKMppyG64wLcjTIYEjML4bsxuF66v5onTkV3ZGxiDpF+nzhMfEPgBpYl/pTBaS/nz8f7nzhqQZT4Wh57+rDQPwfR1xq5plbn4OxZKN1iKjWtm6RZGBdDk4XdGyw4/s5xgCtJ6yX2E2Ujn6mopGxdUX556Q1KqzaxuSjhNmeEs+pe00MrVHuJ5+YFjDuNitzBnuvuhuWRYlFfkO09/a6rv/XBh48BvPZKZMD7+LIIOirC9t3w2obIDEwgHYwPBBJQLVca8exjmEr3oTibTBCcxpNeFs25vO/P3qf3Zc7MdPpY4E6tdNx3mv5nfSL55yDWArPIpaZ+cTBcQGQ3CibK1DOYPL2Udi484qpaJy5wG7LzBz+9McXmD4t51G48yHtm+UJGr98iIg3FHs3WucQJTOSdg2ph+jfaqOaPQ==; 5:LiyVPwy4QKGg+ZhnLWwGxPPRILGkoyNQ50mfE+6dBjdiesWgPBg7fqEBcKFuPZW3V7aJDvqccNG82y0UKV/N5S6Lf6hi3KCJvs1Tb6qB9pxfyeOtuqi8vQb1KEcHDDvgA/h5LIJvDogP5dRQfCghe7aMPA2dEXTjqRdKkZ0rVJg=; 7:Ss1sLu5TKCyRXkMNBXIOoDposppsyLbf5vLHBIUGMjXuRzCjj7ISTHcPa681vZs1CRD2Xl9hfnRNZLbCGwhRnTthl4GC6TtECULdUDNyuv18k5FyGzVNQLwq2tTETwOVE2RVZOJWW30fRQRqVA/96oML3/SyQsJf+0DIDTP2WYj9R3mf+9eVB9PKXp8eO1uwy4yKEIGi5nQbH0dx178FWD5PloIBfCwnbruWcrFd+ks32UCGWvVUvcvFHyYSGzx0 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0dafbe8b-af3f-4a9d-fbe4-08d63484a945 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4355; x-ms-traffictypediagnostic: BL0PR06MB4355: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4355; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4355; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(136003)(39860400002)(366004)(51444003)(252514010)(13464003)(53754006)(199004)(189003)(229853002)(6306002)(4001150100001)(9686003)(6246003)(478600001)(256004)(53936002)(486006)(26005)(14444005)(6436002)(86362001)(5250100002)(14454004)(966005)(53546011)(2906002)(11346002)(55016002)(6506007)(186003)(93156006)(97736004)(446003)(476003)(2900100001)(6116002)(3846002)(8936002)(93886005)(15650500001)(2940100002)(81166006)(305945005)(74316002)(8676002)(106356001)(76176011)(102836004)(7736002)(68736007)(81156014)(25786009)(105586002)(7696005)(4326008)(5660300001)(110136005)(99286004)(54906003)(71200400001)(71190400001)(33656002)(66066001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4355; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9ZJ35Hvd0rIE03otcQu067TZtrjF3NHJwmfA5gV4CHMNR63qXD4F5Pp7x4oZjfeIL8nmiF0tFrt+oDNsygxUrv6jsU7J+EjGLRdivMOr914Mjcq3xWow2m6cnWeFeyfi659Ak0J+NV4pSc0dKMkfh2xCM/RbYxcPiLRBNKa9NZtWcGM+9g8RBAd8Gtvm9pYsbRzc3kOCe0cPnMo3v9LuiXxQWSapLaqFGqTl19lSZX+pfqJ9xo8TPuhdgAh7whMRkGB4zZqrmTrAlJbCnuWIJ6cTXtjxBiQAEfZ/oOvQvxLzlZ1DDPkMiZeFZFHfxweIY0weGFCukylc5H0hbX2ApyQqcDHEzMoQHZ6qZlpPTZY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0dafbe8b-af3f-4a9d-fbe4-08d63484a945 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 23:02:49.7976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4355 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 23:02:55 -0000 T3IgbWF5YmUgdGhlIGFuc3dlciB3aWxsIGJlIGltcGxpY2l0IGluIERhbmllbCBIYXJraW5zJyBy ZXNwb25zZSB0byBKYW5vcycgcGxhbiB0byB1cGRhdGUgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdCB0 byByZWZlciB0byB0aGUgU2VjdXJpdHkgZHJhZnQuIElmIGhlIGFjY2VwdHMgdGhhdCwgdGhlbiBJ IHRoaW5rIHRoYXQgcHJldHR5IG11Y2ggY29uc3RpdHV0ZXMgYWNjZXB0YW5jZSBvZiB0aGF0IHN0 cmF0ZWd5PyBCdXQgZXZlbiBpZiBzbywgd291bGQgdGhhdCBob2xkIGZvciBldmVyeSBkcmFmdCwg b3IgYXJlIHRoZXJlIHNvbWUgdHlwZXMgb2YgZHJhZnQgZm9yIHdoaWNoIHRoYXQgd291bGRuJ3Qg YmUgYWNjZXB0YWJsZT8gDQpFdGhhbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEdyb3NzbWFuLCBFdGhhbiBBLiANClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNywgMjAx OCAxMDoxOSBBTQ0KVG86ICdMb2EgQW5kZXJzc29uJyA8bG9hQHBpLm51PjsgTG91IEJlcmdlciA8 bGJlcmdlckBsYWJuLm5ldD47IERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBhdHQuY29tPg0KQ2M6 IGRldG5ldEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEZXRuZXRdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzLnR4dA0KDQpUaGFua3MgTG9hIChhZGRpbmcgTG91IGFu ZCBEZWJvcmFoKS4gDQoNClNvIGZhciwgdGhlIHJldmlld2VycyBvZiB0aGUgbGFzdCBVc2UgQ2Fz ZXMgZHJhZnQgaGF2ZSBzYWlkICJIZXkgd2hlcmUncyB0aGUgU2VjdXJpdHkgc2VjdGlvbj8iIGFu ZCBMb3UgYW5kIEkgYWRkZWQgYSBTZWN1cml0eSBzZWN0aW9uIHRoYXQgcG9pbnRzIHRoZW0gYXQg dGhlIFNlY3VyaXR5IGRyYWZ0LCBhbmQgdGhleSBzZWVtZWQgdG8gYmUgT0sgd2l0aCB0aGF0LiBJ IGRvbid0IGtub3cgaWYgdGhhdCB3b3VsZCBiZSB0aGUgY2FzZSBmb3Igb3VyIG90aGVyIGRyYWZ0 cy4gIA0KDQpJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIGhhdmUgdGhpcyBjb252ZXJzYXRpb24g d2l0aCB0aGUgU2VjdXJpdHkgQUQncyBhbmQgRGlyZWN0b3JhdGU7IGF0IHByZXNlbnQsIEkgcGVy c29uYWxseSBkb24ndCBrbm93IHRoZSBtb3N0IGFwcHJvcHJpYXRlIGluZGl2aWR1YWxzIHRvIGVu Z2FnZSB3aXRoIG9uIHRoaXMgdG9waWMgLSBpZiBvbmUgb2YgeSdhbGwgd291bGQgbGlrZSB0byBw cm92aWRlIG1lIHNvbWUga2luZCBvZiBpbnRyb2R1Y3Rpb24sIEknbSBoYXBweSB0byB0cnkgdG8g ZHJpdmUgc29tZSByZXNvbHV0aW9uIG9uIG91ciBzdHJhdGVneSBoZXJlLCBlaXRoZXIgb24gdGhl IGxpc3Qgb3IgaW4gQmFuZ2tvay4gDQoNCkV0aGFuLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDE3LCAyMDE4IDI6NTcgQU0NClRvOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bk b2xieS5jb20+DQpDYzogZGV0bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RldG5ldF0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0DQoNCkV0aGFuLCBXb3Jr aW5nIEdyb3VwLA0KDQpJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgb25lIHNpemUgZml0cyBhbGwg YXBwcm9hY2ggcG9zc2libGUgZm9yIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpbiBhbGwg RGV0TmV0IGRvY3VtZW50cy4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBTZWN1cml0eSBE aXJlY3RvcmF0ZSBhbmQgU2VjdXJpdHkgQURzIHJlcXVpcmUgdGhhdCBlYWNoIGRvY3VtZW50IGhh dmUgYW4gaW5kZXBlbmRlbnQgdHJlYXRtZW50IG9mIHRoZSBzcGVjaWZpYyB0aHJlYXRzIGFuZCBj b25jZXJucyBmb3IgYSBwYXJ0aWN1bGFyIGRvY3VtZW50Lg0KDQpXaGF0ZXZlciBzdHJhdGVneSB3 ZSBkZWNpZGUgb24sIHBsZWFzZSBtYWtlIHN1cmUgdGhhdCBpdCBpcyBhZ3JlZWQgb24gYnkgdGhl IFNlY3VyaXR5IEFEcyBhbmQgRGlyZWN0b3JhdGUuDQoNCi9Mb2ENCg0KT24gMjAxOC0xMC0xNyAx NTo1NCwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3RlOg0KPiBIaSBMb2EsDQo+IFZhcmlvdXMgc3Ry YXRlZ2llcyBhcmUgcG9zc2libGUuIE9uZSBwb3NzaWJpbGl0eSBpcyB0aGF0IHRoZSBvdGhlciBk cmFmdHMgKGkuZS4gbm90IHRoZSBTZWN1cml0eSBkcmFmdCkgY291bGQganVzdCBwb2ludCBhdCB0 aGUgU2VjdXJpdHkgZHJhZnQgc3VjaCB0aGF0IHRoZXJlIHdvdWxkIGJlIGEgInNpbmdsZSBjbGVh cmluZyBob3VzZSIgZm9yIERldE5ldC1zcGVjaWZpYyBzZWN1cml0eSBpbmZvLiAgVGhhdCdzIHdo YXQgdGhlIFVzZSBDYXNlcyBkcmFmdCBkb2VzLCBob3dldmVyIHRoZXJlIGlzIGFsc28gc29tZSBz ZWN1cml0eS1yZWxhdGVkIHRleHQgaW4gdGhlIHZhcmlvdXMgdXNlIGNhc2VzLg0KPiANCj4gQXQg b25lIHBvaW50IEkgKGFzIFNlY3VyaXR5IGRyYWZ0IGVkaXRvcikgYXR0ZW1wdGVkIHRvIGJyaW5n IHRvZ2V0aGVyIA0KPiBhbGwgb2YgdGhlIHNlY3VyaXR5LXJlbGF0ZWQgdGV4dCBmcm9tIHRoZSB2 YXJpb3VzIG90aGVyIGRyYWZ0cyBieSANCj4gY29weWluZyBpdCBhbGwgaW50byBhbiBhcHBlbmRp eCBvZiB0aGUgU2VjdXJpdHkgZHJhZnQsIHNpbmNlIGl0IGlzIA0KPiBzb3J0IG9mIGhhbmR5IHRv IGhhdmUgaXQgYWxsIGluIG9uZSBwbGFjZS4gQnV0IGFzIExvdSBwb2ludGVkIG91dCB0byANCj4g bWUsIHdlIGRvbid0IHdhbnQgdG8gbWFrZSB0aGUgZHJhZnRzIGRlcGVuZGVudCBvbiBlYWNoIG90 aGVyIGlmIHdlIGNhbiANCj4gYXZvaWQgaXQsIGFuZCBpZiBzdWNoIHRleHQgZ290IGVkaXRlZCB0 aGVuIGl0IHdvdWxkIGhhdmUgdG8gYmUgZml4ZWQgDQo+IGluIHR3byBwbGFjZXMsIHNvIGl0IGlz bid0IGEgcGVyZmVjdCBzY2hlbWUuIEkgd291bGQgc2F5IHRoYXQgaWYgYSANCj4gZHJhZnQgYXV0 aG9yIHdhbnRzIHRvIHdyaXRlIHRoZWlyIG93biBzZWN1cml0eS1yZWxhdGVkIHRleHQgaW4gdGhl aXIgDQo+IG93biBkcmFmdCBtb3JlIHBvd2VyIHRvIHRoZW0sIGJ1dCBwZXJoYXBzIGV2ZW4gbW9y ZSBwb3dlciBpZiB0aGV5IA0KPiBicmluZyBpdCB0byB0aGUgU2VjdXJpdHkgZHJhZnQgOi0gKQ0K PiANCj4gU29ycnkgbG9uZyBhbnN3ZXIgdG8gYSBzaG9ydCBxdWVzdGlvbi4gQW5kIEknbSBzdXJl IHRoZXJlIGFyZSBvdGhlciBzdHJhdGVnaWVzLi4uIElmIHlvdSBoYXZlIGFueSB0aG91Z2h0cyBv biB0aGUgbWF0dGVyIEknZCBsb3ZlIHRvIGhlYXIgdGhlbSwgZWl0aGVyIG9uIHRoZSBsaXN0IG9y IGF0IElFVEYgMTAzLg0KPiBFdGhhbi4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCj4gU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDE3LCAyMDE4IDEyOjEwIEFNDQo+IFRvOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jv c0Bkb2xieS5jb20+DQo+IENjOiBkZXRuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEZXRu ZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzLnR4dA0KPiANCj4g RXRoYW4sDQo+IA0KPiBJIGhhdmUganVzdCBoYWQgYSBxdWljayBsb29rLCBidXQgd2hhdCBJIHNl ZSBsb29rcyBnb29kLCBhbmQgY2VydGFpbmx5IGdpdmVzIGEgZ29vZCBvdmVydmlldyBvZiB0aGUg ZGV0bmV0IHNlY3VyaXR5IGlzc3Vlcy4NCj4gDQo+IE9uZSBxdWVzdGlvbiwgaXMgaXQgdGhlIGlu dGVudGlvbiB0aGF0IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIHVzZWQgYXMgYSBnZW5lcmFsIHJl ZmVyZW5jZSB3aGVuIHdyaXRpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIGRldG5ldCBk b2N1bWVudHM/DQo+IA0KPiAvTG9hDQo+IA0KPiBPbiAyMDE4LTEwLTE3IDEyOjA1LCBHcm9zc21h biwgRXRoYW4gQS4gd3JvdGU6DQo+PiBIaSBBbGwsDQo+PiBUaGlzIG5vdGUgaXMgdGhlIHN0YXR1 cyB1cGRhdGUgZm9yIHRoZSBEZXROZXQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgZHJhZnQgaW4g YWR2YW5jZSBvZiBJRVRGIDEwMywgaW4gbGlldSBvZiBhIHByZXNlbnRhdGlvbiBzbG90IGZvciBp dCBhdCBJRVRGIDEwMy4NCj4+DQo+PiBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCB3aGlj aCBpbmNsdWRlcyB0aGUgZGlzY3Vzc2lvbiBvbiBPQU0gdHJhZmZpYyBhbmQgaW5jb3Jwb3JhdGVz IHRoZSAiQm91bmRlZCBKaXR0ZXIiIFVzZSBDYXNlIENvbW1vbiBUaGVtZS4NCj4+DQo+PiBUaGVz ZSBhcmUgbWlub3IgY2hhbmdlczsgbm8gc3Vic3RhbnRpYWwgd29yayBoYXMgYmVlbiBkb25lIHNp bmNlIHRoZSBsYXN0IERldE5ldCBzZXNzaW9uLCBzbyB3ZSBkbyBub3QgcGxhbiB0byBoYXZlIGEg c2xvdCBmb3IgdGhpcyBkcmFmdCBhdCB0aGUgSUVURiAxMDMgRGV0TmV0IHNlc3Npb24gKHRob3Vn aCBUYWwgd2lsbCBiZSBwcmVzZW50aW5nIG9uIGl0IGF0IHRoZSBEZXROZXQtVFNOIG1lZXRpbmcg b24gdGhlIGZvbGxvd2luZyBTdW5kYXkpLg0KPj4NCj4+IEkgZXhwZWN0IHRoYXQgd2Ugd2lsbCBj b252ZW5lIGFzIG1hbnkgb2YgdGhlIGF1dGhvcnMgKGFuZCBhbnkgb3RoZXIgaW50ZXJlc3RlZCBw YXJ0aWVzKSBhcyB3ZSBoYXZlIGF2YWlsYWJsZSBhdCBJRVRGIDEwMyB0byBkaXNjdXNzIERldE5l dC1kYXRhLXBsYW5lLXRlY2hub2xvZ3ktc3BlY2lmaWMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg YW5kIGhvdyB0byBpbmNvcnBvcmF0ZSB0aGVtIGludG8gdGhlIGRyYWZ0IGFzIG91ciBuZXh0IHN0 ZXBzLiBJZiB5b3Ugd291bGQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiAoYmUgbm90aWZpZWQgYWJv dXQpIHRoaXMgY29udmVyc2F0aW9uLCBwbGVhc2UgbGV0IG1lIGtub3cuDQo+Pg0KPj4gQmVzdCwN Cj4+IEV0aGFuIChhcyBEZXROZXQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgZHJhZnQgZWRpdG9y KQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBkZXRuZXQgPGRl dG5ldC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgDQo+PiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNCj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTggODo1MSBQTQ0KPj4g VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPj4gQ2M6IGRldG5ldEBpZXRmLm9yZw0KPj4gU3Vi amVjdDogW0RldG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMu dHh0DQo+Pg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIERldGVybWluaXN0aWMgTmV0d29ya2luZyBXRyBvZiB0aGUgSUVU Ri4NCj4+DQo+PiAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGV0ZXJtaW5pc3RpYyBOZXR3 b3JraW5nIChEZXROZXQpIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+PiAgICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogVGFsIE1penJhaGkNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBFdGhhbiBHcm9zc21hbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZHJldyBK LiBIYWNrZXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJpciBEYXMNCj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIERvd2RlbGwNCj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBIZW5yaWsgQXVzdGFkDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgS2V2aW4gU3RhbnRvbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vcm1hbiBG aW5uDQo+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMu dHh0DQo+PiAJUGFnZXMgICAgICAgICAgIDogNDANCj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE4 LTEwLTE2DQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgICAgIEEgZGV0ZXJtaW5pc3RpYyBuZXR3b3Jr IGlzIG9uZSB0aGF0IGNhbiBjYXJyeSBkYXRhIGZsb3dzIGZvciByZWFsLQ0KPj4gICAgICB0aW1l IGFwcGxpY2F0aW9ucyB3aXRoIGV4dHJlbWVseSBsb3cgZGF0YSBsb3NzIHJhdGVzIGFuZCBib3Vu ZGVkDQo+PiAgICAgIGxhdGVuY3kuICBEZXRlcm1pbmlzdGljIG5ldHdvcmtzIGhhdmUgYmVlbiBz dWNjZXNzZnVsbHkgZGVwbG95ZWQgaW4NCj4+ICAgICAgcmVhbC10aW1lIG9wZXJhdGlvbmFsIHRl Y2hub2xvZ3kgKE9UKSBhcHBsaWNhdGlvbnMgZm9yIHNvbWUgeWVhcnMNCj4+ICAgICAgKGZvciBl eGFtcGxlIFtBUklOQzY2NFA3XSkuICBIb3dldmVyLCBzdWNoIG5ldHdvcmtzIGFyZSB0eXBpY2Fs bHkNCj4+ICAgICAgaXNvbGF0ZWQgZnJvbSBleHRlcm5hbCBhY2Nlc3MsIGFuZCB0aHVzIHRoZSBz ZWN1cml0eSB0aHJlYXQgZnJvbQ0KPj4gICAgICBleHRlcm5hbCBhdHRhY2tlcnMgaXMgbG93LiAg SUVURiBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkNCj4+ICAgICAgc3BlY2lmaWVz IGEgc2V0IG9mIHRlY2hub2xvZ2llcyB0aGF0IGVuYWJsZSBjcmVhdGlvbiBvZiBkZXRlcm1pbmlz dGljDQo+PiAgICAgIG5ldHdvcmtzIG9uIElQLWJhc2VkIG5ldHdvcmtzIG9mIHBvdGVudGlhbGx5 IHdpZGUgYXJlYSAob24gdGhlIHNjYWxlDQo+PiAgICAgIG9mIGEgY29ycG9yYXRlIG5ldHdvcmsp IHBvdGVudGlhbGx5IGJyaW5naW5nIHRoZSBPVCBuZXR3b3JrIGludG8NCj4+ICAgICAgY29udGFj dCB3aXRoIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgKElUKSB0cmFmZmljIGFuZCBzZWN1cml0eSB0 aHJlYXRzDQo+PiAgICAgIHRoYXQgbGllIG91dHNpZGUgb2YgYSB0aWdodGx5IGNvbnRyb2xsZWQg YW5kIGJvdW5kZWQgYXJlYSAoc3VjaCBhcw0KPj4gICAgICB0aGUgaW50ZXJuYWxzIG9mIGFuIGFp cmNyYWZ0KS4gIFRoZXNlIERldE5ldCB0ZWNobm9sb2dpZXMgaGF2ZSBub3QNCj4+ICAgICAgcHJl dmlvdXNseSBiZWVuIGRlcGxveWVkIHRvZ2V0aGVyIG9uIGEgd2lkZSBhcmVhIElQLWJhc2VkIG5l dHdvcmssDQo+PiAgICAgIGFuZCB0aHVzIGNhbiBwcmVzZW50IHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHRoYXQgbWF5IGJlIG5ldyB0byBJUC0NCj4+ICAgICAgYmFzZWQgd2lkZSBhcmVhIG5ldHdv cmsgZGVzaWduZXJzLiAgVGhpcyBkcmFmdCwgaW50ZW5kZWQgZm9yIHVzZSBieQ0KPj4gICAgICBE ZXROZXQgbmV0d29yayBkZXNpZ25lcnMsIHByb3ZpZGVzIGluc2lnaHQgaW50byB0aGVzZSBzZWN1 cml0eQ0KPj4gICAgICBjb25zaWRlcmF0aW9ucy4gIEluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0IGNv bGxlY3RzIGFsbCBzZWN1cml0eS0NCj4+ICAgICAgcmVsYXRlZCBzdGF0ZW1lbnRzIGZyb20gdGhl IHZhcmlvdXMgRGV0TmV0IGRyYWZ0cyAoQXJjaGl0ZWN0dXJlLCBVc2UNCj4+ICAgICAgQ2FzZXMs IGV0YykgaW50byBhIHNpbmdsZSBsb2NhdGlvbiBTZWN0aW9uIDcuDQo+Pg0KPj4NCj4+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHkvDQo+ Pg0KPj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAz DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZGV0 bmV0LXNlY3VyaXR5LTAzDQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzDQo+Pg0KPj4NCj4+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+PiBkZXRuZXRAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRldG5ldCBtYWlsaW5n IGxpc3QNCj4+IGRldG5ldEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kZXRuZXQNCj4+DQo+IA0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQ0KU2VuaW9yIE1QTFMgRXhwZXJ0DQpC cm9uemUgRHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEg NjQNCg== From nobody Thu Oct 18 11:47:06 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B51293FB; Thu, 18 Oct 2018 11:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153988842454.22239.14448100799142894515@ietfa.amsl.com> Date: Thu, 18 Oct 2018 11:47:04 -0700 Archived-At: Subject: [Detnet] Genart telechat review of draft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:47:05 -0000 Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-detnet-use-cases-19 Reviewer: Pete Resnick Review Date: 2018-10-18 IETF LC End Date: 2018-10-03 IESG Telechat date: 2018-10-25 Summary: Ready Thanks for the updates to address my previous comments. Good to go. Major issues: None. Minor issues: None. Nits/editorial comments: None. From nobody Fri Oct 19 06:16:32 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63715127333 for ; Fri, 19 Oct 2018 06:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxxO9aQS3xRh for ; Fri, 19 Oct 2018 06:16:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0171E127AC2 for ; Fri, 19 Oct 2018 06:16:25 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.168.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A274B1802AAA; Fri, 19 Oct 2018 15:16:20 +0200 (CEST) To: "Grossman, Ethan A." , Lou Berger , Deborah Brungard Cc: "detnet@ietf.org" , Daniel Harkins References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> From: Loa Andersson Message-ID: Date: Fri, 19 Oct 2018 21:16:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 13:16:30 -0000 Ethan, One small comment - I think that one concern from the SEC-DIR is that "Security draft" is set in time and the very next draft (not to mention very much later drafts) addresses things that were not known when the "Security draft" was written. Thus the Security Considerations can never reference the "Security draft", but we need to show that we understand threats and remedies that is relevant to each and every draft. Having said that (to avoid misunderstandings) the "Security draft" is a good document, well worth referencing, but a reference is not enough, the particular threats need to be addressed. /Loa On 2018-10-18 07:02, Grossman, Ethan A. wrote: > Or maybe the answer will be implicit in Daniel Harkins' response to Janos' plan to update the architecture draft to refer to the Security draft. If he accepts that, then I think that pretty much constitutes acceptance of that strategy? But even if so, would that hold for every draft, or are there some types of draft for which that wouldn't be acceptable? > Ethan. > > -----Original Message----- > From: Grossman, Ethan A. > Sent: Wednesday, October 17, 2018 10:19 AM > To: 'Loa Andersson' ; Lou Berger ; Deborah Brungard > Cc: detnet@ietf.org > Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt > > Thanks Loa (adding Lou and Deborah). > > So far, the reviewers of the last Use Cases draft have said "Hey where's the Security section?" and Lou and I added a Security section that points them at the Security draft, and they seemed to be OK with that. I don't know if that would be the case for our other drafts. > > I would very much like to have this conversation with the Security AD's and Directorate; at present, I personally don't know the most appropriate individuals to engage with on this topic - if one of y'all would like to provide me some kind of introduction, I'm happy to try to drive some resolution on our strategy here, either on the list or in Bangkok. > > Ethan. > > -----Original Message----- > From: Loa Andersson > Sent: Wednesday, October 17, 2018 2:57 AM > To: Grossman, Ethan A. > Cc: detnet@ietf.org > Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt > > Ethan, Working Group, > > I don't think there is a one size fits all approach possible for the Security Considerations in all DetNet documents. My understanding is that the Security Directorate and Security ADs require that each document have an independent treatment of the specific threats and concerns for a particular document. > > Whatever strategy we decide on, please make sure that it is agreed on by the Security ADs and Directorate. > > /Loa > > On 2018-10-17 15:54, Grossman, Ethan A. wrote: >> Hi Loa, >> Various strategies are possible. One possibility is that the other drafts (i.e. not the Security draft) could just point at the Security draft such that there would be a "single clearing house" for DetNet-specific security info. That's what the Use Cases draft does, however there is also some security-related text in the various use cases. >> >> At one point I (as Security draft editor) attempted to bring together >> all of the security-related text from the various other drafts by >> copying it all into an appendix of the Security draft, since it is >> sort of handy to have it all in one place. But as Lou pointed out to >> me, we don't want to make the drafts dependent on each other if we can >> avoid it, and if such text got edited then it would have to be fixed >> in two places, so it isn't a perfect scheme. I would say that if a >> draft author wants to write their own security-related text in their >> own draft more power to them, but perhaps even more power if they >> bring it to the Security draft :- ) >> >> Sorry long answer to a short question. And I'm sure there are other strategies... If you have any thoughts on the matter I'd love to hear them, either on the list or at IETF 103. >> Ethan. >> >> -----Original Message----- >> From: Loa Andersson >> Sent: Wednesday, October 17, 2018 12:10 AM >> To: Grossman, Ethan A. >> Cc: detnet@ietf.org >> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >> >> Ethan, >> >> I have just had a quick look, but what I see looks good, and certainly gives a good overview of the detnet security issues. >> >> One question, is it the intention that this document should be used as a general reference when writing security considerations for detnet documents? >> >> /Loa >> >> On 2018-10-17 12:05, Grossman, Ethan A. wrote: >>> Hi All, >>> This note is the status update for the DetNet Security Considerations draft in advance of IETF 103, in lieu of a presentation slot for it at IETF 103. >>> >>> A new version has been posted which includes the discussion on OAM traffic and incorporates the "Bounded Jitter" Use Case Common Theme. >>> >>> These are minor changes; no substantial work has been done since the last DetNet session, so we do not plan to have a slot for this draft at the IETF 103 DetNet session (though Tal will be presenting on it at the DetNet-TSN meeting on the following Sunday). >>> >>> I expect that we will convene as many of the authors (and any other interested parties) as we have available at IETF 103 to discuss DetNet-data-plane-technology-specific security considerations and how to incorporate them into the draft as our next steps. If you would like to participate in (be notified about) this conversation, please let me know. >>> >>> Best, >>> Ethan (as DetNet Security Considerations draft editor) >>> >>> -----Original Message----- >>> From: detnet On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Tuesday, October 16, 2018 8:51 PM >>> To: i-d-announce@ietf.org >>> Cc: detnet@ietf.org >>> Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Deterministic Networking WG of the IETF. >>> >>> Title : Deterministic Networking (DetNet) Security Considerations >>> Authors : Tal Mizrahi >>> Ethan Grossman >>> Andrew J. Hacker >>> Subir Das >>> John Dowdell >>> Henrik Austad >>> Kevin Stanton >>> Norman Finn >>> Filename : draft-ietf-detnet-security-03.txt >>> Pages : 40 >>> Date : 2018-10-16 >>> >>> Abstract: >>> A deterministic network is one that can carry data flows for real- >>> time applications with extremely low data loss rates and bounded >>> latency. Deterministic networks have been successfully deployed in >>> real-time operational technology (OT) applications for some years >>> (for example [ARINC664P7]). However, such networks are typically >>> isolated from external access, and thus the security threat from >>> external attackers is low. IETF Deterministic Networking (DetNet) >>> specifies a set of technologies that enable creation of deterministic >>> networks on IP-based networks of potentially wide area (on the scale >>> of a corporate network) potentially bringing the OT network into >>> contact with Information Technology (IT) traffic and security threats >>> that lie outside of a tightly controlled and bounded area (such as >>> the internals of an aircraft). These DetNet technologies have not >>> previously been deployed together on a wide area IP-based network, >>> and thus can present security considerations that may be new to IP- >>> based wide area network designers. This draft, intended for use by >>> DetNet network designers, provides insight into these security >>> considerations. In addition, this draft collects all security- >>> related statements from the various DetNet drafts (Architecture, Use >>> Cases, etc) into a single location Section 7. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-detnet-security-03 >>> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Fri Oct 19 10:23:09 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D108130E5F for ; Fri, 19 Oct 2018 10:23:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go-_jTewQ0Px for ; Fri, 19 Oct 2018 10:23:04 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0120.outbound.protection.outlook.com [104.47.37.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4D7130E39 for ; Fri, 19 Oct 2018 10:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KFF/EHtl1d/8oW5mREt+wUO2cpUI6SV14gnRfiG5bqY=; b=eoTp+nvJBB6dITsqlDWnFFlaaBzETxNAhGm4nxmiFJv+SyMezahHX4xzTU92eiUGZcF5K79EYGslk7LyE44a0ZALxLegzQ1x5gWXqX4q9XyuhLaAXIfQS0z0SpBPIt/FXFx/LaaK9S3KU1K4HqFVDu09xgafIrFvGzGxSn75biA= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4180.namprd06.prod.outlook.com (10.167.172.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20; Fri, 19 Oct 2018 17:23:02 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::70af:3505:5e0c:1323%3]) with mapi id 15.20.1228.027; Fri, 19 Oct 2018 17:23:02 +0000 From: "Grossman, Ethan A." To: Loa Andersson , Lou Berger , Deborah Brungard CC: "detnet@ietf.org" , Daniel Harkins Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQgAA3NYCAAAlfoIAAJVkAgAB5JdCAAGFhcIACgdUAgABDm4A= Date: Fri, 19 Oct 2018 17:23:02 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4180; 6:p+XjSyy6I59A7JabFq0ndR7+foMJ9TvuAJDvXcTOA0dqjsv0uOZXzmrzsa5G0ABVstL/MK5M5PWGByG++HE6FmwQEVjqeRO4clVDWpHDEgf9+40dlg0Wm3RlnOOUtcyC5IIfNsgdm3Rcy9a/SsdkWFcUQp3AdIYAM+H6bn3SlyArf3idddOytVIM5FBf/4USf7chYwCDSCcGoZH0JYWdlZJJ9b+jNjr5AgyQmSPVZpX2sgGITxbqVe8a3jC17OgaOwJVaRRDOT7zgXDiXPdzNXsIdUYZp0eW+u0O5U03yHNqiJtpw7LKfiMOetIAVzxIlEWrbV3uS2kse+7tf/dXRBruvxbddZxowwExI2d6r6mcpnXOZjTNXU6Edzhzk8shdAt9x2z0LYERLfrkPD/4t5f7U78RlSNTPG6tazbzd+MEF3Ga0SC8B4IM2RVTEezKpQR3800KcYkCogrci1cQ7g==; 5:n6gCfH1EPbpRDUB4Xobv7yIkeLCqYEKr1zml21hh3+twwfLf/KDrrfy2cbXypTAbtYDUbPEijLr3YKXuIxOLMRDAMKbH22rKgEgr9hKvY/2tVsLDyX90WlNKtBfbe98sf2KRwCvNtm/MQi+V8BcvIIKLzUnb/ckH1yoJCVb/e+4=; 7:ttcXaRb5H7xiod2BO72tSizh7rJS+QHxEFASaQWm9H7EZCZs/JfB+vnjVdRsa13yVA7K1UY19wjGxEN6W9rMewwDqJgfImsFiFjMubuqCILc3S0Bm48kVJ7qtdnxkkGF5/qItgMirrOwkSlkgoWVp8RgYDc1S6e7X2FBQH78UHLby63dXEvVYCyMXR3XJumdIepUgVa+51wAJ2WWzSKBx3zCKt4xJ3GONUgGOUT+nEwqTnzTbMyKjjRQinE3/td5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9cddcbb2-b9fa-49ca-75d6-08d635e78656 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4180; x-ms-traffictypediagnostic: BL0PR06MB4180: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4180; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4180; x-forefront-prvs: 0830866D19 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39840400004)(136003)(366004)(252514010)(199004)(189003)(53754006)(51444003)(13464003)(446003)(8936002)(15650500001)(316002)(229853002)(6116002)(5250100002)(966005)(105586002)(486006)(99286004)(14444005)(26005)(86362001)(11346002)(476003)(97736004)(186003)(256004)(66066001)(25786009)(53936002)(106356001)(81156014)(74316002)(8676002)(305945005)(6306002)(76176011)(9686003)(5660300001)(6436002)(4001150100001)(71200400001)(33656002)(2900100001)(7696005)(7736002)(81166006)(4326008)(110136005)(55016002)(478600001)(102836004)(93886005)(6246003)(68736007)(53546011)(14454004)(2906002)(71190400001)(54906003)(6506007)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4180; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: F70dWzD4/bStkFK7TzWN2pz8c6DDyMYj6Sk6De5SBui3yWmI5IJPKamUwhJ9ia5gvx1AqRFx3kNSJvxHI+P/0sd/NiBzfD6HuH+xIJywMjf7LwLmLg93/H2EM5oXf0L5wUh8L3poSkihiDdZyL/yEm/wC6536omWLrn0RhuHx4QVzYE0284skeL9nr54UjCVGJ8ZNTRtatT46t3syqUi7/6xKRgX2nXklcxAM0926wYzP5DiURJm4a5ye38+Gw+G+cohvgqX7QM3hxvsApof3lHtiqAro64pHMvJXaxChpfv9p1vJQlGou43vIUHjQNf0IupL99DMDo/xPM75UTGaKgKGpGgZYCWv/kOcNM09Io= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cddcbb2-b9fa-49ca-75d6-08d635e78656 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 17:23:02.4853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4180 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 17:23:07 -0000 SGkgTG9hLA0KVGhpcyBpcyBhIHZlcnkgZ29vZCBwb2ludCwgdGhhdCBhcyBvdGhlciBkcmFmdHMg cHJvZ3Jlc3MgYWZ0ZXIgcHVibGljYXRpb24gb2YgdGhlIFNlY3VyaXR5IGRyYWZ0IHRoYXQgbmV3 IGZhY3RvcnMgY291bGQgYXJpc2UuIFBlcmhhcHMgdGhlIGRyYWZ0cyBjb3VsZCBiZSBleHBlY3Rl ZCB0byByZWZlcmVuY2UgdGhlIFNlY3VyaXR5IGRyYWZ0LCBidXQgbm90IGR1cGxpY2F0ZSB3aGF0 IHdhcyBhbHJlYWR5IGluIHRoZSBTZWN1cml0eSBkcmFmdCBhdCB0aGF0IHRpbWUsIGluY29ycG9y YXRpbmcgYW55IG5ldyBtYXRlcmlhbCBpbiB0aGUgZHJhZnQgaXRzZWxmLCBvciBhbHRlcm5hdGl2 ZWx5IHVwZGF0aW5nIHRoZSBTZWN1cml0eSBkcmFmdCB3aXRoIHRoZSBuZXcgbWF0ZXJpYWwgYXQg dGhlIHNhbWUgdGltZT8gT3RoZXJ3aXNlIGEgbG90IG9mIGR1cGxpY2F0aW9uIG9mIHRleHQgd291 bGQgaGF2ZSB0byBiZSBkb25lIHRvIG1ha2UgZWFjaCBhbmQgZXZlcnkgZHJhZnQgc2VsZi1zdWZm aWNpZW50IGluIHRoZSBhcmVhIG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiANCkV0aGFuLg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PiANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOSwgMjAxOCA2OjE2IEFNDQpUbzogR3Jvc3Nt YW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9sYnkuY29tPjsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJu Lm5ldD47IERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBhdHQuY29tPg0KQ2M6IGRldG5ldEBpZXRm Lm9yZzsgRGFuaWVsIEhhcmtpbnMgPGRoYXJraW5zQGxvdW5nZS5vcmc+DQpTdWJqZWN0OiBSZTog W0RldG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0DQoN CkV0aGFuLA0KDQpPbmUgc21hbGwgY29tbWVudCAtIEkgdGhpbmsgdGhhdCBvbmUgY29uY2VybiBm cm9tIHRoZSBTRUMtRElSIGlzIHRoYXQgIlNlY3VyaXR5IGRyYWZ0IiBpcyBzZXQgaW4gdGltZSBh bmQgdGhlIHZlcnkgbmV4dCBkcmFmdCAobm90IHRvIG1lbnRpb24gdmVyeSBtdWNoIGxhdGVyIGRy YWZ0cykgYWRkcmVzc2VzIHRoaW5ncyB0aGF0IHdlcmUgbm90IGtub3duIHdoZW4gdGhlICJTZWN1 cml0eSBkcmFmdCIgd2FzIHdyaXR0ZW4uIFRodXMgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IGNhbiBuZXZlciByZWZlcmVuY2UgdGhlICJTZWN1cml0eSBkcmFmdCIsIGJ1dCB3ZSBuZWVkIHRv IHNob3cgdGhhdCB3ZSB1bmRlcnN0YW5kIHRocmVhdHMgYW5kIHJlbWVkaWVzIHRoYXQgaXMgcmVs ZXZhbnQgdG8gZWFjaCBhbmQgZXZlcnkgZHJhZnQuDQoNCkhhdmluZyBzYWlkIHRoYXQgKHRvIGF2 b2lkIG1pc3VuZGVyc3RhbmRpbmdzKSB0aGUgIlNlY3VyaXR5IGRyYWZ0IiBpcyBhIGdvb2QgZG9j dW1lbnQsIHdlbGwgd29ydGggcmVmZXJlbmNpbmcsIGJ1dCBhIHJlZmVyZW5jZSBpcyBub3QgZW5v dWdoLCB0aGUgcGFydGljdWxhciB0aHJlYXRzIG5lZWQgdG8gYmUgYWRkcmVzc2VkLg0KDQovTG9h DQoNCk9uIDIwMTgtMTAtMTggMDc6MDIsIEdyb3NzbWFuLCBFdGhhbiBBLiB3cm90ZToNCj4gT3Ig bWF5YmUgdGhlIGFuc3dlciB3aWxsIGJlIGltcGxpY2l0IGluIERhbmllbCBIYXJraW5zJyByZXNw b25zZSB0byBKYW5vcycgcGxhbiB0byB1cGRhdGUgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdCB0byBy ZWZlciB0byB0aGUgU2VjdXJpdHkgZHJhZnQuIElmIGhlIGFjY2VwdHMgdGhhdCwgdGhlbiBJIHRo aW5rIHRoYXQgcHJldHR5IG11Y2ggY29uc3RpdHV0ZXMgYWNjZXB0YW5jZSBvZiB0aGF0IHN0cmF0 ZWd5PyBCdXQgZXZlbiBpZiBzbywgd291bGQgdGhhdCBob2xkIGZvciBldmVyeSBkcmFmdCwgb3Ig YXJlIHRoZXJlIHNvbWUgdHlwZXMgb2YgZHJhZnQgZm9yIHdoaWNoIHRoYXQgd291bGRuJ3QgYmUg YWNjZXB0YWJsZT8NCj4gRXRoYW4uDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBHcm9zc21hbiwgRXRoYW4gQS4NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE3 LCAyMDE4IDEwOjE5IEFNDQo+IFRvOiAnTG9hIEFuZGVyc3NvbicgPGxvYUBwaS5udT47IExvdSBC ZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+OyANCj4gRGVib3JhaCBCcnVuZ2FyZCA8ZGIzNTQ2QGF0 dC5jb20+DQo+IENjOiBkZXRuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtEZXRuZXRdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzLnR4dA0KPiANCj4gVGhhbmtz IExvYSAoYWRkaW5nIExvdSBhbmQgRGVib3JhaCkuDQo+IA0KPiBTbyBmYXIsIHRoZSByZXZpZXdl cnMgb2YgdGhlIGxhc3QgVXNlIENhc2VzIGRyYWZ0IGhhdmUgc2FpZCAiSGV5IHdoZXJlJ3MgdGhl IFNlY3VyaXR5IHNlY3Rpb24/IiBhbmQgTG91IGFuZCBJIGFkZGVkIGEgU2VjdXJpdHkgc2VjdGlv biB0aGF0IHBvaW50cyB0aGVtIGF0IHRoZSBTZWN1cml0eSBkcmFmdCwgYW5kIHRoZXkgc2VlbWVk IHRvIGJlIE9LIHdpdGggdGhhdC4gSSBkb24ndCBrbm93IGlmIHRoYXQgd291bGQgYmUgdGhlIGNh c2UgZm9yIG91ciBvdGhlciBkcmFmdHMuDQo+IA0KPiBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRv IGhhdmUgdGhpcyBjb252ZXJzYXRpb24gd2l0aCB0aGUgU2VjdXJpdHkgQUQncyBhbmQgRGlyZWN0 b3JhdGU7IGF0IHByZXNlbnQsIEkgcGVyc29uYWxseSBkb24ndCBrbm93IHRoZSBtb3N0IGFwcHJv cHJpYXRlIGluZGl2aWR1YWxzIHRvIGVuZ2FnZSB3aXRoIG9uIHRoaXMgdG9waWMgLSBpZiBvbmUg b2YgeSdhbGwgd291bGQgbGlrZSB0byBwcm92aWRlIG1lIHNvbWUga2luZCBvZiBpbnRyb2R1Y3Rp b24sIEknbSBoYXBweSB0byB0cnkgdG8gZHJpdmUgc29tZSByZXNvbHV0aW9uIG9uIG91ciBzdHJh dGVneSBoZXJlLCBlaXRoZXIgb24gdGhlIGxpc3Qgb3IgaW4gQmFuZ2tvay4NCj4gDQo+IEV0aGFu Lg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3Nv biA8bG9hQHBpLm51Pg0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTggMjo1NyBB TQ0KPiBUbzogR3Jvc3NtYW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9sYnkuY29tPg0KPiBDYzogZGV0 bmV0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWRldG5ldC1zZWN1cml0eS0wMy50eHQNCj4gDQo+IEV0aGFuLCBXb3JraW5nIEdyb3VwLA0K PiANCj4gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIG9uZSBzaXplIGZpdHMgYWxsIGFwcHJvYWNo IHBvc3NpYmxlIGZvciB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaW4gYWxsIERldE5ldCBk b2N1bWVudHMuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgU2VjdXJpdHkgRGlyZWN0b3Jh dGUgYW5kIFNlY3VyaXR5IEFEcyByZXF1aXJlIHRoYXQgZWFjaCBkb2N1bWVudCBoYXZlIGFuIGlu ZGVwZW5kZW50IHRyZWF0bWVudCBvZiB0aGUgc3BlY2lmaWMgdGhyZWF0cyBhbmQgY29uY2VybnMg Zm9yIGEgcGFydGljdWxhciBkb2N1bWVudC4NCj4gDQo+IFdoYXRldmVyIHN0cmF0ZWd5IHdlIGRl Y2lkZSBvbiwgcGxlYXNlIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIGFncmVlZCBvbiBieSB0aGUgU2Vj dXJpdHkgQURzIGFuZCBEaXJlY3RvcmF0ZS4NCj4gDQo+IC9Mb2ENCj4gDQo+IE9uIDIwMTgtMTAt MTcgMTU6NTQsIEdyb3NzbWFuLCBFdGhhbiBBLiB3cm90ZToNCj4+IEhpIExvYSwNCj4+IFZhcmlv dXMgc3RyYXRlZ2llcyBhcmUgcG9zc2libGUuIE9uZSBwb3NzaWJpbGl0eSBpcyB0aGF0IHRoZSBv dGhlciBkcmFmdHMgKGkuZS4gbm90IHRoZSBTZWN1cml0eSBkcmFmdCkgY291bGQganVzdCBwb2lu dCBhdCB0aGUgU2VjdXJpdHkgZHJhZnQgc3VjaCB0aGF0IHRoZXJlIHdvdWxkIGJlIGEgInNpbmds ZSBjbGVhcmluZyBob3VzZSIgZm9yIERldE5ldC1zcGVjaWZpYyBzZWN1cml0eSBpbmZvLiAgVGhh dCdzIHdoYXQgdGhlIFVzZSBDYXNlcyBkcmFmdCBkb2VzLCBob3dldmVyIHRoZXJlIGlzIGFsc28g c29tZSBzZWN1cml0eS1yZWxhdGVkIHRleHQgaW4gdGhlIHZhcmlvdXMgdXNlIGNhc2VzLg0KPj4N Cj4+IEF0IG9uZSBwb2ludCBJIChhcyBTZWN1cml0eSBkcmFmdCBlZGl0b3IpIGF0dGVtcHRlZCB0 byBicmluZyB0b2dldGhlciANCj4+IGFsbCBvZiB0aGUgc2VjdXJpdHktcmVsYXRlZCB0ZXh0IGZy b20gdGhlIHZhcmlvdXMgb3RoZXIgZHJhZnRzIGJ5IA0KPj4gY29weWluZyBpdCBhbGwgaW50byBh biBhcHBlbmRpeCBvZiB0aGUgU2VjdXJpdHkgZHJhZnQsIHNpbmNlIGl0IGlzIA0KPj4gc29ydCBv ZiBoYW5keSB0byBoYXZlIGl0IGFsbCBpbiBvbmUgcGxhY2UuIEJ1dCBhcyBMb3UgcG9pbnRlZCBv dXQgdG8gDQo+PiBtZSwgd2UgZG9uJ3Qgd2FudCB0byBtYWtlIHRoZSBkcmFmdHMgZGVwZW5kZW50 IG9uIGVhY2ggb3RoZXIgaWYgd2UgDQo+PiBjYW4gYXZvaWQgaXQsIGFuZCBpZiBzdWNoIHRleHQg Z290IGVkaXRlZCB0aGVuIGl0IHdvdWxkIGhhdmUgdG8gYmUgDQo+PiBmaXhlZCBpbiB0d28gcGxh Y2VzLCBzbyBpdCBpc24ndCBhIHBlcmZlY3Qgc2NoZW1lLiBJIHdvdWxkIHNheSB0aGF0IA0KPj4g aWYgYSBkcmFmdCBhdXRob3Igd2FudHMgdG8gd3JpdGUgdGhlaXIgb3duIHNlY3VyaXR5LXJlbGF0 ZWQgdGV4dCBpbiANCj4+IHRoZWlyIG93biBkcmFmdCBtb3JlIHBvd2VyIHRvIHRoZW0sIGJ1dCBw ZXJoYXBzIGV2ZW4gbW9yZSBwb3dlciBpZiANCj4+IHRoZXkgYnJpbmcgaXQgdG8gdGhlIFNlY3Vy aXR5IGRyYWZ0IDotICkNCj4+DQo+PiBTb3JyeSBsb25nIGFuc3dlciB0byBhIHNob3J0IHF1ZXN0 aW9uLiBBbmQgSSdtIHN1cmUgdGhlcmUgYXJlIG90aGVyIHN0cmF0ZWdpZXMuLi4gSWYgeW91IGhh dmUgYW55IHRob3VnaHRzIG9uIHRoZSBtYXR0ZXIgSSdkIGxvdmUgdG8gaGVhciB0aGVtLCBlaXRo ZXIgb24gdGhlIGxpc3Qgb3IgYXQgSUVURiAxMDMuDQo+PiBFdGhhbi4NCj4+DQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0K Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAyMDE4IDEyOjEwIEFNDQo+PiBUbzogR3Jv c3NtYW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9sYnkuY29tPg0KPj4gQ2M6IGRldG5ldEBpZXRmLm9y Zw0KPj4gU3ViamVjdDogUmU6IFtEZXRuZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGV0bmV0 LXNlY3VyaXR5LTAzLnR4dA0KPj4NCj4+IEV0aGFuLA0KPj4NCj4+IEkgaGF2ZSBqdXN0IGhhZCBh IHF1aWNrIGxvb2ssIGJ1dCB3aGF0IEkgc2VlIGxvb2tzIGdvb2QsIGFuZCBjZXJ0YWlubHkgZ2l2 ZXMgYSBnb29kIG92ZXJ2aWV3IG9mIHRoZSBkZXRuZXQgc2VjdXJpdHkgaXNzdWVzLg0KPj4NCj4+ IE9uZSBxdWVzdGlvbiwgaXMgaXQgdGhlIGludGVudGlvbiB0aGF0IHRoaXMgZG9jdW1lbnQgc2hv dWxkIGJlIHVzZWQgYXMgYSBnZW5lcmFsIHJlZmVyZW5jZSB3aGVuIHdyaXRpbmcgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgZm9yIGRldG5ldCBkb2N1bWVudHM/DQo+Pg0KPj4gL0xvYQ0KPj4NCj4+ IE9uIDIwMTgtMTAtMTcgMTI6MDUsIEdyb3NzbWFuLCBFdGhhbiBBLiB3cm90ZToNCj4+PiBIaSBB bGwsDQo+Pj4gVGhpcyBub3RlIGlzIHRoZSBzdGF0dXMgdXBkYXRlIGZvciB0aGUgRGV0TmV0IFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIGRyYWZ0IGluIGFkdmFuY2Ugb2YgSUVURiAxMDMsIGluIGxp ZXUgb2YgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgaXQgYXQgSUVURiAxMDMuDQo+Pj4NCj4+PiBB IG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCB3aGljaCBpbmNsdWRlcyB0aGUgZGlzY3Vzc2lv biBvbiBPQU0gdHJhZmZpYyBhbmQgaW5jb3Jwb3JhdGVzIHRoZSAiQm91bmRlZCBKaXR0ZXIiIFVz ZSBDYXNlIENvbW1vbiBUaGVtZS4NCj4+Pg0KPj4+IFRoZXNlIGFyZSBtaW5vciBjaGFuZ2VzOyBu byBzdWJzdGFudGlhbCB3b3JrIGhhcyBiZWVuIGRvbmUgc2luY2UgdGhlIGxhc3QgRGV0TmV0IHNl c3Npb24sIHNvIHdlIGRvIG5vdCBwbGFuIHRvIGhhdmUgYSBzbG90IGZvciB0aGlzIGRyYWZ0IGF0 IHRoZSBJRVRGIDEwMyBEZXROZXQgc2Vzc2lvbiAodGhvdWdoIFRhbCB3aWxsIGJlIHByZXNlbnRp bmcgb24gaXQgYXQgdGhlIERldE5ldC1UU04gbWVldGluZyBvbiB0aGUgZm9sbG93aW5nIFN1bmRh eSkuDQo+Pj4NCj4+PiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgY29udmVuZSBhcyBtYW55IG9mIHRo ZSBhdXRob3JzIChhbmQgYW55IG90aGVyIGludGVyZXN0ZWQgcGFydGllcykgYXMgd2UgaGF2ZSBh dmFpbGFibGUgYXQgSUVURiAxMDMgdG8gZGlzY3VzcyBEZXROZXQtZGF0YS1wbGFuZS10ZWNobm9s b2d5LXNwZWNpZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBob3cgdG8gaW5jb3Jwb3Jh dGUgdGhlbSBpbnRvIHRoZSBkcmFmdCBhcyBvdXIgbmV4dCBzdGVwcy4gSWYgeW91IHdvdWxkIGxp a2UgdG8gcGFydGljaXBhdGUgaW4gKGJlIG5vdGlmaWVkIGFib3V0KSB0aGlzIGNvbnZlcnNhdGlv biwgcGxlYXNlIGxldCBtZSBrbm93Lg0KPj4+DQo+Pj4gQmVzdCwNCj4+PiBFdGhhbiAoYXMgRGV0 TmV0IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGRyYWZ0IGVkaXRvcikNCj4+Pg0KPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIA0KPj4+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4+ IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTggODo1MSBQTQ0KPj4+IFRvOiBpLWQtYW5u b3VuY2VAaWV0Zi5vcmcNCj4+PiBDYzogZGV0bmV0QGlldGYub3JnDQo+Pj4gU3ViamVjdDogW0Rl dG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0DQo+Pj4N Cj4+Pg0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgV0cgb2YgdGhlIElFVEYuDQo+ Pj4NCj4+PiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IERldGVybWluaXN0aWMgTmV0d29y a2luZyAoRGV0TmV0KSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPj4+ICAgICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogVGFsIE1penJhaGkNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEV0aGFuIEdyb3NzbWFuDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbmRy ZXcgSi4gSGFja2VyDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJpciBEYXMN Cj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4gRG93ZGVsbA0KPj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSGVucmlrIEF1c3RhZA0KPj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgS2V2aW4gU3RhbnRvbg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTm9ybWFuIEZpbm4NCj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kZXRu ZXQtc2VjdXJpdHktMDMudHh0DQo+Pj4gCVBhZ2VzICAgICAgICAgICA6IDQwDQo+Pj4gCURhdGUg ICAgICAgICAgICA6IDIwMTgtMTAtMTYNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICAgICAgIEEg ZGV0ZXJtaW5pc3RpYyBuZXR3b3JrIGlzIG9uZSB0aGF0IGNhbiBjYXJyeSBkYXRhIGZsb3dzIGZv ciByZWFsLQ0KPj4+ICAgICAgIHRpbWUgYXBwbGljYXRpb25zIHdpdGggZXh0cmVtZWx5IGxvdyBk YXRhIGxvc3MgcmF0ZXMgYW5kIGJvdW5kZWQNCj4+PiAgICAgICBsYXRlbmN5LiAgRGV0ZXJtaW5p c3RpYyBuZXR3b3JrcyBoYXZlIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkIGluDQo+Pj4gICAg ICAgcmVhbC10aW1lIG9wZXJhdGlvbmFsIHRlY2hub2xvZ3kgKE9UKSBhcHBsaWNhdGlvbnMgZm9y IHNvbWUgeWVhcnMNCj4+PiAgICAgICAoZm9yIGV4YW1wbGUgW0FSSU5DNjY0UDddKS4gIEhvd2V2 ZXIsIHN1Y2ggbmV0d29ya3MgYXJlIHR5cGljYWxseQ0KPj4+ICAgICAgIGlzb2xhdGVkIGZyb20g ZXh0ZXJuYWwgYWNjZXNzLCBhbmQgdGh1cyB0aGUgc2VjdXJpdHkgdGhyZWF0IGZyb20NCj4+PiAg ICAgICBleHRlcm5hbCBhdHRhY2tlcnMgaXMgbG93LiAgSUVURiBEZXRlcm1pbmlzdGljIE5ldHdv cmtpbmcgKERldE5ldCkNCj4+PiAgICAgICBzcGVjaWZpZXMgYSBzZXQgb2YgdGVjaG5vbG9naWVz IHRoYXQgZW5hYmxlIGNyZWF0aW9uIG9mIGRldGVybWluaXN0aWMNCj4+PiAgICAgICBuZXR3b3Jr cyBvbiBJUC1iYXNlZCBuZXR3b3JrcyBvZiBwb3RlbnRpYWxseSB3aWRlIGFyZWEgKG9uIHRoZSBz Y2FsZQ0KPj4+ICAgICAgIG9mIGEgY29ycG9yYXRlIG5ldHdvcmspIHBvdGVudGlhbGx5IGJyaW5n aW5nIHRoZSBPVCBuZXR3b3JrIGludG8NCj4+PiAgICAgICBjb250YWN0IHdpdGggSW5mb3JtYXRp b24gVGVjaG5vbG9neSAoSVQpIHRyYWZmaWMgYW5kIHNlY3VyaXR5IHRocmVhdHMNCj4+PiAgICAg ICB0aGF0IGxpZSBvdXRzaWRlIG9mIGEgdGlnaHRseSBjb250cm9sbGVkIGFuZCBib3VuZGVkIGFy ZWEgKHN1Y2ggYXMNCj4+PiAgICAgICB0aGUgaW50ZXJuYWxzIG9mIGFuIGFpcmNyYWZ0KS4gIFRo ZXNlIERldE5ldCB0ZWNobm9sb2dpZXMgaGF2ZSBub3QNCj4+PiAgICAgICBwcmV2aW91c2x5IGJl ZW4gZGVwbG95ZWQgdG9nZXRoZXIgb24gYSB3aWRlIGFyZWEgSVAtYmFzZWQgbmV0d29yaywNCj4+ PiAgICAgICBhbmQgdGh1cyBjYW4gcHJlc2VudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0 IG1heSBiZSBuZXcgdG8gSVAtDQo+Pj4gICAgICAgYmFzZWQgd2lkZSBhcmVhIG5ldHdvcmsgZGVz aWduZXJzLiAgVGhpcyBkcmFmdCwgaW50ZW5kZWQgZm9yIHVzZSBieQ0KPj4+ICAgICAgIERldE5l dCBuZXR3b3JrIGRlc2lnbmVycywgcHJvdmlkZXMgaW5zaWdodCBpbnRvIHRoZXNlIHNlY3VyaXR5 DQo+Pj4gICAgICAgY29uc2lkZXJhdGlvbnMuICBJbiBhZGRpdGlvbiwgdGhpcyBkcmFmdCBjb2xs ZWN0cyBhbGwgc2VjdXJpdHktDQo+Pj4gICAgICAgcmVsYXRlZCBzdGF0ZW1lbnRzIGZyb20gdGhl IHZhcmlvdXMgRGV0TmV0IGRyYWZ0cyAoQXJjaGl0ZWN0dXJlLCBVc2UNCj4+PiAgICAgICBDYXNl cywgZXRjKSBpbnRvIGEgc2luZ2xlIGxvY2F0aW9uIFNlY3Rpb24gNy4NCj4+Pg0KPj4+DQo+Pj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJp dHkvDQo+Pj4NCj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXNl Y3VyaXR5LTAzDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMw0KPj4+DQo+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZp b3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMw0KPj4+DQo+Pj4NCj4+PiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4NCj4+PiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPj4+IGRl dG5ldEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGV0bmV0DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+PiBkZXRuZXRAaWV0Zi5vcmcNCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPj4+DQo+Pg0K PiANCg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWls OiBsb2FAcGkubnUNClNlbmlvciBNUExTIEV4cGVydA0KQnJvbnplIERyYWdvbiBDb25zdWx0aW5n ICAgICAgICAgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Fri Oct 19 12:04:38 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F02AC1310CC; Fri, 19 Oct 2018 11:56:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: detnet@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540297.6592.5161843222482609012.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:42 -0700 Archived-At: Subject: [Detnet] detnet - Requested session has been scheduled for IETF 103 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:51 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. detnet Session 1 (2:00 requested) Thursday, 8 November 2018, Afternoon Session I 1350-1550 Room Name: Chitlada 2 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/detnet.ics Request Information: --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: pce teas ccamp netmod mpls Second Priority: rtgwg pals bess lsr tsvwg Third Priority: nvo3 People who must be present: Lou Berger David L. Black Deborah Brungard Janos Farkas Ethan Grossman Resources Requested: Special Requests: Later in the week is preferred as we have the joint meeting with IEEE on Sunday following IETF. --------------------------------------------------------- From nobody Fri Oct 19 12:10:43 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7A1310BD for ; Fri, 19 Oct 2018 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9QlaUEo5I7i for ; Fri, 19 Oct 2018 12:10:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EF172131084 for ; Fri, 19 Oct 2018 12:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539976230; x=1542568230; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kii7tlhJ1XzQxNH+/bHF+//l9ek28SLhu+zMpS/Kzh4=; b=Dg78ZAra8RxBbXoM+Rk+spfW+0Qz6s2xly5NVnwQTEV3yXWTMDEb750BzMSIgLd+ hHl3bNm5CRvO7kUqEXXzvIMT1GGXaRwUNxk4nb7jiOWFerY+F5hZifhrYvAkaUn8 sA9CzjMsjnyalsZWJFLhNqQweaVUCmYn/shWL6lzO3E=; X-AuditID: c1b4fb25-55bff700000018b4-34-5bca2c261a07 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.18.06324.62C2ACB5; Fri, 19 Oct 2018 21:10:30 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 21:10:29 +0200 Received: from [100.94.32.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.192) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 21:10:29 +0200 References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Joel Halpern CC: , , DetNet WG , X-Forwarded-Message-Id: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> Message-ID: Date: Fri, 19 Oct 2018 21:10:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> Content-Type: multipart/alternative; boundary="------------C384341DC509DCF28E761FE9" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbG9UldN51S0wZnz/Ba/P81msdg3axOL xdVXn1ksnm2cz2Lx8dQbJgdWjyVLfjJ5nJvynTGAKYrLJiU1J7MstUjfLoErY++VdWwFrY2M FT27L7A1MO5M7mLk5JAQMJFY8vsecxcjF4eQwFFGiQmNC9lAEkIC3xglps1jhUgcZpRYc/kc C0hCWMBT4u3mSUAJDqCEvcT9k0ogYTYg8+6lDcwgtoiAmsSlvTvASpgFSiXOfRYCMSUEvCUm LHQFqeAFqv7b0A42kEVAVaJ56RFGEFtUIFbi05XFzBA1ghInZz4Bq+EUcJCYuOY4E4jNLBAm sfbRTWYIW1zi1pP5TBAXq0l8evuQfQKj0Cwk7bOQtMxC0gJhW0jMnH+eEcKWl9j+dg5UjYZE 65y57MjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtDBLb9VdzBefuN4iFGAg1GJ h/cUz6loIdbEsuLK3EOMEhzMSiK8iqUno4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUk kJ5YkpqdmlqQWgSTZeLglGpgDD3DZHf09896vat9q39rlPm+O3Fx2gs95RlBc+0dBdZ94nXu W3fpn+aONccP6Lzc+Wdn9xm7efum8vYucVA3DlzPkXW9IO1+zL7C43dX9wqttLX1Vc5dNMfO YvFhsxirvkUPP5zxe6WVkrRPyo2Bbfe8km8T107hE6tk3XrO3ff01ou8Z7dXHVZiKc5INNRi LipOBADCKNT3nQIAAA== Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 19:10:41 -0000 --------------C384341DC509DCF28E761FE9 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Joel, Thank you very much for your review! Please find below in-line responses and how we plan to update the draft to resolve your comments. Best regards, Janos On 9/22/2018 2:59 AM, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-detnet-architecture-08 > Reviewer: Joel Halpern > Review Date: 2018-09-20 > IETF LC End Date: 2018-10-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as a Proposed Standard > > I presume that the status was selected so as to avoid the need for downrefs > when other Detnet documents normatively reference this one? > > Major issues: N/A > > Minor issues: > Section 3.1 states that worst case delay for priority queueing is > unbounded. That does not match my understanding. I know that DelayBound > DSCP behavior tightly (although, I think, not as tightly as Detnet) limits > both the worst case delay and the delay variation. Strict priority is not good enough for DetNet. A high priority packet may need to wait until the transmission of a lower priority packet is finished at an outbound port, which can cause too much uncertainties in the network. > > It seems very odd that section 3.2.1.1 says that DetNet flows can not be > throttled when earlier text says that DetNet flows do have a maximum > bandwidth. Buried in section 4.3.2 I find that what is meant by throttled > is not "enforcing a rate limit", but rather "sending congestion > notification to cause the source to slow down." I think the wording about > "can not be throttled" both in 3.2.1.1 and 4.3.2 should be adjusted for > clarity. The text will be updated to clarify. Section 3.2.1.1: OLD: The primary means by which DetNet achieves its QoS assurances is to reduce, or even completely eliminate, congestion within a node as a cause of packet loss. Given that a DetNet flow cannot be throttled, this can be achieved only by the provision of sufficient buffer storage at each hop through the network to ensure that no packets are dropped due to a lack of buffer storage. NEW: The primary means by which DetNet achieves its QoS assurances is to reduce, or even completely eliminate, congestion within a node as a cause of packet loss. This can be achieved only by the provision of sufficient buffer storage at each hop through the network to ensure that no packets are dropped due to a lack of buffer storage. Note that a DetNet flow cannot be throttled, i.e., its transmission rate cannot be reduced via explicit congestion notification. Section 4.3.2: OLD: There is no provision in DetNet for throttling DetNet flows (reducing end-to-end transmission rate via any explicit congestion notification); the assumption is that a DetNet flow, to be useful, must be delivered in its entirety. NEW: There is no provision in DetNet for throttling DetNet flows, i.e., the transmission rate cannot be reduced via explicit congestion notification. The assumption is that a DetNet flow, to be useful, must be delivered in its entirety. > 3.2.1.1 also reads oddly in that it seems to recommend providing > significant buffering, when the need for and use of such buffers is a major > source of jitter. The next paragraph in 3.2.1.1 explains that the buffers have to be adequately designed, which keeps under control the delay and jitter that can be caused by buffering: "Ensuring adequate buffering requires, in turn, that the source, and every DetNet node along the path to the destination (or nearly every node, see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow." > In section 4.1.2, I realized that the Detnet Transit node terminology had > mildly confused me. The text says "DetNet enabled nodes are interconnected > via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet > service aware." Reading this, and the definitions in section 2.1, it > appears that a Detnet Transit node is a node that is providing transport > behavior that detnet needs, but is not actually modified for detnet. Based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, the phrase "DetNet enabled nodes" is removed from the document and it has been made clear what type of DetNet node is meant: The text is updated to: A "Deterministic Network" will be composed of DetNet enabled end systems, DetNet edge nodes, DetNet relay nodes and collectively deliver DetNet services. DetNet relay and edge nodes are interconnected via DetNet transit nodes (e.g., LSRs) which support DetNet, but are not DetNet service aware. > Section 4.4.2 talks about per flow per node state. It would be good to > have a forward reference to section 4.9 about scaling to larger networks. Forward reference will be added. > Nits/editorial comments: > It would be good if there were some explanation for the 75% maximum number > in section 3.3.1. That there is some limit seems intuitive. What value > that limit has is not so obvious. 75% is been removed based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html. > Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as > part of labeling. There is no earlier explanation of the use of an > Ethernet MAC Multicast destination, and the text does not seem to require > that the traffic be actually multicast. Hence the reader is liable to be > confused by the reference to multicast. I rate this only a nit as it seems > clear that this is an example whose details are presumably explained in > another document. Still, it would help to clarify the example. > > Multicast MAC address is removed based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, --------------C384341DC509DCF28E761FE9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Joel,

    Thank you very much for your review!

    Please find below in-line responses and how we plan to update the draft to resolve your comments.

    Best regards,
    Janos


    On 9/22/2018 2:59 AM, Joel Halpern wrote:
    Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-detnet-architecture-08
Reviewer: Joel Halpern
Review Date: 2018-09-20
IETF LC End Date: 2018-10-03
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard

I presume that the status was selected so as to avoid the need for downrefs
when other Detnet documents normatively reference this one?

Major issues: N/A

Minor issues:
    Section 3.1 states that worst case delay for priority queueing is
    unbounded.  That does not match my understanding.  I know that DelayBound
    DSCP behavior tightly (although, I think, not as tightly  as Detnet) limits
    both the worst case delay and the delay variation.
    Strict priority is not good enough for DetNet. A high priority packet may need to wait until the transmission of a lower priority packet is finished at an outbound port, which can cause too much uncertainties in the network. 

    
    It seems very odd that section 3.2.1.1 says that DetNet flows can not be
    throttled when earlier text says that DetNet flows do have a maximum
    bandwidth.  Buried in section 4.3.2 I find that what is meant by throttled
    is not "enforcing a rate limit", but rather "sending congestion
    notification to cause the source to slow down."  I think the wording about
    "can not be throttled" both in 3.2.1.1 and 4.3.2 should be adjusted for
    clarity.
    The text will be updated to clarify.

    Section 3.2.1.1:

    OLD:
    The primary means by which DetNet achieves its QoS assurances is to
    reduce, or even completely eliminate, congestion within a node as a
    cause of packet loss. Given that a DetNet flow cannot be throttled,
    this can be achieved only by the provision of sufficient buffer
    storage at each hop through the network to ensure that no packets are
    dropped due to a lack of buffer storage.

    NEW:
    The primary means by which DetNet achieves its QoS assurances is to
    reduce, or even completely eliminate, congestion within a node as a
    cause of packet loss. This can be achieved only by the provision of
    sufficient buffer storage at each hop through the network to ensure
    that no packets are dropped due to a lack of buffer storage. Note that
    a DetNet flow cannot be throttled, i.e., its transmission rate cannot be
    reduced via explicit congestion notification.


    Section 4.3.2:

    OLD:
    There is no provision in DetNet for throttling DetNet flows (reducing
    end-to-end transmission rate via any explicit congestion
    notification); the assumption is that a DetNet flow, to be useful,
    must be delivered in its entirety.

    NEW:
    There is no provision in DetNet for throttling DetNet flows, i.e.,
    the transmission rate cannot be reduced via explicit congestion
    notification. The assumption is that a DetNet flow, to be useful,
    must be delivered in its entirety.

        3.2.1.1 also reads oddly in that it seems to recommend providing
    significant buffering, when the need for and use of such buffers is a major
    source of jitter.

    The next paragraph in 3.2.1.1 explains that the buffers have to be adequately designed, which keeps under control the delay and jitter that can be caused by buffering:

    "Ensuring adequate buffering requires, in turn, that the source, and
    every DetNet node along the path to the destination (or nearly every
    node, see Section 4.3.3) be careful to regulate its output to not
    exceed the data rate for any DetNet flow, except for brief periods
    when making up for interfering traffic. Any packet sent ahead of its
    time potentially adds to the number of buffers required by the next
    hop DetNet node and may thus exceed the resources allocated for a
    particular DetNet flow."



        In section 4.1.2, I realized that the Detnet Transit node terminology had
    mildly confused me.  The text says "DetNet enabled nodes are interconnected
    via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet
    service aware."  Reading this, and the definitions in section 2.1, it
    appears that a Detnet Transit node is a node that is providing transport
    behavior that detnet needs, but is not actually modified for detnet.
    Based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, the phrase "DetNet enabled nodes" is removed from the document and it has been made clear what type of DetNet node is meant:
    The text is updated to:
       A "Deterministic Network" will be composed of DetNet enabled end
   systems, DetNet edge nodes, DetNet relay nodes and collectively
   deliver DetNet services.  DetNet relay and edge nodes are
   interconnected via DetNet transit nodes (e.g., LSRs) which support
   DetNet, but are not DetNet service aware. 


        Section 4.4.2 talks about per flow per node state.  It would be good to
    have a forward reference to section 4.9 about scaling to larger networks.
    Forward reference will be added.

    Nits/editorial comments:
     It would be good if there were some explanation for the 75% maximum number
     in section 3.3.1.  That there is some limit seems intuitive.  What value
     that limit has is not so obvious.
    75% is been removed based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html.

        Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as
    part of labeling.  There is no earlier explanation of the use of an
    Ethernet MAC Multicast destination, and the text does not seem to require
    that the traffic be actually multicast.  Hence the reader is liable to be
    confused by the reference to multicast.  I rate this only a nit as it seems
    clear that this is an example whose details are presumably explained in
    another document.    Still, it would help to clarify the example.
    Multicast MAC address is removed based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html,
    --------------C384341DC509DCF28E761FE9-- From nobody Fri Oct 19 12:18:38 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BEE1310BC; Fri, 19 Oct 2018 12:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klNFydam4QfC; Fri, 19 Oct 2018 12:18:25 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (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 AB6AF131125; Fri, 19 Oct 2018 12:17:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 617B73707A1; Fri, 19 Oct 2018 12:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1539976656; bh=emabXK/UdYu/zjHSv+GK3JqD2Z0G09U7kZ0ZwxECi3Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fgWfwsE9m/txl1asf/gUCV9zMpv+WHdFc0ZlZIUpEcx1VSJtCOOUK6IPI5eWUL5oB PC5Zuk4T+RTXFYES9eHGZs0QfDcJeGv9KSfwzVIOAw8+ndsiOEb7EXBuNfbR6A1Sma Dk0RUGHOLqdhPG4qKD2PhNqM3hljJU3iJcQLulkw= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 87AFA360174; Fri, 19 Oct 2018 12:17:35 -0700 (PDT) To: =?UTF-8?Q?J=c3=a1nos_Farkas?= Cc: gen-art@ietf.org, draft-ietf-detnet-architecture.all@ietf.org, DetNet WG , ietf@ietf.org References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 19 Oct 2018 15:17:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 19:18:35 -0000 Thank you Janos. Two clarifications under retained text, with the rest elided. Yours, Joel On 10/19/18 3:10 PM, János Farkas wrote: ... > On 9/22/2018 2:59 AM, Joel Halpern wrote: ... >> Minor issues: >> Section 3.1 states that worst case delay for priority queueing is >> unbounded. That does not match my understanding. I know that DelayBound >> DSCP behavior tightly (although, I think, not as tightly as Detnet) limits >> both the worst case delay and the delay variation. > Strict priority is not good enough for DetNet. A high priority packet > may need to wait until the transmission of a lower priority packet is > finished at an outbound port, which can cause too much uncertainties in > the network. I understand that strict priority queueing is viewed as insufficient. I wasn;t arguing about that. I was arguing with the use of the word "unbounded". As far as I can tell, with suitable priority queueing the worst case delay is bounded, simply not well enough bounded. ... >> In section 4.1.2, I realized that the Detnet Transit node terminology had >> mildly confused me. The text says "DetNet enabled nodes are interconnected >> via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet >> service aware." Reading this, and the definitions in section 2.1, it >> appears that a Detnet Transit node is a node that is providing transport >> behavior that detnet needs, but is not actually modified for detnet. > Based on last call comments: > https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, the > phrase "DetNet enabled nodes" is removed from the document and it has > been made clear what type of DetNet node is meant: > The text is updated to: > > A "Deterministic Network" will be composed of DetNet enabled end > systems, DetNet edge nodes, DetNet relay nodes and collectively > deliver DetNet services. DetNet relay and edge nodes are > interconnected via DetNet transit nodes (e.g., LSRs) which support > DetNet, but are not DetNet service aware. Any chance you could simply say "transit nodes" instead of "DetNet transit nodes? As far as I can tell, they are existing nodes that were designed and implemented (and even configured) potentially before DetNet was even defined? ... From nobody Fri Oct 19 12:20:21 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58091310F0 for ; Fri, 19 Oct 2018 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vUKzAGGhlVM for ; Fri, 19 Oct 2018 12:20:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E30511310D6 for ; Fri, 19 Oct 2018 12:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539976789; x=1542568789; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=izZdGBdcmpsetz3sO08wNcb9lqe6lYJ0sEhznWpM/20=; b=bq+j3GoLDs/kkSizB3O63W8XECF0KXsFTkTEbrOJlhasy9hYqT8zNvysAS+Zm+yA IPYqu92NKIjjQCWcphkVdP7mpox8LWAAZ/tIXHZiTeGT0qIsEinjVHcOr43CWQKb +9BVBmlFzb6x/d+BmWrLFhGsuM0QkPBn/k1+FvynU+0=; X-AuditID: c1b4fb30-2d3ff700000047d2-8e-5bca2e552ece Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.CE.18386.55E2ACB5; Fri, 19 Oct 2018 21:19:49 +0200 (CEST) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB502.ericsson.se (153.88.183.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 21:19:48 +0200 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 21:19:48 +0200 Received: from [100.94.32.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 21:19:46 +0200 References: From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Henning Rogge CC: , , "Pascal Thubert (pthubert)" , =?UTF-8?Q?Bal=c3=a1zs_Varga_A?= X-Forwarded-Message-Id: Message-ID: <023e158d-3e5c-048d-8df5-6ac6d1836262@ericsson.com> Date: Fri, 19 Oct 2018 21:19:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbG9QjdU71S0wZr5fBa/P81msZi+YD2r xbKjp5ksZkx5x+jA4jHl90ZWj52z7rJ7LFnyk8ljx+YHrAEsUVw2Kak5mWWpRfp2CVwZu7af ZC1YpFKx6fQjxgbGlbJdjJwcEgImEtfvrGQGsYUEjjJKfDrMCmF/Y5TYdNq3i5ELwr7dNZMF wjnMKLHxzhp2kCphAXuJmQebobrtJbavmMwIYrMB2XcvbQCLiwioSHQdXswI0swssJpRYsWU V4wQq70lfv+cy9bFyMHBC9Rw/WYcSJhFQFVi94EvYL2iArESn64sBrN5BQQlTs58wgJicwo4 SDw4+o8JxGYWsJCYOf88I4QtL7H97RxmCFtc4taT+UwQt6lJvG+4wziBUWQWklGzkLTPQtI+ C0n7AkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBkXNwy2+DHYwvnzseYhTgYFTi4eXh PhUtxJpYVlyZe4hRgoNZSYRXsfRktBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeC7/NUUIC6Ykl qdmpqQWpRTBZJg5OqQbGHskbW+2PKXWzfLQ4kWJQ9aLu67HTH2SYak1P7tt/UPnKhProGAm/ 9wdP/jncMCVH7trSjkhXuwBFuY0+34rLM5h05qo7flD6IXvw0tWkGaK/2v26fit68827FqyX cFKt7VNfPLvY0d6lQvpJNfevSXp3fXZep6l73f/eo2Pt9ucWKG3qaC9TYinOSDTUYi4qTgQA 3MstWJgCAAA= Archived-At: Subject: [Detnet] Fwd: Re: Last Call Review for ietf-detnet architecture X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 19:20:20 -0000 Hi Henning, Thank you very much for your review! Please find below in-line responses and how we will update the draft to resolve your comments. Best regards, Janos On 10/10/2018 3:13 PM, Henning Rogge wrote: > Hi, > > I was asked to do a last-call review for the detnet architecture 08 > draft... sorry for the delay. > > I think the draft provides a good overview what detnet wants to do. > When read in order, some chapters seem to skip a few points that get > included in later chapters (in a different context), but I think this > should be easy to fix. > > Here are some comments to the draft that came to my mind during reading it: > > > > Detnet Relay Node (Page 5) > > can be bridge (which should be layer2), but Detnet operates on IP layer? bridge is removed based on last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01790.html > > Congestion Protection (Page 8) > > Does Detnet differenciate between limited network capabilities because > of media access and datarate? In some networks you might hit a "packet > per time" limit before you hit the "byte per time" limit, which is > mostly solved by aggregating multiple packets. > > > Explicit Routes (Page 8) > > Does this mean DetNet normally uses a "frozen" state of a route, e.g. > a snapshot of a routing protocol? What happens if the route does not > apply anymore (maybe this is out-of-scope for DetNet)? These issues are solved by explicit routing techniques. For instance, explicit routes are used with PREOF. If one of the routes go down, then the other one remains. The broken route is then changed/updated by explicit routing techniques, e.g., by a central network controller. DetNet only refers to explicit routing techniques specified by other IETF WGs, DetNet does not specify explicit routing details; it is out of scope for DetNet. > > Sufficient buffer (Page 10) > > "Sufficient buffer" also can give you a higher amount of latency. If > for whatever reason a packet arrives "too late", it might be better to > drop it to recover the realtime behavior of the following packets > (assuming more allocated bandwidth than necessary). This is explained > in page 15 (3.3.2. Fault Mitigation) I think. The next paragraph in 3.2.1.1 explains that the buffers have to be adequately designed, which keeps under control the delay and jitter that can be caused by buffering: "Ensuring adequate buffering requires, in turn, that the source, and every DetNet node along the path to the destination (or nearly every node, see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow." > > Extra Buffering for different-length paths (Page 13) > > This sounds like another point where additional latency might appear. It is additional latency, but it is deterministic latency. > > Reduction of available bandwidth for non-DetNet packets (Page 15) > > ... and increased latency. > (Mixing DetNet and non-DetNet packets sounds quite difficult if you > want to keep all guarantees of DetNet) Correct. Updates will be made to clarify along last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html > > DetNet data plane protocol stack (Page 18) > > How does this diagram mesh with the standard stack layers? Are IP/MAC > all "lower Layers" ? > Updates will be made to clarify along last call comments: https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html > DetNet adaptation to data plane (Page 19) > > Figure 4 reads like the combination of UDP and IP (with static routes > set) would be okay for DetNet under certain circumstances... no > "hop-by-hop" userspace (DetNet)-processing required? The data plane forwarding avoids user space processing. The details are in the data plane documents: https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-mpls/ https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/ > > Synchronous DetNet (Page 24) > > I feel that the most important advantage of this would be the > collision-free usage of the shared links between the DetNet nodes, > which helps to keep the Latency to a lower limit. Yes, if synchronization is available, then more can be done, e.g., time-based scheduling techniques can be used. > > Henning Rogge From nobody Fri Oct 19 12:42:25 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7109C130DD1 for ; Fri, 19 Oct 2018 12:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcLb2RrpKyWl for ; Fri, 19 Oct 2018 12:42:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 EA6FF130DF9 for ; Fri, 19 Oct 2018 12:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539978139; x=1542570139; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tRErPwaeabmvmSkq7zN4gxByHaqNx40M2+KmTl5sM5w=; b=Q9Z+rQXAulVnkC3l1UNPDn7A2gAmAm762GQ8Xf3vdU/eJq5kSPVvWSX6aa06L8NY LozWOzH1RcKi3Q78V1+032NjrTbxkjsHQTE8u7NsqBG8SBAtjfQU41TY8ZSempSQ Yw/gchdW9lbCgwb/Ov/6Ba010+xrYhlSOHcwkkjcMns=; X-AuditID: c1b4fb30-2d3ff700000047d2-3c-5bca339be934 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.71.18386.B933ACB5; Fri, 19 Oct 2018 21:42:19 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 21:42:18 +0200 Received: from [100.94.32.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 21:42:18 +0200 To: Brian E Carpenter CC: "draft-ietf-detnet-architecture.all@ietf.org" , "detnet@ietf.org" , "db3546@att.com" References: From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <760f588d-be57-492b-1168-75c598ae2348@ericsson.com> Date: Fri, 19 Oct 2018 21:42:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM2J7le5s41PRBlMvcVq0XdzHZHG5q5vd 4ven2SwW+2ZtYnFg8XjZP4fRY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DK6HtmX/DTu2LN kh9sDYxTbbsYOTkkBEwk/l5/xtbFyMUhJHCUUWJ531Qo5xujxIqPR9ghnMOMEvt2fmUBcYQF 2hklunZeYgLpFxEwlmjsOs0KkmAWWM0o8fXZdTaQhJCAvsT/M8uZQWw2AXuJu5c2gNm8QPba 9zvAalgEVCVOPpkNNkhUIFbi05XFUDWCEidnPmEBsTkFDCSO/vnKCmIzC1hIzJx/nhHClpdo 3jqbGcIWl7j1ZD4TxF41iU9vH7JPYBSahWTULCTts5C0z0LSvoCRZRWjaHFqcVJuupGRXmpR ZnJxcX6eXl5qySZGYAwc3PLbYAfjy+eOhxgFOBiVeHh5uE9FC7EmlhVX5h5ilOBgVhLhVSw9 GS3Em5JYWZValB9fVJqTWnyIUZqDRUmc18Jvc5SQQHpiSWp2ampBahFMlomDU6qBccM9RTke 9/R4tSjduP1NXN/ef91w6si7c5c5gvKrlXzOPG7slVX1ui7WyDg76PfxGvfrIXEREmz/+PXr ovdd2fdgqhJ70KRbJ/0371nxevW5wJX2yxryCkOaOWJ//+bkm5+0fB//nC8MDbtcrn/1Kza/ UpjEOP/+qmVHtS8K3E61ebI6r8slRYmlOCPRUIu5qDgRAFmt7799AgAA Archived-At: Subject: Re: [Detnet] Last Call: (Deterministic Networking Architecture) to Proposed Standard X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 19:42:25 -0000 Hi Brian, Thank you very much for your review! Please find below more in-line on how we will update the draft to resolve your comments. Best regards, Janos On 9/24/2018 1:28 PM, Maik Seewald (maseewal) wrote: > Given the criticality of the use cases (IACS), authentication and > authorisation of the packet source appears to be imperative. > IMHO, applying security controls to the infrastructure elements only > crates a secure architecture for potential hostile traffic. > Application security might/will exist on-top, providing a multi-layer > approach. > > BR, Maik > > > On 24.09.18, 08:27, "detnet on behalf of Pascal Thubert (pthubert)" > > wrote: > >>>> Security must cover: >>>> >>>> o the protection of the signaling protocol >>>> >>>> o the authentication and authorization of the controlling systems >>>> >>>> o the identification and shaping of the DetNet flows >>> What about the identification and authorization of the nodes allowed to >>> generate DetNet flows within a domain, and of the border nodes at the >>> edges >>> of the domain? >>> >>> I'll let others comment on that one. I'm not clear about the >>> boundaries and the amount of overlap between network security and >>> application security, in this case. >> I agree with Brian; the source of the flow must be authenticated. I >> believe that a secure identification of the flow involves that, but it >> could make sense to emphasize this. >> What about: >> >>>> o the identification and shaping of the DetNet flows, including >>> authorization of the packet source >> Note: we have imposed that a flow has a single source and one or mane end >> points. There are MP2MP use cases in industrial. Unsure how to fully >> characterize them but the most basic methods are source A or source B, >> and source A and source B. The latter can be reserved as 2 independent >> DetNet flows, but the former needs methods that we do not have. >> >> Cheers; >> >> Pascal >> >>> -----Original Message----- >>> From: Norman Finn >>> Sent: lundi 24 septembre 2018 07:56 >>> To: Brian E Carpenter >>> Cc: draft-ietf-detnet-architecture.all@ietf.org; detnet@ietf.org; >>> db3546@att.com >>> Subject: RE: Last Call: >>> (Deterministic >>> Networking Architecture) to Proposed Standard >>> >>> Thanks for the comments, Brian. I'll try to respond; others will have >>> opinions, >>> I'm sure. See ________________________________________ >>> From: Brian E Carpenter [brian.e.carpenter@gmail.com] >>> Sent: Sunday, September 23, 2018 9:56 PM >>> Cc: draft-ietf-detnet-architecture.all@ietf.org; detnet@ietf.org; >>> db3546@att.com >>> Subject: Re: Last Call: >>> (Deterministic >>> Networking Architecture) to Proposed Standard >>> >>> Hi, >>> >>> The term "Flow-ID" is used frequently but is not defined or explained. >>> Section 4.7 "Flow identification at technology borders" doesn't really >>> help on >>> this. >>> >>> In fact, it isn't entirely clear what the word "flow" itself means. >>> You might think it's obvious, but when designing the rules for the >>> IPv6 Flow Label we stumbled until we got to this: >>> >>> From the viewpoint of the network layer, a flow is a sequence of >>> packets sent from a particular source to a particular unicast, >>> anycast, or multicast destination that a node desires to label as a >>> flow. >>> >>> In other words, a flow is whatever set of packets the source chooses to >>> assert >>> is a flow. Is that the DetNet definition too? >>> >>> In 2.1 we have, "A DetNet flow is a sequence of packets to >>> which the >>> DetNet service is to be provided." This could be expanded to, "A >>> DetNet flow >>> is a sequence of packets from one source to one or more destinations, >>> which >>> conform uniquely to a flow identifier, and to which the DetNet service >>> is to be >>> provided." The idea is that the process of creating a reservation for >>> a DetNet >>> flow always provides a means for unambiguously identifying to which >>> DetNet >>> flow, if any, a packet belongs. The definition will be updated as suggested by Norm. >>> >>> Also: >>>> The Flow-ID must be unique inside a given domain. >>> It isn't clear from the discussion of Flow-ID mapping whether this >>> implies that >>> the value of the upper layer (the deepest >>> encapsulated) Flow-ID is is intended to be preserved end-to-end. >>> It appears so from the examples in Figure 10 and Figure 11, but based >>> on the >>> experience that this has been a contentious point for the IPv6 Flow >>> Label, I >>> recommend that this should be clearly defined in the architecture. >>> >>> A better way to phrase the uniqueness requirement is that any >>> given >>> relay node must be able to unambiguously assign to a packet the >>> resources >>> reserved for that packet's DetNet flow. That's easiest if the >>> identifiers are >>> unique over domain, of course. I'd like to hear from others, on this. The sentence will be updated to make it clearer: OLD:    The Flow-ID must be unique inside a given domain.  Note that the    Flow-ID added to the App-flow is still present in the packet, but    transport nodes may lack the function to recognize it; that's why the    additional Flow-ID is added. NEW: "The Flow-ID must be unique inside a given domain. Note that the Flow-ID added to the App-flow by higher layer(s) is preserved in the packet, but transport nodes may lack the function to recognize it; that’s why the additional Flow-ID is added." >>> >>>> 3.2.1.1. "Eliminate congestion loss" >>> Shouldn't there be some discussion here about buffer bloat, which >>> serves to >>> reduce congestion loss but does terrible things to latency? The >>> discussion at >>> the beginning of Section 4.5 "Queuing, Shaping, Scheduling, and >>> Preemption" >>> doesn't make it clear how buffer bloat is avoided at large scale, where >>> many >>> DetNet flows are going through the same choke point. Having reserved >>> buffers >>> per flow doesn't prevent the total buffer space creeping up, and clever >>> queueing algorithms can't completely save you when that happens. >>> >>> As we are trying to make more clear in the bounded-latency draft, >>> one >>> of the characteristics of any queuing strategy that is useful for >>> DetNet is that >>> one can compute no later than flow reservation time how much buffer >>> space >>> is required to guarantee zero congestion loss. If you can't, then the >>> queuing >>> strategy is unsuitable. Different strategies make different trade-offs >>> regarding >>> buffer space, latency, data plane and control plane complexity, etc. >>> Generally >>> speaking, buffer space will grow with the number of flows visible to a >>> given >>> relay node. Flow aggregation is helpful, here, but one can expect a >>> DetNet >>> relay node to require more buffer space than a non-DetNet node. And, >>> if you >>> calculate that you haven't enough buffers to ensure zero congestion >>> loss, you >>> refuse the reservation.  The next paragraph in 3.2.1.1 explains that regulation is needed and applied, which actually avoids buffer bloat. "Ensuring adequate buffering requires, in turn, that the source, and every DetNet node along the path to the destination (or nearly every node, see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow. " A sentence will be added to the end of the paragraph to make it clearer: "Ensuring adequate buffering requires, in turn, that the source, and every DetNet node along the path to the destination (or nearly every node, see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow. The regulation ensures adequate use of the buffer space. " >>> >>>> Security must cover: >>>> >>>> o the protection of the signaling protocol >>>> >>>> o the authentication and authorization of the controlling systems >>>> >>>> o the identification and shaping of the DetNet flows >>> What about the identification and authorization of the nodes allowed to >>> generate DetNet flows within a domain, and of the border nodes at the >>> edges >>> of the domain? >>> >>> I'll let others comment on that one. I'm not clear about the >>> boundaries and the amount of overlap between network security and >>> application security, in this case. Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security. Reference will be added to the DetNet security document. >>> >>> Regards >>> Brian Carpenter >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet From nobody Fri Oct 19 13:05:51 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E101C130DD8 for ; Fri, 19 Oct 2018 13:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnObcn8gy50M for ; Fri, 19 Oct 2018 13:05:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A2F451293FB for ; Fri, 19 Oct 2018 13:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539979545; x=1542571545; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ro4grRJ8HCKnzBcxJR30vvpaAZjNa7nYrWBd23AhsTI=; b=Wn3aC2u4D4Wh34PHxd32kWiBhCk/t5Bn2tRhzIw+IV9ZhSqocCb1N4nRWVRuLXln DQWO5Mqaoc1Lelsz89ZGejeHsNeQ/gndWQ7eL6bNZIuDEooEqTeBgXYwArgFwx3J CIz2kWTsjPvjCp33F5UkvfH+nTZJRWC5dqEU1l4jI3A=; X-AuditID: c1b4fb3a-604d59e0000012ff-7f-5bca39195e92 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.96.04863.9193ACB5; Fri, 19 Oct 2018 22:05:45 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 22:05:32 +0200 Received: from [100.94.32.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 22:05:31 +0200 To: "Joel M. Halpern" CC: , , DetNet WG , References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com> Date: Fri, 19 Oct 2018 22:05:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2J7ua6k5alog7Uz2Cx+f5rNYrFv1iYW i6uvPrNYPNs4n8Xi46k3TA6sHkuW/GTyODflO2MAUxSXTUpqTmZZapG+XQJXxqLfp9kLvklV NLX6NjBeEe1i5OSQEDCReNyzjaWLkYtDSOAoo8Tybx/YIJxvjBI/Np2Ecg4zStw4tIIVpEVY wFPi7eZJYLaIgLbE/iUfmLoYOTiYBUolzn0Wgqhfxyixbk8LM0gNm4C9xN1LG8BsXiD7/aUm sF4WAVWJU2uOsoPYogKxEp+uLIaqEZQ4OfMJC4jNKeAs0bu7ASzOLGAhMXP+eUYIW16ieets qLi4xK0n85lAbCEBNYlPbx+yT2AUmoVk1Cwk7bOQtM9C0r6AkWUVo2hxanFxbrqRkV5qUWZy cXF+nl5easkmRmD4H9zy22oH48HnjocYBTgYlXh413CfihZiTSwrrsw9xCjBwawkwqtYejJa iDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWUkEB6YklqdmpqQWoRTJaJg1OqgXH20/KfQjLH rt7cxiLxUmZHoMDDnuenQy8s87c32SJ/PuhZZXCZSVxVzaFFtSsM+eOYH66f/JW5QPz5IucL 24vOnLrO0c722kvUW17x+r7JZhM75m36fXT2JE4Nhp1fK/85LBbekzmXa7746o3PjIWuv54e nCyscr0sWfwoa6Yod6qV637G/ENKLMUZiYZazEXFiQDeAIWYewIAAA== Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 20:05:50 -0000 Joel, Please see in-line. On 10/19/2018 9:17 PM, Joel M. Halpern wrote: > Thank you Janos.  Two clarifications under retained text, with the > rest elided. > > Yours, > Joel > > On 10/19/18 3:10 PM, János Farkas wrote: > ... >> On 9/22/2018 2:59 AM, Joel Halpern wrote: > ... >>> Minor issues: >>>      Section 3.1 states that worst case delay for priority queueing is >>>      unbounded.  That does not match my understanding.  I know that >>> DelayBound >>>      DSCP behavior tightly (although, I think, not as tightly as >>> Detnet) limits >>>      both the worst case delay and the delay variation. >> Strict priority is not good enough for DetNet. A high priority packet >> may need to wait until the transmission of a lower priority packet is >> finished at an outbound port, which can cause too much uncertainties >> in the network. > > I understand that strict priority queueing is viewed as insufficient.  > I wasn;t arguing about that.  I was arguing with the use of the word > "unbounded".  As far as I can tell, with suitable priority queueing > the worst case delay is bounded, simply not well enough bounded. We can make the sentence clearer: OLD: In general, a trivial priority-based queuing scheme will give better average latency to a data flow than DetNet, but of course, the worst- case latency can be essentially unbounded. NEW: In general, a trivial priority-based queuing scheme will give better average latency to a data flow than DetNet; however, it may be that the worst-case latency cannot be reasonably bounded for DetNet. > > ... >>>      In section 4.1.2, I realized that the Detnet Transit node >>> terminology had >>>      mildly confused me.  The text says "DetNet enabled nodes are >>> interconnected >>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>> not DetNet >>>      service aware."  Reading this, and the definitions in section >>> 2.1, it >>>      appears that a Detnet Transit node is a node that is providing >>> transport >>>      behavior that detnet needs, but is not actually modified for >>> detnet. >> Based on last call comments: >> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >> the phrase "DetNet enabled nodes" is removed from the document and it >> has been made clear what type of DetNet node is meant: >> The text is updated to: >> >>     A "Deterministic Network" will be composed of DetNet enabled end >>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>     deliver DetNet services.  DetNet relay and edge nodes are >>     interconnected via DetNet transit nodes (e.g., LSRs) which support >>     DetNet, but are not DetNet service aware. > > Any chance you could simply say "transit nodes" instead of "DetNet > transit nodes?  As far as I can tell, they are existing nodes that > were designed and implemented (and even configured) potentially before > DetNet was even defined? > > ... It has been pointed out during last call (https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html), to be specific on what node type is meant; and be consistent with terminology and definitions. DetNet transit node is a term defined by this document. So, it seems better to have DetNet transit node. Thank you! Best regards, Janos From nobody Sat Oct 20 03:12:22 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E51128CF3 for ; Sat, 20 Oct 2018 03:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnqecmNjaGcd for ; Sat, 20 Oct 2018 03:12:16 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA4B128A6E for ; Sat, 20 Oct 2018 03:12:16 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.168.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 86DBB180121E; Sat, 20 Oct 2018 12:12:11 +0200 (CEST) To: "Grossman, Ethan A." , Lou Berger , Deborah Brungard Cc: "detnet@ietf.org" , Daniel Harkins References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> From: Loa Andersson Message-ID: Date: Sat, 20 Oct 2018 18:12:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 10:12:21 -0000 Ethan, We had (have) a similar case in MPLS/GMPLS (RFC 5920) and MPLS-TP (RFC 6491), those framework serve as very good references, but have never been sufficient as just a reference. I think that the point that the SEC-DIR makes is that the authors (and the wg) of a new draft must be able to demonstrate that they have considered all the important security issues that relate to a particular draft. Yes - we need the security frameworks, but they will not be sufficient as a stand alone security consideration. My initial point was that, this intention should be captured in the draft. /Loa 2018-10-20 01:23, Grossman, Ethan A. wrote: > Hi Loa, > This is a very good point, that as other drafts progress after publication of the Security draft that new factors could arise. Perhaps the drafts could be expected to reference the Security draft, but not duplicate what was already in the Security draft at that time, incorporating any new material in the draft itself, or alternatively updating the Security draft with the new material at the same time? Otherwise a lot of duplication of text would have to be done to make each and every draft self-sufficient in the area of security considerations. > Ethan. > > -----Original Message----- > From: Loa Andersson > Sent: Friday, October 19, 2018 6:16 AM > To: Grossman, Ethan A. ; Lou Berger ; Deborah Brungard > Cc: detnet@ietf.org; Daniel Harkins > Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt > > Ethan, > > One small comment - I think that one concern from the SEC-DIR is that "Security draft" is set in time and the very next draft (not to mention very much later drafts) addresses things that were not known when the "Security draft" was written. Thus the Security Considerations can never reference the "Security draft", but we need to show that we understand threats and remedies that is relevant to each and every draft. > > Having said that (to avoid misunderstandings) the "Security draft" is a good document, well worth referencing, but a reference is not enough, the particular threats need to be addressed. > > /Loa > > On 2018-10-18 07:02, Grossman, Ethan A. wrote: >> Or maybe the answer will be implicit in Daniel Harkins' response to Janos' plan to update the architecture draft to refer to the Security draft. If he accepts that, then I think that pretty much constitutes acceptance of that strategy? But even if so, would that hold for every draft, or are there some types of draft for which that wouldn't be acceptable? >> Ethan. >> >> -----Original Message----- >> From: Grossman, Ethan A. >> Sent: Wednesday, October 17, 2018 10:19 AM >> To: 'Loa Andersson' ; Lou Berger ; >> Deborah Brungard >> Cc: detnet@ietf.org >> Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >> >> Thanks Loa (adding Lou and Deborah). >> >> So far, the reviewers of the last Use Cases draft have said "Hey where's the Security section?" and Lou and I added a Security section that points them at the Security draft, and they seemed to be OK with that. I don't know if that would be the case for our other drafts. >> >> I would very much like to have this conversation with the Security AD's and Directorate; at present, I personally don't know the most appropriate individuals to engage with on this topic - if one of y'all would like to provide me some kind of introduction, I'm happy to try to drive some resolution on our strategy here, either on the list or in Bangkok. >> >> Ethan. >> >> -----Original Message----- >> From: Loa Andersson >> Sent: Wednesday, October 17, 2018 2:57 AM >> To: Grossman, Ethan A. >> Cc: detnet@ietf.org >> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >> >> Ethan, Working Group, >> >> I don't think there is a one size fits all approach possible for the Security Considerations in all DetNet documents. My understanding is that the Security Directorate and Security ADs require that each document have an independent treatment of the specific threats and concerns for a particular document. >> >> Whatever strategy we decide on, please make sure that it is agreed on by the Security ADs and Directorate. >> >> /Loa >> >> On 2018-10-17 15:54, Grossman, Ethan A. wrote: >>> Hi Loa, >>> Various strategies are possible. One possibility is that the other drafts (i.e. not the Security draft) could just point at the Security draft such that there would be a "single clearing house" for DetNet-specific security info. That's what the Use Cases draft does, however there is also some security-related text in the various use cases. >>> >>> At one point I (as Security draft editor) attempted to bring together >>> all of the security-related text from the various other drafts by >>> copying it all into an appendix of the Security draft, since it is >>> sort of handy to have it all in one place. But as Lou pointed out to >>> me, we don't want to make the drafts dependent on each other if we >>> can avoid it, and if such text got edited then it would have to be >>> fixed in two places, so it isn't a perfect scheme. I would say that >>> if a draft author wants to write their own security-related text in >>> their own draft more power to them, but perhaps even more power if >>> they bring it to the Security draft :- ) >>> >>> Sorry long answer to a short question. And I'm sure there are other strategies... If you have any thoughts on the matter I'd love to hear them, either on the list or at IETF 103. >>> Ethan. >>> >>> -----Original Message----- >>> From: Loa Andersson >>> Sent: Wednesday, October 17, 2018 12:10 AM >>> To: Grossman, Ethan A. >>> Cc: detnet@ietf.org >>> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >>> >>> Ethan, >>> >>> I have just had a quick look, but what I see looks good, and certainly gives a good overview of the detnet security issues. >>> >>> One question, is it the intention that this document should be used as a general reference when writing security considerations for detnet documents? >>> >>> /Loa >>> >>> On 2018-10-17 12:05, Grossman, Ethan A. wrote: >>>> Hi All, >>>> This note is the status update for the DetNet Security Considerations draft in advance of IETF 103, in lieu of a presentation slot for it at IETF 103. >>>> >>>> A new version has been posted which includes the discussion on OAM traffic and incorporates the "Bounded Jitter" Use Case Common Theme. >>>> >>>> These are minor changes; no substantial work has been done since the last DetNet session, so we do not plan to have a slot for this draft at the IETF 103 DetNet session (though Tal will be presenting on it at the DetNet-TSN meeting on the following Sunday). >>>> >>>> I expect that we will convene as many of the authors (and any other interested parties) as we have available at IETF 103 to discuss DetNet-data-plane-technology-specific security considerations and how to incorporate them into the draft as our next steps. If you would like to participate in (be notified about) this conversation, please let me know. >>>> >>>> Best, >>>> Ethan (as DetNet Security Considerations draft editor) >>>> >>>> -----Original Message----- >>>> From: detnet On Behalf Of >>>> internet-drafts@ietf.org >>>> Sent: Tuesday, October 16, 2018 8:51 PM >>>> To: i-d-announce@ietf.org >>>> Cc: detnet@ietf.org >>>> Subject: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Deterministic Networking WG of the IETF. >>>> >>>> Title : Deterministic Networking (DetNet) Security Considerations >>>> Authors : Tal Mizrahi >>>> Ethan Grossman >>>> Andrew J. Hacker >>>> Subir Das >>>> John Dowdell >>>> Henrik Austad >>>> Kevin Stanton >>>> Norman Finn >>>> Filename : draft-ietf-detnet-security-03.txt >>>> Pages : 40 >>>> Date : 2018-10-16 >>>> >>>> Abstract: >>>> A deterministic network is one that can carry data flows for real- >>>> time applications with extremely low data loss rates and bounded >>>> latency. Deterministic networks have been successfully deployed in >>>> real-time operational technology (OT) applications for some years >>>> (for example [ARINC664P7]). However, such networks are typically >>>> isolated from external access, and thus the security threat from >>>> external attackers is low. IETF Deterministic Networking (DetNet) >>>> specifies a set of technologies that enable creation of deterministic >>>> networks on IP-based networks of potentially wide area (on the scale >>>> of a corporate network) potentially bringing the OT network into >>>> contact with Information Technology (IT) traffic and security threats >>>> that lie outside of a tightly controlled and bounded area (such as >>>> the internals of an aircraft). These DetNet technologies have not >>>> previously been deployed together on a wide area IP-based network, >>>> and thus can present security considerations that may be new to IP- >>>> based wide area network designers. This draft, intended for use by >>>> DetNet network designers, provides insight into these security >>>> considerations. In addition, this draft collects all security- >>>> related statements from the various DetNet drafts (Architecture, Use >>>> Cases, etc) into a single location Section 7. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-detnet-security-03 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-03 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>> >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>> >>> >> > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Sun Oct 21 06:31:17 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20320130E50; Sun, 21 Oct 2018 06:31:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154012867508.10804.13124782111981612234@ietfa.amsl.com> Date: Sun, 21 Oct 2018 06:31:15 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-geng-detnet-conf-yang-06.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 13:31:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet Configuration YANG Model Authors : Xuesong Geng Mach(Guoyi) Chen Zhenqiang Li Reshad Rahman Filename : draft-geng-detnet-conf-yang-06.txt Pages : 51 Date : 2018-10-21 Abstract: This document defines a YANG data model for Deterministic Networking (DetNet), which includes the DetNet topology YANG module, DetNet flow configuration YANG module and DetNet Transport QoS YANG Module. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-geng-detnet-conf-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-geng-detnet-conf-yang-06 https://datatracker.ietf.org/doc/html/draft-geng-detnet-conf-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-geng-detnet-conf-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 21 20:25:03 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7EE130DD4 for ; Sun, 21 Oct 2018 20:25:01 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVfN7q_2-csf for ; Sun, 21 Oct 2018 20:24:58 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 C3F05130DF2 for ; Sun, 21 Oct 2018 20:24:58 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2018 20:24:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,410,1534834800"; d="scan'208,217";a="243207168" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga004.jf.intel.com with ESMTP; 21 Oct 2018 20:24:58 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX101.amr.corp.intel.com ([169.254.8.122]) with mapi id 14.03.0319.002; Sun, 21 Oct 2018 20:24:57 -0700 From: "Venkatesan, Ganesh" To: "detnet@ietf.org" Thread-Topic: Comment on section 5.1.1 of draft-ietf-detnet-use-cases-19.txt Thread-Index: AdRptMU15iTNO7NGSFSiBDUcOucLLg== Date: Mon, 22 Oct 2018 03:24:56 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B58FAA9@ORSMSX107.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzk3MWFlNTgtZjJmYS00MjMwLTgyM2EtMjdkYTFlZGZhNDIxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoienVsdmYrMlBuWCtSK2xVZjl6RDFBYlB0STRtb2hsVUFpMlBSRFNDXC81bGhaNHNvWHh5Ym12UEVDTEU3eFpwQUcifQ== dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B58FAA9ORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: [Detnet] Comment on section 5.1.1 of draft-ietf-detnet-use-cases-19.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 03:25:01 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FAA9ORSMSX107amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello DetNet members: The following comment on Section 5.1.1 of draft-ietf-detnet-use-cases-19 is= based on our experience with managed Wi-Fi networks (in a wired/wireless t= opology) and we strongly recommended deleting the highlighted text below (f= rom section 5.1.1). Please let me know if you have any comments or question= s: 5.1.1. Network Convergence using 6TiSCH Some wireless network technologies support real-time QoS, and are thus useful for these kinds of networks, but others do not. For example WiFi is pervasive but does not provide guaranteed timing or delivery of packets, and thus is not useful in this context. Comment: Recommend deleting the text in bold font above from 5.1.1 Rationale: In a managed deployment like enterprise networks, where enough A= ccess Points (APs) are provisioned to cater to the expected traffic load, o= perating channels are planned to eliminate/minimize interference, admission= control is enabled to eliminate congestion, the non-determinism in the gai= ning access to the shared medium is minimized. In such cases, packet delive= ry latency is well bounded. Since we are exclusively addressing managed deployments, Wi-Fi is well-suit= ed to meet DetNet requirements (e.g., minimize the over-the-Wi-Fi-hop laten= cy, minimize packet error rate, provide robust security, support for IP con= vergence in Layer-3, provision for required throughput). The following specifications/certifications are relevant in the context of = the requirements outlined in the Use Cases described in this document: (a) Time Synchronization - standards based and interoperable: - IEEE802= .11-2016 with IEEE802.1AS; WFA TimeSyncTM Certification (b) Congestion Control: IEEE802.11-2016 Admission Control; WFA Admissi= on Control (c) Security: WFA WPA2, WPA3 (d) Interoperating with IEEE802.1Q bridges: IEEE802.11ak (e) Stream Reservation Protocol (part of IEEE802.1Qat) - IEEE802.11-20= 16 In addition, there is ongoing/planned work in the IEEE802.11 Working Group = to address challenges like (a) dense deployment (resource limited seat speakers in theaters descri= bed in Section 2, for example) - IEEE802.11ax D3.0 (b) Support for 802.1Qbv - IEEE802.11 Topic Interest Group on Real Time= Applications; topics discussed here include support for both local and cen= tral traffic shaping in order ensure that the low latency/high reliability = requirements for DetNet traffic are met while not starving non-DetNet traff= ic. IEEE P802.11ax includes mechanisms, such as the use of trigger frames, that= allows providing predictable scheduling in a Wi-Fi network and thereby pro= viding guaranteed timely delivery of packets. Moreover, with the support of= Orthogonal Frequency Division Multiple Access (OFDMA), multiple DetNet end= points can be serviced simultaneously. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN (available w= ith access to IEEE802.11 members' area) 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FAA9ORSMSX107amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello DetNet members:

     

    The following comment on Section 5.1.1 of draft-ietf= -detnet-use-cases-19 is based on our experience with managed Wi-Fi networks= (in a wired/wireless topology) and we strongly recommended deleting the hi= ghlighted text below (from section 5.1.1). Please let me know if you have any comments or questions:

     

    5.1.1.  Network Convergence using 6TiSCH

     

       Some wireless network technologies support real-time QoS, a= nd are

       thus useful for these kinds of networks, but others do not.=   For

       example WiFi is pervasive but does not provide guarantee= d timing or

       delivery of packets, and thus is not usefu= l in this context.

     

    Comment: Recommend deleting the text in bold font above from 5.1.1

     

    Rationale: In a managed deploy= ment like enterprise networks, where enough Access Points (APs) are provisi= oned to cater to the expected traffic load, operating channels are planned = to eliminate/minimize interference, admission control is enabled to eliminate congestion, the non-determinism in the gai= ning access to the shared medium is minimized. In such cases, packet delive= ry latency is well bounded.

    Since we are exclusively addressing managed deployments, Wi-Fi is well= -suited to meet DetNet requirements (e.g., minimize the over-the-Wi-Fi-hop = latency, minimize packet error rate, provide robust security, support for IP convergence in Layer-3, provision for required th= roughput).

    The following specifications/certifications are relevant in the contex= t of the requirements outlined in the Use Cases described in this document:=

    (a)     Time Synchronization – standards based and interoperable: = 211; IEEE802.11-2016 with IEEE802.1AS; WFA TimeSyncTM Certificat= ion

    (b)     Congestion Control:  IEEE802.11-2016 Admission Control; WFA Ad= mission Control

    (c)     Security: WFA WPA2, WPA3

    (d)     Interoperating with IEEE802.1Q bridges: IEEE802.11ak

    (e)      Stream Reservation Protocol (part of IEEE802.1Qat) – IE= EE802.11-2016

    In addition, there is ongoing/planned work in the IEEE802.11 Working G= roup to address challenges like

    (a)     dense deployment (resource limited seat speakers in theaters descri= bed in Section 2, for example) – IEEE802.11ax D3.0<= /p>

    (b)     Support for 802.1Qbv – IEEE802.11 Topic Interest Group on Rea= l Time Applications; topics discussed here include support for both local a= nd central traffic shaping in order ensure that the low latency/high reliability requirements for DetNet traffic are met while= not starving non-DetNet traffic.

    IEEE P802.11ax includes mechanisms, such as the use of trigger frames, t= hat allows providing predictable scheduling in a Wi-Fi network and thereby = providing guaranteed timely delivery of packets. Moreover, with the support of Orthogonal Frequency Division Multiple Acces= s (OFDMA), multiple DetNet endpoints can be serviced simultaneously.

     

    References:

    1. IEEE802.11-2016: Wireless LAN Medi= um Access Control (MAC) and Physical Layer (PHY) Specifications<= /span>
    2. <= span style=3D"font-family:"Courier New"">IEEE802.11ak-2017: Enhan= cements for Transit Links Within Bridged Networks
      3. IEEE802.11ax D3.0: Enhancements for Hi= gh Efficiency WLAN (available with access to IEEE802.11 members’ area= )
    3. WNG documen= ts on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-1160-00-0wng-contr= olling-latency-in-802-11.pptx
    4. Wi-Fi Allian= ce Wireless Protected Access 2 (WPA2)
    5. Wi-Fi Alliance Wireless Multi-Media Admission Cont= rol (WMM-AC)
    6. = Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
      7. Wi-Fi Alliance TimeSyncTM

    Cheers -= -

    ganesh

     

    --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FAA9ORSMSX107amrcor_-- From nobody Sun Oct 21 20:56:12 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD6D130DED for ; Sun, 21 Oct 2018 20:56:11 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh3-0UywljZX for ; Sun, 21 Oct 2018 20:56:07 -0700 (PDT) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 0B260130DD0 for ; Sun, 21 Oct 2018 20:56:06 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2018 20:56:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.54,410,1534834800"; d="scan'208,217"; a="80533754" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga008.fm.intel.com with ESMTP; 21 Oct 2018 20:56:05 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 21 Oct 2018 20:56:05 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX154.amr.corp.intel.com ([169.254.11.186]) with mapi id 14.03.0319.002; Sun, 21 Oct 2018 20:56:04 -0700 From: "Venkatesan, Ganesh" To: "detnet@ietf.org" Thread-Topic: proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+Uw== Date: Mon, 22 Oct 2018 03:56:04 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDQ5NjQzN2EtNWNhZi00ZDg0LWIzZjktMTUxMjBlZDRjNTViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRGRONGFaVjRnbG16cFNxUDFWdTg5d21ucjlBczBzcUpDXC9Xck1sbDJiZGxNbjJpQWZheTdCeE5uNXltNDA1R2cifQ== dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B58FADBORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 03:56:12 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FADBORSMSX107amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path. Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers ("making AVB= /TSN-type deterministic performance available from layer-3 applications" or= "connecting two AVB/TSN LANs or 'islands' together through a standard rout= er") should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE8= 02.11 is already supported for time synchronization, stream identification = and reservation and additional TSN capabilities are under development (supp= ort for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 - 10 millisecond latencies over = the wireless hop) is achievable in a managed 802.11 network by leveraging c= urrent TSN capabilities over 802.11, such as time synchronization, stream i= dentification and time-aware shaping. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration - there are aspects of the wireless netw= ork (or the wireless hop from a wired/wireless bridge to a wireless endpoin= t) that will have to be defined. For instance, the controller that does the= central administration may send the desired configuration to the wired/wir= eless bridge (the wireless part in this bridge is the AP function) where it= gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FADBORSMSX107amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello DetNet members:

     

    We proposed adding IEEE802.11 as a L2 media for DetN= et. Based on our experience with IEEE802.11 in managed deployments, we beli= eve that 802.11 links can meet DetNet requirements described in the use cas= e document. In addition there is a lot of work underway in IEEE802.1ax Task Group and in other Topic Interest= Groups within IEEE802.11 Working Group that renders 802.11 as a versatile = L2 media for DetNet.

     

    Please let me know if you have comments/questions on= this submission:

     

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= .

     

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.

     

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

     

    Thus far IEEE 802.11 has been the only wireless media technology that = has already included support for some of the 802.1 TSN capabilities require= d to address the use cases described in this document. The IEEE 802.11 working group has been working in collaboration with the I= EEE 802.1 group for several years extending 802.1 features over 802.11. The= refore, in the Use Cases described in this document, an IEEE 802.11 hop fit= s naturally into the network. In all these cases, the DetNet under consideration is a wired/wireless networ= k with the first and/or the last nodes being IEEE802.11 hops and the rest o= f the network is wired. As with any wireless media, 802.11 imposes new cons= traints and restrictions to TSN-grade QoS, and tradeoffs between latency and reliability guarantees must be cons= idered as well as managed deployment requirements.

    The 802.1 and 802.11 feature set that is already part of I= EEE802.11-2016 (along with a set of Wi-Fi Alliance Certifications to ensure= interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNet described= in this document.

     

    The following sub-sections are analogues of corresponding = subsections in section-11. The intent is to demonstrate how well IEEE802.11= MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the low cost seat= speakers being connected over a IEEE802.11 hop to the network, the HMI at = the building management network, the sensors/alarms in the electric utility= network.

     

    x.1.1 Extension to Ethernet and 802.1 TSN=

     

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate L2 and L3 la= yers (“making AVB/TSN-type deterministic performance available from l= ayer-3 applications” or “connecting two AVB/TSN LANs or ‘islands’ together through a standard router”) should= extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE802.11 is al= ready supported for time synchronization, stream identification and reserva= tion and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

     

    x.1.6 Guaranteed End-to-End Delivery

    Guaranteed e2e delivery is achieved in DetNet by constraining the netw= ork (the network is not the open Internet but a constrained/managed network= ).

    With 802.11, similar constraints can be put in place in a = managed deployment. For instance, multiple channels and Basic Service Sets = (BSSs) may be defined that restrict access based on traffic stream identification and admission control features already jo= intly supported by 802.1 and 802.11. There are additional constraints that = may be defined to achieve the guarantees.

     

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify and prioritize time-sensitive o= perational traffic. The prioritization (and the resulting improved latency/= reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even more effective with high efficien= cy features from IEEE802.11ax, IEEE802.1Qbv over IEEE802.11, etc.

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     

    x.1.10 Lower Cost, Multi Vendor Solutions=

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admission Control pr= events over-subscribing and minimizes collisions, and where QoS provides pr= ioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r0]

     

    x.3.2 Low Latency

    Low latency requirement depends on the Use Case in question. There is = some trade-off in the low latency requirement for the convenience of being = not tethered to a wire, being mobile and being able to reconfigure the network as needed for the specific situation withi= n the Use Case.

    However, low latencies [Reference 18-1160r0] to meet the requirements = of a variety of Use Cases (pro AV, synchronized multi-channel audio, mobile= robotics, repetitive cyclic control systems (1 – 10 millisecond latencies over the wireless hop) is achievable in a= managed 802.11 network by leveraging current TSN capabilities over 802.11,= such as time synchronization, stream identification and time-aware shaping= .

    x.5 Security

    WFA WPA3 provides robust security both for management and = data packets. In addition, WFA Easy Connect provides for robust security wh= ile supporting easy onboarding of headless devices into the network.

     

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration – there are aspec= ts of the wireless network (or the wireless hop from a wired/wireless bridg= e to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administration may send= the desired configuration to the wired/wireless bridge (the wireless part = in this bridge is the AP function) where it gets converted into parameters = that are 802.11-specific.

     

    x.6.2 Standardized Data Flow Information Models=

    Co-ordination between IETF DetNet and IEEE802.11 Working G= roups will be required to ensure that this requirement is met when DetNet o= perates over IEEE802.11 links.

     

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in all wireles= s networks, specifically indoors). Need to research this further.

     

    References:

    1. IEEE802.11-2016: Wireless LAN Medi= um Access Control (MAC) and Physical Layer (PHY) Specifications<= /span>
    2. <= span style=3D"font-family:"Courier New"">IEEE802.11ak-2017: Enhan= cements for Transit Links Within Bridged Networks
      3. IEEE802.11ax D3.0: Enhancements for Hi= gh Efficiency WLAN
    3. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-1160-00-0wng-contr= olling-latency-in-802-11.pptx
    4. Wi-Fi Allian= ce Wireless Protected Access 2 (WPA2)
    5. Wi-Fi Alliance Wireless Multi-Media Admission Cont= rol (WMM-AC)
    6. = Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
      7. Wi-Fi Alliance TimeSyncTM

     

    Cheers -= -

    ganesh

     

    --_000_311BE885E0DA8D4BB369A037CF5B64A79B58FADBORSMSX107amrcor_-- From nobody Sun Oct 21 21:46:29 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC4E12F1AC; Sun, 21 Oct 2018 21:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154018358205.10804.4321226225839144292@ietfa.amsl.com> Date: Sun, 21 Oct 2018 21:46:22 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-mpls-01.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 04:46:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet MPLS Data Plane Encapsulation Authors : Jouni Korhonen Balázs Varga Filename : draft-ietf-detnet-dp-sol-mpls-01.txt Pages : 50 Date : 2018-10-21 Abstract: This document specifies Deterministic Networking data plane encapsulation solutions. The described data plane solutions is applied over an MPLS Packet Switched Networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-mpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-01 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-mpls-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-dp-sol-mpls-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 21 21:47:31 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12815130E71; Sun, 21 Oct 2018 21:47:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154018363703.10657.5095082137142552829@ietfa.amsl.com> Date: Sun, 21 Oct 2018 21:47:17 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-ip-01.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 04:47:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet IP Data Plane Encapsulation Authors : Jouni Korhonen Balázs Varga Filename : draft-ietf-detnet-dp-sol-ip-01.txt Pages : 32 Date : 2018-10-21 Abstract: This document specifies Deterministic Networking data plane operation for IP encapsulated user data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-01 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-ip-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-dp-sol-ip-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 04:30:56 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A70124D68; Mon, 22 Oct 2018 04:30:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154020785439.15340.2570517031141538190@ietfa.amsl.com> Date: Mon, 22 Oct 2018 04:30:54 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 11:30:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet Configuration YANG Model Authors : Xuesong Geng Mach(Guoyi) Chen Zhenqiang Li Reshad Rahman Filename : draft-ietf-detnet-yang-00.txt Pages : 51 Date : 2018-10-22 Abstract: This document defines a YANG data model for Deterministic Networking (DetNet), which includes the DetNet topology YANG module, DetNet flow configuration YANG module and DetNet Transport QoS YANG Module. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-yang-00 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 05:33:20 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CB130E05; Mon, 22 Oct 2018 05:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8rlepTIi1UD; Mon, 22 Oct 2018 05:33:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A84D1200D7; Mon, 22 Oct 2018 05:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5752; q=dns/txt; s=iport; t=1540211596; x=1541421196; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3wTBVDqDafI4hIDTG4zAezUn7sflhujkt/jXJox4nAQ=; b=RpyqY0GvO+LuY72VTdEXU0rt39sHiiKNVP932bbrJKNJfFg9Di6Ezn8D 97BDcYjNT0z86bOGVvF+GC+cGb0q5kb3DFrcupHgsycO+TUrnaR4vAjOM ImctaAUzCz2jcglD2IaGUKyFmcTSMMY6zC3V7YdXzVMU3iU6//8aOqOqU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADIws1b/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVoqZn8oCoNriBiMGoINgz+TVhSBZgs?= =?us-ascii?q?BASOEA0YCF4R9ITQNDQEDAQECAQECbRwMhToBAQEBAyMRRQwEAgEGAhEBAwE?= =?us-ascii?q?BAQICJgICAjAVAgYIAgQBDQUIgxqCAQ+Ic5tNgS6KEAWBC4pHF4FBP4MlfoM?= =?us-ascii?q?bAgGBQAEBBi+CbIJXApQ5ig8JApBoH4FShHOEK4U+jz+GdwIRFIEmHTiBVXA?= =?us-ascii?q?VgyeDOgEHh1eFPm8BiUeBH4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,412,1534809600"; d="scan'208";a="189080825" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 12:33:15 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9MCXFv5009070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2018 12:33:15 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 07:33:14 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 07:33:14 -0500 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?SsOhbm9zIEZhcmthcw==?= , "Joel M. Halpern" CC: "gen-art@ietf.org" , "draft-ietf-detnet-architecture.all@ietf.org" , DetNet WG , "ietf@ietf.org" Thread-Topic: Genart last call review of draft-ietf-detnet-architecture-08 Thread-Index: AQHUUg+YYeqIV0gtu0ONxPpT2TRbqaUl8v4AgAF7gICAAAH7AIAADWaAgAPjr/A= Date: Mon, 22 Oct 2018 12:32:53 +0000 Deferred-Delivery: Mon, 22 Oct 2018 12:32:18 +0000 Message-ID: <7e953a51fcfe44e6b8689c874785caac@XCH-RCD-001.cisco.com> References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com> In-Reply-To: <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.70.30] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 12:33:19 -0000 SGVsbG8gSsOhbm9zDQoNCkkncyBjaGFuZ2UgcmVhc29uYWJseSB0byBzdHJpY3RseS4NCg0KVGhl IHdob2xlIHBvaW50IG9mIGJvdW5kZWQgaW4gZGV0bmV0IGlzIHRoYXQgaXQgaXMgbm90IGEgdmFn dWUgYm91bmRhcnkgYnV0IGEgaGFyZCwgZ3VhcmFudGVlZCBvbmUsIHJlZ2FyZGxlc3Mgb2YgYW55 IG90aGVyIGFjdGl2aXR5IGluIHRoZSBuZXR3b3JrLg0KDQpBbGwgdGhlIGJlc3QsDQoNClBhc2Nh bA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IErDoW5vcyBGYXJrYXMg PGphbm9zLmZhcmthc0Blcmljc3Nvbi5jb20+DQo+IFNlbnQ6IHZlbmRyZWRpIDE5IG9jdG9icmUg MjAxOCAyMjowNg0KPiBUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0K PiBDYzogZ2VuLWFydEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLmFs bEBpZXRmLm9yZzsgRGV0TmV0IFdHDQo+IDxkZXRuZXRAaWV0Zi5vcmc+OyBpZXRmQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRl dG5ldC1hcmNoaXRlY3R1cmUtMDgNCj4gDQo+IEpvZWwsDQo+IA0KPiBQbGVhc2Ugc2VlIGluLWxp bmUuDQo+IA0KPiANCj4gT24gMTAvMTkvMjAxOCA5OjE3IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3Jv dGU6DQo+ID4gVGhhbmsgeW91IEphbm9zLsKgIFR3byBjbGFyaWZpY2F0aW9ucyB1bmRlciByZXRh aW5lZCB0ZXh0LCB3aXRoIHRoZQ0KPiA+IHJlc3QgZWxpZGVkLg0KPiA+DQo+ID4gWW91cnMsDQo+ ID4gSm9lbA0KPiA+DQo+ID4gT24gMTAvMTkvMTggMzoxMCBQTSwgSsOhbm9zIEZhcmthcyB3cm90 ZToNCj4gPiAuLi4NCj4gPj4gT24gOS8yMi8yMDE4IDI6NTkgQU0sIEpvZWwgSGFscGVybiB3cm90 ZToNCj4gPiAuLi4NCj4gPj4+IE1pbm9yIGlzc3VlczoNCj4gPj4+IMKgwqDCoMKgIFNlY3Rpb24g My4xIHN0YXRlcyB0aGF0IHdvcnN0IGNhc2UgZGVsYXkgZm9yIHByaW9yaXR5IHF1ZXVlaW5nDQo+ ID4+PiBpcw0KPiA+Pj4gwqDCoMKgwqAgdW5ib3VuZGVkLsKgIFRoYXQgZG9lcyBub3QgbWF0Y2gg bXkgdW5kZXJzdGFuZGluZy7CoCBJIGtub3cgdGhhdA0KPiA+Pj4gRGVsYXlCb3VuZA0KPiA+Pj4g wqDCoMKgwqAgRFNDUCBiZWhhdmlvciB0aWdodGx5IChhbHRob3VnaCwgSSB0aGluaywgbm90IGFz IHRpZ2h0bHkgYXMNCj4gPj4+IERldG5ldCkgbGltaXRzDQo+ID4+PiDCoMKgwqDCoCBib3RoIHRo ZSB3b3JzdCBjYXNlIGRlbGF5IGFuZCB0aGUgZGVsYXkgdmFyaWF0aW9uLg0KPiA+PiBTdHJpY3Qg cHJpb3JpdHkgaXMgbm90IGdvb2QgZW5vdWdoIGZvciBEZXROZXQuIEEgaGlnaCBwcmlvcml0eSBw YWNrZXQNCj4gPj4gbWF5IG5lZWQgdG8gd2FpdCB1bnRpbCB0aGUgdHJhbnNtaXNzaW9uIG9mIGEg bG93ZXIgcHJpb3JpdHkgcGFja2V0IGlzDQo+ID4+IGZpbmlzaGVkIGF0IGFuIG91dGJvdW5kIHBv cnQsIHdoaWNoIGNhbiBjYXVzZSB0b28gbXVjaCB1bmNlcnRhaW50aWVzDQo+ID4+IGluIHRoZSBu ZXR3b3JrLg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIHRoYXQgc3RyaWN0IHByaW9yaXR5IHF1ZXVl aW5nIGlzIHZpZXdlZCBhcyBpbnN1ZmZpY2llbnQuDQo+ID4gSSB3YXNuO3QgYXJndWluZyBhYm91 dCB0aGF0LsKgIEkgd2FzIGFyZ3Vpbmcgd2l0aCB0aGUgdXNlIG9mIHRoZSB3b3JkDQo+ID4gInVu Ym91bmRlZCIuwqAgQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHdpdGggc3VpdGFibGUgcHJpb3JpdHkg cXVldWVpbmcNCj4gPiB0aGUgd29yc3QgY2FzZSBkZWxheSBpcyBib3VuZGVkLCBzaW1wbHkgbm90 IHdlbGwgZW5vdWdoIGJvdW5kZWQuDQo+IA0KPiBXZSBjYW4gbWFrZSB0aGUgc2VudGVuY2UgY2xl YXJlcjoNCj4gDQo+IE9MRDoNCj4gSW4gZ2VuZXJhbCwgYSB0cml2aWFsIHByaW9yaXR5LWJhc2Vk IHF1ZXVpbmcgc2NoZW1lIHdpbGwgZ2l2ZSBiZXR0ZXIgYXZlcmFnZQ0KPiBsYXRlbmN5IHRvIGEg ZGF0YSBmbG93IHRoYW4gRGV0TmV0LCBidXQgb2YgY291cnNlLCB0aGUgd29yc3QtIGNhc2UgbGF0 ZW5jeSBjYW4NCj4gYmUgZXNzZW50aWFsbHkgdW5ib3VuZGVkLg0KPiANCj4gTkVXOg0KPiBJbiBn ZW5lcmFsLCBhIHRyaXZpYWwgcHJpb3JpdHktYmFzZWQgcXVldWluZyBzY2hlbWUgd2lsbCBnaXZl IGJldHRlciBhdmVyYWdlDQo+IGxhdGVuY3kgdG8gYSBkYXRhIGZsb3cgdGhhbiBEZXROZXQ7IGhv d2V2ZXIsIGl0IG1heSBiZSB0aGF0IHRoZSB3b3JzdC1jYXNlDQo+IGxhdGVuY3kgY2Fubm90IGJl IHJlYXNvbmFibHkgYm91bmRlZCBmb3IgRGV0TmV0Lg0KPiANCj4gDQo+ID4NCj4gPiAuLi4NCj4g Pj4+IMKgwqDCoMKgIEluIHNlY3Rpb24gNC4xLjIsIEkgcmVhbGl6ZWQgdGhhdCB0aGUgRGV0bmV0 IFRyYW5zaXQgbm9kZQ0KPiA+Pj4gdGVybWlub2xvZ3kgaGFkDQo+ID4+PiDCoMKgwqDCoCBtaWxk bHkgY29uZnVzZWQgbWUuwqAgVGhlIHRleHQgc2F5cyAiRGV0TmV0IGVuYWJsZWQgbm9kZXMgYXJl DQo+ID4+PiBpbnRlcmNvbm5lY3RlZA0KPiA+Pj4gwqDCoMKgwqAgdmlhIHRyYW5zaXQgbm9kZXMg KGUuZy4sIExTUnMpIHdoaWNoIHN1cHBvcnQgRGV0TmV0LCBidXQgYXJlDQo+ID4+PiBub3QgRGV0 TmV0DQo+ID4+PiDCoMKgwqDCoCBzZXJ2aWNlIGF3YXJlLiLCoCBSZWFkaW5nIHRoaXMsIGFuZCB0 aGUgZGVmaW5pdGlvbnMgaW4gc2VjdGlvbg0KPiA+Pj4gMi4xLCBpdA0KPiA+Pj4gwqDCoMKgwqAg YXBwZWFycyB0aGF0IGEgRGV0bmV0IFRyYW5zaXQgbm9kZSBpcyBhIG5vZGUgdGhhdCBpcyBwcm92 aWRpbmcNCj4gPj4+IHRyYW5zcG9ydA0KPiA+Pj4gwqDCoMKgwqAgYmVoYXZpb3IgdGhhdCBkZXRu ZXQgbmVlZHMsIGJ1dCBpcyBub3QgYWN0dWFsbHkgbW9kaWZpZWQgZm9yDQo+ID4+PiBkZXRuZXQu DQo+ID4+IEJhc2VkIG9uIGxhc3QgY2FsbCBjb21tZW50czoNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMTc5MS5odG1sLA0KPiA+ PiB0aGUgcGhyYXNlICJEZXROZXQgZW5hYmxlZCBub2RlcyIgaXMgcmVtb3ZlZCBmcm9tIHRoZSBk b2N1bWVudCBhbmQgaXQNCj4gPj4gaGFzIGJlZW4gbWFkZSBjbGVhciB3aGF0IHR5cGUgb2YgRGV0 TmV0IG5vZGUgaXMgbWVhbnQ6DQo+ID4+IFRoZSB0ZXh0IGlzIHVwZGF0ZWQgdG86DQo+ID4+DQo+ ID4+IMKgwqDCoCBBICJEZXRlcm1pbmlzdGljIE5ldHdvcmsiIHdpbGwgYmUgY29tcG9zZWQgb2Yg RGV0TmV0IGVuYWJsZWQgZW5kDQo+ID4+IMKgwqDCoCBzeXN0ZW1zLCBEZXROZXQgZWRnZSBub2Rl cywgRGV0TmV0IHJlbGF5IG5vZGVzIGFuZCBjb2xsZWN0aXZlbHkNCj4gPj4gwqDCoMKgIGRlbGl2 ZXIgRGV0TmV0IHNlcnZpY2VzLsKgIERldE5ldCByZWxheSBhbmQgZWRnZSBub2RlcyBhcmUNCj4g Pj4gwqDCoMKgIGludGVyY29ubmVjdGVkIHZpYSBEZXROZXQgdHJhbnNpdCBub2RlcyAoZS5nLiwg TFNScykgd2hpY2gNCj4gPj4gc3VwcG9ydA0KPiA+PiDCoMKgwqAgRGV0TmV0LCBidXQgYXJlIG5v dCBEZXROZXQgc2VydmljZSBhd2FyZS4NCj4gPg0KPiA+IEFueSBjaGFuY2UgeW91IGNvdWxkIHNp bXBseSBzYXkgInRyYW5zaXQgbm9kZXMiIGluc3RlYWQgb2YgIkRldE5ldA0KPiA+IHRyYW5zaXQg bm9kZXM/wqAgQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoZXkgYXJlIGV4aXN0aW5nIG5vZGVzIHRo YXQNCj4gPiB3ZXJlIGRlc2lnbmVkIGFuZCBpbXBsZW1lbnRlZCAoYW5kIGV2ZW4gY29uZmlndXJl ZCkgcG90ZW50aWFsbHkgYmVmb3JlDQo+ID4gRGV0TmV0IHdhcyBldmVuIGRlZmluZWQ/DQo+ID4N Cj4gPiAuLi4NCj4gSXQgaGFzIGJlZW4gcG9pbnRlZCBvdXQgZHVyaW5nIGxhc3QgY2FsbCAoaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4gYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNn MDE3OTEuaHRtbCksIHRvIGJlIHNwZWNpZmljIG9uIHdoYXQgbm9kZQ0KPiB0eXBlIGlzIG1lYW50 OyBhbmQgYmUgY29uc2lzdGVudCB3aXRoIHRlcm1pbm9sb2d5IGFuZCBkZWZpbml0aW9ucy4gRGV0 TmV0DQo+IHRyYW5zaXQgbm9kZSBpcyBhIHRlcm0gZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50Lg0K PiBTbywgaXQgc2VlbXMgYmV0dGVyIHRvIGhhdmUgRGV0TmV0IHRyYW5zaXQgbm9kZS4NCj4gDQo+ IFRoYW5rIHlvdSENCj4gQmVzdCByZWdhcmRzLA0KPiBKYW5vcw0KDQo= From nobody Mon Oct 22 07:11:05 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64CD1286E7 for ; Mon, 22 Oct 2018 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD711gsZqHO0 for ; Mon, 22 Oct 2018 07:10:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E8683124408 for ; Mon, 22 Oct 2018 07:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540217451; x=1542809451; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Oe8ji/mO4ZI2DG/GJM5G4xko/L8+ulE8jBztdNF3z18=; b=U/h6UeZbfWCur84Kq89A9RzCo8uf2XaMQDuCEl8gIVJVsxXExypCtcmm4ZiXsO6N 2inWnaSreLiHhtzQdJa122xOpJHMi6n+QGfpBXUY33i3alZCAewX77p1GLmtc9Hq rJoivA4oUu/5ETQqRfp17QSDZsMsFGFp1Oy+OuhiDPE=; X-AuditID: c1b4fb25-a0b8c9e0000018b4-d7-5bcdda6b2bb8 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.B5.06324.B6ADDCB5; Mon, 22 Oct 2018 16:10:51 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 16:10:51 +0200 Received: from [100.94.36.169] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Mon, 22 Oct 2018 16:10:50 +0200 To: "Pascal Thubert (pthubert)" , "Joel M. Halpern" CC: "gen-art@ietf.org" , "draft-ietf-detnet-architecture.all@ietf.org" , DetNet WG , "ietf@ietf.org" References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com> <7e953a51fcfe44e6b8689c874785caac@XCH-RCD-001.cisco.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <3f98fe27-e2b1-2ceb-b341-9842db85e07b@ericsson.com> Date: Mon, 22 Oct 2018 16:10:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <7e953a51fcfe44e6b8689c874785caac@XCH-RCD-001.cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2J7uW72rbPRBndnqFr8/jSbxWLfrE0s FldffWaxeLZxPovFx1NvmCxmTHnH6MDmMeX3RlaPJUt+Mnmcm/KdMYA5issmJTUnsyy1SN8u gSvj3bMNTAV96hX3vnxnbGC8Kd/FyMkhIWAiMW/iHcYuRi4OIYGjjBJTbyxlg3C+MUpcONLG DOEcYZT4tf4/I0iLsICnxNvNk1hBbBGBeIl5F76BFTELnGKUuL/sOgtEx3wmiVd7/jODVLEJ 2EvcvbQBzOYFsrf9XgfWzSKgKjGh6QbYVFGBWIlPVxZD1QhKnJz5BGgQBwengKvEvj9eIGFm AQuJmfPPM0LY8hLNW2czQ9jiEreezGcCsYUE1CQ+vX3IPoFRaBaSSbOQtM9C0j4LSfsCRpZV jKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFxcXDLb9UdjJffOB5iFOBgVOLhnbzvbLQQa2JZ cWXuIUYJDmYlEd6VS4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR+ab44SEkhPLEnNTk0tSC2C yTJxcEo1MMbvODhTQv12yLKcG0WnBF69Yv/7dpfshdaDS6sf/40Juhy9U+RQzMU5peeSvq90 jnu5Qat5e2DGSvX/v8tcVu/79ovjlq3N4p0/vn60SN965K/LjoLvUVyhLf++fJB3Vzjmpeus Ulg9y94zaad2isKBSVaGmcbRWjO5mbIOrCt48dq8JLF/5gslluKMREMt5qLiRACplw6yhwIA AA== Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:10:57 -0000 Hi Pascal, Thank you for your comment! There was another comment pointing out that the text I suggested is misleading. Instead, I suggest the following update: OLD: In general, a trivial priority-based queuing scheme will give better average latency to a data flow than DetNet, but of course, the worst- case latency can be essentially unbounded. NEW: In general, a trivial priority-based queuing scheme will give better average latency to a data flow than DetNet; however, it may not be a suitable option for DetNet because of its worst-case latency. I think it addresses both Joel's and Pascal's concern. I hope it is clear this way. Thank you! Best regards, Janos On 10/22/2018 2:32 PM, Pascal Thubert (pthubert) wrote: > Hello János > > I's change reasonably to strictly. > > The whole point of bounded in detnet is that it is not a vague boundary but a hard, guaranteed one, regardless of any other activity in the network. > > All the best, > > Pascal > >> -----Original Message----- >> From: János Farkas >> Sent: vendredi 19 octobre 2018 22:06 >> To: Joel M. Halpern >> Cc: gen-art@ietf.org; draft-ietf-detnet-architecture.all@ietf.org; DetNet WG >> ; ietf@ietf.org >> Subject: Re: Genart last call review of draft-ietf-detnet-architecture-08 >> >> Joel, >> >> Please see in-line. >> >> >> On 10/19/2018 9:17 PM, Joel M. Halpern wrote: >>> Thank you Janos.  Two clarifications under retained text, with the >>> rest elided. >>> >>> Yours, >>> Joel >>> >>> On 10/19/18 3:10 PM, János Farkas wrote: >>> ... >>>> On 9/22/2018 2:59 AM, Joel Halpern wrote: >>> ... >>>>> Minor issues: >>>>>      Section 3.1 states that worst case delay for priority queueing >>>>> is >>>>>      unbounded.  That does not match my understanding.  I know that >>>>> DelayBound >>>>>      DSCP behavior tightly (although, I think, not as tightly as >>>>> Detnet) limits >>>>>      both the worst case delay and the delay variation. >>>> Strict priority is not good enough for DetNet. A high priority packet >>>> may need to wait until the transmission of a lower priority packet is >>>> finished at an outbound port, which can cause too much uncertainties >>>> in the network. >>> I understand that strict priority queueing is viewed as insufficient. >>> I wasn;t arguing about that.  I was arguing with the use of the word >>> "unbounded".  As far as I can tell, with suitable priority queueing >>> the worst case delay is bounded, simply not well enough bounded. >> We can make the sentence clearer: >> >> OLD: >> In general, a trivial priority-based queuing scheme will give better average >> latency to a data flow than DetNet, but of course, the worst- case latency can >> be essentially unbounded. >> >> NEW: >> In general, a trivial priority-based queuing scheme will give better average >> latency to a data flow than DetNet; however, it may be that the worst-case >> latency cannot be reasonably bounded for DetNet. >> >> >>> ... >>>>>      In section 4.1.2, I realized that the Detnet Transit node >>>>> terminology had >>>>>      mildly confused me.  The text says "DetNet enabled nodes are >>>>> interconnected >>>>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>>>> not DetNet >>>>>      service aware."  Reading this, and the definitions in section >>>>> 2.1, it >>>>>      appears that a Detnet Transit node is a node that is providing >>>>> transport >>>>>      behavior that detnet needs, but is not actually modified for >>>>> detnet. >>>> Based on last call comments: >>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >>>> the phrase "DetNet enabled nodes" is removed from the document and it >>>> has been made clear what type of DetNet node is meant: >>>> The text is updated to: >>>> >>>>     A "Deterministic Network" will be composed of DetNet enabled end >>>>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>>>     deliver DetNet services.  DetNet relay and edge nodes are >>>>     interconnected via DetNet transit nodes (e.g., LSRs) which >>>> support >>>>     DetNet, but are not DetNet service aware. >>> Any chance you could simply say "transit nodes" instead of "DetNet >>> transit nodes?  As far as I can tell, they are existing nodes that >>> were designed and implemented (and even configured) potentially before >>> DetNet was even defined? >>> >>> ... >> It has been pointed out during last call (https://www.ietf.org/mail- >> archive/web/detnet/current/msg01791.html), to be specific on what node >> type is meant; and be consistent with terminology and definitions. DetNet >> transit node is a term defined by this document. >> So, it seems better to have DetNet transit node. >> >> Thank you! >> Best regards, >> Janos From nobody Mon Oct 22 07:15:22 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCA9126BED for ; Mon, 22 Oct 2018 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9pSODCQ07M5 for ; Mon, 22 Oct 2018 07:15:16 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 570B51276D0 for ; Mon, 22 Oct 2018 07:15:14 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id q41-v6so46375749qtq.10 for ; Mon, 22 Oct 2018 07:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sgdr0XMrQA69ujJqp1335hTH3W5cyMxNwf4rU6YjLHs=; b=q7HPzJeuSc9BsYvzILNntIHOMESRxxQcQyZfqla78ZvCvD5oqh+XIAB8QRNxUrziOk yY1wx2cUJ6dapiiBu3kYZyR4US8kanevgiNPo1Uj9bRG7ZZGGHmckBsYMyeiIopflYpF +g4h4tkklSQxXnQ0kNBnVi4XHPMTIGhY1nOcdzdoSiku63ca3vNEiT8V22WaZYKmBgF0 5ONm7QtXHfba0kmXpj0u+MQbOeBbr0E4pQfBo8NekqV6GIHuejNvmoqG9V1GzYLE7+bk qLGtmIwQBTvC+iUE09nt9O/1INDyaEFisO7ZWEPQ8Q4T3zunF/zm4EaaB+AT1vd3ajMk mR6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sgdr0XMrQA69ujJqp1335hTH3W5cyMxNwf4rU6YjLHs=; b=sqSOn69VGtiuO80J3WsPS8q2h6PxPbZqJbA25BVq85Oeir3pqNhWSlTu8rK8AwBCqi s69yLrMvuKECELO6VPgxxFUMRuQ+yGymdvDrQ8MXtHzZjXHZWzTqyGJl/Nu05wtE8dee KRWHLXQ6jEALXpm0JZj1KVziVdsSPUVZjR9HvW1Q2Y7PJoMsCkNZ3kA9eDbwBQuyb20s GsFe/WgLh0KAC1WAp5p628ZSLnAppWf3h7bZnZ408r8hwu25o2ewWcCiGQ5dheDIYwC4 P35GEj7L3Pws8DBlmR54jatcsHfPza8Mvynj6UXmHx3UMxFZ6zcHsPPaKC4OqSgMjufu fTDQ== X-Gm-Message-State: ABuFfogz9XihRVAxFy920r7ux9U3nDy9FMSjKfhh1PM/BvnDS/9Jia7Y dLMy7ERns0ftVrUZXhxVCkssfT7SQmuL6Dh7C5s= X-Google-Smtp-Source: ACcGV61leIocHpbbrqJnj8fX1jcGQ0+ugRQ7IzFJgv2TxeB9FzUr/0dJbqmnxIfKI10kZeATjFl9TyLifd/SZOK//1M= X-Received: by 2002:aed:219a:: with SMTP id l26-v6mr42817541qtc.81.1540217713177; Mon, 22 Oct 2018 07:15:13 -0700 (PDT) MIME-Version: 1.0 References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> In-Reply-To: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> From: "Andrew G. Malis" Date: Mon, 22 Oct 2018 10:15:02 -0400 Message-ID: To: ganesh.venkatesan@intel.com Cc: detnet WG Content-Type: multipart/alternative; boundary="000000000000abb95c0578d1e1dc" Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:15:20 -0000 --000000000000abb95c0578d1e1dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ganesh, For those of us that don't attend IEEE, can you fill us in on the relationship between 801.11 and TSN? As the DetNet documents already refer (in many places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we don't need to include explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh < ganesh.venkatesan@intel.com> wrote: > Hello DetNet members: > > > > We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our > experience with IEEE802.11 in managed deployments, we believe that 802.11 > links can meet DetNet requirements described in the use case document. In > addition there is a lot of work underway in IEEE802.1ax Task Group and in > other Topic Interest Groups within IEEE802.11 Working Group that renders > 802.11 as a versatile L2 media for DetNet. > > > > Please let me know if you have comments/questions on this submission: > > > > *Proposed addition of IEEE802.11 as a L2 Media to the > draft-ietf-detnet-use-cases-19 document:* > > > > *Rationale: 802.11 in a managed network environment meets the Use Case > requirements described in this document. The proposal is to use the 802.1= 1 > link in the DetNet network as the first or the last hop of the > wired/wireless end-to-end path.. * > > > > *Editor: the proposed text below can either be a standalone section or > added to the relevant subsections to section 11 of > https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt > .* > > > > x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 > > > > Thus far IEEE 802.11 has been the only wireless media technology that has > already included support for some of the 802.1 TSN capabilities required = to > address the use cases described in this document. The IEEE 802.11 working > group has been working in collaboration with the IEEE 802.1 group for > several years extending 802.1 features over 802.11. Therefore, in the Use > Cases described in this document, an IEEE 802.11 hop fits naturally into > the network. In all these cases, the DetNet under consideration is a > wired/wireless network with the first and/or the last nodes being > IEEE802.11 hops and the rest of the network is wired. As with any wireles= s > media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, > and tradeoffs between latency and reliability guarantees must be consider= ed > as well as managed deployment requirements. > > The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 > (along with a set of Wi-Fi Alliance Certifications to ensure > interoperability) and the work that is ongoing in IEEE802.11 WG renders > IEEE802.11 a natural fit for the DetNet described in this document. > > > > The following sub-sections are analogues of corresponding subsections in > section-11. The intent is to demonstrate how well IEEE802.11 MAC fits int= o > a network with DetNet properties where the edges of the network are > IEEE802.11 links: e.g the low cost seat speakers being connected over a > IEEE802.11 hop to the network, the HMI at the building management network= , > the sensors/alarms in the electric utility network. > > > > x.1.1 Extension to Ethernet and 802.1 TSN > > > > In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN > capabilities that are being now extended to routed networks by DetNet. IE= EE > 802.11ak bridges already defined bridging between 802.1 and 802.11 networ= ks > while maintaining domain-specific semantics. Several 802.1 AVB/TSN > specifications have equivalents in the IEEE802.11 domain (e.g. Clause 12 = of > IEEE802.1AS describes the 802.11 Timing Measurement protocol to enable > 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol > triggers generation of equivalent IEEE802.11 Add TS management frames). > Equivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic > Interest Group (IEEE802.11 TIG for Real Time Applications). > > > > x.1.4 L2 and L3 Integration > > In a managed network, mechanisms to integrate L2 and L3 layers (=E2=80=9C= making > AVB/TSN-type deterministic performance available from layer-3 application= s=E2=80=9D > or =E2=80=9Cconnecting two AVB/TSN LANs or =E2=80=98islands=E2=80=99 toge= ther through a standard > router=E2=80=9D) should extend to IEEE802.11 as L2. AVB/TSN protocol supp= ort over > IEEE802.11 is already supported for time synchronization, stream > identification and reservation and additional TSN capabilities are under > development (support for IEEE802.1Qbv, for instance). > > > > x.1.5 Consideration for IPv4 > > As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 > L2 link is achievable when the network is managed. From a wireless > perspective, this means that there is traffic planning to avoid over > subscription of wireless resources; frequency planning to > minimize/eliminate interference/congestion; stream identification for > prioritization; admission control to prevent over-subscription; time > synchronization as defined in 802.1AS, and 802.1Qbv-like control to > prioritize time-sensitive traffic. > > > > x.1.6 Guaranteed End-to-End Delivery > > Guaranteed e2e delivery is achieved in DetNet by constraining the network > (the network is not the open Internet but a constrained/managed network). > > With 802.11, similar constraints can be put in place in a managed > deployment. For instance, multiple channels and Basic Service Sets (BSSs) > may be defined that restrict access based on traffic stream identificatio= n > and admission control features already jointly supported by 802.1 and > 802.11. There are additional constraints that may be defined to achieve t= he > guarantees. > > > > x.1.7 Replacement for Multiple Proprietary Deterministic Networks > > IEEE802.11 has demonstrated interoperable ubiquitous deployment and it > already has the basic capabilities to interoperate with 802.1 TSN network= s. > With the mechanisms outlined in earlier sub-sections, this can extend to > provide DetNet performance. > > > > x.1.8 Mix of Deterministic and Best-Effort Traffic > > IEEE802.11 has QoS support to identify and prioritize time-sensitive > operational traffic. The prioritization (and the resulting improved > latency/reliability) becomes effective in a managed IEEE802.11 network an= d > has the potential to be even more effective with high efficiency features > from IEEE802.11ax, IEEE802.1Qbv over IEEE802.11, etc. > > x.1.9 Unused Reserved BW to be available to Best Effort Traffic > > The IEEE 802.11ax amendment enables the APs to have more control of the > medium and not only prioritize time-sensitive traffic, but also efficient= ly > allocate resources to Best Effort traffic. 802.11ax can significantly > improve efficiency while reducing contention and latency, which are key > aspects to support the TSN and DetNet use cases defined in this document. > > > > x.1.10 Lower Cost, Multi Vendor Solutions > > IEEE802.11 implementations supporting IEEE802.11 features have been > consistently available from multiple vendors at low cost. When IEEE802.11 > feature set is enhanced, the roll out of enhancements typically follows a > stable amendment in the IEEE 802.11 WG, development of a corresponding > interoperability certification from Wi-Fi Alliance and broad market > availability of the enhancements. > > > > In a managed network, we expect the off-the-shelf implementations of > IEEE802.11 protocol to be part of the DetNet and satisfy the requirements= . > In situations where IEE802.11 enhancements that are currently under > development of being planned for development soon, we envision the roll o= ut > described above and the availability of lower cost, interoperable > multi-vendor implementations with the enhancements to become available. > > > > x.3.1 Bounded Latency > > In managed IEEE802.11 networks, where Admission Control prevents > over-subscribing and minimizes collisions, and where QoS provides > prioritization of Operational Traffic, bounded latency for Operational > Traffic is achievable [reference: 18-1160r0] > > > > x.3.2 Low Latency > > Low latency requirement depends on the Use Case in question. There is som= e > trade-off in the low latency requirement for the convenience of being not > tethered to a wire, being mobile and being able to reconfigure the networ= k > as needed for the specific situation within the Use Case. > > However, low latencies [Reference 18-1160r0] to meet the requirements of = a > variety of Use Cases (pro AV, synchronized multi-channel audio, mobile > robotics, repetitive cyclic control systems (1 =E2=80=93 10 millisecond l= atencies > over the wireless hop) is achievable in a managed 802.11 network by > leveraging current TSN capabilities over 802.11, such as time > synchronization, stream identification and time-aware shaping.. > > x.5 Security > > WFA WPA3 provides robust security both for management and data packets. I= n > addition, WFA Easy Connect provides for robust security while supporting > easy onboarding of headless devices into the network. > > > > x.6 Future work > > x.6.1. Centrally Administered > > Central/distributed Administration =E2=80=93 there are aspects of the wir= eless > network (or the wireless hop from a wired/wireless bridge to a wireless > endpoint) that will have to be defined. For instance, the controller that > does the central administration may send the desired configuration to the > wired/wireless bridge (the wireless part in this bridge is the AP functio= n) > where it gets converted into parameters that are 802.11-specific. > > > > x.6.2 Standardized Data Flow Information Models > > Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be > required to ensure that this requirement is met when DetNet operates over > IEEE802.11 links. > > > > x.6.3 Symmetrical Path Delays > > This may be a challenge in 802.11 (probably in all wireless networks, > specifically indoors). Need to research this further. > > > > References: > > 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and > Physical Layer (PHY) Specifications > 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged > Networks > 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN > 4. WNG documents on RTA (18-1160r0): > https://mentor.ieee.org/802.11/dcn/18/11-18-1160-00-0wng-controlling-l= atency-in-802-11.pptx > 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) > 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) > 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) > 8. Wi-Fi Alliance TimeSyncTM > > > > Cheers -- > > ganesh > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --000000000000abb95c0578d1e1dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ganesh,

    For those of us that don't = attend IEEE, can you fill us in on the relationship between 801.11 and TSN?= As the DetNet documents already refer (in many places) to IEEE TSN as a la= yer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, = then it would seem to me that we don't need to include explicit referen= ces to 802.11. Just a thought.

    Thanks,
    A= ndy


    On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.com> wrote:

    Hello DetNet members:

    =C2=A0

    We proposed adding IEEE802.11 as a L2 media for DetN= et. Based on our experience with IEEE802.11 in managed deployments, we beli= eve that 802.11 links can meet DetNet requirements described in the use cas= e document. In addition there is a lot of work underway in IEEE802.1ax Task Group and in other Topic Interest= Groups within IEEE802.11 Working Group that renders 802.11 as a versatile = L2 media for DetNet.

    =C2=A0

    Please let me know if you have comments/questions on= this submission:

    =C2=A0

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:=

    =C2=A0

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ..

    =C2=A0

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.= txt.

    =C2=A0

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

    =C2=A0

    Thus far IEEE 802.11 has been the only wireless m= edia technology that has already included support for some of the 802.1 TSN= capabilities required to address the use cases described in this document. The IEEE 802.11 working group has been working in collaboration with the I= EEE 802.1 group for several years extending 802.1 features over 802.11. The= refore, in the Use Cases described in this document, an IEEE 802.11 hop fit= s naturally into the network. In all these cases, the DetNet under consideration is a wired/wireless networ= k with the first and/or the last nodes being IEEE802.11 hops and the rest o= f the network is wired. As with any wireless media, 802.11 imposes new cons= traints and restrictions to TSN-grade QoS, and tradeoffs between latency and reliability guarantees must be cons= idered as well as managed deployment requirements.

    The 802.1 and 802.11 feature set that is already part of I= EEE802.11-2016 (along with a set of Wi-Fi Alliance Certifications to ensure= interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNet described= in this document.

    =C2=A0

    The following sub-sections are analogues of corresponding = subsections in section-11. The intent is to demonstrate how well IEEE802.11= MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the low cost seat= speakers being connected over a IEEE802.11 hop to the network, the HMI at = the building management network, the sensors/alarms in the electric utility= network.

    =C2=A0

    x.1.1 Extension to Ethernet and 802.1 TSN

    =C2=A0

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

    =C2=A0

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate L2 and L3 la= yers (=E2=80=9Cmaking AVB/TSN-type deterministic performance available from= layer-3 applications=E2=80=9D or =E2=80=9Cconnecting two AVB/TSN LANs or =E2=80=98islands=E2=80=99 together through a standard router=E2=80=9D) = should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE802.11= is already supported for time synchronization, stream identification and r= eservation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

    =C2=A0

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

    =C2=A0

    x.1.6 Guaranteed End-to-End Delivery=

    Guaranteed e2e delivery is achieved in DetNet by = constraining the network (the network is not the open Internet but a constr= ained/managed network).

    With 802.11, similar constraints can be put in place in a = managed deployment. For instance, multiple channels and Basic Service Sets = (BSSs) may be defined that restrict access based on traffic stream identification and admission control features already jo= intly supported by 802.1 and 802.11. There are additional constraints that = may be defined to achieve the guarantees.=

    =C2=A0

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

    =C2=A0

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify and priori= tize time-sensitive operational traffic. The prioritization (and the result= ing improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even more effective with high efficien= cy features from IEEE802.11ax, IEEE802.1Qbv over IEEE802.11, etc.=

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

    =C2=A0

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

    =C2=A0

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

    =C2=A0

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admission Control pr= events over-subscribing and minimizes collisions, and where QoS provides pr= ioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r0]=

    =C2=A0

    x.3.2 Low Latency

    Low latency requirement depends on the Use Case i= n question. There is some trade-off in the low latency requirement for the = convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed for the specific situation withi= n the Use Case.

    However, low latencies [Reference 18-1160r0] to m= eet the requirements of a variety of Use Cases (pro AV, synchronized multi-= channel audio, mobile robotics, repetitive cyclic control systems (1 =E2=80=93 10 millisecond latencies over the wireless hop) is achievable in= a managed 802.11 network by leveraging current TSN capabilities over 802.1= 1, such as time synchronization, stream identification and time-aware shapi= ng..

    x.5 Security

    WFA WPA3 provides robust security both for management and = data packets. In addition, WFA Easy Connect provides for robust security wh= ile supporting easy onboarding of headless devices into the network.

    =C2=A0

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration =E2=80=93 there are asp= ects of the wireless network (or the wireless hop from a wired/wireless bri= dge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administration may send= the desired configuration to the wired/wireless bridge (the wireless part = in this bridge is the AP function) where it gets converted into parameters = that are 802.11-specific.

    =C2=A0

    x.6.2 Standardized Data Flow Information Models<= /u>

    Co-ordination between IETF DetNet and IEEE802.11 Working G= roups will be required to ensure that this requirement is met when DetNet o= perates over IEEE802.11 links.

    =C2=A0

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in all wireles= s networks, specifically indoors). Need to research this further.=

    =C2=A0

    References:

    1. IEEE802.11-2016: Wireless LAN Medium Access Cont= rol (MAC) and Physical Layer (PHY) Specifications
      2. =
    2. IEEE802.11ak-2017: Enhancements for Transit Link= s Within Bridged Networks
    3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN
    4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-= 1160-00-0wng-controlling-latency-in-802-11.pptx
    5. Wi-Fi Alliance Wireles= s Protected Access 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC)<= u>
    7. Wi-Fi Alliance Wireless Protec= ted Access 3 (WPA3)
    8. Wi-= Fi Alliance TimeSyncTM

    =C2=A0

    Cheers -= -

    ganesh

    =C2=A0

    _______________________________________________
    detnet mailing list
    detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
    --000000000000abb95c0578d1e1dc-- From nobody Mon Oct 22 10:26:02 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4B5131167; Mon, 22 Oct 2018 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW24xyq-7UjO; Mon, 22 Oct 2018 10:25:48 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (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 745DF130FB4; Mon, 22 Oct 2018 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qAlaG+7ryC+gBpwkWzniBT696+kY41w30GhPiP6afDA=; b=jC3gvUUBhpn0nu2p9ClIN/Q1cus0k2Vp+ufj+rnaOMCC1NuXVjnAkZx/9p2XWwJXhWsisye03jQNHny9rykJ3NMvI0a9ty0kYpBfdG8BNqbXX3cj8yaCITsmOgKAophPQiGfMclJcNyJ5pTxMSQYO0sRyKGS3eF1vdo/JI9Qetw= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4881.namprd06.prod.outlook.com (10.167.233.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.22; Mon, 22 Oct 2018 17:25:19 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8%3]) with mapi id 15.20.1250.028; Mon, 22 Oct 2018 17:25:19 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" CC: "detnet-chairs@ietf.org" Thread-Topic: IETF 103 Bangkok - DetNet Meeting Slot Requests Thread-Index: AdRiR4Gv6YTl6S6xQF+b1knHzb/QXgH5FXwQ Date: Mon, 22 Oct 2018 17:25:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4881; 6:zzde4unCE3VTsfIaB5kTBBoV10rdhJGN5Qkc0uKIGfUKHbTUUk49qy9qJNq4xWpZQe+ad2PoRu98t5TrNxJIyJ2Rno1oWJobnU+OZnYhv58TePUxTNjo2WGev3BKPPGHe64ncoQ2Qov0Zbj9tZ6G+G3KfsAaXCweDklARjnSkD2Nlm2mYasXDkKXQhin66A4Lg92IpSGpVhcyfTDKfKas9JmOtrCP31VrtVrln2nngGhhE+NyFNtJP07ACltljKSxmfDyQGcXCgz90kFYLi3QgGigdLilYSYVWUnd5TWN7mh+clidIf0GCGl8UVgKjZqmCBM3w7hSU2BP9t+7/xtJO03sXIVdMbHIogfl9ffGuTlOD8bEyvp0Mx3PILOxD4j8q/tOB9AQCGiLmyqcgO/XFNXl3epdcqPVhJtZjFG+Z7J7d9gDpi55U8oH1VA6/PE2xlX+aXUgihw6fH331c08w==; 5:TMBWhOp63R8QvlVe1dld1k7VKgBZLztczRdVct8R3gI0blMhMEGNjxI0Lf36vvEKz2JBnaPidvnq0ird05mttu8XEtFsR+UKLsY0H/1um53Pvumx0gxoEWATjZE7M4oGZS2j5EuWatrazhJ6nT3evhY/ckOjE6KDoWCw4oFJpiA=; 7:C2WLFK+B7p4wDijblxpBv4LiDul5+NHjWXzGp8eRN+UEhwT1GWrDgsZgnGAJl73jm6lwvEDzpNBGShaPkCFCQWHRtmGiLqpbxRJdaDEHI+ZiH0qcqajKHFhiOfhpv1n7UlFNXL4JzDG6zX3H/1LaoiAOxD4VVhzr4DituW6eMfAsOT79pPsMy4NrbuRgPm5kg++z7guWKSYxFXhUMRCQiCr2ZG3BGr8k295bc5bjn850xBK/OvGAnp10OlcEUNxU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6e70d033-d015-4e75-5aa1-08d638435746 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4881; x-ms-traffictypediagnostic: BL0PR06MB4881: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(10436049006162)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4881; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4881; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(53754006)(199004)(189003)(54014002)(53434003)(256004)(81156014)(106356001)(229853002)(1730700003)(25786009)(97736004)(55016002)(8936002)(14454004)(6916009)(2906002)(99286004)(5640700003)(105586002)(81166006)(26005)(53936002)(450100002)(4326008)(5660300001)(14444005)(102836004)(6436002)(6246003)(186003)(7696005)(5630700001)(86362001)(11346002)(53546011)(8676002)(6506007)(5250100002)(446003)(76176011)(478600001)(71190400001)(486006)(966005)(6306002)(54896002)(316002)(2900100001)(9686003)(33656002)(2501003)(71200400001)(2351001)(66066001)(7736002)(476003)(606006)(68736007)(74316002)(6116002)(3846002)(790700001)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4881; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RWeK4qwh3gOq+1M0HDXBRWSbxpfoBglSJsTgmdJKuQnSxUI+MGuyotlE3a2j8brqNGfwWeMVyTHq2K3EbyYec8uQHh/ZEbVCcgipfHTP28ugiIg4EzLqGK8OvdB2P56dWvuueTEew1/Cd2/43a557xUjzwWSGn30LlvAPKTea29FqHyuq7IMaCTLjlHIbhviw80FmosoHTq/9PRrA68N8d2Skuz2s3MIQPwV7moFEPZWbMhTjX+/vq06CYD8K3TZpiKz3y49Q9+QWqpe7HWH8Df8Io0yQ/IxE53Al9NZ9t8KUFgMcRX+WeZ2HIexvUGgnGkmpj/o8P44RFKEsvAPVvHFOPxAXC0es0/bBY78H0E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR06MB45481E2AB9907D7DBE7554A6C4F40BL0PR06MB4548namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e70d033-d015-4e75-5aa1-08d638435746 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 17:25:19.6759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4881 Archived-At: Subject: Re: [Detnet] IETF 103 Bangkok - DetNet Meeting Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 17:26:00 -0000 --_000_BL0PR06MB45481E2AB9907D7DBE7554A6C4F40BL0PR06MB4548namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that I plan to assemble the DetNet meeting slot requests th= is evening (California time). If you are still planning on submitting a req= uest please either submit it or let me know if you need a little more time. Thanks, Ethan (as DetNet WG Secretary). From: Grossman, Ethan A. Sent: Friday, October 12, 2018 9:21 AM To: detnet@ietf.org Cc: detnet-chairs@ietf.org Subject: IETF 103 Bangkok - DetNet Meeting Slot Requests Hi All, The IETF 103 Bangkok agenda has been posted: https://datatracker.ietf.org/meeting/103/agenda.html We're scheduled to meet: Thursday, November 8, 2018 (+07) 13:50-15:50 Thursday Afternoon session I Please send any slot requests to the chairs email alias (see above) no late= r than Monday October 22nd. Please include draft names(s), presenter and d= esired slot length. Please keep in mind that priority for presentation slo= ts is given to WG drafts and other drafts/topics discussed on the mailing l= ist. The cutoff date for draft submissions is also Monday October 22nd, see http= s://datatracker.ietf.org/meeting/important-dates/ Best, Ethan (as DetNet WG Secretary). --_000_BL0PR06MB45481E2AB9907D7DBE7554A6C4F40BL0PR06MB4548namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Just a reminder tha= t I plan to assemble the DetNet meeting slot requests this evening (Califor= nia time). If you are still planning on submitting a request please either = submit it or let me know if you need a little more time.

    Thanks,<= /span>

    Ethan (as DetNet WG= Secretary).

     

    From:= Grossman, Ethan A.
    Sent: Friday, October 12, 2018 9:21 AM
    To: detnet@ietf.org
    Cc: detnet-chairs@ietf.org
    Subject: IETF 103 Bangkok - DetNet Meeting Slot Requests<= /span>

     

    Hi All,

     

    The IETF 103 Bangkok agenda has been posted= :

     

        https://datatracker.ietf.org/meeting/103/agenda.html

     

    We're scheduled to meet:<= /p>

    Thursday, November 8, 2018 (+07)=

    13:50-15:50 Thursday Afternoon session I

     

    Please send any slot requests to the chairs= email alias (see above) no later than Monday October 22nd.  Plea= se include draft names(s), presenter and desired slot length.  Please keep in mind that priority for presentation slots is given to WG dr= afts and other drafts/topics discussed on the mailing list.

     

    The cutoff date for draft submissions is al= so Monday October 22nd, see https://datatracker.ietf.org/meeting= /important-dates/

     

    Best,

    Ethan (as DetNet WG Secretary).=

     

    --_000_BL0PR06MB45481E2AB9907D7DBE7554A6C4F40BL0PR06MB4548namp_-- From nobody Mon Oct 22 12:33:58 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE0C12F18C for ; Mon, 22 Oct 2018 12:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPZYwYQmGQrU for ; Mon, 22 Oct 2018 12:33:52 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 93B4C12D7EA for ; Mon, 22 Oct 2018 12:33:51 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 12:33:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,413,1534834800"; d="scan'208,217";a="101499319" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga001.fm.intel.com with ESMTP; 22 Oct 2018 12:33:50 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX103.amr.corp.intel.com ([169.254.5.46]) with mapi id 14.03.0319.002; Mon, 22 Oct 2018 12:33:50 -0700 From: "Venkatesan, Ganesh" To: "Andrew G. Malis" CC: detnet WG Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAkcy8AAAPJfDA= Date: Mon, 22 Oct 2018 19:33:49 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDQxZmFlMTItNmVjOS00ODRiLTkxMzEtMWY1YWU2NjcxMzFkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ0NZVk05XC9KZUhDSjcrdmxwbm1QVzUyeG5SeUVXVXdtRmRYWjlBNXhnVG9jdTFvcytPNmF1eFh3Z1JkQnVacGoifQ== dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B590253ORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 19:33:57 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B590253ORSMSX107amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQW5keToNCg0KUmVhZGluZyB0aGUgY3VycmVudCBkcmFmdCwgc3BlY2lmaWNhbGx5IHNl Y3Rpb24gNS4xLjEsIEkgZ2V0IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIGN1cnJlbnQgVXNlIENh c2UgZG9jdW1lbnQgZG9lcyBub3QgY29uc2lkZXIgSUVFRTgwMi4xMSBhcyBwYXJ0IG9mIOKAmElF RUUgVFNOIGFzIGEgbGF5ZXIyIGZvciBEZXROZXTigJkuIEdpdmVuIHRoYXQgdGhlIFRTTiB3b3Jr IGlzIGRvbmUgaW4gSUVFRTgwMi4xIFRTTiwgZG8geW91IHBlcmNlaXZlIElFRUU4MDIuMTEgYXMg 4oCYSUVFRSBUU04gYXMgYSBsYXllcjIgZm9yIERldE5ldOKAmT8gQW5kIHdvdWxkIHRoYXQgYmUg dGhlIHBlcmNlcHRpb24gb2YgdGhlIHJlc3Qgb2YgdGhlIElFVEYgRGV0TmV0IG1lbWJlcnNoaXA/ IElmIHlvdXIgYW5zd2VyIGlzIFllcyB0byBib3RoIHRoZSBxdWVzdGlvbnMsIHRoZW4gSSB3b3Vs ZCBhZ3JlZSAoYW5kIGlmIHdlIGRlbGV0ZSB0aGUgcmVmZXJlbmNlIGluIHNlY3Rpb24gNS4xLjEg d2hlcmUgdGhlIGN1cnJlbnQgZHJhZnQgY2FsbHMgb3V0IElFRUU4MDIuMTEgKFdpRmkpIGFzIHVu c3VpdGVkIGZvciBEZXROZXQpICB0aGF0IOKAnHdlIGRvbuKAmXQgbmVlZCB0byBpbmNsdWRlIGV4 cGxpY2l0IHJlZmVyZW5jZXMgdG8gODAyLjEx4oCdLCBidXQgY2FyZWZ1bGx5IGNhbGwgb3V0IGlu IG90aGVyIHBlcnRpbmVudCBJRVRGIERldE5ldCBSRkNzIHdoZXJlIElFRUU4MDIuMTEgbWVjaGFu aXNtcyByZXF1aXJlZCB0byBtZWV0IERldE5ldCByZXF1aXJlbWVudHMgZXhwbGljaXRseS4NCg0K Q2hlZXJzIC0tDQpnYW5lc2gNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWls LmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxOCAxMDoxNSBBTQ0KVG86IFZlbmth dGVzYW4sIEdhbmVzaCA8Z2FuZXNoLnZlbmthdGVzYW5AaW50ZWwuY29tPg0KQ2M6IGRldG5ldCBX RyA8ZGV0bmV0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEZXRuZXRdIHByb3Bvc2VkIGFkZGl0 aW9uIG9mIElFRUU4MDIuMTEgYXMgTDIgTWVkaWEgdG8gZHRhZnQtaWV0Zi1kZXRuZXQtdXNlLWNh c2VzLTE5DQoNCkdhbmVzaCwNCg0KRm9yIHRob3NlIG9mIHVzIHRoYXQgZG9uJ3QgYXR0ZW5kIElF RUUsIGNhbiB5b3UgZmlsbCB1cyBpbiBvbiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gODAxLjEx IGFuZCBUU04/IEFzIHRoZSBEZXROZXQgZG9jdW1lbnRzIGFscmVhZHkgcmVmZXIgKGluIG1hbnkg cGxhY2VzKSB0byBJRUVFIFRTTiBhcyBhIGxheWVyIDIgbWVkaWEgZm9yIERldE5ldCwgaWYgODAx LjExIGlzIGFscmVhZHkgaW5jbHVkZWQgaW4gdGhlIFRTTiB1bWJyZWxsYSwgdGhlbiBpdCB3b3Vs ZCBzZWVtIHRvIG1lIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byBpbmNsdWRlIGV4cGxpY2l0IHJlZmVy ZW5jZXMgdG8gODAyLjExLiBKdXN0IGEgdGhvdWdodC4NCg0KVGhhbmtzLA0KQW5keQ0KDQoNCk9u IFN1biwgT2N0IDIxLCAyMDE4IGF0IDExOjU2IFBNIFZlbmthdGVzYW4sIEdhbmVzaCA8Z2FuZXNo LnZlbmthdGVzYW5AaW50ZWwuY29tPG1haWx0bzpnYW5lc2gudmVua2F0ZXNhbkBpbnRlbC5jb20+ PiB3cm90ZToNCkhlbGxvIERldE5ldCBtZW1iZXJzOg0KDQpXZSBwcm9wb3NlZCBhZGRpbmcgSUVF RTgwMi4xMSBhcyBhIEwyIG1lZGlhIGZvciBEZXROZXQuIEJhc2VkIG9uIG91ciBleHBlcmllbmNl IHdpdGggSUVFRTgwMi4xMSBpbiBtYW5hZ2VkIGRlcGxveW1lbnRzLCB3ZSBiZWxpZXZlIHRoYXQg ODAyLjExIGxpbmtzIGNhbiBtZWV0IERldE5ldCByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGluIHRo ZSB1c2UgY2FzZSBkb2N1bWVudC4gSW4gYWRkaXRpb24gdGhlcmUgaXMgYSBsb3Qgb2Ygd29yayB1 bmRlcndheSBpbiBJRUVFODAyLjFheCBUYXNrIEdyb3VwIGFuZCBpbiBvdGhlciBUb3BpYyBJbnRl cmVzdCBHcm91cHMgd2l0aGluIElFRUU4MDIuMTEgV29ya2luZyBHcm91cCB0aGF0IHJlbmRlcnMg ODAyLjExIGFzIGEgdmVyc2F0aWxlIEwyIG1lZGlhIGZvciBEZXROZXQuDQoNClBsZWFzZSBsZXQg bWUga25vdyBpZiB5b3UgaGF2ZSBjb21tZW50cy9xdWVzdGlvbnMgb24gdGhpcyBzdWJtaXNzaW9u Og0KDQpQcm9wb3NlZCBhZGRpdGlvbiBvZiBJRUVFODAyLjExIGFzIGEgTDIgTWVkaWEgdG8gdGhl IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOSBkb2N1bWVudDoNCg0KUmF0aW9uYWxlOiA4 MDIuMTEgaW4gYSBtYW5hZ2VkIG5ldHdvcmsgZW52aXJvbm1lbnQgbWVldHMgdGhlIFVzZSBDYXNl IHJlcXVpcmVtZW50cyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gVGhlIHByb3Bvc2FsIGlz IHRvIHVzZSB0aGUgODAyLjExIGxpbmsgaW4gdGhlIERldE5ldCBuZXR3b3JrIGFzIHRoZSBmaXJz dCBvciB0aGUgbGFzdCBob3Agb2YgdGhlIHdpcmVkL3dpcmVsZXNzIGVuZC10by1lbmQgcGF0aC4u DQoNCkVkaXRvcjogdGhlIHByb3Bvc2VkIHRleHQgYmVsb3cgY2FuIGVpdGhlciBiZSBhIHN0YW5k YWxvbmUgc2VjdGlvbiBvciBhZGRlZCB0byB0aGUgcmVsZXZhbnQgc3Vic2VjdGlvbnMgdG8gc2Vj dGlvbiAxMSBvZiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRldG5ldC11c2Ut Y2FzZXMtMTkudHh0Lg0KDQp4LiBVc2UgQ2FzZSBDb21tb24gVGhlbWVzIHdpdGggTDIgTWVkaXVt IEFjY2VzcyBDb250cm9sIGFzIElFRUU4MDIuMTENCg0KDQpUaHVzIGZhciBJRUVFIDgwMi4xMSBo YXMgYmVlbiB0aGUgb25seSB3aXJlbGVzcyBtZWRpYSB0ZWNobm9sb2d5IHRoYXQgaGFzIGFscmVh ZHkgaW5jbHVkZWQgc3VwcG9ydCBmb3Igc29tZSBvZiB0aGUgODAyLjEgVFNOIGNhcGFiaWxpdGll cyByZXF1aXJlZCB0byBhZGRyZXNzIHRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQuIFRoZSBJRUVFIDgwMi4xMSB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHdvcmtpbmcgaW4g Y29sbGFib3JhdGlvbiB3aXRoIHRoZSBJRUVFIDgwMi4xIGdyb3VwIGZvciBzZXZlcmFsIHllYXJz IGV4dGVuZGluZyA4MDIuMSBmZWF0dXJlcyBvdmVyIDgwMi4xMS4gVGhlcmVmb3JlLCBpbiB0aGUg VXNlIENhc2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCBhbiBJRUVFIDgwMi4xMSBob3Ag Zml0cyBuYXR1cmFsbHkgaW50byB0aGUgbmV0d29yay4gSW4gYWxsIHRoZXNlIGNhc2VzLCB0aGUg RGV0TmV0IHVuZGVyIGNvbnNpZGVyYXRpb24gaXMgYSB3aXJlZC93aXJlbGVzcyBuZXR3b3JrIHdp dGggdGhlIGZpcnN0IGFuZC9vciB0aGUgbGFzdCBub2RlcyBiZWluZyBJRUVFODAyLjExIGhvcHMg YW5kIHRoZSByZXN0IG9mIHRoZSBuZXR3b3JrIGlzIHdpcmVkLiBBcyB3aXRoIGFueSB3aXJlbGVz cyBtZWRpYSwgODAyLjExIGltcG9zZXMgbmV3IGNvbnN0cmFpbnRzIGFuZCByZXN0cmljdGlvbnMg dG8gVFNOLWdyYWRlIFFvUywgYW5kIHRyYWRlb2ZmcyBiZXR3ZWVuIGxhdGVuY3kgYW5kIHJlbGlh YmlsaXR5IGd1YXJhbnRlZXMgbXVzdCBiZSBjb25zaWRlcmVkIGFzIHdlbGwgYXMgbWFuYWdlZCBk ZXBsb3ltZW50IHJlcXVpcmVtZW50cy4NClRoZSA4MDIuMSBhbmQgODAyLjExIGZlYXR1cmUgc2V0 IHRoYXQgaXMgYWxyZWFkeSBwYXJ0IG9mIElFRUU4MDIuMTEtMjAxNiAoYWxvbmcgd2l0aCBhIHNl dCBvZiBXaS1GaSBBbGxpYW5jZSBDZXJ0aWZpY2F0aW9ucyB0byBlbnN1cmUgaW50ZXJvcGVyYWJp bGl0eSkgYW5kIHRoZSB3b3JrIHRoYXQgaXMgb25nb2luZyBpbiBJRUVFODAyLjExIFdHIHJlbmRl cnMgSUVFRTgwMi4xMSBhIG5hdHVyYWwgZml0IGZvciB0aGUgRGV0TmV0IGRlc2NyaWJlZCBpbiB0 aGlzIGRvY3VtZW50Lg0KDQpUaGUgZm9sbG93aW5nIHN1Yi1zZWN0aW9ucyBhcmUgYW5hbG9ndWVz IG9mIGNvcnJlc3BvbmRpbmcgc3Vic2VjdGlvbnMgaW4gc2VjdGlvbi0xMS4gVGhlIGludGVudCBp cyB0byBkZW1vbnN0cmF0ZSBob3cgd2VsbCBJRUVFODAyLjExIE1BQyBmaXRzIGludG8gYSBuZXR3 b3JrIHdpdGggRGV0TmV0IHByb3BlcnRpZXMgd2hlcmUgdGhlIGVkZ2VzIG9mIHRoZSBuZXR3b3Jr IGFyZSBJRUVFODAyLjExIGxpbmtzOiBlLmcgdGhlIGxvdyBjb3N0IHNlYXQgc3BlYWtlcnMgYmVp bmcgY29ubmVjdGVkIG92ZXIgYSBJRUVFODAyLjExIGhvcCB0byB0aGUgbmV0d29yaywgdGhlIEhN SSBhdCB0aGUgYnVpbGRpbmcgbWFuYWdlbWVudCBuZXR3b3JrLCB0aGUgc2Vuc29ycy9hbGFybXMg aW4gdGhlIGVsZWN0cmljIHV0aWxpdHkgbmV0d29yay4NCg0KeC4xLjEgRXh0ZW5zaW9uIHRvIEV0 aGVybmV0IGFuZCA4MDIuMSBUU04NCg0KSW4gYWRkaXRpb24gdG8gSUVFRSA4MDIuMywgODAyLjEx IGlzIGFsc28gYSB0YXJnZXQgbWVkaWEgZm9yIDgwMi4xIFRTTiBjYXBhYmlsaXRpZXMgdGhhdCBh cmUgYmVpbmcgbm93IGV4dGVuZGVkIHRvIHJvdXRlZCBuZXR3b3JrcyBieSBEZXROZXQuIElFRUUg ODAyLjExYWsgYnJpZGdlcyBhbHJlYWR5IGRlZmluZWQgYnJpZGdpbmcgYmV0d2VlbiA4MDIuMSBh bmQgODAyLjExIG5ldHdvcmtzIHdoaWxlIG1haW50YWluaW5nIGRvbWFpbi1zcGVjaWZpYyBzZW1h bnRpY3MuIFNldmVyYWwgODAyLjEgQVZCL1RTTiBzcGVjaWZpY2F0aW9ucyBoYXZlIGVxdWl2YWxl bnRzIGluIHRoZSBJRUVFODAyLjExIGRvbWFpbiAoZS5nLiBDbGF1c2UgMTIgb2YgSUVFRTgwMi4x QVMgZGVzY3JpYmVzIHRoZSA4MDIuMTEgVGltaW5nIE1lYXN1cmVtZW50IHByb3RvY29sIHRvIGVu YWJsZSA4MDIuMUFTIG92ZXIgODAyLjExIGxpbmtzLCBJRUVFODAyLjFRYXQgU3RyZWFtIFJlc2Vy dmF0aW9uIFByb3RvY29sIHRyaWdnZXJzIGdlbmVyYXRpb24gb2YgZXF1aXZhbGVudCBJRUVFODAy LjExIEFkZCBUUyBtYW5hZ2VtZW50IGZyYW1lcykuIEVxdWl2YWxlbnQgb2YgdGhlIElFRUUgODAy LjFRYnYgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIGEgSUVFRTgwMi4xMSBUb3BpYyBJbnRlcmVzdCBH cm91cCAoSUVFRTgwMi4xMSBUSUcgZm9yIFJlYWwgVGltZSBBcHBsaWNhdGlvbnMpLg0KDQp4LjEu NCBMMiBhbmQgTDMgSW50ZWdyYXRpb24NCkluIGEgbWFuYWdlZCBuZXR3b3JrLCBtZWNoYW5pc21z IHRvIGludGVncmF0ZSBMMiBhbmQgTDMgbGF5ZXJzICjigJxtYWtpbmcgQVZCL1RTTi10eXBlIGRl dGVybWluaXN0aWMgcGVyZm9ybWFuY2UgYXZhaWxhYmxlIGZyb20gbGF5ZXItMyBhcHBsaWNhdGlv bnPigJ0gb3Ig4oCcY29ubmVjdGluZyB0d28gQVZCL1RTTiBMQU5zIG9yIOKAmGlzbGFuZHPigJkg dG9nZXRoZXIgdGhyb3VnaCBhIHN0YW5kYXJkIHJvdXRlcuKAnSkgc2hvdWxkIGV4dGVuZCB0byBJ RUVFODAyLjExIGFzIEwyLiBBVkIvVFNOIHByb3RvY29sIHN1cHBvcnQgb3ZlciBJRUVFODAyLjEx IGlzIGFscmVhZHkgc3VwcG9ydGVkIGZvciB0aW1lIHN5bmNocm9uaXphdGlvbiwgc3RyZWFtIGlk ZW50aWZpY2F0aW9uIGFuZCByZXNlcnZhdGlvbiBhbmQgYWRkaXRpb25hbCBUU04gY2FwYWJpbGl0 aWVzIGFyZSB1bmRlciBkZXZlbG9wbWVudCAoc3VwcG9ydCBmb3IgSUVFRTgwMi4xUWJ2LCBmb3Ig aW5zdGFuY2UpLg0KDQp4LjEuNSBDb25zaWRlcmF0aW9uIGZvciBJUHY0DQpBcyBkaXNjdXNzZWQg aW4geC4xLjQsIEwzIERldE5ldCBwZXJmb3JtYW5jZSBvdmVyIElQdjQgb3ZlciBhbiBJRUVFODAy LjExIEwyIGxpbmsgaXMgYWNoaWV2YWJsZSB3aGVuIHRoZSBuZXR3b3JrIGlzIG1hbmFnZWQuIEZy b20gYSB3aXJlbGVzcyBwZXJzcGVjdGl2ZSwgdGhpcyBtZWFucyB0aGF0IHRoZXJlIGlzIHRyYWZm aWMgcGxhbm5pbmcgdG8gYXZvaWQgb3ZlciBzdWJzY3JpcHRpb24gb2Ygd2lyZWxlc3MgcmVzb3Vy Y2VzOyBmcmVxdWVuY3kgcGxhbm5pbmcgdG8gbWluaW1pemUvZWxpbWluYXRlIGludGVyZmVyZW5j ZS9jb25nZXN0aW9uOyBzdHJlYW0gaWRlbnRpZmljYXRpb24gZm9yIHByaW9yaXRpemF0aW9uOyBh ZG1pc3Npb24gY29udHJvbCB0byBwcmV2ZW50IG92ZXItc3Vic2NyaXB0aW9uOyB0aW1lIHN5bmNo cm9uaXphdGlvbiBhcyBkZWZpbmVkIGluIDgwMi4xQVMsIGFuZCA4MDIuMVFidi1saWtlIGNvbnRy b2wgdG8gcHJpb3JpdGl6ZSB0aW1lLXNlbnNpdGl2ZSB0cmFmZmljLg0KDQp4LjEuNiBHdWFyYW50 ZWVkIEVuZC10by1FbmQgRGVsaXZlcnkNCg0KR3VhcmFudGVlZCBlMmUgZGVsaXZlcnkgaXMgYWNo aWV2ZWQgaW4gRGV0TmV0IGJ5IGNvbnN0cmFpbmluZyB0aGUgbmV0d29yayAodGhlIG5ldHdvcmsg aXMgbm90IHRoZSBvcGVuIEludGVybmV0IGJ1dCBhIGNvbnN0cmFpbmVkL21hbmFnZWQgbmV0d29y aykuDQpXaXRoIDgwMi4xMSwgc2ltaWxhciBjb25zdHJhaW50cyBjYW4gYmUgcHV0IGluIHBsYWNl IGluIGEgbWFuYWdlZCBkZXBsb3ltZW50LiBGb3IgaW5zdGFuY2UsIG11bHRpcGxlIGNoYW5uZWxz IGFuZCBCYXNpYyBTZXJ2aWNlIFNldHMgKEJTU3MpIG1heSBiZSBkZWZpbmVkIHRoYXQgcmVzdHJp Y3QgYWNjZXNzIGJhc2VkIG9uIHRyYWZmaWMgc3RyZWFtIGlkZW50aWZpY2F0aW9uIGFuZCBhZG1p c3Npb24gY29udHJvbCBmZWF0dXJlcyBhbHJlYWR5IGpvaW50bHkgc3VwcG9ydGVkIGJ5IDgwMi4x IGFuZCA4MDIuMTEuIFRoZXJlIGFyZSBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIHRoYXQgbWF5IGJl IGRlZmluZWQgdG8gYWNoaWV2ZSB0aGUgZ3VhcmFudGVlcy4NCg0KeC4xLjcgUmVwbGFjZW1lbnQg Zm9yIE11bHRpcGxlIFByb3ByaWV0YXJ5IERldGVybWluaXN0aWMgTmV0d29ya3MNCklFRUU4MDIu MTEgaGFzIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmxlIHViaXF1aXRvdXMgZGVwbG95bWVudCBh bmQgaXQgYWxyZWFkeSBoYXMgdGhlIGJhc2ljIGNhcGFiaWxpdGllcyB0byBpbnRlcm9wZXJhdGUg d2l0aCA4MDIuMSBUU04gbmV0d29ya3MuIFdpdGggdGhlIG1lY2hhbmlzbXMgb3V0bGluZWQgaW4g ZWFybGllciBzdWItc2VjdGlvbnMsIHRoaXMgY2FuIGV4dGVuZCB0byBwcm92aWRlIERldE5ldCBw ZXJmb3JtYW5jZS4NCg0KeC4xLjggTWl4IG9mIERldGVybWluaXN0aWMgYW5kIEJlc3QtRWZmb3J0 IFRyYWZmaWMNCg0KSUVFRTgwMi4xMSBoYXMgUW9TIHN1cHBvcnQgdG8gaWRlbnRpZnkgYW5kIHBy aW9yaXRpemUgdGltZS1zZW5zaXRpdmUgb3BlcmF0aW9uYWwgdHJhZmZpYy4gVGhlIHByaW9yaXRp emF0aW9uIChhbmQgdGhlIHJlc3VsdGluZyBpbXByb3ZlZCBsYXRlbmN5L3JlbGlhYmlsaXR5KSBi ZWNvbWVzIGVmZmVjdGl2ZSBpbiBhIG1hbmFnZWQgSUVFRTgwMi4xMSBuZXR3b3JrIGFuZCBoYXMg dGhlIHBvdGVudGlhbCB0byBiZSBldmVuIG1vcmUgZWZmZWN0aXZlIHdpdGggaGlnaCBlZmZpY2ll bmN5IGZlYXR1cmVzIGZyb20gSUVFRTgwMi4xMWF4LCBJRUVFODAyLjFRYnYgb3ZlciBJRUVFODAy LjExLCBldGMuDQp4LjEuOSBVbnVzZWQgUmVzZXJ2ZWQgQlcgdG8gYmUgYXZhaWxhYmxlIHRvIEJl c3QgRWZmb3J0IFRyYWZmaWMNClRoZSBJRUVFIDgwMi4xMWF4IGFtZW5kbWVudCBlbmFibGVzIHRo ZSBBUHMgdG8gaGF2ZSBtb3JlIGNvbnRyb2wgb2YgdGhlIG1lZGl1bSBhbmQgbm90IG9ubHkgcHJp b3JpdGl6ZSB0aW1lLXNlbnNpdGl2ZSB0cmFmZmljLCBidXQgYWxzbyBlZmZpY2llbnRseSBhbGxv Y2F0ZSByZXNvdXJjZXMgdG8gQmVzdCBFZmZvcnQgdHJhZmZpYy4gODAyLjExYXggY2FuIHNpZ25p ZmljYW50bHkgaW1wcm92ZSBlZmZpY2llbmN5IHdoaWxlIHJlZHVjaW5nIGNvbnRlbnRpb24gYW5k IGxhdGVuY3ksIHdoaWNoIGFyZSBrZXkgYXNwZWN0cyB0byBzdXBwb3J0IHRoZSBUU04gYW5kIERl dE5ldCB1c2UgY2FzZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQp4LjEuMTAgTG93ZXIg Q29zdCwgTXVsdGkgVmVuZG9yIFNvbHV0aW9ucw0KSUVFRTgwMi4xMSBpbXBsZW1lbnRhdGlvbnMg c3VwcG9ydGluZyBJRUVFODAyLjExIGZlYXR1cmVzIGhhdmUgYmVlbiBjb25zaXN0ZW50bHkgYXZh aWxhYmxlIGZyb20gbXVsdGlwbGUgdmVuZG9ycyBhdCBsb3cgY29zdC4gV2hlbiBJRUVFODAyLjEx IGZlYXR1cmUgc2V0IGlzIGVuaGFuY2VkLCB0aGUgcm9sbCBvdXQgb2YgZW5oYW5jZW1lbnRzIHR5 cGljYWxseSBmb2xsb3dzIGEgc3RhYmxlIGFtZW5kbWVudCBpbiB0aGUgSUVFRSA4MDIuMTEgV0cs IGRldmVsb3BtZW50IG9mIGEgY29ycmVzcG9uZGluZyBpbnRlcm9wZXJhYmlsaXR5IGNlcnRpZmlj YXRpb24gZnJvbSBXaS1GaSBBbGxpYW5jZSBhbmQgYnJvYWQgbWFya2V0IGF2YWlsYWJpbGl0eSBv ZiB0aGUgZW5oYW5jZW1lbnRzLg0KDQpJbiBhIG1hbmFnZWQgbmV0d29yaywgd2UgZXhwZWN0IHRo ZSBvZmYtdGhlLXNoZWxmIGltcGxlbWVudGF0aW9ucyBvZiBJRUVFODAyLjExIHByb3RvY29sIHRv IGJlIHBhcnQgb2YgdGhlIERldE5ldCBhbmQgc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzLiBJbiBz aXR1YXRpb25zIHdoZXJlIElFRTgwMi4xMSBlbmhhbmNlbWVudHMgdGhhdCBhcmUgY3VycmVudGx5 IHVuZGVyIGRldmVsb3BtZW50IG9mIGJlaW5nIHBsYW5uZWQgZm9yIGRldmVsb3BtZW50IHNvb24s IHdlIGVudmlzaW9uIHRoZSByb2xsIG91dCBkZXNjcmliZWQgYWJvdmUgYW5kIHRoZSBhdmFpbGFi aWxpdHkgb2YgbG93ZXIgY29zdCwgaW50ZXJvcGVyYWJsZSBtdWx0aS12ZW5kb3IgaW1wbGVtZW50 YXRpb25zIHdpdGggdGhlIGVuaGFuY2VtZW50cyB0byBiZWNvbWUgYXZhaWxhYmxlLg0KDQp4LjMu MSBCb3VuZGVkIExhdGVuY3kNCkluIG1hbmFnZWQgSUVFRTgwMi4xMSBuZXR3b3Jrcywgd2hlcmUg QWRtaXNzaW9uIENvbnRyb2wgcHJldmVudHMgb3Zlci1zdWJzY3JpYmluZyBhbmQgbWluaW1pemVz IGNvbGxpc2lvbnMsIGFuZCB3aGVyZSBRb1MgcHJvdmlkZXMgcHJpb3JpdGl6YXRpb24gb2YgT3Bl cmF0aW9uYWwgVHJhZmZpYywgYm91bmRlZCBsYXRlbmN5IGZvciBPcGVyYXRpb25hbCBUcmFmZmlj IGlzIGFjaGlldmFibGUgW3JlZmVyZW5jZTogMTgtMTE2MHIwXQ0KDQp4LjMuMiBMb3cgTGF0ZW5j eQ0KDQpMb3cgbGF0ZW5jeSByZXF1aXJlbWVudCBkZXBlbmRzIG9uIHRoZSBVc2UgQ2FzZSBpbiBx dWVzdGlvbi4gVGhlcmUgaXMgc29tZSB0cmFkZS1vZmYgaW4gdGhlIGxvdyBsYXRlbmN5IHJlcXVp cmVtZW50IGZvciB0aGUgY29udmVuaWVuY2Ugb2YgYmVpbmcgbm90IHRldGhlcmVkIHRvIGEgd2ly ZSwgYmVpbmcgbW9iaWxlIGFuZCBiZWluZyBhYmxlIHRvIHJlY29uZmlndXJlIHRoZSBuZXR3b3Jr IGFzIG5lZWRlZCBmb3IgdGhlIHNwZWNpZmljIHNpdHVhdGlvbiB3aXRoaW4gdGhlIFVzZSBDYXNl Lg0KDQpIb3dldmVyLCBsb3cgbGF0ZW5jaWVzIFtSZWZlcmVuY2UgMTgtMTE2MHIwXSB0byBtZWV0 IHRoZSByZXF1aXJlbWVudHMgb2YgYSB2YXJpZXR5IG9mIFVzZSBDYXNlcyAocHJvIEFWLCBzeW5j aHJvbml6ZWQgbXVsdGktY2hhbm5lbCBhdWRpbywgbW9iaWxlIHJvYm90aWNzLCByZXBldGl0aXZl IGN5Y2xpYyBjb250cm9sIHN5c3RlbXMgKDEg4oCTIDEwIG1pbGxpc2Vjb25kIGxhdGVuY2llcyBv dmVyIHRoZSB3aXJlbGVzcyBob3ApIGlzIGFjaGlldmFibGUgaW4gYSBtYW5hZ2VkIDgwMi4xMSBu ZXR3b3JrIGJ5IGxldmVyYWdpbmcgY3VycmVudCBUU04gY2FwYWJpbGl0aWVzIG92ZXIgODAyLjEx LCBzdWNoIGFzIHRpbWUgc3luY2hyb25pemF0aW9uLCBzdHJlYW0gaWRlbnRpZmljYXRpb24gYW5k IHRpbWUtYXdhcmUgc2hhcGluZy4uDQp4LjUgU2VjdXJpdHkNCldGQSBXUEEzIHByb3ZpZGVzIHJv YnVzdCBzZWN1cml0eSBib3RoIGZvciBtYW5hZ2VtZW50IGFuZCBkYXRhIHBhY2tldHMuIEluIGFk ZGl0aW9uLCBXRkEgRWFzeSBDb25uZWN0IHByb3ZpZGVzIGZvciByb2J1c3Qgc2VjdXJpdHkgd2hp bGUgc3VwcG9ydGluZyBlYXN5IG9uYm9hcmRpbmcgb2YgaGVhZGxlc3MgZGV2aWNlcyBpbnRvIHRo ZSBuZXR3b3JrLg0KDQp4LjYgRnV0dXJlIHdvcmsNCnguNi4xLiBDZW50cmFsbHkgQWRtaW5pc3Rl cmVkDQpDZW50cmFsL2Rpc3RyaWJ1dGVkIEFkbWluaXN0cmF0aW9uIOKAkyB0aGVyZSBhcmUgYXNw ZWN0cyBvZiB0aGUgd2lyZWxlc3MgbmV0d29yayAob3IgdGhlIHdpcmVsZXNzIGhvcCBmcm9tIGEg d2lyZWQvd2lyZWxlc3MgYnJpZGdlIHRvIGEgd2lyZWxlc3MgZW5kcG9pbnQpIHRoYXQgd2lsbCBo YXZlIHRvIGJlIGRlZmluZWQuIEZvciBpbnN0YW5jZSwgdGhlIGNvbnRyb2xsZXIgdGhhdCBkb2Vz IHRoZSBjZW50cmFsIGFkbWluaXN0cmF0aW9uIG1heSBzZW5kIHRoZSBkZXNpcmVkIGNvbmZpZ3Vy YXRpb24gdG8gdGhlIHdpcmVkL3dpcmVsZXNzIGJyaWRnZSAodGhlIHdpcmVsZXNzIHBhcnQgaW4g dGhpcyBicmlkZ2UgaXMgdGhlIEFQIGZ1bmN0aW9uKSB3aGVyZSBpdCBnZXRzIGNvbnZlcnRlZCBp bnRvIHBhcmFtZXRlcnMgdGhhdCBhcmUgODAyLjExLXNwZWNpZmljLg0KDQp4LjYuMiBTdGFuZGFy ZGl6ZWQgRGF0YSBGbG93IEluZm9ybWF0aW9uIE1vZGVscw0KQ28tb3JkaW5hdGlvbiBiZXR3ZWVu IElFVEYgRGV0TmV0IGFuZCBJRUVFODAyLjExIFdvcmtpbmcgR3JvdXBzIHdpbGwgYmUgcmVxdWly ZWQgdG8gZW5zdXJlIHRoYXQgdGhpcyByZXF1aXJlbWVudCBpcyBtZXQgd2hlbiBEZXROZXQgb3Bl cmF0ZXMgb3ZlciBJRUVFODAyLjExIGxpbmtzLg0KDQoNCnguNi4zIFN5bW1ldHJpY2FsIFBhdGgg RGVsYXlzDQpUaGlzIG1heSBiZSBhIGNoYWxsZW5nZSBpbiA4MDIuMTEgKHByb2JhYmx5IGluIGFs bCB3aXJlbGVzcyBuZXR3b3Jrcywgc3BlY2lmaWNhbGx5IGluZG9vcnMpLiBOZWVkIHRvIHJlc2Vh cmNoIHRoaXMgZnVydGhlci4NCg0KDQpSZWZlcmVuY2VzOg0KDQogIDEuICBJRUVFODAyLjExLTIw MTY6IFdpcmVsZXNzIExBTiBNZWRpdW0gQWNjZXNzIENvbnRyb2wgKE1BQykgYW5kIFBoeXNpY2Fs IExheWVyIChQSFkpIFNwZWNpZmljYXRpb25zDQogIDIuICBJRUVFODAyLjExYWstMjAxNzogRW5o YW5jZW1lbnRzIGZvciBUcmFuc2l0IExpbmtzIFdpdGhpbiBCcmlkZ2VkIE5ldHdvcmtzDQogIDMu ICBJRUVFODAyLjExYXggRDMuMDogRW5oYW5jZW1lbnRzIGZvciBIaWdoIEVmZmljaWVuY3kgV0xB Tg0KICA0LiAgV05HIGRvY3VtZW50cyBvbiBSVEEgKDE4LTExNjByMCk6IGh0dHBzOi8vbWVudG9y LmllZWUub3JnLzgwMi4xMS9kY24vMTgvMTEtMTgtMTE2MC0wMC0wd25nLWNvbnRyb2xsaW5nLWxh dGVuY3ktaW4tODAyLTExLnBwdHgNCiAgNS4gIFdpLUZpIEFsbGlhbmNlIFdpcmVsZXNzIFByb3Rl Y3RlZCBBY2Nlc3MgMiAoV1BBMikNCiAgNi4gIFdpLUZpIEFsbGlhbmNlIFdpcmVsZXNzIE11bHRp LU1lZGlhIEFkbWlzc2lvbiBDb250cm9sIChXTU0tQUMpDQogIDcuICBXaS1GaSBBbGxpYW5jZSBX aXJlbGVzcyBQcm90ZWN0ZWQgQWNjZXNzIDMgKFdQQTMpDQogIDguICBXaS1GaSBBbGxpYW5jZSBU aW1lU3luY1RNDQoNCkNoZWVycyAtLQ0KZ2FuZXNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpkZXRuZXQgbWFpbGluZyBsaXN0DQpkZXRuZXRAaWV0 Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGV0bmV0DQo= --_000_311BE885E0DA8D4BB369A037CF5B64A79B590253ORSMSX107amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTgyNjc2NDQ2NTU3MTU3NDk4NzVt c29jb21tZW50dGV4dCwgbGkubTgyNjc2NDQ2NTU3MTU3NDk4NzVtc29jb21tZW50dGV4dCwgZGl2 Lm04MjY3NjQ0NjU1NzE1NzQ5ODc1bXNvY29tbWVudHRleHQNCgl7bXNvLXN0eWxlLW5hbWU6bV84 MjY3NjQ0NjU1NzE1NzQ5ODc1bXNvY29tbWVudHRleHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTkyMjUwNzcyOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTA5NjYyNTIyODt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQW5keTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVhZGluZyB0aGUgY3VycmVudCBkcmFmdCwgc3BlY2lmaWNhbGx5IHNlY3Rpb24gNS4xLjEsIEkg Z2V0IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIGN1cnJlbnQgVXNlIENhc2UgZG9jdW1lbnQgZG9l cyBub3QgY29uc2lkZXIgSUVFRTgwMi4xMSBhcyBwYXJ0IG9mIOKAmElFRUUgVFNOIGFzIGEgbGF5 ZXIyIGZvciBEZXROZXTigJkuIEdpdmVuIHRoYXQgdGhlIFRTTiB3b3JrIGlzIGRvbmUgaW4gSUVF RTgwMi4xIFRTTiwNCiBkbyB5b3UgcGVyY2VpdmUgSUVFRTgwMi4xMSBhcyDigJhJRUVFIFRTTiBh cyBhIGxheWVyMiBmb3IgRGV0TmV04oCZPyBBbmQgd291bGQgdGhhdCBiZSB0aGUgcGVyY2VwdGlv biBvZiB0aGUgcmVzdCBvZiB0aGUgSUVURiBEZXROZXQgbWVtYmVyc2hpcD8gSWYgeW91ciBhbnN3 ZXIgaXMgWWVzIHRvIGJvdGggdGhlIHF1ZXN0aW9ucywgdGhlbiBJIHdvdWxkIGFncmVlIChhbmQg aWYgd2UgZGVsZXRlIHRoZSByZWZlcmVuY2UgaW4gc2VjdGlvbiA1LjEuMSB3aGVyZQ0KIHRoZSBj dXJyZW50IGRyYWZ0IGNhbGxzIG91dCBJRUVFODAyLjExIChXaUZpKSBhcyB1bnN1aXRlZCBmb3Ig RGV0TmV0KSAmbmJzcDt0aGF0IOKAnHdlIGRvbuKAmXQgbmVlZCB0byBpbmNsdWRlIGV4cGxpY2l0 IHJlZmVyZW5jZXMgdG8gODAyLjEx4oCdLCBidXQgY2FyZWZ1bGx5IGNhbGwgb3V0IGluIG90aGVy IHBlcnRpbmVudCBJRVRGIERldE5ldCBSRkNzIHdoZXJlIElFRUU4MDIuMTEgbWVjaGFuaXNtcyBy ZXF1aXJlZCB0byBtZWV0IERldE5ldCByZXF1aXJlbWVudHMNCiBleHBsaWNpdGx5LiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymx1 ZSI+Q2hlZXJzIC0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymx1ZSI+Z2FuZXNoPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQW5kcmV3IEcuIE1hbGlzICZsdDth Z21hbGlzQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAy MiwgMjAxOCAxMDoxNSBBTTxicj4NCjxiPlRvOjwvYj4gVmVua2F0ZXNhbiwgR2FuZXNoICZsdDtn YW5lc2gudmVua2F0ZXNhbkBpbnRlbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkZXRuZXQgV0cg Jmx0O2RldG5ldEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRd IHByb3Bvc2VkIGFkZGl0aW9uIG9mIElFRUU4MDIuMTEgYXMgTDIgTWVkaWEgdG8gZHRhZnQtaWV0 Zi1kZXRuZXQtdXNlLWNhc2VzLTE5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HYW5l c2gsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhv c2Ugb2YgdXMgdGhhdCBkb24ndCBhdHRlbmQgSUVFRSwgY2FuIHlvdSBmaWxsIHVzIGluIG9uIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiA4MDEuMTEgYW5kIFRTTj8gQXMgdGhlIERldE5ldCBkb2N1 bWVudHMgYWxyZWFkeSByZWZlciAoaW4gbWFueSBwbGFjZXMpIHRvIElFRUUgVFNOIGFzIGEgbGF5 ZXIgMiBtZWRpYSBmb3IgRGV0TmV0LCBpZiA4MDEuMTEgaXMgYWxyZWFkeSBpbmNsdWRlZCBpbiB0 aGUNCiBUU04gdW1icmVsbGEsIHRoZW4gaXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHdlIGRvbid0 IG5lZWQgdG8gaW5jbHVkZSBleHBsaWNpdCByZWZlcmVuY2VzIHRvIDgwMi4xMS4gSnVzdCBhIHRo b3VnaHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAyMSwgMjAxOCBhdCAxMTo1NiBQTSBWZW5rYXRlc2FuLCBH YW5lc2ggJmx0OzxhIGhyZWY9Im1haWx0bzpnYW5lc2gudmVua2F0ZXNhbkBpbnRlbC5jb20iPmdh bmVzaC52ZW5rYXRlc2FuQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhlbGxvIERldE5ldCBtZW1iZXJzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgcHJv cG9zZWQgYWRkaW5nIElFRUU4MDIuMTEgYXMgYSBMMiBtZWRpYSBmb3IgRGV0TmV0LiBCYXNlZCBv biBvdXIgZXhwZXJpZW5jZSB3aXRoIElFRUU4MDIuMTEgaW4gbWFuYWdlZCBkZXBsb3ltZW50cywg d2UgYmVsaWV2ZSB0aGF0IDgwMi4xMSBsaW5rcyBjYW4gbWVldCBEZXROZXQgcmVxdWlyZW1lbnRz DQogZGVzY3JpYmVkIGluIHRoZSB1c2UgY2FzZSBkb2N1bWVudC4gSW4gYWRkaXRpb24gdGhlcmUg aXMgYSBsb3Qgb2Ygd29yayB1bmRlcndheSBpbiBJRUVFODAyLjFheCBUYXNrIEdyb3VwIGFuZCBp biBvdGhlciBUb3BpYyBJbnRlcmVzdCBHcm91cHMgd2l0aGluIElFRUU4MDIuMTEgV29ya2luZyBH cm91cCB0aGF0IHJlbmRlcnMgODAyLjExIGFzIGEgdmVyc2F0aWxlIEwyIG1lZGlhIGZvciBEZXRO ZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IGhhdmUgY29tbWVudHMvcXVlc3Rpb25zIG9uIHRoaXMgc3VibWlzc2lvbjo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Qcm9wb3NlZCBhZGRpdGlv biBvZiBJRUVFODAyLjExIGFzIGEgTDIgTWVkaWEgdG8gdGhlIGRyYWZ0LWlldGYtZGV0bmV0LXVz ZS1jYXNlcy0xOSBkb2N1bWVudDo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlJhdGlvbmFsZTogODAyLjExIGluIGEgbWFuYWdlZCBuZXR3b3JrIGVudmlyb25tZW50 IG1lZXRzIHRoZSBVc2UgQ2FzZSByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQuDQogVGhlIHByb3Bvc2FsIGlzIHRvIHVzZSB0aGUgODAyLjExIGxpbmsgaW4gdGhlIERldE5l dCBuZXR3b3JrIGFzIHRoZSBmaXJzdCBvciB0aGUgbGFzdCBob3Agb2YgdGhlIHdpcmVkL3dpcmVs ZXNzIGVuZC10by1lbmQgcGF0aC4uDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkVkaXRvcjogdGhlIHByb3Bvc2VkIHRleHQgYmVsb3cgY2FuIGVpdGhlciBi ZSBhIHN0YW5kYWxvbmUgc2VjdGlvbiBvciBhZGRlZCB0byB0aGUgcmVsZXZhbnQgc3Vic2VjdGlv bnMNCiB0byBzZWN0aW9uIDExIG9mIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOS50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOS50eHQ8L2E+ Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+eC4gVXNlIENhc2UgQ29tbW9u IFRoZW1lcyB3aXRoIEwyIE1lZGl1bSBBY2Nlc3MgQ29udHJvbCBhcyBJRUVFODAyLjExPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MjY3NjQ0NjU1 NzE1NzQ5ODc1bXNvY29tbWVudHRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGh1cyBmYXIgSUVFRSA4MDIuMTEgaGFzIGJlZW4gdGhlIG9ubHkg d2lyZWxlc3MgbWVkaWEgdGVjaG5vbG9neSB0aGF0IGhhcyBhbHJlYWR5IGluY2x1ZGVkIHN1cHBv cnQgZm9yIHNvbWUgb2YgdGhlIDgwMi4xIFRTTiBjYXBhYmlsaXRpZXMgcmVxdWlyZWQgdG8gYWRk cmVzcyB0aGUgdXNlIGNhc2VzDQogZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuIFRoZSBJRUVF IDgwMi4xMSB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHdvcmtpbmcgaW4gY29sbGFib3JhdGlvbiB3 aXRoIHRoZSBJRUVFIDgwMi4xIGdyb3VwIGZvciBzZXZlcmFsIHllYXJzIGV4dGVuZGluZyA4MDIu MSBmZWF0dXJlcyBvdmVyIDgwMi4xMS4gVGhlcmVmb3JlLCBpbiB0aGUgVXNlIENhc2VzIGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50LCBhbiBJRUVFIDgwMi4xMSBob3AgZml0cyBuYXR1cmFsbHkN CiBpbnRvIHRoZSBuZXR3b3JrLiBJbiBhbGwgdGhlc2UgY2FzZXMsIHRoZSBEZXROZXQgdW5kZXIg Y29uc2lkZXJhdGlvbiBpcyBhIHdpcmVkL3dpcmVsZXNzIG5ldHdvcmsgd2l0aCB0aGUgZmlyc3Qg YW5kL29yIHRoZSBsYXN0IG5vZGVzIGJlaW5nIElFRUU4MDIuMTEgaG9wcyBhbmQgdGhlIHJlc3Qg b2YgdGhlIG5ldHdvcmsgaXMgd2lyZWQuIEFzIHdpdGggYW55IHdpcmVsZXNzIG1lZGlhLCA4MDIu MTEgaW1wb3NlcyBuZXcgY29uc3RyYWludHMgYW5kDQogcmVzdHJpY3Rpb25zIHRvIFRTTi1ncmFk ZSBRb1MsIGFuZCB0cmFkZW9mZnMgYmV0d2VlbiBsYXRlbmN5IGFuZCByZWxpYWJpbGl0eSBndWFy YW50ZWVzIG11c3QgYmUgY29uc2lkZXJlZCBhcyB3ZWxsIGFzIG1hbmFnZWQgZGVwbG95bWVudCBy ZXF1aXJlbWVudHMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5UaGUgODAyLjEgYW5kIDgwMi4xMSBmZWF0dXJlIHNldCB0aGF0IGlzIGFs cmVhZHkgcGFydCBvZiBJRUVFODAyLjExLTIwMTYgKGFsb25nIHdpdGggYSBzZXQgb2YgV2ktRmkg QWxsaWFuY2UgQ2VydGlmaWNhdGlvbnMNCiB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSkgYW5k IHRoZSB3b3JrIHRoYXQgaXMgb25nb2luZyBpbiBJRUVFODAyLjExIFdHIHJlbmRlcnMgSUVFRTgw Mi4xMSBhIG5hdHVyYWwgZml0IGZvciB0aGUgRGV0TmV0IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoZSBmb2xsb3dpbmcgc3ViLXNlY3Rpb25zIGFyZSBhbmFsb2d1ZXMgb2YgY29y cmVzcG9uZGluZyBzdWJzZWN0aW9ucyBpbiBzZWN0aW9uLTExLiBUaGUgaW50ZW50IGlzIHRvIGRl bW9uc3RyYXRlIGhvdyB3ZWxsDQogSUVFRTgwMi4xMSBNQUMgZml0cyBpbnRvIGEgbmV0d29yayB3 aXRoIERldE5ldCBwcm9wZXJ0aWVzIHdoZXJlIHRoZSBlZGdlcyBvZiB0aGUgbmV0d29yayBhcmUg SUVFRTgwMi4xMSBsaW5rczogZS5nIHRoZSBsb3cgY29zdCBzZWF0IHNwZWFrZXJzIGJlaW5nIGNv bm5lY3RlZCBvdmVyIGEgSUVFRTgwMi4xMSBob3AgdG8gdGhlIG5ldHdvcmssIHRoZSBITUkgYXQg dGhlIGJ1aWxkaW5nIG1hbmFnZW1lbnQgbmV0d29yaywgdGhlIHNlbnNvcnMvYWxhcm1zDQogaW4g dGhlIGVsZWN0cmljIHV0aWxpdHkgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij54LjEuMSBFeHRlbnNpb24gdG8gRXRoZXJuZXQgYW5kIDgwMi4xIFRTTjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPkluIGFkZGl0aW9uIHRvIElFRUUgODAyLjMsIDgwMi4xMSBpcyBhbHNv IGEgdGFyZ2V0IG1lZGlhIGZvciA4MDIuMSBUU04gY2FwYWJpbGl0aWVzIHRoYXQgYXJlIGJlaW5n IG5vdyBleHRlbmRlZA0KIHRvIHJvdXRlZCBuZXR3b3JrcyBieSBEZXROZXQuIElFRUUgODAyLjEx YWsgYnJpZGdlcyBhbHJlYWR5IGRlZmluZWQgYnJpZGdpbmcgYmV0d2VlbiA4MDIuMSBhbmQgODAy LjExIG5ldHdvcmtzIHdoaWxlIG1haW50YWluaW5nIGRvbWFpbi1zcGVjaWZpYyBzZW1hbnRpY3Mu IFNldmVyYWwgODAyLjEgQVZCL1RTTiBzcGVjaWZpY2F0aW9ucyBoYXZlIGVxdWl2YWxlbnRzIGlu IHRoZSBJRUVFODAyLjExIGRvbWFpbiAoZS5nLiBDbGF1c2UgMTIgb2YgSUVFRTgwMi4xQVMNCiBk ZXNjcmliZXMgdGhlIDgwMi4xMSBUaW1pbmcgTWVhc3VyZW1lbnQgcHJvdG9jb2wgdG8gZW5hYmxl IDgwMi4xQVMgb3ZlciA4MDIuMTEgbGlua3MsIElFRUU4MDIuMVFhdCBTdHJlYW0gUmVzZXJ2YXRp b24gUHJvdG9jb2wgdHJpZ2dlcnMgZ2VuZXJhdGlvbiBvZiBlcXVpdmFsZW50IElFRUU4MDIuMTEg QWRkIFRTIG1hbmFnZW1lbnQgZnJhbWVzKS4gRXF1aXZhbGVudCBvZiB0aGUgSUVFRSA4MDIuMVFi diBpcyBiZWluZyBkaXNjdXNzZWQgaW4gYSBJRUVFODAyLjExDQogVG9waWMgSW50ZXJlc3QgR3Jv dXAgKElFRUU4MDIuMTEgVElHIGZvciBSZWFsIFRpbWUgQXBwbGljYXRpb25zKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij54LjEuNCBMMiBhbmQgTDMgSW50ZWdyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBhIG1hbmFnZWQgbmV0d29yaywg bWVjaGFuaXNtcyB0byBpbnRlZ3JhdGUgTDIgYW5kIEwzIGxheWVycyAo4oCcbWFraW5nIEFWQi9U U04tdHlwZSBkZXRlcm1pbmlzdGljIHBlcmZvcm1hbmNlIGF2YWlsYWJsZQ0KIGZyb20gbGF5ZXIt MyBhcHBsaWNhdGlvbnPigJ0gb3Ig4oCcY29ubmVjdGluZyB0d28gQVZCL1RTTiBMQU5zIG9yIOKA mGlzbGFuZHPigJkgdG9nZXRoZXIgdGhyb3VnaCBhIHN0YW5kYXJkIHJvdXRlcuKAnSkgc2hvdWxk IGV4dGVuZCB0byBJRUVFODAyLjExIGFzIEwyLiBBVkIvVFNOIHByb3RvY29sIHN1cHBvcnQgb3Zl ciBJRUVFODAyLjExIGlzIGFscmVhZHkgc3VwcG9ydGVkIGZvciB0aW1lIHN5bmNocm9uaXphdGlv biwgc3RyZWFtIGlkZW50aWZpY2F0aW9uIGFuZA0KIHJlc2VydmF0aW9uIGFuZCBhZGRpdGlvbmFs IFRTTiBjYXBhYmlsaXRpZXMgYXJlIHVuZGVyIGRldmVsb3BtZW50IChzdXBwb3J0IGZvciBJRUVF ODAyLjFRYnYsIGZvciBpbnN0YW5jZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+eC4xLjUgQ29uc2lkZXJhdGlvbiBmb3IgSVB2 NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkFzIGRpc2N1c3NlZCBpbiB4LjEuNCwgTDMgRGV0TmV0IHBlcmZvcm1hbmNl IG92ZXIgSVB2NCBvdmVyIGFuIElFRUU4MDIuMTEgTDIgbGluayBpcyBhY2hpZXZhYmxlIHdoZW4g dGhlIG5ldHdvcmsNCiBpcyBtYW5hZ2VkLiBGcm9tIGEgd2lyZWxlc3MgcGVyc3BlY3RpdmUsIHRo aXMgbWVhbnMgdGhhdCB0aGVyZSBpcyB0cmFmZmljIHBsYW5uaW5nIHRvIGF2b2lkIG92ZXIgc3Vi c2NyaXB0aW9uIG9mIHdpcmVsZXNzIHJlc291cmNlczsgZnJlcXVlbmN5IHBsYW5uaW5nIHRvIG1p bmltaXplL2VsaW1pbmF0ZSBpbnRlcmZlcmVuY2UvY29uZ2VzdGlvbjsgc3RyZWFtIGlkZW50aWZp Y2F0aW9uIGZvciBwcmlvcml0aXphdGlvbjsgYWRtaXNzaW9uIGNvbnRyb2wNCiB0byBwcmV2ZW50 IG92ZXItc3Vic2NyaXB0aW9uOyB0aW1lIHN5bmNocm9uaXphdGlvbiBhcyBkZWZpbmVkIGluIDgw Mi4xQVMsIGFuZCA4MDIuMVFidi1saWtlIGNvbnRyb2wgdG8gcHJpb3JpdGl6ZSB0aW1lLXNlbnNp dGl2ZSB0cmFmZmljLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnguMS42IEd1YXJhbnRl ZWQgRW5kLXRvLUVuZCBEZWxpdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt ODI2NzY0NDY1NTcxNTc0OTg3NW1zb2NvbW1lbnR0ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkd1YXJhbnRlZWQgZTJlIGRlbGl2ZXJ5IGlzIGFj aGlldmVkIGluIERldE5ldCBieSBjb25zdHJhaW5pbmcgdGhlIG5ldHdvcmsgKHRoZSBuZXR3b3Jr IGlzIG5vdCB0aGUgb3BlbiBJbnRlcm5ldCBidXQgYSBjb25zdHJhaW5lZC9tYW5hZ2VkIG5ldHdv cmspLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPldpdGggODAyLjExLCBzaW1pbGFyIGNvbnN0cmFpbnRzIGNhbiBiZSBwdXQgaW4gcGxhY2Ug aW4gYSBtYW5hZ2VkIGRlcGxveW1lbnQuIEZvciBpbnN0YW5jZSwgbXVsdGlwbGUgY2hhbm5lbHMg YW5kIEJhc2ljDQogU2VydmljZSBTZXRzIChCU1NzKSBtYXkgYmUgZGVmaW5lZCB0aGF0IHJlc3Ry aWN0IGFjY2VzcyBiYXNlZCBvbiB0cmFmZmljIHN0cmVhbSBpZGVudGlmaWNhdGlvbiBhbmQgYWRt aXNzaW9uIGNvbnRyb2wgZmVhdHVyZXMgYWxyZWFkeSBqb2ludGx5IHN1cHBvcnRlZCBieSA4MDIu MSBhbmQgODAyLjExLiBUaGVyZSBhcmUgYWRkaXRpb25hbCBjb25zdHJhaW50cyB0aGF0IG1heSBi ZSBkZWZpbmVkIHRvIGFjaGlldmUgdGhlIGd1YXJhbnRlZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+eC4xLjcgUmVwbGFjZW1lbnQgZm9yIE11bHRpcGxlIFByb3ByaWV0YXJ5IERldGVy bWluaXN0aWMgTmV0d29ya3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JRUVFODAyLjExIGhhcyBkZW1vbnN0cmF0ZWQg aW50ZXJvcGVyYWJsZSB1YmlxdWl0b3VzIGRlcGxveW1lbnQgYW5kIGl0IGFscmVhZHkgaGFzIHRo ZSBiYXNpYyBjYXBhYmlsaXRpZXMgdG8NCiBpbnRlcm9wZXJhdGUgd2l0aCA4MDIuMSBUU04gbmV0 d29ya3MuIFdpdGggdGhlIG1lY2hhbmlzbXMgb3V0bGluZWQgaW4gZWFybGllciBzdWItc2VjdGlv bnMsIHRoaXMgY2FuIGV4dGVuZCB0byBwcm92aWRlIERldE5ldCBwZXJmb3JtYW5jZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj54LjEuOCBNaXggb2YgRGV0ZXJtaW5pc3RpYyBhbmQgQmVz dC1FZmZvcnQgVHJhZmZpYzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODI2NzY0 NDY1NTcxNTc0OTg3NW1zb2NvbW1lbnR0ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPklFRUU4MDIuMTEgaGFzIFFvUyBzdXBwb3J0IHRvIGlkZW50 aWZ5IGFuZCBwcmlvcml0aXplIHRpbWUtc2Vuc2l0aXZlIG9wZXJhdGlvbmFsIHRyYWZmaWMuIFRo ZSBwcmlvcml0aXphdGlvbiAoYW5kIHRoZSByZXN1bHRpbmcgaW1wcm92ZWQgbGF0ZW5jeS9yZWxp YWJpbGl0eSkgYmVjb21lcyBlZmZlY3RpdmUNCiBpbiBhIG1hbmFnZWQgSUVFRTgwMi4xMSBuZXR3 b3JrIGFuZCBoYXMgdGhlIHBvdGVudGlhbCB0byBiZSBldmVuIG1vcmUgZWZmZWN0aXZlIHdpdGgg aGlnaCBlZmZpY2llbmN5IGZlYXR1cmVzIGZyb20gSUVFRTgwMi4xMWF4LCBJRUVFODAyLjFRYnYg b3ZlciBJRUVFODAyLjExLCBldGMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+eC4xLjkgVW51c2VkIFJlc2VydmVkIEJX IHRvIGJlIGF2YWlsYWJsZSB0byBCZXN0IEVmZm9ydCBUcmFmZmljPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIElF RUUgODAyLjExYXggYW1lbmRtZW50IGVuYWJsZXMgdGhlIEFQcyB0byBoYXZlIG1vcmUgY29udHJv bCBvZiB0aGUgbWVkaXVtIGFuZCBub3Qgb25seSBwcmlvcml0aXplIHRpbWUtc2Vuc2l0aXZlDQog dHJhZmZpYywgYnV0IGFsc28gZWZmaWNpZW50bHkgYWxsb2NhdGUgcmVzb3VyY2VzIHRvIEJlc3Qg RWZmb3J0IHRyYWZmaWMuIDgwMi4xMWF4IGNhbiBzaWduaWZpY2FudGx5IGltcHJvdmUgZWZmaWNp ZW5jeSB3aGlsZSByZWR1Y2luZyBjb250ZW50aW9uIGFuZCBsYXRlbmN5LCB3aGljaCBhcmUga2V5 IGFzcGVjdHMgdG8gc3VwcG9ydCB0aGUgVFNOIGFuZCBEZXROZXQgdXNlIGNhc2VzIGRlZmluZWQg aW4gdGhpcyBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj54LjEuMTAgTG93 ZXIgQ29zdCwgTXVsdGkgVmVuZG9yIFNvbHV0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPklFRUU4MDIuMTEgaW1w bGVtZW50YXRpb25zIHN1cHBvcnRpbmcgSUVFRTgwMi4xMSBmZWF0dXJlcyBoYXZlIGJlZW4gY29u c2lzdGVudGx5IGF2YWlsYWJsZSBmcm9tIG11bHRpcGxlIHZlbmRvcnMNCiBhdCBsb3cgY29zdC4g V2hlbiBJRUVFODAyLjExIGZlYXR1cmUgc2V0IGlzIGVuaGFuY2VkLCB0aGUgcm9sbCBvdXQgb2Yg ZW5oYW5jZW1lbnRzIHR5cGljYWxseSBmb2xsb3dzIGEgc3RhYmxlIGFtZW5kbWVudCBpbiB0aGUg SUVFRSA4MDIuMTEgV0csIGRldmVsb3BtZW50IG9mIGEgY29ycmVzcG9uZGluZyBpbnRlcm9wZXJh YmlsaXR5IGNlcnRpZmljYXRpb24gZnJvbSBXaS1GaSBBbGxpYW5jZSBhbmQgYnJvYWQgbWFya2V0 IGF2YWlsYWJpbGl0eSBvZg0KIHRoZSBlbmhhbmNlbWVudHMuIDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkluIGEgbWFuYWdlZCBuZXR3b3JrLCB3ZSBleHBlY3QgdGhlIG9mZi10aGUtc2hl bGYgaW1wbGVtZW50YXRpb25zIG9mIElFRUU4MDIuMTEgcHJvdG9jb2wgdG8gYmUgcGFydCBvZiB0 aGUgRGV0TmV0DQogYW5kIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cy4gSW4gc2l0dWF0aW9ucyB3 aGVyZSBJRUU4MDIuMTEgZW5oYW5jZW1lbnRzIHRoYXQgYXJlIGN1cnJlbnRseSB1bmRlciBkZXZl bG9wbWVudCBvZiBiZWluZyBwbGFubmVkIGZvciBkZXZlbG9wbWVudCBzb29uLCB3ZSBlbnZpc2lv biB0aGUgcm9sbCBvdXQgZGVzY3JpYmVkIGFib3ZlIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9mIGxv d2VyIGNvc3QsIGludGVyb3BlcmFibGUgbXVsdGktdmVuZG9yIGltcGxlbWVudGF0aW9ucw0KIHdp dGggdGhlIGVuaGFuY2VtZW50cyB0byBiZWNvbWUgYXZhaWxhYmxlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPnguMy4xIEJvdW5kZWQgTGF0ZW5jeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkluIG1hbmFnZWQgSUVFRTgwMi4xMSBu ZXR3b3Jrcywgd2hlcmUgQWRtaXNzaW9uIENvbnRyb2wgcHJldmVudHMgb3Zlci1zdWJzY3JpYmlu ZyBhbmQgbWluaW1pemVzIGNvbGxpc2lvbnMsIGFuZCB3aGVyZSBRb1MNCiBwcm92aWRlcyBwcmlv cml0aXphdGlvbiBvZiBPcGVyYXRpb25hbCBUcmFmZmljLCBib3VuZGVkIGxhdGVuY3kgZm9yIE9w ZXJhdGlvbmFsIFRyYWZmaWMgaXMgYWNoaWV2YWJsZSBbcmVmZXJlbmNlOiAxOC0xMTYwcjBdPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+eC4zLjIgTG93IExhdGVuY3k8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTgyNjc2NDQ2NTU3MTU3NDk4NzVtc29jb21tZW50dGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Mb3cgbGF0 ZW5jeSByZXF1aXJlbWVudCBkZXBlbmRzIG9uIHRoZSBVc2UgQ2FzZSBpbiBxdWVzdGlvbi4gVGhl cmUgaXMgc29tZSB0cmFkZS1vZmYgaW4gdGhlIGxvdyBsYXRlbmN5IHJlcXVpcmVtZW50IGZvciB0 aGUgY29udmVuaWVuY2Ugb2YgYmVpbmcgbm90IHRldGhlcmVkIHRvIGEgd2lyZSwgYmVpbmcNCiBt b2JpbGUgYW5kIGJlaW5nIGFibGUgdG8gcmVjb25maWd1cmUgdGhlIG5ldHdvcmsgYXMgbmVlZGVk IGZvciB0aGUgc3BlY2lmaWMgc2l0dWF0aW9uIHdpdGhpbiB0aGUgVXNlIENhc2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MjY3NjQ0NjU1NzE1NzQ5ODc1bXNvY29tbWVudHRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93 ZXZlciwgbG93IGxhdGVuY2llcyBbUmVmZXJlbmNlIDE4LTExNjByMF0gdG8gbWVldCB0aGUgcmVx dWlyZW1lbnRzIG9mIGEgdmFyaWV0eSBvZiBVc2UgQ2FzZXMgKHBybyBBViwgc3luY2hyb25pemVk IG11bHRpLWNoYW5uZWwgYXVkaW8sIG1vYmlsZSByb2JvdGljcywgcmVwZXRpdGl2ZSBjeWNsaWMN CiBjb250cm9sIHN5c3RlbXMgKDEg4oCTIDEwIG1pbGxpc2Vjb25kIGxhdGVuY2llcyBvdmVyIHRo ZSB3aXJlbGVzcyBob3ApIGlzIGFjaGlldmFibGUgaW4gYSBtYW5hZ2VkIDgwMi4xMSBuZXR3b3Jr IGJ5IGxldmVyYWdpbmcgY3VycmVudCBUU04gY2FwYWJpbGl0aWVzIG92ZXIgODAyLjExLCBzdWNo IGFzIHRpbWUgc3luY2hyb25pemF0aW9uLCBzdHJlYW0gaWRlbnRpZmljYXRpb24gYW5kIHRpbWUt YXdhcmUgc2hhcGluZy4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+eC41IFNlY3VyaXR5PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5XRkEgV1BBMyBwcm92aWRlcyByb2J1c3Qgc2Vj dXJpdHkgYm90aCBmb3IgbWFuYWdlbWVudCBhbmQgZGF0YSBwYWNrZXRzLiBJbiBhZGRpdGlvbiwg V0ZBIEVhc3kgQ29ubmVjdCBwcm92aWRlcyBmb3Igcm9idXN0DQogc2VjdXJpdHkgd2hpbGUgc3Vw cG9ydGluZyBlYXN5IG9uYm9hcmRpbmcgb2YgaGVhZGxlc3MgZGV2aWNlcyBpbnRvIHRoZSBuZXR3 b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnguNiBGdXR1cmUgd29yazwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPnguNi4xLiBDZW50cmFsbHkgQWRtaW5pc3RlcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2VudHJhbC9kaXN0cmlidXRlZCBBZG1p bmlzdHJhdGlvbiDigJMgdGhlcmUgYXJlIGFzcGVjdHMgb2YgdGhlIHdpcmVsZXNzIG5ldHdvcmsg KG9yIHRoZSB3aXJlbGVzcyBob3AgZnJvbSBhIHdpcmVkL3dpcmVsZXNzDQogYnJpZGdlIHRvIGEg d2lyZWxlc3MgZW5kcG9pbnQpIHRoYXQgd2lsbCBoYXZlIHRvIGJlIGRlZmluZWQuIEZvciBpbnN0 YW5jZSwgdGhlIGNvbnRyb2xsZXIgdGhhdCBkb2VzIHRoZSBjZW50cmFsIGFkbWluaXN0cmF0aW9u IG1heSBzZW5kIHRoZSBkZXNpcmVkIGNvbmZpZ3VyYXRpb24gdG8gdGhlIHdpcmVkL3dpcmVsZXNz IGJyaWRnZSAodGhlIHdpcmVsZXNzIHBhcnQgaW4gdGhpcyBicmlkZ2UgaXMgdGhlIEFQIGZ1bmN0 aW9uKSB3aGVyZSBpdCBnZXRzDQogY29udmVydGVkIGludG8gcGFyYW1ldGVycyB0aGF0IGFyZSA4 MDIuMTEtc3BlY2lmaWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+eC42LjIgU3RhbmRhcmRpemVkIERhdGEgRmxvdyBJbmZvcm1h dGlvbiBNb2RlbHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5Dby1vcmRpbmF0aW9uIGJldHdlZW4gSUVURiBEZXROZXQgYW5kIElFRUU4MDIu MTEgV29ya2luZyBHcm91cHMgd2lsbCBiZSByZXF1aXJlZCB0byBlbnN1cmUgdGhhdCB0aGlzIHJl cXVpcmVtZW50IGlzIG1ldA0KIHdoZW4gRGV0TmV0IG9wZXJhdGVzIG92ZXIgSUVFRTgwMi4xMSBs aW5rcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgyNjc2NDQ2NTU3 MTU3NDk4NzVtc29jb21tZW50dGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij54LjYuMyBTeW1tZXRyaWNhbCBQYXRoIERlbGF5czwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgbWF5IGJl IGEgY2hhbGxlbmdlIGluIDgwMi4xMSAocHJvYmFibHkgaW4gYWxsIHdpcmVsZXNzIG5ldHdvcmtz LCBzcGVjaWZpY2FsbHkgaW5kb29ycykuIE5lZWQgdG8gcmVzZWFyY2ggdGhpcyBmdXJ0aGVyLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTgyNjc2NDQ2NTU3MTU3NDk4NzVtc29jb21tZW50dGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWZlcmVu Y2VzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SUVFRTgwMi4xMS0yMDE2OiBX aXJlbGVzcyBMQU4gTWVkaXVtIEFjY2VzcyBDb250cm9sIChNQUMpIGFuZCBQaHlzaWNhbCBMYXll ciAoUEhZKSBTcGVjaWZpY2F0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklFRUU4MDIuMTFhay0yMDE3OiBFbmhhbmNl bWVudHMgZm9yIFRyYW5zaXQgTGlua3MgV2l0aGluIEJyaWRnZWQgTmV0d29ya3M8L3NwYW4+PG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5J RUVFODAyLjExYXggRDMuMDogRW5oYW5jZW1lbnRzIGZvciBIaWdoIEVmZmljaWVuY3kgV0xBTjwv c3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPldORyBkb2N1bWVudHMgb24gUlRBICgxOC0xMTYwcjApOiA8L3NwYW4+DQo8YSBocmVm PSJodHRwczovL21lbnRvci5pZWVlLm9yZy84MDIuMTEvZGNuLzE4LzExLTE4LTExNjAtMDAtMHdu Zy1jb250cm9sbGluZy1sYXRlbmN5LWluLTgwMi0xMS5wcHR4IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5odHRwczovL21l bnRvci5pZWVlLm9yZy84MDIuMTEvZGNuLzE4LzExLTE4LTExNjAtMDAtMHduZy1jb250cm9sbGlu Zy1sYXRlbmN5LWluLTgwMi0xMS5wcHR4PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2ktRmkgQWxsaWFuY2UgV2ly ZWxlc3MgUHJvdGVjdGVkIEFjY2VzcyAyIChXUEEyKTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldpLUZpIEFsbGlhbmNlIFdp cmVsZXNzIE11bHRpLU1lZGlhIEFkbWlzc2lvbiBDb250cm9sIChXTU0tQUMpPC9zcGFuPjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V2kt RmkgQWxsaWFuY2UgV2lyZWxlc3MgUHJvdGVjdGVkIEFjY2VzcyAzIChXUEEzKTwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldp LUZpIEFsbGlhbmNlIFRpbWVTeW5jPHN1cD5UTTwvc3VwPjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs dWUiPkNoZWVycyAtLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymx1ZSI+Z2FuZXNoPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRldG5ldCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGV0bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_311BE885E0DA8D4BB369A037CF5B64A79B590253ORSMSX107amrcor_-- From nobody Mon Oct 22 13:18:01 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC87E12D4EA for ; Mon, 22 Oct 2018 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5LBEM8NIyD9 for ; Mon, 22 Oct 2018 13:17:55 -0700 (PDT) Received: from dggwg11-dlp.huawei.com (lhrrg12-dlp.huawei.com [185.176.76.242]) (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 00CEA12D7EA for ; Mon, 22 Oct 2018 13:17:55 -0700 (PDT) Received: from lhrpml402-hub.exmail.huawei.com (unknown [172.18.7.65]) by Forcepoint Email with ESMTP id B5FF74EDD27F4; Mon, 22 Oct 2018 21:17:47 +0100 (IST) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.210]) by lhrpml402-hub.exmail.huawei.com ([10.201.4.206]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 21:17:45 +0100 From: Norman Finn To: "Venkatesan, Ganesh" , "Andrew G. Malis" CC: detnet WG Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwATr6YAAAsiJoAAAl+1Uw== Date: Mon, 22 Oct 2018 20:17:45 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> In-Reply-To: <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.7.94] Content-Type: multipart/alternative; boundary="_000_3DF0466E9510274382F5B74499ACD6F8016F2B9Alhrpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:17:59 -0000 --_000_3DF0466E9510274382F5B74499ACD6F8016F2B9Alhrpml504mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= =91IEEE TSN as a layer2 for DetNet=92. Given that the TSN work is done in = IEEE802.1 TSN, do you perceive IEEE802.11 as =91IEEE TSN as a layer2 for De= tNet=92? And would that be the perception of the rest of the IETF DetNet me= mbership? If your answer is Yes to both the questions, then I would agree (= and if we delete the reference in section 5.1.1 where the current draft cal= ls out IEEE802.11 (WiFi) as unsuited for DetNet) that =93we don=92t need t= o include explicit references to 802.11=94, but carefully call out in other= pertinent IETF DetNet RFCs where IEEE802.11 mechanisms required to meet De= tNet requirements explicitly. Cheers -- ganesh From: Andrew G. Malis Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path.. Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers (=93making A= VB/TSN-type deterministic performance available from layer-3 applications= =94 or =93connecting two AVB/TSN LANs or =91islands=92 together through a s= tandard router=94) should extend to IEEE802.11 as L2. AVB/TSN protocol supp= ort over IEEE802.11 is already supported for time synchronization, stream i= dentification and reservation and additional TSN capabilities are under dev= elopment (support for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 =96 10 millisecond latencies ove= r the wireless hop) is achievable in a managed 802.11 network by leveraging= current TSN capabilities over 802.11, such as time synchronization, stream= identification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration =96 there are aspects of the wireless ne= twork (or the wireless hop from a wired/wireless bridge to a wireless endpo= int) that will have to be defined. For instance, the controller that does t= he central administration may send the desired configuration to the wired/w= ireless bridge (the wireless part in this bridge is the AP function) where = it gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_3DF0466E9510274382F5B74499ACD6F8016F2B9Alhrpml504mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    There is a strong desire from a number of application domains for dete= rministic wireless networks.  This desire has generated projects such = as the 6TiSCH working group in the WPAN world.  There are things that = one can do to greatly improve the reliability and timeliness of 802.11 networks.  I was the primary instigator of 8= 02.11ak, that make it possible to have an 802.11 link in the middle of a wi= red network; the wired robot attached to a wired network on a factory floor= via Wi-Fi was one of the examples I used to promote the idea.

    Having said that ...

    In the wired world, simply eliminating congestion loss gets us to 7 or= 8 nines in reliability.  Dual pathing gets us to 10 or more nines.&nb= sp; And, these are things that we know how to accomplish, today.

    In the wireless world, signal interference can easily drop you to 3 ni= nes.  Deterministic wireless needs different techniques for achieving = reliability -- for example, spreading the data out in time to avoid interfe= rence, and hop-by-hop ACK/retransmission.  These are not required in the wired world.  This leads me to talk abo= ut the (latency)*(loss rate) product.  That is, in wireless, it is mea= ningful to have a direct tradeoff between latency and loss rate, to give ro= om for retransmissions and time spreading.  That product is orders of magnitude different between the wired and wirele= ss cases, and that means that the applications that can use the service hav= e orders of magnitude different requirements.

    I would fully support the creation of a Deterministic Wireless WG.&nbs= p; I believe that such a group and DetNet would complement each others' eff= orts.  The goals are similar, but the solutions are sufficiently diffe= rent that I would not want wireless support to be a goal of DetNet.

    -- Norm

    From: detnet [detnet-bounces@ietf.org] on= behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     

    Reading the current draft, specifically section 5.1.= 1, I get the impression that the current Use Case document does not conside= r IEEE802.11 as part of =91IEEE TSN as a layer2 for DetNet=92. Given that t= he TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as =91IEEE TSN as a layer2 for DetNet=92? And w= ould that be the perception of the rest of the IETF DetNet membership? If y= our answer is Yes to both the questions, then I would agree (and if we dele= te the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as unsuited for DetNet) &nbs= p;that =93we don=92t need to include explicit references to 802.11=94, but = carefully call out in other pertinent IETF DetNet RFCs where IEEE802.11 mec= hanisms required to meet DetNet requirements explicitly.

     

    Cheers = --

    ganesh<= /span>

     

    From: Andrew G. Malis <agmalis@gmail.com&g= t;
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    Ganesh,

     

    For those of us that don't attend IEEE, can you fill= us in on the relationship between 801.11 and TSN? As the DetNet documents = already refer (in many places) to IEEE TSN as a layer 2 media for DetNet, i= f 801.11 is already included in the TSN umbrella, then it would seem to me that we don't need to include expli= cit references to 802.11. Just a thought.

     

    Thanks,

    Andy

     

     

    On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh = <ganesh.venkatesan@intel.com> wrote:

    Hello DetNet members:

     

    We proposed adding IEEE802.11 as a L2 med= ia for DetNet. Based on our experience with IEEE802.11 in managed deploymen= ts, we believe that 802.11 links can meet DetNet requirements described in = the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and in other Topic Int= erest Groups within IEEE802.11 Working Group that renders 802.11 as a versa= tile L2 media for DetNet.

     

    Please let me know if you have comments/q= uestions on this submission:

     

    Proposed addition of IEEE802.1= 1 as a L2 Media to the draft-ietf-detnet-use-cases-19 document:<= /p>

     

    Rationale: 802.11 in a managed= network environment meets the Use Case requirements described in this docu= ment. The proposal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-= to-end path..

     

    Editor: the proposed text b= elow can either be a standalone section or added to the relevant subsection= s to section 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     

    x. Use Case Common Themes with L2= Medium Access Control as IEEE802.11

     

    Thus far IEEE 802.11 has been the only wireless me= dia technology that has already included support for some of the 802.1 TSN = capabilities required to address the use cases described in this document. The IEEE 802.11 working group has been working= in collaboration with the IEEE 802.1 group for several years extending 802= .1 features over 802.11. Therefore, in the Use Cases described in this docu= ment, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under consideration is a = wired/wireless network with the first and/or the last nodes being IEEE802.1= 1 hops and the rest of the network is wired. As with any wireless media, 80= 2.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between latency and reliabili= ty guarantees must be considered as well as managed deployment requirements= .

    The 802.1 and 802.11 feature set that is alrea= dy part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificatio= ns to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNe= t described in this document.

     

    The following sub-sections are analogues of co= rresponding subsections in section-11. The intent is to demonstrate how wel= l IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     

    x.1.1 Extension to Ethernet and 8= 02.1 TSN

     

    In addition to IEEE 802.3, 802.11= is also a target media for 802.1 TSN capabilities that are being now exten= ded to routed networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while m= aintaining domain-specific semantics. Several 802.1 AVB/TSN specifications = have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS de= scribes the 802.11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservat= ion Protocol triggers generation of equivalent IEEE802.11 Add TS management= frames). Equivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.1= 1 Topic Interest Group (IEEE802.11 TIG for Real Time Applications).

     

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate = L2 and L3 layers (=93making AVB/TSN-type deterministic performance availabl= e from layer-3 applications=94 or =93connecting two AVB/TSN LANs or =91islands=92 together through a standard router=94) should extend= to IEEE802.11 as L2. AVB/TSN protocol support over IEEE802.11 is already s= upported for time synchronization, stream identification and reservation an= d additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet = performance over IPv4 over an IEEE802.11 L2 link is achievable when the net= work is managed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireles= s resources; frequency planning to minimize/eliminate interference/congesti= on; stream identification for prioritization; admission control to prevent = over-subscription; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensit= ive traffic.

     

    x.1.6 Guaranteed End-to-End Deliv= ery

    Guaranteed e2e delivery is achieved in DetNet by c= onstraining the network (the network is not the open Internet but a constra= ined/managed network).

    With 802.11, similar constraints can be put in= place in a managed deployment. For instance, multiple channels and Basic S= ervice Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     

    x.1.7 Replacement for Multiple Pr= oprietary Deterministic Networks

    IEEE802.11 has demonstrated inter= operable ubiquitous deployment and it already has the basic capabilities to= interoperate with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide De= tNet performance.

     

    x.1.8 Mix of Deterministic and Be= st-Effort Traffic

    IEEE802.11 has QoS support to identify and priorit= ize time-sensitive operational traffic. The prioritization (and the resulti= ng improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even more effe= ctive with high efficiency features from IEEE802.11ax, IEEE802.1Qbv over IE= EE802.11, etc.

    x.1.9 Unused Reserved BW to be av= ailable to Best Effort Traffic

    The IEEE 802.11ax amendment enabl= es the APs to have more control of the medium and not only prioritize time-= sensitive traffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve effic= iency while reducing contention and latency, which are key aspects to suppo= rt the TSN and DetNet use cases defined in this document.

     

    x.1.10 Lower Cost, Multi Vendor S= olutions

    IEEE802.11 implementations suppor= ting IEEE802.11 features have been consistently available from multiple ven= dors at low cost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendmen= t in the IEEE 802.11 WG, development of a corresponding interoperability ce= rtification from Wi-Fi Alliance and broad market availability of the enhanc= ements.

     

    In a managed network, we expect t= he off-the-shelf implementations of IEEE802.11 protocol to be part of the D= etNet and satisfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being= planned for development soon, we envision the roll out described above and= the availability of lower cost, interoperable multi-vendor implementations= with the enhancements to become available.

     

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admissio= n Control prevents over-subscribing and minimizes collisions, and where QoS= provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     

    x.3.2 Low Latency

    Low latency requirement depends on the Use Case in= question. There is some trade-off in the low latency requirement for the c= onvenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed for the specifi= c situation within the Use Case.

    However, low latencies [Reference 18-1160r0] to me= et the requirements of a variety of Use Cases (pro AV, synchronized multi-c= hannel audio, mobile robotics, repetitive cyclic control systems (1 =96 10 millisecond latencies over the wireless hop) is = achievable in a managed 802.11 network by leveraging current TSN capabiliti= es over 802.11, such as time synchronization, stream identification and tim= e-aware shaping..

    x.5 Security

    WFA WPA3 provides robust security both for man= agement and data packets. In addition, WFA Easy Connect provides for robust= security while supporting easy onboarding of headless devices into the network.

     

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration =96 there a= re aspects of the wireless network (or the wireless hop from a wired/wirele= ss bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administrat= ion may send the desired configuration to the wired/wireless bridge (the wi= reless part in this bridge is the AP function) where it gets converted into= parameters that are 802.11-specific.

     

    x.6.2 Standardized Data Flow Information Model= s

    Co-ordination between IETF DetNet and IEEE802.= 11 Working Groups will be required to ensure that this requirement is met w= hen DetNet operates over IEEE802.11 links.

     

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in= all wireless networks, specifically indoors). Need to research this furthe= r.

     

    References:

    1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and P= hysical Layer (PHY) Specifications
    2. IEEE802.11ak-2017= : Enhancements for Transit Links Within Bridged Networks
    3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN
      4. WNG documents on RTA (18-1160r0): https://mentor.i= eee.org/802.11/dcn/18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx=
    4. Wi-Fi Alliance Wireless Protected Access 2 (WPA2)
    5. Wi-Fi Alliance Wireless Multi-Media Admission Control= (WMM-AC)
    6. Wi-Fi Alliance Wireless Protected Access 3= (WPA3)
    7. Wi-Fi Alliance TimeSyncTM<= /li>

     

    Cheers --

    ganesh

     

    _______________________________________________
    detnet mailing list
    detnet@ietf.org
    https://www.ietf.org/mailman/listinfo/detnet

    --_000_3DF0466E9510274382F5B74499ACD6F8016F2B9Alhrpml504mbxexm_-- From nobody Mon Oct 22 13:37:59 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4810012F1A5 for ; Mon, 22 Oct 2018 13:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZCvL-_bt7XZ for ; Mon, 22 Oct 2018 13:37:46 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 0B32C130EA4 for ; Mon, 22 Oct 2018 13:37:46 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 13:37:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,413,1534834800"; d="scan'208,217";a="101697285" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga001.jf.intel.com with ESMTP; 22 Oct 2018 13:37:45 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX104.amr.corp.intel.com ([169.254.4.129]) with mapi id 14.03.0319.002; Mon, 22 Oct 2018 13:37:44 -0700 From: "Venkatesan, Ganesh" To: Norman Finn , "Andrew G. Malis" CC: detnet WG Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAkcy8AAAPJfDAACOF1gAAOgLxA Date: Mon, 22 Oct 2018 20:37:44 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzJmZjg2NGMtODEzZC00Mzk4LWJmMGYtOWQ5MGJhOTZmNGU2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicUdiV2RSbTZUeGZqTTdUdnpnYUFPK2ZQUVAxbktpbDZVQWtGa3VFbXMwc1QwN0pCbG9NODZoZHY3dG1nOGZyMCJ9 dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B5903EAORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:37:56 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B5903EAORSMSX107amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Norm: Not all Use Cases in draft-ietf-detnet-use-cases-19 require a reliability o= f 7 or 8 nines in reliability. For instance, section 3 Electrical Utilities= has a requirement of 0.1-1% packet loss (3.1.1.1.4). Do you think a manage= d IEEE802.11 network would not meet that requirement? I would agree with your assessment (cannot achieve reliability to 7 or 8 ni= nes) if we are exclusively focusing on IEEE802.11 only networks. The propos= al is to consider a 802.1 core DetNet with IEEE802.11 links at the last (or= first) hop, for Use Cases where a managed IEEE802.11 network (where the wi= reless configuration takes into account the need for low latency and high r= eliability for TSN traffic). Cheers -- ganesh From: Norman Finn Sent: Monday, October 22, 2018 4:18 PM To: Venkatesan, Ganesh ; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= 'IEEE TSN as a layer2 for DetNet'. Given that the TSN work is done in IEEE= 802.1 TSN, do you perceive IEEE802.11 as 'IEEE TSN as a layer2 for DetNet'?= And would that be the perception of the rest of the IETF DetNet membership= ? If your answer is Yes to both the questions, then I would agree (and if w= e delete the reference in section 5.1.1 where the current draft calls out I= EEE802.11 (WiFi) as unsuited for DetNet) that "we don't need to include ex= plicit references to 802.11", but carefully call out in other pertinent IET= F DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requireme= nts explicitly. Cheers -- ganesh From: Andrew G. Malis > Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path.. Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers ("making AVB= /TSN-type deterministic performance available from layer-3 applications" or= "connecting two AVB/TSN LANs or 'islands' together through a standard rout= er") should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE8= 02.11 is already supported for time synchronization, stream identification = and reservation and additional TSN capabilities are under development (supp= ort for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 - 10 millisecond latencies over = the wireless hop) is achievable in a managed 802.11 network by leveraging c= urrent TSN capabilities over 802.11, such as time synchronization, stream i= dentification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration - there are aspects of the wireless netw= ork (or the wireless hop from a wired/wireless bridge to a wireless endpoin= t) that will have to be defined. For instance, the controller that does the= central administration may send the desired configuration to the wired/wir= eless bridge (the wireless part in this bridge is the AP function) where it= gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_311BE885E0DA8D4BB369A037CF5B64A79B5903EAORSMSX107amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Norm:

     

    Not all Use Cases in draft-ietf-detnet-use-cases-19 = require a reliability of 7 or 8 nines in reliability. For instance, section= 3 Electrical Utilities has a requirement of 0.1-1% packet loss (3.1.1.1.4)= . Do you think a managed IEEE802.11 network would not meet that requirement?

     

    I would agree with your assessment (cannot achieve r= eliability to 7 or 8 nines) if we are exclusively focusing on IEEE802.11 on= ly networks. The proposal is to consider a 802.1 core DetNet with IEEE802.1= 1 links at the last (or first) hop, for Use Cases where a managed IEEE802.11 network (where the wireless confi= guration takes into account the need for low latency and high reliability f= or TSN traffic).

     

    Cheers -= -

    ganesh

     

    From: Nor= man Finn <norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 4:18 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G= . Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    There is a strong desire from a number o= f application domains for deterministic wireless networks.  This desir= e has generated projects such as the 6TiSCH working group in the WPAN world.  There are things that one can do to greatly= improve the reliability and timeliness of 802.11 networks.  I was the= primary instigator of 802.11ak, that make it possible to have an 802.11 li= nk in the middle of a wired network; the wired robot attached to a wired network on a factory floor via Wi-Fi was one of = the examples I used to promote the idea.

     

    Having said that ...

     

    In the wired world, simply eliminating c= ongestion loss gets us to 7 or 8 nines in reliability.  Dual pathing g= ets us to 10 or more nines.  And, these are things that we know how to accomplish, today.

     

    In the wireless world, signal interferen= ce can easily drop you to 3 nines.  Deterministic wireless needs diffe= rent techniques for achieving reliability -- for example, spreading the data out in time to avoid interference, and hop-by-hop ACK/r= etransmission.  These are not required in the wired world.  This = leads me to talk about the (latency)*(loss rate) product.  That is, in= wireless, it is meaningful to have a direct tradeoff between latency and loss rate, to give room for retransmissions and time s= preading.  That product is orders of magnitude different between the w= ired and wireless cases, and that means that the applications that can use = the service have orders of magnitude different requirements.

     

    I would fully support the creation of a = Deterministic Wireless WG.  I believe that such a group and DetNet wou= ld complement each others' efforts.  The goals are similar, but the solutions are sufficiently different that I would not wan= t wireless support to be a goal of DetNet.

     

    -- Norm

     

    From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     =

    Reading the current draf= t, specifically section 5.1.1, I get the impression that the current Use Ca= se document does not consider IEEE802.11 as part of ‘IEEE TSN as a la= yer2 for DetNet’. Given that the TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as ‘IEEE TSN as= a layer2 for DetNet’? And would that be the perception of the rest o= f the IETF DetNet membership? If your answer is Yes to both the questions, = then I would agree (and if we delete the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as un= suited for DetNet)  that “we don’t need to include explici= t references to 802.11”, but carefully call out in other pertinent IE= TF DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requirements explicitly.

     =

    Cheers -= -

    ganesh

     =

    From: Andrew G. Malis <agmalis@gmail.com>
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
    Cc: detnet WG <detnet@ietf.org= >
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    Ganesh,

     =

    For those of us that don= 't attend IEEE, can you fill us in on the relationship between 801.11 and T= SN? As the DetNet documents already refer (in many places) to IEEE TSN as a= layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we = don't need to include explicit references to 802.11. Just a thought.

     =

    Thanks,

    Andy

     =

     =

    On Sun, Oct 21, 2018 at = 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.com> wrote:=

    Hello DetNet members:

     =

    We proposed adding IEEE8= 02.11 as a L2 media for DetNet. Based on our experience with IEEE802.11 in = managed deployments, we believe that 802.11 links can meet DetNet requireme= nts described in the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and = in other Topic Interest Groups within IEEE802.11 Working Group that renders= 802.11 as a versatile L2 media for DetNet.

     =

    Please let me know if yo= u have comments/questions on this submission:

     =

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ..

     

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     =

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

     =

    Thus far IEEE 802.11 has been the only= wireless media technology that has already included support for some of th= e 802.1 TSN capabilities required to address the use cases described in this document. The IEEE 802.11 working group has be= en working in collaboration with the IEEE 802.1 group for several years ext= ending 802.1 features over 802.11. Therefore, in the Use Cases described in= this document, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under cons= ideration is a wired/wireless network with the first and/or the last nodes = being IEEE802.11 hops and the rest of the network is wired. As with any wir= eless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between laten= cy and reliability guarantees must be considered as well as managed deploym= ent requirements.

    The 802.1 and 802.11 feature set that is alrea= dy part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificatio= ns to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNe= t described in this document.=

     =

    The following sub-sections are analogues of co= rresponding subsections in section-11. The intent is to demonstrate how wel= l IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     =

    x.1.1 Extension to Ethernet and 802.1 TSN

     =

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     =

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate = L2 and L3 layers (“making AVB/TSN-type deterministic performance avai= lable from layer-3 applications” or “connecting two AVB/TSN LANs or ‘islands’ together through a standard router&#= 8221;) should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEE= E802.11 is already supported for time synchronization, stream identificatio= n and reservation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     =

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

     =

    x.1.6 Guaranteed End-to-End Delivery

    Guaranteed e2e delivery is achieved in= DetNet by constraining the network (the network is not the open Internet b= ut a constrained/managed network).<= /o:p>

    With 802.11, similar constraints can be put in= place in a managed deployment. For instance, multiple channels and Basic S= ervice Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     =

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     =

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify= and prioritize time-sensitive operational traffic. The prioritization (and= the resulting improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even= more effective with high efficiency features from IEEE802.11ax, IEEE802.1Q= bv over IEEE802.11, etc.

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     =

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     =

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     =

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admissio= n Control prevents over-subscribing and minimizes collisions, and where QoS= provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     =

    x.3.2 Low Latency

    Low latency requirement depends on the= Use Case in question. There is some trade-off in the low latency requireme= nt for the convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed f= or the specific situation within the Use Case.

    However, low latencies [Reference 18-1= 160r0] to meet the requirements of a variety of Use Cases (pro AV, synchron= ized multi-channel audio, mobile robotics, repetitive cyclic control systems (1 – 10 millisecond latencies over the wirele= ss hop) is achievable in a managed 802.11 network by leveraging current TSN= capabilities over 802.11, such as time synchronization, stream identificat= ion and time-aware shaping..<= /span>

    x.5 Security

    WFA WPA3 provides robust security both for man= agement and data packets. In addition, WFA Easy Connect provides for robust= security while supporting easy onboarding of headless devices into the network.=

     =

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration – the= re are aspects of the wireless network (or the wireless hop from a wired/wi= reless bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administ= ration may send the desired configuration to the wired/wireless bridge (the= wireless part in this bridge is the AP function) where it gets converted i= nto parameters that are 802.11-specific.=

     =

    x.6.2 Standardized Data Flow Information Model= s

    Co-ordination between IETF DetNet and IEEE802.= 11 Working Groups will be required to ensure that this requirement is met w= hen DetNet operates over IEEE802.11 links.

     =

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in= all wireless networks, specifically indoors). Need to research this furthe= r.

     =

    References:

    1. IEEE802.11-2016: Wireless LA= N Medium Access Control (MAC) and Physical Layer (PHY) Specifications
    2. IEEE802.11a= k-2017: Enhancements for Transit Links Within Bridged Networks<= /o:p>
    3. IEEE802.11ax D3.0:= Enhancements for High Efficiency WLAN
    4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-= 1160-00-0wng-controlling-latency-in-802-11.pptx
    5. Wi-Fi= Alliance Wireless Protected Access 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-Medi= a Admission Control (WMM-AC)
    7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
    8. Wi-Fi Al= liance TimeSyncTM

     =

    Cheers -= -

    ganesh

     =

    ________________________= _______________________
    detnet mailing list
    detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet

    --_000_311BE885E0DA8D4BB369A037CF5B64A79B5903EAORSMSX107amrcor_-- From nobody Mon Oct 22 14:12:31 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD30130EA1 for ; Mon, 22 Oct 2018 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ph6s3hwmdoG for ; Mon, 22 Oct 2018 14:12:18 -0700 (PDT) Received: from dggwg11-dlp.huawei.com (lhrrg12-dlp.huawei.com [185.176.76.242]) (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 E718C130F0D for ; Mon, 22 Oct 2018 14:12:17 -0700 (PDT) Received: from lhrpml402-hub.exmail.huawei.com (unknown [172.18.7.65]) by Forcepoint Email with ESMTP id D4CA3E6888E42; Mon, 22 Oct 2018 22:12:10 +0100 (IST) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.210]) by lhrpml402-hub.exmail.huawei.com ([10.201.4.206]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 22:12:07 +0100 From: Norman Finn To: "Venkatesan, Ganesh" , "Andrew G. Malis" CC: detnet WG Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwATr6YAAAsiJoAAAl+1U////t4AgAAWplg= Date: Mon, 22 Oct 2018 21:12:06 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com>, <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> In-Reply-To: <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.7.94] Content-Type: multipart/alternative; boundary="_000_3DF0466E9510274382F5B74499ACD6F8016F2C00lhrpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:12:30 -0000 --_000_3DF0466E9510274382F5B74499ACD6F8016F2C00lhrpml504mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think I was misunderstanding your wishes, Ganesh. Sorry. I thought you = wanted to add 802.11 to the core of DetNet and/or to the architecture. Now= I see that you are talking about a use case. I'd have to look more at the= details to have an opinion. Given the variability of 802.11 delivery, can you comment about how the dif= ference between DetNet service and typical weighted priorities would be cri= tical to the success of your envisioned applications? I have heard argumen= ts about needing DetNet/TSN to enable timed deliveries. -- Norm ________________________________ From: Venkatesan, Ganesh [ganesh.venkatesan@intel.com] Sent: Monday, October 22, 2018 1:37 PM To: Norman Finn; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Norm: Not all Use Cases in draft-ietf-detnet-use-cases-19 require a reliability o= f 7 or 8 nines in reliability. For instance, section 3 Electrical Utilities= has a requirement of 0.1-1% packet loss (3.1.1.1.4). Do you think a manage= d IEEE802.11 network would not meet that requirement? I would agree with your assessment (cannot achieve reliability to 7 or 8 ni= nes) if we are exclusively focusing on IEEE802.11 only networks. The propos= al is to consider a 802.1 core DetNet with IEEE802.11 links at the last (or= first) hop, for Use Cases where a managed IEEE802.11 network (where the wi= reless configuration takes into account the need for low latency and high r= eliability for TSN traffic). Cheers -- ganesh From: Norman Finn Sent: Monday, October 22, 2018 4:18 PM To: Venkatesan, Ganesh ; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= =91IEEE TSN as a layer2 for DetNet=92. Given that the TSN work is done in = IEEE802.1 TSN, do you perceive IEEE802.11 as =91IEEE TSN as a layer2 for De= tNet=92? And would that be the perception of the rest of the IETF DetNet me= mbership? If your answer is Yes to both the questions, then I would agree (= and if we delete the reference in section 5.1.1 where the current draft cal= ls out IEEE802.11 (WiFi) as unsuited for DetNet) that =93we don=92t need t= o include explicit references to 802.11=94, but carefully call out in other= pertinent IETF DetNet RFCs where IEEE802.11 mechanisms required to meet De= tNet requirements explicitly. Cheers -- ganesh From: Andrew G. Malis > Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path.. Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers (=93making A= VB/TSN-type deterministic performance available from layer-3 applications= =94 or =93connecting two AVB/TSN LANs or =91islands=92 together through a s= tandard router=94) should extend to IEEE802.11 as L2. AVB/TSN protocol supp= ort over IEEE802.11 is already supported for time synchronization, stream i= dentification and reservation and additional TSN capabilities are under dev= elopment (support for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 =96 10 millisecond latencies ove= r the wireless hop) is achievable in a managed 802.11 network by leveraging= current TSN capabilities over 802.11, such as time synchronization, stream= identification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration =96 there are aspects of the wireless ne= twork (or the wireless hop from a wired/wireless bridge to a wireless endpo= int) that will have to be defined. For instance, the controller that does t= he central administration may send the desired configuration to the wired/w= ireless bridge (the wireless part in this bridge is the AP function) where = it gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_3DF0466E9510274382F5B74499ACD6F8016F2C00lhrpml504mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    I think I was misunderstanding your wishes, Ganesh.  Sorry. = I thought you wanted to add 802.11 to the core of DetNet and/or to the arc= hitecture.  Now I see that you are talking about a use case.  I'd= have to look more at the details to have an opinion.

    Given the variability of 802.11 delivery, can you comment about how th= e difference between DetNet service and typical weighted priorities would b= e critical to the success of your envisioned applications?  I have hea= rd arguments about needing DetNet/TSN to enable timed deliveries.

    -- Norm

    From: Venkatesan, Ganesh [ganesh.venkatesa= n@intel.com]
    Sent: Monday, October 22, 2018 1:37 PM
    To: Norman Finn; Andrew G. Malis
    Cc: detnet WG
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Norm:

     

    Not all Use Cases in draft-ietf-detnet-use-cases-19 = require a reliability of 7 or 8 nines in reliability. For instance, section= 3 Electrical Utilities has a requirement of 0.1-1% packet loss (3.1.1.1.4)= . Do you think a managed IEEE802.11 network would not meet that requirement?

     

    I would agree with your assessment (cannot achieve r= eliability to 7 or 8 nines) if we are exclusively focusing on IEEE802.11 on= ly networks. The proposal is to consider a 802.1 core DetNet with IEEE802.1= 1 links at the last (or first) hop, for Use Cases where a managed IEEE802.11 network (where the wireless confi= guration takes into account the need for low latency and high reliability f= or TSN traffic).

     

    Cheers = --

    ganesh<= /span>

     

    From: Nor= man Finn <norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 4:18 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G= . Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    There is a strong desire from a number= of application domains for deterministic wireless networks.  This des= ire has generated projects such as the 6TiSCH working group in the WPAN world.  There are things that one can do to greatly= improve the reliability and timeliness of 802.11 networks.  I was the= primary instigator of 802.11ak, that make it possible to have an 802.11 li= nk in the middle of a wired network; the wired robot attached to a wired network on a factory floor via Wi-Fi was one of = the examples I used to promote the idea.

     

    Having said that ...

     

    In the wired world, simply eliminating= congestion loss gets us to 7 or 8 nines in reliability.  Dual pathing= gets us to 10 or more nines.  And, these are things that we know how to accomplish, today.

     

    In the wireless world, signal interfer= ence can easily drop you to 3 nines.  Deterministic wireless needs dif= ferent techniques for achieving reliability -- for example, spreading the data out in time to avoid interference, and hop-by-= hop ACK/retransmission.  These are not required in the wired world.&nb= sp; This leads me to talk about the (latency)*(loss rate) product.  Th= at is, in wireless, it is meaningful to have a direct tradeoff between latency and loss rate, to give room for retransmis= sions and time spreading.  That product is orders of magnitude differe= nt between the wired and wireless cases, and that means that the applicatio= ns that can use the service have orders of magnitude different requirements.

     

    I would fully support the creation of = a Deterministic Wireless WG.  I believe that such a group and DetNet w= ould complement each others' efforts.  The goals are similar, but the solutions are sufficiently different that I would not wan= t wireless support to be a goal of DetNet.

     

    -- Norm

     

    From= : detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     

    Reading the current draf= t, specifically section 5.1.1, I get the impression that the current Use Ca= se document does not consider IEEE802.11 as part of =91IEEE TSN as a layer2= for DetNet=92. Given that the TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as =91IEEE TSN as a l= ayer2 for DetNet=92? And would that be the perception of the rest of the IE= TF DetNet membership? If your answer is Yes to both the questions, then I w= ould agree (and if we delete the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as un= suited for DetNet)  that =93we don=92t need to include explicit refere= nces to 802.11=94, but carefully call out in other pertinent IETF DetNet RF= Cs where IEEE802.11 mechanisms required to meet DetNet requirements explicitly.

     

    Cheers = --

    ganesh<= /span>

     

    From: Andrew G. Malis <agmalis@gmail.com&g= t;
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel= .com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    Ganesh,

     

    For those of us that don= 't attend IEEE, can you fill us in on the relationship between 801.11 and T= SN? As the DetNet documents already refer (in many places) to IEEE TSN as a= layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we = don't need to include explicit references to 802.11. Just a thought.=

     

    Thanks,

    Andy

     

     

    On Sun, Oct 21, 2018 at = 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.c= om> wrote:

    Hello DetNet members:

     

    We proposed adding IEEE8= 02.11 as a L2 media for DetNet. Based on our experience with IEEE802.11 in = managed deployments, we believe that 802.11 links can meet DetNet requireme= nts described in the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and = in other Topic Interest Groups within IEEE802.11 Working Group that renders= 802.11 as a versatile L2 media for DetNet.

     

    Please let me know if yo= u have comments/questions on this submission:

     

    Proposed addition of IEEE802.11 as a L2 M= edia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network en= vironment meets the Use Case requirements described in this document. The p= roposal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ..

     

    Editor: the proposed text below can ei= ther be a standalone section or added to the relevant subsections to sectio= n 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     

    x. Use Case Common Themes with L2 Medium Acc= ess Control as IEEE802.11

     

    Thus far IEEE 802.11 has been the onl= y wireless media technology that has already included support for some of t= he 802.1 TSN capabilities required to address the use cases described in this document. The IEEE 802.11 working group ha= s been working in collaboration with the IEEE 802.1 group for several years= extending 802.1 features over 802.11. Therefore, in the Use Cases describe= d in this document, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under = consideration is a wired/wireless network with the first and/or the last no= des being IEEE802.11 hops and the rest of the network is wired. As with any= wireless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between l= atency and reliability guarantees must be considered as well as managed dep= loyment requirements.

    The 802.1 and 802.11 feature set that is alr= eady part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificat= ions to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the = DetNet described in this document.

     

    The following sub-sections are analogues of = corresponding subsections in section-11. The intent is to demonstrate how w= ell IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     

    x.1.1 Extension to Ethernet and 802.1 TSN

     

    In addition to IEEE 802.3, 802.11 is also a = target media for 802.1 TSN capabilities that are being now extended to rout= ed networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrat= e L2 and L3 layers (=93making AVB/TSN-type deterministic performance availa= ble from layer-3 applications=94 or =93connecting two AVB/TSN LANs or =91islands=92 together through a standard router=94) shoul= d extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE802.11 is a= lready supported for time synchronization, stream identification and reserv= ation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance= over IPv4 over an IEEE802.11 L2 link is achievable when the network is man= aged. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless reso= urces; frequency planning to minimize/eliminate interference/congestion; st= ream identification for prioritization; admission control to prevent over-s= ubscription; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensit= ive traffic.

     

    x.1.6 Guaranteed End-to-End Delivery<= span style=3D"color:black">

    Guaranteed e2e delivery is achieved i= n DetNet by constraining the network (the network is not the open Internet = but a constrained/managed network).

    With 802.11, similar constraints can be put = in place in a managed deployment. For instance, multiple channels and Basic= Service Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     

    x.1.7 Replacement for Multiple Proprietary D= eterministic Networks

    IEEE802.11 has demonstrated interoperable ub= iquitous deployment and it already has the basic capabilities to interopera= te with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     

    x.1.8 Mix of Deterministic and Best-Effort T= raffic

    IEEE802.11 has QoS support to identif= y and prioritize time-sensitive operational traffic. The prioritization (an= d the resulting improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to= be even more effective with high efficiency features from IEEE802.11ax, IE= EE802.1Qbv over IEEE802.11, etc.<= /p>

    x.1.9 Unused Reserved BW to be available to = Best Effort Traffic

    The IEEE 802.11ax amendment enables the APs = to have more control of the medium and not only prioritize time-sensitive t= raffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE80= 2.11 features have been consistently available from multiple vendors at low= cost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     

    In a managed network, we expect the off-the-= shelf implementations of IEEE802.11 protocol to be part of the DetNet and s= atisfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admiss= ion Control prevents over-subscribing and minimizes collisions, and where Q= oS provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     

    x.3.2 Low Latency

    Low latency requirement depends on th= e Use Case in question. There is some trade-off in the low latency requirem= ent for the convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as neede= d for the specific situation within the Use Case.

    However, low latencies [Reference 18-= 1160r0] to meet the requirements of a variety of Use Cases (pro AV, synchro= nized multi-channel audio, mobile robotics, repetitive cyclic control systems (1 =96 10 millisecond latencies over the wireless h= op) is achievable in a managed 802.11 network by leveraging current TSN cap= abilities over 802.11, such as time synchronization, stream identification = and time-aware shaping..

    x.5 Security

    WFA WPA3 provides robust security both for m= anagement and data packets. In addition, WFA Easy Connect provides for robu= st security while supporting easy onboarding of headless devices into the network.

     

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration =96 there= are aspects of the wireless network (or the wireless hop from a wired/wire= less bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administ= ration may send the desired configuration to the wired/wireless bridge (the= wireless part in this bridge is the AP function) where it gets converted i= nto parameters that are 802.11-specific.=

     

    x.6.2 Standardized Data Flow Information Mod= els

    Co-ordination between IETF DetNet and IEEE80= 2.11 Working Groups will be required to ensure that this requirement is met= when DetNet operates over IEEE802.11 links.

     

    x.6.3 Symmetrical Path Delays<= span style=3D"color:black">

    This may be a challenge in 802.11 (probably = in all wireless networks, specifically indoors). Need to research this furt= her.

     

    References:

    1. IEEE802.11-2016: Wireless LAN Medium Access Control = (MAC) and Physical Layer (PHY) Specifications
    2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netwo= rks
    3. IEEE802.11ax D3.0: Enhancements for H= igh Efficiency WLAN
    4. WNG documents on RTA = (18-1160r0): https://mentor.i= eee.org/802.11/dcn/18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx=
    5. Wi-Fi Alliance Wireless Protected Access= 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-M= edia Admission Control (WMM-AC)
    7. Wi-Fi All= iance Wireless Protected Access 3 (WPA3)
    8. = Wi-Fi Alliance TimeSyncTM

     

    Cheers = --

    ganesh<= /span>

     

    ________________________= _______________________
    detnet mailing list
    detnet@ietf.org
    https://www.ietf.org/mailman/listinfo/detnet

    --_000_3DF0466E9510274382F5B74499ACD6F8016F2C00lhrpml504mbxexm_-- From nobody Mon Oct 22 14:26:35 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C2D12DD85; Mon, 22 Oct 2018 14:26:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154024359489.13801.16913032839524700637@ietfa.amsl.com> Date: Mon, 22 Oct 2018 14:26:34 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-architecture-09.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:26:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Architecture Authors : Norman Finn Pascal Thubert Balázs Varga János Farkas Filename : draft-ietf-detnet-architecture-09.txt Pages : 42 Date : 2018-10-22 Abstract: This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-architecture-09 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 14:44:43 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F116130F2A; Mon, 22 Oct 2018 14:44:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 aPQ1IBR7vfz5; Mon, 22 Oct 2018 14:44:29 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAAF130EB9; Mon, 22 Oct 2018 14:44:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 57AEB25A14; Mon, 22 Oct 2018 23:44:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1540244667; bh=kILU6mJi51Ul+wlr9zt6bsx5ZpOb2nsI+smd7Q5FSGs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=uvDAymuSVLnK39P1gwwBHw8AX9WqYvF/Cl1sIlp9x0koJn0h+r4rF7PO2G7CC1tyg JrNRospBjlir6CCzJjezANdHURpfqJ+8SY6d86iON2BuiHggfdZbxO31SwCVKL2j6O xBAW19aV8yT577EvzrqsrWgCIfVrKifZ+yBpBEEo= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJB3C3vlL5bE; Mon, 22 Oct 2018 23:44:27 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 22 Oct 2018 23:44:27 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 23:44:26 +0200 From: "Scharf, Michael" To: =?utf-8?B?J0rDoW5vcyBGYXJrYXMn?= CC: "tsv-art@ietf.org" , "draft-ietf-detnet-architecture.all@ietf.org" , DetNet WG Thread-Topic: Tsvart last call review of draft-ietf-detnet-architecture-08 Thread-Index: AQHUZfdHeIU2S3L1QUWzRDtJ6Iup9aUrnUaA Date: Mon, 22 Oct 2018 21:44:25 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D143BE1@rznt8114.rznt.rzdir.fht-esslingen.de> References: <0bb7176c-c386-b863-a4f8-06254f4627ab@ericsson.com> <1705d15c-c7ba-c76f-88db-c75f1a88db0f@ericsson.com> In-Reply-To: <1705d15c-c7ba-c76f-88db-c75f1a88db0f@ericsson.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Tsvart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:44:42 -0000 SGkgSmFub3MsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBNeSBjb21tZW50cyBhcmUgaW5saW5l IFttc10uDQoNCkkgaGF2ZSBvbWl0dGVkIGFsbCBwcm9wb3NlZCBjaGFuZ2VzIHRoYXQgd29yayBm b3IgbWUuDQoNCk1pY2hhZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SsOhbm9zIEZhcmthcyA8amFub3MuZmFya2FzQGVyaWNzc29uLmNvbT4gDQpTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMTcsIDIwMTggMTA6NTYgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWwgPE1pY2hh ZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT4NCkNjOiB0c3YtYXJ0QGlldGYub3JnOyBkcmFmdC1p ZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUuYWxsQGlldGYub3JnOyBEZXROZXQgV0cgPGRldG5ldEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBUc3ZhcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1p ZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMDgNCg0KSGkgTWljaGFlbCwNCg0KVGhhbmsgeW91IHZl cnkgbXVjaCBmb3IgdGhlIHRob3JvdWdoIHJldmlldyBhbmQgZ29vZCBjb21tZW50cyENCg0KUGxl YXNlIGZpbmQgYmVsb3cgaW4tbGluZSByZXNwb25zZXMgYW5kIGhvdyB3ZSBwbGFuIHRvIHVwZGF0 ZSB0aGUgZHJhZnQgdG8gcmVzb2x2ZSB5b3VyIGNvbW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpK YW5vcw0KDQoNCk9uIDkvMjkvMjAxOCAxMjoyNCBBTSwgTWljaGFlbCBTY2hhcmYgd3JvdGU6DQo+ IFJldmlld2VyOiBNaWNoYWVsIFNjaGFyZg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElz c3Vlcw0KPg0KPiBUaGUgZG9jdW1lbnQgIkRldGVybWluaXN0aWMgTmV0d29ya2luZyBBcmNoaXRl Y3R1cmUiDQo+IChkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMDgpIGRlZmluZXMgYW4g b3ZlcmFsbCBmcmFtZXdvcmsgZm9yIA0KPiBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcuDQo+DQo+ IEFzIFRTVi1BUlQgcmV2aWV3ZXIsIEkgYmVsaWV2ZSB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIGlz c3VlcyBhcyANCj4gZGV0YWlsZWQgYmVsb3cuDQo+DQo+IE1pY2hhZWwNCj4NCj4gTWFqb3IgaXNz dWVzOg0KDQpbLi4uXQ0KDQo+IERldE5ldA0KPiBiYXNpY2FsbHkgcmVxdWlyZXMgc3VwcG9ydCBp biAoYWxtb3N0KSBhbGwgbmV0d29yayBkZXZpY2VzIA0KPiB0cmFuc3BvcnRpbmcgRGV0TmV0IHRy YWZmaWMuIFRoYXQgYXNzdW1wdGlvbiBzaG91bGQgYmUgZXhwbGljaXRseSANCj4gc3BlbHQgb3V0 IGVhcmx5IGluIHRoZSBkb2N1bWVudCwgZS5nLiwgaW4gdGhlIGludHJvZHVjdGlvbi4NCg0KQWN0 dWFsbHksIHNvbWUgZm9ybSBvZiBEZXROZXQgc3VwcG9ydCBpcyByZXF1aXJlZCBmcm9tIGVhY2gg bm9kZSB0aGF0IHRyYW5zcG9ydHMgRGV0TmV0IHRyYWZmaWMuIEZvciBpbnN0YW5jZSwgRGV0TmV0 IGZsb3dzIGhhdmUgdG8gYmUgcmVjb2duaXplZCBpbiBvcmRlciBub3QgdG8gc3BvaWwgdGhlaXIg UW9TIGF0IHRoZSBtaW5pbXVtLg0KDQpbbXNdIEkgbG9vayBmb3IgYW4gY2xlYXIgZXhwbGFuYXRp b24gaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBvZiB3aGF0ICJzb21lIGZvcm0gb2YgRGV0 TmV0IHN1cHBvcnQiIGV4YWN0bHkgbWVhbnMuIEZvciBpbnN0YW5jZSwgaXMgc3RhbmRhcmQgTVBM UyBURSB3aXRob3V0IGFueSBEZXROZXQgc3VwcG9ydCBnb29kIGVub3VnaCBmb3IgYW4gTFNSIG9u IHRoZSBJUC9NUExTIHBhdGggdXNlZCBieSBEZXROZXQgdHJhZmZpYywgb3Igbm90PyBBcyBhbiBl eGFtcGxlLCB3aGVuIEkgcmVhZCB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCBpbiBkcmFmdC1pZXRm LWRldG5ldC1kcC1zb2wtbXBscy0wMSAuLi4NCg0KICAgVHJhbnNpdCBub2RlcyBhcmUgbm9ybWFs IE1QTFMgTGFiZWwgU3dpdGNoaW5nIFJvdXRlcnMgKExTUnMpLiAgVGhleQ0KICAgYXJlIGdlbmVy YWxseSB1bmF3YXJlIG9mIHRoZSBzcGVjaWFsIHJlcXVpcmVtZW50cyBvZiBEZXROZXQgZmxvd3Ms DQogICBhbHRob3VnaCB0aGV5IG5lZWQgdG8gcHJvdmlkZSB0cmFmZmljIGVuZ2luZWVyaW5nIHNl cnZpY2VzIGFuZCBwcm9wZXINCiAgIFFvUyB0byB0aGUgTFNQcyBhc3NvY2lhdGVkIHdpdGggRGV0 TmV0IGZsb3dzIHRvIGVuaGFuY2UgdGhlIHByb3NwZWN0DQogICBvZiB0aGUgTFNQcyBtZWV0aW5n IHRoZSBEZXROZXQgc2VydmljZSByZXF1aXJlbWVudHMuICBTb21lDQogICBpbXBsZW1lbnRhdGlv bnMgb2YgdHJhbnNpdCBub2RlcyBtYXkgYmUgRGV0TmV0IGF3YXJlLCBidXQgc3VjaCBub2Rlcw0K ICAganVzdCBzdXBwb3J0IHRoZSBEZXROZXQgdHJhbnNwb3J0IGxheWVyLg0KDQouLi4gSSBjb3Vs ZCBtYXliZSBhc3N1bWUgdGhhdCBhY3R1YWxseSB0aGVyZSBjYW4gYmUgInRyYW5zaXQgbm9kZXMi IHRoYXQgZG8gbm90IHJlcXVpcmUgKmFueSogc29ydCBvZiBEZXROZXQgc3VwcG9ydCBvciBEZXRO ZXQgYXdhcmVuZXNzLiBJcyB0aGF0IGNvcnJlY3Q/IEkgdGhpbmsgdGhlIGFyY2hpdGVjdHVyZSBk b2N1bWVudCBoYXMgdG8gYmUgY2xlYXIgb24gc3VjaCBmdW5kYW1lbnRhbCBxdWVzdGlvbnMuDQoN ClRoZSBJbnRyb2R1Y3Rpb24gY291bGQgYmUgZXh0ZW5kZWQgdG8gY2xhcmlmeSwgZS5nLiwgdGhl IHRoaXJkIHBhcmFncmFwaDoNCg0KT0xEOg0KQSBnb2FsIG9mIERldE5ldCBpcyBhIGNvbnZlcmdl ZCBuZXR3b3JrIGluIGFsbCByZXNwZWN0cy4gVGhhdCBpcywgdGhlIHByZXNlbmNlIG9mIERldE5l dCBmbG93cyBkb2VzIG5vdCBwcmVjbHVkZSBub24tRGV0TmV0IGZsb3dzLCBhbmQgdGhlIGJlbmVm aXRzIG9mZmVyZWQgRGV0TmV0IGZsb3dzIHNob3VsZCBub3QsIGV4Y2VwdCBpbiBleHRyZW1lIGNh c2VzLCBwcmV2ZW50IGV4aXN0aW5nIFFvUyBtZWNoYW5pc21zIGZyb20gb3BlcmF0aW5nIGluIGEg bm9ybWFsIGZhc2hpb24sIHN1YmplY3QgdG8gdGhlIGJhbmR3aWR0aCByZXF1aXJlZCBmb3IgdGhl IERldE5ldCBmbG93cy4gQSBzaW5nbGUgc291cmNlLWRlc3RpbmF0aW9uIHBhaXIgY2FuIHRyYWRl IGJvdGggRGV0TmV0IGFuZCBub24tRGV0TmV0IGZsb3dzLiBFbmQgc3lzdGVtcyBhbmQgYXBwbGlj YXRpb25zIG5lZWQgbm90IGluc3RhbnRpYXRlIHNwZWNpYWwgaW50ZXJmYWNlcyBmb3IgRGV0TmV0 IGZsb3dzLiBOZXR3b3JrcyBhcmUgbm90IHJlc3RyaWN0ZWQgdG8gY2VydGFpbiB0b3BvbG9naWVz OyBjb25uZWN0aXZpdHkgaXMgbm90IHJlc3RyaWN0ZWQuIEFueSBhcHBsaWNhdGlvbiB0aGF0IGdl bmVyYXRlcyBhIGRhdGEgZmxvdyB0aGF0IGNhbiBiZSB1c2VmdWxseSBjaGFyYWN0ZXJpemVkIGFz IGhhdmluZyBhIG1heGltdW0gYmFuZHdpZHRoIHNob3VsZCBiZSBhYmxlIHRvIHRha2UgYWR2YW50 YWdlIG9mIERldE5ldCwgYXMgbG9uZyBhcyB0aGUgbmVjZXNzYXJ5IHJlc291cmNlcyBjYW4gYmUg cmVzZXJ2ZWQuIFJlc2VydmF0aW9ucyBjYW4gYmUgbWFkZSBieSB0aGUgYXBwbGljYXRpb24gaXRz ZWxmLCB2aWEgbmV0d29yayBtYW5hZ2VtZW50LCBieSBhbiBhcHBsaWNhdGlvbuKAmXMgY29udHJv bGxlciwgb3IgYnkgb3RoZXIgbWVhbnMsIGUuZy4sIGEgZHluYW1pYyBjb250cm9sIHBsYW5lIChl LmcuLCBbUkZDMjIwNV0pLg0KDQpORVc6DQpBIGdvYWwgb2YgRGV0TmV0IGlzIGEgY29udmVyZ2Vk IG5ldHdvcmsgaW4gYWxsIHJlc3BlY3RzLiBUaGF0IGlzLCB0aGUgcHJlc2VuY2Ugb2YgRGV0TmV0 IGZsb3dzIGRvZXMgbm90IHByZWNsdWRlIG5vbi1EZXROZXQgZmxvd3MsIGFuZCB0aGUgYmVuZWZp dHMgb2ZmZXJlZCBEZXROZXQgZmxvd3Mgc2hvdWxkIG5vdCwgZXhjZXB0IGluIGV4dHJlbWUgY2Fz ZXMsIHByZXZlbnQgZXhpc3RpbmcgUW9TIG1lY2hhbmlzbXMgZnJvbSBvcGVyYXRpbmcgaW4gYSBu b3JtYWwgZmFzaGlvbiwgc3ViamVjdCB0byB0aGUgYmFuZHdpZHRoIHJlcXVpcmVkIGZvciB0aGUg RGV0TmV0IGZsb3dzLiBBIHNpbmdsZSBzb3VyY2UtZGVzdGluYXRpb24gcGFpciBjYW4gdHJhZGUg Ym90aCBEZXROZXQgYW5kIG5vbi1EZXROZXQgZmxvd3MuIEVuZCBzeXN0ZW1zIGFuZCBhcHBsaWNh dGlvbnMgbmVlZCBub3QgaW5zdGFudGlhdGUgc3BlY2lhbCBpbnRlcmZhY2VzIGZvciBEZXROZXQg Zmxvd3MuIE5ldHdvcmtzIGFyZSBub3QgcmVzdHJpY3RlZCB0byBjZXJ0YWluIHRvcG9sb2dpZXM7 IGNvbm5lY3Rpdml0eSBpcyBub3QgcmVzdHJpY3RlZC4gQW55IGFwcGxpY2F0aW9uIHRoYXQgZ2Vu ZXJhdGVzIGEgZGF0YSBmbG93IHRoYXQgY2FuIGJlIHVzZWZ1bGx5IGNoYXJhY3Rlcml6ZWQgYXMg aGF2aW5nIGEgbWF4aW11bSBiYW5kd2lkdGggc2hvdWxkIGJlIGFibGUgdG8gdGFrZSBhZHZhbnRh Z2Ugb2YgRGV0TmV0LCBhcyBsb25nIGFzIHRoZSBuZWNlc3NhcnkgcmVzb3VyY2VzIGNhbiBiZSBy ZXNlcnZlZC4gUmVzZXJ2YXRpb25zIGNhbiBiZSBtYWRlIGJ5IHRoZSBhcHBsaWNhdGlvbiBpdHNl bGYsIHZpYSBuZXR3b3JrIG1hbmFnZW1lbnQsIGJ5IGFuIGFwcGxpY2F0aW9u4oCZcyBjb250cm9s bGVyLCBvciBieSBvdGhlciBtZWFucywgZS5nLiwgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgKGUu Zy4sIFtSRkMyMjA1XSkuIE5ldHdvcmsgbm9kZXMgc3VwcG9ydGluZyBEZXROZXQgZmxvd3MgaGF2 ZSB0byBpbXBsZW1lbnQgc29tZSBvZiB0aGUgRGV0TmV0IGNhcGFiaWxpdGllcyAobm90IG5lY2Vz c2FyaWx5IGFsbCkgaW4gb3JkZXIgdG8gdHJlYXQgRGV0TmV0IGZsb3dzIHN1Y2ggdGhhdCB0aGVp ciBRb1MgcmVxdWlyZW1lbnRzIGFyZSBtZXQuDQoNClttc10gVG8gbWUsIHRoZSBsYXN0IHNlbnRl bmNlIGlzIG5vdCBjbGVhci4gRG9lcyAic29tZSBvZiB0aGUgRGV0TmV0IGNhcGFiaWxpdGllcyAo bm90IG5lY2Vzc2FyaWx5IGFsbCkiIGluY2x1ZGUgZS5nLiB2YW5pbGxhIHRyYWZmaWMgZW5naW5l ZXJpbmc/IEZvciBpbnN0YW5jZSwgaWYgYSBuZXR3b3JrIG5vZGUgY2FuIGVuc3VyZSB0aGF0IHRo ZSBRb1MgcmVxdWlyZW1lbnRzIGFyZSBtZXQgYnkgbGV2ZXJhZ2luZyBleGlzdGluZyBzdGFuZGFy ZGl6ZWQgVEUgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBEZXROZXQgYXdhcmVuZXNzLCBpcyB0aGlz IGVub3VnaCBmb3IgZGVwbG95aW5nIERldE5ldD8gT3IgZG9lcyB0aGlzIG5vZGUgaGF2ZSB0byBp bXBsZW1lbnQgYWRkaXRpb25hbCBEZXROZXQtc3BlY2lmaWMgZnVuY3Rpb25hbGl0eT8gU3BlY2lm aWNhbGx5LCBwbGVhc2UgZXhwbGFpbiBpZiBhbiBleGlzdGluZyBEZXROZXQtdW5hd2FyZSByb3V0 ZXIgb24gdGhlIHBhdGggdGFrZW4gYnkgRGV0TmV0IHRyYWZmaWMgY2FuIGJlIHVzZWQgdG8gZm9y d2FyZCBEZXROZXQgdHJhZmZpYywgb3IgaWYgaXQgaXMgbWFuZGF0b3J5IHRoYXQgYW55IHJvdXRl ciBmb3J3YXJkaW5nIERldE5ldCB0cmFmZmljIGluZGVlZCBpbXBsZW1lbnRzIG5ldyBjYXBhYmls aXRpZXMgc3BlY2lmaWMgdG8gRGV0TmV0LiBJbiB0aGUgbGF0dGVyIGNhc2UsIEkgdGhpbmsgdGhl IGRvY3VtZW50IHdvdWxkIG5lZWQgdG8gZGlzY3VzcyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IHN0 cmF0ZWdpZXMgYXMgd2VsbC4NCg0KPiAqIEl0IGlzIHN1cnByaXNpbmcgdGhhdCB0aGVyZSBpcyBo YXJkbHkgYW55IGRpc2N1c3Npb24gb24gbmV0d29yayANCj4gcm9idXN0bmVzcw0KPiBhbmQgc2Fm ZXR5OyB0aGlzIHByb2JhYmx5IGFsc28gcmVsYXRlcyB0byBzZWN1cml0eS4gRm9yIGluc3RhbmNl LA0KPiBtaXNjb25maWd1cmF0aW9uIG9yIGVycm9ycyBvZiBmdW5jdGlvbnMgcGVyZm9ybWluZyBw YWNrZXQgcmVwbGljYXRpb24gDQo+IGNvdWxkDQo+IHNldmVyZWx5IGFuZCBwZXJtYW50bHkgY29u Z2VzdCBhIG5ldHdvcmsgYW5kIGNhdXNlIGhhcm0uIEhvdyBkb2VzIHRoZSANCj4gRGV0TmV0DQo+ IGFyY2hpdGVjdHVyZSBlbnN1cmUgdGhhdCBhIG5ldHdvcmsgc3RheXMgZnVsbHkgb3BlcmF0aW9u YWwgZS5nLiBpZiB0aGUgDQo+IHRvcG9sb2d5DQo+IGNoYW5nZXMgb3IgdGhlcmUgYXJlIGVxdWlw bWVudCBmYWlsdXJlcz8gUHJvYmFibHkgdGhpcyBjYW4gYmUgc29sdmVkIGJ5DQo+IGltcGxlbWVu dGF0aW9ucyAoZS5nLiwgZHluYW1pYyBjb250cm9sIHBsYW5lKSwgYnV0IHdoeSBhcmUgY29ycmVz cG9uZGluZw0KPiByZXF1aXJlbWVudHMgbm90IHNwZWx0IG91dD8gU2VjdGlvbiAzLjMuMiBzcGVj dWxhdGVzIHRoYXQgZmlsdGVycyBhbmQgDQo+IHBvbGljZXJzDQo+IGNhbiBoZWxwLCBhbmQgdGhh dCBtYXkgYmUgdHJ1ZSwgYnV0IHRoYXQgcHJvYmFibHkgc3RpbGwgYXNzdW1lcyANCj4gY29uc2lz dGVudGx5DQo+IGFuZCBjb3JyZWN0bHkgY29uZmlndXJlZCAoYW5kIHdlbGwtYmVoYXZpbmcpIGRl dmljZXMuIEFuZCBTZWN0aW9uIDMuMy4yIGlzDQo+IHZhZ3VlIGFuZCBtZW50aW9ucyBhICJpbmZp bml0ZSB2YXJpZXR5IG9mIHBvc3NpYmxlIGZhaWx1cmVzIiB3aXRob3V0IA0KPiBzdGF0aW5nDQo+ IGFueSByZXF1aXJlbWVudHMgb3IgcmVjb21tZW5kYXRpb25zLiBUaGVyZSBtYXkgYmUgZnVydGhl ciBzb2x1dGlvbnMsIA0KPiBzdWNoIGFzDQo+IGNpcmN1aXQgYnJlYWtlcnMgYW5kIHRoZSBsaWtl LiBXaHkgYXJlIHN1Y2ggdG9waWNzIG5vdCBkaXNjdXNzZWQ/DQpTZWN1cml0eSBpc3N1ZXMgYW5k IGNvbnNpZGVyYXRpb25zIGFyZSBhZGRyZXNzZWQgYnkgdGhlIERldE5ldCBTZWN1cml0eSANCmRy YWZ0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1z ZWN1cml0eS4NClJlZmVyZW5jZSB0byB0aGXCoCBEZXROZXQgU2VjdXJpdHkgZHJhZnQgd2lsbCBi ZSBhZGRlZC4NCg0KVGhlcmUgd2lsbCBiZSBhIGRvY3VtZW50IGRlZGljYXRlZCB0byBPcGVyYXRp b25zLCBBZG1pbmlzdHJhdGlvbiBhbmQgDQpNYWludGVuYW5jZSAoT0FNKSwgd2hpY2ggd2lsbCBh ZGRyZXNzIG9wZXJhdGlvbmFsLCBtaXNjb25maWd1cmF0aW9uLCBhbmQgDQpmYWlsdXJlIGRldGVj dGlvbiBpc3N1ZXMuDQoNClRoZSB0b3BvbG9neSBjaGFuZ2VzIGhhdmUgdG8gYmUgc29sdmVkIGJ5 IHRoZSBjb250cm9sIHBsYW5lLCBlaXRoZXIgDQpjZW50cmFsaXplZCBvciBkaXN0cmlidXRlZC4N Cg0KVGhlIGZpbHRlcnMgYW5kIHBvbGljZXJzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4yIGFs c28gcHJvdmlkZSANCnJvYnVzdG5lc3MgYnkgZWxpbWluYXRpbmcvbWl0aWdhdGluZyB0cmFmZmlj IGNvbWluZyBmcm9tIG1hbGZ1bmN0aW9uaW5nIA0KZGV2aWNlcy4NCg0KUkZDMjQ3NSBpcyByZWNv bW1lbmRlZCBmb3IgdHJhZmZpYyBwb2xpY2luZyBmdW5jdGlvbnMgdG8gaW5jcmVhc2UgDQpyb2J1 c3RuZXNzLg0KDQpUaGUgdGV4dMKgIGluIFNlY3Rpb24gMy4zLjIgY291bGQgYmUgbWFkZSBjbGVh cmVyLCBlLmcuLCBieSB1cGRhdGluZyB0aGUgDQpmaXJzdCBwYXJhZ3JhcGggdG86DQoNCk9MRDoN Ck9uZSBrZXkgdG8gYnVpbGRpbmcgcm9idXN0IHJlYWwtdGltZSBzeXN0ZW1zIGlzIHRvIHJlZHVj ZSB0aGUNCmluZmluaXRlIHZhcmlldHkgb2YgcG9zc2libGUgZmFpbHVyZXMgdG8gYSBudW1iZXIg dGhhdCBjYW4gYmUNCmFuYWx5emVkIHdpdGggcmVhc29uYWJsZSBjb25maWRlbmNlLiBEZXROZXQg YWlkcyBpbiB0aGUgcHJvY2VzcyBieQ0KYWxsb3dpbmcgZm9yIGZpbHRlcnMgYW5kIHBvbGljZXJz IHRvIGRldGVjdCBEZXROZXQgcGFja2V0cyByZWNlaXZlZA0Kb24gdGhlIHdyb25nIGludGVyZmFj ZSwgb3IgYXQgdGhlIHdyb25nIHRpbWUsIG9yIGluIHRvbyBncmVhdCBhDQp2b2x1bWUsIGFuZCB0 byB0aGVuIHRha2UgYWN0aW9ucyBzdWNoIGFzIGRpc2NhcmRpbmcgdGhlIG9mZmVuZGluZw0KcGFj a2V0LCBzaHV0dGluZyBkb3duIHRoZSBvZmZlbmRpbmcgRGV0TmV0IGZsb3csIG9yIHNodXR0aW5n IGRvd24gdGhlDQpvZmZlbmRpbmcgaW50ZXJmYWNlLg0KDQpORVc6DQpSb2J1c3QgcmVhbC10aW1l IHN5c3RlbXMgcmVxdWlyZSB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBwb3NzaWJsZQ0KZmFpbHVy ZXMuIEZpbHRlcnMgYW5kIHBvbGljZXJzIHNob3VsZCBiZSB1c2VkIGluIGEgRGV0TmV0IG5ldHdv cmsgdG8NCmRldGVjdCBpZiBEZXROZXQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gdGhlIHdyb25n IGludGVyZmFjZSwgb3IgYXQNCnRoZSB3cm9uZyB0aW1lLCBvciBpbiB0b28gZ3JlYXQgdm9sdW1l LiBGdXJ0aGVybW9yZSwgZmlsdGVycyBhbmQNCnBvbGljZXJzIGNhbiB0YWtlIGFjdGlvbiB0byBk aXNjYXJkIG9mZmVuZGluZyBwYWNrZXRzIG9yIGZsb3dzLCBvcg0KdHJpZ2dlciBzaHV0dGluZyBk b3duIHRoZSBvZmZlbmRpbmcgRGV0TmV0IGZsb3csIG9yIHNodXR0aW5nIGRvd24NCnRoZSBvZmZl bmRpbmcgaW50ZXJmYWNlLg0KDQpbbXNdIFRoYXQgZG9lcyBub3QgYWRkcmVzcyBteSBjb25jZXJu LiBBcyBJIHdyb3RlIGFscmVhZHksIEkgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGhhcyB0byBkaXNj dXNzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGNpcmN1aXQgYnJlYWtlcnMgYWNjb3JkaW5nIHRvIFJG QyA4MDg0LiANCg0KPiAqIFNvbWV3aGF0IHJlbGF0ZWQsIHRoZSBkb2N1bWVudCBvbmx5IGxvb2tz IGF0IGltcGFjdCBvZiBmYWlsdXJlcyB0byANCj4gdGhlIFFvUyBvZg0KPiBEZXROZXQgdHJhZmZp Yy4gV2hhdCBpcyBtaXNzaW5nIGlzIGEgZGlzY3Vzc2lvbiBob3cgdG8gcHJvdGVjdCANCj4gbm9u LURldE5ldCBwYXJ0cw0KPiBvZiBhIG5ldHdvcmsgZnJvbSBhbnkgaGFybSBjYXVzZWQgYnkgRGV0 TmV0IG1lY2hhbmlzbXMuIFNvbHV0aW9ucyB0byB0aGlzDQo+IHByb2JhYmx5IGV4aXN0LiBCdXQg d2h5IGlzIHRoZSBpbXBhY3Qgb24gbm9uLURldE5ldCB0cmFmZmljIChlLmcuLCBpbiANCj4gY2Fz ZSBvZg0KPiB0b3BvbG9neSBjaGFuZ2VzIG9yIGZhaWx1cmVzIG9mIERldE5ldCBmdW5jdGlvbnMp IG5vdCBkaXNjdXNzZWQgYXQgYWxsIA0KPiBpbiB0aGUNCj4gZG9jdW1lbnQ/DQpBY3R1YWxseSB0 aGUgcmVndWxhdGlvbiBvZiBEZXROZXQgdHJhZmZpYyBieSBwb2xpY2VzIGFuZCBmaWx0ZXJzIA0K cHJvdGVjdHMgYm90aCBvdGhlciBEZXROZXQgdHJhZmZpYyBhbmQgbm9uLURldE5ldCB0cmFmZmlj Lg0KDQpTZWN0aW9uIDMuMy4xIGNvdWxkIGJlIGV4dGVuZGVkIHRvIG1ha2UgaXQgY2xlYXIsIGUu Zy4sIGJ5IGV4dGVuZGluZyB0aGUgDQpsYXN0IHBhcmFncmFwaDoNCg0KT0xEOg0KSWRlYWxseSwg dGhlIG5ldCBlZmZlY3Qgb2YgdGhlIHByZXNlbmNlIG9mIERldE5ldCBmbG93cyBpbiBhIG5ldHdv cmsNCm9uIHRoZSBub24tRGV0TmV0IHBhY2tldHMgaXMgcHJpbWFyaWx5IGEgcmVkdWN0aW9uIGlu IHRoZSBhdmFpbGFibGUNCmJhbmR3aWR0aC4NCg0KTkVXOg0KVHJhZmZpYyBwb2xpY2luZyBmdW5j dGlvbnMgKGUuZy4gW1JGQzI0NzVdKSBhcmUgdXNlZCB0byBhdm9pZCB0aGUNCnN0YXJ2YXRpb24g b2Ygbm9uLURldE5ldCB0cmFmZmljLiBUaHVzLCB0aGUgbmV0IGVmZmVjdCBvZiB0aGUgcHJlc2Vu Y2UNCm9mIERldE5ldCBmbG93cyBpbiBhIG5ldHdvcmsgb24gbm9uLURldE5ldCBmbG93cyBpcyBw cmltYXJpbHkgYQ0KcmVkdWN0aW9uIGluIHRoZSBhdmFpbGFibGUgYmFuZHdpZHRoLg0KDQpbbXNd IEkgYmVsaWV2ZSBhIHN0cm9uZ2VyIHdvcmRpbmcgaXMgbmVlZGVkLCBlLmcuIGFsb25nIHRoZSBs aW5lcyBvZiAiYSBEZXROZXQgZGVwbG95bWVudCBtdXN0IGF2b2lkIHN0YXJ2YXRpb24gb2Ygbm9u LURldE5ldCB0cmFmZmljIC4uLiIuDQoNClsuLi5dDQoNCj4gKiBTZWN0aW9uIDQuNCByZWZlcnMg dG8gUkZDIDc0MjYsIHdoaWNoIGlzIGFuIGluZm9ybWF0aW9uYWwgUkZDIG9uIA0KPiBJUlRGIHN0 cmVhbSwNCj4gYW5kIHRoZSBkb2N1bWVudCB1c2VzIHRoZSBjb25jZXB0cyBpbnRyb2R1Y2VkIHRo ZXJlIChlLmcuLCAicGxhbmVzIikuIA0KPiBUaGlzIGlzDQo+IHZlcnkgY29uZnVzaW5nLiBGaXJz dCwgYW4gSUVURiBQcm9wb3NlZCBTdGFuZGFyZCBzaG91bGQgcHJvYmFibHkgcmVmZXIgdG8NCj4g ZG9jdW1lbnRzIGhhdmluZyBJRVRGIGNvbnNlbnN1cy4gQW4gZXhhbXBsZSB3b3VsZCBiZSBSRkMg NzQ5MSwgYWxiZWl0IA0KPiB0aGVyZSBpcw0KPiBvdGhlciByZWxhdGVkIHdvcmsgYXMgd2VsbCwg ZS5nLiwgaW4gdGhlIFRFQVMgV0cuIFNlY29uZCwgU2VjdGlvbiA0LjQgDQo+IGlzIGJ5IGFuZA0K PiBsYXJnZSBkZWNvdXBsZWQgZnJvbSB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgYW5kIG5vdCBz cGVjaWZpYyB0byBEZXROZXQuDQo+IE5laXRoZXIgZG8gb3RoZXIgc2VjdGlvbnMgb2YgdGhlIGRv Y3VtZW50IHJlZmVyIHRvIHRoZSBjb25jZXB0cyANCj4gaW50cm9kdWNlZCBpbg0KPiBTZWN0aW9u IDQuNCwgbm9yIGRvZXMgU2VjdGlvbiA0LjQgdXNlIHRoZSBEZXROZXQgdGVybWlub2xvZ3kgb3Ig ZGlzY3Vzcw0KPiBhcHBsaWNhYmlsaXR5IHRvIERldE5ldC4gU2VjdGlvbiA0LjQgZXZlbiBtZW50 aW9ucyBleHBsaWNpdGx5IGF0IHRoZSANCj4gZW5kIHRoYXQNCj4gaXQgZGlzY3Vzc2VzIGFzcGVj dHMgdGhhdCBhcmUgb3J0aG9nb25hbCB0byB0aGUgRGV0TmV0IGFyY2hpdGVjdHVyZS4gDQo+IEl0 IGlzIG5vdA0KPiBhdCBhbGwgY2xlYXIgd2h5IFNlY3Rpb24gNC40IGlzIGluIHRoaXMgZG9jdW1l bnQuIFNlY3Rpb24gNC40IGNvdWxkIGJlIA0KPiByZW1vdmVkDQo+IGZyb20gdGhlIGRvY3VtZW50 IHdpdGhvdXQgaW1wYWN0aW5nIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4NClRoZSBkb2N1bWVu dCBzaG91bGQgcG9pbnQgb3V0IHRvIHRyYWZmaWMgZW5naW5lZXJpbmcgYW5kIGNlbnRyYWxpemVk IA0KY29udHJvbCBwbGFuZSBhc3BlY3RzLCBzbyBpdCBpcyBiZXR0ZXIgdG8ga2VlcCBTZWN0aW9u IDQuNC4NCg0KUkZDIDc0MjYgcHJvdmlkZXMgdGhlIGZ1bGwgcGljdHVyZSBvZiBTRE4gYXJjaGl0 ZWN0dXJlLCB3aGljaCBuZWVkcyB0byANCmJlIHJlZmVycmVkIGZyb20gdGhlIERldE5ldCBhcmNo aXRlY3R1cmUuIE5vIG90aGVyIFJGQyBwcm92aWRlcyBzdWNoIA0KZGV0YWlsZWQgcGljdHVyZS4g VGhlcmVmb3JlLCB3ZSBuZWVkIHRvIGtlZXAgdGhlIHJlZmVyZW5jZSB0byBSRkMgNzQyNiwgDQp3 aGljaCBpcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UuDQoNClttc10gSSdsbCBsZWF2ZSB0aGF0 IHVwIHRvIHRoZSBJRVNHIHRvIGRlY2lkZSB3aGV0aGVyIGFuIElFVEYgcHJvcG9zZWQgc3RhbmRh cmQgc2hvdWxkIGJ1aWxkIGFuIGFyY2hpdGVjdHVyZSBiYXNlZCBvbiByZXNlYXJjaCB3b3JrIGlu c3RlYWQgb2YsIHNheSwgZG9jdW1lbnRzIHdpdGggSUVURiBjb25zZW5zdXMuIEFzIGEgc2lkZSBu b3RlLCBJIGJlbGlldmUgdGhlIHVuZGVyc3RhbmRpbmcgaW4gaW5kdXN0cnkgd2hhdCAiU0ROIGFy Y2hpdGVjdHVyZSIgcmVhbGx5IG1lYW5zIGFuZCBob3cgaXQgaXMgaW1wbGVtZW50ZWQgbWF5IGhh dmUgZXZvbHZlZCBzaW5jZSBwdWJsaWNhdGlvbiBvZiBJUlRGIFJGQyA3NDI2LCB3aGljaCB3YXMg cHVibGlzaGVkIGluIEphbi4gMjAxNS4gRm9yIGluc3RhbmNlLCBJUlRGIFJGQyA3NDI2IGRvZXMg bm90IGRpc2N1c3MgdGhlIGltcGxpY2F0aW9ucyBvZiBzZWdtZW50IHJvdXRpbmcsIEJHUC1MUywg YW5kIG90aGVyIHJlY2VudCBJRVRGIHRlY2huaXF1ZXMuIEFuZCwgYmFzZWQgb24gd2hhdCBJIHJl YWQgaW4gdGhlIERldE5ldCBhcmNoaXRlY3R1cmUsIEkgYmVsaWV2ZSBEZXROZXQgY291bGQgYWN0 dWFsbHkgYmUgaW1wbGVtZW50ZWQgd2l0aG91dCBhbnkgIlNETiBhcmNoaXRlY3R1cmUiLCBlLmcu IGJ5IGRpc3RyaWJ1dGVkIHRyYWZmaWMgZW5naW5lZXJpbmcuIEFzIGEgcmVzdWx0LCBJIGRvbid0 IGV2ZW4gdW5kZXJzdGFuZCB0aGUgbmVlZCB0byBkaXNjdXNzICJTRE4iLg0KDQpbbXNdIEZvciB0 aGUgcmVjb3JkOiBBcyBUU1YtQVJUIHJldmlld2VyLCBJIHF1ZXN0aW9uIHdoZXRoZXIgSVJURiBS RkMgNzQyNiBpcyBpbmRlZWQgYW4gYXBwcm9wcmlhdGUgcmVmZXJlbmNlLCBJIGhhdmUgZG91YnRz IHRoYXQgSVJURiBSRkMgNzQyNiBpcyByZWFsbHkgdXAtdG8tZGF0ZSwgYW5kIEkgYW0gY29uY2Vy bmVkIGFib3V0IHRoZSBjb250ZW50IHF1YWxpdHkgb2Ygc2VjdGlvbiA0LjQsIGUuZy4sIHJlZ2Fy ZGluZyB0aGUgbGFjayBvZiBhbGlnbm1lbnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQu IFRoZSBJRVNHIHdpbGwgY2VydGFpbmx5IGhhdmUgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyB0aGF0 IHRoYW4gbWUgaG93IHRvIGRlYWwgd2l0aCBzdWNoIHRvcGljcy4NCiANClRoZSByZWxhdGVkIHdv cmsgaW4gVEVBUyBpcyBhbHJlYWR5IHJlZmVycmVkIHRvLg0KDQpbLi4uXQ0KDQo+IE1pbm9yIGlz c3VlczoNCj4NCj4gKiBUZXJtaW5vbG9neSAiRGV0TmV0IHRyYW5zcG9ydCBsYXllciINCj4NCj4g VGhlIHRlcm0gInRyYW5zcG9ydCBsYXllciIgaGFzIGEgd2VsbC1kZWZpbmVkIG1lYW5pbmcgaW4g dGhlIElFVEYsIGUuZy4NCj4gb3JpZ2luYXRpbmcgZnJvbSBSRkMgMTEyMi4gV2hpbGUgInRyYW5z cG9ydCIgYW5kIGUuZy4gInRyYW5zcG9ydCANCj4gbmV0d29yayIgaXMNCj4gdXNlZCBpbiB0aGUg SUVURiBmb3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcyBpbiBkaWZmZXJlbnQgYXJlYXMsIEkgDQo+ IHRoaW5rIHRoZQ0KPiB0ZXJtICJ0cmFuc3BvcnQgbGF5ZXIiIGlzIHR5cGljYWxseSB1bmRlcnN0 b29kIHRvIHJlZmVyIHRvIHRyYW5zcG9ydA0KPiBwcm90b2NvbHMgc3VjaCBhcyBUQ1AgYW5kIFVE UC4gQXMgc3VjaCwgSSBwZXJzb25hbGx5IGZpbmQgdGhlIHRlcm0gIkRldE5ldA0KPiB0cmFuc3Bv cnQgbGF5ZXIiIG1pc2xlYWRpbmcgYW5kIGNvbmZ1c2luZy4gVGhlIGNvbmZ1c2lvbiBpcyBlYXN5 IHRvIA0KPiBzZWUgZS5nLg0KPiBpbiBGaWd1cmUgNCwgd2hlcmUgVURQICh3aGljaCBpcyBhIHRy YW5zcG9ydCBwcm90b2NvbCBhcyBwZXIgUkZDIDExMjIpIA0KPiBzaXRzDQo+IG9uIHRvcCBvZiAi dHJhbnNwb3J0Ii4NCj4NCj4gQmFzZWQgb24gdGhlIGRvY3VtZW50IGl0IGFsc28gbWF5IGJlIHNv bHV0aW9uL2ltcGxlbWVudGF0aW9uIHNwZWNpZmljIA0KPiB3aGV0aGVyDQo+IHRoZSAiRGV0TmV0 IHRyYW5zcG9ydCBsYXllciIgaXMgYWN0dWFsbHkgYSBzZXBhcmF0ZSBwcm90b2NvbCBsYXllciAN Cj4gY29tcGFyZWQNCj4gdG8gdGhlICJEZXROZXQgc2VydmljZSBsYXllciIuIFRodXMgaXQgaXMg bm90IGNsZWFyIHRvIG1lIHdoeSB0aGUgd29yZA0KPiAibGF5ZXIiIGhhcyB0byBiZSB1c2VkLCBz cGVjaWZpY2FsbHkgaW4gY29tYmluYXRpb24gInRyYW5zcG9ydCBsYXllciIuDQo+DQo+IFRvIG1l IGFzLCB0aGUgd29yZCAidHJhbnNwb3J0IGxheWVyIiAoYW5kICJ0cmFuc3BvcnQgcHJvdG9jb2wi KSBzaG91bGQgYmUNCj4gdXNlZCBmb3IgcHJvdG9jb2xzIGRlZmluZWQgaW4gVFNWIGFyZWEsIGNv bnNpc3RlbnQgd2l0aCBSRkMgMTEyMi4gQnV0IA0KPiB0aGlzIGlzDQo+IHByb2JhYmx5IGEgcXVl c3Rpb24gdG8gYmUgc29ydGVkIG91dCBieSB0aGUgSUVTRy4NCg0KInRyYW5zcG9ydCIgaXMgdXNl ZCBoZXJlIGFzIGluICJwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzIiBub3QgYXMgT1NJIEw0IA0K dHJhbnNwb3J0Lg0KDQpbbXNdIEF0IHRoZSByaXNrIG9mIHN0YXRpbmcgdGhlIG9idmlvdXM6IFRo ZSByZWxldmFudCBzZWN0aW9uIG9mIFJGQyAxMTIyIGRlZmluaW5nICJ0cmFuc3BvcnQgbGF5ZXIi IGlzIGVudGl0bGVkIGJ5ICJUaGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIi4gQW5kLCBhY2NvcmRp bmcgZS5nLiB0byBSRkMgNTkyMSwgInBhY2tldCB0cmFuc3BvcnQgbmV0d29yayIgaXMgYSB0ZXJt IGRlZmluZWQgYnkgSVRVLVQuIEluIGFuIElFVEYgZG9jdW1lbnQsIEkgYmVsaWV2ZSBJRVRGIHRl cm1pbm9sb2d5IHNob3VsZCBiZSB1c2VkLiANCg0KSSBzdWdnZXN0IHRvIHVzZSB0aGUgdGVybXMg IkRldE5ldCB0cmFuc3BvcnQgc3ViLWxheWVyIiBhbmQgIkRldE5ldCANCnNlcnZpY2Ugc3ViLWxh eWVyIiB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCwgd2hpY2ggd291bGQgaG9wZWZ1bGx5IGF2b2lk IA0KY29uZnVzaW9uLg0KDQpbbXNdICJEZXROZXQgdHJhbnNwb3J0IHN1Yi1sYXllciIgc29tZXdo YXQgc29sdmVzIG15IGNvbmNlcm4gb2YgYXZvaWRpbmcgdGhlIGV4cHJlc3Npb24gInRyYW5zcG9y dCBsYXllciIuIFRvIHJlYWxseSBhdm9pZCBjb25mdXNpb24sIEkgYmVsaWV2ZSBpdCB3b3VsZCBi ZSBiZXR0ZXIgdG8gYXZvaWQgdGhlIGFtYmlndW91cyB0ZXJtICJ0cmFuc3BvcnQiIGFsdG9nZXRo ZXIuICBCdXQgSSB3aWxsIGJlIGZpbmUgaWYgYWxsIERldE5ldCBkb2N1bWVudHMgY29uc2lzdGVu dGx5IGF2b2lkIHRoZSB0ZXJtICJ0cmFuc3BvcnQgbGF5ZXIiLiANCg0KTWljaGFlbA0K From nobody Mon Oct 22 14:58:33 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3EB130DF6; Mon, 22 Oct 2018 14:58:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154024550437.13342.4686308658599451396@ietfa.amsl.com> Date: Mon, 22 Oct 2018 14:58:24 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-02.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 21:58:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : DetNet Flow Information Model Authors : János Farkas Balázs Varga Rodney Cummings Yuanlong Jiang Yiyong Zha Filename : draft-ietf-detnet-flow-information-model-02.txt Pages : 24 Date : 2018-10-22 Abstract: This document describes flow and service information model for Deterministic Networking (DetNet). The DetNet service is provided either for a Layer 3 or a Layer 2 flow. This document provides DetNet flow and service information model both for Layer 3 and Layer 2 flows in an integrated fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-flow-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-flow-information-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-flow-information-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 15:11:08 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2676130DC5 for ; Mon, 22 Oct 2018 15:11:00 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWIF_ZTeo1QN for ; Mon, 22 Oct 2018 15:10:55 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 0D9CF130DC8 for ; Mon, 22 Oct 2018 15:10:54 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 15:10:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.54,413,1534834800"; d="scan'208,217"; a="80758563" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga008.fm.intel.com with ESMTP; 22 Oct 2018 15:10:53 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX109.amr.corp.intel.com ([169.254.11.251]) with mapi id 14.03.0319.002; Mon, 22 Oct 2018 15:10:53 -0700 From: "Venkatesan, Ganesh" To: Norman Finn , "Andrew G. Malis" CC: detnet WG Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAkcy8AAAPJfDAACOF1gAAOgLxA//+bKQCAAGesoA== Date: Mon, 22 Oct 2018 22:10:52 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B59055C@ORSMSX107.amr.corp.intel.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com>, <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWYwNWI2NGYtMzIxMS00ZTRkLWE3NWMtODZjMTczNGMxNmU4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVEdoaVoxYllkbU9Fck8xQ1pNU1JIVVNwMXFQT1hvQkNpNVBCZnYyT0RjekhJVmRmSUFSK1BlV3ZkNjd2WWxLZSJ9 dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B59055CORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 22:11:07 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B59055CORSMSX107amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Norm: Please see my response(s) inline, below. Cheers -- ganesh From: Norman Finn Sent: Monday, October 22, 2018 5:12 PM To: Venkatesan, Ganesh ; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 I think I was misunderstanding your wishes, Ganesh. Sorry. I thought you = wanted to add 802.11 to the core of DetNet and/or to the architecture. Now= I see that you are talking about a use case. I'd have to look more at the= details to have an opinion. Given the variability of 802.11 delivery, can you comment about how the dif= ference between DetNet service and typical weighted priorities would be cri= tical to the success of your envisioned applications? I have heard argumen= ts about needing DetNet/TSN to enable timed deliveries. [[gv]] We argue that the 'variability of 802.11 delivery' is an artifact of= an unplanned/unmanaged IEEE802.11 deployment (and can be eliminated). A de= ployment where the traffic characteristics is taken into account (including= the fact that some of the traffic in the network is TSN, the IEEE802.11 po= rtion(s) of the network is configured to: 1. Allocate operational channels to eliminate wireless collisions 2. Use admission control to avoid over-subscription of the network (may = be even use SRP over IEEE802.11) 3. With IEEE802.1AS over IEEE802.11 (and IEEE802.1) enable time synchron= ization and schedule transmit opportunities for TSN traffic 4. In the future we will be able to execute IEEE802.1Qbv over IEEE802.11= (this is a Topic Interest Group at this time). If this configuration is done right, the one-hop overhead is just time it t= akes to transmit the payload (at a given MCS). Going forward, the performance will only improve with IEEE802.11ax where OF= DMA can be used to transmit to/receive from multiple destinations/transmitt= ers simultaneously. -- Norm ________________________________ From: Venkatesan, Ganesh [ganesh.venkatesan@intel.com] Sent: Monday, October 22, 2018 1:37 PM To: Norman Finn; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Norm: Not all Use Cases in draft-ietf-detnet-use-cases-19 require a reliability o= f 7 or 8 nines in reliability. For instance, section 3 Electrical Utilities= has a requirement of 0.1-1% packet loss (3.1.1.1.4). Do you think a manage= d IEEE802.11 network would not meet that requirement? I would agree with your assessment (cannot achieve reliability to 7 or 8 ni= nes) if we are exclusively focusing on IEEE802.11 only networks. The propos= al is to consider a 802.1 core DetNet with IEEE802.11 links at the last (or= first) hop, for Use Cases where a managed IEEE802.11 network (where the wi= reless configuration takes into account the need for low latency and high r= eliability for TSN traffic). Cheers -- ganesh From: Norman Finn > Sent: Monday, October 22, 2018 4:18 PM To: Venkatesan, Ganesh >; Andrew G. Malis = > Cc: detnet WG > Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= 'IEEE TSN as a layer2 for DetNet'. Given that the TSN work is done in IEEE= 802.1 TSN, do you perceive IEEE802.11 as 'IEEE TSN as a layer2 for DetNet'?= And would that be the perception of the rest of the IETF DetNet membership= ? If your answer is Yes to both the questions, then I would agree (and if w= e delete the reference in section 5.1.1 where the current draft calls out I= EEE802.11 (WiFi) as unsuited for DetNet) that "we don't need to include ex= plicit references to 802.11", but carefully call out in other pertinent IET= F DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requireme= nts explicitly. Cheers -- ganesh From: Andrew G. Malis > Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path.. Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers ("making AVB= /TSN-type deterministic performance available from layer-3 applications" or= "connecting two AVB/TSN LANs or 'islands' together through a standard rout= er") should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE8= 02.11 is already supported for time synchronization, stream identification = and reservation and additional TSN capabilities are under development (supp= ort for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 - 10 millisecond latencies over = the wireless hop) is achievable in a managed 802.11 network by leveraging c= urrent TSN capabilities over 802.11, such as time synchronization, stream i= dentification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration - there are aspects of the wireless netw= ork (or the wireless hop from a wired/wireless bridge to a wireless endpoin= t) that will have to be defined. For instance, the controller that does the= central administration may send the desired configuration to the wired/wir= eless bridge (the wireless part in this bridge is the AP function) where it= gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_311BE885E0DA8D4BB369A037CF5B64A79B59055CORSMSX107amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Norm:

     

    Please see my response(s) inline, below.<= /p>

     

    Cheers -= -

    ganesh

     

    From: Nor= man Finn <norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 5:12 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G= . Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    I think I was misunderstanding your wish= es, Ganesh.  Sorry.  I thought you wanted to add 802.11 to the co= re of DetNet and/or to the architecture.  Now I see that you are talking about a use case.  I'd have to look more at the detai= ls to have an opinion.

     

    Given the variability of 802.11 delivery= , can you comment about how the difference between DetNet service and typic= al weighted priorities would be critical to the success of your envisioned applications?  I have heard arguments abou= t needing DetNet/TSN to enable timed deliveries.

    [[gv]] We argue that the ‘variability of= 802.11 delivery’ is an artifact of an unplanned/unmanaged IEEE802.11= deployment (and can be eliminated). A deployment where the traffic charact= eristics is taken into account (including the fact that some of the traffic in the network is TSN, the IEEE802.11 portio= n(s) of the network is configured to:

    1. Allocate operational channels to eliminate wireless collisions
    2. Use admission control to avoid over-subscription of the netw= ork (may be even use SRP over IEEE802.11)
    3. With IEEE802= .1AS over IEEE802.11 (and IEEE802.1) enable time synchronization and schedu= le transmit opportunities for TSN traffic
    4. In the futur= e we will be able to execute IEEE802.1Qbv over IEEE802.11 (this is a Topic = Interest Group at this time).

     

    If this configuration is done right, the one-hop ove= rhead is just time it takes to transmit the payload (at a given MCS).<= /o:p>

     

    Going forward, the performance will only improve wit= h IEEE802.11ax where OFDMA can be used to transmit to/receive from multiple= destinations/transmitters simultaneously.

     

    -- Norm

     

    From:<= /span> Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 1:37 PM
    To: Norman Finn; Andrew G. Malis
    Cc: detnet WG
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Norm:

     =

    Not all Use Cases in dra= ft-ietf-detnet-use-cases-19 require a reliability of 7 or 8 nines in reliab= ility. For instance, section 3 Electrical Utilities has a requirement of 0.= 1-1% packet loss (3.1.1.1.4). Do you think a managed IEEE802.11 network would not meet that requirement?

     =

    I would agree with your = assessment (cannot achieve reliability to 7 or 8 nines) if we are exclusive= ly focusing on IEEE802.11 only networks. The proposal is to consider a 802.= 1 core DetNet with IEEE802.11 links at the last (or first) hop, for Use Cases where a managed IEEE802.11 netwo= rk (where the wireless configuration takes into account the need for low la= tency and high reliability for TSN traffic).

     =

    Cheers -= -

    ganesh

     =

    From: Norman Finn <norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 4:18 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G. Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org= >
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    There is a strong desire from a number o= f application domains for deterministic wireless networks.  This desir= e has generated projects such as the 6TiSCH working group in the WPAN world.  There are things that one can do to greatly= improve the reliability and timeliness of 802.11 networks.  I was the= primary instigator of 802.11ak, that make it possible to have an 802.11 li= nk in the middle of a wired network; the wired robot attached to a wired network on a factory floor via Wi-Fi was one of = the examples I used to promote the idea.=

     

    Having said that ...

     

    In the wired world, simply eliminating c= ongestion loss gets us to 7 or 8 nines in reliability.  Dual pathing g= ets us to 10 or more nines.  And, these are things that we know how to accomplish, today.<= o:p>

     

    In the wireless world, signal interferen= ce can easily drop you to 3 nines.  Deterministic wireless needs diffe= rent techniques for achieving reliability -- for example, spreading the data out in time to avoid interference, and hop-by-hop ACK/r= etransmission.  These are not required in the wired world.  This = leads me to talk about the (latency)*(loss rate) product.  That is, in= wireless, it is meaningful to have a direct tradeoff between latency and loss rate, to give room for retransmissions and time s= preading.  That product is orders of magnitude different between the w= ired and wireless cases, and that means that the applications that can use = the service have orders of magnitude different requirements.

     

    I would fully support the creation of a = Deterministic Wireless WG.  I believe that such a group and DetNet wou= ld complement each others' efforts.  The goals are similar, but the solutions are sufficiently different that I would not wan= t wireless support to be a goal of DetNet.

     

    -- Norm

     

    From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     =

    Reading the current draf= t, specifically section 5.1.1, I get the impression that the current Use Ca= se document does not consider IEEE802.11 as part of ‘IEEE TSN as a la= yer2 for DetNet’. Given that the TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as ‘IEEE TSN as= a layer2 for DetNet’? And would that be the perception of the rest o= f the IETF DetNet membership? If your answer is Yes to both the questions, = then I would agree (and if we delete the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as un= suited for DetNet)  that “we don’t need to include explici= t references to 802.11”, but carefully call out in other pertinent IE= TF DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requirements explicitly.

     =

    Cheers -= -

    ganesh

     =

    From: Andrew G. Malis <agmalis@gmail.com>
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    Ganesh,

     =

    For those of us that don= 't attend IEEE, can you fill us in on the relationship between 801.11 and T= SN? As the DetNet documents already refer (in many places) to IEEE TSN as a= layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we = don't need to include explicit references to 802.11. Just a thought.

     =

    Thanks,

    Andy

     =

     =

    On Sun, Oct 21, 2018 at = 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.com> wrote:=

    Hello DetNet members:

     =

    We proposed adding IEEE8= 02.11 as a L2 media for DetNet. Based on our experience with IEEE802.11 in = managed deployments, we believe that 802.11 links can meet DetNet requireme= nts described in the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and = in other Topic Interest Groups within IEEE802.11 Working Group that renders= 802.11 as a versatile L2 media for DetNet.

     =

    Please let me know if yo= u have comments/questions on this submission:

     =

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ..

     

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     =

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

     =

    Thus far IEEE 802.11 has been the only= wireless media technology that has already included support for some of th= e 802.1 TSN capabilities required to address the use cases described in this document. The IEEE 802.11 working group has be= en working in collaboration with the IEEE 802.1 group for several years ext= ending 802.1 features over 802.11. Therefore, in the Use Cases described in= this document, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under cons= ideration is a wired/wireless network with the first and/or the last nodes = being IEEE802.11 hops and the rest of the network is wired. As with any wir= eless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between laten= cy and reliability guarantees must be considered as well as managed deploym= ent requirements.

    The 802.1 and 802.11 feature set that is alrea= dy part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificatio= ns to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNe= t described in this document.=

     =

    The following sub-sections are analogues of co= rresponding subsections in section-11. The intent is to demonstrate how wel= l IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     =

    x.1.1 Extension to Ethernet and 802.1 TSN

     =

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     =

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate = L2 and L3 layers (“making AVB/TSN-type deterministic performance avai= lable from layer-3 applications” or “connecting two AVB/TSN LANs or ‘islands’ together through a standard router&#= 8221;) should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEE= E802.11 is already supported for time synchronization, stream identificatio= n and reservation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     =

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

     =

    x.1.6 Guaranteed End-to-End Delivery

    Guaranteed e2e delivery is achieved in= DetNet by constraining the network (the network is not the open Internet b= ut a constrained/managed network).<= /o:p>

    With 802.11, similar constraints can be put in= place in a managed deployment. For instance, multiple channels and Basic S= ervice Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     =

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     =

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify= and prioritize time-sensitive operational traffic. The prioritization (and= the resulting improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even= more effective with high efficiency features from IEEE802.11ax, IEEE802.1Q= bv over IEEE802.11, etc.

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     =

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     =

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     =

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admissio= n Control prevents over-subscribing and minimizes collisions, and where QoS= provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     =

    x.3.2 Low Latency

    Low latency requirement depends on the= Use Case in question. There is some trade-off in the low latency requireme= nt for the convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed f= or the specific situation within the Use Case.

    However, low latencies [Reference 18-1= 160r0] to meet the requirements of a variety of Use Cases (pro AV, synchron= ized multi-channel audio, mobile robotics, repetitive cyclic control systems (1 – 10 millisecond latencies over the wirele= ss hop) is achievable in a managed 802.11 network by leveraging current TSN= capabilities over 802.11, such as time synchronization, stream identificat= ion and time-aware shaping..<= /span>

    x.5 Security

    WFA WPA3 provides robust security both for man= agement and data packets. In addition, WFA Easy Connect provides for robust= security while supporting easy onboarding of headless devices into the network.=

     =

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration – the= re are aspects of the wireless network (or the wireless hop from a wired/wi= reless bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administ= ration may send the desired configuration to the wired/wireless bridge (the= wireless part in this bridge is the AP function) where it gets converted i= nto parameters that are 802.11-specific.=

     =

    x.6.2 Standardized Data Flow Information Model= s

    Co-ordination between IETF DetNet and IEEE802.= 11 Working Groups will be required to ensure that this requirement is met w= hen DetNet operates over IEEE802.11 links.

     =

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in= all wireless networks, specifically indoors). Need to research this furthe= r.

     =

    References:

    1. IEEE802.11-2016: Wireless LA= N Medium Access Control (MAC) and Physical Layer (PHY) Specifications
    2. IEEE802.11a= k-2017: Enhancements for Transit Links Within Bridged Networks<= /o:p>
    3. IEEE802.11ax D3.0:= Enhancements for High Efficiency WLAN
    4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-= 1160-00-0wng-controlling-latency-in-802-11.pptx
    5. Wi-Fi= Alliance Wireless Protected Access 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-Medi= a Admission Control (WMM-AC)
    7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
    8. Wi-Fi Al= liance TimeSyncTM

     =

    Cheers -= -

    ganesh

     =

    ________________________= _______________________
    detnet mailing list
    detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet

    --_000_311BE885E0DA8D4BB369A037CF5B64A79B59055CORSMSX107amrcor_-- From nobody Mon Oct 22 15:17:34 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036F1128CB7 for ; Mon, 22 Oct 2018 15:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX1aPw8XHm1l for ; Mon, 22 Oct 2018 15:17:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 CE773126BED for ; Mon, 22 Oct 2018 15:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540246647; x=1542838647; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IgoJPLcbZIXgdiEVcWBpwuO9Qb32sGKSNggWb0cKJww=; b=SMKfXOTfOLeVw6eWZ0RjttJZUtnHABm0TDNqqRfixAqy3lYRvzlHkGsgnUTmqcfe xfYQs2mQo+AY74TrZikt/c2hT+1P/nIfXjdbNhrLtFuzwjC/XCLKrqq0+if1jRbt xFSwMLeOSofPIlIQTyk318cm8/tq1pEE3CWgnZ+bE4o=; X-AuditID: c1b4fb2d-b37ff70000003a27-1f-5bce4c77ce04 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.35.14887.77C4ECB5; Tue, 23 Oct 2018 00:17:27 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 00:17:26 +0200 Received: from [100.94.39.104] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.188) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 23 Oct 2018 00:17:26 +0200 References: <154024359504.13801.17286519055572490399.idtracker@ietfa.amsl.com> To: DetNet WG From: =?UTF-8?Q?J=c3=a1nos_Farkas?= X-Forwarded-Message-Id: <154024359504.13801.17286519055572490399.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 23 Oct 2018 00:17:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154024359504.13801.17286519055572490399.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BB01AF077E1F976D5078EB1D" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2J7tW65z7log7YmDovfn2azODB6LFny kymAMYrLJiU1J7MstUjfLoErY+OqZYwFM90rLjctZGtgbLHuYuTgkBAwkejfo9fFyMUhJHCU UWL13lssEM43RonTc6azQjhHGCU+/b/I1MXIySEsECRxbf1rVhBbSMBPomP3O7C4iIC8RGPv Z3YQm03AXuLupQ3MILaEQJTEnjerGEFsXqD44yUnwWpYBFQl7p/bCNYrKhAr8enKYmaIGkGJ kzOfsIDYnAL+EmcufwLrZRYIk3jyYgI7hC0ucevJfCaIG9QkPr19yD6BUXAWkvZZSFpmIWmB sC0kZs4/zwhhy0s0b53NDGFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkm RmDwH9zyW3cH4+rXjocYBTgYlXh4wy3ORQuxJpYVV+YeYpTgYFYS4V255Gy0EG9KYmVValF+ fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYzu0utzRZduPPm1LNzlTv9p rYVd2/ry1Rtbb06fZ/JBX91zqeqBLVN3Pah6d4aT/3K0b8npLe9tmva0mC1pct74NFFOxuhK eOvN+0peZa+uSF6V3eWisWK5iHFDnsX7p1vSNvkeOCp5gCd9b9OhuNnnHJZYmvjfj83am2M0 RWtKv5RKvhpv5GQlluKMREMt5qLiRAD4OsMgegIAAA== Archived-At: Subject: [Detnet] Fwd: New Version Notification for draft-ietf-detnet-architecture-09.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 22:17:33 -0000 --------------BB01AF077E1F976D5078EB1D Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, draft-ietf-detnet-architecture-09 is available: https://tools.ietf.org/html/draft-ietf-detnet-architecture-09 It implements the changes discussed in: https://www.ietf.org/mail-archive/web/detnet/current/msg01813.html https://www.ietf.org/mail-archive/web/detnet/current/msg01803.html https://www.ietf.org/mail-archive/web/detnet/current/msg01802.html https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html https://www.ietf.org/mail-archive/web/detnet/current/msg01790.html Best regards, Janos -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-detnet-architecture-09.txt Date: Mon, 22 Oct 2018 14:26:35 -0700 From: internet-drafts@ietf.org To: Balazs Varga , Norman Finn , Pascal Thubert , Balázs Varga , Janos Farkas , János Farkas A new version of I-D, draft-ietf-detnet-architecture-09.txt has been successfully submitted by János Farkas and posted to the IETF repository. Name: draft-ietf-detnet-architecture Revision: 09 Title: Deterministic Networking Architecture Document date: 2018-10-22 Group: detnet Pages: 42 URL: https://www.ietf.org/internet-drafts/draft-ietf-detnet-architecture-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ Htmlized: https://tools.ietf.org/html/draft-ietf-detnet-architecture-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-09 Abstract: This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). 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 --------------BB01AF077E1F976D5078EB1D Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,

    draft-ietf-detnet-architecture-09 is available: https://tools.ietf.org/html/draft-ietf-detnet-architecture-09
    It implements the changes discussed in:
    https://www.ietf.org/mail-archive/web/detnet/current/msg01813.html
    https://www.ietf.org/mail-archive/web/detnet/current/msg01803.html
    https://www.ietf.org/mail-archive/web/detnet/current/msg01802.html
    https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html
    https://www.ietf.org/mail-archive/web/detnet/current/msg01790.html

    Best regards,
    Janos


    -------- Forwarded Message --------
    Subject: New Version Notification for draft-ietf-detnet-architecture-09.txt
    Date: Mon, 22 Oct 2018 14:26:35 -0700
    From: internet-drafts@ietf.org
    To: Balazs Varga <balazs.a.varga@ericsson.com>, Norman Finn <norman.finn@mail01.huawei.com>, Pascal Thubert <pthubert@cisco.com>, Balázs Varga <balazs.a.varga@ericsson.com>, Janos Farkas <janos.farkas@ericsson.com>, János Farkas <janos.farkas@ericsson.com>



    A new version of I-D, draft-ietf-detnet-architecture-09.txt
    has been successfully submitted by János Farkas and posted to the
    IETF repository.

    Name: draft-ietf-detnet-architecture
    Revision: 09
    Title: Deterministic Networking Architecture
    Document date: 2018-10-22
    Group: detnet
    Pages: 42
    URL: https://www.ietf.org/internet-drafts/draft-ietf-detnet-architecture-09.txt
    Status: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
    Htmlized: https://tools.ietf.org/html/draft-ietf-detnet-architecture-09
    Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture
    Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-09

    Abstract:
    This document provides the overall architecture for Deterministic
    Networking (DetNet), which provides a capability to carry specified
    unicast or multicast data flows for real-time applications with
    extremely low data loss rates and bounded latency within a network
    domain. Techniques used include: 1) reserving data plane resources
    for individual (or aggregated) DetNet flows in some or all of the
    intermediate nodes along the path of the flow; 2) providing explicit
    routes for DetNet flows that do not immediately change with the
    network topology; and 3) distributing data from DetNet flow packets
    over time and/or space to ensure delivery of each packet's data in
    spite of the loss of a path. DetNet operates at the IP layer and
    delivers service over sub-network technologies such as MPLS and IEEE
    802.1 Time-Sensitive Networking (TSN).



    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

    --------------BB01AF077E1F976D5078EB1D-- From nobody Mon Oct 22 15:22:28 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EF812D4F1 for ; Mon, 22 Oct 2018 15:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx4tKoaNqYvt for ; Mon, 22 Oct 2018 15:22:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 28A5D126BED for ; Mon, 22 Oct 2018 15:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540246940; x=1542838940; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EYnXJ8OnKvUfgiYkxD5nkENZcwKSbo9uFrhYLNTh7RA=; b=H5LfaNY6ojuu3jeUYzBGaiofaftlRqJWEBj1bpE4manN0gvZ16wx9S5GwL9acVka ure699Fc/7g2E+YtLe53MDGW59PG9gFRGcvbn85WLzP5Q5icC6IWOZbFWoZpMopk xuJnbvCks9pJOjJZWlZhUGB0Rduzr6uiHsK9Y1O+0ak=; X-AuditID: c1b4fb3a-171ff700000012ff-03-5bce4d9c6229 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.7A.04863.C9D4ECB5; Tue, 23 Oct 2018 00:22:20 +0200 (CEST) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESBMB505.ericsson.se (153.88.183.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 00:21:21 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 23 Oct 2018 00:21:21 +0200 Received: from [100.94.39.104] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 23 Oct 2018 00:21:21 +0200 To: References: <2d6d8f85-a283-eb43-6bea-323b7af661f2@ericsson.com> <3DF0466E9510274382F5B74499ACD6F8D38234@DFWPML704-CHM.exmail.huawei.com> <37d1fcb7-110c-5ec9-99b6-3269cc5ac76d@labn.net> <3DF0466E9510274382F5B74499ACD6F8D38291@DFWPML704-CHM.exmail.huawei.com> <3719f94c-55fa-1f7f-316d-e2a62f2a3e56@labn.net> <3DF0466E9510274382F5B74499ACD6F8D38506@DFWPML704-CHM.exmail.huawei.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Tue, 23 Oct 2018 00:21:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM2J7me4c33PRBoc7FSx+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM6Xk9gKdhZVzLu7mrWBcXZsFyMnh4SAicT8FfvYuhi5OIQE jjJKrF3xnhEkISTwjVFizlIRiASQvb/hEwuEc4RRYuax6UwgVcIC9hKf560H6xAREJU4MaWT HaJoF7PE6bsHWUASbEBFdy9tYAaxeYHsze9awBpYBFQlJh/fwApiiwrESny6shiqRlDi5Mwn YL2cAg4S847fAarn4GAG6n2wtQwkzCwgL9G8dTYzhC0ucevJfCaIq9Uk3jfcYZzAKDQLyaRZ CN2zkHTPQtK9gJFlFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgMB/c8ttqB+PB546HGAU4 GJV4eA9YnIsWYk0sK67MPcQowcGsJMK7csnZaCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8TmkW UUIC6YklqdmpqQWpRTBZJg5OqQZGvtmcH3iW5Jd4WZi/ksxZ+Lea18Wj+Wrx7Ru/Z7Kd7OSS YpFdmCZ71/j5re2mdV9yK5i/px/obsotmeX2s3e+ZOXBS6HFL0VfsAq6aG3XfOfj2PTmWNLB 2S37g63dFm64WxVeXce+qEfnwrUHiwQqK4qL/Tyq/9zjbrtYLXtuyXzbqtoFqxWUWIozEg21 mIuKEwG4hosdYgIAAA== Archived-At: Subject: Re: [Detnet] updating the flow information model draft X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 22:22:27 -0000 Hi, A new revision (02) of the  flow information model draft is available: https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02. As a contribution to the WG, it has been updated along the liens below. (plus a few nits related to references addressed) Best regards, Janos On 10/17/2018 8:17 PM, János Farkas wrote: > Hi, > > Coming back to this. > > In order delivery is one of the service parameters. As such, it > reflects how much out of order delivery the application running in the > end system can tolerate. If it is zero, then the application cannot > tolerate misordering at all. A non-zero value indicates how many > packets received out of order can be handled by the application. > > Violation of service parameters implies that the application cannot > handle (drops) the packets received. For instance, if the maximum > tolerable end to end latency is violated, then the packet arrives too > late for the application to be able to process. Similarly, if > misordering is violated, the application cannot process the packet. > > The service parameters are input to the DetNet network, which only > accepts a request to establish a new flow if the network can meet the > service parameters, otherwise rejects the request. > > > The comments received on the document in this discussion are actually > on Section 5.2 Service parameters, e.g., delay and delay variation > parameters, misordering etc. > > In order to make progress, as a contribution to the WG, Section 5.2 > will be updated and a new revision of the draft will be submitted by > the submission deadline to address the comments to our best. The WG > discussion can be then continued taking it as an input, and fruther > updates will be made based on the discussions. > > Best regards, > Janos > > > On 7/20/2018 8:50 PM, Norman Finn wrote: >> Lou:  Perhaps you could expand on your "different technologies" comment. >> >> Short explanation: >> >> The amount of misordering, and hence the resources (including choice >> of algorithm) required to re-order packets, is known the the network, >> not the listener.  The application already specifies a min/max >> latency in order to bound his receive buffer requirements.  I would >> favor 1) adding the ability of the network to report the worst-case >> misordering, 2) keeping the binary "application can/cannot tolerate >> misordering" parameter, 3) having a binary "network can/cannot ensure >> ordering". >> >> Long explanation: >> >> I stand by my arguments about 5/100 vs. no/yes.  If it's possible for >> the network to misorder packets, the resources required to reorder >> them, given the path and the bandwidth/packet size spec for the flow, >> is certainly known to the network, but probably not to the >> application.  Reporting the worst-case misordering to the application >> would be useful.  But, allowing the application to specify "5" when >> the network is likely to deliver 100 simply complicates the >> reservation process.  Of course, it's easy to compare the >> application's requirement to the network's number, but that is not >> the issue..  Having the parameter merely begs a pile of questions for >> the application: >> >>    - What number do I specify to maximize my chances of success? >>    - How many buffers might the network want me to have? >>    - Does that mean I need to know the topology?  Line lengths? >>    - How do I compare my need for receiver buffers to my other needs >> for memory space? >>    - Which device, me or the edge node, would find it easier/cheaper >> to increase the number of reordering buffers? >>    - Does the edge node even have reordering capability? >>    - Will the network configuration produce misordering, at all? >> >> My claim is that most of these questions are settled much more easily >> with the current yes/no requirement plus a report from the network on >> worst-case misordering, and we can see a path for >> negotiating/refusing/remaking the reservation.  I further claim that >> turning the yes/no into a number will complicate the process without >> bringing anything significant to the range of results available. >> >> For example, are we suggesting that the network could buffer just >> enough to reduce the 100 to 5?  I don't think it worthwhile to >> support the (I think infrequent) case where the listener's >> capabilities to handle some misordering would make a significant >> difference in the resources required for the network to reduce >> misordering to that level, but not eliminate it. >> >> I would rather not add a "misordering limit" parameter.  It will >> inevitably generate requirements for the control protocols support >> it, and I claim there is no clear use for that information.  Yes/no >> parameters for network and application capabilities, and a report on >> the possible misordering number from the network, is sufficient. >> >> -- Norm >> >> ________________________________________ >> From: detnet [detnet-bounces@ietf.org] on behalf of Lou Berger >> [lberger@labn.net] >> Sent: Thursday, July 19, 2018 7:27 AM >> To: Norman Finn; János Farkas; DetNet WG >> Subject: Re: [Detnet] updating the flow information model draft >> >> On 7/17/2018 7:01 PM, Norman Finn wrote: >>> Binary "reordering is/not acceptable" I can see some use for.  It's >>> the numbers that I don't know how to deal with. >> There are different technology related/specific solutions here. The >> fundamental point  is to allow for it in the architecture and modeling. >> >> Lou >> >>> -- Norm >>> >>> ________________________________________ >>> From: Lou Berger [lberger@labn.net] >>> Sent: Tuesday, July 17, 2018 1:39 PM >>> To: Norman Finn; János Farkas; DetNet WG >>> Subject: Re: [Detnet] updating the flow information model draft >>> >>> Norm, >>> >>>        In the IP case, worst-case packet misordering can also impact >>> multi-path forwarding behavior.  An implementation (IP or MPLS data >>> planes) can always satisfy a non-zero reordering requirement with paths >>> that don't reorder. >>> >>> Lou >>> >>> On 7/17/2018 4:33 PM, Norman Finn wrote: >>>> I have a problem with the idea of the user expressing a requirement >>>> for worst-case packet misordering.  My problem is that I'm not sure >>>> what the network can do with that information. >>>> >>>> Either you are using PR/PE or not.  If you are NOT using PR/PE, >>>> then you are presumably using some routing/bridging protocol to >>>> heal the network after a failure.  The out-of-order problem will >>>> occur when, some time after a failure caused a loss of packets and >>>> the use of a long path A-->B, healing the failure and thus opening >>>> a shorter path causes early deliveries and hence out-of-order >>>> packets.  In order to predict the worst-case scenario for >>>> out-of-order delivery, so that the network can pass or fail the >>>> reservation request, one would have to determine the worst-case >>>> packets in flight for the longest path A-->B after multiple >>>> failures in the network, and then look at the fastest possible >>>> healing to the shortest possible path to get the worst-case >>>> out-of-order difference.  It might be possible to calculate this in >>>> a single-ring topology, but in a more complex topology, I have my >>>> doubts that it can be performed reliably.  Without a reliable way >>>> to calculate the worst case, the user's misordering requirements >>>> are irrelevant. >>>> >>>> If you ARE using PR/PE, then either you are using a bandwidth >>>> reservation or you are not.  If you are NOT using a bandwidth >>>> reservation, then all bets are off.  It is difficult to predict the >>>> worst-case difference in packets-in-flight for the two paths, and >>>> hence the worst-case sequence delta.  With nothing to compare the >>>> user's misording requirements to, the requirements are irrelevant. >>>> >>>> If you ARE using PR/PE and you ARE using bandwidth reservations, >>>> then as you are making the reservations, you can determine the >>>> worst-case time differential on the different paths before a merge >>>> point, you know the maximum data rates, and you can determine the >>>> buffer space needed to put the packets in order.    If the merge >>>> system has insufficient buffer space to accomplish the merge, then >>>> the user's misordering requirements are irrelevant.  That buffer >>>> space is required in order to both a) prevent overloading the >>>> bandwidth reservation of the merged stream and b) not drop packets >>>> due to congestion of the merge port, whether or not in-order >>>> delivery is desired.    If the merge buffer space is available, >>>> then there is no problem with full in-order delivery, and the >>>> user's misordering requirements are irrelevant. >>>> >>>> Finally, what do we imagine the network to do other than refuse the >>>> reservation in the very few cases where this is possible?  If it >>>> discards packets with larger differences, then you are doing >>>> nothing that the receiver cannot do for itself.  You also are >>>> taking on the problem of knowing when to resume transmission, >>>> detecting when the sequence number is reset, etc.  These are not >>>> trivial problems, and wind up needing help from the sequencing >>>> source.  This is better left to the application to sort out. >>>> >>>> To sum up, I think that user requirements are much better >>>> expressed, and the network's ability to conform to those >>>> requirements are better measured, in terms of best- and worst-case >>>> latency and latency variation. >>>> >>>> -- Norm >>>> ________________________________________ >>>> From: detnet [detnet-bounces@ietf.org] on behalf of János Farkas >>>> [janos.farkas@ericsson.com] >>>> Sent: Wednesday, July 04, 2018 11:12 AM >>>> To: DetNet WG >>>> Subject: [Detnet] updating the flow information model draft >>>> >>>> Dear all, >>>> >>>> I think the flow information model draft needs some updates to >>>> bring it >>>> in-line with the recent developments in the WG. I’d like to have WG >>>> discussion on the list and at IETF 102 before making any updates. >>>> >>>> 1, Current version of draft-ietf-detnet-flow-information-model-01 >>>> >>>> Section 5.2 Service Parameters includes in order delivery, which is a >>>> binary value in draft-ietf-detnet-flow-information-model-01 >>>> depending on >>>> whether or not in order delivery is required for the given service. >>>> This >>>> requires refinements based on the developments we had in >>>> draft-ietf-detnet-architecture-06. >>>> >>>> The refinement would involve introducing a numerical service >>>> parameter, >>>> which could be called “MisorderingTolerance” or alike to replace the >>>> current binary parameter. >>>> >>>> >>>> 2, Recent updates of draft-ietf-detnet-architecture-06 >>>> >>>> draft-ietf-detnet-architecture-06 provides a finer grade DetNet QoS >>>> parameter by introducing : >>>> >>>> Section 3.1: >>>> “o An upper bound on out-of-order packet delivery. It is worth >>>> noting that some DetNet applications are unable to tolerate any >>>> out-of-order delivery.” >>>> >>>> Section 3.2.2.1. In-Order Delivery: >>>> “Out-of-order packet delivery can be a side effect of service >>>> protection. Packets delivered out-of-order impact the amount of >>>> buffering needed at the destination to properly process the received >>>> data. Such packets also influence the jitter of a flow. The DetNet >>>> service includes maximum allowed misordering as a constraint. Zero >>>> misordering would be a valid service constraint to reflect that the >>>> end system(s) of the flow cannot tolerate any out-of-order delivery. >>>> Service protection may provide a mechanism to support in-order >>>> delivery.” >>>> >>>> The architecture document does not provide further details on purpose. >>>> It is the job of the flow information model draft to go into the >>>> details. >>>> >>>> >>>> 3, “MisorderingTolerance” related thoughts >>>> >>>> The DetNet QoS requirements are correlated to each other. For >>>> instance, >>>> a packet received with a too big delay or jitter is practically a lost >>>> packet for the application. As for misordering, it is related, >>>> e.g., to >>>> jitter as explained in the architecture document. (Well, misordering >>>> above the tolerable limit can be considered loss.) The correlations >>>> can >>>> be taken into account when defining the QoS requirements for a DetNet >>>> service, and also when providing the given DetNet service by the >>>> DetNet >>>> network. >>>> >>>> Actually, misordering and jitter can be decreased with a similar tool, >>>> e.g., a playout buffer. It is a bit more complex for reordering and >>>> requires sequencing information carried in the packets. >>>> >>>> I see two approaches to express maximum allowed misordering: >>>> a) number of misordered packets >>>> b) time >>>> >>>> Both of them have their pros and cons. >>>> >>>> I propose to follow a) for multiple reasons. >>>> >>>> Maximum allowed/tolerable misordering could be defined along: >>>> “maximum number of misordered packets, e.g., a delta of sequence >>>> numbers >>>> between the highest sequence number that was just received and the >>>> lowest sequence that is acceptable” >>>> (credit goes to Pascal for initial wording!) >>>> >>>> This is a relatively simple definition and also simple to measure, >>>> detect, and verify. Furthermore, timing requirement is already defined >>>> as part of the jitter requirement, no need to duplicate. In addition, >>>> timing may not be as important as the order of packets for some >>>> applications. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Janos >>>> >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>> >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>> >>> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 23 01:16:18 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6F130F69 for ; Tue, 23 Oct 2018 01:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.969 X-Spam-Level: X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5EgGeF6vFEK for ; Tue, 23 Oct 2018 01:16:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35481130DC2 for ; Tue, 23 Oct 2018 01:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60177; q=dns/txt; s=iport; t=1540282571; x=1541492171; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CGEVfTyDLaU/w4m35uE+ENDx8anN5H5O6t8noDRCscA=; b=ZBFTBwAA4/olSl4DtSRMSooc3EmTyP3Imhs9wZwG6pQsRMB4QfTOanws Zd03H52opRvJoJhInYtSPeI+AFdlApv7eXjC/u1h2Cw0ZxrO+8zRKIjWy s+ZCHjrcSr8adNFZxu+f9vlSCI/LhvheXY7qx9Z2XVGo0sCyciHulx7Wg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAADs185b/4ENJK1ZChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMDAQEBAQsBgQ1NKmZ/KAqYIIINeogAjhsUgWMDCwEBGAE?= =?us-ascii?q?MhAFGAoUmITYLDQEDAQECAQECbRwMhToBAQEBAwEBGAESQQICBxACAQgRAQM?= =?us-ascii?q?BAQ4ICwEGByEGCxQDBggCBAENBQgTgweBHUwDFQ+nGIQsAQMDAYNLDYITBYt?= =?us-ascii?q?hF4FBP4ERgl0HLoFBgRVFAQGBHBowIgUKCYUbAohLEhcnA0iEUYYSiTMmLgk?= =?us-ascii?q?ChmGGbIMdH4FShHSJaodEhRh5hi6CQQIRFIEmJAQtgVVwFTuCbAmCHRcSawE?= =?us-ascii?q?DAYdahT5vAQGMWoEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,415,1534809600"; d="scan'208,217";a="460016010" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 08:16:08 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9N8G7Qj022743 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 08:16:07 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 03:16:07 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 03:16:07 -0500 From: "Pascal Thubert (pthubert)" To: Norman Finn , "Venkatesan, Ganesh" , "Andrew G. Malis" CC: detnet WG , "thomas.watteyne@analog.com" Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAgQk0AAAsiJYAAAYjMgAAAsqoAAAEzQwAADFWOAA== Date: Tue, 23 Oct 2018 08:16:01 +0000 Deferred-Delivery: Tue, 23 Oct 2018 08:15:36 +0000 Message-ID: <6f879f8e625a424eb5ebf858d076658a@XCH-RCD-001.cisco.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com>, <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.205.35] Content-Type: multipart/alternative; boundary="_000_6f879f8e625a424eb5ebf858d076658aXCHRCD001ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 08:16:17 -0000 --_000_6f879f8e625a424eb5ebf858d076658aXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree 100% with Norm below. Wireless can apply to use cases with a whole different range of requirement= s and with a whole different set of techniques. I participated to DetNet wi= th wireless in mind, and realized that the interest of the group are largel= y related to wired TSN. Wireless needs something different, and probably the term "deterministic" s= hould be excluded in favor of something like "predictable and available wir= eless" (PAW), be it just to avoid grinding teeth from all parties. I'd be happy to have a BAR BoF during IETF 103 or at an evening dinner dur= ing the week end before IEEE to discuss that. Cheers, Pascal From: detnet On Behalf Of Norman Finn Sent: lundi 22 octobre 2018 23:12 To: Venkatesan, Ganesh ; Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 I think I was misunderstanding your wishes, Ganesh. Sorry. I thought you = wanted to add 802.11 to the core of DetNet and/or to the architecture. Now= I see that you are talking about a use case. I'd have to look more at the= details to have an opinion. Given the variability of 802.11 delivery, can you comment about how the dif= ference between DetNet service and typical weighted priorities would be cri= tical to the success of your envisioned applications? I have heard argumen= ts about needing DetNet/TSN to enable timed deliveries. -- Norm ________________________________ From: Venkatesan, Ganesh [ganesh.venkatesan@intel.com] Sent: Monday, October 22, 2018 1:37 PM To: Norman Finn; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Norm: Not all Use Cases in draft-ietf-detnet-use-cases-19 require a reliability o= f 7 or 8 nines in reliability. For instance, section 3 Electrical Utilities= has a requirement of 0.1-1% packet loss (3.1.1.1.4).. Do you think a manag= ed IEEE802.11 network would not meet that requirement? I would agree with your assessment (cannot achieve reliability to 7 or 8 ni= nes) if we are exclusively focusing on IEEE802.11 only networks. The propos= al is to consider a 802.1 core DetNet with IEEE802.11 links at the last (or= first) hop, for Use Cases where a managed IEEE802.11 network (where the wi= reless configuration takes into account the need for low latency and high r= eliability for TSN traffic). Cheers -- ganesh From: Norman Finn Sent: Monday, October 22, 2018 4:18 PM To: Venkatesan, Ganesh ; Andrew G.. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= 'IEEE TSN as a layer2 for DetNet'. Given that the TSN work is done in IEEE= 802.1 TSN, do you perceive IEEE802.11 as 'IEEE TSN as a layer2 for DetNet'?= And would that be the perception of the rest of the IETF DetNet membership= ? If your answer is Yes to both the questions, then I would agree (and if w= e delete the reference in section 5.1.1 where the current draft calls out I= EEE802.11 (WiFi) as unsuited for DetNet) that "we don't need to include ex= plicit references to 802.11", but carefully call out in other pertinent IET= F DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requireme= nts explicitly. Cheers -- ganesh From: Andrew G. Malis > Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path... Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers ("making AVB= /TSN-type deterministic performance available from layer-3 applications" or= "connecting two AVB/TSN LANs or 'islands' together through a standard rout= er") should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE8= 02.11 is already supported for time synchronization, stream identification = and reservation and additional TSN capabilities are under development (supp= ort for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 - 10 millisecond latencies over = the wireless hop) is achievable in a managed 802.11 network by leveraging c= urrent TSN capabilities over 802.11, such as time synchronization, stream i= dentification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration - there are aspects of the wireless netw= ork (or the wireless hop from a wired/wireless bridge to a wireless endpoin= t) that will have to be defined. For instance, the controller that does the= central administration may send the desired configuration to the wired/wir= eless bridge (the wireless part in this bridge is the AP function) where it= gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_6f879f8e625a424eb5ebf858d076658aXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I agree 100% with Norm= below.

     

    Wireless can apply to = use cases with a whole different range of requirements and with a whole dif= ferent set of techniques. I participated to DetNet with wireless in mind, a= nd realized that the interest of the group are largely related to wired TSN.

     

    Wireless needs somethi= ng different, and probably the term “deterministic” should be e= xcluded in favor of something like “predictable and available wireles= s” (PAW), be it just to avoid grinding teeth from all parties.

     

    I’d  be hap= py to have a BAR BoF during IETF 103 or at an evening dinner during the wee= k end before IEEE to discuss that.

     

    Cheers,

     

    Pascal

     

    From: detnet <detnet-bounces@ietf.org> = On Behalf Of Norman Finn
    Sent: lundi 22 octobre 2018 23:12
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G= . Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    I think I was misunderstanding your wish= es, Ganesh.  Sorry.  I thought you wanted to add 802.11 to the co= re of DetNet and/or to the architecture.  Now I see that you are talking about a use case.  I'd have to look more at the detai= ls to have an opinion.

     

    Given the variability of 802.11 delivery= , can you comment about how the difference between DetNet service and typic= al weighted priorities would be critical to the success of your envisioned applications?  I have heard arguments abou= t needing DetNet/TSN to enable timed deliveries.

     

    -- Norm

     

    From:<= /span> Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 1:37 PM
    To: Norman Finn; Andrew G. Malis
    Cc: detnet WG
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Norm:

     =

    Not all Use Cases in dra= ft-ietf-detnet-use-cases-19 require a reliability of 7 or 8 nines in reliab= ility. For instance, section 3 Electrical Utilities has a requirement of 0.= 1-1% packet loss (3.1.1.1.4).. Do you think a managed IEEE802.11 network would not meet that requirement?

     =

    I would agree with your = assessment (cannot achieve reliability to 7 or 8 nines) if we are exclusive= ly focusing on IEEE802.11 only networks. The proposal is to consider a 802.= 1 core DetNet with IEEE802.11 links at the last (or first) hop, for Use Cases where a managed IEEE802.11 netwo= rk (where the wireless configuration takes into account the need for low la= tency and high reliability for TSN traffic).

     =

    Cheers -= -

    ganesh

     =

    From: Norman Finn &= lt;norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 4:18 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G= .. Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    There is a strong desire from a number o= f application domains for deterministic wireless networks.  This desir= e has generated projects such as the 6TiSCH working group in the WPAN world.  There are things that one can do to greatly= improve the reliability and timeliness of 802.11 networks.  I was the= primary instigator of 802.11ak, that make it possible to have an 802.11 li= nk in the middle of a wired network; the wired robot attached to a wired network on a factory floor via Wi-Fi was one of = the examples I used to promote the idea.=

     

    Having said that ...

     

    In the wired world, simply eliminating c= ongestion loss gets us to 7 or 8 nines in reliability.  Dual pathing g= ets us to 10 or more nines.  And, these are things that we know how to accomplish, today.<= o:p>

     

    In the wireless world, signal interferen= ce can easily drop you to 3 nines.  Deterministic wireless needs diffe= rent techniques for achieving reliability -- for example, spreading the data out in time to avoid interference, and hop-by-hop ACK/r= etransmission.  These are not required in the wired world.  This = leads me to talk about the (latency)*(loss rate) product.  That is, in= wireless, it is meaningful to have a direct tradeoff between latency and loss rate, to give room for retransmissions and time s= preading.  That product is orders of magnitude different between the w= ired and wireless cases, and that means that the applications that can use = the service have orders of magnitude different requirements.

     

    I would fully support the creation of a = Deterministic Wireless WG.  I believe that such a group and DetNet wou= ld complement each others' efforts.  The goals are similar, but the solutions are sufficiently different that I would not wan= t wireless support to be a goal of DetNet.

     

    -- Norm

     

    From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     =

    Reading the current draf= t, specifically section 5.1.1, I get the impression that the current Use Ca= se document does not consider IEEE802.11 as part of ‘IEEE TSN as a la= yer2 for DetNet’. Given that the TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as ‘IEEE TSN as= a layer2 for DetNet’? And would that be the perception of the rest o= f the IETF DetNet membership? If your answer is Yes to both the questions, = then I would agree (and if we delete the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as un= suited for DetNet)  that “we don’t need to include explici= t references to 802.11”, but carefully call out in other pertinent IE= TF DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requirements explicitly.

     =

    Cheers -= -

    ganesh

     =

    From: Andrew G. Malis <agmalis@gmail.com>
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel..com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    Ganesh,

     =

    For those of us that don= 't attend IEEE, can you fill us in on the relationship between 801.11 and T= SN? As the DetNet documents already refer (in many places) to IEEE TSN as a= layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we = don't need to include explicit references to 802.11. Just a thought.

     =

    Thanks,

    Andy

     =

     =

    On Sun, Oct 21, 2018 at = 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.com> wrote:=

    Hello DetNet members:

     =

    We proposed adding IEEE8= 02.11 as a L2 media for DetNet. Based on our experience with IEEE802.11 in = managed deployments, we believe that 802.11 links can meet DetNet requireme= nts described in the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and = in other Topic Interest Groups within IEEE802.11 Working Group that renders= 802.11 as a versatile L2 media for DetNet.

     =

    Please let me know if yo= u have comments/questions on this submission:

     =

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ...

     

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     =

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

     =

    Thus far IEEE 802.11 has been the only= wireless media technology that has already included support for some of th= e 802.1 TSN capabilities required to address the use cases described in this document. The IEEE 802.11 working group has be= en working in collaboration with the IEEE 802.1 group for several years ext= ending 802.1 features over 802.11. Therefore, in the Use Cases described in= this document, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under cons= ideration is a wired/wireless network with the first and/or the last nodes = being IEEE802.11 hops and the rest of the network is wired. As with any wir= eless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between laten= cy and reliability guarantees must be considered as well as managed deploym= ent requirements.

    The 802.1 and 802.11 feature set that is alrea= dy part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificatio= ns to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNe= t described in this document.=

     =

    The following sub-sections are analogues of co= rresponding subsections in section-11. The intent is to demonstrate how wel= l IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     =

    x.1.1 Extension to Ethernet and 802.1 TSN

     =

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     =

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate = L2 and L3 layers (“making AVB/TSN-type deterministic performance avai= lable from layer-3 applications” or “connecting two AVB/TSN LANs or ‘islands’ together through a standard router&#= 8221;) should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEE= E802.11 is already supported for time synchronization, stream identificatio= n and reservation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     =

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

     =

    x.1.6 Guaranteed End-to-End Delivery

    Guaranteed e2e delivery is achieved in= DetNet by constraining the network (the network is not the open Internet b= ut a constrained/managed network).<= /o:p>

    With 802.11, similar constraints can be put in= place in a managed deployment. For instance, multiple channels and Basic S= ervice Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     =

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     =

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify= and prioritize time-sensitive operational traffic. The prioritization (and= the resulting improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even= more effective with high efficiency features from IEEE802.11ax, IEEE802.1Q= bv over IEEE802.11, etc.

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     =

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     =

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     =

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admissio= n Control prevents over-subscribing and minimizes collisions, and where QoS= provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     =

    x.3.2 Low Latency

    Low latency requirement depends on the= Use Case in question. There is some trade-off in the low latency requireme= nt for the convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed f= or the specific situation within the Use Case.

    However, low latencies [Reference 18-1= 160r0] to meet the requirements of a variety of Use Cases (pro AV, synchron= ized multi-channel audio, mobile robotics, repetitive cyclic control systems (1 – 10 millisecond latencies over the wirele= ss hop) is achievable in a managed 802.11 network by leveraging current TSN= capabilities over 802.11, such as time synchronization, stream identificat= ion and time-aware shaping..<= /span>

    x.5 Security

    WFA WPA3 provides robust security both for man= agement and data packets. In addition, WFA Easy Connect provides for robust= security while supporting easy onboarding of headless devices into the network.=

     =

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration – the= re are aspects of the wireless network (or the wireless hop from a wired/wi= reless bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administ= ration may send the desired configuration to the wired/wireless bridge (the= wireless part in this bridge is the AP function) where it gets converted i= nto parameters that are 802.11-specific.=

     =

    x.6.2 Standardized Data Flow Information Model= s

    Co-ordination between IETF DetNet and IEEE802.= 11 Working Groups will be required to ensure that this requirement is met w= hen DetNet operates over IEEE802.11 links.

     =

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in= all wireless networks, specifically indoors). Need to research this furthe= r.

     =

    References:

    1. IEEE802.11-2016: Wireless LA= N Medium Access Control (MAC) and Physical Layer (PHY) Specifications
    2. IEEE802.11a= k-2017: Enhancements for Transit Links Within Bridged Networks<= /o:p>
    3. IEEE802.11ax D3.0:= Enhancements for High Efficiency WLAN
    4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-= 1160-00-0wng-controlling-latency-in-802-11.pptx
    5. Wi-Fi= Alliance Wireless Protected Access 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-Medi= a Admission Control (WMM-AC)
    7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
    8. Wi-Fi Al= liance TimeSyncTM

     =

    Cheers -= -

    ganesh

     =

    ________________________= _______________________
    detnet mailing list
    detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet

    --_000_6f879f8e625a424eb5ebf858d076658aXCHRCD001ciscocom_-- From nobody Tue Oct 23 02:42:01 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122CD130EDD for ; Tue, 23 Oct 2018 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdG3GvkFyFN8 for ; Tue, 23 Oct 2018 02:41:56 -0700 (PDT) Received: from know-smtprelay-omc-3.server.virginmedia.net (know-smtprelay-omc-3.server.virginmedia.net [80.0.253.67]) (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 8D8AC130EEA for ; Tue, 23 Oct 2018 02:41:53 -0700 (PDT) Received: from [192.168.1.33] ([79.64.221.174]) by cmsmtp with ESMTPA id EtCAgFoL3btAcEtCBgDSY0; Tue, 23 Oct 2018 10:41:51 +0100 X-Originating-IP: [79.64.221.174] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=QvlwI26d c=1 sm=1 tr=0 a=tSXTDYfEbJ8U9z3iCe1Xaw==:117 a=tSXTDYfEbJ8U9z3iCe1Xaw==:17 a=N659UExz7-8A:10 a=m9GjrRzhAAAA:8 a=le6d79QuAAAA:8 a=3CDRvgL2xrVxo1Kg7YwA:9 a=pILNOxqGKmIA:10 a=UUiqWKL9VJ8mk3D6_09B:22 a=QbAMNLWdp4a7deKPGBBn:22 To: detnet@ietf.org References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> From: John Grant Message-ID: <91fc7642-cc76-870a-dfb5-cb6f4fe55076@ninetiles.com> Date: Tue, 23 Oct 2018 10:42:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfGEUl5G+vG7Y8AgEA+GZtXOqBB/tLNlnYhYYEpQUygeJhEpE//4E/zZUTyOhli19xqkpSoZWgb1nlyywT0vwMWDXkltYPXDL4XQ0fNdMP4sz89vQeexQ ElgDMXHI49TEK6ZcgD6keDJH2aa8RlHHAhi6y1D4gejY34cA9/yuJuqr Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 09:42:00 -0000 On 22/10/2018 21:17, Norman Finn wrote: > I would fully support the creation of a Deterministic Wireless WG. I > believe that such a group and DetNet would complement each others' > efforts.  The goals are similar, but the solutions are sufficiently > different that I would not want wireless support to be a goal of DetNet. This is something that also needs to be addressed for cellular radio, which has to live with the same laws of physics. Currently the emphasis in 5G mobile is on eMBB (enhanced mobile broadband), but URLLC (ultra-reliable low latency) is also promised. The only work on it I'm aware of is reported at https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2018/180819_NGMN_5G_Ext_Req_TF_D2_2_v2.0.pdf -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Tue Oct 23 03:47:47 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B24130E04 for ; Tue, 23 Oct 2018 03:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjjTw7OWnRuN for ; Tue, 23 Oct 2018 03:47:43 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C03130E02 for ; Tue, 23 Oct 2018 03:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1540291662; x=1541501262; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IpUb1puz3BQqWUJtLm2huRdh5+NurzwLVYgs4phpoiQ=; b=T3/uFMphacUd0IaN7R1o3CemhhCltegNG5swswlOBXAAaybEiFryuGJU 8O391PVApbvf3HCfng4At2vb8RFKPnvCDN5WEyo296Lrhb6eaedJxV3g8 z/kOqlUBCTKAzK5VKIm+FLevJeqFJJZLqhqXBBzXvUBNO9+fNdD6jHN+R s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABg+85b/51dJa1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggRmfygKmCGCDZcVgXoLAQEYC4QDRgK?= =?us-ascii?q?FKCE2Cw0BAwEBAgEBAm0cDIU6AQEBAQMBAVMZFwQCAQgOAwQBAQEuJwsdCAE?= =?us-ascii?q?BBAESCBODB4IBD6cohCwBhXeLYReBQT+DdS6BQYFaAQGHOwKPDY9DCQKGYYo?= =?us-ascii?q?JH4FShHSJaoxciWgCERSBJiQDLoFVcBU7gjgBAQExCYJGgzaFFIU+bwaMVoE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.54,415,1534809600"; d="scan'208";a="190508475" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 10:47:42 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w9NAlfFH010365 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 10:47:42 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 05:47:41 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 05:47:41 -0500 From: "Pascal Thubert (pthubert)" To: John Grant , "detnet@ietf.org" Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAgQk0AAAsiJYAAAYjMgAAcFtoAAAko05A= Date: Tue, 23 Oct 2018 10:47:30 +0000 Deferred-Delivery: Tue, 23 Oct 2018 10:21:45 +0000 Message-ID: References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com> <91fc7642-cc76-870a-dfb5-cb6f4fe55076@ninetiles.com> In-Reply-To: <91fc7642-cc76-870a-dfb5-cb6f4fe55076@ninetiles.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.82.82] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 10:47:45 -0000 OK, cool then. Let's talk! I created a doodle for a PAW bar Bof see when we could meet; https://doodl= e.com/poll/ikewr3wcztiztppx=20 Please enter if you have a matching availability Cheers, Pascal > -----Original Message----- > From: detnet On Behalf Of John Grant > Sent: mardi 23 octobre 2018 11:42 > To: detnet@ietf.org > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaf= t- > ietf-detnet-use-cases-19 >=20 > On 22/10/2018 21:17, Norman Finn wrote: > > I would fully support the creation of a Deterministic Wireless WG. I > > believe that such a group and DetNet would complement each others' > > efforts.=A0 The goals are similar, but the solutions are sufficiently > > different that I would not want wireless support to be a goal of DetNet= . > This is something that also needs to be addressed for cellular radio, whi= ch has > to live with the same laws of physics. Currently the emphasis in 5G mobil= e is > on eMBB (enhanced mobile broadband), but URLLC (ultra-reliable low latenc= y) > is also promised. The only work on it I'm aware of is reported at > https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2018/ > 180819_NGMN_5G_Ext_Req_TF_D2_2_v2.0.pdf >=20 > -- > John Grant > Nine Tiles, Cambridge, England > +44 1223 862599 and +44 1223 511455 > http://www.ninetiles.com >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Oct 23 04:18:52 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603F4130E77; Tue, 23 Oct 2018 04:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.994 X-Spam-Level: X-Spam-Status: No, score=-12.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, SUBJ_ALL_CAPS=1.506, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cms2eLs0KYHR; Tue, 23 Oct 2018 04:18:43 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5505130E02; Tue, 23 Oct 2018 04:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3370; q=dns/txt; s=iport; t=1540293523; x=1541503123; h=from:to:cc:subject:date:message-id:mime-version; bh=IJXn8xZDSUZ1+prjeU5rPg6nhEreqdgYEdc1gARfkrk=; b=enO4q5BDQTff20iQ1i/cYA7rSpYQf/62kHTpYFNL5cw1Sbl+5eHVYzFF iZ3YCEu+JPn5shRgBuqkpfn5TZMSrfaSQ852xZQ6mLEeO+VSYBaX3n4I2 Hr+EGZp60CIiSimSoknX1CWuQibCexFJmdBDCZp5IQ44essKKw8IFRbzO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAByAs9b/40NJK1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ13Zn8yjAOMHpNahUgUgWYLAQEjhEm?= =?us-ascii?q?FKiE0DQ0BAwEBAgEBAm0TCQyFbkELEgEMdCYBBAENDYMagR1kD6crih8Fi2E?= =?us-ascii?q?XgUE/hWSDBYYSAo43hhKKBwkChmGKCR+BUoR0iWkBgmCJfIloAhEUgSYdOIF?= =?us-ascii?q?VcBU7gm2GBIpSjUuBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,416,1534809600"; d="scan'208,217";a="189812721" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 11:18:42 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9NBIfbH017436 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 11:18:42 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 06:18:41 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 06:18:41 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org>, "detnet@ietf.org" CC: "Venkatesan, Ganesh" , "Jerome Henry (jerhenry)" Thread-Topic: PAW @ IETF 103 Thread-Index: AdRqvbcd3laOAmeFQ82Pbx7pi1v0kw== Date: Tue, 23 Oct 2018 11:18:31 +0000 Deferred-Delivery: Tue, 23 Oct 2018 11:18:14 +0000 Message-ID: <08888a2d9dfd4f24a20e209ab2aff446@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.82.82] Content-Type: multipart/alternative; boundary="_000_08888a2d9dfd4f24a20e209ab2aff446XCHRCD001ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [Detnet] PAW @ IETF 103 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 11:18:45 -0000 --_000_08888a2d9dfd4f24a20e209ab2aff446XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all : I created a doodle https://doodle.com/poll/ikewr3wcztiztppx to have an info= rmal discussion on Predictable and Available Wireless, see what we could do= at the IETF to achieve on wireless similar goals as deterministic networki= ng on wires. Please let me know if you are interested to follow that discussion. If ther= e is enough interest, I'll ask for a separate non-WG mailing list. See you in Bangkok! Pascal --_000_08888a2d9dfd4f24a20e209ab2aff446XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear all :

     

    I created a doodle https://doodle.com/poll/ikewr3wcztiztppx to have an informal discussion= on Predictable and Available Wireless, see what we could do at the IETF to= achieve on wireless similar goals as deterministic networking on wires.

     

    Please let me know if you are interested to follow t= hat discussion. If there is enough interest, I’ll ask for a separate = non-WG mailing list.

     

    See you in Bangkok!

     

    Pascal

    --_000_08888a2d9dfd4f24a20e209ab2aff446XCHRCD001ciscocom_-- From nobody Tue Oct 23 04:49:53 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589CE1277CC for ; Tue, 23 Oct 2018 04:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVPmnDXnOJVR for ; Tue, 23 Oct 2018 04:49:47 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 2271212D4EF for ; Tue, 23 Oct 2018 04:49:47 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 04:49:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.54,416,1534834800"; d="scan'208,217"; a="97775650" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga002.fm.intel.com with ESMTP; 23 Oct 2018 04:49:47 -0700 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Oct 2018 04:49:46 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.14]) by ORSMSX155.amr.corp.intel.com ([169.254.7.228]) with mapi id 14.03.0319.002; Tue, 23 Oct 2018 04:49:45 -0700 From: "Venkatesan, Ganesh" To: "Pascal Thubert (pthubert)" , Norman Finn , "Andrew G. Malis" CC: detnet WG , "thomas.watteyne@analog.com" Thread-Topic: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 Thread-Index: AdRpun7qsEkkNWlsSF2ZENnvGmV+UwAkcy8AAAPJfDAACOF1gAAOgLxA//+bKQCAALl/gIAAPGfw Date: Tue, 23 Oct 2018 11:49:45 +0000 Message-ID: <311BE885E0DA8D4BB369A037CF5B64A79B591D86@ORSMSX107.amr.corp.intel.com> References: <311BE885E0DA8D4BB369A037CF5B64A79B58FADB@ORSMSX107.amr.corp.intel.com> , <311BE885E0DA8D4BB369A037CF5B64A79B590253@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2B9A@lhrpml504-mbx.exmail.huawei.com>, <311BE885E0DA8D4BB369A037CF5B64A79B5903EA@ORSMSX107.amr.corp.intel.com> <3DF0466E9510274382F5B74499ACD6F8016F2C00@lhrpml504-mbx.exmail.huawei.com> <6f879f8e625a424eb5ebf858d076658a@XCH-RCD-001.cisco.com> In-Reply-To: <6f879f8e625a424eb5ebf858d076658a@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTY5N2Q5ZjUtZTVlNC00MjM1LThmZDAtNzdlOGQwM2RkYzc3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQnkzOFhJekdnSUxXN1lkRng1OUxTK0tTUTdKMDJDQzkwU21RYTRaU2RUYUhSeDRkSUlaSG50Q0I3dEhOdkxOVSJ9 dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_311BE885E0DA8D4BB369A037CF5B64A79B591D86ORSMSX107amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 11:49:52 -0000 --_000_311BE885E0DA8D4BB369A037CF5B64A79B591D86ORSMSX107amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pascal: I will not be at IETF 103 but will be at IEEE802 Plenary the following week= . Here is my rationale for keeping 802.11 as part of the IETF DetNet activity= : 1. Real life deployments will typically be wired/wireless (802.11), spec= ifically a wired core with 802.11 end points (the first and the last link). 2. Some of 802.1TSN protocols have analogue in the IEEE802.11 domain (80= 2.1AS over 802.11, 802.1Qat over 802.11; and there is ongoing discussion on= 802.1Qbv over 802.11 Cheers -- ganesh From: Pascal Thubert (pthubert) Sent: Tuesday, October 23, 2018 10:16 AM To: Norman Finn ; Venkatesan, Ganesh ; Andrew G. Malis Cc: detnet WG ; thomas.watteyne@analog.com Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 I agree 100% with Norm below. Wireless can apply to use cases with a whole different range of requirement= s and with a whole different set of techniques. I participated to DetNet wi= th wireless in mind, and realized that the interest of the group are largel= y related to wired TSN. Wireless needs something different, and probably the term "deterministic" s= hould be excluded in favor of something like "predictable and available wir= eless" (PAW), be it just to avoid grinding teeth from all parties. I'd be happy to have a BAR BoF during IETF 103 or at an evening dinner dur= ing the week end before IEEE to discuss that. Cheers, Pascal From: detnet > On B= ehalf Of Norman Finn Sent: lundi 22 octobre 2018 23:12 To: Venkatesan, Ganesh >; Andrew G. Malis = > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 I think I was misunderstanding your wishes, Ganesh. Sorry. I thought you = wanted to add 802.11 to the core of DetNet and/or to the architecture. Now= I see that you are talking about a use case. I'd have to look more at the= details to have an opinion. Given the variability of 802.11 delivery, can you comment about how the dif= ference between DetNet service and typical weighted priorities would be cri= tical to the success of your envisioned applications? I have heard argumen= ts about needing DetNet/TSN to enable timed deliveries. -- Norm ________________________________ From: Venkatesan, Ganesh [ganesh.venkatesan@intel.com] Sent: Monday, October 22, 2018 1:37 PM To: Norman Finn; Andrew G. Malis Cc: detnet WG Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Norm: Not all Use Cases in draft-ietf-detnet-use-cases-19 require a reliability o= f 7 or 8 nines in reliability. For instance, section 3 Electrical Utilities= has a requirement of 0.1-1% packet loss (3.1.1.1.4).. Do you think a manag= ed IEEE802.11 network would not meet that requirement? I would agree with your assessment (cannot achieve reliability to 7 or 8 ni= nes) if we are exclusively focusing on IEEE802.11 only networks. The propos= al is to consider a 802.1 core DetNet with IEEE802.11 links at the last (or= first) hop, for Use Cases where a managed IEEE802.11 network (where the wi= reless configuration takes into account the need for low latency and high r= eliability for TSN traffic). Cheers -- ganesh From: Norman Finn > Sent: Monday, October 22, 2018 4:18 PM To: Venkatesan, Ganesh >; Andrew G.. Malis > Cc: detnet WG > Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 There is a strong desire from a number of application domains for determini= stic wireless networks. This desire has generated projects such as the 6Ti= SCH working group in the WPAN world. There are things that one can do to g= reatly improve the reliability and timeliness of 802.11 networks. I was th= e primary instigator of 802.11ak, that make it possible to have an 802.11 l= ink in the middle of a wired network; the wired robot attached to a wired n= etwork on a factory floor via Wi-Fi was one of the examples I used to promo= te the idea. Having said that ... In the wired world, simply eliminating congestion loss gets us to 7 or 8 ni= nes in reliability. Dual pathing gets us to 10 or more nines. And, these = are things that we know how to accomplish, today. In the wireless world, signal interference can easily drop you to 3 nines. = Deterministic wireless needs different techniques for achieving reliabilit= y -- for example, spreading the data out in time to avoid interference, and= hop-by-hop ACK/retransmission. These are not required in the wired world.= This leads me to talk about the (latency)*(loss rate) product. That is, = in wireless, it is meaningful to have a direct tradeoff between latency and= loss rate, to give room for retransmissions and time spreading. That prod= uct is orders of magnitude different between the wired and wireless cases, = and that means that the applications that can use the service have orders o= f magnitude different requirements. I would fully support the creation of a Deterministic Wireless WG. I belie= ve that such a group and DetNet would complement each others' efforts. The= goals are similar, but the solutions are sufficiently different that I wou= ld not want wireless support to be a goal of DetNet. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [gan= esh.venkatesan@intel.com] Sent: Monday, October 22, 2018 12:33 PM To: Andrew G. Malis Cc: detnet WG Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Hello Andy: Reading the current draft, specifically section 5.1.1, I get the impression= that the current Use Case document does not consider IEEE802.11 as part of= 'IEEE TSN as a layer2 for DetNet'. Given that the TSN work is done in IEEE= 802.1 TSN, do you perceive IEEE802.11 as 'IEEE TSN as a layer2 for DetNet'?= And would that be the perception of the rest of the IETF DetNet membership= ? If your answer is Yes to both the questions, then I would agree (and if w= e delete the reference in section 5.1.1 where the current draft calls out I= EEE802.11 (WiFi) as unsuited for DetNet) that "we don't need to include ex= plicit references to 802.11", but carefully call out in other pertinent IET= F DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requireme= nts explicitly. Cheers -- ganesh From: Andrew G. Malis > Sent: Monday, October 22, 2018 10:15 AM To: Venkatesan, Ganesh > Cc: detnet WG > Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to dtaft-= ietf-detnet-use-cases-19 Ganesh, For those of us that don't attend IEEE, can you fill us in on the relations= hip between 801.11 and TSN? As the DetNet documents already refer (in many = places) to IEEE TSN as a layer 2 media for DetNet, if 801.11 is already inc= luded in the TSN umbrella, then it would seem to me that we don't need to i= nclude explicit references to 802.11. Just a thought. Thanks, Andy On Sun, Oct 21, 2018 at 11:56 PM Venkatesan, Ganesh > wrote: Hello DetNet members: We proposed adding IEEE802.11 as a L2 media for DetNet. Based on our experi= ence with IEEE802.11 in managed deployments, we believe that 802.11 links c= an meet DetNet requirements described in the use case document. In addition= there is a lot of work underway in IEEE802.1ax Task Group and in other Top= ic Interest Groups within IEEE802.11 Working Group that renders 802.11 as a= versatile L2 media for DetNet. Please let me know if you have comments/questions on this submission: Proposed addition of IEEE802.11 as a L2 Media to the draft-ietf-detnet-use-= cases-19 document: Rationale: 802.11 in a managed network environment meets the Use Case requi= rements described in this document. The proposal is to use the 802.11 link = in the DetNet network as the first or the last hop of the wired/wireless en= d-to-end path... Editor: the proposed text below can either be a standalone section or added= to the relevant subsections to section 11 of https://www.ietf.org/id/draft= -ietf-detnet-use-cases-19.txt. x. Use Case Common Themes with L2 Medium Access Control as IEEE802.11 Thus far IEEE 802.11 has been the only wireless media technology that has a= lready included support for some of the 802.1 TSN capabilities required to = address the use cases described in this document. The IEEE 802.11 working g= roup has been working in collaboration with the IEEE 802.1 group for severa= l years extending 802.1 features over 802.11. Therefore, in the Use Cases d= escribed in this document, an IEEE 802.11 hop fits naturally into the netwo= rk. In all these cases, the DetNet under consideration is a wired/wireless = network with the first and/or the last nodes being IEEE802.11 hops and the = rest of the network is wired. As with any wireless media, 802.11 imposes ne= w constraints and restrictions to TSN-grade QoS, and tradeoffs between late= ncy and reliability guarantees must be considered as well as managed deploy= ment requirements. The 802.1 and 802.11 feature set that is already part of IEEE802.11-2016 (a= long with a set of Wi-Fi Alliance Certifications to ensure interoperability= ) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natura= l fit for the DetNet described in this document. The following sub-sections are analogues of corresponding subsections in se= ction-11. The intent is to demonstrate how well IEEE802.11 MAC fits into a = network with DetNet properties where the edges of the network are IEEE802.1= 1 links: e.g the low cost seat speakers being connected over a IEEE802.11 h= op to the network, the HMI at the building management network, the sensors/= alarms in the electric utility network. x.1.1 Extension to Ethernet and 802.1 TSN In addition to IEEE 802.3, 802.11 is also a target media for 802.1 TSN capa= bilities that are being now extended to routed networks by DetNet. IEEE 802= .11ak bridges already defined bridging between 802.1 and 802.11 networks wh= ile maintaining domain-specific semantics. Several 802.1 AVB/TSN specificat= ions have equivalents in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1= AS describes the 802.11 Timing Measurement protocol to enable 802.1AS over = 802.11 links, IEEE802.1Qat Stream Reservation Protocol triggers generation = of equivalent IEEE802.11 Add TS management frames). Equivalent of the IEEE = 802.1Qbv is being discussed in a IEEE802.11 Topic Interest Group (IEEE802.1= 1 TIG for Real Time Applications). x.1.4 L2 and L3 Integration In a managed network, mechanisms to integrate L2 and L3 layers ("making AVB= /TSN-type deterministic performance available from layer-3 applications" or= "connecting two AVB/TSN LANs or 'islands' together through a standard rout= er") should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEEE8= 02.11 is already supported for time synchronization, stream identification = and reservation and additional TSN capabilities are under development (supp= ort for IEEE802.1Qbv, for instance). x.1.5 Consideration for IPv4 As discussed in x.1.4, L3 DetNet performance over IPv4 over an IEEE802.11 L= 2 link is achievable when the network is managed. From a wireless perspecti= ve, this means that there is traffic planning to avoid over subscription of= wireless resources; frequency planning to minimize/eliminate interference/= congestion; stream identification for prioritization; admission control to = prevent over-subscription; time synchronization as defined in 802.1AS, and = 802.1Qbv-like control to prioritize time-sensitive traffic. x.1.6 Guaranteed End-to-End Delivery Guaranteed e2e delivery is achieved in DetNet by constraining the network (= the network is not the open Internet but a constrained/managed network). With 802.11, similar constraints can be put in place in a managed deploymen= t. For instance, multiple channels and Basic Service Sets (BSSs) may be def= ined that restrict access based on traffic stream identification and admiss= ion control features already jointly supported by 802.1 and 802.11. There a= re additional constraints that may be defined to achieve the guarantees. x.1.7 Replacement for Multiple Proprietary Deterministic Networks IEEE802.11 has demonstrated interoperable ubiquitous deployment and it alre= ady has the basic capabilities to interoperate with 802.1 TSN networks. Wit= h the mechanisms outlined in earlier sub-sections, this can extend to provi= de DetNet performance. x.1.8 Mix of Deterministic and Best-Effort Traffic IEEE802.11 has QoS support to identify and prioritize time-sensitive operat= ional traffic. The prioritization (and the resulting improved latency/relia= bility) becomes effective in a managed IEEE802.11 network and has the poten= tial to be even more effective with high efficiency features from IEEE802.1= 1ax, IEEE802.1Qbv over IEEE802.11, etc. x.1.9 Unused Reserved BW to be available to Best Effort Traffic The IEEE 802.11ax amendment enables the APs to have more control of the med= ium and not only prioritize time-sensitive traffic, but also efficiently al= locate resources to Best Effort traffic. 802.11ax can significantly improve= efficiency while reducing contention and latency, which are key aspects to= support the TSN and DetNet use cases defined in this document. x.1.10 Lower Cost, Multi Vendor Solutions IEEE802.11 implementations supporting IEEE802.11 features have been consist= ently available from multiple vendors at low cost. When IEEE802.11 feature = set is enhanced, the roll out of enhancements typically follows a stable am= endment in the IEEE 802.11 WG, development of a corresponding interoperabil= ity certification from Wi-Fi Alliance and broad market availability of the = enhancements. In a managed network, we expect the off-the-shelf implementations of IEEE80= 2.11 protocol to be part of the DetNet and satisfy the requirements. In sit= uations where IEE802.11 enhancements that are currently under development o= f being planned for development soon, we envision the roll out described ab= ove and the availability of lower cost, interoperable multi-vendor implemen= tations with the enhancements to become available. x.3.1 Bounded Latency In managed IEEE802.11 networks, where Admission Control prevents over-subsc= ribing and minimizes collisions, and where QoS provides prioritization of O= perational Traffic, bounded latency for Operational Traffic is achievable [= reference: 18-1160r0] x.3.2 Low Latency Low latency requirement depends on the Use Case in question. There is some = trade-off in the low latency requirement for the convenience of being not t= ethered to a wire, being mobile and being able to reconfigure the network a= s needed for the specific situation within the Use Case. However, low latencies [Reference 18-1160r0] to meet the requirements of a = variety of Use Cases (pro AV, synchronized multi-channel audio, mobile robo= tics, repetitive cyclic control systems (1 - 10 millisecond latencies over = the wireless hop) is achievable in a managed 802.11 network by leveraging c= urrent TSN capabilities over 802.11, such as time synchronization, stream i= dentification and time-aware shaping.. x.5 Security WFA WPA3 provides robust security both for management and data packets. In = addition, WFA Easy Connect provides for robust security while supporting ea= sy onboarding of headless devices into the network. x.6 Future work x.6.1. Centrally Administered Central/distributed Administration - there are aspects of the wireless netw= ork (or the wireless hop from a wired/wireless bridge to a wireless endpoin= t) that will have to be defined. For instance, the controller that does the= central administration may send the desired configuration to the wired/wir= eless bridge (the wireless part in this bridge is the AP function) where it= gets converted into parameters that are 802.11-specific. x.6.2 Standardized Data Flow Information Models Co-ordination between IETF DetNet and IEEE802.11 Working Groups will be req= uired to ensure that this requirement is met when DetNet operates over IEEE= 802.11 links. x.6.3 Symmetrical Path Delays This may be a challenge in 802.11 (probably in all wireless networks, speci= fically indoors). Need to research this further. References: 1. IEEE802.11-2016: Wireless LAN Medium Access Control (MAC) and Physica= l Layer (PHY) Specifications 2. IEEE802.11ak-2017: Enhancements for Transit Links Within Bridged Netw= orks 3. IEEE802.11ax D3.0: Enhancements for High Efficiency WLAN 4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/= 18/11-18-1160-00-0wng-controlling-latency-in-802-11.pptx 5. Wi-Fi Alliance Wireless Protected Access 2 (WPA2) 6. Wi-Fi Alliance Wireless Multi-Media Admission Control (WMM-AC) 7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3) 8. Wi-Fi Alliance TimeSyncTM Cheers -- ganesh _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_311BE885E0DA8D4BB369A037CF5B64A79B591D86ORSMSX107amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Pascal:

     

    I will not be at IETF 103 but will be at IEEE802 Ple= nary the following week.

     

    Here is my rationale for keeping 802.11 as part of t= he IETF DetNet activity:

    1. Real life deployments will typically be wired/wireless (802.11), spec= ifically a wired core with 802.11 end points (the first and the last link).=
    2. Some of 802.1TSN protocols have analogue in the IEEE8= 02.11 domain (802.1AS over 802.11, 802.1Qat over 802.11; and there is ongoi= ng discussion on 802.1Qbv over 802.11

     

    Cheers -= -

    ganesh

     

    From: Pas= cal Thubert (pthubert) <pthubert@cisco.com>
    Sent: Tuesday, October 23, 2018 10:16 AM
    To: Norman Finn <norman.finn@mail01.huawei.com>; Venkatesan, G= anesh <ganesh.venkatesan@intel.com>; Andrew G. Malis <agmalis@gmai= l.com>
    Cc: detnet WG <detnet@ietf.org>; thomas.watteyne@analog.com Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    I agree 100% with Norm= below.

     

    Wireless can apply to = use cases with a whole different range of requirements and with a whole dif= ferent set of techniques. I participated to DetNet with wireless in mind, a= nd realized that the interest of the group are largely related to wired TSN.

     

    Wireless needs somethi= ng different, and probably the term “deterministic” should be e= xcluded in favor of something like “predictable and available wireles= s” (PAW), be it just to avoid grinding teeth from all parties.

     

    I’d  be hap= py to have a BAR BoF during IETF 103 or at an evening dinner during the wee= k end before IEEE to discuss that.

     

    Cheers,

     

    Pascal

     

    From: detnet <detnet-bounces@ietf.org> On Behalf Of Norman Finn
    Sent: lundi 22 octobre 2018 23:12
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G. Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org= >
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     

    I think I was misunderstanding your wish= es, Ganesh.  Sorry.  I thought you wanted to add 802.11 to the co= re of DetNet and/or to the architecture.  Now I see that you are talking about a use case.  I'd have to look more at the detai= ls to have an opinion.

     

    Given the variability of 802.11 delivery= , can you comment about how the difference between DetNet service and typic= al weighted priorities would be critical to the success of your envisioned applications?  I have heard arguments abou= t needing DetNet/TSN to enable timed deliveries.

     

    -- Norm

     

    From:<= /span> Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 1:37 PM
    To: Norman Finn; Andrew G. Malis
    Cc: detnet WG
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Norm:

     =

    Not all Use Cases in dra= ft-ietf-detnet-use-cases-19 require a reliability of 7 or 8 nines in reliab= ility. For instance, section 3 Electrical Utilities has a requirement of 0.= 1-1% packet loss (3.1.1.1.4).. Do you think a managed IEEE802.11 network would not meet that requirement?

     =

    I would agree with your = assessment (cannot achieve reliability to 7 or 8 nines) if we are exclusive= ly focusing on IEEE802.11 only networks. The proposal is to consider a 802.= 1 core DetNet with IEEE802.11 links at the last (or first) hop, for Use Cases where a managed IEEE802.11 netwo= rk (where the wireless configuration takes into account the need for low la= tency and high reliability for TSN traffic).

     =

    Cheers -= -

    ganesh

     =

    From: Norman Finn <norman.finn@mail01.huawei.com>
    Sent: Monday, October 22, 2018 4:18 PM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>; Andrew G.. Malis <agmalis@gmail.com>
    Cc: detnet WG <detnet@ietf.org= >
    Subject: RE: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    There is a strong desire from a number o= f application domains for deterministic wireless networks.  This desir= e has generated projects such as the 6TiSCH working group in the WPAN world.  There are things that one can do to greatly= improve the reliability and timeliness of 802.11 networks.  I was the= primary instigator of 802.11ak, that make it possible to have an 802.11 li= nk in the middle of a wired network; the wired robot attached to a wired network on a factory floor via Wi-Fi was one of = the examples I used to promote the idea.=

     

    Having said that ...

     

    In the wired world, simply eliminating c= ongestion loss gets us to 7 or 8 nines in reliability.  Dual pathing g= ets us to 10 or more nines.  And, these are things that we know how to accomplish, today.<= o:p>

     

    In the wireless world, signal interferen= ce can easily drop you to 3 nines.  Deterministic wireless needs diffe= rent techniques for achieving reliability -- for example, spreading the data out in time to avoid interference, and hop-by-hop ACK/r= etransmission.  These are not required in the wired world.  This = leads me to talk about the (latency)*(loss rate) product.  That is, in= wireless, it is meaningful to have a direct tradeoff between latency and loss rate, to give room for retransmissions and time s= preading.  That product is orders of magnitude different between the w= ired and wireless cases, and that means that the applications that can use = the service have orders of magnitude different requirements.

     

    I would fully support the creation of a = Deterministic Wireless WG.  I believe that such a group and DetNet wou= ld complement each others' efforts.  The goals are similar, but the solutions are sufficiently different that I would not wan= t wireless support to be a goal of DetNet.

     

    -- Norm

     

    From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Venkatesan, Ganesh [ganesh.venkatesan@intel.com]
    Sent: Monday, October 22, 2018 12:33 PM
    To: Andrew G. Malis
    Cc: detnet WG
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

    Hello Andy:

     =

    Reading the current draf= t, specifically section 5.1.1, I get the impression that the current Use Ca= se document does not consider IEEE802.11 as part of ‘IEEE TSN as a la= yer2 for DetNet’. Given that the TSN work is done in IEEE802.1 TSN, do you perceive IEEE802.11 as ‘IEEE TSN as= a layer2 for DetNet’? And would that be the perception of the rest o= f the IETF DetNet membership? If your answer is Yes to both the questions, = then I would agree (and if we delete the reference in section 5.1.1 where the current draft calls out IEEE802.11 (WiFi) as un= suited for DetNet)  that “we don’t need to include explici= t references to 802.11”, but carefully call out in other pertinent IE= TF DetNet RFCs where IEEE802.11 mechanisms required to meet DetNet requirements explicitly.

     =

    Cheers -= -

    ganesh

     =

    From: Andrew G. Malis <agmalis@gmail.com>
    Sent: Monday, October 22, 2018 10:15 AM
    To: Venkatesan, Ganesh <ganesh.venkatesan@intel..com>
    Cc: detnet WG <detnet@ietf.org>
    Subject: Re: [Detnet] proposed addition of IEEE802.11 as L2 Media to= dtaft-ietf-detnet-use-cases-19

     =

    Ganesh,

     =

    For those of us that don= 't attend IEEE, can you fill us in on the relationship between 801.11 and T= SN? As the DetNet documents already refer (in many places) to IEEE TSN as a= layer 2 media for DetNet, if 801.11 is already included in the TSN umbrella, then it would seem to me that we = don't need to include explicit references to 802.11. Just a thought.

     =

    Thanks,

    Andy

     =

     =

    On Sun, Oct 21, 2018 at = 11:56 PM Venkatesan, Ganesh <ganesh.venkatesan@intel.com> wrote:=

    Hello DetNet members:

     =

    We proposed adding IEEE8= 02.11 as a L2 media for DetNet. Based on our experience with IEEE802.11 in = managed deployments, we believe that 802.11 links can meet DetNet requireme= nts described in the use case document. In addition there is a lot of work underway in IEEE802.1ax Task Group and = in other Topic Interest Groups within IEEE802.11 Working Group that renders= 802.11 as a versatile L2 media for DetNet.

     =

    Please let me know if yo= u have comments/questions on this submission:

     =

    Proposed addition of IEEE802.11 as a L2 Med= ia to the draft-ietf-detnet-use-cases-19 document:

     

    Rationale: 802.11 in a managed network envi= ronment meets the Use Case requirements described in this document. The pro= posal is to use the 802.11 link in the DetNet network as the first or the last hop of the wired/wireless end-to-end path= ...

     

    Editor: the proposed text below can eith= er be a standalone section or added to the relevant subsections to section = 11 of https://www.ietf.org/id/draft-ietf-detnet-use-cases-19.txt.<= /b>

     =

    x. Use Case Common Themes with L2 Medium Acces= s Control as IEEE802.11

     =

    Thus far IEEE 802.11 has been the only= wireless media technology that has already included support for some of th= e 802.1 TSN capabilities required to address the use cases described in this document. The IEEE 802.11 working group has be= en working in collaboration with the IEEE 802.1 group for several years ext= ending 802.1 features over 802.11. Therefore, in the Use Cases described in= this document, an IEEE 802.11 hop fits naturally into the network. In all these cases, the DetNet under cons= ideration is a wired/wireless network with the first and/or the last nodes = being IEEE802.11 hops and the rest of the network is wired. As with any wir= eless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between laten= cy and reliability guarantees must be considered as well as managed deploym= ent requirements.

    The 802.1 and 802.11 feature set that is alrea= dy part of IEEE802.11-2016 (along with a set of Wi-Fi Alliance Certificatio= ns to ensure interoperability) and the work that is ongoing in IEEE802.11 WG renders IEEE802.11 a natural fit for the DetNe= t described in this document.=

     =

    The following sub-sections are analogues of co= rresponding subsections in section-11. The intent is to demonstrate how wel= l IEEE802.11 MAC fits into a network with DetNet properties where the edges of the network are IEEE802.11 links: e.g the lo= w cost seat speakers being connected over a IEEE802.11 hop to the network, = the HMI at the building management network, the sensors/alarms in the elect= ric utility network.

     =

    x.1.1 Extension to Ethernet and 802.1 TSN

     =

    In addition to IEEE 802.3, 802.11 is also a ta= rget media for 802.1 TSN capabilities that are being now extended to routed= networks by DetNet. IEEE 802.11ak bridges already defined bridging between 802.1 and 802.11 networks while maintaining domai= n-specific semantics. Several 802.1 AVB/TSN specifications have equivalents= in the IEEE802.11 domain (e.g. Clause 12 of IEEE802.1AS describes the 802.= 11 Timing Measurement protocol to enable 802.1AS over 802.11 links, IEEE802.1Qat Stream Reservation Protocol= triggers generation of equivalent IEEE802.11 Add TS management frames). Eq= uivalent of the IEEE 802.1Qbv is being discussed in a IEEE802.11 Topic Inte= rest Group (IEEE802.11 TIG for Real Time Applications).

     =

    x.1.4 L2 and L3 Integration

    In a managed network, mechanisms to integrate = L2 and L3 layers (“making AVB/TSN-type deterministic performance avai= lable from layer-3 applications” or “connecting two AVB/TSN LANs or ‘islands’ together through a standard router&#= 8221;) should extend to IEEE802.11 as L2. AVB/TSN protocol support over IEE= E802.11 is already supported for time synchronization, stream identificatio= n and reservation and additional TSN capabilities are under development (support for IEEE802.1Qbv, for instance).

     =

    x.1.5 Consideration for IPv4

    As discussed in x.1.4, L3 DetNet performance o= ver IPv4 over an IEEE802.11 L2 link is achievable when the network is manag= ed. From a wireless perspective, this means that there is traffic planning to avoid over subscription of wireless resources= ; frequency planning to minimize/eliminate interference/congestion; stream = identification for prioritization; admission control to prevent over-subscr= iption; time synchronization as defined in 802.1AS, and 802.1Qbv-like control to prioritize time-sensitive= traffic.

     =

    x.1.6 Guaranteed End-to-End Delivery

    Guaranteed e2e delivery is achieved in= DetNet by constraining the network (the network is not the open Internet b= ut a constrained/managed network).<= /o:p>

    With 802.11, similar constraints can be put in= place in a managed deployment. For instance, multiple channels and Basic S= ervice Sets (BSSs) may be defined that restrict access based on traffic stream identification and admission control featur= es already jointly supported by 802.1 and 802.11. There are additional cons= traints that may be defined to achieve the guarantees.

     =

    x.1.7 Replacement for Multiple Proprietary Det= erministic Networks

    IEEE802.11 has demonstrated interoperable ubiq= uitous deployment and it already has the basic capabilities to interoperate= with 802.1 TSN networks. With the mechanisms outlined in earlier sub-sections, this can extend to provide DetNet perfor= mance.

     =

    x.1.8 Mix of Deterministic and Best-Effort Tra= ffic

    IEEE802.11 has QoS support to identify= and prioritize time-sensitive operational traffic. The prioritization (and= the resulting improved latency/reliability) becomes effective in a managed IEEE802.11 network and has the potential to be even= more effective with high efficiency features from IEEE802.11ax, IEEE802.1Q= bv over IEEE802.11, etc.

    x.1.9 Unused Reserved BW to be available to Be= st Effort Traffic

    The IEEE 802.11ax amendment enables the APs to= have more control of the medium and not only prioritize time-sensitive tra= ffic, but also efficiently allocate resources to Best Effort traffic. 802.11ax can significantly improve efficiency whil= e reducing contention and latency, which are key aspects to support the TSN= and DetNet use cases defined in this document.

     =

    x.1.10 Lower Cost, Multi Vendor Solutions

    IEEE802.11 implementations supporting IEEE802.= 11 features have been consistently available from multiple vendors at low c= ost. When IEEE802.11 feature set is enhanced, the roll out of enhancements typically follows a stable amendment in the I= EEE 802.11 WG, development of a corresponding interoperability certificatio= n from Wi-Fi Alliance and broad market availability of the enhancements.

     =

    In a managed network, we expect the off-the-sh= elf implementations of IEEE802.11 protocol to be part of the DetNet and sat= isfy the requirements. In situations where IEE802.11 enhancements that are currently under development of being planned for dev= elopment soon, we envision the roll out described above and the availabilit= y of lower cost, interoperable multi-vendor implementations with the enhanc= ements to become available.

     =

    x.3.1 Bounded Latency

    In managed IEEE802.11 networks, where Admissio= n Control prevents over-subscribing and minimizes collisions, and where QoS= provides prioritization of Operational Traffic, bounded latency for Operational Traffic is achievable [reference: 18-1160r= 0]

     =

    x.3.2 Low Latency

    Low latency requirement depends on the= Use Case in question. There is some trade-off in the low latency requireme= nt for the convenience of being not tethered to a wire, being mobile and being able to reconfigure the network as needed f= or the specific situation within the Use Case.

    However, low latencies [Reference 18-1= 160r0] to meet the requirements of a variety of Use Cases (pro AV, synchron= ized multi-channel audio, mobile robotics, repetitive cyclic control systems (1 – 10 millisecond latencies over the wirele= ss hop) is achievable in a managed 802.11 network by leveraging current TSN= capabilities over 802.11, such as time synchronization, stream identificat= ion and time-aware shaping..<= /span>

    x.5 Security

    WFA WPA3 provides robust security both for man= agement and data packets. In addition, WFA Easy Connect provides for robust= security while supporting easy onboarding of headless devices into the network.=

     =

    x.6 Future work

    x.6.1. Centrally Administered

    Central/distributed Administration – the= re are aspects of the wireless network (or the wireless hop from a wired/wi= reless bridge to a wireless endpoint) that will have to be defined. For instance, the controller that does the central administ= ration may send the desired configuration to the wired/wireless bridge (the= wireless part in this bridge is the AP function) where it gets converted i= nto parameters that are 802.11-specific.=

     =

    x.6.2 Standardized Data Flow Information Model= s

    Co-ordination between IETF DetNet and IEEE802.= 11 Working Groups will be required to ensure that this requirement is met w= hen DetNet operates over IEEE802.11 links.

     =

    x.6.3 Symmetrical Path Delays

    This may be a challenge in 802.11 (probably in= all wireless networks, specifically indoors). Need to research this furthe= r.

     =

    References:

    1. IEEE802.11-2016: Wireless LA= N Medium Access Control (MAC) and Physical Layer (PHY) Specifications
    2. IEEE802.11a= k-2017: Enhancements for Transit Links Within Bridged Networks<= /o:p>
    3. IEEE802.11ax D3.0:= Enhancements for High Efficiency WLAN
    4. WNG documents on RTA (18-1160r0): https://mentor.ieee.org/802.11/dcn/18/11-18-= 1160-00-0wng-controlling-latency-in-802-11.pptx
    5. Wi-Fi= Alliance Wireless Protected Access 2 (WPA2)
    6. Wi-Fi Alliance Wireless Multi-Medi= a Admission Control (WMM-AC)
    7. Wi-Fi Alliance Wireless Protected Access 3 (WPA3)
    8. Wi-Fi Al= liance TimeSyncTM

     =

    Cheers -= -

    ganesh

     =

    ________________________= _______________________
    detnet mailing list
    detnet@ietf.org = https://www.ietf.org/mailman/listinfo/detnet

    --_000_311BE885E0DA8D4BB369A037CF5B64A79B591D86ORSMSX107amrcor_-- From nobody Tue Oct 23 16:36:14 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99811130EB1 for ; Tue, 23 Oct 2018 16:35:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irb3gNW3H7yy for ; Tue, 23 Oct 2018 16:35:52 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCAB130EED for ; Tue, 23 Oct 2018 16:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0MbEu8uFquNFeJIhxklZ1/NJEC+dSfsgjmR/FD/9u88=; b=TZE4GVI0eBJ+RvxmUUtuodWI/ymBcZQ45xhhWVPIHRYrMN4UyvidgCuvDm8r4pqjiy8wXQ61G7jL1Jj1rzdXcwK2pnxQsqiPUwq6SBn15jA6YdL+Ha57nxIuF98qjN2uwAxVP09Q8itv/hIatofAbByejnywltp39/VELVj0zrw= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4531.namprd06.prod.outlook.com (20.177.145.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Tue, 23 Oct 2018 23:35:50 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8%3]) with mapi id 15.20.1250.028; Tue, 23 Oct 2018 23:35:50 +0000 From: "Grossman, Ethan A." To: Loa Andersson CC: "detnet@ietf.org" , Daniel Harkins , Lou Berger , Deborah Brungard Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt Thread-Index: AQHUZcy1QxqXU+k7GUCjw6VABdAuOaUizfCQgAA3NYCAAAlfoIAAJVkAgAB5JdCAAGFhcIACgdUAgABDm4CAARtHgIAFkzXQ Date: Tue, 23 Oct 2018 23:35:50 +0000 Message-ID: References: <153974828679.9449.14033266463915630968@ietfa.amsl.com> <71004a92-f6ac-b204-f53c-d0e57a2a159e@pi.nu> <19754e94-fa63-799d-39c0-97df99e2c168@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4531; 6:+3cmqPS45ofCGekpD0SSpnEYItJfxnhAlrwdQ19tGpACVsQdFmeMhUtI6QrxEG9oGVUaF1Jiciu/YzwRzwb2gMaL6xysVA7Yd3jcFIiBwyKSoysvIMxN+/cclRPfE/gKr/qmgPAg/9hfyYNtFZ13bBz1H6F8Qpo801MZxZm3GfNMXkBc9mdjAA7J3GMGft2Tr7Bj49jFGXRKbUMeTDasLYamyP7wVtVezMU14ioOOCy3C1tDasy/RKw60KPmAOa5/h8d49L+FPlqKCUxOfNwlumd7Sy8jhUf6tC8DCHdTPiv3jMha/uq516qHBVpSk/CwWaDuoXp59SjUFc4m+g3Q/X35JDm2yHqzBA8GYUrG2+FASH8KfR1XmLjLIKoMqRBaW6/PXr+oPt/0jjVorpMgBelFx+ZxMlMCxprcqwT/wY00cmqoX/nmiBRCICPzFEkeLx1dcQxmYM/bODGp64N6g==; 5:3wh4nLvqnSzdXZedEgESMAjRj7L4dOyxSgcql0j8h4RyiooeCfknXl/E7mUFohGcdAf3QyXVPaDI4j+UTjh3bCIj2m3QIBDv+UbyPp/KBxFmaQiV0Fbyz4ldf/70eqh1+JK5Cpc5HuX8umFafUESTMZ2dbHuOZBISx8sM9K0JWI=; 7:l9aU1fLWwkHrRiRJ5YgdKdNc6rBImYbCIvwwEO6F6bKs5n/SozzOIFUXKYKad9C57AlIR2KARy54lg6TtdofM+JpjsgjJFcKLSNPao9ShvndIwRmuaHJ5eCnDDNKtMT+wW6ERArMyuColWISEoWCcUt/g/YEmlyUJ8Ijxzh6jWZqeHDOOUTk+Cu1SCxrPpbd/El8fVz29whZS0M55WZTykhsHvE1lUEc1srf0MGv+iuo8e5WLfrMmImvGycIT12E x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 51784bfb-4dfb-47ad-3972-08d63940445a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4531; x-ms-traffictypediagnostic: BL0PR06MB4531: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(278428928389397)(155532106045638)(120809045254105)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4531; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4531; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(136003)(376002)(39860400002)(13464003)(53754006)(252514010)(199004)(189003)(51444003)(66066001)(8676002)(81156014)(102836004)(33656002)(2906002)(71200400001)(8936002)(305945005)(86362001)(97736004)(11346002)(7736002)(186003)(6116002)(14454004)(5660300001)(256004)(2900100001)(4001150100001)(316002)(6246003)(15650500001)(25786009)(6916009)(4744004)(6506007)(106356001)(53546011)(3846002)(4326008)(6436002)(99286004)(5250100002)(76176011)(229853002)(7696005)(74316002)(966005)(105586002)(55016002)(93886005)(486006)(476003)(478600001)(68736007)(446003)(53936002)(54906003)(81166006)(26005)(14444005)(9686003)(71190400001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4531; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HypwC8B7LgjI+FZPkUkKF8QBRsmu408CS9fFFsPMSoiNl9ntLe8E2j8QJ2UIfI1/GATX795JPoCu0ZmD8B5fklUa4Ao3iOj8PivFKv7UolP04nCt5PQhEelghvoTZDPzW8qrpHpvqKmdeTi+V5yvm0XyS8XkjmaoyYTtHGDz5MxqlyMB6a6xntGOHfnUhYUdwHEx9FWj5TBNoae8ogojBWwzQsykr8VwXLeAI2VBOSLXPgR/5LCQAHjfZkosL1MLRhcLi8FUx8ebgtlyQ4OnxGhf3gJWxKHTyVYxUx/QWIi1Gkqh/C6iJgIvopNH3jTsetCPmor3UaJay8SOCg+CpEUhxjMspsvPJt2EH+3y6GU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51784bfb-4dfb-47ad-3972-08d63940445a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 23:35:50.6332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4531 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-03.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 23:36:04 -0000 T0ssIHNvIHdoYXQgeW91IGFyZSBzYXlpbmcgaXMgdGhhdCB0aGUgYmFkIHNjZW5hcmlvIGdvZXMg bGlrZSB0aGlzOiANCg0KUmV2aWV3ZXI6ICJZb3UgaGF2ZSBubyBzZWN1cml0eSBpbmZvIGluIHlv dXIgZHJhZnQiDQpBdXRob3I6ICJEbyBJIGxvb2sgbGlrZSBhIHNlY3VyaXR5IGV4cGVydD8gVGhp cyBpcyBub3QgbXkgcHJvYmxlbS4gQnV0IEFoYSEgSSBrbm93IHdoYXQgSSdsbCBkbywgSSdsbCBh ZGQgIGEgcmVmZXJlbmNlIHRvIHRoZSBTZWN1cml0eSBGcmFtZXdvcmsgZHJhZnQgYW5kIHRoYXQg d2lsbCBhZGRyZXNzIHlvdXIgY29uY2VybiBhbmQgd2UgY2FuIHB1Ymxpc2ggbXkgZHJhZnQsIHJp Z2h0PyIgDQoNCldoYXQgeW91J2QgcmF0aGVyIGhhdmUgaXMgbW9yZSBsaWtlOiANCg0KUmV2aWV3 ZXI6ICJZb3UgaGF2ZSBubyBzZWN1cml0eSBpbmZvIGluIHlvdXIgZHJhZnQiDQpBdXRob3I6ICJP aCwgZ29vZCBwb2ludCwgbGV0IG1lIGRpc2N1c3MgaXQgd2l0aCB0aGUgV0ciLiANCihzb21lIHdl ZWtzIGxhdGVyOikgDQpBdXRob3I6ICJPSyB3ZSBnb3QgdGhlIHJpZ2h0IHBlb3BsZSBvbiB0aGUg Y2FzZSBhbmQgY29uc2lkZXJlZCB0aGUgc2VjdXJpdHkgY29uY2VybnMsIGFuZCBmb3VuZCB0aGF0 IG1vc3Qgb2YgdGhlbSBhcmUgYWRkcmVzc2VkIGJ5IHRoZSBTZWN1cml0eSBGcmFtZXdvcmssIHNv IHdlIGFkZGVkIGEgU2VjdXJpdHkgc2VjdGlvbiB3aXRoIGEgcmVmZXJlbmNlIHRvIHRoYXQsIGFu ZCBhbHNvIHdlIGFkZGVkIHNvbWUgYWRkaXRpb25hbCBzZWN1cml0eSBpbmZvIHRvIHRoYXQgc2Vj dGlvbiB0aGF0IHdhcyB1bmlxdWUgdG8gb3VyIHRlY2hub2xvZ3kgd2hpY2ggd2UgYmVsaWV2ZSBh ZGRyZXNzZXMgb3VyIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIE9LPyIgDQoN ClJpZ2h0PyANCk9mIGNvdXJzZSB0aGUgZGVnZW5lcmF0ZSBjYXNlIGlzIHdoZXJlIHRoZSBhdXRo b3JzIGRvIGJlbGlldmUgdGhhdCB0aGUgU2VjdXJpdHkgRnJhbWV3b3JrIGRyYWZ0IGNvdmVycyBh cyBtdWNoIGFzIGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgZHJhZnQsIHNvIGFsbCAgdGhhdCBpcyBp biB0aGUgU2VjdXJpdHkgc2VjdGlvbiBpcyB0aGF0IHJlZmVyZW5jZSwgd2l0aCBhIHN0YXRlbWVu dCB0byB0aGF0IGVmZmVjdC4gDQpFdGhhbi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiANClNlbnQ6IFNhdHVyZGF5LCBPY3Rv YmVyIDIwLCAyMDE4IDM6MTIgQU0NClRvOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xi eS5jb20+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjsgRGVib3JhaCBCcnVuZ2FyZCA8 ZGIzNTQ2QGF0dC5jb20+DQpDYzogZGV0bmV0QGlldGYub3JnOyBEYW5pZWwgSGFya2lucyA8ZGhh cmtpbnNAbG91bmdlLm9yZz4NClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMy50eHQNCg0KRXRoYW4sDQoNCldlIGhhZCAoaGF2ZSkg YSBzaW1pbGFyIGNhc2UgaW4gTVBMUy9HTVBMUyAoUkZDIDU5MjApIGFuZCBNUExTLVRQIChSRkMg NjQ5MSksIHRob3NlIGZyYW1ld29yayBzZXJ2ZSBhcyB2ZXJ5IGdvb2QgcmVmZXJlbmNlcywgYnV0 IGhhdmUgbmV2ZXIgYmVlbiBzdWZmaWNpZW50IGFzIGp1c3QgYSByZWZlcmVuY2UuDQoNCkkgdGhp bmsgdGhhdCB0aGUgcG9pbnQgdGhhdCB0aGUgU0VDLURJUiBtYWtlcyBpcyB0aGF0IHRoZSBhdXRo b3JzIChhbmQgdGhlIHdnKSBvZiBhIG5ldyBkcmFmdCBtdXN0IGJlIGFibGUgdG8gZGVtb25zdHJh dGUgdGhhdCB0aGV5IGhhdmUgY29uc2lkZXJlZCBhbGwgdGhlIGltcG9ydGFudCBzZWN1cml0eSBp c3N1ZXMgdGhhdCByZWxhdGUgdG8gYSBwYXJ0aWN1bGFyIGRyYWZ0Lg0KDQpZZXMgLSB3ZSBuZWVk IHRoZSBzZWN1cml0eSBmcmFtZXdvcmtzLCBidXQgdGhleSB3aWxsIG5vdCBiZSBzdWZmaWNpZW50 IGFzIGEgc3RhbmQgYWxvbmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbi4NCg0KTXkgaW5pdGlhbCBw b2ludCB3YXMgdGhhdCwgdGhpcyBpbnRlbnRpb24gc2hvdWxkIGJlIGNhcHR1cmVkIGluIHRoZSBk cmFmdC4NCg0KL0xvYQ0KDQoNCg0KICAyMDE4LTEwLTIwIDAxOjIzLCBHcm9zc21hbiwgRXRoYW4g QS4gd3JvdGU6DQo+IEhpIExvYSwNCj4gVGhpcyBpcyBhIHZlcnkgZ29vZCBwb2ludCwgdGhhdCBh cyBvdGhlciBkcmFmdHMgcHJvZ3Jlc3MgYWZ0ZXIgcHVibGljYXRpb24gb2YgdGhlIFNlY3VyaXR5 IGRyYWZ0IHRoYXQgbmV3IGZhY3RvcnMgY291bGQgYXJpc2UuIFBlcmhhcHMgdGhlIGRyYWZ0cyBj b3VsZCBiZSBleHBlY3RlZCB0byByZWZlcmVuY2UgdGhlIFNlY3VyaXR5IGRyYWZ0LCBidXQgbm90 IGR1cGxpY2F0ZSB3aGF0IHdhcyBhbHJlYWR5IGluIHRoZSBTZWN1cml0eSBkcmFmdCBhdCB0aGF0 IHRpbWUsIGluY29ycG9yYXRpbmcgYW55IG5ldyBtYXRlcmlhbCBpbiB0aGUgZHJhZnQgaXRzZWxm LCBvciBhbHRlcm5hdGl2ZWx5IHVwZGF0aW5nIHRoZSBTZWN1cml0eSBkcmFmdCB3aXRoIHRoZSBu ZXcgbWF0ZXJpYWwgYXQgdGhlIHNhbWUgdGltZT8gT3RoZXJ3aXNlIGEgbG90IG9mIGR1cGxpY2F0 aW9uIG9mIHRleHQgd291bGQgaGF2ZSB0byBiZSBkb25lIHRvIG1ha2UgZWFjaCBhbmQgZXZlcnkg ZHJhZnQgc2VsZi1zdWZmaWNpZW50IGluIHRoZSBhcmVhIG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg0KPiBFdGhhbi4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE5LCAy MDE4IDY6MTYgQU0NCj4gVG86IEdyb3NzbWFuLCBFdGhhbiBBLiA8ZWFncm9zQGRvbGJ5LmNvbT47 IExvdSBCZXJnZXIgDQo+IDxsYmVyZ2VyQGxhYm4ubmV0PjsgRGVib3JhaCBCcnVuZ2FyZCA8ZGIz NTQ2QGF0dC5jb20+DQo+IENjOiBkZXRuZXRAaWV0Zi5vcmc7IERhbmllbCBIYXJraW5zIDxkaGFy a2luc0Bsb3VuZ2Uub3JnPg0KPiBTdWJqZWN0OiBSZTogW0RldG5ldF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0DQo+IA0KPiBFdGhhbiwNCj4gDQo+IE9uZSBz bWFsbCBjb21tZW50IC0gSSB0aGluayB0aGF0IG9uZSBjb25jZXJuIGZyb20gdGhlIFNFQy1ESVIg aXMgdGhhdCAiU2VjdXJpdHkgZHJhZnQiIGlzIHNldCBpbiB0aW1lIGFuZCB0aGUgdmVyeSBuZXh0 IGRyYWZ0IChub3QgdG8gbWVudGlvbiB2ZXJ5IG11Y2ggbGF0ZXIgZHJhZnRzKSBhZGRyZXNzZXMg dGhpbmdzIHRoYXQgd2VyZSBub3Qga25vd24gd2hlbiB0aGUgIlNlY3VyaXR5IGRyYWZ0IiB3YXMg d3JpdHRlbi4gVGh1cyB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgY2FuIG5ldmVyIHJlZmVy ZW5jZSB0aGUgIlNlY3VyaXR5IGRyYWZ0IiwgYnV0IHdlIG5lZWQgdG8gc2hvdyB0aGF0IHdlIHVu ZGVyc3RhbmQgdGhyZWF0cyBhbmQgcmVtZWRpZXMgdGhhdCBpcyByZWxldmFudCB0byBlYWNoIGFu ZCBldmVyeSBkcmFmdC4NCj4gDQo+IEhhdmluZyBzYWlkIHRoYXQgKHRvIGF2b2lkIG1pc3VuZGVy c3RhbmRpbmdzKSB0aGUgIlNlY3VyaXR5IGRyYWZ0IiBpcyBhIGdvb2QgZG9jdW1lbnQsIHdlbGwg d29ydGggcmVmZXJlbmNpbmcsIGJ1dCBhIHJlZmVyZW5jZSBpcyBub3QgZW5vdWdoLCB0aGUgcGFy dGljdWxhciB0aHJlYXRzIG5lZWQgdG8gYmUgYWRkcmVzc2VkLg0KPiANCj4gL0xvYQ0KPiANCj4g T24gMjAxOC0xMC0xOCAwNzowMiwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3RlOg0KPj4gT3IgbWF5 YmUgdGhlIGFuc3dlciB3aWxsIGJlIGltcGxpY2l0IGluIERhbmllbCBIYXJraW5zJyByZXNwb25z ZSB0byBKYW5vcycgcGxhbiB0byB1cGRhdGUgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdCB0byByZWZl ciB0byB0aGUgU2VjdXJpdHkgZHJhZnQuIElmIGhlIGFjY2VwdHMgdGhhdCwgdGhlbiBJIHRoaW5r IHRoYXQgcHJldHR5IG11Y2ggY29uc3RpdHV0ZXMgYWNjZXB0YW5jZSBvZiB0aGF0IHN0cmF0ZWd5 PyBCdXQgZXZlbiBpZiBzbywgd291bGQgdGhhdCBob2xkIGZvciBldmVyeSBkcmFmdCwgb3IgYXJl IHRoZXJlIHNvbWUgdHlwZXMgb2YgZHJhZnQgZm9yIHdoaWNoIHRoYXQgd291bGRuJ3QgYmUgYWNj ZXB0YWJsZT8NCj4+IEV0aGFuLg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiBHcm9zc21hbiwgRXRoYW4gQS4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAx NywgMjAxOCAxMDoxOSBBTQ0KPj4gVG86ICdMb2EgQW5kZXJzc29uJyA8bG9hQHBpLm51PjsgTG91 IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD47IA0KPj4gRGVib3JhaCBCcnVuZ2FyZCA8ZGIzNTQ2 QGF0dC5jb20+DQo+PiBDYzogZGV0bmV0QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTogW0RldG5l dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0DQo+Pg0KPj4g VGhhbmtzIExvYSAoYWRkaW5nIExvdSBhbmQgRGVib3JhaCkuDQo+Pg0KPj4gU28gZmFyLCB0aGUg cmV2aWV3ZXJzIG9mIHRoZSBsYXN0IFVzZSBDYXNlcyBkcmFmdCBoYXZlIHNhaWQgIkhleSB3aGVy ZSdzIHRoZSBTZWN1cml0eSBzZWN0aW9uPyIgYW5kIExvdSBhbmQgSSBhZGRlZCBhIFNlY3VyaXR5 IHNlY3Rpb24gdGhhdCBwb2ludHMgdGhlbSBhdCB0aGUgU2VjdXJpdHkgZHJhZnQsIGFuZCB0aGV5 IHNlZW1lZCB0byBiZSBPSyB3aXRoIHRoYXQuIEkgZG9uJ3Qga25vdyBpZiB0aGF0IHdvdWxkIGJl IHRoZSBjYXNlIGZvciBvdXIgb3RoZXIgZHJhZnRzLg0KPj4NCj4+IEkgd291bGQgdmVyeSBtdWNo IGxpa2UgdG8gaGF2ZSB0aGlzIGNvbnZlcnNhdGlvbiB3aXRoIHRoZSBTZWN1cml0eSBBRCdzIGFu ZCBEaXJlY3RvcmF0ZTsgYXQgcHJlc2VudCwgSSBwZXJzb25hbGx5IGRvbid0IGtub3cgdGhlIG1v c3QgYXBwcm9wcmlhdGUgaW5kaXZpZHVhbHMgdG8gZW5nYWdlIHdpdGggb24gdGhpcyB0b3BpYyAt IGlmIG9uZSBvZiB5J2FsbCB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgbWUgc29tZSBraW5kIG9mIGlu dHJvZHVjdGlvbiwgSSdtIGhhcHB5IHRvIHRyeSB0byBkcml2ZSBzb21lIHJlc29sdXRpb24gb24g b3VyIHN0cmF0ZWd5IGhlcmUsIGVpdGhlciBvbiB0aGUgbGlzdCBvciBpbiBCYW5na29rLg0KPj4N Cj4+IEV0aGFuLg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBM b2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTcs IDIwMTggMjo1NyBBTQ0KPj4gVG86IEdyb3NzbWFuLCBFdGhhbiBBLiA8ZWFncm9zQGRvbGJ5LmNv bT4NCj4+IENjOiBkZXRuZXRAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMy50eHQNCj4+DQo+PiBFdGhhbiwg V29ya2luZyBHcm91cCwNCj4+DQo+PiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgb25lIHNpemUg Zml0cyBhbGwgYXBwcm9hY2ggcG9zc2libGUgZm9yIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBpbiBhbGwgRGV0TmV0IGRvY3VtZW50cy4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBT ZWN1cml0eSBEaXJlY3RvcmF0ZSBhbmQgU2VjdXJpdHkgQURzIHJlcXVpcmUgdGhhdCBlYWNoIGRv Y3VtZW50IGhhdmUgYW4gaW5kZXBlbmRlbnQgdHJlYXRtZW50IG9mIHRoZSBzcGVjaWZpYyB0aHJl YXRzIGFuZCBjb25jZXJucyBmb3IgYSBwYXJ0aWN1bGFyIGRvY3VtZW50Lg0KPj4NCj4+IFdoYXRl dmVyIHN0cmF0ZWd5IHdlIGRlY2lkZSBvbiwgcGxlYXNlIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIGFn cmVlZCBvbiBieSB0aGUgU2VjdXJpdHkgQURzIGFuZCBEaXJlY3RvcmF0ZS4NCj4+DQo+PiAvTG9h DQo+Pg0KPj4gT24gMjAxOC0xMC0xNyAxNTo1NCwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3RlOg0K Pj4+IEhpIExvYSwNCj4+PiBWYXJpb3VzIHN0cmF0ZWdpZXMgYXJlIHBvc3NpYmxlLiBPbmUgcG9z c2liaWxpdHkgaXMgdGhhdCB0aGUgb3RoZXIgZHJhZnRzIChpLmUuIG5vdCB0aGUgU2VjdXJpdHkg ZHJhZnQpIGNvdWxkIGp1c3QgcG9pbnQgYXQgdGhlIFNlY3VyaXR5IGRyYWZ0IHN1Y2ggdGhhdCB0 aGVyZSB3b3VsZCBiZSBhICJzaW5nbGUgY2xlYXJpbmcgaG91c2UiIGZvciBEZXROZXQtc3BlY2lm aWMgc2VjdXJpdHkgaW5mby4gIFRoYXQncyB3aGF0IHRoZSBVc2UgQ2FzZXMgZHJhZnQgZG9lcywg aG93ZXZlciB0aGVyZSBpcyBhbHNvIHNvbWUgc2VjdXJpdHktcmVsYXRlZCB0ZXh0IGluIHRoZSB2 YXJpb3VzIHVzZSBjYXNlcy4NCj4+Pg0KPj4+IEF0IG9uZSBwb2ludCBJIChhcyBTZWN1cml0eSBk cmFmdCBlZGl0b3IpIGF0dGVtcHRlZCB0byBicmluZyANCj4+PiB0b2dldGhlciBhbGwgb2YgdGhl IHNlY3VyaXR5LXJlbGF0ZWQgdGV4dCBmcm9tIHRoZSB2YXJpb3VzIG90aGVyIA0KPj4+IGRyYWZ0 cyBieSBjb3B5aW5nIGl0IGFsbCBpbnRvIGFuIGFwcGVuZGl4IG9mIHRoZSBTZWN1cml0eSBkcmFm dCwgDQo+Pj4gc2luY2UgaXQgaXMgc29ydCBvZiBoYW5keSB0byBoYXZlIGl0IGFsbCBpbiBvbmUg cGxhY2UuIEJ1dCBhcyBMb3UgDQo+Pj4gcG9pbnRlZCBvdXQgdG8gbWUsIHdlIGRvbid0IHdhbnQg dG8gbWFrZSB0aGUgZHJhZnRzIGRlcGVuZGVudCBvbiANCj4+PiBlYWNoIG90aGVyIGlmIHdlIGNh biBhdm9pZCBpdCwgYW5kIGlmIHN1Y2ggdGV4dCBnb3QgZWRpdGVkIHRoZW4gaXQgDQo+Pj4gd291 bGQgaGF2ZSB0byBiZSBmaXhlZCBpbiB0d28gcGxhY2VzLCBzbyBpdCBpc24ndCBhIHBlcmZlY3Qg c2NoZW1lLiANCj4+PiBJIHdvdWxkIHNheSB0aGF0IGlmIGEgZHJhZnQgYXV0aG9yIHdhbnRzIHRv IHdyaXRlIHRoZWlyIG93biANCj4+PiBzZWN1cml0eS1yZWxhdGVkIHRleHQgaW4gdGhlaXIgb3du IGRyYWZ0IG1vcmUgcG93ZXIgdG8gdGhlbSwgYnV0IA0KPj4+IHBlcmhhcHMgZXZlbiBtb3JlIHBv d2VyIGlmIHRoZXkgYnJpbmcgaXQgdG8gdGhlIFNlY3VyaXR5IGRyYWZ0IDotICkNCj4+Pg0KPj4+ IFNvcnJ5IGxvbmcgYW5zd2VyIHRvIGEgc2hvcnQgcXVlc3Rpb24uIEFuZCBJJ20gc3VyZSB0aGVy ZSBhcmUgb3RoZXIgc3RyYXRlZ2llcy4uLiBJZiB5b3UgaGF2ZSBhbnkgdGhvdWdodHMgb24gdGhl IG1hdHRlciBJJ2QgbG92ZSB0byBoZWFyIHRoZW0sIGVpdGhlciBvbiB0aGUgbGlzdCBvciBhdCBJ RVRGIDEwMy4NCj4+PiBFdGhhbi4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4gRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KPj4+IFNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAxNywgMjAxOCAxMjoxMCBBTQ0KPj4+IFRvOiBHcm9zc21hbiwgRXRoYW4gQS4g PGVhZ3Jvc0Bkb2xieS5jb20+DQo+Pj4gQ2M6IGRldG5ldEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6 IFJlOiBbRGV0bmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wMy50 eHQNCj4+Pg0KPj4+IEV0aGFuLA0KPj4+DQo+Pj4gSSBoYXZlIGp1c3QgaGFkIGEgcXVpY2sgbG9v aywgYnV0IHdoYXQgSSBzZWUgbG9va3MgZ29vZCwgYW5kIGNlcnRhaW5seSBnaXZlcyBhIGdvb2Qg b3ZlcnZpZXcgb2YgdGhlIGRldG5ldCBzZWN1cml0eSBpc3N1ZXMuDQo+Pj4NCj4+PiBPbmUgcXVl c3Rpb24sIGlzIGl0IHRoZSBpbnRlbnRpb24gdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB1 c2VkIGFzIGEgZ2VuZXJhbCByZWZlcmVuY2Ugd2hlbiB3cml0aW5nIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIGZvciBkZXRuZXQgZG9jdW1lbnRzPw0KPj4+DQo+Pj4gL0xvYQ0KPj4+DQo+Pj4gT24g MjAxOC0xMC0xNyAxMjowNSwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3RlOg0KPj4+PiBIaSBBbGws DQo+Pj4+IFRoaXMgbm90ZSBpcyB0aGUgc3RhdHVzIHVwZGF0ZSBmb3IgdGhlIERldE5ldCBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBkcmFmdCBpbiBhZHZhbmNlIG9mIElFVEYgMTAzLCBpbiBsaWV1 IG9mIGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIGl0IGF0IElFVEYgMTAzLg0KPj4+Pg0KPj4+PiBB IG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCB3aGljaCBpbmNsdWRlcyB0aGUgZGlzY3Vzc2lv biBvbiBPQU0gdHJhZmZpYyBhbmQgaW5jb3Jwb3JhdGVzIHRoZSAiQm91bmRlZCBKaXR0ZXIiIFVz ZSBDYXNlIENvbW1vbiBUaGVtZS4NCj4+Pj4NCj4+Pj4gVGhlc2UgYXJlIG1pbm9yIGNoYW5nZXM7 IG5vIHN1YnN0YW50aWFsIHdvcmsgaGFzIGJlZW4gZG9uZSBzaW5jZSB0aGUgbGFzdCBEZXROZXQg c2Vzc2lvbiwgc28gd2UgZG8gbm90IHBsYW4gdG8gaGF2ZSBhIHNsb3QgZm9yIHRoaXMgZHJhZnQg YXQgdGhlIElFVEYgMTAzIERldE5ldCBzZXNzaW9uICh0aG91Z2ggVGFsIHdpbGwgYmUgcHJlc2Vu dGluZyBvbiBpdCBhdCB0aGUgRGV0TmV0LVRTTiBtZWV0aW5nIG9uIHRoZSBmb2xsb3dpbmcgU3Vu ZGF5KS4NCj4+Pj4NCj4+Pj4gSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGNvbnZlbmUgYXMgbWFueSBv ZiB0aGUgYXV0aG9ycyAoYW5kIGFueSBvdGhlciBpbnRlcmVzdGVkIHBhcnRpZXMpIGFzIHdlIGhh dmUgYXZhaWxhYmxlIGF0IElFVEYgMTAzIHRvIGRpc2N1c3MgRGV0TmV0LWRhdGEtcGxhbmUtdGVj aG5vbG9neS1zcGVjaWZpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgaG93IHRvIGluY29y cG9yYXRlIHRoZW0gaW50byB0aGUgZHJhZnQgYXMgb3VyIG5leHQgc3RlcHMuIElmIHlvdSB3b3Vs ZCBsaWtlIHRvIHBhcnRpY2lwYXRlIGluIChiZSBub3RpZmllZCBhYm91dCkgdGhpcyBjb252ZXJz YXRpb24sIHBsZWFzZSBsZXQgbWUga25vdy4NCj4+Pj4NCj4+Pj4gQmVzdCwNCj4+Pj4gRXRoYW4g KGFzIERldE5ldCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBkcmFmdCBlZGl0b3IpDQo+Pj4+DQo+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IGRldG5ldCA8ZGV0bmV0 LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiANCj4+Pj4gaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTggODo1MSBQTQ0KPj4+ PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+Pj4+IENjOiBkZXRuZXRAaWV0Zi5vcmcNCj4+ Pj4gU3ViamVjdDogW0RldG5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJp dHktMDMudHh0DQo+Pj4+DQo+Pj4+DQo+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pj4g VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5n IFdHIG9mIHRoZSBJRVRGLg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAg OiBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCj4+Pj4gICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGFsIE1penJhaGkNCj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXRoYW4gR3Jvc3NtYW4NCj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IEouIEhhY2tlcg0KPj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTdWJpciBEYXMNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSm9obiBEb3dkZWxsDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEhlbnJpayBBdXN0YWQNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgS2V2aW4g U3RhbnRvbg0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3JtYW4gRmlubg0K Pj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDMudHh0 DQo+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA0MA0KPj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAx OC0xMC0xNg0KPj4+Pg0KPj4+PiBBYnN0cmFjdDoNCj4+Pj4gICAgICAgIEEgZGV0ZXJtaW5pc3Rp YyBuZXR3b3JrIGlzIG9uZSB0aGF0IGNhbiBjYXJyeSBkYXRhIGZsb3dzIGZvciByZWFsLQ0KPj4+ PiAgICAgICAgdGltZSBhcHBsaWNhdGlvbnMgd2l0aCBleHRyZW1lbHkgbG93IGRhdGEgbG9zcyBy YXRlcyBhbmQgYm91bmRlZA0KPj4+PiAgICAgICAgbGF0ZW5jeS4gIERldGVybWluaXN0aWMgbmV0 d29ya3MgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBkZXBsb3llZCBpbg0KPj4+PiAgICAgICAgcmVh bC10aW1lIG9wZXJhdGlvbmFsIHRlY2hub2xvZ3kgKE9UKSBhcHBsaWNhdGlvbnMgZm9yIHNvbWUg eWVhcnMNCj4+Pj4gICAgICAgIChmb3IgZXhhbXBsZSBbQVJJTkM2NjRQN10pLiAgSG93ZXZlciwg c3VjaCBuZXR3b3JrcyBhcmUgdHlwaWNhbGx5DQo+Pj4+ICAgICAgICBpc29sYXRlZCBmcm9tIGV4 dGVybmFsIGFjY2VzcywgYW5kIHRodXMgdGhlIHNlY3VyaXR5IHRocmVhdCBmcm9tDQo+Pj4+ICAg ICAgICBleHRlcm5hbCBhdHRhY2tlcnMgaXMgbG93LiAgSUVURiBEZXRlcm1pbmlzdGljIE5ldHdv cmtpbmcgKERldE5ldCkNCj4+Pj4gICAgICAgIHNwZWNpZmllcyBhIHNldCBvZiB0ZWNobm9sb2dp ZXMgdGhhdCBlbmFibGUgY3JlYXRpb24gb2YgZGV0ZXJtaW5pc3RpYw0KPj4+PiAgICAgICAgbmV0 d29ya3Mgb24gSVAtYmFzZWQgbmV0d29ya3Mgb2YgcG90ZW50aWFsbHkgd2lkZSBhcmVhIChvbiB0 aGUgc2NhbGUNCj4+Pj4gICAgICAgIG9mIGEgY29ycG9yYXRlIG5ldHdvcmspIHBvdGVudGlhbGx5 IGJyaW5naW5nIHRoZSBPVCBuZXR3b3JrIGludG8NCj4+Pj4gICAgICAgIGNvbnRhY3Qgd2l0aCBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5IChJVCkgdHJhZmZpYyBhbmQgc2VjdXJpdHkgdGhyZWF0cw0K Pj4+PiAgICAgICAgdGhhdCBsaWUgb3V0c2lkZSBvZiBhIHRpZ2h0bHkgY29udHJvbGxlZCBhbmQg Ym91bmRlZCBhcmVhIChzdWNoIGFzDQo+Pj4+ICAgICAgICB0aGUgaW50ZXJuYWxzIG9mIGFuIGFp cmNyYWZ0KS4gIFRoZXNlIERldE5ldCB0ZWNobm9sb2dpZXMgaGF2ZSBub3QNCj4+Pj4gICAgICAg IHByZXZpb3VzbHkgYmVlbiBkZXBsb3llZCB0b2dldGhlciBvbiBhIHdpZGUgYXJlYSBJUC1iYXNl ZCBuZXR3b3JrLA0KPj4+PiAgICAgICAgYW5kIHRodXMgY2FuIHByZXNlbnQgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgdGhhdCBtYXkgYmUgbmV3IHRvIElQLQ0KPj4+PiAgICAgICAgYmFzZWQgd2lk ZSBhcmVhIG5ldHdvcmsgZGVzaWduZXJzLiAgVGhpcyBkcmFmdCwgaW50ZW5kZWQgZm9yIHVzZSBi eQ0KPj4+PiAgICAgICAgRGV0TmV0IG5ldHdvcmsgZGVzaWduZXJzLCBwcm92aWRlcyBpbnNpZ2h0 IGludG8gdGhlc2Ugc2VjdXJpdHkNCj4+Pj4gICAgICAgIGNvbnNpZGVyYXRpb25zLiAgSW4gYWRk aXRpb24sIHRoaXMgZHJhZnQgY29sbGVjdHMgYWxsIHNlY3VyaXR5LQ0KPj4+PiAgICAgICAgcmVs YXRlZCBzdGF0ZW1lbnRzIGZyb20gdGhlIHZhcmlvdXMgRGV0TmV0IGRyYWZ0cyAoQXJjaGl0ZWN0 dXJlLCBVc2UNCj4+Pj4gICAgICAgIENhc2VzLCBldGMpIGludG8gYSBzaW5nbGUgbG9jYXRpb24g U2VjdGlvbiA3Lg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHkvDQo+Pj4+DQo+Pj4+IFRoZXJlIGFyZSBh bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTAzDQo+Pj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHkt MDMNCj4+Pj4NCj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1kZXRuZXQtc2VjdXJpdHktMDMNCj4+Pj4NCj4+Pj4NCj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPj4+Pg0KPj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4gZGV0bmV0QGlldGYu b3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4gZGV0bmV0QGlldGYub3JnDQo+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+Pj4+DQo+Pj4NCj4+ DQo+IA0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1h aWw6IGxvYUBwaS5udQ0KU2VuaW9yIE1QTFMgRXhwZXJ0DQpCcm9uemUgRHJhZ29uIENvbnN1bHRp bmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Wed Oct 24 09:06:26 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8DF130E0E; Wed, 24 Oct 2018 09:06:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker To: Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154039718506.6853.7266750048073148979@ietfa.amsl.com> Date: Wed, 24 Oct 2018 09:06:25 -0700 Archived-At: Subject: [Detnet] Secdir last call review of draft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:06:25 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready I have reviewed the document, and it is ready for publication. The document is an analysis of the use cases and (now) properly refers to a separate security considerations section. The use cases document is ready for publication and this should go forward now. However the security considerations document is still a work in progress, no document shepherd assigned. Which is of course right and proper for a security considerations relating to the final proposal. And of course it is useful to nail down the use cases before looking at the security considerations. But the use cases having deferred security to the external document risks creating a deadlock situation. It is important that the document contain a link to the security considerations to be supplied but this should not hold up publication as an RFC. My only comment on the referenced SC document at this stage is that it might be that the term 'deterministic networking' overstates the requirements evidenced by the use cases. In many of the cited use cases, what is required is a higher degree of confidence that the network characteristics meet certain requirements than an absolute guarantee. It might be that 'predictable networking' provides a better description of those requirements. From nobody Wed Oct 24 12:57:50 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B892124C04; Wed, 24 Oct 2018 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GATFvMqh3tNU; Wed, 24 Oct 2018 12:57:46 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680138.outbound.protection.outlook.com [40.107.68.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDFF1276D0; Wed, 24 Oct 2018 12:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/cblNCwnj1n8i86w5j31zM6czdm+t7Yv9VanxxsusfU=; b=CvJ9a8WLIVEam/J3KPVyiTTxp33AVfbRsXZTFBmmygNMABcD+K7uvukR6LWmI+6ez+Wj+/bl6f82du9YrP90ViHQm3b6JHwUDNw3ZwHu3mVg1JIjFOkQNQ1gDcwioMUtUWFzuK7TQ73i9eGwcN4I44Nzr0uERuPcB1TguhgNEII= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4609.namprd06.prod.outlook.com (20.177.145.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.19; Wed, 24 Oct 2018 19:57:44 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8%3]) with mapi id 15.20.1250.028; Wed, 24 Oct 2018 19:57:43 +0000 From: "Grossman, Ethan A." To: Phillip Hallam-Baker , "secdir@ietf.org" CC: "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-use-cases.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-detnet-use-cases-19 Thread-Index: AQHUa7OHygCoWERxgE2KW1ed/V/+46Uuz4HA Date: Wed, 24 Oct 2018 19:57:43 +0000 Message-ID: References: <154039718506.6853.7266750048073148979@ietfa.amsl.com> In-Reply-To: <154039718506.6853.7266750048073148979@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4609; 6:GmeKlSgdave8yyVXSEC012EhVHkWdMWfB6AIeGP5EUMan+LbKKPWpLoN/L8pgDqma2iru1xF4hAzef0+c5sOH3CSxRaoysx8y5ZyqqJi+Qe06WlO4pI56SeCMvQG/V0KeolHCCR/dOmYJUjpSd8Y2GIbVQV6IHtbjbmkPoB97Z/fGHFAPq7kNsx71YdpN2dk2ooH0BVLERlyTfHobbiP8xFFxeMK35J72Bwmv/caVeU/EcQORXUFMuchaNdDtC6Lc+tj+ZY6IqNs+WHJT6GbFj6hPAfyEHk0t1uoa1VVpEOBzyAKsbGP7BWq9dPjKLbQjaoKDO4Xk5LWUWiJuzP/bowA4LF+cUVR/65XxIiXbQqVzxs7kvISNhRSCkYrPQN8cwxl5uJ4S7heCkzmupTauztV6pFxaVvgjKb0iN/iJI0I8+LqOxgL+UooOVe4NaZtY52c8M+3p4x2dNdFEx1wxg==; 5:SD1GkZqdwu2r9iqwyauNKzSiSojnv9nkYMeF79ZuULnstaxYLdMP7m/uXpsxgR7xGguN/v8CdDMGZ/+1fZXUGNwoqSCzIWJtFqNcE/I8rgO5kUHZ+ukyiwlPkjNgGqE3bx1zdoghXD4ZuKgtghiAbzRRKdT5BMTJB9ZlX+M2cHI=; 7:/2IB4BN367fwVZauvOdLI1SypJ29+mKh54/Wt/dUepGTEW3ddziURST1QyM7942l5OzcS8V2iNwMlfz3DU0vcSnsdkigQ9BtXhJJvGznU2SVTwn+3BSdLB2VfoBXz3uuc0DySOw9B3VzinNHBvV0nw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7d5c2245-7346-4121-72f2-08d639eaf66f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4609; x-ms-traffictypediagnostic: BL0PR06MB4609: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4609; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4609; x-forefront-prvs: 083526BF8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(346002)(376002)(396003)(189003)(199004)(13464003)(229853002)(186003)(478600001)(5660300001)(25786009)(14454004)(4326008)(105586002)(106356001)(26005)(54906003)(3846002)(6116002)(110136005)(53546011)(6436002)(2906002)(561944003)(102836004)(316002)(33656002)(2900100001)(39060400002)(305945005)(99286004)(7736002)(74316002)(8676002)(6506007)(9686003)(55016002)(476003)(7696005)(6246003)(81156014)(8936002)(76176011)(81166006)(53936002)(68736007)(66066001)(256004)(14444005)(97736004)(86362001)(486006)(5250100002)(2501003)(11346002)(71200400001)(446003)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4609; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: yVueAokepd/ajIvvXywGm8Hjxa0PXJN2vsNxvNWfizX/3MKQ5uzKwzuzrgnG3meWNGs+qZCGWgPqf+Dx8/QX8RABoUWAXKh0h9DeWK7PSmtKLKIiqe9uTezzI4PZs5wLlWz20PnW6su0vyePagvvJ0jugNx+COk6B55ofipP0CcH8sfd+nKjsg2qQilxjAFxsd0EfQD2eU06iu5uLcjpkW9ju0ND8H84PUIjlh0RKAKTm7WOQ5JeJTNN/n67uJe2wjKr49PseNLJGCArUWb8/SFjiOx1gWHMzfAJBlUlCx6Zn92RZK/p3IYMMUzdY8OKx9K/S9uVuZIl+/eCW+eaZkSWdTZtuvyqes+DEo/qIPg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d5c2245-7346-4121-72f2-08d639eaf66f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 19:57:43.7102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4609 Archived-At: Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 19:57:50 -0000 VGhhbmtzIFBoaWxsaXAuIEdpdmVuIHRoYXQgdGhlIGxpbmsgaW4gdGhlIFVzZSBDYXNlcyBkcmFm dCB0byB0aGUgU2VjdXJpdHkgZHJhZnQgaXMgaW5mb3JtYXRpb25hbCBvbmx5IHRoZW4gaXQgY2Fu J3QgY2F1c2UgYSBwdWJsaWNhdGlvbiBkZWFkbG9jaywgY29ycmVjdD8gDQpUaGFua3MsDQpFdGhh biAoYXMgRGV0TmV0IFVzZSBDYXNlcyBkcmFmdCBlZGl0b3IpLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUGhpbGxpcCBIYWxsYW0tQmFrZXIgPGhhbGxhbUBnbWFpbC5jb20+ IA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI0LCAyMDE4IDk6MDYgQU0NClRvOiBzZWNkaXJA aWV0Zi5vcmcNCkNjOiBkZXRuZXRAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt ZGV0bmV0LXVzZS1jYXNlcy5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOQ0KDQpSZXZpZXdlcjogUGhp bGxpcCBIYWxsYW0tQmFrZXINClJldmlldyByZXN1bHQ6IFJlYWR5DQoNCkkgaGF2ZSByZXZpZXdl ZCB0aGUgZG9jdW1lbnQsIGFuZCBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIFRoZSBkb2N1 bWVudCBpcyBhbiBhbmFseXNpcyBvZiB0aGUgdXNlIGNhc2VzIGFuZCAobm93KSBwcm9wZXJseSBy ZWZlcnMgdG8gYSBzZXBhcmF0ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpU aGUgdXNlIGNhc2VzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhbmQgdGhpcyBz aG91bGQgZ28gZm9yd2FyZCBub3cuDQpIb3dldmVyIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBkb2N1bWVudCBpcyBzdGlsbCBhIHdvcmsgaW4gcHJvZ3Jlc3MsIG5vIGRvY3VtZW50IHNoZXBo ZXJkIGFzc2lnbmVkLiBXaGljaCBpcyBvZiBjb3Vyc2UgcmlnaHQgYW5kIHByb3BlciBmb3IgYSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0byB0aGUgZmluYWwgcHJvcG9zYWwuIEFu ZCBvZiBjb3Vyc2UgaXQgaXMgdXNlZnVsIHRvIG5haWwgZG93biB0aGUgdXNlIGNhc2VzIGJlZm9y ZSBsb29raW5nIGF0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gQnV0IHRoZSB1c2UgY2Fz ZXMgaGF2aW5nIGRlZmVycmVkIHNlY3VyaXR5IHRvIHRoZSBleHRlcm5hbCBkb2N1bWVudCByaXNr cyBjcmVhdGluZyBhIGRlYWRsb2NrIHNpdHVhdGlvbi4NCg0KSXQgaXMgaW1wb3J0YW50IHRoYXQg dGhlIGRvY3VtZW50IGNvbnRhaW4gYSBsaW5rIHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyB0byBiZSBzdXBwbGllZCBidXQgdGhpcyBzaG91bGQgbm90IGhvbGQgdXAgcHVibGljYXRpb24g YXMgYW4gUkZDLg0KDQpNeSBvbmx5IGNvbW1lbnQgb24gdGhlIHJlZmVyZW5jZWQgU0MgZG9jdW1l bnQgYXQgdGhpcyBzdGFnZSBpcyB0aGF0IGl0IG1pZ2h0IGJlIHRoYXQgdGhlIHRlcm0gJ2RldGVy bWluaXN0aWMgbmV0d29ya2luZycgb3ZlcnN0YXRlcyB0aGUgcmVxdWlyZW1lbnRzIGV2aWRlbmNl ZCBieSB0aGUgdXNlIGNhc2VzLiBJbiBtYW55IG9mIHRoZSBjaXRlZCB1c2UgY2FzZXMsIHdoYXQg aXMgcmVxdWlyZWQgaXMgYSBoaWdoZXIgZGVncmVlIG9mIGNvbmZpZGVuY2UgdGhhdCB0aGUgbmV0 d29yayBjaGFyYWN0ZXJpc3RpY3MgbWVldCBjZXJ0YWluIHJlcXVpcmVtZW50cyB0aGFuIGFuIGFi c29sdXRlIGd1YXJhbnRlZS4gSXQgbWlnaHQgYmUgdGhhdCAncHJlZGljdGFibGUgbmV0d29ya2lu ZycgcHJvdmlkZXMgYSBiZXR0ZXIgZGVzY3JpcHRpb24gb2YgdGhvc2UgcmVxdWlyZW1lbnRzLg0K DQo= From nobody Wed Oct 24 15:18:23 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72781130E1A; Wed, 24 Oct 2018 15:18:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: lberger@labn.net, detnet@ietf.org, detnet-chairs@ietf.org, Lou Berger , draft-ietf-detnet-use-cases@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154041950146.6903.13544217898101021155.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 15:18:21 -0700 Archived-At: Subject: [Detnet] Eric Rescorla's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 22:18:22 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3472 COMMENTS S 3.1.1.1.5. > | Availability | 99.9999 | > | precise timing required | Yes | > | Recovery time on node failure | less than 50ms - hitless | > | performance management | Yes, Mandatory | > | Redundancy | Yes | > | Packet loss | 0.1% | Where do these packet loss numbers come from? It seems like if you had a .1% chance of systems damage, that would be bad, S 3.3.2.2. > physical networks leveraging different technologies across the > country: an optical network and a microwave network for instance. > Each protection and automatism system between two points has two > telecommunications circuits, one on each network. Path diversity > between two substations is key. Regardless of the event type > (hurricane, ice storm, etc.), one path shall stay available so the You may want to say "needs to" S 3.3.3. > concepts of: > > o Integrity : data cannot be altered undetectably > > o Authenticity : the telecommunications parties involved must be > validated as genuine FWIW, we typically refer to this as "data origin authentication" and obviously it's kind of inseparable from integrity S 5.1. > These networks may also contain very large numbers of devices, for > example for factories, "big data" acquisition, and the IoT. Given > the large numbers of devices installed, and the potential > pervasiveness of the IoT, this is a huge and very cost-sensitive > market. For example, a 1% cost reduction in some areas could save > $100B This seems like a surprisingly high number given that 100B/.01 ~= 10 trillion and the entire US GDP is 20 trillion. S 7.2.1. > "n", then the next cycle ("n+1") must be lossless). After two or > more consecutive packet losses the network may be considered to be > "down" by the Application. > > As network downtime may impact the whole production system the > required network availability is rather high (99,999%). Nit: you are using period-based decimals elswehre. S 8.1. > where the final product (e.g. Copper) is obtained. Although the > operation is autonomous, the tracks are remotely monitored from a > central facility. > > In pit mines, the monitoring of the tailings or mine dumps is > critical in order to avoid any environmental pollution. In the past, Not a networking issue, but my understanding is that pit mines in practice generate quite a bit of pollution. S 9.1.1. > 9.1.1. Blockchain Operation > > A 'block' runs as a container of a batch of primary items such as > transactions, property records etc. The blocks are chained in such a > way that the hash of the previous block works as the pointer header > of the new block, where confirmation of each block requires a This is not maximally clear. The relevant point is that block N+1 transitively vouches for blocks N and before. S 9.1.2. > items and the blocks to the other nodes. > > When a node initiates, it first requests the other nodes' address > from a specific entity such as DNS, then it creates persistent > connections each of with other nodes. If node A confirms an item, it > sends the item to the other nodes via the persistent connections. This is certainly one design, but it's not the only one. S 9.3. > 9.3. Private Blockchain Future > > Blockchain system performance can be greatly improved through > deterministic networking service primarily because it would > accelerate the consensus process. It would be valuable to be able to > design a private blockchain network with the following properties: Hmm... I'm not sure how persuaded I am by this. Generally the rate of block generation is quite low, compared to any plausible network. S 11.1.8. > > 11.1.8. Mix of Deterministic and Best-Effort Traffic > > DetNet is intended to support coexistance of time-sensitive > operational (OT) traffic and information (IT) traffic on the same > ("unified") network. This seems potentially inconsistent with 11.1.6. Perhaps you mean that 11.1.6 only applies to OT? S 11.5. > addition to arriving with the data content as intended, the data must > also arrive at the expected time. This may present "new" security > challenges to implementers, and must be addressed accordingly. There > are other security implications, including (but not limited to) the > change in attack surface presented by packet replication and > elimination. Do these requirements impose new requirements on the cryptographic algorithms used to verify traffic? From nobody Wed Oct 24 16:41:53 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FD126CC7; Wed, 24 Oct 2018 16:41:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154042451096.6988.14199105482194896622.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 16:41:50 -0700 Archived-At: Subject: [Detnet] Ben Campbell's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 23:41:51 -0000 Ben Campbell has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate the work that went into this draft, and am balloting "No Objection". I also greatly appreciate the fact the draft has text to explain why it would have archival value as an RFC. However, I'm not sure I'm convinced. Much of its value is as input to other WG efforts, which I assume will eventually complete. The remaining value seems to be to provide design context to future users or the technology. While I can sort of accept that, it's an argument that could apply to almost any WG input document. (Note: I don't really expect a change due to this comment.) Other than that, I have some specific comments: *** Substantive *** §2.1.1: Would it be worthwhile to discuss whether Forward Error Correction (FEC) is helpful here? §5.1: "For example, a 1% cost reduction in some areas could save $100B" I really hope the math if off. $100B is 1% of $10T. §9.1.2: "The challenge of blockchain network operation is not overall data rates, since the volume from both block and item stays between hundreds of bytes to a couple of mega bytes per second, but is in transporting the blocks with minimum latency to maximize efficiency of the blockchain consensus process." That needs elaboration. What is the impact of latency on the consensus process? It's not obvious to me from the text how this is more impacted the ''average" application. §17: Are there really no normative references? Please keep in mind that any reference that must be read for the reader to fully understand the draft should be normative. *** Editorial *** - General: -- There are a number of assertions that refer to the current state of technology. Words like "currently" tend to age badly in RFCs. I suggest qualifying those with something to the effect of "At the time of publication...". -- There seems to be some overlap between use cases. I wonder why things like "Wireless for Industrial Applications" and "Mining Industry", which describes an industrial application of wireless, are treated separately. §3.1.1.4: "The IEC (International Electrotechnical Commission) has recently published...": Will not age well. §5, title: "Industrial" is not a noun. I suggest "Wireless for Industrial Applications". §7, title: Please expand M2M in the section title. §7.3: First sentence is a fragment. §8.2, third paragraph: Please define "leaky feeder" §9 and subsections: This section needs proofreading for missing articles and plurals. §9.1.1: s/ "amount of items"/"number of items" §9.1.2: - 2nd paragraph: "initiates" is a transitive verb. A node either initiates _something_, or a node is initiated. - 3rd paragraph: 2nd sentence has multiple comma splices. §9.1.3: typo: "todayt" §10.3, first paragraph: "currently under development" will not age well. From nobody Wed Oct 24 19:29:45 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBB130E0A for ; Wed, 24 Oct 2018 19:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 9kr_t9OxdNyE for ; Wed, 24 Oct 2018 19:29:41 -0700 (PDT) Received: from outbound-ss-579.bluehost.com (outbound-ss-579.bluehost.com [74.220.218.175]) (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 80FBA130DEC for ; Wed, 24 Oct 2018 19:29:41 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id D8D351E08D3 for ; Wed, 24 Oct 2018 20:29:40 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id FVP2gNzMsE0jMFVP2gnF7C; Wed, 24 Oct 2018 20:29:40 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tO45WyaceAOqC9QggUsQlA9CrM30jsgKPkP6WUuhVEU=; b=SQ4xjQvfIoC/ApWb9cyBDmqV/A mFDNLyLdzMLXxSRdHaAPAW169XRFM/DG8aIHNXetUgg/GF0X3X66K+bWBWI+oNOUIY60HnUX/lzhk gpv3vDmT5uTltP2OQkTAWaoQn; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:49664 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gFVP2-000MO9-DH; Wed, 24 Oct 2018 20:29:40 -0600 From: Lou Berger To: DetNet WG , DetNet Chairs Message-ID: <032f3dae-fbfb-6ca9-36e5-f648ea13906e@labn.net> Date: Wed, 24 Oct 2018 22:29:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1gFVP2-000MO9-DH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:49664 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Detnet] Draft IETF103 agenda uploaded X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 02:29:44 -0000 Hi,     A draft agenda is available at: https://datatracker.ietf.org/meeting/103/materials/agenda-103-detnet Please take a look and send any question/comments/corrections you may have. Thank you, Lou (Janos and Ethan) From nobody Wed Oct 24 21:27:01 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9FC128CFD; Wed, 24 Oct 2018 21:26:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154044161243.6891.13225261002580451128.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 21:26:52 -0700 Archived-At: Subject: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 04:26:52 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 6.1.5 3GPP networks have some form of admission control to get access to these time sensitive streams. I think that it is important to mention that here * Section 6.2.1. How does CPRI fit the narrative here for the fronthaul? Do you think it falls under the proprietary protocol and framing category? * Section 7.4 What does burstless mean (especially in the context of low packet loss)? * Section 10.3 A reference to 3GPP TS 23.501 could be useful here to describe the 5G slicing. * Section 12 I did not see much value in this but I am assuming this was put in to keep track of out of scope items during the WG process. Could this be moved to an Appendix? * References The reference for 3GPP TR 38.801 wrongly cites it as an IEEE spec. Please fix this. Typo: * Section 9.1.3. s/todayt/today/ From nobody Wed Oct 24 22:20:10 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2286130E2A; Wed, 24 Oct 2018 22:20:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154044480172.6867.8728934401663813237.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 22:20:01 -0700 Archived-At: Subject: [Detnet] Alvaro Retana's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 05:20:02 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There's a lot of interesting and useful information in this document. Thanks to all who put work into getting it done! It is not hard to tell that sections were written by different authors -- in itself, that is a good thing because it highlights the diversity of the scenarios considered and the applicability of the DetNet technology. However, the result is an uneven treatment of the different use cases, from how they are described (some include more details and others get a higher level description), to even the number of references used. This last point is what I would like to call out as a point of improvement: basically starting in Section 7, none of the use cases have a single reference in them...even when explicitly pointing at a resource, for example: "see the IETF99 Network Slicing BOF session agenda and materials" (§10.6). It would increase the value of the document if relevant references were added. From nobody Thu Oct 25 00:10:31 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7912D4F2; Thu, 25 Oct 2018 00:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154045142958.16251.6742934480115245561.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 00:10:29 -0700 Archived-At: Subject: [Detnet] Adam Roach's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 07:10:30 -0000 Adam Roach has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben's point regarding formal archival value, and would encourage the working group to at least briefly consider the guidance for alternate formats described in the final paragraph of https://www.ietf.org/blog/support-documents-ietf-working-groups/ I don't object to publication of this document, as it was added to the DETNET charter prior to the IESG's guidance on the topic. I simply want to make sure the working group considered and ruled out alternate forms of making the use cases available in light of their goals. On a casual examination, the goals stated in the Introduction of this document would appear to be satisfied by any of the three concrete suggestions given in the IESG guidance I cite above. From nobody Thu Oct 25 02:36:18 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024A6130E08; Thu, 25 Oct 2018 02:36:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 02:36:09 -0700 Archived-At: Subject: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 09:36:10 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-detnet-use-cases-19: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document has useful content but I'm not convinced of its archival value. Consistent with the IESG statement on supporting documents , I am abstaining. Notably, the detnet charter states: "WG sustaining/informational documents may include: These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers: Problem statement and (constrained) deployment environments User-driven use cases" So I would not have expected this document to be published as an RFC. I also could not find any other WG documents referencing this normatively. There are a few places in the document that are particularly problematic for an archival document: 4.2.1 "There are many field protocols used today; some are standards-based and others are proprietary (see standards [lontalk], [modbus], [profibus] and [flnet])." I would suggest s/today/at the time of this writing/ 5.1.2 "Note: Current WG discussion indicates that some peer-to-peer communication must be assumed, i.e. the PCE may communicate only indirectly with any given device, enabling hierarchical configuration of the system." This seems like it could be rendered out of date. I would suggest deleting "Current WG discussion indicates that." 12.4 "Current WG consensus is that this item won't be directly supported by the DetNet architecture, for example because it implies guarantee of in-order delivery of packets which conflicts with the core goal of achieving the lowest possible latency." Same comment as above. I would suggest deleting "Current WG consensus is that." From nobody Thu Oct 25 02:38:41 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8DC130E08; Thu, 25 Oct 2018 02:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=FmyqVHxu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=URV2HW33 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 LNr1t0D9V-Jr; Thu, 25 Oct 2018 02:38:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8277130DEB; Thu, 25 Oct 2018 02:38:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2CB2F20A41; Thu, 25 Oct 2018 05:38:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 25 Oct 2018 05:38:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=A G18ERmLLHqexfI84/Dm+CQ+pr8xqiLJwIFhwI2NwCo=; b=FmyqVHxulhWkCKhBs ug8g0YUkJbbs1JPMU2grTr81NDyxjJs6to45pI5Vc97xDHQT9Etoq/lUt/EGDOLT Bfqp4yZDcrv2WsDx5G3DIvyXcQqtSBFhCOBo03P2yFJsTdy39i1NROaJeqX8hK1/ JZMWaj01l+wgN+08wdtaulUVCJAZQHjKcBzj6f3vhU8KFvzqRfJTZdz8RItm/p81 P1spPMuG65RKQkHiNGHwfX1/C/nByEk5rw9pTyCI3i9T3aCWJ7ygQxUcUSI9FJ+R zCIuTiuiDXlRftxg4Zo9e7VhB57SJq837UUrBv6liZ8t1soTnFmRKBasftCPHaWi TK1qw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=AG18ERmLLHqexfI84/Dm+CQ+pr8xqiLJwIFhwI2Nw Co=; b=URV2HW33OkCz6tPIRjDi4RUf7jelv6v0AnXI8WuCoHBMT+QRRvC5PDMtP TvgRGGm1aSy8CPeiPmiEYzV+QYLlgc8VbqqPQs30XM1dIX1Xy622Fwj1U8+/WPwv kIb+LOya+fzBv6h1S9qFli4S/3uD49sjXR/VzO6CSyAGsKqydGqxCunmtcMP9rdc uEsxOKFBWAUQ/F+LKRwLhlmMYpNGYfAJp4+j7No+Ht/E4wOj5pxKRVA77hAYUBzT 8ZCW7GxQd0knKvCYS3Rtkkhv+W+Gpg0t30EmvvRUrGRdN3cEShU+BsQNJAYgfnox J3MVoZRwH84fPCOKdW6WjknRZIaMw== X-ME-Sender: X-ME-Proxy: Received: from [10.82.174.167] (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id B9688102A0; Thu, 25 Oct 2018 05:38:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153988842454.22239.14448100799142894515@ietfa.amsl.com> Date: Thu, 25 Oct 2018 11:38:30 +0200 Cc: General Area Review Team , detnet@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4209CADA-A09D-4E35-B223-EF6F0ACDF6B1@cooperw.in> References: <153988842454.22239.14448100799142894515@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] [Gen-art] Genart telechat review of draft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 09:38:39 -0000 Pete, thank your for your reviews. Ethan, thanks for your responses. I = have entered an Abstain ballot for reasons unrelated to the Gen-ART = review. Alissa > On Oct 18, 2018, at 8:47 PM, Pete Resnick = wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-detnet-use-cases-19 > Reviewer: Pete Resnick > Review Date: 2018-10-18 > IETF LC End Date: 2018-10-03 > IESG Telechat date: 2018-10-25 >=20 > Summary: Ready >=20 > Thanks for the updates to address my previous comments. Good to go. >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: None. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Oct 25 05:50:31 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC12128A5C; Thu, 25 Oct 2018 05:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org, Georg Mayer X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154047183004.16297.1395901673621499861.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 05:50:30 -0700 Archived-At: Subject: [Detnet] Spencer Dawkins' No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 12:50:30 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-detnet-use-cases-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Most of my comments have appeared in other AD's ballot positions, which is always handy when I ballot an hour and a half before a telechat, but when I noticed that Section 6 (almost in its entirety) and Section 10.3 are describing 3GPP environments, and I hadn't seen any traffic on the 3gpp-ietf-coordination mailing list about this draft, I checked last night with Georg Meyer, the 3GPP liaison to IETF, and he said he remembered discussions about this draft in SA2, but wasn't remembering recent discussions. He's in a meeting this week, and said he would check the draft next week. I don't think there's any reason for me to expect a problem, but given that Georg had been quite clear in previous discussions on Netslicing that 3GPP didn't have requirements for the IETF yet, it seemed helpful to make sure that 3GPP agrees with what's being said about 3GPP networks in IETF documents. I'm actually fine publishing this draft in archival form, because if there are SDOs that AREN'T worried about any of these use cases, I sure can't think of them, so I'd expect that this would be useful in coordinating with other SDOs, and more broadly with implementers and operators who don't participate in the IETF, and I'm not Deferring or Discussing, because I'm sure the right thing will happen, whether the draft is approved today or not. But I thought I should ask now, rather than 5 minutes after the RFC is announced :-) From nobody Thu Oct 25 07:00:51 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE981292F1; Thu, 25 Oct 2018 07:00:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-detnet-use-cases@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154047604123.16342.17879381711877381417.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 07:00:41 -0700 Archived-At: Subject: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-iet?= =?utf-8?q?f-detnet-use-cases-19=3A_=28with_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 14:00:42 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-detnet-use-cases-19: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I unfortunately did not have the time to read this doc in detail which is the main reason for my abstain. However, having a quick look at the doc, I'm also not convinced that all described use cases are actually relevant for detnet (while these use case are important in general) or could be addressed with much simpler solutions (like an appropriate diffserv configuration in an controlled network) instead. From nobody Thu Oct 25 09:07:00 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6D130EA2; Thu, 25 Oct 2018 09:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntqvwgHKUOio; Thu, 25 Oct 2018 09:06:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 B8FC8130EA0; Thu, 25 Oct 2018 09:06:49 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9PG1CJ6001547; Thu, 25 Oct 2018 12:06:45 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2nbgmk0wq4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Oct 2018 12:06:44 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9PG6g1S015818; Thu, 25 Oct 2018 12:06:42 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9PG6cXE015734; Thu, 25 Oct 2018 12:06:38 -0400 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id B0B4F4039457; Thu, 25 Oct 2018 16:06:38 +0000 (GMT) Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (unknown [130.9.129.150]) by zlp27128.vci.att.com (Service) with ESMTPS id 990A44039455; Thu, 25 Oct 2018 16:06:38 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.89]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0415.000; Thu, 25 Oct 2018 12:06:38 -0400 From: "BRUNGARD, DEBORAH A" To: Alissa Cooper , The IESG CC: "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Thread-Topic: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) Thread-Index: AQHUbEYuj6dHz+RT2ki5ZyKWS9seqqUv+gXw Date: Thu, 25 Oct 2018 16:06:38 +0000 Message-ID: References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> In-Reply-To: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.141.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250133 Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 16:06:55 -0000 SGkgQWxpc3NhLA0KDQpNdWNoIHRoYW5rcyBmb3IgeW91ciBjYXJlZnVsIHJldmlldy4gSSB3YW50 ZWQgdG8gYWRkcmVzcyBvbmUgaXRlbSwgSSdsbCBsZXQgdGhlIGF1dGhvcnMgcmVzcG9uZCBvbiB0 aGUgb3RoZXJzLg0KDQpXaGlsZSBJIHVuZGVyc3RhbmQgeW91ciBjb21tZW50IGlzIG5vbi1ibG9j a2luZyBvbiB0aGUgZG9jdW1lbnQsIEkgd2FudGVkIHRvIHVuZGVyc3RhbmQgeW91ciBjb21tZW50 IHRoYXQgeW91IGFyZSBhYnN0YWluaW5nIHRvIGJlICJjb25zaXN0ZW50IiB3aXRoIHRoZSBJRVNH IHN0YXRlbWVudCBvbiBzdXBwb3J0IGRvY3VtZW50cy4gVGhlIElFU0cgc3RhdGVtZW50ICh0byBt ZSkgd2FzIG5vdCBibG9ja2luZyB0aGUgcHVibGljYXRpb24gb2Ygc3VwcG9ydCBkb2N1bWVudHMu IFRvIG1lLCBpdCB3YXMgYWRkcmVzc2luZyB0aGUgY29uY2VybiBvbiBzdXBwb3J0IGRvY3VtZW50 cyBob2xkaW5nIHVwIHRoZSBjb21tZW5jZW1lbnQgb2Ygc29sdXRpb24gd29yay4NCg0KSGVyZSdz IHdoeSBJIHN1cHBvcnRlZCB0aGlzIGRvY3VtZW50IGZvciBwdWJsaWNhdGlvbjoNCg0KLSBCYXNl ZCBvbiB0aGUgd29ya2luZyBncm91cCBhbmQgQ2hhaXJzIGFncmVlbWVudCB0byBwdWJsaXNoLiBU aGUgY2hhcnRlciBkb2VzIG5vdCBwcmV2ZW50IHB1YmxpY2F0aW9uLiBUaGlzIGNoYXJ0ZXIgdGV4 dCB3YXMgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgd2hlbiB0aGUgZ3JvdXAgd2FzIGNoYXJ0ZXJlZCBh cyBpdCB3YXMgZmVsdCBieSB0aGUgSUVTRyBhdCB0aGF0IHRpbWUgdGhhdCBpdCB3YXMgbm90IGZv ciB0aGUgSUVTRyB0byBwcmV2ZW50IHB1YmxpY2F0aW9uIG9mIGEgc3VwcG9ydCBkb2N1bWVudC4N Ci0gVGhlIGRvY3VtZW50IHNoZXBoZXJkIHdyaXRldXAgc2F5cyAiVGhpcyBkb2N1bWVudCBwcm92 aWRlcyBjb250ZXh0IGZvciB0aGUgRGV0TmV0IFdHIGFuZCBoYXMgZ3VpZGVkIHRoZSBkZXZlbG9w bWVudCBvZiBvdGhlciBXRyBkb2N1bWVudHMuIiBOb3Qgc3VyZSBvbiB5b3VyIGNvbW1lbnQganVz dGlmeWluZyBub3QtdG8tcHVibGlzaCBhcyB0aGUgZG9jdW1lbnQgaXMgbm90IG5vcm1hdGl2ZWx5 IHJlZmVyZW5jZWQsIHRoZSBkb2N1bWVudCBpcyBpbmZvcm1hdGl2ZWx5IHJlZmVyZW5jZWQgKHR5 cGljYWwgYXMgaXQgaXMgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCkgYnkgb3RoZXIgZG9jdW1l bnRzLg0KLSAgUGVyIHRoZSBJRVNHIHN0YXRlbWVudCwgdGhpcyBkb2N1bWVudCBoYXMgbm90IHBy ZXZlbnRlZCB0aGUgY29tbWVuY2VtZW50IG9mIHNvbHV0aW9uIHdvcmsuIENvbnZlcnNlbHksIGl0 IGhhcyBncmVhdGx5IGhlbHBlZCB0byBzY29wZSB0aGUgc29sdXRpb24gd29yay4NCi0gTW9zdCBp bXBvcnRhbnQgZm9yIHRoaXMgZG9jdW1lbnQgYXJlIHRoZSBub24tcHJvY2VkdXJhbCBhc3BlY3Rz IHN1cHBvcnRpbmcgcHVibGljYXRpb24uIEFzIHRoaXMgd29yayBpcyBjbG9zZWx5IGFsaWduZWQg d2l0aCBJRUVFJ3MgVFNOIHdvcmssIGhhdmluZyBhbiBSRkMgc2hvd3MgdGhlIGNvbnNlbnN1cyBv ZiB0aGUgd29ya2luZyBncm91cC4gRm9yIG90aGVyIFNET3MsIGEgd2lraSBkb2VzIG5vdCBoYXZl ICJjb25zZW5zdXMiLiBBcyB0aGUgYXV0aG9yIGxpc3QgaW5kaWNhdGVzLCB0aGUgZG9jdW1lbnQg aGFkIGlucHV0IGZyb20gYSBkaXZlcnNlIHNldCBvZiB0aGUgY29tbXVuaXR5LiBBcyBTcGVuY2Vy IHNheXMsIGl0IHByb3ZpZGVzIGNvbnRleHQgZm9yIG9wZXJhdG9ycyBhbmQgdmVuZG9ycyBub3Qg cGFydGljaXBhdGluZyBpbiBJRVRGLiBBbmQgYXMgdGhlIEdlbmFydCByZXZpZXdlciBzYXlzICJy ZWFsbHkgY29vbCBkb2N1bWVudCB0byByZWFkIi4gRm9yIG1hbnkgb3BlcmF0b3JzL3VzZXJzLCBp bmZvcm1hdGlvbmFsIGRvY3VtZW50cyBhcmUgYSBtZWFucyB0byBwYXJ0aWNpcGF0ZSB3aXRob3V0 IHNob3dpbmcgcHJlZmVyZW5jZSBmb3Igb25lIHNvbHV0aW9uIG9yIGFub3RoZXIuDQoNClBlcmhh cHMsIEkgb3IgdGhlIGRvY3VtZW50IHNoZXBoZXJkIHNob3VsZCBoYXZlIGluY2x1ZGVkIHRoaXMg anVzdGlmaWNhdGlvbiBpbiBvdXIgd3JpdGV1cHMgc28gYXMgdG8gaGF2ZSBnYWluZWQgeW91ciBz dXBwb3J0IGZvciBwdWJsaXNoaW5nIHRoZSBkb2N1bWVudC4gV2UgY2FuIHRhbGsgbW9yZSBhbW9u ZyB0aGUgSUVTRyBvbiB0aGlzIHNvIGFzIG5vdCB0byBjb25mdXNlIHRoZSBjb21tdW5pdHkgb24g d2hhdCB0aGUgSUVTRyBzdGF0ZW1lbnQgc2F5cyB3aGVuIGNvbnNpZGVyaW5nIGZ1dHVyZSByZXF1 ZXN0cyBmb3IgcHVibGlzaGluZyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cy4NCg0KVGhhbmtzIGFn YWluIGV2ZXJ5b25lIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3cyENCkRlYm9yYWgNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQWxpc3NhIENvb3Blcg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjUs IDIwMTggNTozNiBBTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRldG5ldC1j aGFpcnNAaWV0Zi5vcmc7IGRldG5ldEBpZXRmLm9yZzsgbGJlcmdlckBsYWJuLm5ldDsgZHJhZnQt aWV0Zi1kZXRuZXQtdXNlLWNhc2VzQGlldGYub3JnDQpTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3Mg QWJzdGFpbiBvbiBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTk6ICh3aXRoIENPTU1FTlQp DQoNCkFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQpkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTk6IEFic3RhaW4NCg0KV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K DQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3Jp dGVyaWEuaHRtbCZkPUR3SUNhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj0tdWZMcU9udHQ2 TGVqTE1UYk4zUXBqWUh4c09ieG1QS1JoaUYzRm5tb0kwJm09S2s0VGltN1QxeG9NXzU3aXI0NEl1 SWl3amRMSmZZYWduRGJsNDlhcjBVayZzPWFHbjhnaC1PYWFhTnBWSDRxLUF3QmM2OWt6MVl1S202 cGtsakgtS3NvTzgmZT0NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19k b2NfZHJhZnQtMkRpZXRmLTJEZGV0bmV0LTJEdXNlLTJEY2FzZXNfJmQ9RHdJQ2FRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPS11ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhpRjNG bm1vSTAmbT1LazRUaW03VDF4b01fNTdpcjQ0SXVJaXdqZExKZllhZ25EYmw0OWFyMFVrJnM9WEIw N1B1Q3Q5ei1va2F0cUYwbzdWVEdSWHRUYUljYmo2TlRpUGhmYWFydyZlPQ0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBkb2N1bWVudCBoYXMgdXNl ZnVsIGNvbnRlbnQgYnV0IEknbSBub3QgY29udmluY2VkIG9mIGl0cyBhcmNoaXZhbCB2YWx1ZS4N CkNvbnNpc3RlbnQgd2l0aCB0aGUgSUVTRyBzdGF0ZW1lbnQgb24gc3VwcG9ydGluZyBkb2N1bWVu dHMgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX2Jsb2dfc3VwcG9ydC0yRGRvY3VtZW50cy0yRGlldGYtMkR3b3JraW5nLTJE Z3JvdXBzXy0zRnByaW1hcnktNUZ0b3BpYy0zRDctMjYmZD1Ed0lDYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9LXVmTHFPbnR0NkxlakxNVGJOM1FwallIeHNPYnhtUEtSaGlGM0ZubW9JMCZt PUtrNFRpbTdUMXhvTV81N2lyNDRJdUlpd2pkTEpmWWFnbkRibDQ5YXIwVWsmcz1DaFVSQmJTMlQt UUVNajJFczh2Mkt5MWMybmlQV1R4ZkRnQTR5TU84VXVnJmU9PiwNCkkgYW0gYWJzdGFpbmluZy4g Tm90YWJseSwgdGhlIGRldG5ldCBjaGFydGVyIHN0YXRlczoNCg0KIldHIHN1c3RhaW5pbmcvaW5m b3JtYXRpb25hbCBkb2N1bWVudHMgbWF5IGluY2x1ZGU6DQoNClRoZXNlIGRvY3VtZW50cyBtYXkg bm90IG5lY2Vzc2FyaWx5IGJlIHB1Ymxpc2hlZCwgYnV0IG1heSBiZSBtYWludGFpbmVkIGluIGEg ZHJhZnQgZm9ybSBvciBvbiBhIGNvbGxhYm9yYXRpdmUgV29ya2luZyBHcm91cCB3aWtpIHRvIHN1 cHBvcnQgdGhlIGVmZm9ydHMgb2YgdGhlIFdvcmtpbmcgR3JvdXAgYW5kIGhlbHAgbmV3IGNvbWVy czoNCg0KUHJvYmxlbSBzdGF0ZW1lbnQgYW5kIChjb25zdHJhaW5lZCkgZGVwbG95bWVudCBlbnZp cm9ubWVudHMgVXNlci1kcml2ZW4gdXNlIGNhc2VzIg0KDQpTbyBJIHdvdWxkIG5vdCBoYXZlIGV4 cGVjdGVkIHRoaXMgZG9jdW1lbnQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIFJGQy4gSSBhbHNvIGNv dWxkIG5vdCBmaW5kIGFueSBvdGhlciBXRyBkb2N1bWVudHMgcmVmZXJlbmNpbmcgdGhpcyBub3Jt YXRpdmVseS4NCg0KVGhlcmUgYXJlIGEgZmV3IHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBh cmUgcGFydGljdWxhcmx5IHByb2JsZW1hdGljIGZvciBhbiBhcmNoaXZhbCBkb2N1bWVudDoNCg0K NC4yLjENCg0KIlRoZXJlIGFyZSBtYW55IGZpZWxkIHByb3RvY29scyB1c2VkIHRvZGF5OyBzb21l IGFyZSBzdGFuZGFyZHMtYmFzZWQNCiAgIGFuZCBvdGhlcnMgYXJlIHByb3ByaWV0YXJ5IChzZWUg c3RhbmRhcmRzIFtsb250YWxrXSwgW21vZGJ1c10sDQogICBbcHJvZmlidXNdIGFuZCBbZmxuZXRd KS4iDQoNCkkgd291bGQgc3VnZ2VzdCBzL3RvZGF5L2F0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGlu Zy8NCg0KNS4xLjINCg0KIk5vdGU6IEN1cnJlbnQgV0cgZGlzY3Vzc2lvbiBpbmRpY2F0ZXMgdGhh dCBzb21lIHBlZXItdG8tcGVlcg0KICAgY29tbXVuaWNhdGlvbiBtdXN0IGJlIGFzc3VtZWQsIGku ZS4gdGhlIFBDRSBtYXkgY29tbXVuaWNhdGUgb25seQ0KICAgaW5kaXJlY3RseSB3aXRoIGFueSBn aXZlbiBkZXZpY2UsIGVuYWJsaW5nIGhpZXJhcmNoaWNhbCBjb25maWd1cmF0aW9uDQogICBvZiB0 aGUgc3lzdGVtLiINCg0KVGhpcyBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIHJlbmRlcmVkIG91dCBv ZiBkYXRlLiBJIHdvdWxkIHN1Z2dlc3QgZGVsZXRpbmcgIkN1cnJlbnQgV0cgZGlzY3Vzc2lvbiBp bmRpY2F0ZXMgdGhhdC4iDQoNCjEyLjQNCg0KIkN1cnJlbnQgV0cgY29uc2Vuc3VzIGlzIHRoYXQg dGhpcyBpdGVtIHdvbid0IGJlDQogICBkaXJlY3RseSBzdXBwb3J0ZWQgYnkgdGhlIERldE5ldCBh cmNoaXRlY3R1cmUsIGZvciBleGFtcGxlIGJlY2F1c2UgaXQNCiAgIGltcGxpZXMgZ3VhcmFudGVl IG9mIGluLW9yZGVyIGRlbGl2ZXJ5IG9mIHBhY2tldHMgd2hpY2ggY29uZmxpY3RzDQogICB3aXRo IHRoZSBjb3JlIGdvYWwgb2YgYWNoaWV2aW5nIHRoZSBsb3dlc3QgcG9zc2libGUgbGF0ZW5jeS4i DQoNClNhbWUgY29tbWVudCBhcyBhYm92ZS4gSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nICJDdXJy ZW50IFdHIGNvbnNlbnN1cyBpcyB0aGF0LiINCg0KDQo= From nobody Thu Oct 25 11:01:41 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68721130E05; Thu, 25 Oct 2018 11:01:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-problem-statement.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154049050040.15652.1135893758057744905@ietfa.amsl.com> Date: Thu, 25 Oct 2018 11:01:40 -0700 Archived-At: Subject: [Detnet] Genart last call review of draft-ietf-detnet-problem-statement-07 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 18:01:40 -0000 Reviewer: Matthew Miller Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: Reviewer: Matthew A. Miller Review Date: 2018-10-25 IETF LC End Date: 2018-10-03 IESG Telechat date: N/A Summary: Ready to publish as an Informational Draft, though there are nits that ought to be addressed before publication. Major issues: NONE Minor issues: NONE Nits/editorial comments: * In Section 3.1. "Supported topologies" paragraph 2, the word "an" should be "an" in the phrase "a tunnel between and ingress and an egress router". * In Section 3.1. "Supported topologies" paragraph 2, the word "of" should be "or" in the phrase "... the path is end-to-end of a tunnel.". From nobody Thu Oct 25 11:12:53 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E997A130E3A; Thu, 25 Oct 2018 11:12:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGQahnvoW6qP; Thu, 25 Oct 2018 11:12:50 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406EF130E01; Thu, 25 Oct 2018 11:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fKr0oIWbJDQFUkyQDGnITrgwfPXwgVWYzkBmxbQ1Njo=; b=Db/M/oCvHFLM+vnFsGch/TmYYa0RjztUL6dr7om63Vzq3uSCB+O0ENVnOU9ZQFhS7KK+zYHshqtdlaiMVd8VEa897JELTOv3Z/LT1MNav0GwpETTxx6edR3D6DJT7TRi9X3kQTSTNrJ4EHOH0OFnz0wSMXkMnm/uU3d+VKeS/fk= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4402.namprd06.prod.outlook.com (10.167.181.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Thu, 25 Oct 2018 18:12:46 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8%3]) with mapi id 15.20.1250.028; Thu, 25 Oct 2018 18:12:46 +0000 From: "Grossman, Ethan A." To: "BRUNGARD, DEBORAH A" , Alissa Cooper , The IESG CC: "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Thread-Topic: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) Thread-Index: AQHUbEYswG457J13jUKObmAWmXXcwqUwIN4AgAAifQA= Date: Thu, 25 Oct 2018 18:12:46 +0000 Message-ID: References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4402; 6:bIEPksdAzJF6d0Yo22A7vdhLPYsxowIHr9E9HmVE5LqIOlY0D0qy1n9UoZtPNiXlsQLNKrXmM5IkXGPXQcNv4aX6Sca3GUTsAEI1DlGNzsUBzjbp5OqZnW9xJP4F+mRFFMJkYIQf/AW0fB0pgl5xFbVWitr7hshTYRY9vZat9Ee2EOA7YyviYU6KE6B3WIiYvKLCHURGw+IQZAIjD+p0YCCq7HaV7C56G5PSuKdIJ8kQZlEKUhC9zm0d4dUW/se4TxHVETeZ3l9qhIGirkkVDBi8m311otN+hifCBTdI3G2ixfp0WOL4we7YmQe5onTRFp7xDYaDBq1uMAT9V9/yiVVgqGRKZR5KqzfETskOglRMFN1Fl8hRuNjhSXl8I/oAaM4qzdI/dSWV7xbZ+86SMCmPPIH1tdW7jzCdDJ4nrk2FqP3PfVN1nUelfuipmdnJvCZLiOXMmpZ/gwWOVZIStg==; 5:jEks1dE8agj8iB3bZlfhAatkVm5K7FR5d4FfdFx4I3earpGcWxwHkcnbwr07WEv/F7W/ulkDyArPuwz8A2zyFpekuc0NyOeoK0FfW4zgY5eYcTjB5gWE0f0jMKyPs/7z0Es+jE58zGzlqs+LZzeIMplRhMAeZ27J3kOSoB/du4U=; 7:pKGGuk9oh8XRyktm5oTeTN7vZsfcav2B2A3QfFLXWgf6gTzNyBOEfCQHKasixDbOfsZQ5GrkvodDx8OH/rpzzKpmI5o49YRy8ls8ic/pz7ALk9CTQAg9LKlOXkwbdulACaTBYtaj2+tqH9uS5z2JcCxx3afLkkT/FKWfhSUw4vw03N+Fldmhk86A0SuK1+BLEXxNi3fapAPOFbFSWBgyNiARQ/XI7FhAqJwukqyHF5EFIFK5IYw0gH07lftIWWv5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4786fe08-7a4b-4597-70e5-08d63aa57765 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4402; x-ms-traffictypediagnostic: BL0PR06MB4402: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(10436049006162)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4402; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4402; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(396003)(346002)(376002)(13464003)(189003)(199004)(476003)(5250100002)(7696005)(2906002)(11346002)(106356001)(3846002)(229853002)(6436002)(66066001)(9686003)(55016002)(6306002)(446003)(53936002)(86362001)(26005)(97736004)(6246003)(102836004)(305945005)(486006)(575784001)(186003)(7736002)(53546011)(6506007)(76176011)(110136005)(256004)(966005)(316002)(105586002)(71190400001)(6116002)(74316002)(71200400001)(14444005)(99286004)(33656002)(4326008)(81156014)(478600001)(8676002)(68736007)(14454004)(81166006)(5660300001)(54906003)(25786009)(2900100001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4402; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ehKezHie4lZqHIoiZvfO9RRAK+PSmQgVaOScnp8FEqAJUBRbc9JuLrMIIDME5Ss9w1lN5RSwjnaR5dKHQLYsNbR6l5L53efzldzAh/3oGwHnCRGK/ZyiGyeGayjR3C0LRIMb9DozYGg4RxiaMjW8ox7wShMduF5q4MgC+e+ZBPDGuKkhHb+zWrZ7vJ7WyYPmzug/Qw0dzdYld6fxRLkjDEP2FeUth0AuAZpBsH6W39AfwXeU8HffltLaJuJCrWsbHk9geUIU9MTYlGEnpFTpRyHG5k+Z8BW1DCg7k0D4TV9ZGINRNQeQMvsG7xFHXHwbyPifRvuojpprzYa1b3Vni2JD/0h3tbyLQqaqEe+C60Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4786fe08-7a4b-4597-70e5-08d63aa57765 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 18:12:46.5561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4402 Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 18:12:53 -0000 SGkgQWxpc3NhLA0KUmVnYXJkaW5nIHRoZSB3b3JkaW5nIHRoYXQgeW91IHBvaW50IG91dCBpcyAi cHJvYmxlbWF0aWMgZm9yIGFuIGFyY2hpdmFsIGRvY3VtZW50IiBJIGNvbXBsZXRlbHkgYWdyZWUs IEkganVzdCBtaXNzZWQgdGhvc2UsIGFuZCB0aGV5IHNob3VsZCBjZXJ0YWlubHkgYmUgY2hhbmdl ZCBhcyB5b3Ugc3VnZ2VzdC4gDQpUaGFua3MsDQpFdGhhbiAoYXMgRWRpdG9yIG9mIERldE5ldCBV c2UgQ2FzZXMgZHJhZnQpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCUlVO R0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNvbT4gDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyNSwgMjAxOCA5OjA3IEFNDQpUbzogQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+ OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkZXRuZXQtY2hhaXJzQGlldGYub3JnOyBk ZXRuZXRAaWV0Zi5vcmc7IGxiZXJnZXJAbGFibi5uZXQ7IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1j YXNlc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IEFsaXNzYSBDb29wZXIncyBBYnN0YWluIG9uIGRy YWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xOTogKHdpdGggQ09NTUVOVCkNCg0KSGkgQWxpc3Nh LA0KDQpNdWNoIHRoYW5rcyBmb3IgeW91ciBjYXJlZnVsIHJldmlldy4gSSB3YW50ZWQgdG8gYWRk cmVzcyBvbmUgaXRlbSwgSSdsbCBsZXQgdGhlIGF1dGhvcnMgcmVzcG9uZCBvbiB0aGUgb3RoZXJz Lg0KDQpXaGlsZSBJIHVuZGVyc3RhbmQgeW91ciBjb21tZW50IGlzIG5vbi1ibG9ja2luZyBvbiB0 aGUgZG9jdW1lbnQsIEkgd2FudGVkIHRvIHVuZGVyc3RhbmQgeW91ciBjb21tZW50IHRoYXQgeW91 IGFyZSBhYnN0YWluaW5nIHRvIGJlICJjb25zaXN0ZW50IiB3aXRoIHRoZSBJRVNHIHN0YXRlbWVu dCBvbiBzdXBwb3J0IGRvY3VtZW50cy4gVGhlIElFU0cgc3RhdGVtZW50ICh0byBtZSkgd2FzIG5v dCBibG9ja2luZyB0aGUgcHVibGljYXRpb24gb2Ygc3VwcG9ydCBkb2N1bWVudHMuIFRvIG1lLCBp dCB3YXMgYWRkcmVzc2luZyB0aGUgY29uY2VybiBvbiBzdXBwb3J0IGRvY3VtZW50cyBob2xkaW5n IHVwIHRoZSBjb21tZW5jZW1lbnQgb2Ygc29sdXRpb24gd29yay4NCg0KSGVyZSdzIHdoeSBJIHN1 cHBvcnRlZCB0aGlzIGRvY3VtZW50IGZvciBwdWJsaWNhdGlvbjoNCg0KLSBCYXNlZCBvbiB0aGUg d29ya2luZyBncm91cCBhbmQgQ2hhaXJzIGFncmVlbWVudCB0byBwdWJsaXNoLiBUaGUgY2hhcnRl ciBkb2VzIG5vdCBwcmV2ZW50IHB1YmxpY2F0aW9uLiBUaGlzIGNoYXJ0ZXIgdGV4dCB3YXMgY2Fy ZWZ1bGx5IGNvbnNpZGVyZWQgd2hlbiB0aGUgZ3JvdXAgd2FzIGNoYXJ0ZXJlZCBhcyBpdCB3YXMg ZmVsdCBieSB0aGUgSUVTRyBhdCB0aGF0IHRpbWUgdGhhdCBpdCB3YXMgbm90IGZvciB0aGUgSUVT RyB0byBwcmV2ZW50IHB1YmxpY2F0aW9uIG9mIGEgc3VwcG9ydCBkb2N1bWVudC4NCi0gVGhlIGRv Y3VtZW50IHNoZXBoZXJkIHdyaXRldXAgc2F5cyAiVGhpcyBkb2N1bWVudCBwcm92aWRlcyBjb250 ZXh0IGZvciB0aGUgRGV0TmV0IFdHIGFuZCBoYXMgZ3VpZGVkIHRoZSBkZXZlbG9wbWVudCBvZiBv dGhlciBXRyBkb2N1bWVudHMuIiBOb3Qgc3VyZSBvbiB5b3VyIGNvbW1lbnQganVzdGlmeWluZyBu b3QtdG8tcHVibGlzaCBhcyB0aGUgZG9jdW1lbnQgaXMgbm90IG5vcm1hdGl2ZWx5IHJlZmVyZW5j ZWQsIHRoZSBkb2N1bWVudCBpcyBpbmZvcm1hdGl2ZWx5IHJlZmVyZW5jZWQgKHR5cGljYWwgYXMg aXQgaXMgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCkgYnkgb3RoZXIgZG9jdW1lbnRzLg0KLSAg UGVyIHRoZSBJRVNHIHN0YXRlbWVudCwgdGhpcyBkb2N1bWVudCBoYXMgbm90IHByZXZlbnRlZCB0 aGUgY29tbWVuY2VtZW50IG9mIHNvbHV0aW9uIHdvcmsuIENvbnZlcnNlbHksIGl0IGhhcyBncmVh dGx5IGhlbHBlZCB0byBzY29wZSB0aGUgc29sdXRpb24gd29yay4NCi0gTW9zdCBpbXBvcnRhbnQg Zm9yIHRoaXMgZG9jdW1lbnQgYXJlIHRoZSBub24tcHJvY2VkdXJhbCBhc3BlY3RzIHN1cHBvcnRp bmcgcHVibGljYXRpb24uIEFzIHRoaXMgd29yayBpcyBjbG9zZWx5IGFsaWduZWQgd2l0aCBJRUVF J3MgVFNOIHdvcmssIGhhdmluZyBhbiBSRkMgc2hvd3MgdGhlIGNvbnNlbnN1cyBvZiB0aGUgd29y a2luZyBncm91cC4gRm9yIG90aGVyIFNET3MsIGEgd2lraSBkb2VzIG5vdCBoYXZlICJjb25zZW5z dXMiLiBBcyB0aGUgYXV0aG9yIGxpc3QgaW5kaWNhdGVzLCB0aGUgZG9jdW1lbnQgaGFkIGlucHV0 IGZyb20gYSBkaXZlcnNlIHNldCBvZiB0aGUgY29tbXVuaXR5LiBBcyBTcGVuY2VyIHNheXMsIGl0 IHByb3ZpZGVzIGNvbnRleHQgZm9yIG9wZXJhdG9ycyBhbmQgdmVuZG9ycyBub3QgcGFydGljaXBh dGluZyBpbiBJRVRGLiBBbmQgYXMgdGhlIEdlbmFydCByZXZpZXdlciBzYXlzICJyZWFsbHkgY29v bCBkb2N1bWVudCB0byByZWFkIi4gRm9yIG1hbnkgb3BlcmF0b3JzL3VzZXJzLCBpbmZvcm1hdGlv bmFsIGRvY3VtZW50cyBhcmUgYSBtZWFucyB0byBwYXJ0aWNpcGF0ZSB3aXRob3V0IHNob3dpbmcg cHJlZmVyZW5jZSBmb3Igb25lIHNvbHV0aW9uIG9yIGFub3RoZXIuDQoNClBlcmhhcHMsIEkgb3Ig dGhlIGRvY3VtZW50IHNoZXBoZXJkIHNob3VsZCBoYXZlIGluY2x1ZGVkIHRoaXMganVzdGlmaWNh dGlvbiBpbiBvdXIgd3JpdGV1cHMgc28gYXMgdG8gaGF2ZSBnYWluZWQgeW91ciBzdXBwb3J0IGZv ciBwdWJsaXNoaW5nIHRoZSBkb2N1bWVudC4gV2UgY2FuIHRhbGsgbW9yZSBhbW9uZyB0aGUgSUVT RyBvbiB0aGlzIHNvIGFzIG5vdCB0byBjb25mdXNlIHRoZSBjb21tdW5pdHkgb24gd2hhdCB0aGUg SUVTRyBzdGF0ZW1lbnQgc2F5cyB3aGVuIGNvbnNpZGVyaW5nIGZ1dHVyZSByZXF1ZXN0cyBmb3Ig cHVibGlzaGluZyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cy4NCg0KVGhhbmtzIGFnYWluIGV2ZXJ5 b25lIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3cyENCkRlYm9yYWgNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgQWxpc3NhIENvb3Blcg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjUsIDIwMTggNToz NiBBTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRldG5ldC1jaGFpcnNAaWV0 Zi5vcmc7IGRldG5ldEBpZXRmLm9yZzsgbGJlcmdlckBsYWJuLm5ldDsgZHJhZnQtaWV0Zi1kZXRu ZXQtdXNlLWNhc2VzQGlldGYub3JnDQpTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgQWJzdGFpbiBv biBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTk6ICh3aXRoIENPTU1FTlQpDQoNCkFsaXNz YSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpk cmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTk6IEFic3RhaW4NCg0KV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFz ZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19pZXNnX3N0YXRlbWVudF9kaXNjdXNzLTJEY3JpdGVyaWEuaHRt bCZkPUR3SUNhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj0tdWZMcU9udHQ2TGVqTE1UYk4z UXBqWUh4c09ieG1QS1JoaUYzRm5tb0kwJm09S2s0VGltN1QxeG9NXzU3aXI0NEl1SWl3amRMSmZZ YWduRGJsNDlhcjBVayZzPWFHbjhnaC1PYWFhTnBWSDRxLUF3QmM2OWt6MVl1S202cGtsakgtS3Nv TzgmZT0NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQt MkRpZXRmLTJEZGV0bmV0LTJEdXNlLTJEY2FzZXNfJmQ9RHdJQ2FRJmM9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZyPS11ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhpRjNGbm1vSTAmbT1L azRUaW03VDF4b01fNTdpcjQ0SXVJaXdqZExKZllhZ25EYmw0OWFyMFVrJnM9WEIwN1B1Q3Q5ei1v a2F0cUYwbzdWVEdSWHRUYUljYmo2TlRpUGhmYWFydyZlPQ0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Q09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBkb2N1bWVudCBoYXMgdXNlZnVsIGNvbnRl bnQgYnV0IEknbSBub3QgY29udmluY2VkIG9mIGl0cyBhcmNoaXZhbCB2YWx1ZS4NCkNvbnNpc3Rl bnQgd2l0aCB0aGUgSUVTRyBzdGF0ZW1lbnQgb24gc3VwcG9ydGluZyBkb2N1bWVudHMgPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX2Jsb2dfc3VwcG9ydC0yRGRvY3VtZW50cy0yRGlldGYtMkR3b3JraW5nLTJEZ3JvdXBzXy0z RnByaW1hcnktNUZ0b3BpYy0zRDctMjYmZD1Ed0lDYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2akln JnI9LXVmTHFPbnR0NkxlakxNVGJOM1FwallIeHNPYnhtUEtSaGlGM0ZubW9JMCZtPUtrNFRpbTdU MXhvTV81N2lyNDRJdUlpd2pkTEpmWWFnbkRibDQ5YXIwVWsmcz1DaFVSQmJTMlQtUUVNajJFczh2 Mkt5MWMybmlQV1R4ZkRnQTR5TU84VXVnJmU9PiwNCkkgYW0gYWJzdGFpbmluZy4gTm90YWJseSwg dGhlIGRldG5ldCBjaGFydGVyIHN0YXRlczoNCg0KIldHIHN1c3RhaW5pbmcvaW5mb3JtYXRpb25h bCBkb2N1bWVudHMgbWF5IGluY2x1ZGU6DQoNClRoZXNlIGRvY3VtZW50cyBtYXkgbm90IG5lY2Vz c2FyaWx5IGJlIHB1Ymxpc2hlZCwgYnV0IG1heSBiZSBtYWludGFpbmVkIGluIGEgZHJhZnQgZm9y bSBvciBvbiBhIGNvbGxhYm9yYXRpdmUgV29ya2luZyBHcm91cCB3aWtpIHRvIHN1cHBvcnQgdGhl IGVmZm9ydHMgb2YgdGhlIFdvcmtpbmcgR3JvdXAgYW5kIGhlbHAgbmV3IGNvbWVyczoNCg0KUHJv YmxlbSBzdGF0ZW1lbnQgYW5kIChjb25zdHJhaW5lZCkgZGVwbG95bWVudCBlbnZpcm9ubWVudHMg VXNlci1kcml2ZW4gdXNlIGNhc2VzIg0KDQpTbyBJIHdvdWxkIG5vdCBoYXZlIGV4cGVjdGVkIHRo aXMgZG9jdW1lbnQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIFJGQy4gSSBhbHNvIGNvdWxkIG5vdCBm aW5kIGFueSBvdGhlciBXRyBkb2N1bWVudHMgcmVmZXJlbmNpbmcgdGhpcyBub3JtYXRpdmVseS4N Cg0KVGhlcmUgYXJlIGEgZmV3IHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBhcmUgcGFydGlj dWxhcmx5IHByb2JsZW1hdGljIGZvciBhbiBhcmNoaXZhbCBkb2N1bWVudDoNCg0KNC4yLjENCg0K IlRoZXJlIGFyZSBtYW55IGZpZWxkIHByb3RvY29scyB1c2VkIHRvZGF5OyBzb21lIGFyZSBzdGFu ZGFyZHMtYmFzZWQNCiAgIGFuZCBvdGhlcnMgYXJlIHByb3ByaWV0YXJ5IChzZWUgc3RhbmRhcmRz IFtsb250YWxrXSwgW21vZGJ1c10sDQogICBbcHJvZmlidXNdIGFuZCBbZmxuZXRdKS4iDQoNCkkg d291bGQgc3VnZ2VzdCBzL3RvZGF5L2F0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZy8NCg0KNS4x LjINCg0KIk5vdGU6IEN1cnJlbnQgV0cgZGlzY3Vzc2lvbiBpbmRpY2F0ZXMgdGhhdCBzb21lIHBl ZXItdG8tcGVlcg0KICAgY29tbXVuaWNhdGlvbiBtdXN0IGJlIGFzc3VtZWQsIGkuZS4gdGhlIFBD RSBtYXkgY29tbXVuaWNhdGUgb25seQ0KICAgaW5kaXJlY3RseSB3aXRoIGFueSBnaXZlbiBkZXZp Y2UsIGVuYWJsaW5nIGhpZXJhcmNoaWNhbCBjb25maWd1cmF0aW9uDQogICBvZiB0aGUgc3lzdGVt LiINCg0KVGhpcyBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIHJlbmRlcmVkIG91dCBvZiBkYXRlLiBJ IHdvdWxkIHN1Z2dlc3QgZGVsZXRpbmcgIkN1cnJlbnQgV0cgZGlzY3Vzc2lvbiBpbmRpY2F0ZXMg dGhhdC4iDQoNCjEyLjQNCg0KIkN1cnJlbnQgV0cgY29uc2Vuc3VzIGlzIHRoYXQgdGhpcyBpdGVt IHdvbid0IGJlDQogICBkaXJlY3RseSBzdXBwb3J0ZWQgYnkgdGhlIERldE5ldCBhcmNoaXRlY3R1 cmUsIGZvciBleGFtcGxlIGJlY2F1c2UgaXQNCiAgIGltcGxpZXMgZ3VhcmFudGVlIG9mIGluLW9y ZGVyIGRlbGl2ZXJ5IG9mIHBhY2tldHMgd2hpY2ggY29uZmxpY3RzDQogICB3aXRoIHRoZSBjb3Jl IGdvYWwgb2YgYWNoaWV2aW5nIHRoZSBsb3dlc3QgcG9zc2libGUgbGF0ZW5jeS4iDQoNClNhbWUg Y29tbWVudCBhcyBhYm92ZS4gSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nICJDdXJyZW50IFdHIGNv bnNlbnN1cyBpcyB0aGF0LiINCg0KDQo= From nobody Fri Oct 26 06:48:10 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14462130DDF; Fri, 26 Oct 2018 06:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-cmtil0imsO; Fri, 26 Oct 2018 06:48:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1510128A5C; Fri, 26 Oct 2018 06:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2128; q=dns/txt; s=iport; t=1540561686; x=1541771286; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hM7rhzpkiTw0vW3s19UkermTVC9QnsiICv8qLLbUzyY=; b=L9Ijmm/yQo7dtwRB+lqZrKyjKkkOgzDOnDC8OZUAp/hmrlYSSgmJDsL/ 8Vq7u1i3MZ10NLs4pQBezgaPUOJp5yVoS58eWXyH3z9FQPCu6AmZpAPUV lQ46PiWyPb0DjvLjG4QlrTVyQUgQYV3LqM+1i9oi9dCJBxpegbo5OZ3Nj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAD0GdNb/4YNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmfygKg2uIGIwYgg2DQJNdgXoLAQE?= =?us-ascii?q?jhEkCF4MAITQNDQEDAQECAQECbRwMhToBAQEBAyMRRQwEAgEIEQMBAQEDAiY?= =?us-ascii?q?CAgIwFQgIAgQBDQUIgxqCAQ+mDIEuihYFgQuKXReBQT+BEYMSgxsChGWCVwK?= =?us-ascii?q?JIpVdCQKGZ4oOIIFShHeJfIkygzuJfgIRFIEmHTiBPBEIcBWDJ4sZhT5vjCW?= =?us-ascii?q?BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208";a="469946814" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 13:48:04 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QDm4fw029418 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 13:48:04 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 08:48:03 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 08:48:03 -0500 From: "Pascal Thubert (pthubert)" To: Matthew Miller , "gen-art@ietf.org" CC: "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-problem-statement.all@ietf.org" Thread-Topic: Genart last call review of draft-ietf-detnet-problem-statement-07 Thread-Index: AQHUbIzLsmZMxfSs806pV1GvrIvxE6Uxg9qQ Date: Fri, 26 Oct 2018 13:47:48 +0000 Deferred-Delivery: Fri, 26 Oct 2018 13:47:17 +0000 Message-ID: <7ece81694bc540b79da52c37b5da14fd@XCH-RCD-001.cisco.com> References: <154049050040.15652.1135893758057744905@ietfa.amsl.com> In-Reply-To: <154049050040.15652.1135893758057744905@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.170.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-problem-statement-07 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 13:48:08 -0000 TWFueSB0aGFua3MsIE1hdHRoZXcuDQoNClRoaXMgd2lsbCBiZSBmaXhlZCBpbiB0aGUgbmV4dCB1 cGRhdGUgb2YgdGhlIGRyYWZ0LCBhbHJlYWR5IGZpeGVkIGluIGJpdGJ1Y2tldC4NCg0KVGFrZSBj YXJlLA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBN YXR0aGV3IE1pbGxlciA8bGludXh3b2xmK2lldGZAb3V0ZXItcGxhbmVzLm5ldD4NCj4gU2VudDog amV1ZGkgMjUgb2N0b2JyZSAyMDE4IDIwOjAyDQo+IFRvOiBnZW4tYXJ0QGlldGYub3JnDQo+IENj OiBkZXRuZXRAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGV0bmV0LXByb2Js ZW0tDQo+IHN0YXRlbWVudC5hbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogR2VuYXJ0IGxhc3QgY2Fs bCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kZXRuZXQtcHJvYmxlbS1zdGF0ZW1lbnQtMDcNCj4gDQo+ IFJldmlld2VyOiBNYXR0aGV3IE1pbGxlcg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5p dHMNCj4gDQo+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJh ZnQuIFRoZSBHZW5lcmFsIEFyZWEgUmV2aWV3DQo+IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3INCj4gdGhlIElF VEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwNCj4gY29tbWVudHMuDQo+IA0KPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgRkFRIGF0DQo+IA0KPiA8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2Vu L3dpa2kvR2VuQXJ0ZmFxPi4NCj4gDQo+IERvY3VtZW50Og0KPiBSZXZpZXdlcjogTWF0dGhldyBB LiBNaWxsZXINCj4gUmV2aWV3IERhdGU6IDIwMTgtMTAtMjUNCj4gSUVURiBMQyBFbmQgRGF0ZTog MjAxOC0xMC0wMw0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IE4vQQ0KPiANCj4gU3VtbWFyeToNCj4g DQo+IFJlYWR5IHRvIHB1Ymxpc2ggYXMgYW4gSW5mb3JtYXRpb25hbCBEcmFmdCwgdGhvdWdoIHRo ZXJlIGFyZSBuaXRzIHRoYXQgb3VnaHQgdG8NCj4gYmUgYWRkcmVzc2VkIGJlZm9yZSBwdWJsaWNh dGlvbi4NCj4gDQo+IE1ham9yIGlzc3VlczogIE5PTkUNCj4gDQo+IE1pbm9yIGlzc3VlczogIE5P TkUNCj4gDQo+IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0KPiANCj4gKiBJbiBTZWN0aW9uIDMu MS4gIlN1cHBvcnRlZCB0b3BvbG9naWVzIiBwYXJhZ3JhcGggMiwgdGhlIHdvcmQgImFuIg0KPiBz aG91bGQgYmUgImFuIiBpbiB0aGUgcGhyYXNlICJhIHR1bm5lbCBiZXR3ZWVuIGFuZCBpbmdyZXNz IGFuZCBhbiBlZ3Jlc3MNCj4gcm91dGVyIi4NCj4gDQo+ICogSW4gU2VjdGlvbiAzLjEuICJTdXBw b3J0ZWQgdG9wb2xvZ2llcyIgcGFyYWdyYXBoIDIsIHRoZSB3b3JkICJvZiINCj4gc2hvdWxkIGJl ICJvciIgaW4gdGhlIHBocmFzZSAiLi4uIHRoZSBwYXRoIGlzIGVuZC10by1lbmQgb2YgYSB0dW5u ZWwuIi4NCj4gDQoNCg== From nobody Fri Oct 26 10:00:12 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6BD12D4ED; Fri, 26 Oct 2018 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n87YMxwg1wBD; Fri, 26 Oct 2018 10:00:00 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACF71252B7; Fri, 26 Oct 2018 10:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F3PHaF0nE1IBRyzhufPCjthfsOIzricqmqpgvxF9EO0=; b=lnOC3OykT5tz93yzaaMgLj9VNMrZX9Hrw+yLhclkMSnbUj7DGLWIEw1RxfFYwlrFrDjKHBS+nRPiCiR+d7sYPtIyfenYeSiGsf8/KXKzNiIsrMFow6k7VWqVVQmamFbTbRAPq3VubuWGILoXuUU3aK95SrSkPy/+YdbFDTRQafM= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB5060.namprd06.prod.outlook.com (10.167.240.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.22; Fri, 26 Oct 2018 16:59:58 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::f06d:40fc:302a:4d8%3]) with mapi id 15.20.1250.032; Fri, 26 Oct 2018 16:59:58 +0000 From: "Grossman, Ethan A." To: Alissa Cooper , The IESG CC: "draft-ietf-detnet-use-cases@ietf.org" , Lou Berger , "detnet-chairs@ietf.org" , "lberger@labn.net" , "detnet@ietf.org" Thread-Topic: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) Thread-Index: AQHUbEYswG457J13jUKObmAWmXXcwqUxwKEA Date: Fri, 26 Oct 2018 16:59:57 +0000 Message-ID: References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> In-Reply-To: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB5060; 6:kaWjTJl/+o/J047m1LqKwf1xkTbHF8tMsxL2k3mWe+TES7MoKJtNx31Dj7gnUpObxT6xKOPzPCjKgEZBiob7lJfm/cw4g2eM70BbIwzEJef7O93XWJ6JIJze95yM6EZI61Pfg178Dkp9EsYd3EJJzQz1fJ4IX+4cpuOWUaY1Cs1sg+P3iXsE2HAdybtZzdYGHcvESagzLaKv+OlbXhzsXwoPeeiPWIu/FM5Uc8qwHctljjCoYZ3T1MFlM+4slscpH8cpP3A8/DGaNPm19pgyWUl9tXxwvCW3eBwwCepmkkItFxsM1wuhiWNeOTfJUZPIqcBlTEVWVWCqxAeVpXMHzCtic/4guRqsKeQH4gxnF40Sw9uHi57HQh/R24//uL1k7XeuMC9kA0VLX3BPpk2AgIStIE92Q3B/9nFFII/zmSch4okFA0FkRSFglikFAuuvnSRIe1Ti8ugTmHD0f2snJQ==; 5:Rz9hM7ZkweAMTYGKrnrgrSLSAQ7LTOUjRXpZAOvdWYDH8QQzfSnBORSbJI8LxeksmehCgZosI0EDfynqg5k8hM+i9kMc2mFSevLOFG/qG+sxDxuJwKDpMCdz/g/ahNEjFagunxR36ShG2nAYO81ohsrhKSbVA1lXuKZFtFNq61Q=; 7:TLeUb0A6VR3mGIri3Mg4oZ9jO1aHlOp10P0x99z8k8zaJ0HkfKHSgqXTOQVYzc4IimmfOkkGitffO8Z98QUlbZvEFtLzNM5hc1kAJRE9Vj5QKCEpUT2fa7jtR+sQcY7H+wWSZ4MfeenVAyAGj7VdAA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5f6a05f5-ff37-4d5b-8c48-08d63b6475f5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB5060; x-ms-traffictypediagnostic: BL0PR06MB5060: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB5060; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB5060; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39850400004)(13464003)(199004)(189003)(9686003)(102836004)(6506007)(3846002)(55016002)(53546011)(6436002)(6306002)(6116002)(33656002)(186003)(26005)(99286004)(2900100001)(68736007)(8676002)(7696005)(76176011)(2906002)(316002)(110136005)(54906003)(105586002)(106356001)(81156014)(81166006)(446003)(97736004)(478600001)(11346002)(229853002)(476003)(8936002)(14454004)(4326008)(71190400001)(71200400001)(6246003)(86362001)(66066001)(256004)(966005)(14444005)(25786009)(53936002)(7736002)(74316002)(5250100002)(486006)(5660300001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB5060; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qdy+FGxFf5W+CR+KIE0tXjG8LMA9LfgupxfcLNYLG1saVD110hSb/P8Hwo4axN/75/c7wQMcEz1XwXRMW/2Grlzi7NWtwdsBk+n/a+r1YoAVw2bYdIBjdFtfOP5lT1FwRBRXbpVh+12BlznauIMR1OAEUWnaYeTMi+f1ttwIoPzw8ziRHiiBsuFuGUFoEBmXc5YkzM++WWw3+Ro0ybw2vmToc4RLJVQlkiOGfgK1+1aSbTT/w1c465T7M1BHLoRHZPE78sXKtK/t4nH5cg4SdBOLv6fzQx7cJsqrx0SE451rMH6j19lH6n3Wozqv+DmTnZx+0WgseHs3lk2m8eIAC5A7EJNebQLianJwX92QUOU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f6a05f5-ff37-4d5b-8c48-08d63b6475f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 16:59:57.9580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB5060 Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 17:00:03 -0000 SGkgQWxpc3NhLA0KT25lIHJlYXNvbiB3ZSBwbGFubmVkIHRvIHB1Ymxpc2ggdGhlIFVzZSBDYXNl cyBkcmFmdCBpcyB0aGF0IHRoZSBXRyBkZWNpZGVkIGVhcmx5IG9uIG5vdCB0byBoYXZlIGEgIlJl cXVpcmVtZW50cyIgZHJhZnQsIGJlY2F1c2Ugd2Ugd2VyZW4ndCBzdXJlIHdoYXQga2luZCBvZiBz b2x1dGlvbiB3b3VsZCBiZSByZWFzb25hYmxlIHRvIHByb3ZpZGUsIGFuZCB3ZSBkaWRuJ3Qgd2Fu dCB0byBoYXZlIHRvIGVsaW1pbmF0ZSBhbiBvdGhlcndpc2UgZ29vZCBzb2x1dGlvbiBiZWNhdXNl IGl0IG1pc3NlZCBvbmUgb3IgbW9yZSAicmVxdWlyZW1lbnRzIi4gU28gdGhlIFVzZSBDYXNlcyBk cmFmdCBoYXMgYmVlbiB1c2VkIGZvciB0aGF0IHB1cnBvc2UsIGFuZCBpcyByZWZlcmVuY2VkIGlu Zm9ybWF0aW9uYWxseSBpbiBvdGhlciBXRyBkcmFmdHMgd2hlcmV2ZXIgInJlcXVpcmVtZW50cyIg d291bGQgb3RoZXJ3aXNlIGJlIHJlZmVyZW5jZWQuIFRoZSBwb2ludCBpcyB0aGF0IHRoZSBVc2Ug Q2FzZXMgZHJhZnQgc3RhcnRlZCBvdXQgd2l0aCBzb21lIHRoaW5ncyB0aGF0IG91ciBiZXN0IHBy b3Bvc2VkIHNvbHV0aW9uIGNvdWxkIG5vdCBhZGRyZXNzLCBzbyB3ZSByZW1vdmVkIHRoZW0gZnJv bSB0aGUgInJlcXVpcmVtZW50cyIgKGkuZS4gdGhlIGV4cGVjdGF0aW9ucyBvZiB0aGUgdXNlIGNh c2VzKSByYXRoZXIgdGhhbiBzY3JhcCB0aGUgc29sdXRpb24uIA0KRXRoYW4gKGFzIFVzZSBDYXNl cyBkcmFmdCBlZGl0b3IpLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxp c3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+IA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MjUsIDIwMTggMjozNiBBTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0 LWlldGYtZGV0bmV0LXVzZS1jYXNlc0BpZXRmLm9yZzsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJu Lm5ldD47IGRldG5ldC1jaGFpcnNAaWV0Zi5vcmc7IGxiZXJnZXJAbGFibi5uZXQ7IGRldG5ldEBp ZXRmLm9yZw0KU3ViamVjdDogQWxpc3NhIENvb3BlcidzIEFic3RhaW4gb24gZHJhZnQtaWV0Zi1k ZXRuZXQtdXNlLWNhc2VzLTE5OiAod2l0aCBDT01NRU5UKQ0KDQpBbGlzc2EgQ29vcGVyIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1kZXRu ZXQtdXNlLWNhc2VzLTE5OiBBYnN0YWluDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgZG9jdW1lbnQgaGFzIHVzZWZ1bCBjb250ZW50IGJ1dCBJ J20gbm90IGNvbnZpbmNlZCBvZiBpdHMgYXJjaGl2YWwgdmFsdWUuDQpDb25zaXN0ZW50IHdpdGgg dGhlIElFU0cgc3RhdGVtZW50IG9uIHN1cHBvcnRpbmcgZG9jdW1lbnRzIDxodHRwczovL3d3dy5p ZXRmLm9yZy9ibG9nL3N1cHBvcnQtZG9jdW1lbnRzLWlldGYtd29ya2luZy1ncm91cHMvP3ByaW1h cnlfdG9waWM9NyY+LA0KSSBhbSBhYnN0YWluaW5nLiBOb3RhYmx5LCB0aGUgZGV0bmV0IGNoYXJ0 ZXIgc3RhdGVzOg0KDQoiV0cgc3VzdGFpbmluZy9pbmZvcm1hdGlvbmFsIGRvY3VtZW50cyBtYXkg aW5jbHVkZToNCg0KVGhlc2UgZG9jdW1lbnRzIG1heSBub3QgbmVjZXNzYXJpbHkgYmUgcHVibGlz aGVkLCBidXQgbWF5IGJlIG1haW50YWluZWQgaW4gYSBkcmFmdCBmb3JtIG9yIG9uIGEgY29sbGFi b3JhdGl2ZSBXb3JraW5nIEdyb3VwIHdpa2kgdG8gc3VwcG9ydCB0aGUgZWZmb3J0cyBvZiB0aGUg V29ya2luZyBHcm91cCBhbmQgaGVscCBuZXcgY29tZXJzOg0KDQpQcm9ibGVtIHN0YXRlbWVudCBh bmQgKGNvbnN0cmFpbmVkKSBkZXBsb3ltZW50IGVudmlyb25tZW50cyBVc2VyLWRyaXZlbiB1c2Ug Y2FzZXMiDQoNClNvIEkgd291bGQgbm90IGhhdmUgZXhwZWN0ZWQgdGhpcyBkb2N1bWVudCB0byBi ZSBwdWJsaXNoZWQgYXMgYW4gUkZDLiBJIGFsc28gY291bGQgbm90IGZpbmQgYW55IG90aGVyIFdH IGRvY3VtZW50cyByZWZlcmVuY2luZyB0aGlzIG5vcm1hdGl2ZWx5Lg0KDQpUaGVyZSBhcmUgYSBm ZXcgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB0aGF0IGFyZSBwYXJ0aWN1bGFybHkgcHJvYmxlbWF0 aWMgZm9yIGFuIGFyY2hpdmFsIGRvY3VtZW50Og0KDQo0LjIuMQ0KDQoiVGhlcmUgYXJlIG1hbnkg ZmllbGQgcHJvdG9jb2xzIHVzZWQgdG9kYXk7IHNvbWUgYXJlIHN0YW5kYXJkcy1iYXNlZA0KICAg YW5kIG90aGVycyBhcmUgcHJvcHJpZXRhcnkgKHNlZSBzdGFuZGFyZHMgW2xvbnRhbGtdLCBbbW9k YnVzXSwNCiAgIFtwcm9maWJ1c10gYW5kIFtmbG5ldF0pLiINCg0KSSB3b3VsZCBzdWdnZXN0IHMv dG9kYXkvYXQgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLw0KDQo1LjEuMg0KDQoiTm90ZTogQ3Vy cmVudCBXRyBkaXNjdXNzaW9uIGluZGljYXRlcyB0aGF0IHNvbWUgcGVlci10by1wZWVyDQogICBj b21tdW5pY2F0aW9uIG11c3QgYmUgYXNzdW1lZCwgaS5lLiB0aGUgUENFIG1heSBjb21tdW5pY2F0 ZSBvbmx5DQogICBpbmRpcmVjdGx5IHdpdGggYW55IGdpdmVuIGRldmljZSwgZW5hYmxpbmcgaGll cmFyY2hpY2FsIGNvbmZpZ3VyYXRpb24NCiAgIG9mIHRoZSBzeXN0ZW0uIg0KDQpUaGlzIHNlZW1z IGxpa2UgaXQgY291bGQgYmUgcmVuZGVyZWQgb3V0IG9mIGRhdGUuIEkgd291bGQgc3VnZ2VzdCBk ZWxldGluZyAiQ3VycmVudCBXRyBkaXNjdXNzaW9uIGluZGljYXRlcyB0aGF0LiINCg0KMTIuNA0K DQoiQ3VycmVudCBXRyBjb25zZW5zdXMgaXMgdGhhdCB0aGlzIGl0ZW0gd29uJ3QgYmUNCiAgIGRp cmVjdGx5IHN1cHBvcnRlZCBieSB0aGUgRGV0TmV0IGFyY2hpdGVjdHVyZSwgZm9yIGV4YW1wbGUg YmVjYXVzZSBpdA0KICAgaW1wbGllcyBndWFyYW50ZWUgb2YgaW4tb3JkZXIgZGVsaXZlcnkgb2Yg cGFja2V0cyB3aGljaCBjb25mbGljdHMNCiAgIHdpdGggdGhlIGNvcmUgZ29hbCBvZiBhY2hpZXZp bmcgdGhlIGxvd2VzdCBwb3NzaWJsZSBsYXRlbmN5LiINCg0KU2FtZSBjb21tZW50IGFzIGFib3Zl LiBJIHdvdWxkIHN1Z2dlc3QgZGVsZXRpbmcgIkN1cnJlbnQgV0cgY29uc2Vuc3VzIGlzIHRoYXQu Ig0KDQoNCg== From nobody Fri Oct 26 10:39:02 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E8212870E; Fri, 26 Oct 2018 10:38:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW9ZdYGa_03A; Fri, 26 Oct 2018 10:38:52 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 C1A76127133; Fri, 26 Oct 2018 10:38:51 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 189-v6so2270956wmw.2; Fri, 26 Oct 2018 10:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=k0fUdbrK5oHqWExCDifLsM15zeIj/SaUNVlwkr1ZvUA=; b=rWaB6aPjY662NKA77S0QOVVt2EqCUQ8CCNqe85VHGuH1Q17Vraq3jTICzFcMXvSoXI gbCjG/hIpH0aA1VALuZY/yFpCRdTYatkom4n/YFX/WQww8z6d2YyMbrShQDXzMRrkSDF KrlR3Pevn3GnnWwqghQqrCJj0Urr74cwiq6AJ8L5JVx6W9Zs49jBNvItjBlpDcCAs5J6 oeRGKSRLLbNCRD4hcZxgXQPUGGH44vRe9jVw7yKDcVFvYTBB3rjjt6fLYBeGivZw0Noi qZ0b72FzXvR4mmx5nttzzvcFo5u9CQGo4hYwtyLcW+SFFKdpoUaO5EGS343+S8qUvzZr nQfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=k0fUdbrK5oHqWExCDifLsM15zeIj/SaUNVlwkr1ZvUA=; b=UIHtjE5z0KEBkLKFBeS7K0xIzYOa1fNWI2l3rBruFP4cb0wlB4E1J0/C/EZH+j+CUe ugJgGlMQWSsABCipWQ1RrnLFQ8TY2fV4flBtxentd+lCbeLfGmw5ar4RDJhtcTm5WBV0 mUPQLk5aN/2c14WJpTCmMYItfvz/Bu3swmBMtE36wWmklPz1GDn/6bIqr3K6Jr0/pnJw l+OklzwnJv2Z9hbmpkrKu9IO1D8lUi2HuYsYyXV1gATNzi9G0YtQ3dfs6Ebdy0jKrC+C H83ctS7zF5kD1byFTHt1yPFqVGUoOB+CyO8LlggQQtuI3/tmlOn9eigg/LekRCCDojpb jvlQ== X-Gm-Message-State: AGRZ1gIZRYYFhrhRMnEmt8x2HtpZGykHpFGa7ukjpQTnu1HHAyrvoH9O VTIHrcaBfLY8QKqC/B1BkPNxBPAw X-Google-Smtp-Source: AJdET5eQGUqhMOdl6DG3LJ4EF5JiWCNbDY9ZrzaW7KbzJmC1eeo2bsTq1RWdbKE7Qk1WtpxclX8RbA== X-Received: by 2002:a1c:ca0f:: with SMTP id a15-v6mr6194480wmg.71.1540575529791; Fri, 26 Oct 2018 10:38:49 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x18-v6sm4503292wme.42.2018.10.26.10.38.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Oct 2018 10:38:49 -0700 (PDT) To: Alissa Cooper , The IESG Cc: detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, draft-ietf-detnet-use-cases@ietf.org References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> Date: Fri, 26 Oct 2018 18:38:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2338B11BD954C410BE35B2D1" Content-Language: en-GB Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 17:38:54 -0000 This is a multi-part message in MIME format. --------------2338B11BD954C410BE35B2D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 25/10/2018 10:36, Alissa Cooper wrote: > Consistent with the IESG statement on supporting documents > , > I am abstaining. Notably, the detnet charter states: I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents? Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem. The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer. Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors. I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve. Best regards Stewart --------------2338B11BD954C410BE35B2D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



    On 25/10/2018 10:36, Alissa Cooper wrote:
    Consistent with the IESG statement on supporting documents
<https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,
I am abstaining. Notably, the detnet charter states:

    I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents?

    Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem.

    The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer.

    Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors.

    I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

    Best regards

    Stewart


    --------------2338B11BD954C410BE35B2D1-- From nobody Fri Oct 26 10:47:16 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A1A130DDA; Fri, 26 Oct 2018 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdxHwl3eT-4Y; Fri, 26 Oct 2018 10:47:05 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 0161C12870E; Fri, 26 Oct 2018 10:47:04 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w9QHj45t035654; Fri, 26 Oct 2018 13:47:01 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 2nc6c830cs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 13:47:01 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9QHl0rt005117; Fri, 26 Oct 2018 13:47:00 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w9QHkvU4005058; Fri, 26 Oct 2018 13:46:57 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 6001240002D0; Fri, 26 Oct 2018 17:46:57 +0000 (GMT) Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (unknown [130.9.129.145]) by zlp27127.vci.att.com (Service) with ESMTPS id 4B64D40002B8; Fri, 26 Oct 2018 17:46:57 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.89]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0415.000; Fri, 26 Oct 2018 13:46:57 -0400 From: "BRUNGARD, DEBORAH A" To: Stewart Bryant , Alissa Cooper , The IESG CC: "draft-ietf-detnet-use-cases@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "detnet-chairs@ietf.org" Thread-Topic: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) Thread-Index: AQHUbEYuj6dHz+RT2ki5ZyKWS9seqqUyEACA//++CFA= Date: Fri, 26 Oct 2018 17:46:57 +0000 Message-ID: References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> In-Reply-To: <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.139.207] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8884691D5MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-26_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810260149 Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 17:47:07 -0000 --_000_F64C10EAA68C8044B33656FA214632C8884691D5MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3Rld2FydCwNCg0KSSBhZ3JlZSDigJMgSSBzZW50IGFuIGVhcmxpZXIgcmVwbHkgKG9uIHRo ZSBsaXN0KSB0byBBbGlzc2EgZXhwbGFpbmluZyB3aHkgd2Ugd2VudCBmb3IgcHVibGljYXRpb24u IEFzIHRoaXMgaXMgYSBkb2N1bWVudCB3aGljaCB3aWxsIGJlIGxvb2tlZCBhdCBieSBJRUVFIGFu ZCBvdGhlcnMsIGl0IGlzIG9mIHZhbHVlIHRvIGhhdmUgaXQgcHVibGlzaGVkIHZzLiBhIHdpa2ku IEFuZCBwdWJsaWNhdGlvbiBpbmRpY2F0ZXMgY29uc2Vuc3VzIG9mIHRoZSBncm91cC4NCg0KSSB3 aWxsIGJlIGZvbGxvd2luZyB1cCB3aXRoIHRoZSBJRVNHIG9uIGJvdGggdGhlIGludGVycHJldGF0 aW9uIG9mIHRoZSBJRVNHIHN0YXRlbWVudCBmb3IgcHVibGlzaGluZyBpbmZvcm1hdGlvbmFscyBh bmQgdXNlIG9mIEFic3RhaW5zIHNvIHdlIGNhbiBiZSBjb25zaXN0ZW50IGZvciB0aGUgY29tbXVu aXR5Lg0KDQpUaGFua3MsDQpEZWJvcmFoDQoNCg0KRnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFN0ZXdhcnQgQnJ5YW50DQpTZW50OiBGcmlkYXksIE9j dG9iZXIgMjYsIDIwMTggMTozOSBQTQ0KVG86IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3 LmluPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1kZXRuZXQtdXNl LWNhc2VzQGlldGYub3JnOyBkZXRuZXRAaWV0Zi5vcmc7IGxiZXJnZXJAbGFibi5uZXQ7IGRldG5l dC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBBbGlzc2EgQ29vcGVyJ3Mg QWJzdGFpbiBvbiBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTk6ICh3aXRoIENPTU1FTlQp DQoNCg0KDQoNCk9uIDI1LzEwLzIwMTggMTA6MzYsIEFsaXNzYSBDb29wZXIgd3JvdGU6DQoNCkNv bnNpc3RlbnQgd2l0aCB0aGUgSUVTRyBzdGF0ZW1lbnQgb24gc3VwcG9ydGluZyBkb2N1bWVudHMN Cg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvc3VwcG9ydC1kb2N1bWVudHMtaWV0Zi13b3Jr aW5nLWdyb3Vwcy8/cHJpbWFyeV90b3BpYz03Jj48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfYmxvZ19zdXBwb3J0LTJEZG9j dW1lbnRzLTJEaWV0Zi0yRHdvcmtpbmctMkRncm91cHNfLTNGcHJpbWFyeS01RnRvcGljLTNENy0y NiZkPUR3TUNhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhY RDh3Jm09bGNoWFZjaHF1dFlJWFpsYjhfWEVXWjdVU2lSclEyVkpWcmgwV21CcVdQNCZzPWFYUG9T YVRERkI5R24xYlpUUUYtMFhQcng1YmplTUw0bHhxOFBOejVhcW8mZT0+LA0KDQpJIGFtIGFic3Rh aW5pbmcuIE5vdGFibHksIHRoZSBkZXRuZXQgY2hhcnRlciBzdGF0ZXM6DQoNCkkgd29uZGVyIGhv dyBhbGlnbmVkIHdpdGggdGhlIHJlc3Qgb2YgdGhlIElFVEYgdGhpcyBwb2xpY3kgaXMgd2hlbiBh cHBsaWVkIHRvIHVzZSBjYXNlcyBkb2N1bWVudHM/DQoNClB1bGxpbmcgdG9nZXRoZXIgdXNlIGNh c2UgaW5mb3JtYXRpb24gaXMgb2Z0ZW4gYSBtZXRob2Qgb2YgZm9jdXNzaW5nIHRoZSBkZXNpZ24g cmVxdWlyZW1lbnRzIGJ5IGNhc2luZyB0aGVtIGludG8gc29tZXRoaW5nIHNvbGlkIHRoYXQgdGhv c2Ugd29ya2luZyBvbiB0aGUgcHJvYmxlbSBjYW4gdXNlIHRvIGJ1aWxkIGEgbWVudGFsIG1vZGVs IG9mIGhvdyB0aGUgZGVzaWduIG1hcHMgdG8gcmVhbGl0eS4gU29tZSBwZW9wbGUgbmVlZCB0aGVz ZSBtb2RlbHMgdG8gdmlzdWFsaXNlIHdoYXQgdGhleSBhcmUgYXR0ZW1wdGluZyB0byBkZXNpZ24u IFNvbWUgcmVhZGVyIG5lZWQgdGhlbSB0byBzb2xpZGl0eSBhbiBhYnN0cmFjdCBwcm90b2NvbCBp bnRvIHJlYWxpdHkgdG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGludmFyaWFudHMsIHRoZSBjb25z dHJhaW50cyBhbmQgYm91bmRhcmllcyBhbmQgaG93IHRoZSBjb21wb25lbnRzIG9mIHRoZSBzb2x1 dGlvbiBmaXQgdG9nZXRoZXIuIEkgZm9yIG9uZSBmaW5kIHRoZXNlIHNvcnRzIG9mIHRleHQgaGVs cGZ1bCBpbiBiZXR0ZXIgdW5kZXJzdGFuZGluZyB0aGUgcHJvYmxlbS4NCg0KVGhlICJyZXdhcmQi IHRvIHRoZSBhdXRob3JzIGZvciB0aGUgbm9uLXRyaXZpYWwgd29yayBmb3IgcHVsbGluZyB0aGlz IHRvZ2V0aGVyIGlzIGEgcHVibGlzaGVkIFJGQy4gTWF5YmUgc29tZSBtYXkgY29uc2lkZXIgdGhh dCB0byBiZSB2YW5pdHksIGJ1dCB0aGUgZmFjdCBpcyB0aGF0IHBlb3BsZSBhcmUgbW9yZSBpbmNs aW5lZCB0byBzbyB3b3JrIGlmIHRoZXkgcGVyY2VpdmUgYSB0YW5naWJsZSByZXdhcmQgZm9yIHRo ZWlyIHdvcmssIGFuZCBhbiBSRkMgaXMgb25lIG9mIHRoZSBmZXcgInJld2FyZHMiIHRoZSBJRVRG IGhhcyB0byBvZmZlci4NCg0KUHVibGljYXRpb24gb2Ygc3VjaCB0ZXh0IGFzIGFuIFJGQyB0aHVz IHNlcnZlcyB0d28gcHVycG9zZXM6IGEgc3RhcnRpbmcgcG9pbnQgZm9yIHNvbWVvbmUgdG8gdW5k ZXJzdGFuZCB0aGUgcHJvYmxlbSB0aGF0IHRoZSBkZXNpZ25lcnMgd2VyZSB0cnlpbmcgdG8gc29s dmUgYXMgc2VlbiBhdCB0aGUgdGltZSB0aGF0IHRoZXkgd29ya2VkIG9uIGl0LCBhbmQgYXMgYW4g YWNrbm93bGVkZ2VtZW50IGJ5IHRoZSBJRVRGIHRoYXQgdGhlIHdvcmsgb2YgZGVmaW5pbmcgdGhl IHNjZW5hcmlvcyBvZiB1c2Ugd2FzIGRvbmUgYnkgdGhlIGF1dGhvcnMuDQoNCkkgdGhlcmVmb3Jl IHRoaW5rIHRoYXQgZGlzbWlzc2luZyBzdWNoIHdvcmsgaW4gdGhpcyB3YXkgaXMgY291bnRlcnBy b2R1Y3RpdmUgYW5kIGRlbW90aXZhdGluZywgcXVpdGUgdGhlIG9wcG9zaXRlIG9mIHdoYXQgdGhl IElFU0cgc2hvdWxkIGJlIHN0cml2aW5nIHRvIGFjaGlldmUuDQoNCkJlc3QgcmVnYXJkcw0KDQpT dGV3YXJ0DQoNCg== --_000_F64C10EAA68C8044B33656FA214632C8884691D5MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGkgU3Rld2FydCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkkgYWdyZWUg4oCTIEkgc2VudCBhbiBlYXJsaWVyIHJl cGx5IChvbiB0aGUgbGlzdCkgdG8gQWxpc3NhIGV4cGxhaW5pbmcgd2h5IHdlIHdlbnQgZm9yIHB1 YmxpY2F0aW9uLiBBcyB0aGlzIGlzIGEgZG9jdW1lbnQgd2hpY2ggd2lsbCBiZSBsb29rZWQgYXQg YnkgSUVFRSBhbmQgb3RoZXJzLCBpdCBpcyBvZiB2YWx1ZSB0byBoYXZlIGl0IHB1Ymxpc2hlZCB2 cy4gYQ0KIHdpa2kuIEFuZCBwdWJsaWNhdGlvbiBpbmRpY2F0ZXMgY29uc2Vuc3VzIG9mIHRoZSBn cm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkkgd2lsbCBi ZSBmb2xsb3dpbmcgdXAgd2l0aCB0aGUgSUVTRyBvbiBib3RoIHRoZSBpbnRlcnByZXRhdGlvbiBv ZiB0aGUgSUVTRyBzdGF0ZW1lbnQgZm9yIHB1Ymxpc2hpbmcgaW5mb3JtYXRpb25hbHMgYW5kIHVz ZSBvZiBBYnN0YWlucyBzbyB3ZSBjYW4gYmUgY29uc2lzdGVudCBmb3IgdGhlIGNvbW11bml0eS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+RGVib3JhaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PiBkZXRuZXQgJmx0O2RldG5ldC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9m IDwvYj5TdGV3YXJ0IEJyeWFudDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMjYs IDIwMTggMTozOSBQTTxicj4NCjxiPlRvOjwvYj4gQWxpc3NhIENvb3BlciAmbHQ7YWxpc3NhQGNv b3BlcncuaW4mZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8 L2I+IGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlc0BpZXRmLm9yZzsgZGV0bmV0QGlldGYub3Jn OyBsYmVyZ2VyQGxhYm4ubmV0OyBkZXRuZXQtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbRGV0bmV0XSBBbGlzc2EgQ29vcGVyJ3MgQWJzdGFpbiBvbiBkcmFmdC1pZXRm LWRldG5ldC11c2UtY2FzZXMtMTk6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNS8xMC8y MDE4IDEwOjM2LCBBbGlzc2EgQ29vcGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwcmU+Q29uc2lzdGVudCB3aXRoIHRoZSBJRVNHIHN0YXRlbWVudCBvbiBzdXBwb3J0aW5nIGRv Y3VtZW50czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2Jsb2dfc3Vw cG9ydC0yRGRvY3VtZW50cy0yRGlldGYtMkR3b3JraW5nLTJEZ3JvdXBzXy0zRnByaW1hcnktNUZ0 b3BpYy0zRDctMjYmYW1wO2Q9RHdNQ2FRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1w O3I9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT1sY2hYVmNocXV0WUlYWmxiOF9YRVdaN1VT aVJyUTJWSlZyaDBXbUJxV1A0JmFtcDtzPWFYUG9TYVRERkI5R24xYlpUUUYtMFhQcng1YmplTUw0 bHhxOFBOejVhcW8mYW1wO2U9Ij4mbHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYmxvZy9zdXBwb3J0 LWRvY3VtZW50cy1pZXRmLXdvcmtpbmctZ3JvdXBzLz9wcmltYXJ5X3RvcGljPTcmYW1wOyZndDs8 L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgYW0gYWJzdGFpbmluZy4gTm90YWJseSwgdGhl IGRldG5ldCBjaGFydGVyIHN0YXRlczo8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJ IHdvbmRlciBob3cgYWxpZ25lZCB3aXRoIHRoZSByZXN0IG9mIHRoZSBJRVRGIHRoaXMgcG9saWN5 IGlzIHdoZW4gYXBwbGllZCB0byB1c2UgY2FzZXMgZG9jdW1lbnRzPzxicj4NCjxicj4NClB1bGxp bmcgdG9nZXRoZXIgdXNlIGNhc2UgaW5mb3JtYXRpb24gaXMgb2Z0ZW4gYSBtZXRob2Qgb2YgZm9j dXNzaW5nIHRoZSBkZXNpZ24gcmVxdWlyZW1lbnRzIGJ5IGNhc2luZyB0aGVtIGludG8gc29tZXRo aW5nIHNvbGlkIHRoYXQgdGhvc2Ugd29ya2luZyBvbiB0aGUgcHJvYmxlbSBjYW4gdXNlIHRvIGJ1 aWxkIGEgbWVudGFsIG1vZGVsIG9mIGhvdyB0aGUgZGVzaWduIG1hcHMgdG8gcmVhbGl0eS4gU29t ZSBwZW9wbGUgbmVlZCB0aGVzZSBtb2RlbHMNCiB0byB2aXN1YWxpc2Ugd2hhdCB0aGV5IGFyZSBh dHRlbXB0aW5nIHRvIGRlc2lnbi4gU29tZSByZWFkZXIgbmVlZCB0aGVtIHRvIHNvbGlkaXR5IGFu IGFic3RyYWN0IHByb3RvY29sIGludG8gcmVhbGl0eSB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUg aW52YXJpYW50cywgdGhlIGNvbnN0cmFpbnRzIGFuZCBib3VuZGFyaWVzIGFuZCBob3cgdGhlIGNv bXBvbmVudHMgb2YgdGhlIHNvbHV0aW9uIGZpdCB0b2dldGhlci4gSSBmb3Igb25lIGZpbmQgdGhl c2UNCiBzb3J0cyBvZiB0ZXh0IGhlbHBmdWwgaW4gYmV0dGVyIHVuZGVyc3RhbmRpbmcgdGhlIHBy b2JsZW0uPGJyPg0KPGJyPg0KVGhlICZxdW90O3Jld2FyZCZxdW90OyB0byB0aGUgYXV0aG9ycyBm b3IgdGhlIG5vbi10cml2aWFsIHdvcmsgZm9yIHB1bGxpbmcgdGhpcyB0b2dldGhlciBpcyBhIHB1 Ymxpc2hlZCBSRkMuIE1heWJlIHNvbWUgbWF5IGNvbnNpZGVyIHRoYXQgdG8gYmUgdmFuaXR5LCBi dXQgdGhlIGZhY3QgaXMgdGhhdCBwZW9wbGUgYXJlIG1vcmUgaW5jbGluZWQgdG8gc28gd29yayBp ZiB0aGV5IHBlcmNlaXZlIGEgdGFuZ2libGUgcmV3YXJkIGZvciB0aGVpciB3b3JrLCBhbmQgYW4N CiBSRkMgaXMgb25lIG9mIHRoZSBmZXcgJnF1b3Q7cmV3YXJkcyZxdW90OyB0aGUgSUVURiBoYXMg dG8gb2ZmZXIuPGJyPg0KPGJyPg0KUHVibGljYXRpb24gb2Ygc3VjaCB0ZXh0IGFzIGFuIFJGQyB0 aHVzIHNlcnZlcyB0d28gcHVycG9zZXM6IGEgc3RhcnRpbmcgcG9pbnQgZm9yIHNvbWVvbmUgdG8g dW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB0aGF0IHRoZSBkZXNpZ25lcnMgd2VyZSB0cnlpbmcgdG8g c29sdmUgYXMgc2VlbiBhdCB0aGUgdGltZSB0aGF0IHRoZXkgd29ya2VkIG9uIGl0LCBhbmQgYXMg YW4gYWNrbm93bGVkZ2VtZW50IGJ5IHRoZSBJRVRGIHRoYXQgdGhlIHdvcmsgb2YgZGVmaW5pbmcN CiB0aGUgc2NlbmFyaW9zIG9mIHVzZSB3YXMgZG9uZSBieSB0aGUgYXV0aG9ycy48YnI+DQo8YnI+ DQpJIHRoZXJlZm9yZSB0aGluayB0aGF0IGRpc21pc3Npbmcgc3VjaCB3b3JrIGluIHRoaXMgd2F5 IGlzIGNvdW50ZXJwcm9kdWN0aXZlIGFuZCBkZW1vdGl2YXRpbmcsIHF1aXRlIHRoZSBvcHBvc2l0 ZSBvZiB3aGF0IHRoZSBJRVNHIHNob3VsZCBiZSBzdHJpdmluZyB0byBhY2hpZXZlLjxicj4NCjxi cj4NCkJlc3QgcmVnYXJkczxicj4NCjxicj4NClN0ZXdhcnQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C8884691D5MISOUT7MSGUSRDE_-- From nobody Fri Oct 26 10:48:57 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F612870E; Fri, 26 Oct 2018 10:48:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWL1_Nmt2Iwb; Fri, 26 Oct 2018 10:48:45 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 084D1120072; Fri, 26 Oct 2018 10:48:45 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id b14-v6so2220238wmj.3; Fri, 26 Oct 2018 10:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=f276ucsJGIwMJfjv6sSN+U+dcd3966Jr/6iEAhw9OCE=; b=tmTIG6juyHqwtiwa7PUXJg8Kh3qzGgv3bTWShTd/c2JGWFcoKl+2FYrOWwm6vSVSLO YoQLovSsT1gHwFbq2vT4cohGgfs/ThBxUfk42XUSU6M3PGyLe8sXU9OlWKSqfS+hzTed 6GEtDNq3uzQeAEcYE7TWXBpNmZ+bi0jt9JSvBHDmvXpm+7ootJvLL0zqA+d95zE1XSD1 di4Pn1R1ke2D9XTkLDbXRxl/PLdMJM4ws5Nbzgg90zQRyR2ofrKGLCuy0wE1ry4tLsea g4/9/AIVQE6uKAus3a4IRJcEBxFpfuroMOnNaIjQUq9WzKEnvFpiSAgnMruQ8a0LFj+v wHYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=f276ucsJGIwMJfjv6sSN+U+dcd3966Jr/6iEAhw9OCE=; b=DNHpG/sGzMyZit9a+Bbz2OpgyWBlbTb65uN0lqcq4eko+8vLgdFCPVWexk+dS1iLjn MJnmtWJqFiGOptTSUyJ5BWtV6a4K+t3nYKcAgOfgHYjEi6NK8mNHhnmrhlmGeWGfZ6Lp 2+sfjSsS69PsEjtLoRS9KGsL35BA7vsCELWbWshmMTmGp0TtswK35IXMF81PfFMAq5tA dkfBIKiTlPpK+1ymaVjKUtCd1+Udo0X4Er1bW5kvYli8jFgeEmSQOns408eu2+83RDsl QVXeULN5/TnRyGNZI90JCeejiGvQ0dOOxDqsZkU+1QvTYyDTypGQcKue1c/RwZXDCgrL /Sgg== X-Gm-Message-State: AGRZ1gLTVP/6kS8/ZSWtSp8XLxTsExAfNMvPr9KmOGjhorbKYFOTrRgY nOQsg0hwdnaD0E/ST/7hp5o7CaAv X-Google-Smtp-Source: AJdET5cJ39J98hjCKg4B6IzizBeyMrrCmIzATl/JUKfEsShS5VFf97XzcKv8oVWurTOTgCPctux4vQ== X-Received: by 2002:a1c:c187:: with SMTP id r129-v6mr6196910wmf.20.1540576123200; Fri, 26 Oct 2018 10:48:43 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id t13-v6sm6755695wrn.22.2018.10.26.10.48.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Oct 2018 10:48:42 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, draft-ietf-detnet-use-cases@ietf.org References: <154047604123.16342.17879381711877381417.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <1df130ab-fddc-5f3f-7011-45cb1d163453@gmail.com> Date: Fri, 26 Oct 2018 18:48:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154047604123.16342.17879381711877381417.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-iet?= =?utf-8?q?f-detnet-use-cases-19=3A_=28with_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 17:48:47 -0000 On 25/10/2018 15:00, Mirja Kühlewind wrote: > I unfortunately did not have the time to read this doc in detail which is the > main reason for my abstain. Mirja I would have thought that no-objection would have better reflected that situation. No-objection says that you trust others in the IESG to make a decision on matters that you do not understand or do not have time to evaluate. That is consistent with a situation when an AD has not read the text. Abstain send the message that the AD would prefer that a document not be published, but not strongly enough to issue a Discuss. Given the statement that you did not read the text in detail, I cannot see how it is reasonable to arrive at that position. Best regards Stewart From nobody Fri Oct 26 11:13:39 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F149130DDE for ; Fri, 26 Oct 2018 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMWimGWl1sFm for ; Fri, 26 Oct 2018 11:13:35 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 062A812D4E7 for ; Fri, 26 Oct 2018 11:13:35 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id k11-v6so1991536lja.5 for ; Fri, 26 Oct 2018 11:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BRmevGGA15Px3VeX3K6bUZr69K4ox4tIul2cNcCbojg=; b=aDKHaue6rBDoWcZHvrqXlWp+18SGjQuXpcHZmgDm3D/OC3g6ZDkVBvRYKgeJGxpaLq iYYtnT56EqXdgs//z3eXJPOYyBDWr0HxgB+xuPAteS/P154htcVfcvS/R0uLw2l3CGIu DsRLMbHJ5Y7Uy6SBujeQTMt8VCd7ruF8pdKXtSLdiGCk3R7QpU83A20ajJ7QZobOtVdD Sw444ZhMwyD1+f8SBFeQC9YxisAvk7/O/5dRTXkI0A5AC33cD1VUYZM77kxZS2fzk/Jo f3ld+UK1SCQlcS2R8gI85WRlUFV2fQyPa2/mfP4IY7oU2x2m9quW5bmRzBLlrMFbxWFX a1qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BRmevGGA15Px3VeX3K6bUZr69K4ox4tIul2cNcCbojg=; b=hez4jhbLJc5Dik+/y9htMH6Ln6yj9f1v4NDzfwFPZDvV3Fbrj8JPuqEDtOxR5g6304 WTO7IuIuMfQYt6tmRK22XZOuDouHBmk4nJ8n53IUu0Dc3B4q+uDPL9M+5uIYO7uL0gAQ zLoclVaiRDXDxtKY0bAEsGBjeEbxoxBcsfEqkbhiz+kDceqPL5XUFpYseYb3s8jIsDfK QknuChCBvsAaT+/lns4o2yl1Ewv9c8Z99IskhzAgpHWDVXU+Tb0G6HHecshRqQaM+XHm T+hgfnbk/AuG0ZwVhOJO9m7CB6jHue9ZFWw9P6h5bXC8c8OeRMmzCCPxU7cR3EcXuKC9 xCwQ== X-Gm-Message-State: AGRZ1gJNOBzQAx50+48pN59zWFXH7IoWeOSPc0knL6MwiypZVCVzo7u4 PgKFLHyH9euBkzkeX2wa1MsrJ36K0oatAOv4fB5prw== X-Google-Smtp-Source: AJdET5de4VtjvmKExLnxcIOpDhjr/hmbOuGooT77QnUNHEEd6qFM38tvX+wywUDCLZHjUQtwvRJlcedsLNz+unntQCU= X-Received: by 2002:a2e:94c4:: with SMTP id r4-v6mr3164144ljh.68.1540577613197; Fri, 26 Oct 2018 11:13:33 -0700 (PDT) MIME-Version: 1.0 References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> In-Reply-To: <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> From: Eric Rescorla Date: Fri, 26 Oct 2018 11:12:56 -0700 Message-ID: To: Stewart Bryant Cc: Alissa Cooper , IESG , draft-ietf-detnet-use-cases@ietf.org, detnet@ietf.org, Lou Berger , detnet-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000062771d057925ad46" Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:13:38 -0000 --00000000000062771d057925ad46 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 26, 2018 at 10:38 AM Stewart Bryant wrote: > > > On 25/10/2018 10:36, Alissa Cooper wrote: > > Consistent with the IESG statement on supporting documents , > I am abstaining. Notably, the detnet charter states: > > > I wonder how aligned with the rest of the IETF this policy is when applied > to use cases documents? > I didn't abstain because I don't care that much, but I am aligned with that policy (though it predates me, so I wasn't part of crafting it). > Pulling together use case information is often a method of focussing the > design requirements by casing them into something solid that those working > on the problem can use to build a mental model of how the design maps to > reality. Some people need these models to visualise what they are > attempting to design. Some reader need them to solidity an abstract > protocol into reality to better understand the invariants, the constraints > and boundaries and how the components of the solution fit together. I for > one find these sorts of text helpful in better understanding the problem. > > The "reward" to the authors for the non-trivial work for pulling this > together is a published RFC. Maybe some may consider that to be vanity, but > the fact is that people are more inclined to so work if they perceive a > tangible reward for their work, and an RFC is one of the few "rewards" the > IETF has to offer. > > Publication of such text as an RFC thus serves two purposes: a starting > point for someone to understand the problem that the designers were trying > to solve as seen at the time that they worked on it, and as an > acknowledgement by the IETF that the work of defining the scenarios of use > was done by the authors. > > I therefore think that dismissing such work in this way is > counterproductive and demotivating, quite the opposite of what the IESG > should be striving to achieve. > I'm perhaps less sanguine than you about the value of use case documents, but the IESG statement doesn't say that they aren't valuable, what it says is that they don't always have high *archival* value (and I note that the second value proposition you mention isn't about the value of the document being published at all, but rather about rewarding the authors). That's speaking in general, of course. I *did* review this specific document and in my opinion the level of detail and domain specificity in it does not have very high archival value. So, while I did not abstain, were I making the choice, i would not publish this as an RFC. -Ekr Best regards > > Stewart > > > --00000000000062771d057925ad46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable     --00000000000025d65f057931f631-- From nobody Sat Oct 27 10:53:59 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC37D128DFD; Sat, 27 Oct 2018 10:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=m7+vYccU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xy8vrPi/ 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 hEUifuKNChBP; Sat, 27 Oct 2018 10:53:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9B6124BAA; Sat, 27 Oct 2018 10:53:54 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 873E921B6B; Sat, 27 Oct 2018 13:53:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 27 Oct 2018 13:53:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=4oyZQBFKOAaFRIfgdX+qybF arYW32uL/bs8wMc/eMBw=; b=m7+vYccU1CgFCmOgFVpjOXT7eJpBEM/XSf/MZZK 36Yr7AqexHZhMoHwOfo0iORjft0KzvkBWLz/4OVI7epct3tkUICakxRBEDfdEjWA wor7tQGLpn2BJogWoMQ4Jl6QpECgp2HkxSXrrESdZHwXBFsXXjOIhFI6hQCyzGcI GccQ20paLvQxDWHQnzPQETriaUFvdO5DNeXzuffjtGglsXQcbGBg1PJS3/ha8br6 YORR+ofaXJAqd53TUqkPnZ5mWB1hBrDVijVHiUf44NjxL37nqiU3sDRjwvJ41Vms Wo20Dtg1WIDp7iKgqrhdnDKIK8azFgq08M/kgEDMGviReZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4oyZQB FKOAaFRIfgdX+qybFarYW32uL/bs8wMc/eMBw=; b=xy8vrPi/beN9TVpHoa7Suv J3tuwuAkm/kbEtRiIkzPh3zdY1ByMNF93wN+PmRGj1kLWxzdfvlvWiSiz9lCNdWZ Cnfl9e/0owFXjLpccNo4dM0baqjyxQigCth7ftUoYe1Uxd8IgTmrVvGEnPsV+oyJ o9zbzsoCqgWa7asKILVufDRr2ZaY2x6YdVY3qdUwhpBs92nx/55/guPiqqEyumN9 numCaZMxXeSxntqCMLxzR7u/J3msPQfDX3Par/xWAAG8M2wRk3yh+xRR3n/piXKV fy4y0xyg8Tt+NjpABnB/E7pymp9+pPehyWBwqgOSt2uzAN+La0THzXlJSedVZdDQ == X-ME-Sender: X-ME-Proxy: Received: from [172.20.14.63] (unknown [62.154.197.55]) by mail.messagingengine.com (Postfix) with ESMTPA id B9355102DD; Sat, 27 Oct 2018 13:53:51 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5A4206AD-B608-4CA5-9EEA-94820067881F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 27 Oct 2018 19:53:49 +0200 In-Reply-To: <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> Cc: IESG , detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, draft-ietf-detnet-use-cases@ietf.org To: Stewart Bryant References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 17:53:57 -0000 --Apple-Mail=_5A4206AD-B608-4CA5-9EEA-94820067881F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stewart, > On Oct 26, 2018, at 7:38 PM, Stewart Bryant = wrote: >=20 >=20 >=20 > On 25/10/2018 10:36, Alissa Cooper wrote: >> Consistent with the IESG statement on supporting documents >> = = , >> I am abstaining. Notably, the detnet charter states: >=20 > I wonder how aligned with the rest of the IETF this policy is when = applied to use cases documents? I suppose we would have heard more concerns when we published the = statement if people thought it was not aligned. >=20 > Pulling together use case information is often a method of focussing = the design requirements by casing them into something solid that those = working on the problem can use to build a mental model of how the design = maps to reality. Some people need these models to visualise what they = are attempting to design. Some reader need them to solidity an abstract = protocol into reality to better understand the invariants, the = constraints and boundaries and how the components of the solution fit = together. I for one find these sorts of text helpful in better = understanding the problem. >=20 > The "reward" to the authors for the non-trivial work for pulling this = together is a published RFC. Maybe some may consider that to be vanity, = but the fact is that people are more inclined to so work if they = perceive a tangible reward for their work, and an RFC is one of the few = "rewards" the IETF has to offer. I think considering RFCs as rewards to individuals for their work would = create some fairly perverse incentives that would not align well with = the IETF=E2=80=99s goals of producing output of sound engineering = quality. (Not a comment on the quality of this document in particular, = but about the general effect.) >=20 > Publication of such text as an RFC thus serves two purposes: a = starting point for someone to understand the problem that the designers = were trying to solve as seen at the time that they worked on it, and as = an acknowledgement by the IETF that the work of defining the scenarios = of use was done by the authors. >=20 > I therefore think that dismissing such work in this way is = counterproductive and demotivating, quite the opposite of what the IESG = should be striving to achieve. I could see how this conclusion could follow from your other premises if = I were to hold a DISCUSS indefinitely, but I balloted ABSTAIN = purposefully because it doesn=E2=80=99t block publication. Thanks, Alissa >=20 > Best regards >=20 > Stewart >=20 >=20 --Apple-Mail=_5A4206AD-B608-4CA5-9EEA-94820067881F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Stewart,

    = --Apple-Mail=_5A4206AD-B608-4CA5-9EEA-94820067881F-- From nobody Sat Oct 27 10:56:20 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D2130E2F; Sat, 27 Oct 2018 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=T4dmY1uG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kPSBCuXZ 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 HvUq6LNjexpq; Sat, 27 Oct 2018 10:56:15 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A77D130E1E; Sat, 27 Oct 2018 10:56:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7E6EE21947; Sat, 27 Oct 2018 13:56:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 27 Oct 2018 13:56:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=SX7lZ1+gbqNy/a+I7lUf4oZ HziZkqzd14PWl5no7EaQ=; b=T4dmY1uGdXe0cOvjfSuG31SltPLYoqSc60xMsri 6IE+4TJU95eikfUoyy6sb6AEGuxE1zFso3G8Tv5A5UKCFZvLEFDQWnQfELIYTD7x zNkRB0QI3brIWJXznERvZ3jXgTeVDp6vBUMIbhLM2r6Da8KxcqAyM2Y6hxEeIZU9 +IyHfQLJkBAoi4z4Qa9IUz/5NhCwi18MBrlICrmsJUrpzPMQvRBVRxMbhHhhyhl2 qdPpamaKHrubyue2GTNf3Awvo9ZTd2iZgvFYZBzEKHnUzeSjxnLjC/9mKTowFQd6 HY0fR3C7d6bJsgr1iHqlTA92iCfUuNN5t0SXNxMPB9x09iA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SX7lZ1 +gbqNy/a+I7lUf4oZHziZkqzd14PWl5no7EaQ=; b=kPSBCuXZCpFvp3nx46osEi s9CN4kuT81yf5dJouXbD9m0ufTtzC5bTcmINs/MT6DLDDtEgOUEp6MNEF/N1LZFq jh334swtAVyVJ3pALEKI8hDhLN3hKDtuVm1xTiSbVf3J53oYnyes26BUrsgJ+DxM qtefnzj7+Nl28eopAZryR5pF3WJ2lfxGu0RFr2nSpkNBOCtTmRGenN7Us+zW3P/w ULknmn5S+xYkSZQrhJX9kOZlP4iqy9OTXhafJVRueCvgAGwF0l68gciq7/N+lD9/ DFNlvpGCzG8+bUfOPI7pqYAyw0WO0RQY2GOiKQKEDySSrunaLI3LuTe8Nr20cjaQ == X-ME-Sender: X-ME-Proxy: Received: from [172.20.14.63] (unknown [62.154.197.55]) by mail.messagingengine.com (Postfix) with ESMTPA id BAD7E102DD; Sat, 27 Oct 2018 13:56:12 -0400 (EDT) From: Alissa Cooper Message-Id: <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E739BA0-938B-4D2F-A371-89AC63126474" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 27 Oct 2018 19:56:11 +0200 In-Reply-To: Cc: "BRUNGARD, DEBORAH A" , Stewart Bryant , The IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" To: Spencer Dawkins at IETF References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 17:56:18 -0000 --Apple-Mail=_4E739BA0-938B-4D2F-A371-89AC63126474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, > On Oct 27, 2018, at 10:52 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Deborah, >=20 > On Fri, Oct 26, 2018, 12:47 BRUNGARD, DEBORAH A > wrote: > Hi Stewart, >=20 > =20 >=20 > I agree =E2=80=93 I sent an earlier reply (on the list) to Alissa = explaining why we went for publication. As this is a document which will = be looked at by IEEE and others, it is of value to have it published vs. = a wiki. And publication indicates consensus of the group. >=20 > =20 >=20 > I will be following up with the IESG on both the interpretation of the = IESG statement for publishing informationals and use of Abstains so we = can be consistent for the community. >=20 > Are you thinking following up in Bangkok? >=20 > My understanding matches yours - the problem we were solving was when = we chartered a theoretically 18-24 month working group to specify = something developers could implement, and the working group spent 17-23 = months on use cases, problem statements, requirements docs, and = architectures, and developers had nothing.=20 >=20 > We also had publication requests for these drafts that had been useful = at the beginning of solutions work, but hadn't been maintained since = that started, so weren't consistent with the standards-track documents = they had supported, being published at the same time. >=20 > That was why I thought the IESG came up with the statement on working = group support documents - not to ban classes of (informational) = documents, but to get to standards-track documents faster. An ABSTAIN ballot does not ban a document or a class of documents. It is = explicitly defined to allow for the publication of the document. Alissa >=20 > We can talk about what the right thing to do is, but I don't think the = IESG has a common understanding about that today. >=20 > Each IESG is special, and this IESG can certainly change the way the = current IESG works (within our BCP framework), but it's likely that this = is a change we should confirm with the community, after we ourselves = figure out this IESG thinks. >=20 > Spencer >=20 --Apple-Mail=_4E739BA0-938B-4D2F-A371-89AC63126474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Spencer,

    On Oct 27, 2018, at 10:52 AM, Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com> wrote:

    Hi, Deborah,

    On Fri, Oct 26, 2018, = 12:47 BRUNGARD, DEBORAH A <db3546@att.com> = wrote:

    Hi = Stewart,

     

    I agree = =E2=80=93 I sent an earlier reply (on the list) to Alissa explaining why = we went for publication. As this is a document which will be looked at = by IEEE and others, it is of value to have it published vs. a wiki. And publication indicates consensus of the group.

     

    I will be following up with the = IESG on both the interpretation of the IESG statement for publishing = informationals and use of Abstains so we can be consistent for the = community.

    Are you thinking following up in = Bangkok?

    My understanding matches yours - the problem we = were solving was when we chartered a theoretically 18-24 month working = group to specify something developers could implement, and the working = group spent 17-23 months on use cases, problem statements, requirements = docs, and architectures, and developers had nothing. 

    We also had publication requests for these drafts that had = been useful at the beginning of solutions work, but hadn't been = maintained since that started, so weren't consistent with the = standards-track documents they had supported, being published at the = same time.

    That was why I thought the IESG came up with the = statement on working group support documents - not to ban classes of = (informational) documents, but to get to standards-track documents = faster.

    An = ABSTAIN ballot does not ban a document or a class of documents. It is = explicitly defined to allow for the publication of the = document.

    Alissa


    We can talk about what the = right thing to do is, but I don't think the IESG has a common = understanding about that today.

    Each IESG is special, and = this IESG can certainly change the way the current IESG works (within = our BCP framework), but it's likely that this is a change we should = confirm with the community, after we ourselves figure out this IESG = thinks.

    Spencer


    = --Apple-Mail=_4E739BA0-938B-4D2F-A371-89AC63126474-- From nobody Sun Oct 28 18:51:11 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CF3123FFD; Sun, 28 Oct 2018 18:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH-8lGSlu36W; Sun, 28 Oct 2018 18:51:07 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 DDFFD124C04; Sun, 28 Oct 2018 18:51:06 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id g8-v6so3301909ljk.1; Sun, 28 Oct 2018 18:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dIgM+BDF0tm+PW80UMD24BN0zGEGXMfOVdaD+/dFfkI=; b=n+d9dGWFcqCHI2tgsAgp5vXwNMLa0on39TyjfAaDvoPexZIlkoM7aCFPC7jP3XiMnq gI+yTZ+m0+A8h9hcHsqEMoPq8fbaLkSrLvSwzMkTaDeMfZzivY2MukXkNOLt5PXvs4KA eQtbQQ4kg1RFHMlqnUAdgXAIF6KN+499UEWojrfw8t8hgp9UveHQKTC0KAzUm6JEpQmN YswfFYUEA8veF4QLspEudUjAUpMI1wTxkRfFjW4v/owdzjrgNhxGDM/SSWc3IixSh+7x KPwTntn7viVHFcI4gYncbtCfEXSQl+yBVJwT8agdUmKrzetD98kFSzSt/AnMuEPVwUQr 3A7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dIgM+BDF0tm+PW80UMD24BN0zGEGXMfOVdaD+/dFfkI=; b=p+/DtkXEimbKT+1S6NQemA9pCBZIfgtvniUZR5ZIFhrLf8FzWvhonHYDdHCnrSGjOO bFXrtkoqDvjrh/fA65JXJWVlGRxI+BgPhC7TeF3FagXVSOIXD6tIQzjfS9Vmrfav4Acv K/5LzsPoShtt8zq6K2d3cenHBKXfWmCcjUHEQkV75fO2qwlScArCCaB3loYzVGzI8j3y iTvXlQ+i8+W5pZcquxlh0cK5f0s+gOy1QYc0tnH4lKgrTPeSdzhZHqlra3NKVVtNsvQf Qjbi4dnSTu+PhQfqm3FDVlJ5VDl/d6MO9hjh0UKSTJp7cKlJ7qzvqxI7JV1dFFDHHibR cIBw== X-Gm-Message-State: AGRZ1gL5IIiuevV2QhT1l5V9o98Tw83RnVyc/4C5drUM/3E/ABQt0Bx7 mBQwtqL+YaZjzlP0PSvDWxIvPrJ+B/MOcDAl9Ts= X-Google-Smtp-Source: AJdET5d8a36P/iezf3GuOWvM+DPWqQOqfrMxCCE2FFNSrKYlAz0H1FTJhJqNXKZush9a3TEVtmPpRw2IGhe2y55VQH8= X-Received: by 2002:a2e:8545:: with SMTP id u5-v6mr7698374ljj.164.1540777864783; Sun, 28 Oct 2018 18:51:04 -0700 (PDT) MIME-Version: 1.0 References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> In-Reply-To: <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> From: Spencer Dawkins at IETF Date: Sun, 28 Oct 2018 20:50:49 -0500 Message-ID: To: Alissa Cooper Cc: "BRUNGARD, DEBORAH A" , Stewart Bryant , The IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004ee9dc0579544dd6" Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 01:51:10 -0000 --0000000000004ee9dc0579544dd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Alissa, On Sat, Oct 27, 2018, 12:56 Alissa Cooper wrote: > Hi Spencer, > > On Oct 27, 2018, at 10:52 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Deborah, > > On Fri, Oct 26, 2018, 12:47 BRUNGARD, DEBORAH A wrote: > >> Hi Stewart, >> >> >> >> I agree =E2=80=93 I sent an earlier reply (on the list) to Alissa explai= ning why >> we went for publication. As this is a document which will be looked at b= y >> IEEE and others, it is of value to have it published vs. a wiki. And >> publication indicates consensus of the group. >> >> >> >> I will be following up with the IESG on both the interpretation of the >> IESG statement for publishing informationals and use of Abstains so we c= an >> be consistent for the community. >> > Are you thinking following up in Bangkok? > > My understanding matches yours - the problem we were solving was when we > chartered a theoretically 18-24 month working group to specify something > developers could implement, and the working group spent 17-23 months on u= se > cases, problem statements, requirements docs, and architectures, and > developers had nothing. > > We also had publication requests for these drafts that had been useful at > the beginning of solutions work, but hadn't been maintained since that > started, so weren't consistent with the standards-track documents they ha= d > supported, being published at the same time. > > That was why I thought the IESG came up with the statement on working > group support documents - not to ban classes of (informational) documents= , > but to get to standards-track documents faster. > > > An ABSTAIN ballot does not ban a document or a class of documents. It is > explicitly defined to allow for the publication of the document. > Understood. I've also gotten mail this past summer from one of our most experienced TSV chairs, who did not understand the meaning of an avalanche of ABSTAINs in the way that you and I understand it. He may not be the only person in the IETF to have missed that subtle distinction. Without going back for a quote, he was basically saying he thought more tgan one ABSTAIN was a pretty strong signal from the IESG that a document should not be published. Travel safely. Spencer Alissa > > > We can talk about what the right thing to do is, but I don't think the > IESG has a common understanding about that today. > > Each IESG is special, and this IESG can certainly change the way the > current IESG works (within our BCP framework), but it's likely that this = is > a change we should confirm with the community, after we ourselves figure > out this IESG thinks. > > Spencer > >> > --0000000000004ee9dc0579544dd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Alissa,

    On Sat, Oct 27, 2018, 12:56 Alissa Cooper <alissa@cooperw.in> wrote:
    Hi Spencer,

    On Oct 27, 20= 18, at 10:52 AM, Spencer Dawkins at IETF <spencerdawkins.ietf= @gmail.com> wrote:

    Hi, Deborah,

    On Fri, Oct 26, 2018, 12:47 BRUNGARD, DE= BORAH A <db3546@att.com> wrote:

    H= i Stewart,

    =C2=A0

    I agree =E2=80=93 I sent an earlier reply (on t= he list) to Alissa explaining why we went for publication. As this is a doc= ument which will be looked at by IEEE and others, it is of value to have it= published vs. a wiki. And publication indicates consensus of the group.

    =C2=A0=

    I= will be following up with the IESG on both the interpretation of the IESG = statement for publishing informationals and use of Abstains so we can be co= nsistent for the community.

    =
    Are you thinking following up in Bangkok?

    My understanding matches yours - the = problem we were solving was when we chartered a theoretically 18-24 month w= orking group to specify something developers could implement, and the worki= ng group spent 17-23 months on use cases, problem statements, requirements = docs, and architectures, and developers had nothing.=C2=A0

    We also had publication requests for the= se drafts that had been useful at the beginning of solutions work, but hadn= 't been maintained since that started, so weren't consistent with t= he standards-track documents they had supported, being published at the sam= e time.

    That was why I t= hought the IESG came up with the statement on working group support documen= ts - not to ban classes of (informational) documents, but to get to standar= ds-track documents faster.

    An ABSTAIN ballot does not ban a document or a class of documents. It is = explicitly defined to allow for the publication of the document.

    Understood.=C2=A0

    I&#= 39;ve also gotten mail this past summer from one of our most experienced TS= V chairs, who did not understand the meaning of an avalanche of ABSTAINs in= the way that you and I understand it.=C2=A0

    He may not be t= he only person in the IETF to have missed that subtle distinction.

    Without going back fo= r a quote, he was basically saying he thought more tgan one ABSTAIN was a p= retty strong signal from the IESG that a document should not be published.<= /div>

    Travel safely.

    Spencer
    <= div>
    Alissa


    We can talk about what the= right thing to do is, but I don't think the IESG has a common understa= nding about that today.

    = Each IESG is special, and this IESG can certainly change the way the curren= t IESG works (within our BCP framework), but it's likely that this is a= change we should confirm with the community, after we ourselves figure out= this IESG thinks.

    Spenc= er

    =


    --0000000000004ee9dc0579544dd6-- From nobody Mon Oct 29 10:42:15 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA255131050; Mon, 29 Oct 2018 10:42:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5ZuLQ8SXt2E; Mon, 29 Oct 2018 10:42:05 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 A3C58131048; Mon, 29 Oct 2018 10:42:02 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id p2-v6so8803346wmc.2; Mon, 29 Oct 2018 10:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cNkLHDAg8b8AxFqwe/Ep97ws1HF7VKiFfgyZMJ3IwDQ=; b=IPp2MoY29+ZG2/W3ZlR8n150Dvxx4p4vTzVghzeE0tMX65SRzHW3zOht4tzGFHgzBY /SmuZsYCjKlyEWN0p3vGForDSqcCvX3r02SYYwUVr5+a3nsfGFTcDeuT0uezoqFVvgTO QMlcgxnFU/2VzpENwPCsnoJsAIrk+gO3Je3bg5V6nooaW9OrDn2zJRu/Fdm+TIWcHhRJ jy5n3CqbrzsxuyY+cgJsp9irj+VStrbJObxebD2fM5TQo3x2eUFdTkok+3iftHFFyIDa ey+dOJyO0Ar1NL+BxZ2Wyef6MAJ7i8DiaaltFvltWriBrK7yrJ/D2PJXrhMOXAOfn4RP 7hVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cNkLHDAg8b8AxFqwe/Ep97ws1HF7VKiFfgyZMJ3IwDQ=; b=qeCKajQFTCNIxVuznywNmSL/ek6q5FO6gQZw+g3xT5ySXOpD5JcRC4UVfVXIciT8rY Ob9UN1u+z176DVl7bQmQ68jHWwGhFIgaeYl0M9v4uKa+12CicOlG+kEG7WGlAUWrKHsO P6hSpDOGsO0eMtcye9fET8jPbVnppPC+W3CNShEJByi5KjVHckVtv75xRCEswFqb7HIF QPlgqC+bhEyRW+LRKxn0PAwknt4DcWWAi6EP4832jFjQcRfXzvGALt1miBAARic7qvbk 5MP2f5vcnrAUQQ307Mzb5H7mBYwfVwuDFRChoNzuPVfgpik02aWokGG2p5BcVTlJvoNt IREg== X-Gm-Message-State: AGRZ1gLeqSMhu1x+vDTRLYw2gsp38zwzS4xbKDjJ02D7LiFNbRqR574n GFiT1X+1GVDBhhCJvJph3AQs+9X8 X-Google-Smtp-Source: AJdET5dsjqRd4K75GbuVhyd1HXHBSnBhyGXGddTl+aZ8NJjciNxJZktR2s9ls5/cf/1O3RXCuBIPXw== X-Received: by 2002:a1c:d750:: with SMTP id o77-v6mr14010820wmg.110.1540834920643; Mon, 29 Oct 2018 10:42:00 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l6-v6sm5293504wrs.85.2018.10.29.10.41.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 10:41:59 -0700 (PDT) To: Spencer Dawkins at IETF , Alissa Cooper Cc: "BRUNGARD, DEBORAH A" , The IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> From: Stewart Bryant Message-ID: <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> Date: Mon, 29 Oct 2018 17:41:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 17:42:07 -0000 On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: > Without going back for a quote, he was basically saying he thought > more tgan one ABSTAIN was a pretty strong signal from the IESG that a > document should not be published. That was always my understanding when I was on the IESG. - Stewart From nobody Mon Oct 29 12:02:51 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7351D131065; Mon, 29 Oct 2018 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD13lPCnRSXN; Mon, 29 Oct 2018 12:02:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464C4131069; Mon, 29 Oct 2018 12:02:38 -0700 (PDT) Received: from Svantevit.attlocal.net (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9TJ2Dgo027536 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Oct 2018 14:02:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.attlocal.net To: Stewart Bryant , Spencer Dawkins at IETF , Alissa Cooper Cc: "detnet@ietf.org" , "BRUNGARD, DEBORAH A" , "draft-ietf-detnet-use-cases@ietf.org" , The IESG , "detnet-chairs@ietf.org" , "lberger@labn.net" References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> From: Adam Roach Message-ID: <84792317-1414-109e-2e56-57f034d16219@nostrum.com> Date: Mon, 29 Oct 2018 14:02:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 19:02:43 -0000 On 10/29/18 12:41 PM, Stewart Bryant wrote: > > > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: >> Without going back for a quote, he was basically saying he thought >> more tgan one ABSTAIN was a pretty strong signal from the IESG that a >> document should not be published. > > That was always my understanding when I was on the IESG. It is mine as well, but it only serves as advice. For informational documents, it has no process significance, since it does not preclude publication. Basically, if there are a large number of ABSTAINs, it means that the working group is publishing the document over the objections of the IESG (unless it uses this advice as an opportunity to reconsider the request for publication). It is my understanding that the process is set up exactly to allow this kind of thing to happen. It's certainly fair game to discuss whether the system *should* be set up this way, but I can't imagine any realistic changes other than ones that would actually block publication under such circumstances -- and I doubt that's where the community wants to take things. In this particular case, it appears as if you're trying to get an IESG member to say that she supports publication of a document when that is not actually true. Given that there is no practical difference in getting the document published, this pressure seems kind of problematic. /a From nobody Mon Oct 29 14:36:09 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71B2131028; Mon, 29 Oct 2018 14:36:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_umD1wBJHML; Mon, 29 Oct 2018 14:35:58 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 0640A131027; Mon, 29 Oct 2018 14:35:58 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id q6-v6so7244725lfh.9; Mon, 29 Oct 2018 14:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2fybmI55GpIy3hIh/Ny5YlRtXGjoT1u+zxDZq+z46qM=; b=eUnq4yc1tzNCpo5EsNzUB3LIA3XZJwBKvor97RZw62jHOyDqczlpbcW6BMlLMFwKR7 O4hh0zMKonC1XAFfLkTj/r5yIP7y8msenRs6cP/duuUpAdIoESLbKbtim5w5SgyN4j5A Z1MMoe2C8LYCuoaGGm1qlvYvzmp/ocAe9oa2o/OOCnAD+VA2BJLFVdE07S0o0hQkDqMz C3tzDib1y5hFYF/8a1jO9+hkQ9Pf2CTGDm3SpL7CaQ2AIfM+EA9N4YQbHcEXinm52CF6 FzKumBcf4Hhpvjr+WPkWssV8YoWgSXyXQ2TYoSQrcuQO5io0YrUV97RZ9PxOxXoacSfO vL4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2fybmI55GpIy3hIh/Ny5YlRtXGjoT1u+zxDZq+z46qM=; b=iGYsPJnzUVYOkH6ptds7Q59+y0fbT45Vxu6Mczyur6bpKtIF5kRR7rUPqQc+/cR8/S yJkVXwl7AdZXJBU1G6XoL0EpT+kTPhCt3SDgSNSqxMTnoxBV/3IZRjqtoOqirGv1zY8H EotZIpalVKMTm1oFfvQGqoIKz+Z8LOgz1tFAaqS2o94wHs5OCZdqidwkvVLKO2RxcP4t KSE7patGS2EVhn1a6tEPqPTH1l+MvgTij2MgR+AHn9tbNDLXtYmX5dEGGLkDnD+kynqE TshvxyLb8/idyBfiGGFFqEhCG4GyWoYyF+zPwj2UvPm6ae7HIeOMHTzVA27To+479OzP AoDw== X-Gm-Message-State: AGRZ1gJ2V5pm1+0Cojh1JU0i8Jq7/70FzFviuBm1+stdvO9gVutZD3ox ia91pyf+IHUjrQNb385wYlv7ylCsCy6Og8KNsM1EaOJE X-Google-Smtp-Source: AJdET5dsj9DtREo421sXbXNE17W1kqkwj3NYWifS4SrvSRFUxugi7kvfm+3Mz5i9IIJfWqD4UcirfDoJB0EjEOsOacc= X-Received: by 2002:a19:d145:: with SMTP id i66mr237086lfg.97.1540848955966; Mon, 29 Oct 2018 14:35:55 -0700 (PDT) MIME-Version: 1.0 References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> <84792317-1414-109e-2e56-57f034d16219@nostrum.com> In-Reply-To: <84792317-1414-109e-2e56-57f034d16219@nostrum.com> From: Spencer Dawkins at IETF Date: Mon, 29 Oct 2018 16:35:43 -0500 Message-ID: To: Adam Roach Cc: Stewart Bryant , Alissa Cooper , detnet@ietf.org, "BRUNGARD, DEBORAH A" , draft-ietf-detnet-use-cases@ietf.org, IESG , DetNet Chairs , Lou Berger Content-Type: multipart/alternative; boundary="000000000000ac4a0f057964da29" Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 21:36:01 -0000 --000000000000ac4a0f057964da29 Content-Type: text/plain; charset="UTF-8" Hi, Adam, On Mon, Oct 29, 2018 at 2:02 PM Adam Roach wrote: > On 10/29/18 12:41 PM, Stewart Bryant wrote: > > > > > > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: > >> Without going back for a quote, he was basically saying he thought > >> more tgan one ABSTAIN was a pretty strong signal from the IESG that a > >> document should not be published. > > > > That was always my understanding when I was on the IESG. > > > It is mine as well, but it only serves as advice. For informational > documents, it has no process significance, since it does not preclude > publication. Basically, if there are a large number of ABSTAINs, it > means that the working group is publishing the document over the > objections of the IESG (unless it uses this advice as an opportunity to > reconsider the request for publication). It is my understanding that the > process is set up exactly to allow this kind of thing to happen. > > It's certainly fair game to discuss whether the system *should* be set > up this way, but I can't imagine any realistic changes other than ones > that would actually block publication under such circumstances -- and I > doubt that's where the community wants to take things. > > In this particular case, it appears as if you're trying to get an IESG > member to say that she supports publication of a document when that is > not actually true. Given that there is no practical difference in > getting the document published, this pressure seems kind of problematic. Pronouns are confusing, but since Stewart was replying to me, I'm not sure who "you" is. But just in case it's me, we're still talking about an Informational document that requires one Yes and no Discusses to publish, no? And our BCP says that Informational documents do not reflect IETF consensus or recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2. So, I know why an AD would ballot DIscuss on an Informational document, but I'm less clear about why ADs ballot Abstains. Of course, we've had conversations about this at least since Stewart was on the IESG. So I'll stop typing, and go back to packing. Travel safely, all, of course. Spencer --000000000000ac4a0f057964da29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Adam,=C2=A0

    On Mon, Oct 29, 2018 at 2:02 PM Adam Roach <<= a href=3D"mailto:adam@nostrum.com">adam@nostrum.com> wrote:
    On 10/29/18 12:41 PM, St= ewart Bryant wrote:
    >
    >
    > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote:
    >> Without going back for a quote, he was basically saying he thought=
    >> more tgan one ABSTAIN was a pretty strong signal from the IESG tha= t a
    >> document should not be published.
    >
    > That was always my understanding when I was on the IESG.


    It is mine as well, but it only serves as advice. For informational
    documents, it has no process significance, since it does not preclude
    publication. Basically, if there are a large number of ABSTAINs, it
    means that the working group is publishing the document over the
    objections of the IESG (unless it uses this advice as an opportunity to reconsider the request for publication). It is my understanding that the process is set up exactly to allow this kind of thing to happen.

    It's certainly fair game to discuss whether the system *should* be set =
    up this way, but I can't imagine any realistic changes other than ones =
    that would actually block publication under such circumstances -- and I doubt that's where the community wants to take things.

    In this particular case, it appears as if you're trying to get an IESG =
    member to say that she supports publication of a document when that is
    not actually true. Given that there is no practical difference in
    getting the document published, this pressure seems kind of problematic.

    Pronouns are confusing, but since Stewart was= replying to me, I'm not sure who "you" is.=C2=A0
    <= br>
    But just in case it's me, we're still talking about a= n Informational document that requires one Yes and no Discusses to publish,= no? And our BCP says that Informational documents do not reflect IETF cons= ensus or recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2.=C2=A0= =C2=A0

    So, I know why an AD would ballot DIscuss o= n an Informational document, but I'm less clear about why ADs ballot Ab= stains.=C2=A0

    Of course, we've had conversatio= ns about this at least since Stewart was on the IESG. So I'll stop typi= ng, and go back to packing.

    Travel safely, all, of= course.

    Spencer
    --000000000000ac4a0f057964da29-- From nobody Mon Oct 29 19:23:20 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8494126F72; Mon, 29 Oct 2018 19:23:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDphVKL3Zrtx; Mon, 29 Oct 2018 19:23:08 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 74F9712008A; Mon, 29 Oct 2018 19:23:08 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id d18-v6so4377190yba.4; Mon, 29 Oct 2018 19:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7T8f8PWLvPizn0vG7Y7HAvGihi2tbMKSoqIM/KVS9yA=; b=VWrKNaItovLfq1UfVJe9gIwr14HK+R0Fqf05zk7bzDaeNMZkvghXDTMAlhzvq0wY7s aN/oYWtKQA37pQnu3UtaEWDtfCJO/aIKajtFvivn3g2mqdfGBI0tc+FsIHfmkis7swZe al0TWkr5Q8wrzva01BlNHh22BYr6N3zKzBwl9kUS9GodLI8i692hPKIvbXyA337DCTX/ XTXzzc950DqG2Bur8RIyzsXnMPfRSNp52mHTnQ49/j7cd/7qnHdjyQYCo/b7IvWNHCDO bKrhF41ueZRfMNSFqNJT1TE5wwbEj+P4/mGAEnrsPlvrJMcfDpPFUGR39P2MOIbLlHBL xoTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7T8f8PWLvPizn0vG7Y7HAvGihi2tbMKSoqIM/KVS9yA=; b=kxSpMokNeKM235FmHTwTAzvnziiAI8LgMvh3Rgw3grnkXah6h3JijW/gx0Jo/aRO4A lscX37Kv5mY6BOSE+sjujoeFQudSp+IHUIFXTQ3ooBioGQAdBd5C+CcTV6iAHpnpHHTh 33TgM76ea/uKh4ScI4K1gQTaPb0JgFowWbHR1IUm5K+bKcooBMVexjP2RwbX9ffOHJ+0 Pc6B6ZKXYfwrz/ct2heuyT54+VHXUEsjZO1gPl7PiPOCSF/vUGa53/6lZKaj4nMQf8eR fuYTdlNL4sQxwuuXxPo3xNjlWPqVcMoGH5lw7pw4tGtv3aQ+vPPzQS5B7DrCyBIES/LS HlVw== X-Gm-Message-State: AGRZ1gK877cRnKxzauL/ut2GKiIfa3MFHTsTUt7ju74WCbxc6d0zZXHS ixFTz1vugz8NRn8CqMukzd0= X-Google-Smtp-Source: AJdET5eMYMdhYNPaZ+AEHTUWCjLIQE/nL3qMn691RrFW2RG6Uk1NvY8j42A07uQzZDy7oJacXxt9DA== X-Received: by 2002:a25:d0d4:: with SMTP id h203-v6mr16409987ybg.70.1540866187354; Mon, 29 Oct 2018 19:23:07 -0700 (PDT) Received: from [10.0.0.18] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id g5-v6sm6206212ywa.39.2018.10.29.19.23.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 19:23:06 -0700 (PDT) From: Suresh Krishnan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A87601D2-3E31-4290-BD15-6D6BCB9B907F" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 29 Oct 2018 22:23:05 -0400 In-Reply-To: Cc: Adam Roach , Lou Berger , "BRUNGARD, DEBORAH A" , Alissa Cooper , draft-ietf-detnet-use-cases@ietf.org, IESG , DetNet Chairs , detnet@ietf.org To: Spencer Dawkins at IETF , Stewart Bryant References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> <84792317-1414-109e-2e56-57f034d16219@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 02:23:11 -0000 --Apple-Mail=_A87601D2-3E31-4290-BD15-6D6BCB9B907F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Spencer, > On Oct 29, 2018, at 5:35 PM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Adam,=20 >=20 > On Mon, Oct 29, 2018 at 2:02 PM Adam Roach > wrote: > On 10/29/18 12:41 PM, Stewart Bryant wrote: > > > > > > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: > >> Without going back for a quote, he was basically saying he thought=20= > >> more tgan one ABSTAIN was a pretty strong signal from the IESG that = a=20 > >> document should not be published. > > > > That was always my understanding when I was on the IESG.=20 >=20 >=20 > It is mine as well, but it only serves as advice. For informational=20 > documents, it has no process significance, since it does not preclude=20= > publication. Basically, if there are a large number of ABSTAINs, it=20 > means that the working group is publishing the document over the=20 > objections of the IESG (unless it uses this advice as an opportunity = to=20 > reconsider the request for publication). It is my understanding that = the=20 > process is set up exactly to allow this kind of thing to happen. >=20 > It's certainly fair game to discuss whether the system *should* be set=20= > up this way, but I can't imagine any realistic changes other than ones=20= > that would actually block publication under such circumstances -- and = I=20 > doubt that's where the community wants to take things. >=20 > In this particular case, it appears as if you're trying to get an IESG=20= > member to say that she supports publication of a document when that is=20= > not actually true. Given that there is no practical difference in=20 > getting the document published, this pressure seems kind of = problematic. >=20 > Pronouns are confusing, but since Stewart was replying to me, I'm not = sure who "you" is.=20 >=20 > But just in case it's me, we're still talking about an Informational = document that requires one Yes and no Discusses to publish, no? And our = BCP says that Informational documents do not reflect IETF consensus or = recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2 = . =20 >=20 > So, I know why an AD would ballot DIscuss on an Informational = document, but I'm less clear about why ADs ballot Abstains.=20 I usually ballot Abstain on an Informational document if I personally do = not believe that the document has any archival value. I feel that = balloting an Abstain lets me stay true to my conscience, while = respecting the consensus of the working group that sent the document = over.=20 Stewart, Are you objecting to anything specific in the text of the IESG = statement itself? If so, I would greatly appreciate it if you can = explain your objection(s).=20 Thanks Suresh --Apple-Mail=_A87601D2-3E31-4290-BD15-6D6BCB9B907F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Spencer,

    On Oct 29, 2018, at 5:35 PM, Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com> wrote:

    Hi, Adam, 

    On Mon, Oct 29, 2018 = at 2:02 PM Adam Roach <adam@nostrum.com> wrote:
    On 10/29/18 12:41 PM, Stewart = Bryant wrote:
    >
    >
    > = On 29/10/2018 01:50, Spencer Dawkins at IETF wrote:
    >>= Without going back for a quote, he was basically saying he thought 
    >> = more tgan one ABSTAIN was a pretty strong signal from the IESG that = a 
    >> document should not be published.
    >
    > That was always my understanding when = I was on the IESG. 


    It is mine as well, but it only = serves as advice. For informational 
    documents, = it has no process significance, since it does not preclude 
    publication. = Basically, if there are a large number of ABSTAINs, it 
    means that = the working group is publishing the document over the 
    objections = of the IESG (unless it uses this advice as an opportunity to 
    reconsider = the request for publication). It is my understanding that the 
    process is = set up exactly to allow this kind of thing to happen.

    It's certainly fair game to discuss whether the system = *should* be set 
    up this way, but I can't imagine any realistic changes other = than ones 
    that would actually block publication under such = circumstances -- and I 
    doubt that's = where the community wants to take things.

    In = this particular case, it appears as if you're trying to get an IESG 
    member to = say that she supports publication of a document when that is 
    not actually = true. Given that there is no practical difference in 
    getting the = document published, this pressure seems kind of = problematic.

    Pronouns are confusing, but since Stewart was replying to me, = I'm not sure who "you" is. 

    But just in case it's me, we're still = talking about an Informational document that requires one Yes and no = Discusses to publish, no? And our BCP says that Informational documents = do not reflect IETF consensus or recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2. &nb= sp;

    So, I know = why an AD would ballot DIscuss on an Informational document, but I'm = less clear about why ADs ballot = Abstains. 

    I usually ballot Abstain on an Informational = document if I personally do not believe that the document has any = archival value. I feel that balloting an Abstain lets me stay true to my = conscience, while respecting the consensus of the working group that = sent the document over. 

    Stewart,
      Are you objecting to = anything specific in the text of the IESG statement itself? If so, I = would greatly appreciate it if you can explain your = objection(s). 

    Thanks
    Suresh

    = --Apple-Mail=_A87601D2-3E31-4290-BD15-6D6BCB9B907F-- From nobody Wed Oct 31 06:15:07 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9FC130E1A; Wed, 31 Oct 2018 06:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QoevVxjZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZkxZ98xq 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 kMkb6_sc6t9B; Wed, 31 Oct 2018 06:14:55 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644AE12DDA3; Wed, 31 Oct 2018 06:14:55 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7AD812228E; Wed, 31 Oct 2018 09:14:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 31 Oct 2018 09:14:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=M tZvr2MexYZVx9jZ3h+/WgkW0mzx864/wUYAg92tHKU=; b=QoevVxjZlEaWT/pjJ R4tBHtd0qK5QiBYILIaiePZ/07AP7yqDckYWuaR905aUinifrwLkYf//VODDO7kV aiB617JQ3MascSeRZoIRSeIcJ1fmuMACGqli53R8eqPrD4qGGSSeYkFWnq6wAVFC Fzy/apSF69XzCCMhPnbB349rBFDexexAxqLNKEUXf7bGC529Nl/wKI3o1khwY+93 +VHe7XGSZZSepTP497cMekkCofcxj4qhtTv6bslBi159L2zuHN97rSfUB0/408zK uBgYgfEeS7jQ+bEraq3NQ8LVaX3Mrgg4VFzvoGOdgT0siy0iCzdAaU6IxDQ4NG3R s2K7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=MtZvr2MexYZVx9jZ3h+/WgkW0mzx864/wUYAg92tH KU=; b=ZkxZ98xqUNHdxZipOGPLAqzARf3HQFKCAfl0Z+JXMQpv8CaPiwmMoDUOm YOa9ZZx8dNxH8rPz+RG9kb7dwai7IJlEaM5t0V7scigNxYnoYmOeZPIUgXar20tZ 9tBAFXkJshzqymfqp5z3I/zAdxwNG498aYtoJ+Anvzdk0k8h+lsH9XME1BWuu9jm RI0behwC6gaQsFSitvRObZf5KdpXbanO2lE4gzkdxGz4g2TDbQ02ieUT3Yv0gQpt VFr82fM87WVieitTWRWRYuh3qRluP3lrkP0isYb9JfLRIOXgTVDnCEAN6k1hQyFg nIQ2M4ybN4wgoVM4pGCEm0UQcx95g== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C3C61042D; Wed, 31 Oct 2018 09:14:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> Date: Wed, 31 Oct 2018 09:14:51 -0400 Cc: Spencer Dawkins at IETF , "BRUNGARD, DEBORAH A" , The IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8D147331-B24B-4D8D-AD59-FFBB726A879F@cooperw.in> References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 13:14:58 -0000 > On Oct 29, 2018, at 1:41 PM, Stewart Bryant = wrote: >=20 >=20 >=20 > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: >> Without going back for a quote, he was basically saying he thought = more tgan one ABSTAIN was a pretty strong signal from the IESG that a = document should not be published. >=20 > That was always my understanding when I was on the IESG. This does not match what is described at = , which is the = guideline I follow. Informational documents require one Yes ballot with = no Discuss ballots. If we wanted to block publication, someone would = need to ballot Discuss, or we would all need to ballot something besides = Yes, including the sponsoring AD. When I filed my ballot, this document already had one Yes and five No = Objection ballot positions, so the implication that my Abstain was meant = to trigger some set of ballots that would block this document seems = misplaced. Alissa >=20 > - Stewart >=20 >=20 From nobody Wed Oct 31 06:17:34 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A2130E34; Wed, 31 Oct 2018 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=CwGzxcgP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FhplgOPO 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 tSdJ-PSjH8pr; Wed, 31 Oct 2018 06:17:30 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA09130E27; Wed, 31 Oct 2018 06:17:30 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4EDD22211E; Wed, 31 Oct 2018 09:17:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 31 Oct 2018 09:17:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=HxSoQFQWOPN8vkIv0+74ZCz 4gx5MAAksXQp+99vfJ8M=; b=CwGzxcgPFg0AK46BkrGiS/tQmnouu6vQIvsDDwZ XF3LwqPG0IR8QHWdpSMfhPwP+ugcQ1nL85e6JbT3EQuHgcBiadgZ5TiR+rETFPLM kVKKSNTd0LyBnz9IiAcqLtrFRod7VLtRYYWt/njpYRDJAMUNmp20t43oAzpSaa9X /lQJSmJEzXlLd73sDQy41KNoGPGQX+fW3odLW+LAdcYpbqMdHIAqmk/wMXIqMTTm 9jSdYzt8X64h83J7bL5zfxiAwdjZpNOUB5D9e1cSGO7AVfjb5CZFoS0HSgVI769E sjLKFUfNUetzU1TzK1OK16u5Np8esaLsG8ROJufLfn1yl/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=HxSoQF QWOPN8vkIv0+74ZCz4gx5MAAksXQp+99vfJ8M=; b=FhplgOPO8JtOWH+dSD920s swAQfJIBGuSmrRVWn0b5rPUOR4xrq3fNdHwUb8kgECgeBWQOTX+/Bxq4kavyOeM+ /MAn/q1xdXaymZUVQtpjZsijhyHi7DcGFEKdY/zLA/P/FtvUzInkpj1lxqRmUbhH PLMRlDJ+K08ZdhHmDQTM/SwHybjPAaDIxS0tlHHTcrlbCiysqqsMVxLcED4/drVZ jyY0A1I/f+h7po2XiGQdwoLQFc/LFZxT3L7OdJrp5z/gazkh3RD3/iJL/Tu1KqTJ wQ5Yc7DYZZ9KYtELbmBKjhqVTpEUgsQjbfzxZsBbwpEQbc0SizLx8F9SrJ2psIFQ == X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 40DD9E425A; Wed, 31 Oct 2018 09:17:28 -0400 (EDT) From: Alissa Cooper Message-Id: <8278D1D7-D4A8-4948-9FA7-2E46104F4BF7@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_06DC5F9D-494B-41E5-906B-6BB248CD14C1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 31 Oct 2018 09:17:27 -0400 In-Reply-To: Cc: Adam Roach , Stewart Bryant , detnet@ietf.org, "BRUNGARD, DEBORAH A" , draft-ietf-detnet-use-cases@ietf.org, IESG , DetNet Chairs , Lou Berger To: Spencer Dawkins at IETF References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> <8367E97A-74C3-4E99-9575-F48BC8ACE2BE@cooperw.in> <152b46f5-4ac4-6449-536b-b8cb7ecf3d21@gmail.com> <84792317-1414-109e-2e56-57f034d16219@nostrum.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 13:17:32 -0000 --Apple-Mail=_06DC5F9D-494B-41E5-906B-6BB248CD14C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 29, 2018, at 5:35 PM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Adam,=20 >=20 > On Mon, Oct 29, 2018 at 2:02 PM Adam Roach > wrote: > On 10/29/18 12:41 PM, Stewart Bryant wrote: > > > > > > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote: > >> Without going back for a quote, he was basically saying he thought=20= > >> more tgan one ABSTAIN was a pretty strong signal from the IESG that = a=20 > >> document should not be published. > > > > That was always my understanding when I was on the IESG.=20 >=20 >=20 > It is mine as well, but it only serves as advice. For informational=20 > documents, it has no process significance, since it does not preclude=20= > publication. Basically, if there are a large number of ABSTAINs, it=20 > means that the working group is publishing the document over the=20 > objections of the IESG (unless it uses this advice as an opportunity = to=20 > reconsider the request for publication). It is my understanding that = the=20 > process is set up exactly to allow this kind of thing to happen. >=20 > It's certainly fair game to discuss whether the system *should* be set=20= > up this way, but I can't imagine any realistic changes other than ones=20= > that would actually block publication under such circumstances -- and = I=20 > doubt that's where the community wants to take things. >=20 > In this particular case, it appears as if you're trying to get an IESG=20= > member to say that she supports publication of a document when that is=20= > not actually true. Given that there is no practical difference in=20 > getting the document published, this pressure seems kind of = problematic. >=20 > Pronouns are confusing, but since Stewart was replying to me, I'm not = sure who "you" is.=20 >=20 > But just in case it's me, we're still talking about an Informational = document that requires one Yes and no Discusses to publish, no? And our = BCP says that Informational documents do not reflect IETF consensus or = recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2 = . =20 >=20 > So, I know why an AD would ballot DIscuss on an Informational = document, but I'm less clear about why ADs ballot Abstains.=20 I ballot Abstain when my position on the document is consistent with = what is described at = >, namely "I = oppose this document but understand that others differ and am not going = to stand in the way of the others.=E2=80=9D Alissa >=20 > Of course, we've had conversations about this at least since Stewart = was on the IESG. So I'll stop typing, and go back to packing. >=20 > Travel safely, all, of course. >=20 > Spencer --Apple-Mail=_06DC5F9D-494B-41E5-906B-6BB248CD14C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Oct 29, 2018, at 5:35 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

    Hi, Adam, 

    On = Mon, Oct 29, 2018 at 2:02 PM Adam Roach <adam@nostrum.com> = wrote:
    On 10/29/18 12:41 PM, Stewart Bryant = wrote:
    >
    >
    > On 29/10/2018 01:50, Spencer Dawkins at IETF wrote:
    >> Without going back for a quote, he was basically saying he = thought
    >> more tgan one ABSTAIN was a pretty strong signal from the IESG = that a
    >> document should not be published.
    >
    > That was always my understanding when I was on the IESG.


    It is mine as well, but it only serves as advice. For informational
    documents, it has no process significance, since it does not preclude =
    publication. Basically, if there are a large number of ABSTAINs, it
    means that the working group is publishing the document over the
    objections of the IESG (unless it uses this advice as an opportunity to =
    reconsider the request for publication). It is my understanding that the =
    process is set up exactly to allow this kind of thing to happen.

    It's certainly fair game to discuss whether the system *should* be set =
    up this way, but I can't imagine any realistic changes other than ones =
    that would actually block publication under such circumstances -- and I =
    doubt that's where the community wants to take things.

    In this particular case, it appears as if you're trying to get an IESG =
    member to say that she supports publication of a document when that is =
    not actually true. Given that there is no practical difference in
    getting the document published, this pressure seems kind of = problematic.

    Pronouns are confusing, but since Stewart was replying to me, = I'm not sure who "you" is. 

    But just in case it's me, we're still = talking about an Informational document that requires one Yes and no = Discusses to publish, no? And our BCP says that Informational documents = do not reflect IETF consensus or recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2. &nb= sp;

    So, I know = why an AD would ballot DIscuss on an Informational document, but I'm = less clear about why ADs ballot = Abstains. 

    I ballot Abstain when my position on the document = is consistent with what is described at <https://www.ietf.org/standards/process/iesg-ballots/>, = namely "I oppose this document but understand that others differ and am = not going to stand in the way of the others.=E2=80=9D

    Alissa


    Of course, we've had conversations = about this at least since Stewart was on the IESG. So I'll stop typing, = and go back to packing.

    Travel safely, all, of course.

    Spencer

    = --Apple-Mail=_06DC5F9D-494B-41E5-906B-6BB248CD14C1--

    On Oct 26, 2018, at 7:38 PM, Stewart Bryant = <stewart.bryant@gmail.com> wrote:

    =20 =20



    On 25/10/2018 10:36, Alissa Cooper wrote:
    Consistent with the IESG statement on =
supporting documents
<https://www.ietf.org/blog/support-documents-i=
etf-working-groups/?primary_topic=3D7&>,
I am abstaining. Notably, the detnet charter states:

    I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents?

    I = suppose we would have heard more concerns when we published the = statement if people thought it was not aligned.


    Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem.

    The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer.

    I = think considering RFCs as rewards to individuals for their work would = create some fairly perverse incentives that would not align well with = the IETF=E2=80=99s goals of producing output of sound engineering = quality. (Not a comment on the quality of this document in particular, = but about the general effect.)


    Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors.

    I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

    I = could see how this conclusion could follow from your other premises if I = were to hold a DISCUSS indefinitely, but I balloted ABSTAIN purposefully = because it doesn=E2=80=99t block publication.

    Thanks,
    Alissa


    Best regards

    Stewart




    On Fri= , Oct 26, 2018 at 10:38 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
    =20 =20 =20



    On 25/10/2018 10:3= 6, Alissa Cooper wrote:
    Consistent with the IESG statement on supporting documents
<https://www.ietf.org/blog/support-documents-ietf-=
working-groups/?primary_topic=3D7&>,
I am abstaining. Notably, the detnet charter states:

    I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents?

    I didn't abstain because I don't care that much, but I am aligne= d with that policy (though it predates me, so I wasn't part of crafting= it).


    Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem.

    The "reward" to the authors for the non-trivial work for pull= ing this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer.

    Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors.

    I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

    I'm perhaps less sanguine than you about the value of use case d= ocuments, but the IESG statement doesn't say that they aren't valua= ble, what it says is that they don't always have high *archival* value = (and I note that the second value proposition you mention isn't about t= he value of the document being published at all, but rather about rewarding= the authors).

    That's speaking in general= , of course. I *did* review this specific document and in my opinion the le= vel of detail and domain specificity in it does not have very high archival= value. So, while I did not abstain, were I making the choice, i would not = publish this as an RFC.

    -Ekr

    Best regards

    Stewart


    --00000000000062771d057925ad46-- From nobody Fri Oct 26 11:27:46 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF1130E6C; Fri, 26 Oct 2018 11:27:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj9eNsMO3jcN; Fri, 26 Oct 2018 11:27:37 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 843F7130DE8; Fri, 26 Oct 2018 11:27:37 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id x12-v6so2271793wrw.8; Fri, 26 Oct 2018 11:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Wuhxp4Nw4JWe3GZzc3ViOgj7SZwxmWXJ79Ftk9GVe+M=; b=vHSjVB8T/+dCHXTu2tkY5yAC9FZBmRFuIwuzX5P+7HGsQbg0CmN4Ui6DBb+87XnIzF tdCSXEqfxy7Oo4kff1MPEg6uZXmt2USx1tfT+QFXNLPzNrqzqItjepNHHR2etETJSUHc WovG7OXlgimGhGwfbr4JBUYsJvojajf+NlTUeIsLXQx4icTYmpvOPy9y1f2rLfqz7+jk 5ye2MS2ee73ZPjhQ/ONeaX7LgryEtv6q8bcp2qwfMl1KzPTURzjZsapx2wBIdeie2YU+ EPcO+1BQvrSPk9ZjglPJH8gpFtnsXA5sWaCVxg9WmjWqP1qhcpNEYtm1VtSNbOp5kyZm mHCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Wuhxp4Nw4JWe3GZzc3ViOgj7SZwxmWXJ79Ftk9GVe+M=; b=RzzBHux/kJATkQqfb+qceeYpELMzbxnudVaKKKwWo24jY4SKc4L6d2NabRy6flapJg balLCaVyTFn7SAfa1C38esjqu6T9Ycn/O2CLOS43MMaEmTk4GBWNN+J2ozfmhk4MsSKG 1hW+IqC18bkCxcnFWgfKHEvDwMwgcPhKToydUzIKLErRxRXTBrVzzCijH6enOGeYP+XK C1XI651T8TmqYBHiK9g8kENHzbsXI1JtFJTqjD+g1O7hvE9/F6b3YOOnp5/A/ftJ7uAg +VpsVvHJcO2oIIrlBhj+Py8o5e/JuAXlLC479QvTDimxjsFP6LokFDplqsQRxllXcupB hdtg== X-Gm-Message-State: AGRZ1gJ3hLNKhNcyCxIGdeEVq2j/3G5d6tMH94z1xAApFS+rooAnbhzB H0a3Z8akylrpiIcEggLIuQ1rvqzD X-Google-Smtp-Source: AJdET5f/5RoldhckeG/ckxiGf7585QjWXLeoEgRkMdPyYVvMJeiSReHoTfPO8d8jmsWMVvHjkEHp1w== X-Received: by 2002:adf:da43:: with SMTP id r3-v6mr6772757wrl.221.1540578455743; Fri, 26 Oct 2018 11:27:35 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y16-v6sm12192938wru.18.2018.10.26.11.27.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Oct 2018 11:27:35 -0700 (PDT) To: Eric Rescorla Cc: Alissa Cooper , IESG , draft-ietf-detnet-use-cases@ietf.org, detnet@ietf.org, Lou Berger , detnet-chairs@ietf.org References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> From: Stewart Bryant Message-ID: <691a868b-d945-ffd2-5eb3-94b1ddfb4823@gmail.com> Date: Fri, 26 Oct 2018 19:27:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------80EF779CC2EDB66089C88707" Content-Language: en-GB Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 18:27:44 -0000 This is a multi-part message in MIME format. --------------80EF779CC2EDB66089C88707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 26/10/2018 19:12, Eric Rescorla wrote: > > > On Fri, Oct 26, 2018 at 10:38 AM Stewart Bryant > > wrote: > > > > On 25/10/2018 10:36, Alissa Cooper wrote: >> Consistent with the IESG statement on supporting documents >> >> , >> I am abstaining. Notably, the detnet charter states: > > I wonder how aligned with the rest of the IETF this policy is when > applied to use cases documents? > > > I didn't abstain because I don't care that much, but I am aligned with > that policy (though it predates me, so I wasn't part of crafting it). Note that I was wondering about the IETF as a whole rather than their current leadership or the leadership that took the decision to publish that IESG statement. > > > Pulling together use case information is often a method of > focussing the design requirements by casing them into something > solid that those working on the problem can use to build a mental > model of how the design maps to reality. Some people need these > models to visualise what they are attempting to design. Some > reader need them to solidity an abstract protocol into reality to > better understand the invariants, the constraints and boundaries > and how the components of the solution fit together. I for one > find these sorts of text helpful in better understanding the problem. > > The "reward" to the authors for the non-trivial work for pulling > this together is a published RFC. Maybe some may consider that to > be vanity, but the fact is that people are more inclined to so > work if they perceive a tangible reward for their work, and an RFC > is one of the few "rewards" the IETF has to offer. > > Publication of such text as an RFC thus serves two purposes: a > starting point for someone to understand the problem that the > designers were trying to solve as seen at the time that they > worked on it, and as an acknowledgement by the IETF that the work > of defining the scenarios of use was done by the authors. > > > I therefore think that dismissing such work in this way is > counterproductive and demotivating, quite the opposite of what the > IESG should be striving to achieve. > > > I'm perhaps less sanguine than you about the value of use case > documents, but the IESG statement doesn't say that they aren't > valuable, what it says is that they don't always have high *archival* > value (and I note that the second value proposition you mention isn't > about the value of the document being published at all, but rather > about rewarding the authors). Quite, but rewarding authors and contributors for their work is fundamental to motivating them. The IETF I see these days seems less motivated that it was in previous days, and motivation is a key part of the IESG role. - Stewart > > That's speaking in general, of course. I *did* review this specific > document and in my opinion the level of detail and domain specificity > in it does not have very high archival value. So, while I did not > abstain, were I making the choice, i would not publish this as an RFC. > > -Ekr > > Best regards > > Stewart > > --------------80EF779CC2EDB66089C88707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



    On 26/10/2018 19:12, Eric Rescorla wrote:


    On Fri, Oct 26, 2018 at 10:38 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:



    On 25/10/2018 10:36, Alissa Cooper wrote:
    Consistent with the IESG statement on supporting documents
<https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,
I am abstaining. Notably, the detnet charter states:

    I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents?

    I didn't abstain because I don't care that much, but I am aligned with that policy (though it predates me, so I wasn't part of crafting it).

    Note that I was wondering about the IETF as a whole rather than their current leadership or the leadership that took the decision to publish that IESG statement.



    Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem.

    The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer.

    Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors.

    I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

    I'm perhaps less sanguine than you about the value of use case documents, but the IESG statement doesn't say that they aren't valuable, what it says is that they don't always have high *archival* value (and I note that the second value proposition you mention isn't about the value of the document being published at all, but rather about rewarding the authors).

    Quite, but rewarding authors and contributors for their work is fundamental to motivating them. The IETF I see these days seems less motivated that it was in previous days, and motivation is a key part of the IESG role.

    - Stewart


    That's speaking in general, of course. I *did* review this specific document and in my opinion the level of detail and domain specificity in it does not have very high archival value. So, while I did not abstain, were I making the choice, i would not publish this as an RFC.

    -Ekr

    Best regards

    Stewart



    --------------80EF779CC2EDB66089C88707-- From nobody Fri Oct 26 14:51:39 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8B127148; Fri, 26 Oct 2018 14:51:36 -0700 (PDT) X-Quarantine-ID: <2bQcDY1VYh3G> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bQcDY1VYh3G; Fri, 26 Oct 2018 14:51:35 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28CA1276D0; Fri, 26 Oct 2018 14:51:34 -0700 (PDT) X-AuditID: 1209190f-e9bff70000004c47-42-5bd38c64259e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 09.3B.19527.56C83DB5; Fri, 26 Oct 2018 17:51:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id w9QLpRFQ016063; Fri, 26 Oct 2018 17:51:29 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9QLpNqR015671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 17:51:25 -0400 Date: Fri, 26 Oct 2018 16:51:23 -0500 From: Benjamin Kaduk To: "Grossman, Ethan A." Cc: Phillip Hallam-Baker , "secdir@ietf.org" , "detnet@ietf.org" , "ietf@ietf.org" , "draft-ietf-detnet-use-cases.all@ietf.org" Message-ID: <20181026215122.GS45914@kduck.kaduk.org> References: <154039718506.6853.7266750048073148979@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT103tuRxt8OSkgsXvT7NZLKY1fmSz 6Hu8nd3i6vLjTBbPNs5nsfiw8CGLA5vHvolHWDx2zrrL7rFkyU+mAOYoLpuU1JzMstQifbsE royHX1ayFLQyVWzoa2BqYLzE2MXIySEhYCJx8d9z9i5GLg4hgTVMErN+/mKDcDYySiw+dhLK ucsksX7tYXaQFhYBVYm7K+eD2WwCKhIN3ZeZuxg5OEQEtCWOn7YAqWcW6GCSuHX3KhNIjbCA m8TSzz/ZQGxeoHWPF55mhBg6lVFixr6fjBAJQYmTM5+wgNjMAloSN/69ZAIZyiwgLbH8HwdI mFMgVuLy3vlgJaICyhJ7+w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+bl pRbpmujlZpbopaaUbmIEhTanJP8OxjkN3ocYBTgYlXh4FxhcjhZiTSwrrsw9xCjJwaQkyjux AyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPdaAVCONyWxsiq1KB8mJc3BoiTOO6FlcbSQQHpi SWp2ampBahFMVoaDQ0mC93IXUKNgUWp6akVaZk4JQpqJgxNkOA/Q8D8gNbzFBYm5xZnpEPlT jIpS4rxtIAkBkERGaR5cLyj1SGTvr3nFKA70ijDvK5AqHmDagut+BTSYCWjwDIULIINLEhFS Ug2MXDFNjl+rm17mVb6LsMud25yRpsu4jCfmwP/6DedSLklvLluiVaCS/EHwU3s3u7X8kU+3 HSY0moR6xc19Pm+H59bCsOY9s3ZcOHAuvfHuIhP1whPZxZGG0x93SXrNXbfznme916PUy3kO Bhfy3x4xvhOvEiioYm/j25j3oEv2pnrgIQWeLRJKLMUZiYZazEXFiQDyY3doGAMAAA== Archived-At: Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-use-cases-19 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 21:51:37 -0000 On Wed, Oct 24, 2018 at 07:57:43PM +0000, Grossman, Ethan A. wrote: > Thanks Phillip. Given that the link in the Use Cases draft to the Security draft is informational only then it can't cause a publication deadlock, correct? That's correct. -Benjamin From nobody Sat Oct 27 01:30:16 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901E512F18C; Sat, 27 Oct 2018 01:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=cnHB6Zru; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZlQIXsxa 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 6Vz-nWVlTfqw; Sat, 27 Oct 2018 01:30:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0901012D4E6; Sat, 27 Oct 2018 01:30:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 05A2D220B3; Sat, 27 Oct 2018 04:30:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 27 Oct 2018 04:30:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=/ GU3fXrgy76flv8mUHFN2iuMZ5mgLunCN/jYUP5JYMY=; b=cnHB6Zru+xwsTuqRR qVb/lZMGbTj9yfC2j25n/ykbRoSTBQ6z5nBduW0dtKyu2wgUQHtleG6hlxRA+Kc0 L5A7pNrbyiPZlJzOJ9nSAtCIiRQW/GG95UkrP2V0d1dsvk0oiP5AfthtYCe3se1+ nj1TkQ0W3HIa7GfWVEbjtE866/K/2M//eem2uUX8VihkC8ik1swERqM21XQtIARv lkyXs8zARMKIfwiojgKDB+bBjbBUxxvYfv/doaBmsMLoDKFtGOvlz/fGtTLELWAq sBa+ko72AouqRQn07dKauO2ZqwJe1t12djp+A/JlEUdu32QTBzm3urKzoKyQDlMj Q33Yw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=/GU3fXrgy76flv8mUHFN2iuMZ5mgLunCN/jYUP5JY MY=; b=ZlQIXsxaPfvHLFl+Owc+mvtHgmSpBLUu4avhYy4z3KVP+TNx16yuwzhqD v1aTJMK2iznoZTCptqLvGomB5shIqKP1WBU3sFBd09DiixpbvTRRuEGn8sSVU9mb uHhrxDYd8lDwmcIOmEPp1mtT0vn6gWs7Krs6yRhNDv2msSKj+lb+RIUOjqrBqabb O1vFdcV11yxx4QyWBc26oKBfjxxSlwgZLUIXo5mAEvb+215hyNKqKdKgEowjEJ+3 Ww/vdXc58JSUC2STPnOhObekBZiTDmpQltIFjkLIHMuv6Nm7ok02mVoc7Vi1zoJy 3VLa9Q68msYvllQfWbEXgphYrVmkg== X-ME-Sender: X-ME-Proxy: Received: from rtp-vpn4-1969.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id EB7D6E4A43; Sat, 27 Oct 2018 04:30:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Sat, 27 Oct 2018 10:30:06 +0200 Cc: IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A4A4C5E-FA43-4B11-BA83-CCF2811E6A55@cooperw.in> References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 08:30:14 -0000 Hi Deborah, > On Oct 25, 2018, at 6:06 PM, BRUNGARD, DEBORAH A = wrote: >=20 > Hi Alissa, >=20 > Much thanks for your careful review. I wanted to address one item, = I'll let the authors respond on the others. >=20 > While I understand your comment is non-blocking on the document, I = wanted to understand your comment that you are abstaining to be = "consistent" with the IESG statement on support documents. The IESG = statement (to me) was not blocking the publication of support documents. Perhaps this was not clear from the ballot, but I didn=E2=80=99t abstain = because I thought it was what the IESG statement requires. What I said = was that my ballot position is consistent with the statement. = Specifically, it is consistent with this text: "While writing down such things as requirements and use cases help to = get a common understanding (and often common language) between = participants in the working group, support documentation doesn=E2=80=99t = always have a high archival value. Under most circumstances, the IESG = encourages the community to consider alternate mechanisms for publishing = this content, such as on a working group wiki, in an informational = appendix of a solution document, or simply as an expired draft.=E2=80=9D =46rom what I could gather this document was very valuable to the WG, = but the incremental value of getting IETF consensus, running it through = the publication process, and archiving it as an RFC wasn=E2=80=99t = obvious. An internet draft seemed just as good, especially given those = couple of references to =E2=80=9Ccurrent WG discussion=E2=80=9D and = =E2=80=9Ccurrent WG consensus." > To me, it was addressing the concern on support documents holding up = the commencement of solution work. >=20 > Here's why I supported this document for publication: >=20 > - Based on the working group and Chairs agreement to publish. The = charter does not prevent publication. Yep, the point of the abstain ballot is explicitly not to prevent = publication. > This charter text was carefully considered when the group was = chartered as it was felt by the IESG at that time that it was not for = the IESG to prevent publication of a support document. > - The document shepherd writeup says "This document provides context = for the DetNet WG and has guided the development of other WG documents." = Not sure on your comment justifying not-to-publish as the document is = not normatively referenced, the document is informatively referenced = (typical as it is an informational document) by other documents. An internet-draft can be referenced this way. > - Per the IESG statement, this document has not prevented the = commencement of solution work. Conversely, it has greatly helped to = scope the solution work. > - Most important for this document are the non-procedural aspects = supporting publication. As this work is closely aligned with IEEE's TSN = work, having an RFC shows the consensus of the working group. Having an RFC shows the consensus of the IETF, not the WG. > For other SDOs, a wiki does not have "consensus". As the author list = indicates, the document had input from a diverse set of the community. = As Spencer says, it provides context for operators and vendors not = participating in IETF. And as the Genart reviewer says "really cool = document to read". For many operators/users, informational documents are = a means to participate without showing preference for one solution or = another. >=20 > Perhaps, I or the document shepherd should have included this = justification in our writeups so as to have gained your support for = publishing the document. We can talk more among the IESG on this so as = not to confuse the community on what the IESG statement says when = considering future requests for publishing informational documents. I don=E2=80=99t think the statement is confusing, but I suspect the IESG = would be happy to entertain clarifications to it if you have = suggestions. Thanks, Alissa >=20 > Thanks again everyone for your careful reviews! > Deborah >=20 >=20 > -----Original Message----- > From: iesg On Behalf Of Alissa Cooper > Sent: Thursday, October 25, 2018 5:36 AM > To: The IESG > Cc: detnet-chairs@ietf.org; detnet@ietf.org; lberger@labn.net; = draft-ietf-detnet-use-cases@ietf.org > Subject: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: = (with COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-detnet-use-cases-19: Abstain >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_iesg_s= tatement_discuss-2Dcriteria.html&d=3DDwICaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D= -ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3DKk4Tim7T1xoM_57ir44IuIiwjd= LJfYagnDbl49ar0Uk&s=3DaGn8gh-OaaaNpVH4q-AwBc69kz1YuKm6pkljH-KsoO8&e=3D > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dietf-2Ddetnet-2Duse-2Dcases_&d=3DDwICaQ&c=3DLFYZ-o9_HUMeMTSQ= icvjIg&r=3D-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3DKk4Tim7T1xoM_57= ir44IuIiwjdLJfYagnDbl49ar0Uk&s=3DXB07PuCt9z-okatqF0o7VTGRXtTaIcbj6NTiPhfaa= rw&e=3D >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This document has useful content but I'm not convinced of its archival = value. > Consistent with the IESG statement on supporting documents = , > I am abstaining. Notably, the detnet charter states: >=20 > "WG sustaining/informational documents may include: >=20 > These documents may not necessarily be published, but may be = maintained in a draft form or on a collaborative Working Group wiki to = support the efforts of the Working Group and help new comers: >=20 > Problem statement and (constrained) deployment environments = User-driven use cases" >=20 > So I would not have expected this document to be published as an RFC. = I also could not find any other WG documents referencing this = normatively. >=20 > There are a few places in the document that are particularly = problematic for an archival document: >=20 > 4.2.1 >=20 > "There are many field protocols used today; some are standards-based > and others are proprietary (see standards [lontalk], [modbus], > [profibus] and [flnet])." >=20 > I would suggest s/today/at the time of this writing/ >=20 > 5.1.2 >=20 > "Note: Current WG discussion indicates that some peer-to-peer > communication must be assumed, i.e. the PCE may communicate only > indirectly with any given device, enabling hierarchical = configuration > of the system." >=20 > This seems like it could be rendered out of date. I would suggest = deleting "Current WG discussion indicates that." >=20 > 12.4 >=20 > "Current WG consensus is that this item won't be > directly supported by the DetNet architecture, for example because = it > implies guarantee of in-order delivery of packets which conflicts > with the core goal of achieving the lowest possible latency." >=20 > Same comment as above. I would suggest deleting "Current WG consensus = is that." >=20 >=20 From nobody Sat Oct 27 01:31:55 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC66712F18C; Sat, 27 Oct 2018 01:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg-43DKdd8Px; Sat, 27 Oct 2018 01:31:44 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 8BBA012D4E6; Sat, 27 Oct 2018 01:31:44 -0700 (PDT) Received: from 200116b82c1b8e005ca560212220e8ce.dip.versatel-1u1.de ([2001:16b8:2c1b:8e00:5ca5:6021:2220:e8ce]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gGK0T-00056r-1W; Sat, 27 Oct 2018 10:31:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1df130ab-fddc-5f3f-7011-45cb1d163453@gmail.com> Date: Sat, 27 Oct 2018 10:31:39 +0200 Cc: The IESG , detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, draft-ietf-detnet-use-cases@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <13CEC4A1-F2AB-499E-9F55-A479679D7472@kuehlewind.net> References: <154047604123.16342.17879381711877381417.idtracker@ietfa.amsl.com> <1df130ab-fddc-5f3f-7011-45cb1d163453@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1540629104;4f895729; X-HE-SMSGID: 1gGK0T-00056r-1W Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-iet?= =?utf-8?q?f-detnet-use-cases-19=3A_=28with_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 08:31:47 -0000 Hi Stewart, Adrian pinged me about this as well and I also told me that I wasn=E2=80=99= t myself sure about what to pick. I didn=E2=80=99t feel "no objection" was appropriate because I read = briefly through the document but not enough to reach to a =E2=80=9Eno = objection=E2=80=9C conclusion as I do noticed some potentially concerns = as my second sentence in the comment says. I agree that =E2=80=9Eabstain=E2=80=9C is probably also not fully = appropriate because it should be rather used when you have actual = concerns but don=E2=80=99t want to block publication. I was more like I = might eventually have seem concerns but in any case don=E2=80=99t want = to block publication (given this is an information use case doc). I guess I could have left my ballot at =E2=80=9Eno record=E2=80=9C and = put a comment in anyway. Not sure that=E2=80=99s much better. As I just = said, my main point really is not matter what I don=E2=80=99t want to = block publication.=20 Mirja > Am 26.10.2018 um 19:48 schrieb Stewart Bryant = : >=20 >=20 >=20 > On 25/10/2018 15:00, Mirja K=C3=BChlewind wrote: >> I unfortunately did not have the time to read this doc in detail = which is the >> main reason for my abstain. >=20 > Mirja >=20 > I would have thought that no-objection would have better reflected = that situation. >=20 > No-objection says that you trust others in the IESG to make a decision = on matters that you do not understand or do not have time to evaluate. = That is consistent with a situation when an AD has not read the text. >=20 > Abstain send the message that the AD would prefer that a document not = be published, but not strongly enough to issue a Discuss. Given the = statement that you did not read the text in detail, I cannot see how it = is reasonable to arrive at that position. >=20 > Best regards >=20 > Stewart >=20 >=20 From nobody Sat Oct 27 01:35:02 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05212F18C; Sat, 27 Oct 2018 01:35: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgEQLHeyWhKN; Sat, 27 Oct 2018 01:35:00 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 E567212D4E6; Sat, 27 Oct 2018 01:34:59 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id y144-v6so3397601wmd.4; Sat, 27 Oct 2018 01:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Dtv8b2d/DkL+wbYi0L3XMCLHYdIQzC9BjfTzXJjLW9U=; b=UM2T9NDRhdp7SXc4ePvGSCFOBZ9JHrQgQfQ0Mb9amYZKoIjdk9eAYry+lRY1N0WCPv Qlrb5iYeYxL9HJLehkAGAMpM10mpfgZYDGXQdV8bu1ng3OVfkC5nxXU5dadKi+yk7OEE Z4f7wMBrFJjLWaUJtR21SjwwgIwl9ZllA0UC96+TGrnGDSIQYn1BzZ0xeifAgvRFWrcJ Z5uZg+GU1XLpJwPajMNdGc4CTCghaHWlqeUHsmiBOwvxPuWlSIX8Jt6XBSmjqlS00xWG uFdooFbYzIZEu7iBAQEhsw41nGRIozenQ1lymli8AJrTacbGHqMqk9WOgNz5BTany/er sYTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Dtv8b2d/DkL+wbYi0L3XMCLHYdIQzC9BjfTzXJjLW9U=; b=eoGfVK4iJSV7KqkbVa/aZN+3ZILyFYSWGs0xMM3sitqBcFtMCEJOfcDOuXX0wv9poT rYDG6S8wsXA49d26YpAqxzsoYJEBPpvuk/7O2IZAXfjkaF/kOx0HrpEvO+S3CAfEo/58 1akm0jUnH6cc7u4YyQZifCSKiXNaI2UJ8w3takSLwmgDRw1pwYjvlpplCtmpCGrn5MB8 0kx6Q2a1Zv8xvfnv9kAwqBMqSNjK4a8PGfrsGqC9vbe3CWzlv8wJm/Bl9E+BIF0nFDCC KweNh1kgx6OG0P1ezDJOrPajTrYCs9i1K9cUMVT3jL61kBOXhTMzMquSNFUCzVpk4ZRu 0iog== X-Gm-Message-State: AGRZ1gKNW06XCD+nhm5l1B7TMn+10jjz983rbi5TIm7ljev4E+VM8QV8 LQWPfFX8tA9LzR0YFjYyqrfkdnGm X-Google-Smtp-Source: AJdET5dJmQMTtH07YEfBcUthajzkeAlacI1MWtNrVyXxUk4dA6JMOG0mnIUFvgDoM0ZN2MrEpNpeAw== X-Received: by 2002:a1c:f518:: with SMTP id t24-v6mr7611401wmh.82.1540629297951; Sat, 27 Oct 2018 01:34:57 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i7-v6sm9698067wmd.41.2018.10.27.01.34.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Oct 2018 01:34:57 -0700 (PDT) To: Alissa Cooper , "BRUNGARD, DEBORAH A" Cc: "draft-ietf-detnet-use-cases@ietf.org" , "detnet@ietf.org" , IESG , "lberger@labn.net" , "detnet-chairs@ietf.org" References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <8A4A4C5E-FA43-4B11-BA83-CCF2811E6A55@cooperw.in> From: Stewart Bryant Message-ID: Date: Sat, 27 Oct 2018 09:34:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8A4A4C5E-FA43-4B11-BA83-CCF2811E6A55@cooperw.in> Content-Type: multipart/alternative; boundary="------------1CF402930E25CB8B6AEEAF2C" Content-Language: en-GB Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 08:35:01 -0000 This is a multi-part message in MIME format. --------------1CF402930E25CB8B6AEEAF2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 27/10/2018 09:30, Alissa Cooper wrote: >> This charter text was carefully considered when the group was chartered as it was felt by the IESG at that time that it was not for the IESG to prevent publication of a support document. >> - The document shepherd writeup says "This document provides context for the DetNet WG and has guided the development of other WG documents." Not sure on your comment justifying not-to-publish as the document is not normatively referenced, the document is informatively referenced (typical as it is an informational document) by other documents. > An internet-draft can be referenced this way. > Not is some SDOs. As I recall the ITU, for example,  will reference RFCs but not IDs. - Stewart --------------1CF402930E25CB8B6AEEAF2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 27/10/2018 09:30, Alissa Cooper wrote:
    This charter text was carefully considered when the group was chartered as it was felt by the IESG at that time that it was not for the IESG to prevent publication of a support document.
- The document shepherd writeup says "This document provides context for the DetNet WG and has guided the development of other WG documents." Not sure on your comment justifying not-to-publish as the document is not normatively referenced, the document is informatively referenced (typical as it is an informational document) by other documents.

    An internet-draft can be referenced this way.

    Not is some SDOs.

    As I recall the ITU, for example,  will reference RFCs but not IDs.

    - Stewart
    --------------1CF402930E25CB8B6AEEAF2C-- From nobody Sat Oct 27 01:53:04 2018 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0712F18C; Sat, 27 Oct 2018 01:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebnslBD2KNDX; Sat, 27 Oct 2018 01:52:55 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6D312D4E6; Sat, 27 Oct 2018 01:52:55 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id o14-v6so3320426ljj.2; Sat, 27 Oct 2018 01:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xia16ieV3idj/eUMPlJ/mzIaKtWATR+lqQ8L2GIflew=; b=sQM+DQsC/w+/DfihIJiybGA63vWbfWxOHvmfwCgGEATCnrHmDOIF7nYLWbA8DjhlHq YDpLH/H0XST7ZDUKOBs9Cqhngy4Fnh9nuA3bPyS6DrR4R6m8MWK5afSK7bsQYDUX0Uum gQGJf6RM2mfzRG2KGXCBA+33p8+oeWbgGIPzuK72EfeBV2EltOm1+FkCWP27qy9qbPXj Z5vwNI9HwPbTAmc9Q2Vp/KcSFIthXaaa44l4FZIIi8iM7Bhi3mmxq8qPbdw/+5gB3sff bmC8tMjP/2d7WjGxbIG9j36oSgN0AY7deqDCREtWkzR/UjF9zs95HWdf216z5OsQeQbC oBvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xia16ieV3idj/eUMPlJ/mzIaKtWATR+lqQ8L2GIflew=; b=Ee7NRsd8XTxH91JdRiVZj40jeTFxcBhL5S2bpmt7FHHroluqfxq1amz/uf3Bnmn0X0 h4vgQ0ArmMDfmOtBX6pKflgKJjXrqYh2fkPcwT/EM6iIDVSYZQ16RroI0b3g83glYIh1 e+HHLZUseatLEaS2o/84v7iTrrX4ZMNJx6fkeH3zbaTxGrx29nBQmDx7CD5g22jmlqsj VEUHUfQ7KDAu3lKkvm2gIqe5NdHE5TH4oqwQTKRZB6nAnveIp89qjz4+cxM7MVr+LaTw mMmoz3thVHHCFPfv1c+Ll3s5Ugf6iZC+yqPE3w3YAps15VMoTO8oH+xRiBgfqw+Ngkqm No0g== X-Gm-Message-State: AGRZ1gLI/ZL78PI8IVCqqJ14Q1pkXAwkiyTSyeH2RSbw9oX2nu7DtQb3 NKDoJ+pcRoBZOlzsryXH3GobCnB17fq7jDW1lF4= X-Google-Smtp-Source: AJdET5dQ2JoIdCJF9nnc3jBq6GDr5zEq9bQL2nLX7PgiWkZ/MBkIFw+9Z/2KjWYluQqUEMjIemECI+B1D4cQ0gT9pOs= X-Received: by 2002:a2e:320c:: with SMTP id y12-v6mr985220ljy.163.1540630373585; Sat, 27 Oct 2018 01:52:53 -0700 (PDT) MIME-Version: 1.0 References: <154046016999.16330.646297723728540542.idtracker@ietfa.amsl.com> <5b05a230-95d1-0979-05a4-69d53b759b9a@gmail.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Sat, 27 Oct 2018 03:52:39 -0500 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: Stewart Bryant , Alissa Cooper , The IESG , "detnet-chairs@ietf.org" , "detnet@ietf.org" , "lberger@labn.net" , "draft-ietf-detnet-use-cases@ietf.org" Content-Type: multipart/alternative; boundary="00000000000025d65f057931f631" Archived-At: Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 08:52:58 -0000 --00000000000025d65f057931f631 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Deborah, On Fri, Oct 26, 2018, 12:47 BRUNGARD, DEBORAH A wrote: > Hi Stewart, > > > > I agree =E2=80=93 I sent an earlier reply (on the list) to Alissa explain= ing why > we went for publication. As this is a document which will be looked at by > IEEE and others, it is of value to have it published vs. a wiki. And > publication indicates consensus of the group. > > > > I will be following up with the IESG on both the interpretation of the > IESG statement for publishing informationals and use of Abstains so we ca= n > be consistent for the community. > Are you thinking following up in Bangkok? My understanding matches yours - the problem we were solving was when we chartered a theoretically 18-24 month working group to specify something developers could implement, and the working group spent 17-23 months on use cases, problem statements, requirements docs, and architectures, and developers had nothing. We also had publication requests for these drafts that had been useful at the beginning of solutions work, but hadn't been maintained since that started, so weren't consistent with the standards-track documents they had supported, being published at the same time. That was why I thought the IESG came up with the statement on working group support documents - not to ban classes of (informational) documents, but to get to standards-track documents faster. We can talk about what the right thing to do is, but I don't think the IESG has a common understanding about that today. Each IESG is special, and this IESG can certainly change the way the current IESG works (within our BCP framework), but it's likely that this is a change we should confirm with the community, after we ourselves figure out this IESG thinks. Spencer > --00000000000025d65f057931f631 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    =
    My understanding matches yours - the problem we were solv= ing was when we chartered a theoretically 18-24 month working group to spec= ify something developers could implement, and the working group spent 17-23= months on use cases, problem statements, requirements docs, and architectu= res, and developers had nothing.=C2=A0

    We also had publication requests for these drafts that had b= een useful at the beginning of solutions work, but hadn't been maintain= ed since that started, so weren't consistent with the standards-track d= ocuments they had supported, being published at the same time.