From nobody Wed Jan 2 07:28:28 2019 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 D07C8128B01; Wed, 2 Jan 2019 07:28:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lberger@labn.net, detnet@ietf.org, db3546@att.com, detnet-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2019 07:28:25 -0800 Archived-At: Subject: [Detnet] detnet - New Meeting Session Request for IETF 104 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, 02 Jan 2019 15:28:26 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the detnet working group. --------------------------------------------------------- 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 netmod mpls Second Priority: rtgwg pals bess lsr tsvwg ccamp Third Priority: nvo3 People who must be present: Lou Berger David L. Black Deborah Brungard Janos Farkas Ethan Grossman Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 2 07:59:24 2019 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 D27F0130E31; Wed, 2 Jan 2019 07:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3hCtWm0yF7ab; Wed, 2 Jan 2019 07:59:20 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 A6CF8130E30; Wed, 2 Jan 2019 07:59:20 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id l11so33925178qtp.0; Wed, 02 Jan 2019 07:59:20 -0800 (PST) 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=RhUhISjaue5xpGGWZUmIaBtEopSzEfjXNKQMjXjpjm0=; b=CJL3z+ZmS8wacQ10Ez9+Zm61RN2qc3BR8OSW2EBQcZQ0rIKznBBign4WAfRAdv6tCp eBtpnRBhwLcicwyN+ibcaGCnc6N6OFULdEz+wZGqOnYZoKnVq48o4l4Ee8884/+gRvuq /br4XjrOTpi5NX6XbrGFZkUNS6k9+9WgZj/x8YrenjEUzx7W31NaPFPjpyrZem0esYh9 lvHAu9CrLLCexnJjAF+2vrEj7GP1LpK604fDHGmXrtSpLzZT98BbC4FYa2GchuvSWbRd jhFbtEg0e81pF83oyP+INJRA+wHuz7/nimBEZF/DpXV5BTx9ubMhQuO+zuFK5yu7tXKJ wliQ== 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=RhUhISjaue5xpGGWZUmIaBtEopSzEfjXNKQMjXjpjm0=; b=gx4Gv3idgmWx7CWDm2/bk13lh25r1nPpNdICuO7XXm48GoUxit6C0mswHzCpAEToGw F3vEHjAjrkDtX3xcVEQSgdVu/ivqlL3y9Hmozj5RidgmbKG4JQ8sstFIfQ3hotv1ASdx Od8Tig91amDkO4xrgm9AHZaD43IUPAVfBZGsYRVO/K4mYi96dvYIiR0ZRooq9w8biUs9 G/X1qy426XJiBCYN4+29AVdfJLNo3SsvkVordWb0S0ZmahzhA50Y/vO5kzqbAdrRHm1Z mnopjuixaEzD4s2zTe/H/fuP54MG3sxumxY4tD6ONV/WVp2iBhlq6NgpYvX1KcJ1Dg0B Y3IA== X-Gm-Message-State: AJcUukfdCej0VeOK1Kh/Ohx78lr+VfcekyD9LWxw8Frs/uyFE+ggb6gB xNzMzR1FCx7JPBd0801PzEuvUuIjBZDu/PBVFn8= X-Google-Smtp-Source: ALg8bN5SRY4R6Qj+Fe3MD9FwOCADFH+vdqolczici+RCxP+Wqo1o6rkDyuKIEytzHbXiNvZvTM0CFrujBBvrqjNdobA= X-Received: by 2002:a0c:c389:: with SMTP id o9mr43532683qvi.90.1546444759768; Wed, 02 Jan 2019 07:59:19 -0800 (PST) MIME-Version: 1.0 References: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> In-Reply-To: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Wed, 2 Jan 2019 10:59:09 -0500 Message-ID: To: Lou Berger Cc: detnet WG , "BRUNGARD, DEBORAH A (ATTLABS)" , DetNet Chairs Content-Type: multipart/alternative; boundary="000000000000922360057e7bba9c" Archived-At: Subject: Re: [Detnet] detnet - New Meeting Session Request for IETF 104 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, 02 Jan 2019 15:59:23 -0000 --000000000000922360057e7bba9c Content-Type: text/plain; charset="UTF-8" Lou, Could you add sfc as a second priority conflict? Last time several of us were inconvenienced by DetNet and SFC meeting at the same time. Thanks, Andy On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > A new meeting session request has just been submitted by Lou Berger, a > Chair of the detnet working group. > > > --------------------------------------------------------- > 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 netmod mpls > Second Priority: rtgwg pals bess lsr tsvwg ccamp > Third Priority: nvo3 > > > People who must be present: > Lou Berger > David L. Black > Deborah Brungard > Janos Farkas > Ethan Grossman > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --000000000000922360057e7bba9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou,

Could you add sfc as a second prio= rity conflict? Last time several of us were inconvenienced by DetNet and SF= C meeting at the same time.

Thanks,
Andy=



On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request= Tool <session-request@ietf.= org> wrote:


A new meeting session request has just been submitted by Lou Berger, a Chai= r of the detnet working group.


---------------------------------------------------------
Working Group Name: Deterministic Networking
Area Name: Routing Area
Session Requester: Lou Berger

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 100
Conflicts to Avoid:
=C2=A0First Priority: pce teas netmod mpls
=C2=A0Second Priority: rtgwg pals bess lsr tsvwg ccamp
=C2=A0Third Priority: nvo3


People who must be present:
=C2=A0 Lou Berger
=C2=A0 David L. Black
=C2=A0 Deborah Brungard
=C2=A0 Janos Farkas
=C2=A0 Ethan Grossman

Resources Requested:

Special Requests:

---------------------------------------------------------

_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
--000000000000922360057e7bba9c-- From nobody Wed Jan 2 08:14:13 2019 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 678D5130E2B; Wed, 2 Jan 2019 08:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0jDrbs1LnviF; Wed, 2 Jan 2019 08:14:10 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 099A7130E34; Wed, 2 Jan 2019 08:14:10 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id u18so21287803lff.10; Wed, 02 Jan 2019 08:14:09 -0800 (PST) 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=mxDT0sN70nfR89A74RjhmeoDBO1ifSt2LuWCJrfrPUQ=; b=T8gIfWsyqLEd7iNyLgNWyMLnIJhUp+sDwjBKq58bEc9G2U9eHQqaQg+QlqcmDvOzn6 HEAi6ISNA/+bPEgHbEPwajV4GsPcy9WtTK97JOIAZIldZpQ7VKTLsTyiY7zXTnHidBX3 OK2OfwGDgV+V0DU59QyRVzSsmFvl8A3uowcYFV5zGLHbnaYJLshQ2DY0ihuug5KqCM7y aXYywX7vNVAZ0u9pIvoDrtg5VqnsuVnCwAKuKzO4bg/+H6qTPJZYA/3d/KxQKR6FhBEs LwVFyFXTFErexhybt54UJ2FVjHjB/NxmKjPCXAFfxX3f+RqBrEYINdmHa9fh7w1YKTUH RlAw== 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=mxDT0sN70nfR89A74RjhmeoDBO1ifSt2LuWCJrfrPUQ=; b=hrWM8GhPx20l5wLQguBhXsg7MTeUd6a7W6/ZAoVWr0OnCBI8gkaKAJG1GgP6ARXmH/ 3PBCEt296kpfY9+zS3+HUZ1VBLXJEBnr4KpL2R0LRPMR939ZN9zhQJ/nSozqm45u/K0K O4qtClAJUXfx+Mhlw/199dO3kSLN9ErWFOn6W2OqzycvzG4HLEbqAVGQ6mt9LfaEpWDt HWjw91b95Ti9WdxTGLBY3g2DQDKe8k+2BqYP3lzXSXiuTkcQl/RbWI9IagJyLtd9Cf5z ApQ6ObTL/j2nujmBpjrzf0o6CCynhK8l9YNM+J2105vfzNoM1IylIpKAZAXufmk6XJs6 iIBA== X-Gm-Message-State: AA+aEWbaznMLW383VQYOSrZDvvYaGlvDxOQTrFSRoXEZtn9sZvWYhjbO GCR4IrsgOisVQmOZrmr1qWK03G0uyzwQwiFHPOs8eUlW X-Google-Smtp-Source: AFSGD/XZFxnXnzl0wNwAQHusRAn5J9L/PijWdpRnYVQhGdxIYxBVwZJsA5CkwevMmORp0HRnDn0zQQ+/uZiGBHQHENc= X-Received: by 2002:a19:7919:: with SMTP id u25mr20947145lfc.18.1546445648131; Wed, 02 Jan 2019 08:14:08 -0800 (PST) MIME-Version: 1.0 References: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Wed, 2 Jan 2019 11:14:01 -0500 Message-ID: To: "Andrew G. Malis" Cc: Lou Berger , detnet WG , "BRUNGARD, DEBORAH A (ATTLABS)" , DetNet Chairs Content-Type: multipart/alternative; boundary="000000000000857da7057e7befc3" Archived-At: Subject: Re: [Detnet] detnet - New Meeting Session Request for IETF 104 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, 02 Jan 2019 16:14:12 -0000 --000000000000857da7057e7befc3 Content-Type: text/plain; charset="UTF-8" +100! Happy New Year to All! On Wed, Jan 2, 2019 at 10:59 AM Andrew G. Malis wrote: > Lou, > > Could you add sfc as a second priority conflict? Last time several of us > were inconvenienced by DetNet and SFC meeting at the same time. > > Thanks, > Andy > > > > On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request Tool < > session-request@ietf.org> wrote: > >> >> >> A new meeting session request has just been submitted by Lou Berger, a >> Chair of the detnet working group. >> >> >> --------------------------------------------------------- >> 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 netmod mpls >> Second Priority: rtgwg pals bess lsr tsvwg ccamp >> Third Priority: nvo3 >> >> >> People who must be present: >> Lou Berger >> David L. Black >> Deborah Brungard >> Janos Farkas >> Ethan Grossman >> >> Resources Requested: >> >> Special Requests: >> >> --------------------------------------------------------- >> >> _______________________________________________ >> 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 > --000000000000857da7057e7befc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+100!

Happy New Year to All!

On Wed, Jan 2, 2019 at 10:= 59 AM Andrew G. Malis <agmalis@gmai= l.com> wrote:
Lou,

Could you add sfc as a second= priority conflict? Last time several of us were inconvenienced by DetNet a= nd SFC meeting at the same time.

Thanks,
Andy



On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Re= quest Tool <session-request@ietf.org> wrote:


A new meeting session request has just been submitted by Lou Berger, a Chai= r of the detnet working group.


---------------------------------------------------------
Working Group Name: Deterministic Networking
Area Name: Routing Area
Session Requester: Lou Berger

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 100
Conflicts to Avoid:
=C2=A0First Priority: pce teas netmod mpls
=C2=A0Second Priority: rtgwg pals bess lsr tsvwg ccamp
=C2=A0Third Priority: nvo3


People who must be present:
=C2=A0 Lou Berger
=C2=A0 David L. Black
=C2=A0 Deborah Brungard
=C2=A0 Janos Farkas
=C2=A0 Ethan Grossman

Resources Requested:

Special Requests:

---------------------------------------------------------

_______________________________________________
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
--000000000000857da7057e7befc3-- From nobody Wed Jan 2 08:16:39 2019 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 5E81A130E43; Wed, 2 Jan 2019 08:16:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lberger@labn.net, detnet@ietf.org, db3546@att.com, detnet-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154644579834.32563.9638760929864749562.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2019 08:16:38 -0800 Archived-At: Subject: [Detnet] detnet - Update to a Meeting Session Request for IETF 104 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, 02 Jan 2019 16:16:39 -0000 An update to a meeting session request has just been submitted by Lou Berger, a Chair of the detnet working group. --------------------------------------------------------- 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 netmod mpls Second Priority: rtgwg pals bess lsr tsvwg ccamp sfc Third Priority: nvo3 People who must be present: Lou Berger David L. Black Deborah Brungard Janos Farkas Ethan Grossman Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 2 08:17:36 2019 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 4F6E5130E5E for ; Wed, 2 Jan 2019 08:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-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 UhMneaVKSbJy for ; Wed, 2 Jan 2019 08:17:32 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 5475B130E5B for ; Wed, 2 Jan 2019 08:17:32 -0800 (PST) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id F19B1215C10 for ; Wed, 2 Jan 2019 09:17:31 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id ejD1gimPT4pE3ejD1gVSex; Wed, 02 Jan 2019 09:17:31 -0700 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:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=nVTwdhoHm2yIq9UXJ2dXnijC48QyNigNGHxO6PKC8us=; b=v56NtsgY5PamHa3wUFifuQj4un VGANvu+4fbc1Zfx4h0TWULutQcxyfQwxp72n88ZNKEn3KtFmdrhoniZN04EUTFvwef3FMt4MB+g3N fWM7LWWT4gTgumo9b79FPILG+; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:33534 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gejD1-003182-JY; Wed, 02 Jan 2019 09:17:31 -0700 To: "Andrew G. Malis" Cc: detnet WG , "BRUNGARD, DEBORAH A (ATTLABS)" , DetNet Chairs References: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> From: Lou Berger Openpgp: preference=signencrypt Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU= Message-ID: <956c6e78-7d12-4b31-72e5-818dcb614d29@labn.net> Date: Wed, 2 Jan 2019 11:17:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gejD1-003182-JY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:33534 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] detnet - New Meeting Session Request for IETF 104 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, 02 Jan 2019 16:17:34 -0000 done! On 1/2/19 10:59 AM, Andrew G. Malis wrote: > Lou, > > Could you add sfc as a second priority conflict? Last time several of us > were inconvenienced by DetNet and SFC meeting at the same time. > > Thanks, > Andy > > > > On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request Tool > > wrote: > > > > A new meeting session request has just been submitted by Lou Berger, > a Chair of the detnet working group. > > > --------------------------------------------------------- > 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 netmod mpls >  Second Priority: rtgwg pals bess lsr tsvwg ccamp >  Third Priority: nvo3 > > > People who must be present: >   Lou Berger >   David L. Black >   Deborah Brungard >   Janos Farkas >   Ethan Grossman > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Wed Jan 2 10:16:05 2019 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 3EFB2130F29; Wed, 2 Jan 2019 10:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EzaATeBKh4u1; Wed, 2 Jan 2019 10:15:51 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 BD65B130F04; Wed, 2 Jan 2019 10:15:51 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id i7so34350208qtj.10; Wed, 02 Jan 2019 10:15:51 -0800 (PST) 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=pGpSmsQjPdRDygESYlHBHdcuviFSklpqRWx3cPoUExo=; b=iqYBP2+rmweUnMERhdorEd8IVUtFPgnAYHDGFdJBWLhI4DL8LuH3cDlsugyr2aSn1Y eF8nqrT/V4taaEHxIwqPqdiClUVx4hJ9AHw7VvQ9nSx6ZvZsp6pKND8TNUSRiup3cQgG 4XBdlwz+Yne3cSaLm3eJ6riDHEkC678G+1qzDjXkQZvZs6DXH5NoHCi9Td3JFlESsuzD 8Uo+YrRF1QmsxptBoxXmQPeAjIDylw6czf6Z+aLCOcJN7ddfIiEgSAAhzvet5UgxmDBn Cn/9xpMGDnfHMsTaF7mONfhCC5UhIgkkwz1cndaHhaXhKdkI0a6h/QjfC0hCmedMwyK5 VV9w== 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=pGpSmsQjPdRDygESYlHBHdcuviFSklpqRWx3cPoUExo=; b=XcUY6JX7JfLgtvQnk+7xi5bgQ2svnJ9FjyBmVtxFel7rGVFnbb1HSDt5c8ftFnNZiY IBEvbBj4k4ZE3Yy2rCbOCzICPlFeq00IbXEfMOqIT6VN66r4ULTERuOPGKyyokC5drc+ SZ7rUU9aWqAVTVe0BnFPpYsfg4dD3Ho6J9cnlktHyBKSn0PuMHfjAUmzfPahDYgFMnDt U09hLfsZHkbO+OFDeSn/m1Ofvg7YbWkh8j9Oxt5iobus1E0+kr6WRyFs22pexeq0RLO6 TsZnivcENc0AQgYuhDwE7zp2oEehli8F4g/Lo81x/e+R/RnXWsafuNL8sln4M8+eAv48 qm3Q== X-Gm-Message-State: AA+aEWb20rauJKau6/9dKcS4Q2qe0DzYNNlw/2Lb8U1sPUR4X8YIg1Qe El2u61YEKEw7YtwrWoGonZsYdm7ZjSMjD9dG3Yk= X-Google-Smtp-Source: AFSGD/VXCxgbftFqkjsI2xocxxzgdSO5m1cJPW60Vi5CIJu15ETE83CZNUSPYyd1fIlo+/3v/TFo41w0wfYL74shqic= X-Received: by 2002:ac8:2eb8:: with SMTP id h53mr42755141qta.18.1546452950798; Wed, 02 Jan 2019 10:15:50 -0800 (PST) MIME-Version: 1.0 References: <154644290584.32466.7088239013928359511.idtracker@ietfa.amsl.com> <956c6e78-7d12-4b31-72e5-818dcb614d29@labn.net> In-Reply-To: <956c6e78-7d12-4b31-72e5-818dcb614d29@labn.net> From: "Andrew G. Malis" Date: Wed, 2 Jan 2019 13:15:40 -0500 Message-ID: To: Lou Berger Cc: detnet WG , "BRUNGARD, DEBORAH A (ATTLABS)" , DetNet Chairs Content-Type: multipart/alternative; boundary="000000000000cb5746057e7da260" Archived-At: Subject: Re: [Detnet] detnet - New Meeting Session Request for IETF 104 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, 02 Jan 2019 18:16:02 -0000 --000000000000cb5746057e7da260 Content-Type: text/plain; charset="UTF-8" Lou, Thanks, much appreciated. Cheers, Andy On Wed, Jan 2, 2019 at 11:17 AM Lou Berger wrote: > done! > On 1/2/19 10:59 AM, Andrew G. Malis wrote: > > Lou, > > > > Could you add sfc as a second priority conflict? Last time several of us > > were inconvenienced by DetNet and SFC meeting at the same time. > > > > Thanks, > > Andy > > > > > > > > On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request Tool > > > wrote: > > > > > > > > A new meeting session request has just been submitted by Lou Berger, > > a Chair of the detnet working group. > > > > > > --------------------------------------------------------- > > 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 netmod mpls > > Second Priority: rtgwg pals bess lsr tsvwg ccamp > > Third Priority: nvo3 > > > > > > People who must be present: > > Lou Berger > > David L. Black > > Deborah Brungard > > Janos Farkas > > Ethan Grossman > > > > Resources Requested: > > > > Special Requests: > > > > --------------------------------------------------------- > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > > --000000000000cb5746057e7da260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou,

Thanks, much=C2=A0appreciated.

Cheers,
Andy


=
On Wed, Jan 2, 2019 at 11:17 AM= Lou Berger <lberger@labn.net>= ; wrote:
done! On 1/2/19 10:59 AM, Andrew G. Malis wrote:
> Lou,
>
> Could you add sfc as a second priority conflict? Last time several of = us
> were inconvenienced by DetNet and SFC meeting at the same time.
>
> Thanks,
> Andy
>
>
>
> On Wed, Jan 2, 2019 at 10:28 AM IETF Meeting Session Request Tool
> <sess= ion-request@ietf.org <mailto:session-request@ietf.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0A new meeting session request has just been submitt= ed by Lou Berger,
>=C2=A0 =C2=A0 =C2=A0a Chair of the detnet working group.
>
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= ------
>=C2=A0 =C2=A0 =C2=A0Working Group Name: Deterministic Networking
>=C2=A0 =C2=A0 =C2=A0Area Name: Routing Area
>=C2=A0 =C2=A0 =C2=A0Session Requester: Lou Berger
>
>=C2=A0 =C2=A0 =C2=A0Number of Sessions: 1
>=C2=A0 =C2=A0 =C2=A0Length of Session(s):=C2=A0 2 Hours
>=C2=A0 =C2=A0 =C2=A0Number of Attendees: 100
>=C2=A0 =C2=A0 =C2=A0Conflicts to Avoid:
>=C2=A0 =C2=A0 =C2=A0=C2=A0First Priority: pce teas netmod mpls
>=C2=A0 =C2=A0 =C2=A0=C2=A0Second Priority: rtgwg pals bess lsr tsvwg cc= amp
>=C2=A0 =C2=A0 =C2=A0=C2=A0Third Priority: nvo3
>
>
>=C2=A0 =C2=A0 =C2=A0People who must be present:
>=C2=A0 =C2=A0 =C2=A0=C2=A0 Lou Berger
>=C2=A0 =C2=A0 =C2=A0=C2=A0 David L. Black
>=C2=A0 =C2=A0 =C2=A0=C2=A0 Deborah Brungard
>=C2=A0 =C2=A0 =C2=A0=C2=A0 Janos Farkas
>=C2=A0 =C2=A0 =C2=A0=C2=A0 Ethan Grossman
>
>=C2=A0 =C2=A0 =C2=A0Resources Requested:
>
>=C2=A0 =C2=A0 =C2=A0Special Requests:
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= ------
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0detnet mailing list
>=C2=A0 =C2=A0 =C2=A0detnet@ietf.org <mailto:detnet@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/detnet
>

--000000000000cb5746057e7da260-- From nobody Sun Jan 6 22:19:59 2019 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 C6998130DCD for ; Sun, 6 Jan 2019 22:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RED=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 jkP6oetzLfJJ for ; Sun, 6 Jan 2019 22:19:56 -0800 (PST) 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 015B8130DC6 for ; Sun, 6 Jan 2019 22:19:56 -0800 (PST) Received: from lhrpml402-hub.exmail.huawei.com (unknown [172.18.7.66]) by Forcepoint Email with ESMTP id 1183B78B6D9AC4595CF3; Mon, 7 Jan 2019 06:19:53 +0000 (GMT) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.41]) by lhrpml402-hub.exmail.huawei.com ([10.201.4.206]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 06:19:50 +0000 From: Norman Finn To: "Andrew G. Malis" , Lou Berger CC: detnet WG , "Black, David" , =?iso-8859-1?Q?J=E1nos_Farkas?= Thread-Topic: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) Thread-Index: AQHUm8a22Hrj2HelzUCAo4Xy//CLeaWOVmYAgBUS/YA= Date: Mon, 7 Jan 2019 06:19:49 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F801720DDC@lhrpml504-mbx.exmail.huawei.com> References: , In-Reply-To: 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_3DF0466E9510274382F5B74499ACD6F801720DDClhrpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) 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, 07 Jan 2019 06:19:58 -0000 --_000_3DF0466E9510274382F5B74499ACD6F801720DDClhrpml504mbxexm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1. You may well need more than one DSCP for DetNet region for different cla= sses of service. 2. You don't want to discard unexpected packets with a DetNet DSCP -- you w= ant to remark them to a non-DSCP code point. Not good if configuring (or m= isconfiguring) a QoS feature destroys a bystander's connectivity. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmali= s@gmail.com] Sent: Monday, December 24, 2018 12:26 PM To: Lou Berger Cc: detnet WG; Black, David; J=E1nos Farkas Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Lou, Thanks for following up. Cheers, Andy On Mon, Dec 24, 2018 at 3:24 PM Lou Berger > wrote: Andy, Just following up on one point on DetNet-specific DSCPs: On 12/19/2018 1:11 PM, Andrew G. Malis wrote: > In that case, the DetNet flows would most probably be a using > DetNet-specific DSCP, and if the ingress interface isn't properly > provisioned to know how to process packets with that DSCP, they'll at > least be reduced to best-effort treatment.. We can also recommend that > packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such packets= . While I personally think use of DSCPs will be useful in supporting aggregated DetNet flows, the IP solution draft has no requirement that operators or vendors restrict DetNet flows to a specific DSCP value. -- I personally think this is an important design point. Happy Holidays! Lou --_000_3DF0466E9510274382F5B74499ACD6F801720DDClhrpml504mbxexm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1. You may well need more than one DSCP for DetNet region for differen= t classes of service.
2. You don't want to discard unexpected packets with a DetNet DSCP -- = you want to remark them to a non-DSCP code point.  Not good if configu= ring (or misconfiguring) a QoS feature destroys a bystander's connectivity.=

-- Norm

From: detnet [detnet-bounces@ietf.org] on = behalf of Andrew G. Malis [agmalis@gmail.com]
Sent: Monday, December 24, 2018 12:26 PM
To: Lou Berger
Cc: detnet WG; Black, David; J=E1nos Farkas
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

Lou,

Thanks for following up.

Cheers,
Andy


On Mon, Dec 24, 2018 at 3:24 PM Lou Berger <lber= ger@labn.net> wrote:
Andy,

Just following up on one point on DetNet-specific DSCPs:

On 12/19/2018 1:11 PM, Andrew G. Malis wrote:
> In that case, the DetNet flows would most probably be a using
> DetNet-specific DSCP, and if the ingress interface isn't properly
> provisioned to know how to process packets with that DSCP, they'll at =
> least be reduced to best-effort treatment.. We can also recommend that=
> packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such pack= ets.

While I personally think use of DSCPs will be useful in supporting
aggregated DetNet flows, the IP solution draft has no requirement that
operators or vendors restrict DetNet flows to a specific DSCP value.  = --
I personally think this is an important design point.

Happy Holidays!

Lou


--_000_3DF0466E9510274382F5B74499ACD6F801720DDClhrpml504mbxexm_-- From nobody Sun Jan 6 22:27:00 2019 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 9897F130DE3 for ; Sun, 6 Jan 2019 22:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 2LIy9JuW1RNh for ; Sun, 6 Jan 2019 22:26:57 -0800 (PST) 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 BBEF9130DCD for ; Sun, 6 Jan 2019 22:26:57 -0800 (PST) Received: from lhrpml402-hub.exmail.huawei.com (unknown [172.18.7.66]) by Forcepoint Email with ESMTP id DB9331E81E60C1543F2C; Mon, 7 Jan 2019 06:26:54 +0000 (GMT) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.41]) by lhrpml402-hub.exmail.huawei.com ([10.201.4.206]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 06:26:52 +0000 From: Norman Finn To: "Black, David" , =?iso-8859-1?Q?J=E1nos_Farkas?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7Ma4C0tH7nm20uUTxpPIscWq6WGU60AgB0ZkxA= Date: Mon, 7 Jan 2019 06:26:52 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com> References: , In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 06:27:00 -0000 I'm good with a SHOULD in the first paragraph of 3.3.2.=0A= =0A= -- Norm=0A= ________________________________________=0A= From: detnet [detnet-bounces@ietf.org] on behalf of Black, David [David.Bla= ck@dell.com]=0A= Sent: Wednesday, December 19, 2018 9:37 AM=0A= To: J=E1nos Farkas; DetNet WG=0A= Subject: Re: [Detnet] draft-ietf-detnet-architecture-10=0A= =0A= Janos,=0A= =0A= The terminology is definitely improved - the resulting draft is much=0A= clearer - many thanks to you and the authors for doing that.=0A= =0A= Where do we stand on the concern about protecting external=0A= non-DetNet networks from DetNet flows that escape a DetNet=0A= network, e.g., due to an erroneous network configuration change?=0A= =0A= My current views are ...=0A= =0A= There's no throttling in DetNet, e.g., this text in 4.3.2:=0A= =0A= There is no provision in DetNet for throttling DetNet flows, i.e.,=0A= the transmission rate cannot be reduced via explicit congestion=0A= notification [RFC3168]. The assumption is that a DetNet flow, to be=0A= useful, must be delivered in its entirety.=0A= =0A= and no assurance that all DetNet-using applications will cease and desist= =0A= in the face of packet drops that indicate congestion.=0A= =0A= Packet Replication and Elimination makes this worse via its ability to hide= =0A= network packet drops and congestion indications from endpoints, e.g.,=0A= of those drops and/or congestion indications occur on only one of=0A= the paths used by replicated packets.=0A= =0A= The first paragraph in section 3.3.2 is a good start, but I think its lower= =0A= case "should" is too weak:=0A= =0A= Robust real-time systems require to reduce the number of possible=0A= failures. Filters and policers should be used in a DetNet network to=0A= detect if DetNet packets are received on the wrong interface, or at=0A= the wrong time, or in too great a volume. Furthermore, filters and=0A= policers can take actions to discard the offending packets or flows,=0A= or trigger shutting down the offending flow or the offending=0A= interface.=0A= =0A= At a minimum, I think that the requirement to discard DetNet traffic=0A= that would otherwise escape a DetNet network has to be stated as=0A= a "MUST" requirement for any DetNet network that supports Packet=0A= Replication and Elimination due to the ability of that functionality=0A= to hide congestion from endpoints, making it impossible for higher=0A= layers of the protocol stack to respond.=0A= =0A= Beyond this, I think a "SHOULD" requirement to discard DetNet traffic=0A= that would otherwise escape is needed, and the statement of that=0A= requirement ought to be connected to the explanation of how to=0A= implement that requirement. The text in Section 3.3.2 has a lot of=0A= the content needed - for a worked example of such "SHOULD" text,=0A= see Section 5 of RFC 7510, in particular the itemized list at the end of=0A= that section and the paragraph that introduces that list:=0A= https://tools.ietf.org/html/rfc7510#section-5=0A= =0A= Thanks, --David=0A= =0A= > -----Original Message-----=0A= > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of J=E1nos Farkas= =0A= > Sent: Wednesday, December 19, 2018 10:54 AM=0A= > To: DetNet WG=0A= > Subject: [Detnet] draft-ietf-detnet-architecture-10=0A= >=0A= >=0A= > [EXTERNAL EMAIL]=0A= >=0A= > Hi,=0A= >=0A= > The DetNet architecture document has been updated to address the=0A= > comments. The new revision (v10) is available at=0A= > https://tools.ietf.org/html/draft-ietf-detnet-architecture-10.=0A= >=0A= > There have been a number of discussion items emails on the list. The=0A= > updates are along the major discussion items, which also cover the=0A= > derivative discussions, address the comments.=0A= >=0A= > The major items have been summarized in:=0A= > https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html.=0A= > Follow up discussions implied terminology changes summarized in:=0A= > https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html:=0A= > replace "transport sub-layer" with "forwarding sub-layer"=0A= > https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html:=0A= > replace "congestion protection" with "resource" allocation"=0A= > Consequently, the document had a good 'scurb".=0A= >=0A= > In addition, outstanding comments have been addressed along=0A= > https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html.=0A= >=0A= > Please let us know if any comment happened to be remained open.=0A= >=0A= > Best regards,=0A= > Janos=0A= >=0A= > _______________________________________________=0A= > detnet mailing list=0A= > detnet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/detnet=0A= =0A= _______________________________________________=0A= detnet mailing list=0A= detnet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/detnet=0A= From nobody Sun Jan 6 22:54:07 2019 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 DCF9F130DE5 for ; Sun, 6 Jan 2019 22:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.566 X-Spam-Level: X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 ozJ5mw7Flg-h for ; Sun, 6 Jan 2019 22:54:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989C6130DDD for ; Sun, 6 Jan 2019 22:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6196; q=dns/txt; s=iport; t=1546844042; x=1548053642; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xoQdA12Oab78XUwK3dDSQrkQweGNwdZkrmNwAcPrCig=; b=UVOv9gsxhGJpjKUjo8rBHObWQ9gCoQ6B1KK/N8oh8kEC+tsBSjVdKrr+ w+28aagSOJSBCkN0m+ksN9SU1PNEEaEEalIbCggqbf03RMPAso0AxBF0g fmQmg5mEKBeHz2M4ZcXHVe5DFi265KwgZ6D4o0LJlFGPJFgTzJYPokrl4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAv9zJc/5RdJa1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCowPi2aCDXyOI4hPFIFnCwE?= =?us-ascii?q?BGAuEA0YCggIiNAkNAQMBAQIBAQJtHAyFSgEBAQQBASVHFwQCAQgRAQMBASg?= =?us-ascii?q?HJwsUAwYIAgQBEgiDG4IBD6cAM4QxAoVmBYw/F4FAP4ERghRJNYMeAQEBAQG?= =?us-ascii?q?BJgUBEQIBJSuFLQKJUoZfhgCLKwkChxKFJYUwIIFghSMFimeJYoUFiy8CERS?= =?us-ascii?q?BJx84ZXFwFRohgmyFAoYbhT9BMQGJYYEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,450,1539648000"; d="scan'208";a="502561947" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 06:54:00 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x076s0X0023328 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Jan 2019 06:54:00 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; Mon, 7 Jan 2019 00:53:59 -0600 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, 7 Jan 2019 00:54:00 -0600 From: "Pascal Thubert (pthubert)" To: Norman Finn , "Black, David" , =?iso-8859-1?Q?J=E1nos_Farkas?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7MS2a5F1EenOkimumZNuZjfBqWGuEMAgB0g4AD//6EpQA== Date: Mon, 7 Jan 2019 06:53:49 +0000 Deferred-Delivery: Mon, 7 Jan 2019 06:53:07 +0000 Message-ID: References: , <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F801720EBD@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.55.22.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 06:54:05 -0000 Dear all: This creates an interesting side effect: Since we are aiming at std track and using uppercase then we need to refere= nce BCP 14. Janos, could you please add this snippet as the first section o= f the terminology? Note that if we take that path we need to reconsider all lowercase use of t= he terms listed below. -----------------------------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 1= 4 when, and only whe= n, they appear in all capitals, as shown here.
--------------------------- Happy new year you all! Pascal > -----Original Message----- > From: detnet On Behalf Of Norman Finn > Sent: lundi 7 janvier 2019 07:27 > To: Black, David ; J=E1nos Farkas > ; DetNet WG > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 >=20 > I'm good with a SHOULD in the first paragraph of 3.3.2. >=20 > -- Norm > ________________________________________ > From: detnet [detnet-bounces@ietf.org] on behalf of Black, David > [David.Black@dell.com] > Sent: Wednesday, December 19, 2018 9:37 AM > To: J=E1nos Farkas; DetNet WG > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 >=20 > Janos, >=20 > The terminology is definitely improved - the resulting draft is much clea= rer - > many thanks to you and the authors for doing that. >=20 > Where do we stand on the concern about protecting external non-DetNet > networks from DetNet flows that escape a DetNet network, e.g., due to an > erroneous network configuration change? >=20 > My current views are ... >=20 > There's no throttling in DetNet, e.g., this text in 4.3.2: >=20 > There is no provision in DetNet for throttling DetNet flows, i.e., > the transmission rate cannot be reduced via explicit congestion > notification [RFC3168]. The assumption is that a DetNet flow, to be > useful, must be delivered in its entirety. >=20 > and no assurance that all DetNet-using applications will cease and desist= in the > face of packet drops that indicate congestion. >=20 > Packet Replication and Elimination makes this worse via its ability to hi= de > network packet drops and congestion indications from endpoints, e.g., of = those > drops and/or congestion indications occur on only one of the paths used b= y > replicated packets. >=20 > The first paragraph in section 3.3.2 is a good start, but I think its low= er case > "should" is too weak: >=20 > 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 a volume. Furthermore, filters and > policers can take actions to discard the offending packets or flows, > or trigger shutting down the offending flow or the offending > interface. >=20 > At a minimum, I think that the requirement to discard DetNet traffic that > would otherwise escape a DetNet network has to be stated as a "MUST" > requirement for any DetNet network that supports Packet Replication and > Elimination due to the ability of that functionality to hide congestion f= rom > endpoints, making it impossible for higher layers of the protocol stack t= o > respond. >=20 > Beyond this, I think a "SHOULD" requirement to discard DetNet traffic tha= t > would otherwise escape is needed, and the statement of that requirement > ought to be connected to the explanation of how to implement that > requirement. The text in Section 3.3.2 has a lot of the content needed -= for a > worked example of such "SHOULD" text, see Section 5 of RFC 7510, in > particular the itemized list at the end of that section and the paragraph= that > introduces that list: > https://tools.ietf.org/html/rfc7510#section-5 >=20 > Thanks, --David >=20 > > -----Original Message----- > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of J=E1nos > > Farkas > > Sent: Wednesday, December 19, 2018 10:54 AM > > To: DetNet WG > > Subject: [Detnet] draft-ietf-detnet-architecture-10 > > > > > > [EXTERNAL EMAIL] > > > > Hi, > > > > The DetNet architecture document has been updated to address the > > comments. The new revision (v10) is available at > > https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. > > > > There have been a number of discussion items emails on the list. The > > updates are along the major discussion items, which also cover the > > derivative discussions, address the comments. > > > > The major items have been summarized in: > > https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. > > Follow up discussions implied terminology changes summarized in: > > https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: > > replace "transport sub-layer" with "forwarding sub-layer" > > https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: > > replace "congestion protection" with "resource" allocation" > > Consequently, the document had a good 'scurb". > > > > In addition, outstanding comments have been addressed along > > https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. > > > > Please let us know if any comment happened to be remained open. > > > > Best regards, > > Janos > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Jan 7 03:10:26 2019 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 32DC2130DE7 for ; Mon, 7 Jan 2019 03:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 aGmwWjREcxxJ for ; Mon, 7 Jan 2019 03:10:12 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 63460130EA0 for ; Mon, 7 Jan 2019 03:10:12 -0800 (PST) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 8194A1406C6 for ; Mon, 7 Jan 2019 04:10:03 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id gSnDgvhkEqZYcgSnDg1SeJ; Mon, 07 Jan 2019 04:10:03 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason 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:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc: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=YBZiVviTKumh87T2T52y17Zt+hQ1gLLE0elb612SP/4=; b=BZuU6pPpGjmQ0Bd1oPOsAGdQak izvMy5OrhhgxiUbSgDWn8z1w0pHIkj8lmFsNqfSnlgwniWTs9P4jDJCIXhP+vfC5oQ4Nn+nMpg6d0 pH8Khc433rxQc6vzBwblFsxwC; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:58067 helo=[11.5.0.30]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ggSnC-001SFY-Ri; Mon, 07 Jan 2019 04:10:03 -0700 From: Lou Berger To: Norman Finn , "Black, David" , =?UTF-8?B?SsOhbm9zIEZhcmthcw==?= , DetNet WG Date: Mon, 07 Jan 2019 06:09:59 -0500 Message-ID: <16828014758.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com> References: , <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com> User-Agent: AquaMail/1.18.1-1405 (build: 101800005) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1ggSnC-001SFY-Ri X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([11.5.0.30]) [72.66.11.201]:58067 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 11:10:19 -0000 Norm (Pascal), Please see my response to David -- wrt to *not* introducing capitalization in this case/document. Lou ---------- On January 7, 2019 1:27:31 AM Norman Finn wrote: > I'm good with a SHOULD in the first paragraph of 3.3.2. > > -- Norm > ________________________________________ > From: detnet [detnet-bounces@ietf.org] on behalf of Black, David > [David.Black@dell.com] > Sent: Wednesday, December 19, 2018 9:37 AM > To: János Farkas; DetNet WG > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > Janos, > > The terminology is definitely improved - the resulting draft is much > clearer - many thanks to you and the authors for doing that. > > Where do we stand on the concern about protecting external > non-DetNet networks from DetNet flows that escape a DetNet > network, e.g., due to an erroneous network configuration change? > > My current views are ... > > There's no throttling in DetNet, e.g., this text in 4.3.2: > > There is no provision in DetNet for throttling DetNet flows, i.e., > the transmission rate cannot be reduced via explicit congestion > notification [RFC3168]. The assumption is that a DetNet flow, to be > useful, must be delivered in its entirety. > > and no assurance that all DetNet-using applications will cease and desist > in the face of packet drops that indicate congestion. > > Packet Replication and Elimination makes this worse via its ability to hide > network packet drops and congestion indications from endpoints, e.g., > of those drops and/or congestion indications occur on only one of > the paths used by replicated packets. > > The first paragraph in section 3.3.2 is a good start, but I think its lower > case "should" is too weak: > > 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 a volume. Furthermore, filters and > policers can take actions to discard the offending packets or flows, > or trigger shutting down the offending flow or the offending > interface. > > At a minimum, I think that the requirement to discard DetNet traffic > that would otherwise escape a DetNet network has to be stated as > a "MUST" requirement for any DetNet network that supports Packet > Replication and Elimination due to the ability of that functionality > to hide congestion from endpoints, making it impossible for higher > layers of the protocol stack to respond. > > Beyond this, I think a "SHOULD" requirement to discard DetNet traffic > that would otherwise escape is needed, and the statement of that > requirement ought to be connected to the explanation of how to > implement that requirement. The text in Section 3.3.2 has a lot of > the content needed - for a worked example of such "SHOULD" text, > see Section 5 of RFC 7510, in particular the itemized list at the end of > that section and the paragraph that introduces that list: > https://tools.ietf.org/html/rfc7510#section-5 > > Thanks, --David > >> -----Original Message----- >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of János Farkas >> Sent: Wednesday, December 19, 2018 10:54 AM >> To: DetNet WG >> Subject: [Detnet] draft-ietf-detnet-architecture-10 >> >> >> [EXTERNAL EMAIL] >> >> Hi, >> >> The DetNet architecture document has been updated to address the >> comments. The new revision (v10) is available at >> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. >> >> There have been a number of discussion items emails on the list. The >> updates are along the major discussion items, which also cover the >> derivative discussions, address the comments. >> >> The major items have been summarized in: >> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. >> Follow up discussions implied terminology changes summarized in: >> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: >> replace "transport sub-layer" with "forwarding sub-layer" >> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: >> replace "congestion protection" with "resource" allocation" >> Consequently, the document had a good 'scurb". >> >> In addition, outstanding comments have been addressed along >> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. >> >> Please let us know if any comment happened to be remained open. >> >> Best 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 Mon Jan 7 07:44:36 2019 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 513BB130EDB for ; Mon, 7 Jan 2019 07:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=DDha/8MI; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=IvEGh5ps 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 6VuIXmpYxTwB for ; Mon, 7 Jan 2019 07:44:32 -0800 (PST) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 AD7E5126CC7 for ; Mon, 7 Jan 2019 07:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1546875871; x=1578411871; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tnyi1+5otwCfUfCPFeQRWMXV6KTQ8MnzrNIrdKGxonQ=; b=DDha/8MIvWw0BrX2h/gIBJKAXXij6HDZf7JKgmSRdJRywWQxbvpY7Z/T Wux4fT8DlcZ7cTw9yn3cf91d5Fr1Q9n7korf+hKAG45klnLI8XSJ7o4Zh DmMY0CmnfYI8xWkivGkSxe2zokizoOVz9MNF5Z1nqn+1CGqtGKCjKWyBv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EFAACicjNchyeV50NjGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEwgTmBAicKg3VihzhfiweCDZdvFIErPAsBARgLC4N?= =?us-ascii?q?4RgIXgW4iNAkNAQMBAQIBAQIBAQIQAQEBFQkIKSMMgjopARQxHC8JBgEBAQE?= =?us-ascii?q?BAScBAQEBAQEBAQEBAQEBAQEBAQEXAkMBEgEBGAEBAQECAQEBEBERDB8PDAQ?= =?us-ascii?q?HBAIBCA4DAQMBAQECAgYdAwICAiULFAECBggCBAESCBMHgwABgXkIAQ6ZeD0?= =?us-ascii?q?CgW6JBgEBAW6BL4J9gTQChWcDBYELizSBWD6BEUaBTn6DHgEBAQEBgSsBEQI?= =?us-ascii?q?BIBWCcTGCJolQmA4DBAIChxKKdYFghSODM4c5iWKEfgeLLwIEAgQFAhSBRjd?= =?us-ascii?q?ncXBQgmyCJw4Jg0uFFIU/QTEBiWCBHwEB?= X-IPAS-Result: =?us-ascii?q?A2EFAACicjNchyeV50NjGwEBAQEDAQEBBwMBAQGBUQYBA?= =?us-ascii?q?QELAYEwgTmBAicKg3VihzhfiweCDZdvFIErPAsBARgLC4N4RgIXgW4iNAkNA?= =?us-ascii?q?QMBAQIBAQIBAQIQAQEBFQkIKSMMgjopARQxHC8JBgEBAQEBAScBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEXAkMBEgEBGAEBAQECAQEBEBERDB8PDAQHBAIBCA4DAQMBA?= =?us-ascii?q?QECAgYdAwICAiULFAECBggCBAESCBMHgwABgXkIAQ6ZeD0CgW6JBgEBAW6BL?= =?us-ascii?q?4J9gTQChWcDBYELizSBWD6BEUaBTn6DHgEBAQEBgSsBEQIBIBWCcTGCJolQm?= =?us-ascii?q?A4DBAIChxKKdYFghSODM4c5iWKEfgeLLwIEAgQFAhSBRjdncXBQgmyCJw4Jg?= =?us-ascii?q?0uFFIU/QTEBiWCBHwEB?= Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 07 Jan 2019 09:44:29 -0600 Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x07FbdHO095474 for ; Mon, 7 Jan 2019 10:44:29 -0500 Received: from esa3.dell-outbound2.iphmx.com (esa3.dell-outbound2.iphmx.com [68.232.154.63]) by mx0a-00154901.pphosted.com with ESMTP id 2pu2xe7t9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 07 Jan 2019 10:44:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 07 Jan 2019 21:44:20 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x07FiOdD027082 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 10:44:26 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x07FiOdD027082 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1546875866; bh=MpygXwVVy8ouyAVTZeQdKILTY6A=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IvEGh5pszqb22nNjHIW7FnakkQV30iP+iTdYvhENXkxEgby4/ESd11yAZwC94FtXV 27LDbLJMhZ05V6qF8fHsw+9gqL/5Krk8k/CsexlT6Iu2yFhULTp9NctfveK8Qd+5vC IuyCPRu6/tLTWPZhiQ3+MSRM21sKb76K5k3IPyGQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x07FiOdD027082 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 7 Jan 2019 10:44:04 -0500 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x07Fi6Ug008417 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 7 Jan 2019 10:44:06 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0399.000; Mon, 7 Jan 2019 10:44:06 -0500 To: Lou Berger , =?utf-8?B?SsOhbm9zIEZhcmthcw==?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7MQHC64vzb8fEG2yQUlzcD3VqWGSxwQgAhk5ID///4dQIABWMAAgBQC8lA= Date: Mon, 7 Jan 2019 15:44:06 +0000 Message-ID: References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> In-Reply-To: <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound 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-1810050000 definitions=main-1901070137 Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 15:44:35 -0000 TG91LA0KDQpBdHRlbXB0aW5nIHRvIHN1bW1hcml6ZSB3aGF0IG5lZWRzIHRvIGJlIHN0YXRlZCB3 aXRob3V0IHVzaW5nIE1VU1QvU0hPVUxEL01BWToNCg0KWzFdIFNlbmRpbmcgRGV0TmV0IHRyYWZm aWMgaW50byBuZXR3b3JrcyB0aGF0IGhhdmUgbm90IGJlZW4gcHJvdmlzaW9uZWQgaW4gYWR2YW5j ZSB0byBoYW5kbGUgdGhhdCBEZXROZXQgdHJhZmZpYyBoYXMgdG8gYmUgdHJlYXRlZCBhcyBhIGZh dWx0LiAgRWdyZXNzIHRyYWZmaWMgZmlsdGVycyB0byBwcmV2ZW50IHRoaXMgZnJvbSBoYXBwZW5p bmcgYXJlIHN0cm9uZ2x5IHJlY29tbWVuZGVkIGF0IHRoZSBlZGdlcyBvZiBhIERldE5ldCBuZXR3 b3JrcyBhbmQgRGV0TmV0IHN1cHBvcnRpbmcgbmV0d29ya3MuICBJbiB0aGlzIGNvbnRleHQsIHRo ZSB0ZXJtICdwcm92aXNpb25lZCcgaGFzIGEgYnJvYWQgbWVhbmluZywgZS5nLiwgcHJvdmlzaW9u aW5nIGNvdWxkIGJlIHBlcmZvcm1lZCB2aWEgYW4gYWRtaW5pc3RyYXRpdmUgZGVjaXNpb24gdGhh dCB0aGUgZG93bnN0cmVhbSBuZXR3b3JrIGhhcyB0aGUgYXZhaWxhYmxlIGNhcGFjaXR5IHRvIGNh cnJ5IHRoZSBEZXROZXQgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHNlbnQgaW50byBpdC4NCg0KWzJd IFNlbmRpbmcgbm9uLWNvbmdlc3Rpb24tY29udHJvbGxlZCBEZXROZXQgdHJhZmZpYyAoaS5lLiwg RGV0TmV0IHRyYWZmaWMgdGhhdCBkb2VzIG5vdCBjb21wbHkgd2l0aCBCQ1AgNDEvUkZDIDI5MTQp IGludG8gYSBuZXR3b3JrIHRoYXQgaXMgbm90IHByb3Zpc2lvbmVkIHRvIGhhbmRsZSB0aGF0IHRy YWZmaWMgaGFzIHRvIGJlIHByZXZlbnRlZCBpbiBhZGRpdGlvbiB0byBiZWluZyB0cmVhdGVkIGFz IGEgZmF1bHQuICBEZXROZXQgdHJhZmZpYyB0aGF0IGlzIG5vdCBrbm93biB0byBiZSBjb25nZXN0 aW9uIGNvbnRyb2xsZWQgaGFzIHRvIGJlIHRyZWF0ZWQgYXMgbm9uLWNvbmdlc3Rpb24tY29udHJv bGxlZCBEZXROZXQgdHJhZmZpYyBmb3IgdGhpcyByZXF1aXJlbWVudC4gIERldE5ldCByZXBsaWNh dGVkIHRyYWZmaWMgaXMgYWx3YXlzIG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgZXZlbiBpZiB0 aGUgb3JpZ2luYWwgRGV0TmV0IGZsb3cgaXMgY29uZ2VzdGlvbi1jb250cm9sbGVkIGJlY2F1c2Ug RGV0TmV0IHBhY2tldCBlbGltaW5hdGlvbiBjYW4gaGlkZSBjb25nZXN0aW9uIGluZGljYXRpb25z IChlLmcuLCBkcm9wcywgRUNOIENFIG1hcmtzLCBpbmNyZWFzZWQgbGF0ZW5jeSkgZnJvbSBlbmRw b2ludHMuICBUaGUgcmVzcG9uc2liaWxpdHkgZm9yIGRlYWxpbmcgd2l0aCB0aGVzZSByZXF1aXJl bWVudHMgaW4gZ2VuZXJhbCwgYW5kIHJlcGxpY2F0ZWQgdHJhZmZpYyBpbiBwYXJ0aWN1bGFyLCBp cyBzb2x1dGlvbi1zcGVjaWZpYywgYXMgdGhlcmUgYXJlIE1QTFMgbWVjaGFuaXNtcyB0aGF0IGNh bm5vdCBiZSBhcHBsaWVkIHRvIHRoZSBJUCBzb2x1dGlvbiwgYW5kIG1vcmVvdmVyLCB0aGUgY3Vy cmVudCBJUCBzb2x1dGlvbiBkb2Vzbid0IHN1cHBvcnQgRGV0TmV0IHRyYWZmaWMgcmVwbGljYXRp b24uDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBUdWVz ZGF5LCBEZWNlbWJlciAyNSwgMjAxOCAxMTo0NSBBTQ0KPiBUbzogQmxhY2ssIERhdmlkOyBKw6Fu b3MgRmFya2FzOyBEZXROZXQgV0cNCj4gU3ViamVjdDogUmU6IFtEZXRuZXRdIGRyYWZ0LWlldGYt ZGV0bmV0LWFyY2hpdGVjdHVyZS0xMA0KPiANCj4gDQo+IFtFWFRFUk5BTCBFTUFJTF0NCj4gDQo+ IEhpIERhdmlkLA0KPiANCj4gT24gMTIvMjQvMjAxOCA4OjI5IFBNLCBCbGFjaywgRGF2aWQgd3Jv dGU6DQo+ID4gSGkgTG91LA0KPiA+DQo+ID4gRXhjZXJwdGluZyBrZXkgcGFyYWdyYXBocyAuLi4N Cj4gPg0KPiA+PiBUbyBtZSBjbGVhciwgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgdGV4dCBiZSBh ZGRlZCB0byBzYXkgdGhhdCBzZW5kaW5nDQo+ID4+IGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1k ZXRuZXQgaW50ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPj4gSXMgdGhp cyBjb3JyZWN0Pw0KPiA+IE5vdCBleGFjdGx5IC4uLg0KPiA+DQo+ID4+IElmIHNvLCBJIHRoaW5r IHRoaXMgaXMgdG9vIGJyb2FkIGNvbnNpZGVyaW5nIHRoYXQNCj4gPj4gdGhlcmUgYXJlIG5ldHdv cmtzIHRoYXQgY2FuIHByb3ZpZGVkIHRoZSByZXF1aXJlZCBkZXRuZXQgZm9yd2FyZGluZw0KPiA+ PiBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBub3QgZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMg aXMgbWVudGlvbmVkIGF0DQo+ID4+IHRoZSBlbmQgb2Ygc2VjdGlvbiA0LjMuMi4gKEknbGwgcmVm ZXIgdG8gc3VjaCBhcyAiRGV0TmV0IHN1cHBvcnRpbmcNCj4gPj4gbmV0d29ya3MiIGluIHRoZSBu ZXh0IHBhcmFncmFwaC4pDQo+ID4gSSBhZ3JlZSB3aXRoIHdoZXJlIHRoaXMgaXMgaGVhZGVkIC0g c2VuZGluZyBEZXROZXQgdHJhZmZpYyBpbnRvIGEgbmV0d29yaw0KPiA+IHRoYXQgaGFzIG5vdCBi ZWVuIHByb3Zpc2lvbmVkIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGRldG5ldCBmb3J3YXJkaW5n DQo+ID4gc2VydmljZSB0byB0aGF0IHRyYWZmaWMgaGFzIHRvIGJlIHRyZWF0ZWQgYXMgYSBmYXVs dC4gIEluIHRoaXMgc3RhdGVtZW50LA0KPiA+ICJwcm92aXNpb25lZCIgc2hvdWxkIGJlIHJlYWQg YnJvYWRseSwgZS5nLiwgaXQgY291bGQgYmUgcmVhbGl6ZWQgdmlhIGFuDQo+ID4gYWRtaW5pc3Ry YXRpdmUgZGVjaXNpb24gdGhhdCB0aGUgRGV0TmV0IHN1cHBvcnRpbmcgbmV0d29yayBoYXMgdGhl DQo+ID4gYXZhaWxhYmxlIGNhcGFjaXR5IHRvIGNhcnJ5IHRoZSBEZXROZXQgdHJhZmZpYyB0aGF0 IGlzIGJlaW5nIHNlbnQgaW50byBpdC4NCj4gYWdyZWVkLg0KPiA+PiBUaGlzIHNhaWQsIEkgdGhp bmsgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0byBtYWtlIGl0IGEgcmVxdWlyZW1lbnQgdGhhdA0K PiA+PiBEZXROZXQgbm9kZXMgbXVzdCBub3QgZm9yd2FyZCB0cmFmZmljIHRoYXQgZG9lc24ndCBj b25mb3JtIHdpdGggQkNQNDENCj4gPj4gb3ZlciBhIG5ldHdvcmsgdGhhdCBpcyBuZWl0aGVyIGEg RGV0bmV0IG5ldHdvcmsgb3IgYSBEZXROZXQgc3VwcG9ydGluZw0KPiA+PiBuZXR3b3JrLiAgQWx0 aG91Z2ggdGhpcyB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIHRoZSBEZXROZXQgc2VydmljZQ0K PiA+PiBtb2RlbCwgaS5lLiwgIHRvIGtub3cgd2hpY2ggdHJhZmZpYyB3YXMgY29uZm9ybWFudC9u b24tY29uZm9ybWFudC4NCj4gPiBUaGF0J3MgZmluZSB3aXRoIG9uZSBpbXBvcnRhbnQgdHdpc3Q6 DQo+ID4NCj4gPiBBbnkgdHJhZmZpYyB0aGF0IGhhcyBiZWVuIHJlcGxpY2F0ZWQgYnkgRGV0TmV0 IHBhY2tldCByZXBsaWNhdGlvbiBoYXMgdG8NCj4gPiBiZSB0cmVhdGVkIGFzIG5vdCBjb25mb3Jt aW5nIHdpdGggQkNQNDEgYmVjYXVzZSBEZXROZXQgcGFja2V0DQo+ID4gZWxpbWluYXRpb24gKG9m IHJlcGxpY2F0ZWQgcGFja2V0cykgbWF5IGhpZGUgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucw0KPiA+ IChlLmcuLCBkZWxheSwgRUNOIENFIG1hcmtzLCBkcm9wcykgZnJvbSB0aGUgZW5kcG9pbnRzIC0g YSBzY2VuYXJpbyBvZg0KPiA+IHBhcnRpY3VsYXIgY29uY2VybiBpbnZvbHZlcyB0aGUgb3RoZXIg ZmxvdyBvZiByZXBsaWNhdGVkIHBhY2tldHMNCj4gPiBmb2xsb3dpbmcgYSBEZXROZXQgbmV0d29y ayBwYXRoIGFsb25nIHdoaWNoIG5vdGhpbmcgZ29lcyB3cm9uZy4NCj4gPiBCQ1A0MSBpcyBhYm91 dCBlbmQtdG8tZW5kLWNvbmdlc3Rpb24gY29udHJvbCwgd2hpY2ggZG9lcyBub3QgZG8NCj4gPiBh bnl0aGluZyBpZiBEZXROZXQgcGFja2V0IGVsaW1pbmF0aW9uIGhpZGVzIGNvbmdlc3Rpb24gaW5k aWNhdGlvbnMNCj4gPiBmcm9tIHRoZSBlbmRwb2ludHMuDQo+IA0KPiBUaGlzIHNlZW1zIHJlYXNv bmFibGUgdG8gbWUuDQo+IA0KPiANCj4gPg0KPiA+Pj4gQmV5b25kIHRoaXMsIEkgdGhpbmsgYSAi U0hPVUxEIiByZXF1aXJlbWVudCB0byBkaXNjYXJkIERldE5ldCB0cmFmZmljDQo+ID4+PiB0aGF0 IHdvdWxkIG90aGVyd2lzZSBlc2NhcGUgaXMgbmVlZGVkLCBhbmQgdGhlIHN0YXRlbWVudCBvZiB0 aGF0DQo+ID4+PiByZXF1aXJlbWVudCBvdWdodCB0byBiZSBjb25uZWN0ZWQgdG8gdGhlIGV4cGxh bmF0aW9uIG9mIGhvdyB0bw0KPiA+Pj4gaW1wbGVtZW50IHRoYXQgcmVxdWlyZW1lbnQuDQo+ID4+ IEkgdGhpbmsgYWRkaW5nIGEgc3RhdGVtZW50IG9uIG91dHB1dCBmaWx0ZXJzIChhbmQgcG9saWNl cnMpIHRvIHRoaXMNCj4gPj4gc2VjdGlvbiBpcyByZWFzb25hYmxlLg0KPiA+IExldCdzIHN0YXJ0 IHdpdGggdGhlIGluY2x1c2lvbiBvZiBvdXRwdXQgZmlsdGVycyAoYW5kIHBvbGljZXJzKSBpbiB0 aGUgMy4zLjINCj4gPiB0ZXh0IHdpdGggdGhlIHVzZSBvZiB1cHBlci1jYXNlICJTSE9VTEQiIGFz IHN1Z2dlc3RlZCBieSBQYXNjYWwgLSBJIHdpbGwNCj4gPiBsb29rIHRoaXMgb3ZlciBhbmQgc3Vn Z2VzdCBhbnkgYWRkaXRpb25hbCB0ZXh0IHRoYXQgSSB0aGluayBvdWdodCB0byBiZQ0KPiA+IGlu Y2x1ZGVkLg0KPiANCj4gQXMgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LCB0aGUgYXV0aG9ycy9X RyBtYWRlIHRoZSBjYWxsIHRvIG5vdCB1c2UNCj4gY29uZm9ybWFuY2UgY2FwaXRhbGl6YXRpb24g b3IgcmVmZXJlbmNlIDIxMTkvODE3NC7CoCBJIHRoaW5rIHRoaXMNCj4gdHJhbnNsYXRlcyB0byB0 aGUgY29uZm9ybWFuY2UgbGFuZ3VhZ2UgbmVlZGluZyB0byBiZSBhZGRlZCB0byB0aGUgZGF0YQ0K PiBwbGFuZSBzb2x1dGlvbiBkb2N1bWVudHMuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBMb3UNCj4g DQo+IA0KPiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0K PiA+PiBTZW50OiBNb25kYXksIERlY2VtYmVyIDI0LCAyMDE4IDM6MTggUE0NCj4gPj4gVG86IEJs YWNrLCBEYXZpZDsgSsOhbm9zIEZhcmthczsgRGV0TmV0IFdHDQo+ID4+IFN1YmplY3Q6IFJlOiBb RGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTANCj4gPj4NCj4gPj4NCj4g Pj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiA+Pg0KPiA+PiBIaSBEYXZpZCwNCj4gPj4NCj4gPj4gT24g MTIvMTkvMjAxOCAxMjozNyBQTSwgQmxhY2ssIERhdmlkIHdyb3RlOg0KPiA+Pj4gSmFub3MsDQo+ ID4+Pg0KPiA+Pj4gVGhlIHRlcm1pbm9sb2d5IGlzIGRlZmluaXRlbHkgaW1wcm92ZWQgLSB0aGUg cmVzdWx0aW5nIGRyYWZ0IGlzIG11Y2gNCj4gPj4+IGNsZWFyZXIgLSBtYW55IHRoYW5rcyB0byB5 b3UgYW5kIHRoZSBhdXRob3JzIGZvciBkb2luZyB0aGF0Lg0KPiA+PiBIYXBweSB0byBoZWFyIHRo YXQuDQo+ID4+DQo+ID4+DQo+ID4+PiBXaGVyZSBkbyB3ZSBzdGFuZCBvbiB0aGUgY29uY2VybiBh Ym91dCBwcm90ZWN0aW5nIGV4dGVybmFsDQo+ID4+PiBub24tRGV0TmV0IG5ldHdvcmtzIGZyb20g RGV0TmV0IGZsb3dzIHRoYXQgZXNjYXBlIGEgRGV0TmV0DQo+ID4+PiBuZXR3b3JrLCBlLmcuLCBk dWUgdG8gYW4gZXJyb25lb3VzIG5ldHdvcmsgY29uZmlndXJhdGlvbiBjaGFuZ2U/DQo+ID4+IEkn bSBub3Qgc3VyZSB3ZSBoYXZlIGdlbmVyYWwgc29sdXRpb25zIGluIHRoZSBpbnRlcm5ldCBhcmNo aXRlY3R1cmUgZm9yDQo+ID4+IG1pc3MtY29uZmlndXJlZC9idWdneSBzeXN0ZW1zIG90aGVyIHRo YW4gZHJvcHBpbmcgdGhlIHBhY2tldHMgb24gdGhlDQo+ID4+IGZsb29yIChlLmcuLCBkdWUgdG8g bm8gcm91dGUsIG5vIGxhYmVsLCBvciB0dGwgZXhwaXJ5KS7CoCBXaGF0IHR5cGUgb2YNCj4gPj4g cHJvdGVjdGlvbiBhcmUgeW91IGxvb2tpbmcgZm9yIGhlcmUsIGFuZCBjYW4geW91IHByb3ZpZGUg YSByZWZlcmVuY2UgdG8NCj4gPj4gdGhlIHR5cGUgb2Ygcm91dGVyIGJlaGF2aW9yIHlvdSB3b3Vs ZCBsaWtlIHRvIHNlZT/CoCBJIGhhdmUgYSBzdWdnZXN0aW9uDQo+ID4+IHRoYXQgbWlnaHQgYWRk cmVzcyB5b3VyIGNvbmNlcm4gYmVsb3cgZWxhdGVkIHRvIG5vbi1CQ1A0MSBjb25mb3JtYW50DQo+ ID4+IHRyYWZmaWMsIGJ1dCBhbSB1bnN1cmUgaWYgdGhpcyBpcyB3aGF0IHlvdSBhcmUgY29uY2Vy bmVkIGFib3V0Lg0KPiA+Pg0KPiA+Pj4gTXkgY3VycmVudCB2aWV3cyBhcmUgLi4uDQo+ID4+Pg0K PiA+Pj4gVGhlcmUncyBubyB0aHJvdHRsaW5nIGluIERldE5ldCwgZS5nLiwgdGhpcyB0ZXh0IGlu IDQuMy4yOg0KPiA+Pj4NCj4gPj4+ICAgICAgVGhlcmUgaXMgbm8gcHJvdmlzaW9uIGluIERldE5l dCBmb3IgdGhyb3R0bGluZyBEZXROZXQgZmxvd3MsIGkuZS4sDQo+ID4+PiAgICAgIHRoZSB0cmFu c21pc3Npb24gcmF0ZSBjYW5ub3QgYmUgcmVkdWNlZCB2aWEgZXhwbGljaXQgY29uZ2VzdGlvbg0K PiA+Pj4gICAgICBub3RpZmljYXRpb24gW1JGQzMxNjhdLiAgVGhlIGFzc3VtcHRpb24gaXMgdGhh dCBhIERldE5ldCBmbG93LCB0byBiZQ0KPiA+Pj4gICAgICB1c2VmdWwsIG11c3QgYmUgZGVsaXZl cmVkIGluIGl0cyBlbnRpcmV0eS4NCj4gPj4gV2VsbCBsb29raW5nIGF0IGl0IHRoaXMgd2F5LCB0 aGVyZSBpcyBubyB0aHJvdHRsaW5nIGluIGFueSBJUCBuZXR3b3JrIGFzDQo+ID4+IHRoZSByb3V0 ZXJzIGdlbmVyYXRlIHRoZSBDTiBhbmQgb25seSBkcm9wIHdoZW4gdGhlaXIgcXVldWVzIGFyZSBm dWxsIG9yDQo+ID4+IGltcGxlbWVudGluZyBzb21lIHNvcnQgb2YgUkVELg0KPiA+Pg0KPiA+PiBJ biBEZXROZXQgdGhlcmUgaXMgYW4gZXhwZWN0YXRpb24gdGhhdCBpbnRlcm1lZGlhdGUgbm9kZXMg ZG8gbW9yZSB0aGFuDQo+ID4+IHRoaXMuwqAgU3BlY2lmaWNhbGx5LCBzZWUgc2VjdGlvbiA0LjU6 ICJRdWV1aW5nLCBTaGFwaW5nLCBTY2hlZHVsaW5nLCBhbmQNCj4gPj4gUHJlZW1wdGlvbiIgYW5k IHBvbGljaW5nLCB3aGljaCBpcyBtZW50aW9uZWQgYXMgcmVxdWlyZW1lbnQgaW4gc2VjdGlvbg0K PiA+PiAzLjMuMS4NCj4gPj4NCj4gPj4+IGFuZCBubyBhc3N1cmFuY2UgdGhhdCBhbGwgRGV0TmV0 LXVzaW5nIGFwcGxpY2F0aW9ucyB3aWxsIGNlYXNlIGFuZCBkZXNpc3QNCj4gPj4+IGluIHRoZSBm YWNlIG9mIHBhY2tldCBkcm9wcyB0aGF0IGluZGljYXRlIGNvbmdlc3Rpb24uDQo+ID4+IEkgdGhp bmsgdGhpcyBpcyBjb3JyZWN0Lg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gUGFja2V0IFJlcGxpY2F0aW9u IGFuZCBFbGltaW5hdGlvbiBtYWtlcyB0aGlzIHdvcnNlIHZpYSBpdHMgYWJpbGl0eSB0byBoaWRl DQo+ID4+PiBuZXR3b3JrIHBhY2tldCBkcm9wcyBhbmQgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBm cm9tIGVuZHBvaW50cywgZS5nLiwNCj4gPj4+IG9mIHRob3NlIGRyb3BzIGFuZC9vciBjb25nZXN0 aW9uIGluZGljYXRpb25zIG9jY3VyIG9uIG9ubHkgb25lIG9mDQo+ID4+PiB0aGUgcGF0aHMgdXNl ZCBieSByZXBsaWNhdGVkIHBhY2tldHMuDQo+ID4+Pg0KPiA+Pj4gVGhlIGZpcnN0IHBhcmFncmFw aCBpbiBzZWN0aW9uIDMuMy4yIGlzIGEgZ29vZCBzdGFydCwgYnV0IEkgdGhpbmsgaXRzIGxvd2Vy DQo+ID4+PiBjYXNlICJzaG91bGQiIGlzIHRvbyB3ZWFrOg0KPiA+Pj4NCj4gPj4+ICAgICAgUm9i dXN0IHJlYWwtdGltZSBzeXN0ZW1zIHJlcXVpcmUgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgcG9z c2libGUNCj4gPj4+ICAgICAgZmFpbHVyZXMuICBGaWx0ZXJzIGFuZCBwb2xpY2VycyBzaG91bGQg YmUgdXNlZCBpbiBhIERldE5ldCBuZXR3b3JrIHRvDQo+ID4+PiAgICAgIGRldGVjdCBpZiBEZXRO ZXQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gdGhlIHdyb25nIGludGVyZmFjZSwgb3IgYXQNCj4g Pj4+ICAgICAgdGhlIHdyb25nIHRpbWUsIG9yIGluIHRvbyBncmVhdCBhIHZvbHVtZS4gIEZ1cnRo ZXJtb3JlLCBmaWx0ZXJzIGFuZA0KPiA+Pj4gICAgICBwb2xpY2VycyBjYW4gdGFrZSBhY3Rpb25z IHRvIGRpc2NhcmQgdGhlIG9mZmVuZGluZyBwYWNrZXRzIG9yIGZsb3dzLA0KPiA+Pj4gICAgICBv ciB0cmlnZ2VyIHNodXR0aW5nIGRvd24gdGhlIG9mZmVuZGluZyBmbG93IG9yIHRoZSBvZmZlbmRp bmcNCj4gPj4+ICAgICAgaW50ZXJmYWNlLg0KPiA+Pj4NCj4gPj4+IEF0IGEgbWluaW11bSwgSSB0 aGluayB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBkaXNjYXJkIERldE5ldCB0cmFmZmljDQo+ID4+ PiB0aGF0IHdvdWxkIG90aGVyd2lzZSBlc2NhcGUgYSBEZXROZXQgbmV0d29yayBoYXMgdG8gYmUg c3RhdGVkIGFzDQo+ID4+PiBhICJNVVNUIiByZXF1aXJlbWVudCBmb3IgYW55IERldE5ldCBuZXR3 b3JrIHRoYXQgc3VwcG9ydHMgUGFja2V0DQo+ID4+PiBSZXBsaWNhdGlvbiBhbmQgRWxpbWluYXRp b24gZHVlIHRvIHRoZSBhYmlsaXR5IG9mIHRoYXQgZnVuY3Rpb25hbGl0eQ0KPiA+Pj4gdG8gaGlk ZSBjb25nZXN0aW9uIGZyb20gZW5kcG9pbnRzLCBtYWtpbmcgaXQgaW1wb3NzaWJsZSBmb3IgaGln aGVyDQo+ID4+PiBsYXllcnMgb2YgdGhlIHByb3RvY29sIHN0YWNrIHRvIHJlc3BvbmQuDQo+ID4+ IFRvIG1lIGNsZWFyLCB5b3VyIGFyZSBzdWdnZXN0aW5nIHRoYXQgdGV4dCBiZSBhZGRlZCB0byBz YXkgdGhhdCBzZW5kaW5nDQo+ID4+IGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1kZXRuZXQgaW50 ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPj4gSXMgdGhpcyBjb3JyZWN0 P8KgIElmIHNvLCBJIHRoaW5rIHRoaXMgaXMgdG9vIGJyb2FkIGNvbnNpZGVyaW5nIHRoYXQNCj4g Pj4gdGhlcmUgYXJlIG5ldHdvcmtzIHRoYXQgY2FuIHByb3ZpZGVkIHRoZSByZXF1aXJlZCBkZXRu ZXQgZm9yd2FyZGluZw0KPiA+PiBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBub3QgZGV0bmV0 IHNlcnZpY2UgYXdhcmUgYXMgaXMgbWVudGlvbmVkIGF0DQo+ID4+IHRoZSBlbmQgb2Ygc2VjdGlv biA0LjMuMi4gKEknbGwgcmVmZXIgdG8gc3VjaCBhcyAiRGV0TmV0IHN1cHBvcnRpbmcNCj4gPj4g bmV0d29ya3MiIGluIHRoZSBuZXh0IHBhcmFncmFwaC4pDQo+ID4+DQo+ID4+IFRoaXMgc2FpZCwg SSB0aGluayBpdCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIG1ha2UgaXQgYSByZXF1aXJlbWVudCB0 aGF0DQo+ID4+IERldE5ldCBub2RlcyBtdXN0IG5vdCBmb3J3YXJkIHRyYWZmaWMgdGhhdCBkb2Vz bid0IGNvbmZvcm0gd2l0aCBCQ1A0MQ0KPiA+PiBvdmVyIGEgbmV0d29yayB0aGF0IGlzIG5laXRo ZXIgYSBEZXRuZXQgbmV0d29yayBvciBhIERldE5ldCBzdXBwb3J0aW5nDQo+ID4+IG5ldHdvcmsu wqAgQWx0aG91Z2ggdGhpcyB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIHRoZSBEZXROZXQgc2Vy dmljZQ0KPiA+PiBtb2RlbCwgaS5lLizCoCB0byBrbm93IHdoaWNoIHRyYWZmaWMgd2FzIGNvbmZv cm1hbnQvbm9uLWNvbmZvcm1hbnQuDQo+ID4+DQo+ID4+DQo+ID4+PiBCZXlvbmQgdGhpcywgSSB0 aGluayBhICJTSE9VTEQiIHJlcXVpcmVtZW50IHRvIGRpc2NhcmQgRGV0TmV0IHRyYWZmaWMNCj4g Pj4+IHRoYXQgd291bGQgb3RoZXJ3aXNlIGVzY2FwZSBpcyBuZWVkZWQsIGFuZCB0aGUgc3RhdGVt ZW50IG9mIHRoYXQNCj4gPj4+IHJlcXVpcmVtZW50IG91Z2h0IHRvIGJlIGNvbm5lY3RlZCB0byB0 aGUgZXhwbGFuYXRpb24gb2YgaG93IHRvDQo+ID4+PiBpbXBsZW1lbnQgdGhhdCByZXF1aXJlbWVu dC4NCj4gPj4gSSB0aGluayBhZGRpbmcgYSBzdGF0ZW1lbnQgb24gb3V0cHV0IGZpbHRlcnMgKGFu ZCBwb2xpY2llcnMpIHRvIHRoaXMNCj4gPj4gc2VjdGlvbiBpcyByZWFzb25hYmxlLg0KPiA+Pg0K PiA+Pg0KPiA+Pj4gVGhlIHRleHQgaW4gU2VjdGlvbiAzLjMuMiBoYXMgYSBsb3Qgb2YNCj4gPj4+ IHRoZSBjb250ZW50IG5lZWRlZCAtIGZvciBhIHdvcmtlZCBleGFtcGxlIG9mIHN1Y2ggIlNIT1VM RCIgdGV4dCwNCj4gPj4+IHNlZSBTZWN0aW9uIDUgb2YgUkZDIDc1MTAsIGluIHBhcnRpY3VsYXIg dGhlIGl0ZW1pemVkIGxpc3QgYXQgdGhlIGVuZCBvZg0KPiA+Pj4gdGhhdCBzZWN0aW9uIGFuZCB0 aGUgcGFyYWdyYXBoIHRoYXQgaW50cm9kdWNlcyB0aGF0IGxpc3Q6DQo+ID4+PiAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTEwI3NlY3Rpb24tNQ0KPiA+PiBJZiBJJ20gbm90 IG1pc3Rha2VuLCBzdWNoIG1lY2hhbmlzbXMgYXJlIGFscmVhZHkgaW5jbHVkZWQgaW4gdGhlDQo+ ID4+IGRvY3VtZW50IGFuZCB5b3UgcmVhbGx5IGFyZSBqdXN0IGFza2luZyB0aGVtIHRvIGJlIChy ZSlsaXN0ZWQgdG8gZW5zdXJlDQo+ID4+IHRoYXQgdGhpcyBpbXBvcnQgcG9pbnQgaXNuJ3QgbWlz c2VkLsKgIElzIHRoaXMgY29ycmVjdD8gQmVzaWRlcyB3aGF0IGlzDQo+ID4+IG1lbnRpb25lZCBh Ym92ZSwgaXMgdGhlcmUgYW55dGhpbmcgZWxzZSBtaXNzaW5nPw0KPiA+Pg0KPiA+PiBUaGFua3Mh DQo+ID4+DQo+ID4+IExvdQ0KPiA+Pg0KPiA+Pj4gVGhhbmtzLCAtLURhdmlkDQo+ID4+Pg0KPiA+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogZGV0bmV0IFttYWls dG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKw6Fub3MgRmFya2FzDQo+ ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxOCAxMDo1NCBBTQ0KPiA+Pj4+ IFRvOiBEZXROZXQgV0cNCj4gPj4+PiBTdWJqZWN0OiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5l dC1hcmNoaXRlY3R1cmUtMTANCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gW0VYVEVSTkFMIEVNQUlM XQ0KPiA+Pj4+DQo+ID4+Pj4gSGksDQo+ID4+Pj4NCj4gPj4+PiBUaGUgRGV0TmV0IGFyY2hpdGVj dHVyZSBkb2N1bWVudCBoYXMgYmVlbiB1cGRhdGVkIHRvIGFkZHJlc3MgdGhlDQo+ID4+Pj4gY29t bWVudHMuIFRoZSBuZXcgcmV2aXNpb24gKHYxMCkgaXMgYXZhaWxhYmxlIGF0DQo+ID4+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0x MC4NCj4gPj4+Pg0KPiA+Pj4+IFRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBkaXNjdXNzaW9u IGl0ZW1zIGVtYWlscyBvbiB0aGUgbGlzdC4gVGhlDQo+ID4+Pj4gdXBkYXRlcyBhcmUgYWxvbmcg dGhlIG1ham9yIGRpc2N1c3Npb24gaXRlbXMsIHdoaWNoIGFsc28gY292ZXIgdGhlDQo+ID4+Pj4g ZGVyaXZhdGl2ZSBkaXNjdXNzaW9ucywgYWRkcmVzcyB0aGUgY29tbWVudHMuDQo+ID4+Pj4NCj4g Pj4+PiBUaGUgbWFqb3IgaXRlbXMgaGF2ZSBiZWVuIHN1bW1hcml6ZWQgaW46DQo+ID4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMTk2 OC5odG1sLg0KPiA+Pj4+IEZvbGxvdyB1cCBkaXNjdXNzaW9ucyBpbXBsaWVkIHRlcm1pbm9sb2d5 IGNoYW5nZXMgc3VtbWFyaXplZCBpbjoNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2RldG5ldC9jdXJyZW50L21zZzAyMDM2Lmh0bWw6DQo+ID4+Pj4gcmVwbGFj ZSAidHJhbnNwb3J0IHN1Yi1sYXllciIgd2l0aCAiZm9yd2FyZGluZyBzdWItbGF5ZXIiDQo+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9t c2cwMjAzOC5odG1sOg0KPiA+Pj4+IHJlcGxhY2UgImNvbmdlc3Rpb24gcHJvdGVjdGlvbiIgd2l0 aCAicmVzb3VyY2UiIGFsbG9jYXRpb24iDQo+ID4+Pj4gQ29uc2VxdWVudGx5LCB0aGUgZG9jdW1l bnQgaGFkIGEgZ29vZCAnc2N1cmIiLg0KPiA+Pj4+DQo+ID4+Pj4gSW4gYWRkaXRpb24sIG91dHN0 YW5kaW5nIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYWxvbmcNCj4gPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RldG5ldC9jdXJyZW50L21zZzAxOTQzLmh0 bWwuDQo+ID4+Pj4NCj4gPj4+PiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGNvbW1lbnQgaGFw cGVuZWQgdG8gYmUgcmVtYWluZWQgb3Blbi4NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywN Cj4gPj4+PiBKYW5vcw0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4+Pj4g ZGV0bmV0QGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kZXRuZXQNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4+PiBkZXRuZXRAaWV0Zi5v cmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+ ID4+Pg0K From nobody Mon Jan 7 07:54:17 2019 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 A88AD126CC7 for ; Mon, 7 Jan 2019 07:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.566 X-Spam-Level: X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 Ed1VMuBEvWuv for ; Mon, 7 Jan 2019 07:54:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CCF130E68 for ; Mon, 7 Jan 2019 07:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8334; q=dns/txt; s=iport; t=1546876451; x=1548086051; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dyVuf9+1hbw5WIb4LvIkLy1gVHBWG+pRDqxvxRFjwiI=; b=lB3MXJ5fCE3xRh5TnwvS8FJ5Z2+2t5LAR8bgXolgF2eF7DVhh5tqqcww 3XNik++qirimPTm5oIE1YEzI1HSnlcQLc6uM9ll9dOzu4yZwImNWRmlOD Lan3WKyR5XX+WpGRuXxUVA8ri5VzGeLe+8EdzK6Zb3nH8AScYp38I44A0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAD8dDNc/4gNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCoN1iBqLZoINl24UgWcLAQE?= =?us-ascii?q?YDYQBRgIXgW0iNAkNAQMBAQIBAQJtHAyFSgEBAQQBASEROhcEAgEIDgMBAwE?= =?us-ascii?q?BAQICIwMCAgIlCxQBAgYIAgQBEgiDG4IBD6YkgS+EAgEuAoVqBYELizQXgUA?= =?us-ascii?q?/gRGCFH6DHgEBAQEBgSsBEQIBJRAjgk6CVwKJUpgKCQKHEopVIIFghSOKbIl?= =?us-ascii?q?ihQWLLwIRFIEnHzhlcXAVO4JshQKGG4UIATZBMQGJYIEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,451,1539648000"; d="scan'208";a="506045607" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 15:54:10 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x07FsA7x003459 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Jan 2019 15:54:10 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; Mon, 7 Jan 2019 09:54:09 -0600 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, 7 Jan 2019 09:54:09 -0600 From: "Pascal Thubert (pthubert)" To: Lou Berger , Norman Finn , "Black, David" , =?utf-8?B?SsOhbm9zIEZhcmthcw==?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUpnmH2a5F1EenOkimumZNuZjfBqWj9JaQ Date: Mon, 7 Jan 2019 15:53:47 +0000 Deferred-Delivery: Mon, 7 Jan 2019 15:53:28 +0000 Message-ID: References: , <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com> <16828014758.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <16828014758.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 15:54:15 -0000 SGVsbG8gTG91Og0KDQpJIGNhbiBidXkgbm90IHVzaW5nIHVwcGVyY2FzZTsgdGhlIHN0YW5kYXJk IHNuaXBwZXQgaXMgc3RpbGwgdXNlZnVsIGV2ZW4gd2hlbiB0aGVyZSBhcmUgbm9uZSBhY3R1YWxs eS4gVGhpcyBpcyBob3cgSSB3cm90ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi02dGlzY2gtYXJjaGl0ZWN0dXJlLTE5I3NlY3Rpb24tMi4xIA0KDQpUYWtlIGNhcmUsDQoN ClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRldG5ldCA8 ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+IFNlbnQ6 IGx1bmRpIDcgamFudmllciAyMDE5IDEyOjEwDQo+IFRvOiBOb3JtYW4gRmlubiA8bm9ybWFuLmZp bm5AbWFpbDAxLmh1YXdlaS5jb20+OyBCbGFjaywgRGF2aWQNCj4gPERhdmlkLkJsYWNrQGRlbGwu Y29tPjsgSsOhbm9zIEZhcmthcyA8amFub3MuZmFya2FzQGVyaWNzc29uLmNvbT47IERldE5ldA0K PiBXRyA8ZGV0bmV0QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0 Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwDQo+IA0KPiBOb3JtIChQYXNjYWwpLA0KPiANCj4gUGxl YXNlIHNlZSBteSByZXNwb25zZSB0byBEYXZpZCAtLSB3cnQgdG8gKm5vdCogaW50cm9kdWNpbmcg Y2FwaXRhbGl6YXRpb24gaW4NCj4gdGhpcyBjYXNlL2RvY3VtZW50Lg0KPiANCj4gTG91DQo+IA0K PiANCj4gLS0tLS0tLS0tLQ0KPiBPbiBKYW51YXJ5IDcsIDIwMTkgMToyNzozMSBBTSBOb3JtYW4g Rmlubg0KPiA8bm9ybWFuLmZpbm5AbWFpbDAxLmh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiANCj4g PiBJJ20gZ29vZCB3aXRoIGEgU0hPVUxEIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgMy4zLjIu DQo+ID4NCj4gPiAtLSBOb3JtDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IEZyb206IGRldG5ldCBbZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJl aGFsZiBvZiBCbGFjaywgRGF2aWQNCj4gPiBbRGF2aWQuQmxhY2tAZGVsbC5jb21dDQo+ID4gU2Vu dDogV2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxOCA5OjM3IEFNDQo+ID4gVG86IErDoW5vcyBG YXJrYXM7IERldE5ldCBXRw0KPiA+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRl dG5ldC1hcmNoaXRlY3R1cmUtMTANCj4gPg0KPiA+IEphbm9zLA0KPiA+DQo+ID4gVGhlIHRlcm1p bm9sb2d5IGlzIGRlZmluaXRlbHkgaW1wcm92ZWQgLSB0aGUgcmVzdWx0aW5nIGRyYWZ0IGlzIG11 Y2gNCj4gPiBjbGVhcmVyIC0gbWFueSB0aGFua3MgdG8geW91IGFuZCB0aGUgYXV0aG9ycyBmb3Ig ZG9pbmcgdGhhdC4NCj4gPg0KPiA+IFdoZXJlIGRvIHdlIHN0YW5kIG9uIHRoZSBjb25jZXJuIGFi b3V0IHByb3RlY3RpbmcgZXh0ZXJuYWwgbm9uLURldE5ldA0KPiA+IG5ldHdvcmtzIGZyb20gRGV0 TmV0IGZsb3dzIHRoYXQgZXNjYXBlIGEgRGV0TmV0IG5ldHdvcmssIGUuZy4sIGR1ZSB0bw0KPiA+ IGFuIGVycm9uZW91cyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gY2hhbmdlPw0KPiA+DQo+ID4gTXkg Y3VycmVudCB2aWV3cyBhcmUgLi4uDQo+ID4NCj4gPiBUaGVyZSdzIG5vIHRocm90dGxpbmcgaW4g RGV0TmV0LCBlLmcuLCB0aGlzIHRleHQgaW4gNC4zLjI6DQo+ID4NCj4gPiAgICBUaGVyZSBpcyBu byBwcm92aXNpb24gaW4gRGV0TmV0IGZvciB0aHJvdHRsaW5nIERldE5ldCBmbG93cywgaS5lLiwN Cj4gPiAgICB0aGUgdHJhbnNtaXNzaW9uIHJhdGUgY2Fubm90IGJlIHJlZHVjZWQgdmlhIGV4cGxp Y2l0IGNvbmdlc3Rpb24NCj4gPiAgICBub3RpZmljYXRpb24gW1JGQzMxNjhdLiAgVGhlIGFzc3Vt cHRpb24gaXMgdGhhdCBhIERldE5ldCBmbG93LCB0byBiZQ0KPiA+ICAgIHVzZWZ1bCwgbXVzdCBi ZSBkZWxpdmVyZWQgaW4gaXRzIGVudGlyZXR5Lg0KPiA+DQo+ID4gYW5kIG5vIGFzc3VyYW5jZSB0 aGF0IGFsbCBEZXROZXQtdXNpbmcgYXBwbGljYXRpb25zIHdpbGwgY2Vhc2UgYW5kDQo+ID4gZGVz aXN0IGluIHRoZSBmYWNlIG9mIHBhY2tldCBkcm9wcyB0aGF0IGluZGljYXRlIGNvbmdlc3Rpb24u DQo+ID4NCj4gPiBQYWNrZXQgUmVwbGljYXRpb24gYW5kIEVsaW1pbmF0aW9uIG1ha2VzIHRoaXMg d29yc2UgdmlhIGl0cyBhYmlsaXR5IHRvDQo+ID4gaGlkZSBuZXR3b3JrIHBhY2tldCBkcm9wcyBh bmQgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBmcm9tIGVuZHBvaW50cywNCj4gPiBlLmcuLCBvZiB0 aG9zZSBkcm9wcyBhbmQvb3IgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBvY2N1ciBvbiBvbmx5IG9u ZQ0KPiA+IG9mIHRoZSBwYXRocyB1c2VkIGJ5IHJlcGxpY2F0ZWQgcGFja2V0cy4NCj4gPg0KPiA+ IFRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzLjMuMiBpcyBhIGdvb2Qgc3RhcnQsIGJ1 dCBJIHRoaW5rIGl0cw0KPiA+IGxvd2VyIGNhc2UgInNob3VsZCIgaXMgdG9vIHdlYWs6DQo+ID4N Cj4gPiAgICBSb2J1c3QgcmVhbC10aW1lIHN5c3RlbXMgcmVxdWlyZSB0byByZWR1Y2UgdGhlIG51 bWJlciBvZiBwb3NzaWJsZQ0KPiA+ICAgIGZhaWx1cmVzLiAgRmlsdGVycyBhbmQgcG9saWNlcnMg c2hvdWxkIGJlIHVzZWQgaW4gYSBEZXROZXQgbmV0d29yayB0bw0KPiA+ICAgIGRldGVjdCBpZiBE ZXROZXQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gdGhlIHdyb25nIGludGVyZmFjZSwgb3IgYXQN Cj4gPiAgICB0aGUgd3JvbmcgdGltZSwgb3IgaW4gdG9vIGdyZWF0IGEgdm9sdW1lLiAgRnVydGhl cm1vcmUsIGZpbHRlcnMgYW5kDQo+ID4gICAgcG9saWNlcnMgY2FuIHRha2UgYWN0aW9ucyB0byBk aXNjYXJkIHRoZSBvZmZlbmRpbmcgcGFja2V0cyBvciBmbG93cywNCj4gPiAgICBvciB0cmlnZ2Vy IHNodXR0aW5nIGRvd24gdGhlIG9mZmVuZGluZyBmbG93IG9yIHRoZSBvZmZlbmRpbmcNCj4gPiAg ICBpbnRlcmZhY2UuDQo+ID4NCj4gPiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgdGhhdCB0aGUgcmVx dWlyZW1lbnQgdG8gZGlzY2FyZCBEZXROZXQgdHJhZmZpYw0KPiA+IHRoYXQgd291bGQgb3RoZXJ3 aXNlIGVzY2FwZSBhIERldE5ldCBuZXR3b3JrIGhhcyB0byBiZSBzdGF0ZWQgYXMgYQ0KPiA+ICJN VVNUIiByZXF1aXJlbWVudCBmb3IgYW55IERldE5ldCBuZXR3b3JrIHRoYXQgc3VwcG9ydHMgUGFj a2V0DQo+ID4gUmVwbGljYXRpb24gYW5kIEVsaW1pbmF0aW9uIGR1ZSB0byB0aGUgYWJpbGl0eSBv ZiB0aGF0IGZ1bmN0aW9uYWxpdHkNCj4gPiB0byBoaWRlIGNvbmdlc3Rpb24gZnJvbSBlbmRwb2lu dHMsIG1ha2luZyBpdCBpbXBvc3NpYmxlIGZvciBoaWdoZXINCj4gPiBsYXllcnMgb2YgdGhlIHBy b3RvY29sIHN0YWNrIHRvIHJlc3BvbmQuDQo+ID4NCj4gPiBCZXlvbmQgdGhpcywgSSB0aGluayBh ICJTSE9VTEQiIHJlcXVpcmVtZW50IHRvIGRpc2NhcmQgRGV0TmV0IHRyYWZmaWMNCj4gPiB0aGF0 IHdvdWxkIG90aGVyd2lzZSBlc2NhcGUgaXMgbmVlZGVkLCBhbmQgdGhlIHN0YXRlbWVudCBvZiB0 aGF0DQo+ID4gcmVxdWlyZW1lbnQgb3VnaHQgdG8gYmUgY29ubmVjdGVkIHRvIHRoZSBleHBsYW5h dGlvbiBvZiBob3cgdG8NCj4gPiBpbXBsZW1lbnQgdGhhdCByZXF1aXJlbWVudC4gIFRoZSB0ZXh0 IGluIFNlY3Rpb24gMy4zLjIgaGFzIGEgbG90IG9mDQo+ID4gdGhlIGNvbnRlbnQgbmVlZGVkIC0g Zm9yIGEgd29ya2VkIGV4YW1wbGUgb2Ygc3VjaCAiU0hPVUxEIiB0ZXh0LCBzZWUNCj4gPiBTZWN0 aW9uIDUgb2YgUkZDIDc1MTAsIGluIHBhcnRpY3VsYXIgdGhlIGl0ZW1pemVkIGxpc3QgYXQgdGhl IGVuZCBvZg0KPiA+IHRoYXQgc2VjdGlvbiBhbmQgdGhlIHBhcmFncmFwaCB0aGF0IGludHJvZHVj ZXMgdGhhdCBsaXN0Og0KPiA+ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTEw I3NlY3Rpb24tNQ0KPiA+DQo+ID4gVGhhbmtzLCAtLURhdmlkDQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogZGV0bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKw6Fub3MNCj4gPj4gRmFya2FzDQo+ID4+IFNlbnQ6 IFdlZG5lc2RheSwgRGVjZW1iZXIgMTksIDIwMTggMTA6NTQgQU0NCj4gPj4gVG86IERldE5ldCBX Rw0KPiA+PiBTdWJqZWN0OiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUt MTANCj4gPj4NCj4gPj4NCj4gPj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiA+Pg0KPiA+PiBIaSwNCj4g Pj4NCj4gPj4gVGhlIERldE5ldCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaGFzIGJlZW4gdXBkYXRl ZCB0byBhZGRyZXNzIHRoZQ0KPiA+PiBjb21tZW50cy4gVGhlIG5ldyByZXZpc2lvbiAodjEwKSBp cyBhdmFpbGFibGUgYXQNCj4gPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMC4NCj4gPj4NCj4gPj4gVGhlcmUgaGF2ZSBiZWVuIGEg bnVtYmVyIG9mIGRpc2N1c3Npb24gaXRlbXMgZW1haWxzIG9uIHRoZSBsaXN0LiBUaGUNCj4gPj4g dXBkYXRlcyBhcmUgYWxvbmcgdGhlIG1ham9yIGRpc2N1c3Npb24gaXRlbXMsIHdoaWNoIGFsc28g Y292ZXIgdGhlDQo+ID4+IGRlcml2YXRpdmUgZGlzY3Vzc2lvbnMsIGFkZHJlc3MgdGhlIGNvbW1l bnRzLg0KPiA+Pg0KPiA+PiBUaGUgbWFqb3IgaXRlbXMgaGF2ZSBiZWVuIHN1bW1hcml6ZWQgaW46 DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJl bnQvbXNnMDE5NjguaHRtbC4NCj4gPj4gRm9sbG93IHVwIGRpc2N1c3Npb25zIGltcGxpZWQgdGVy bWlub2xvZ3kgY2hhbmdlcyBzdW1tYXJpemVkIGluOg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2RldG5ldC9jdXJyZW50L21zZzAyMDM2Lmh0bWw6DQo+ID4+IHJl cGxhY2UgInRyYW5zcG9ydCBzdWItbGF5ZXIiIHdpdGggImZvcndhcmRpbmcgc3ViLWxheWVyIg0K PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RldG5ldC9jdXJyZW50 L21zZzAyMDM4Lmh0bWw6DQo+ID4+IHJlcGxhY2UgImNvbmdlc3Rpb24gcHJvdGVjdGlvbiIgd2l0 aCAicmVzb3VyY2UiIGFsbG9jYXRpb24iDQo+ID4+IENvbnNlcXVlbnRseSwgdGhlIGRvY3VtZW50 IGhhZCBhIGdvb2QgJ3NjdXJiIi4NCj4gPj4NCj4gPj4gSW4gYWRkaXRpb24sIG91dHN0YW5kaW5n IGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYWxvbmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMTk0My5odG1sLg0KPiA+ Pg0KPiA+PiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGNvbW1lbnQgaGFwcGVuZWQgdG8gYmUg cmVtYWluZWQgb3Blbi4NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+PiBKYW5vcw0KPiA+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4+IGRldG5ldEBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkZXRuZXQgbWFp bGluZyBsaXN0DQo+ID4gZGV0bmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPiA+IGRl dG5ldEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGV0bmV0DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+IGRldG5ldEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0K From nobody Mon Jan 7 13:49:35 2019 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 AA5CF12D7F8 for ; Mon, 7 Jan 2019 13:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-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 hqN1aMb6u9o6 for ; Mon, 7 Jan 2019 13:49:30 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 EC4BA12D4F0 for ; Mon, 7 Jan 2019 13:49:29 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 5C6F3215D60 for ; Mon, 7 Jan 2019 14:49:24 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id gclwg9tMru4p1gclwgZcpZ; Mon, 07 Jan 2019 14:49:24 -0700 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:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=wt38ueiGZ10l5+kmezPFscvipxGGB2MGtw2A1cKs+/8=; b=l0noy1LWEti9wJGGxRBl1+omUk IcnHe0QNbg34OO8RSIUk7PoiU8GfbZg42F5Berba9qnb6CFrNspbbXrVI2qbEmEc7dyST6DMKnwzG iqzKzPW0a9WU8L3+80A16eBkD; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:38242 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1ggclw-000AFN-2I; Mon, 07 Jan 2019 14:49:24 -0700 To: "Black, David" , =?UTF-8?Q?J=c3=a1nos_Farkas?= , DetNet WG References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> From: Lou Berger Message-ID: Date: Mon, 7 Jan 2019 16:49:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.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-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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1ggclw-000AFN-2I X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:38242 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 21:49:33 -0000 David,     This looks good/right to me.  The only specific change I'd add is to clarify that we're talking PEROF traffic when saying "DetNet replicated traffic". Thanks! Lou On 1/7/2019 10:44 AM, Black, David wrote: > Lou, > > Attempting to summarize what needs to be stated without using MUST/SHOULD/MAY: > > [1] Sending DetNet traffic into networks that have not been provisioned in advance to handle that DetNet traffic has to be treated as a fault. Egress traffic filters to prevent this from happening are strongly recommended at the edges of a DetNet networks and DetNet supporting networks. In this context, the term 'provisioned' has a broad meaning, e.g., provisioning could be performed via an administrative decision that the downstream network has the available capacity to carry the DetNet traffic that is being sent into it. > > [2] Sending non-congestion-controlled DetNet traffic (i.e., DetNet traffic that does not comply with BCP 41/RFC 2914) into a network that is not provisioned to handle that traffic has to be prevented in addition to being treated as a fault. DetNet traffic that is not known to be congestion controlled has to be treated as non-congestion-controlled DetNet traffic for this requirement. DetNet replicated traffic is always non-congestion-controlled even if the original DetNet flow is congestion-controlled because DetNet packet elimination can hide congestion indications (e.g., drops, ECN CE marks, increased latency) from endpoints. The responsibility for dealing with these requirements in general, and replicated traffic in particular, is solution-specific, as there are MPLS mechanisms that cannot be applied to the IP solution, and moreover, the current IP solution doesn't support DetNet traffic replication. > > Thanks, --David > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, December 25, 2018 11:45 AM >> To: Black, David; János Farkas; DetNet WG >> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 >> >> >> [EXTERNAL EMAIL] >> >> Hi David, >> >> On 12/24/2018 8:29 PM, Black, David wrote: >>> Hi Lou, >>> >>> Excerpting key paragraphs ... >>> >>>> To me clear, you are suggesting that text be added to say that sending >>>> detnet traffic out a non-detnet interfaces must be treated as a fault. >>>> Is this correct? >>> Not exactly ... >>> >>>> If so, I think this is too broad considering that >>>> there are networks that can provided the required detnet forwarding >>>> sub-layer service that are not detnet service aware as is mentioned at >>>> the end of section 4.3.2. (I'll refer to such as "DetNet supporting >>>> networks" in the next paragraph.) >>> I agree with where this is headed - sending DetNet traffic into a network >>> that has not been provisioned to provide the required detnet forwarding >>> service to that traffic has to be treated as a fault. In this statement, >>> "provisioned" should be read broadly, e.g., it could be realized via an >>> administrative decision that the DetNet supporting network has the >>> available capacity to carry the DetNet traffic that is being sent into it. >> agreed. >>>> This said, I think it would be reasonable to make it a requirement that >>>> DetNet nodes must not forward traffic that doesn't conform with BCP41 >>>> over a network that is neither a Detnet network or a DetNet supporting >>>> network. Although this would require a change to the DetNet service >>>> model, i.e., to know which traffic was conformant/non-conformant. >>> That's fine with one important twist: >>> >>> Any traffic that has been replicated by DetNet packet replication has to >>> be treated as not conforming with BCP41 because DetNet packet >>> elimination (of replicated packets) may hide congestion indications >>> (e.g., delay, ECN CE marks, drops) from the endpoints - a scenario of >>> particular concern involves the other flow of replicated packets >>> following a DetNet network path along which nothing goes wrong. >>> BCP41 is about end-to-end-congestion control, which does not do >>> anything if DetNet packet elimination hides congestion indications >>> from the endpoints. >> This seems reasonable to me. >> >> >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet traffic >>>>> that would otherwise escape is needed, and the statement of that >>>>> requirement ought to be connected to the explanation of how to >>>>> implement that requirement. >>>> I think adding a statement on output filters (and policers) to this >>>> section is reasonable. >>> Let's start with the inclusion of output filters (and policers) in the 3.3.2 >>> text with the use of upper-case "SHOULD" as suggested by Pascal - I will >>> look this over and suggest any additional text that I think ought to be >>> included. >> As an architecture document, the authors/WG made the call to not use >> conformance capitalization or reference 2119/8174.  I think this >> translates to the conformance language needing to be added to the data >> plane solution documents. >> >> Cheers, >> >> Lou >> >> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Monday, December 24, 2018 3:18 PM >>>> To: Black, David; János Farkas; DetNet WG >>>> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 >>>> >>>> >>>> [EXTERNAL EMAIL] >>>> >>>> Hi David, >>>> >>>> On 12/19/2018 12:37 PM, Black, David wrote: >>>>> Janos, >>>>> >>>>> The terminology is definitely improved - the resulting draft is much >>>>> clearer - many thanks to you and the authors for doing that. >>>> Happy to hear that. >>>> >>>> >>>>> Where do we stand on the concern about protecting external >>>>> non-DetNet networks from DetNet flows that escape a DetNet >>>>> network, e.g., due to an erroneous network configuration change? >>>> I'm not sure we have general solutions in the internet architecture for >>>> miss-configured/buggy systems other than dropping the packets on the >>>> floor (e.g., due to no route, no label, or ttl expiry).  What type of >>>> protection are you looking for here, and can you provide a reference to >>>> the type of router behavior you would like to see?  I have a suggestion >>>> that might address your concern below elated to non-BCP41 conformant >>>> traffic, but am unsure if this is what you are concerned about. >>>> >>>>> My current views are ... >>>>> >>>>> There's no throttling in DetNet, e.g., this text in 4.3.2: >>>>> >>>>> There is no provision in DetNet for throttling DetNet flows, i.e., >>>>> the transmission rate cannot be reduced via explicit congestion >>>>> notification [RFC3168]. The assumption is that a DetNet flow, to be >>>>> useful, must be delivered in its entirety. >>>> Well looking at it this way, there is no throttling in any IP network as >>>> the routers generate the CN and only drop when their queues are full or >>>> implementing some sort of RED. >>>> >>>> In DetNet there is an expectation that intermediate nodes do more than >>>> this.  Specifically, see section 4.5: "Queuing, Shaping, Scheduling, and >>>> Preemption" and policing, which is mentioned as requirement in section >>>> 3.3.1. >>>> >>>>> and no assurance that all DetNet-using applications will cease and desist >>>>> in the face of packet drops that indicate congestion. >>>> I think this is correct. >>>> >>>> >>>>> Packet Replication and Elimination makes this worse via its ability to hide >>>>> network packet drops and congestion indications from endpoints, e.g., >>>>> of those drops and/or congestion indications occur on only one of >>>>> the paths used by replicated packets. >>>>> >>>>> The first paragraph in section 3.3.2 is a good start, but I think its lower >>>>> case "should" is too weak: >>>>> >>>>> 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 a volume. Furthermore, filters and >>>>> policers can take actions to discard the offending packets or flows, >>>>> or trigger shutting down the offending flow or the offending >>>>> interface. >>>>> >>>>> At a minimum, I think that the requirement to discard DetNet traffic >>>>> that would otherwise escape a DetNet network has to be stated as >>>>> a "MUST" requirement for any DetNet network that supports Packet >>>>> Replication and Elimination due to the ability of that functionality >>>>> to hide congestion from endpoints, making it impossible for higher >>>>> layers of the protocol stack to respond. >>>> To me clear, your are suggesting that text be added to say that sending >>>> detnet traffic out a non-detnet interfaces must be treated as a fault. >>>> Is this correct?  If so, I think this is too broad considering that >>>> there are networks that can provided the required detnet forwarding >>>> sub-layer service that are not detnet service aware as is mentioned at >>>> the end of section 4.3.2. (I'll refer to such as "DetNet supporting >>>> networks" in the next paragraph.) >>>> >>>> This said, I think it would be reasonable to make it a requirement that >>>> DetNet nodes must not forward traffic that doesn't conform with BCP41 >>>> over a network that is neither a Detnet network or a DetNet supporting >>>> network.  Although this would require a change to the DetNet service >>>> model, i.e.,  to know which traffic was conformant/non-conformant. >>>> >>>> >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet traffic >>>>> that would otherwise escape is needed, and the statement of that >>>>> requirement ought to be connected to the explanation of how to >>>>> implement that requirement. >>>> I think adding a statement on output filters (and policiers) to this >>>> section is reasonable. >>>> >>>> >>>>> The text in Section 3.3.2 has a lot of >>>>> the content needed - for a worked example of such "SHOULD" text, >>>>> see Section 5 of RFC 7510, in particular the itemized list at the end of >>>>> that section and the paragraph that introduces that list: >>>>> https://tools.ietf.org/html/rfc7510#section-5 >>>> If I'm not mistaken, such mechanisms are already included in the >>>> document and you really are just asking them to be (re)listed to ensure >>>> that this import point isn't missed.  Is this correct? Besides what is >>>> mentioned above, is there anything else missing? >>>> >>>> Thanks! >>>> >>>> Lou >>>> >>>>> Thanks, --David >>>>> >>>>>> -----Original Message----- >>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of János Farkas >>>>>> Sent: Wednesday, December 19, 2018 10:54 AM >>>>>> To: DetNet WG >>>>>> Subject: [Detnet] draft-ietf-detnet-architecture-10 >>>>>> >>>>>> >>>>>> [EXTERNAL EMAIL] >>>>>> >>>>>> Hi, >>>>>> >>>>>> The DetNet architecture document has been updated to address the >>>>>> comments. The new revision (v10) is available at >>>>>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. >>>>>> >>>>>> There have been a number of discussion items emails on the list. The >>>>>> updates are along the major discussion items, which also cover the >>>>>> derivative discussions, address the comments. >>>>>> >>>>>> The major items have been summarized in: >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. >>>>>> Follow up discussions implied terminology changes summarized in: >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: >>>>>> replace "transport sub-layer" with "forwarding sub-layer" >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: >>>>>> replace "congestion protection" with "resource" allocation" >>>>>> Consequently, the document had a good 'scurb". >>>>>> >>>>>> In addition, outstanding comments have been addressed along >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. >>>>>> >>>>>> Please let us know if any comment happened to be remained open. >>>>>> >>>>>> Best 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 >>>>> From nobody Mon Jan 7 14:35:22 2019 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 444C012E04D for ; Mon, 7 Jan 2019 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 EZ7gv5nf-_1z for ; Mon, 7 Jan 2019 14:35:18 -0800 (PST) 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 D109F12DDA3 for ; Mon, 7 Jan 2019 14:35:17 -0800 (PST) Received: from lhrpml402-hub.exmail.huawei.com (unknown [172.18.7.66]) by Forcepoint Email with ESMTP id D4D59196DC7F50A406C0; Mon, 7 Jan 2019 22:35:14 +0000 (GMT) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.41]) by lhrpml402-hub.exmail.huawei.com ([10.201.4.206]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 22:35:09 +0000 From: Norman Finn To: Lou Berger , "Black, David" , =?iso-8859-1?Q?J=E1nos_Farkas?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7Ma4C0tH7nm20uUTxpPIscWq6WGU60AgB0ZkxCAAFZogIAAvvur Date: Mon, 7 Jan 2019 22:35:08 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F801720FA9@lhrpml504-mbx.exmail.huawei.com> References: , <3DF0466E9510274382F5B74499ACD6F801720EBD@lhrpml504-mbx.exmail.huawei.com>, <16828014758.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <16828014758.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 07 Jan 2019 22:35:20 -0000 Thanks. I missed that one. I'm also good with not adding a SHOULD.=0A= =0A= -- Norm=0A= =0A= ________________________________________=0A= From: Lou Berger [lberger@labn.net]=0A= Sent: Monday, January 07, 2019 3:09 AM=0A= To: Norman Finn; Black, David; J=E1nos Farkas; DetNet WG=0A= Subject: Re: [Detnet] draft-ietf-detnet-architecture-10=0A= =0A= Norm (Pascal),=0A= =0A= Please see my response to David -- wrt to *not* introducing capitalization= =0A= in this case/document.=0A= =0A= Lou=0A= =0A= =0A= ----------=0A= On January 7, 2019 1:27:31 AM Norman Finn = =0A= wrote:=0A= =0A= > I'm good with a SHOULD in the first paragraph of 3.3.2.=0A= >=0A= > -- Norm=0A= > ________________________________________=0A= > From: detnet [detnet-bounces@ietf.org] on behalf of Black, David=0A= > [David.Black@dell.com]=0A= > Sent: Wednesday, December 19, 2018 9:37 AM=0A= > To: J=E1nos Farkas; DetNet WG=0A= > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10=0A= >=0A= > Janos,=0A= >=0A= > The terminology is definitely improved - the resulting draft is much=0A= > clearer - many thanks to you and the authors for doing that.=0A= >=0A= > Where do we stand on the concern about protecting external=0A= > non-DetNet networks from DetNet flows that escape a DetNet=0A= > network, e.g., due to an erroneous network configuration change?=0A= >=0A= > My current views are ...=0A= >=0A= > There's no throttling in DetNet, e.g., this text in 4.3.2:=0A= >=0A= > There is no provision in DetNet for throttling DetNet flows, i.e.,=0A= > the transmission rate cannot be reduced via explicit congestion=0A= > notification [RFC3168]. The assumption is that a DetNet flow, to be= =0A= > useful, must be delivered in its entirety.=0A= >=0A= > and no assurance that all DetNet-using applications will cease and desist= =0A= > in the face of packet drops that indicate congestion.=0A= >=0A= > Packet Replication and Elimination makes this worse via its ability to hi= de=0A= > network packet drops and congestion indications from endpoints, e.g.,=0A= > of those drops and/or congestion indications occur on only one of=0A= > the paths used by replicated packets.=0A= >=0A= > The first paragraph in section 3.3.2 is a good start, but I think its low= er=0A= > case "should" is too weak:=0A= >=0A= > Robust real-time systems require to reduce the number of possible=0A= > failures. Filters and policers should be used in a DetNet network to= =0A= > detect if DetNet packets are received on the wrong interface, or at=0A= > the wrong time, or in too great a volume. Furthermore, filters and=0A= > policers can take actions to discard the offending packets or flows,= =0A= > or trigger shutting down the offending flow or the offending=0A= > interface.=0A= >=0A= > At a minimum, I think that the requirement to discard DetNet traffic=0A= > that would otherwise escape a DetNet network has to be stated as=0A= > a "MUST" requirement for any DetNet network that supports Packet=0A= > Replication and Elimination due to the ability of that functionality=0A= > to hide congestion from endpoints, making it impossible for higher=0A= > layers of the protocol stack to respond.=0A= >=0A= > Beyond this, I think a "SHOULD" requirement to discard DetNet traffic=0A= > that would otherwise escape is needed, and the statement of that=0A= > requirement ought to be connected to the explanation of how to=0A= > implement that requirement. The text in Section 3.3.2 has a lot of=0A= > the content needed - for a worked example of such "SHOULD" text,=0A= > see Section 5 of RFC 7510, in particular the itemized list at the end of= =0A= > that section and the paragraph that introduces that list:=0A= > https://tools.ietf.org/html/rfc7510#section-5=0A= >=0A= > Thanks, --David=0A= >=0A= >> -----Original Message-----=0A= >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of J=E1nos Farka= s=0A= >> Sent: Wednesday, December 19, 2018 10:54 AM=0A= >> To: DetNet WG=0A= >> Subject: [Detnet] draft-ietf-detnet-architecture-10=0A= >>=0A= >>=0A= >> [EXTERNAL EMAIL]=0A= >>=0A= >> Hi,=0A= >>=0A= >> The DetNet architecture document has been updated to address the=0A= >> comments. The new revision (v10) is available at=0A= >> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10.=0A= >>=0A= >> There have been a number of discussion items emails on the list. The=0A= >> updates are along the major discussion items, which also cover the=0A= >> derivative discussions, address the comments.=0A= >>=0A= >> The major items have been summarized in:=0A= >> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html.=0A= >> Follow up discussions implied terminology changes summarized in:=0A= >> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html:=0A= >> replace "transport sub-layer" with "forwarding sub-layer"=0A= >> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html:=0A= >> replace "congestion protection" with "resource" allocation"=0A= >> Consequently, the document had a good 'scurb".=0A= >>=0A= >> In addition, outstanding comments have been addressed along=0A= >> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html.=0A= >>=0A= >> Please let us know if any comment happened to be remained open.=0A= >>=0A= >> Best regards,=0A= >> Janos=0A= >>=0A= >> _______________________________________________=0A= >> detnet mailing list=0A= >> detnet@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/detnet=0A= >=0A= > _______________________________________________=0A= > detnet mailing list=0A= > detnet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/detnet=0A= >=0A= > _______________________________________________=0A= > detnet mailing list=0A= > detnet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/detnet=0A= >=0A= =0A= =0A= From nobody Tue Jan 8 09:46:37 2019 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 F2C3A130F27 for ; Tue, 8 Jan 2019 09:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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=dell.com header.b=AoFOmmiU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=SURhJfBA 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 Xdp6VIQ2KTHA for ; Tue, 8 Jan 2019 09:46:31 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 B03DD130F26 for ; Tue, 8 Jan 2019 09:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1546969591; x=1578505591; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qol1aM+Fhm1vo/Zh1QjsLPOM4IJ6poau5FCQt84bpdA=; b=AoFOmmiUJeYGoyJjomRKr7INbsDXfsn2FFsZFSod9elWY+h35K2Ykke2 qhfP6cJD46mniB3hrasNHznpRnfJ4p8LcRHVi+uCjvrpFYBGVV8vJNlWN NpnoipAyX24OdvoxY4XJ3M954vTphjguP0qH+Jha1csYObq7zEHjMSSQK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EAAAAX4TRchiWd50NjGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBMIE5gQInCoN2iBpfiw2CDZdxFIErPAsBARg?= =?us-ascii?q?LC4N4RgIXgXwiNAkNAQMBAQIBAQIBAQIQAQEBEwsIKSMMgjopARQxHC8JBgE?= =?us-ascii?q?BAQEBAScBAQEBAQEBAQEBAQEBAQEBAQEXAkMBEgEBGAEBAQEDAQEQEREMHw8?= =?us-ascii?q?MCwQCAQgOAwEDAQEBAgIGHQMCAgIlCxQBAgYIAgQBEggTB4MAAYIBAQ6cAz0?= =?us-ascii?q?CgW6JBgEBAW6BL4J9gTQChXUDBYELizSBWD6BEUaBTn6DHgEBAQEBgSsBEQI?= =?us-ascii?q?BIBWCcTGCJolRmBgDBAIChxaKeIFjhSSDM4c7iWqFAQeLNQIEAgQFAhSBRjd?= =?us-ascii?q?ncXBQgmyCJw4Jg0uFFIU/QTEBiXiBHwEB?= X-IPAS-Result: =?us-ascii?q?A2EAAAAX4TRchiWd50NjGgEBAQEBAgEBAQEHAgEBAQGBU?= =?us-ascii?q?QUBAQEBCwGBMIE5gQInCoN2iBpfiw2CDZdxFIErPAsBARgLC4N4RgIXgXwiN?= =?us-ascii?q?AkNAQMBAQIBAQIBAQIQAQEBEwsIKSMMgjopARQxHC8JBgEBAQEBAScBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEXAkMBEgEBGAEBAQEDAQEQEREMHw8MCwQCAQgOAwEDA?= =?us-ascii?q?QEBAgIGHQMCAgIlCxQBAgYIAgQBEggTB4MAAYIBAQ6cAz0CgW6JBgEBAW6BL?= =?us-ascii?q?4J9gTQChXUDBYELizSBWD6BEUaBTn6DHgEBAQEBgSsBEQIBIBWCcTGCJolRm?= =?us-ascii?q?BgDBAIChxaKeIFjhSSDM4c7iWqFAQeLNQIEAgQFAhSBRjdncXBQgmyCJw4Jg?= =?us-ascii?q?0uFFIU/QTEBiXiBHwEB?= Received: from mx0b-00154901.pphosted.com ([67.231.157.37]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 08 Jan 2019 11:46:29 -0600 Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x08HhKnX091517 for ; Tue, 8 Jan 2019 12:46:29 -0500 Received: from esa3.dell-outbound2.iphmx.com (esa3.dell-outbound2.iphmx.com [68.232.154.63]) by mx0b-00154901.pphosted.com with ESMTP id 2pvv8p1nak-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 08 Jan 2019 12:46:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 08 Jan 2019 23:46:06 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x08HkMaP022788 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jan 2019 12:46:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x08HkMaP022788 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1546969586; bh=EKqjR6H4CPYZR2u9gTSuzQb82eM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SURhJfBArOE7DcFnRC2idFJZ5em4ONEIgNFnuOEypkurk4DVF8Ox6bEU0bqI0EXW6 qI7IaWF7AEW0Um9tzNh4j6mc1gHc6zdCQHcTa0GWcMTGTwTkf3ows8cVYGJW6JaFvk mauIV7sIl4COSO/NIOWzwqpA33NlPndkCQpF4rm8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x08HkMaP022788 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 8 Jan 2019 12:46:11 -0500 Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x08HkBFR002687 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 8 Jan 2019 12:46:11 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0399.000; Tue, 8 Jan 2019 12:46:10 -0500 To: Lou Berger , =?utf-8?B?SsOhbm9zIEZhcmthcw==?= , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7MQHC64vzb8fEG2yQUlzcD3VqWGSxwQgAhk5ID///4dQIABWMAAgBQC8lCAAMBOgIAA+hBw Date: Tue, 8 Jan 2019 17:46:10 +0000 Message-ID: References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound 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-1810050000 definitions=main-1901080143 Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 08 Jan 2019 17:46:35 -0000 VGhhdCdzIGZpbmUgYW5kIHdoYXQgd2FzIGludGVuZGVkLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86 bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDcsIDIwMTkgNDo0OSBQ TQ0KPiBUbzogQmxhY2ssIERhdmlkOyBKw6Fub3MgRmFya2FzOyBEZXROZXQgV0cNCj4gU3ViamVj dDogUmU6IFtEZXRuZXRdIGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMA0KPiANCj4g DQo+IFtFWFRFUk5BTCBFTUFJTF0NCj4gDQo+IERhdmlkLA0KPiANCj4gIMKgwqDCoCBUaGlzIGxv b2tzIGdvb2QvcmlnaHQgdG8gbWUuwqAgVGhlIG9ubHkgc3BlY2lmaWMgY2hhbmdlIEknZCBhZGQg aXMNCj4gdG8gY2xhcmlmeSB0aGF0IHdlJ3JlIHRhbGtpbmcgUEVST0YgdHJhZmZpYyB3aGVuIHNh eWluZyAiRGV0TmV0DQo+IHJlcGxpY2F0ZWQgdHJhZmZpYyIuDQo+IA0KPiBUaGFua3MhDQo+IA0K PiBMb3UNCj4gDQo+IE9uIDEvNy8yMDE5IDEwOjQ0IEFNLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ ID4gTG91LA0KPiA+DQo+ID4gQXR0ZW1wdGluZyB0byBzdW1tYXJpemUgd2hhdCBuZWVkcyB0byBi ZSBzdGF0ZWQgd2l0aG91dCB1c2luZw0KPiBNVVNUL1NIT1VMRC9NQVk6DQo+ID4NCj4gPiBbMV0g U2VuZGluZyBEZXROZXQgdHJhZmZpYyBpbnRvIG5ldHdvcmtzIHRoYXQgaGF2ZSBub3QgYmVlbiBw cm92aXNpb25lZCBpbg0KPiBhZHZhbmNlIHRvIGhhbmRsZSB0aGF0IERldE5ldCB0cmFmZmljIGhh cyB0byBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuICBFZ3Jlc3MNCj4gdHJhZmZpYyBmaWx0ZXJzIHRv IHByZXZlbnQgdGhpcyBmcm9tIGhhcHBlbmluZyBhcmUgc3Ryb25nbHkgcmVjb21tZW5kZWQgYXQg dGhlDQo+IGVkZ2VzIG9mIERldE5ldCBuZXR3b3JrcyBhbmQgRGV0TmV0IHN1cHBvcnRpbmcgbmV0 d29ya3MuICBJbiB0aGlzIGNvbnRleHQsDQo+IHRoZSB0ZXJtICdwcm92aXNpb25lZCcgaGFzIGEg YnJvYWQgbWVhbmluZywgZS5nLiwgcHJvdmlzaW9uaW5nIGNvdWxkIGJlDQo+IHBlcmZvcm1lZCB2 aWEgYW4gYWRtaW5pc3RyYXRpdmUgZGVjaXNpb24gdGhhdCB0aGUgZG93bnN0cmVhbSBuZXR3b3Jr IGhhcyB0aGUNCj4gYXZhaWxhYmxlIGNhcGFjaXR5IHRvIGNhcnJ5IHRoZSBEZXROZXQgdHJhZmZp YyB0aGF0IGlzIGJlaW5nIHNlbnQgaW50byBpdC4NCj4gPg0KPiA+IFsyXSBTZW5kaW5nIG5vbi1j b25nZXN0aW9uLWNvbnRyb2xsZWQgRGV0TmV0IHRyYWZmaWMgKGkuZS4sIERldE5ldCB0cmFmZmlj IHRoYXQNCj4gZG9lcyBub3QgY29tcGx5IHdpdGggQkNQIDQxL1JGQyAyOTE0KSBpbnRvIGEgbmV0 d29yayB0aGF0IGlzIG5vdCBwcm92aXNpb25lZA0KPiB0byBoYW5kbGUgdGhhdCB0cmFmZmljIGhh cyB0byBiZSBwcmV2ZW50ZWQgaW4gYWRkaXRpb24gdG8gYmVpbmcgdHJlYXRlZCBhcyBhIGZhdWx0 Lg0KPiBEZXROZXQgdHJhZmZpYyB0aGF0IGlzIG5vdCBrbm93biB0byBiZSBjb25nZXN0aW9uIGNv bnRyb2xsZWQgaGFzIHRvIGJlIHRyZWF0ZWQgYXMNCj4gbm9uLWNvbmdlc3Rpb24tY29udHJvbGxl ZCBEZXROZXQgdHJhZmZpYyBmb3IgdGhpcyByZXF1aXJlbWVudC4gIERldE5ldA0KPiByZXBsaWNh dGVkIHRyYWZmaWMgaXMgYWx3YXlzIG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgZXZlbiBpZiB0 aGUgb3JpZ2luYWwNCj4gRGV0TmV0IGZsb3cgaXMgY29uZ2VzdGlvbi1jb250cm9sbGVkIGJlY2F1 c2UgRGV0TmV0IHBhY2tldCBlbGltaW5hdGlvbiBjYW4NCj4gaGlkZSBjb25nZXN0aW9uIGluZGlj YXRpb25zIChlLmcuLCBkcm9wcywgRUNOIENFIG1hcmtzLCBpbmNyZWFzZWQgbGF0ZW5jeSkgZnJv bQ0KPiBlbmRwb2ludHMuICBUaGUgcmVzcG9uc2liaWxpdHkgZm9yIGRlYWxpbmcgd2l0aCB0aGVz ZSByZXF1aXJlbWVudHMgaW4gZ2VuZXJhbCwNCj4gYW5kIHJlcGxpY2F0ZWQgdHJhZmZpYyBpbiBw YXJ0aWN1bGFyLCBpcyBzb2x1dGlvbi1zcGVjaWZpYywgYXMgdGhlcmUgYXJlIE1QTFMNCj4gbWVj aGFuaXNtcyB0aGF0IGNhbm5vdCBiZSBhcHBsaWVkIHRvIHRoZSBJUCBzb2x1dGlvbiwgYW5kIG1v cmVvdmVyLCB0aGUNCj4gY3VycmVudCBJUCBzb2x1dGlvbiBkb2Vzbid0IHN1cHBvcnQgRGV0TmV0 IHRyYWZmaWMgcmVwbGljYXRpb24uDQo+ID4NCj4gPiBUaGFua3MsIC0tRGF2aWQNCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWls dG86bGJlcmdlckBsYWJuLm5ldF0NCj4gPj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjUsIDIw MTggMTE6NDUgQU0NCj4gPj4gVG86IEJsYWNrLCBEYXZpZDsgSsOhbm9zIEZhcmthczsgRGV0TmV0 IFdHDQo+ID4+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRl Y3R1cmUtMTANCj4gPj4NCj4gPj4NCj4gPj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiA+Pg0KPiA+PiBI aSBEYXZpZCwNCj4gPj4NCj4gPj4gT24gMTIvMjQvMjAxOCA4OjI5IFBNLCBCbGFjaywgRGF2aWQg d3JvdGU6DQo+ID4+PiBIaSBMb3UsDQo+ID4+Pg0KPiA+Pj4gRXhjZXJwdGluZyBrZXkgcGFyYWdy YXBocyAuLi4NCj4gPj4+DQo+ID4+Pj4gVG8gbWUgY2xlYXIsIHlvdSBhcmUgc3VnZ2VzdGluZyB0 aGF0IHRleHQgYmUgYWRkZWQgdG8gc2F5IHRoYXQgc2VuZGluZw0KPiA+Pj4+IGRldG5ldCB0cmFm ZmljIG91dCBhIG5vbi1kZXRuZXQgaW50ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVs dC4NCj4gPj4+PiBJcyB0aGlzIGNvcnJlY3Q/DQo+ID4+PiBOb3QgZXhhY3RseSAuLi4NCj4gPj4+ DQo+ID4+Pj4gSWYgc28sIEkgdGhpbmsgdGhpcyBpcyB0b28gYnJvYWQgY29uc2lkZXJpbmcgdGhh dA0KPiA+Pj4+IHRoZXJlIGFyZSBuZXR3b3JrcyB0aGF0IGNhbiBwcm92aWRlZCB0aGUgcmVxdWly ZWQgZGV0bmV0IGZvcndhcmRpbmcNCj4gPj4+PiBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBu b3QgZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMgaXMgbWVudGlvbmVkIGF0DQo+ID4+Pj4gdGhlIGVu ZCBvZiBzZWN0aW9uIDQuMy4yLiAoSSdsbCByZWZlciB0byBzdWNoIGFzICJEZXROZXQgc3VwcG9y dGluZw0KPiA+Pj4+IG5ldHdvcmtzIiBpbiB0aGUgbmV4dCBwYXJhZ3JhcGguKQ0KPiA+Pj4gSSBh Z3JlZSB3aXRoIHdoZXJlIHRoaXMgaXMgaGVhZGVkIC0gc2VuZGluZyBEZXROZXQgdHJhZmZpYyBp bnRvIGEgbmV0d29yaw0KPiA+Pj4gdGhhdCBoYXMgbm90IGJlZW4gcHJvdmlzaW9uZWQgdG8gcHJv dmlkZSB0aGUgcmVxdWlyZWQgZGV0bmV0IGZvcndhcmRpbmcNCj4gPj4+IHNlcnZpY2UgdG8gdGhh dCB0cmFmZmljIGhhcyB0byBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuICBJbiB0aGlzIHN0YXRlbWVu dCwNCj4gPj4+ICJwcm92aXNpb25lZCIgc2hvdWxkIGJlIHJlYWQgYnJvYWRseSwgZS5nLiwgaXQg Y291bGQgYmUgcmVhbGl6ZWQgdmlhIGFuDQo+ID4+PiBhZG1pbmlzdHJhdGl2ZSBkZWNpc2lvbiB0 aGF0IHRoZSBEZXROZXQgc3VwcG9ydGluZyBuZXR3b3JrIGhhcyB0aGUNCj4gPj4+IGF2YWlsYWJs ZSBjYXBhY2l0eSB0byBjYXJyeSB0aGUgRGV0TmV0IHRyYWZmaWMgdGhhdCBpcyBiZWluZyBzZW50 IGludG8gaXQuDQo+ID4+IGFncmVlZC4NCj4gPj4+PiBUaGlzIHNhaWQsIEkgdGhpbmsgaXQgd291 bGQgYmUgcmVhc29uYWJsZSB0byBtYWtlIGl0IGEgcmVxdWlyZW1lbnQgdGhhdA0KPiA+Pj4+IERl dE5ldCBub2RlcyBtdXN0IG5vdCBmb3J3YXJkIHRyYWZmaWMgdGhhdCBkb2Vzbid0IGNvbmZvcm0g d2l0aCBCQ1A0MQ0KPiA+Pj4+IG92ZXIgYSBuZXR3b3JrIHRoYXQgaXMgbmVpdGhlciBhIERldG5l dCBuZXR3b3JrIG9yIGEgRGV0TmV0IHN1cHBvcnRpbmcNCj4gPj4+PiBuZXR3b3JrLiAgQWx0aG91 Z2ggdGhpcyB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIHRoZSBEZXROZXQgc2VydmljZQ0KPiA+ Pj4+IG1vZGVsLCBpLmUuLCAgdG8ga25vdyB3aGljaCB0cmFmZmljIHdhcyBjb25mb3JtYW50L25v bi1jb25mb3JtYW50Lg0KPiA+Pj4gVGhhdCdzIGZpbmUgd2l0aCBvbmUgaW1wb3J0YW50IHR3aXN0 Og0KPiA+Pj4NCj4gPj4+IEFueSB0cmFmZmljIHRoYXQgaGFzIGJlZW4gcmVwbGljYXRlZCBieSBE ZXROZXQgcGFja2V0IHJlcGxpY2F0aW9uIGhhcyB0bw0KPiA+Pj4gYmUgdHJlYXRlZCBhcyBub3Qg Y29uZm9ybWluZyB3aXRoIEJDUDQxIGJlY2F1c2UgRGV0TmV0IHBhY2tldA0KPiA+Pj4gZWxpbWlu YXRpb24gKG9mIHJlcGxpY2F0ZWQgcGFja2V0cykgbWF5IGhpZGUgY29uZ2VzdGlvbiBpbmRpY2F0 aW9ucw0KPiA+Pj4gKGUuZy4sIGRlbGF5LCBFQ04gQ0UgbWFya3MsIGRyb3BzKSBmcm9tIHRoZSBl bmRwb2ludHMgLSBhIHNjZW5hcmlvIG9mDQo+ID4+PiBwYXJ0aWN1bGFyIGNvbmNlcm4gaW52b2x2 ZXMgdGhlIG90aGVyIGZsb3cgb2YgcmVwbGljYXRlZCBwYWNrZXRzDQo+ID4+PiBmb2xsb3dpbmcg YSBEZXROZXQgbmV0d29yayBwYXRoIGFsb25nIHdoaWNoIG5vdGhpbmcgZ29lcyB3cm9uZy4NCj4g Pj4+IEJDUDQxIGlzIGFib3V0IGVuZC10by1lbmQtY29uZ2VzdGlvbiBjb250cm9sLCB3aGljaCBk b2VzIG5vdCBkbw0KPiA+Pj4gYW55dGhpbmcgaWYgRGV0TmV0IHBhY2tldCBlbGltaW5hdGlvbiBo aWRlcyBjb25nZXN0aW9uIGluZGljYXRpb25zDQo+ID4+PiBmcm9tIHRoZSBlbmRwb2ludHMuDQo+ ID4+IFRoaXMgc2VlbXMgcmVhc29uYWJsZSB0byBtZS4NCj4gPj4NCj4gPj4NCj4gPj4+Pj4gQmV5 b25kIHRoaXMsIEkgdGhpbmsgYSAiU0hPVUxEIiByZXF1aXJlbWVudCB0byBkaXNjYXJkIERldE5l dCB0cmFmZmljDQo+ID4+Pj4+IHRoYXQgd291bGQgb3RoZXJ3aXNlIGVzY2FwZSBpcyBuZWVkZWQs IGFuZCB0aGUgc3RhdGVtZW50IG9mIHRoYXQNCj4gPj4+Pj4gcmVxdWlyZW1lbnQgb3VnaHQgdG8g YmUgY29ubmVjdGVkIHRvIHRoZSBleHBsYW5hdGlvbiBvZiBob3cgdG8NCj4gPj4+Pj4gaW1wbGVt ZW50IHRoYXQgcmVxdWlyZW1lbnQuDQo+ID4+Pj4gSSB0aGluayBhZGRpbmcgYSBzdGF0ZW1lbnQg b24gb3V0cHV0IGZpbHRlcnMgKGFuZCBwb2xpY2VycykgdG8gdGhpcw0KPiA+Pj4+IHNlY3Rpb24g aXMgcmVhc29uYWJsZS4NCj4gPj4+IExldCdzIHN0YXJ0IHdpdGggdGhlIGluY2x1c2lvbiBvZiBv dXRwdXQgZmlsdGVycyAoYW5kIHBvbGljZXJzKSBpbiB0aGUgMy4zLjINCj4gPj4+IHRleHQgd2l0 aCB0aGUgdXNlIG9mIHVwcGVyLWNhc2UgIlNIT1VMRCIgYXMgc3VnZ2VzdGVkIGJ5IFBhc2NhbCAt IEkgd2lsbA0KPiA+Pj4gbG9vayB0aGlzIG92ZXIgYW5kIHN1Z2dlc3QgYW55IGFkZGl0aW9uYWwg dGV4dCB0aGF0IEkgdGhpbmsgb3VnaHQgdG8gYmUNCj4gPj4+IGluY2x1ZGVkLg0KPiA+PiBBcyBh biBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIHRoZSBhdXRob3JzL1dHIG1hZGUgdGhlIGNhbGwgdG8g bm90IHVzZQ0KPiA+PiBjb25mb3JtYW5jZSBjYXBpdGFsaXphdGlvbiBvciByZWZlcmVuY2UgMjEx OS84MTc0LsKgIEkgdGhpbmsgdGhpcw0KPiA+PiB0cmFuc2xhdGVzIHRvIHRoZSBjb25mb3JtYW5j ZSBsYW5ndWFnZSBuZWVkaW5nIHRvIGJlIGFkZGVkIHRvIHRoZSBkYXRhDQo+ID4+IHBsYW5lIHNv bHV0aW9uIGRvY3VtZW50cy4NCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+Pg0KPiA+PiBMb3UNCj4g Pj4NCj4gPj4NCj4gPj4+IFRoYW5rcywgLS1EYXZpZA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2Vy QGxhYm4ubmV0XQ0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjQsIDIwMTggMzoxOCBQ TQ0KPiA+Pj4+IFRvOiBCbGFjaywgRGF2aWQ7IErDoW5vcyBGYXJrYXM7IERldE5ldCBXRw0KPiA+ Pj4+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUt MTANCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiA+Pj4+DQo+ID4+ Pj4gSGkgRGF2aWQsDQo+ID4+Pj4NCj4gPj4+PiBPbiAxMi8xOS8yMDE4IDEyOjM3IFBNLCBCbGFj aywgRGF2aWQgd3JvdGU6DQo+ID4+Pj4+IEphbm9zLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgdGVy bWlub2xvZ3kgaXMgZGVmaW5pdGVseSBpbXByb3ZlZCAtIHRoZSByZXN1bHRpbmcgZHJhZnQgaXMg bXVjaA0KPiA+Pj4+PiBjbGVhcmVyIC0gbWFueSB0aGFua3MgdG8geW91IGFuZCB0aGUgYXV0aG9y cyBmb3IgZG9pbmcgdGhhdC4NCj4gPj4+PiBIYXBweSB0byBoZWFyIHRoYXQuDQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4+PiBXaGVyZSBkbyB3ZSBzdGFuZCBvbiB0aGUgY29uY2VybiBhYm91dCBwcm90 ZWN0aW5nIGV4dGVybmFsDQo+ID4+Pj4+IG5vbi1EZXROZXQgbmV0d29ya3MgZnJvbSBEZXROZXQg Zmxvd3MgdGhhdCBlc2NhcGUgYSBEZXROZXQNCj4gPj4+Pj4gbmV0d29yaywgZS5nLiwgZHVlIHRv IGFuIGVycm9uZW91cyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gY2hhbmdlPw0KPiA+Pj4+IEknbSBu b3Qgc3VyZSB3ZSBoYXZlIGdlbmVyYWwgc29sdXRpb25zIGluIHRoZSBpbnRlcm5ldCBhcmNoaXRl Y3R1cmUgZm9yDQo+ID4+Pj4gbWlzcy1jb25maWd1cmVkL2J1Z2d5IHN5c3RlbXMgb3RoZXIgdGhh biBkcm9wcGluZyB0aGUgcGFja2V0cyBvbiB0aGUNCj4gPj4+PiBmbG9vciAoZS5nLiwgZHVlIHRv IG5vIHJvdXRlLCBubyBsYWJlbCwgb3IgdHRsIGV4cGlyeSkuwqAgV2hhdCB0eXBlIG9mDQo+ID4+ Pj4gcHJvdGVjdGlvbiBhcmUgeW91IGxvb2tpbmcgZm9yIGhlcmUsIGFuZCBjYW4geW91IHByb3Zp ZGUgYSByZWZlcmVuY2UgdG8NCj4gPj4+PiB0aGUgdHlwZSBvZiByb3V0ZXIgYmVoYXZpb3IgeW91 IHdvdWxkIGxpa2UgdG8gc2VlP8KgIEkgaGF2ZSBhIHN1Z2dlc3Rpb24NCj4gPj4+PiB0aGF0IG1p Z2h0IGFkZHJlc3MgeW91ciBjb25jZXJuIGJlbG93IGVsYXRlZCB0byBub24tQkNQNDEgY29uZm9y bWFudA0KPiA+Pj4+IHRyYWZmaWMsIGJ1dCBhbSB1bnN1cmUgaWYgdGhpcyBpcyB3aGF0IHlvdSBh cmUgY29uY2VybmVkIGFib3V0Lg0KPiA+Pj4+DQo+ID4+Pj4+IE15IGN1cnJlbnQgdmlld3MgYXJl IC4uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGVyZSdzIG5vIHRocm90dGxpbmcgaW4gRGV0TmV0LCBl LmcuLCB0aGlzIHRleHQgaW4gNC4zLjI6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIFRoZXJlIGlz IG5vIHByb3Zpc2lvbiBpbiBEZXROZXQgZm9yIHRocm90dGxpbmcgRGV0TmV0IGZsb3dzLCBpLmUu LA0KPiA+Pj4+PiAgICAgICB0aGUgdHJhbnNtaXNzaW9uIHJhdGUgY2Fubm90IGJlIHJlZHVjZWQg dmlhIGV4cGxpY2l0IGNvbmdlc3Rpb24NCj4gPj4+Pj4gICAgICAgbm90aWZpY2F0aW9uIFtSRkMz MTY4XS4gIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgYSBEZXROZXQgZmxvdywgdG8gYmUNCj4gPj4+ Pj4gICAgICAgdXNlZnVsLCBtdXN0IGJlIGRlbGl2ZXJlZCBpbiBpdHMgZW50aXJldHkuDQo+ID4+ Pj4gV2VsbCBsb29raW5nIGF0IGl0IHRoaXMgd2F5LCB0aGVyZSBpcyBubyB0aHJvdHRsaW5nIGlu IGFueSBJUCBuZXR3b3JrIGFzDQo+ID4+Pj4gdGhlIHJvdXRlcnMgZ2VuZXJhdGUgdGhlIENOIGFu ZCBvbmx5IGRyb3Agd2hlbiB0aGVpciBxdWV1ZXMgYXJlIGZ1bGwgb3INCj4gPj4+PiBpbXBsZW1l bnRpbmcgc29tZSBzb3J0IG9mIFJFRC4NCj4gPj4+Pg0KPiA+Pj4+IEluIERldE5ldCB0aGVyZSBp cyBhbiBleHBlY3RhdGlvbiB0aGF0IGludGVybWVkaWF0ZSBub2RlcyBkbyBtb3JlIHRoYW4NCj4g Pj4+PiB0aGlzLsKgIFNwZWNpZmljYWxseSwgc2VlIHNlY3Rpb24gNC41OiAiUXVldWluZywgU2hh cGluZywgU2NoZWR1bGluZywgYW5kDQo+ID4+Pj4gUHJlZW1wdGlvbiIgYW5kIHBvbGljaW5nLCB3 aGljaCBpcyBtZW50aW9uZWQgYXMgcmVxdWlyZW1lbnQgaW4gc2VjdGlvbg0KPiA+Pj4+IDMuMy4x Lg0KPiA+Pj4+DQo+ID4+Pj4+IGFuZCBubyBhc3N1cmFuY2UgdGhhdCBhbGwgRGV0TmV0LXVzaW5n IGFwcGxpY2F0aW9ucyB3aWxsIGNlYXNlIGFuZCBkZXNpc3QNCj4gPj4+Pj4gaW4gdGhlIGZhY2Ug b2YgcGFja2V0IGRyb3BzIHRoYXQgaW5kaWNhdGUgY29uZ2VzdGlvbi4NCj4gPj4+PiBJIHRoaW5r IHRoaXMgaXMgY29ycmVjdC4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+IFBhY2tldCBSZXBsaWNh dGlvbiBhbmQgRWxpbWluYXRpb24gbWFrZXMgdGhpcyB3b3JzZSB2aWEgaXRzIGFiaWxpdHkgdG8N Cj4gaGlkZQ0KPiA+Pj4+PiBuZXR3b3JrIHBhY2tldCBkcm9wcyBhbmQgY29uZ2VzdGlvbiBpbmRp Y2F0aW9ucyBmcm9tIGVuZHBvaW50cywgZS5nLiwNCj4gPj4+Pj4gb2YgdGhvc2UgZHJvcHMgYW5k L29yIGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgb2NjdXIgb24gb25seSBvbmUgb2YNCj4gPj4+Pj4g dGhlIHBhdGhzIHVzZWQgYnkgcmVwbGljYXRlZCBwYWNrZXRzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBU aGUgZmlyc3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gMy4zLjIgaXMgYSBnb29kIHN0YXJ0LCBidXQg SSB0aGluayBpdHMgbG93ZXINCj4gPj4+Pj4gY2FzZSAic2hvdWxkIiBpcyB0b28gd2VhazoNCj4g Pj4+Pj4NCj4gPj4+Pj4gICAgICAgUm9idXN0IHJlYWwtdGltZSBzeXN0ZW1zIHJlcXVpcmUgdG8g cmVkdWNlIHRoZSBudW1iZXIgb2YgcG9zc2libGUNCj4gPj4+Pj4gICAgICAgZmFpbHVyZXMuICBG aWx0ZXJzIGFuZCBwb2xpY2VycyBzaG91bGQgYmUgdXNlZCBpbiBhIERldE5ldCBuZXR3b3JrIHRv DQo+ID4+Pj4+ICAgICAgIGRldGVjdCBpZiBEZXROZXQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24g dGhlIHdyb25nIGludGVyZmFjZSwgb3IgYXQNCj4gPj4+Pj4gICAgICAgdGhlIHdyb25nIHRpbWUs IG9yIGluIHRvbyBncmVhdCBhIHZvbHVtZS4gIEZ1cnRoZXJtb3JlLCBmaWx0ZXJzIGFuZA0KPiA+ Pj4+PiAgICAgICBwb2xpY2VycyBjYW4gdGFrZSBhY3Rpb25zIHRvIGRpc2NhcmQgdGhlIG9mZmVu ZGluZyBwYWNrZXRzIG9yIGZsb3dzLA0KPiA+Pj4+PiAgICAgICBvciB0cmlnZ2VyIHNodXR0aW5n IGRvd24gdGhlIG9mZmVuZGluZyBmbG93IG9yIHRoZSBvZmZlbmRpbmcNCj4gPj4+Pj4gICAgICAg aW50ZXJmYWNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBdCBhIG1pbmltdW0sIEkgdGhpbmsgdGhhdCB0 aGUgcmVxdWlyZW1lbnQgdG8gZGlzY2FyZCBEZXROZXQgdHJhZmZpYw0KPiA+Pj4+PiB0aGF0IHdv dWxkIG90aGVyd2lzZSBlc2NhcGUgYSBEZXROZXQgbmV0d29yayBoYXMgdG8gYmUgc3RhdGVkIGFz DQo+ID4+Pj4+IGEgIk1VU1QiIHJlcXVpcmVtZW50IGZvciBhbnkgRGV0TmV0IG5ldHdvcmsgdGhh dCBzdXBwb3J0cyBQYWNrZXQNCj4gPj4+Pj4gUmVwbGljYXRpb24gYW5kIEVsaW1pbmF0aW9uIGR1 ZSB0byB0aGUgYWJpbGl0eSBvZiB0aGF0IGZ1bmN0aW9uYWxpdHkNCj4gPj4+Pj4gdG8gaGlkZSBj b25nZXN0aW9uIGZyb20gZW5kcG9pbnRzLCBtYWtpbmcgaXQgaW1wb3NzaWJsZSBmb3IgaGlnaGVy DQo+ID4+Pj4+IGxheWVycyBvZiB0aGUgcHJvdG9jb2wgc3RhY2sgdG8gcmVzcG9uZC4NCj4gPj4+ PiBUbyBtZSBjbGVhciwgeW91ciBhcmUgc3VnZ2VzdGluZyB0aGF0IHRleHQgYmUgYWRkZWQgdG8g c2F5IHRoYXQgc2VuZGluZw0KPiA+Pj4+IGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1kZXRuZXQg aW50ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPj4+PiBJcyB0aGlzIGNv cnJlY3Q/wqAgSWYgc28sIEkgdGhpbmsgdGhpcyBpcyB0b28gYnJvYWQgY29uc2lkZXJpbmcgdGhh dA0KPiA+Pj4+IHRoZXJlIGFyZSBuZXR3b3JrcyB0aGF0IGNhbiBwcm92aWRlZCB0aGUgcmVxdWly ZWQgZGV0bmV0IGZvcndhcmRpbmcNCj4gPj4+PiBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBu b3QgZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMgaXMgbWVudGlvbmVkIGF0DQo+ID4+Pj4gdGhlIGVu ZCBvZiBzZWN0aW9uIDQuMy4yLiAoSSdsbCByZWZlciB0byBzdWNoIGFzICJEZXROZXQgc3VwcG9y dGluZw0KPiA+Pj4+IG5ldHdvcmtzIiBpbiB0aGUgbmV4dCBwYXJhZ3JhcGguKQ0KPiA+Pj4+DQo+ ID4+Pj4gVGhpcyBzYWlkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlYXNvbmFibGUgdG8gbWFrZSBp dCBhIHJlcXVpcmVtZW50IHRoYXQNCj4gPj4+PiBEZXROZXQgbm9kZXMgbXVzdCBub3QgZm9yd2Fy ZCB0cmFmZmljIHRoYXQgZG9lc24ndCBjb25mb3JtIHdpdGggQkNQNDENCj4gPj4+PiBvdmVyIGEg bmV0d29yayB0aGF0IGlzIG5laXRoZXIgYSBEZXRuZXQgbmV0d29yayBvciBhIERldE5ldCBzdXBw b3J0aW5nDQo+ID4+Pj4gbmV0d29yay7CoCBBbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUgYSBj aGFuZ2UgdG8gdGhlIERldE5ldCBzZXJ2aWNlDQo+ID4+Pj4gbW9kZWwsIGkuZS4swqAgdG8ga25v dyB3aGljaCB0cmFmZmljIHdhcyBjb25mb3JtYW50L25vbi1jb25mb3JtYW50Lg0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+Pj4gQmV5b25kIHRoaXMsIEkgdGhpbmsgYSAiU0hPVUxEIiByZXF1aXJlbWVu dCB0byBkaXNjYXJkIERldE5ldCB0cmFmZmljDQo+ID4+Pj4+IHRoYXQgd291bGQgb3RoZXJ3aXNl IGVzY2FwZSBpcyBuZWVkZWQsIGFuZCB0aGUgc3RhdGVtZW50IG9mIHRoYXQNCj4gPj4+Pj4gcmVx dWlyZW1lbnQgb3VnaHQgdG8gYmUgY29ubmVjdGVkIHRvIHRoZSBleHBsYW5hdGlvbiBvZiBob3cg dG8NCj4gPj4+Pj4gaW1wbGVtZW50IHRoYXQgcmVxdWlyZW1lbnQuDQo+ID4+Pj4gSSB0aGluayBh ZGRpbmcgYSBzdGF0ZW1lbnQgb24gb3V0cHV0IGZpbHRlcnMgKGFuZCBwb2xpY2llcnMpIHRvIHRo aXMNCj4gPj4+PiBzZWN0aW9uIGlzIHJlYXNvbmFibGUuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ PiBUaGUgdGV4dCBpbiBTZWN0aW9uIDMuMy4yIGhhcyBhIGxvdCBvZg0KPiA+Pj4+PiB0aGUgY29u dGVudCBuZWVkZWQgLSBmb3IgYSB3b3JrZWQgZXhhbXBsZSBvZiBzdWNoICJTSE9VTEQiIHRleHQs DQo+ID4+Pj4+IHNlZSBTZWN0aW9uIDUgb2YgUkZDIDc1MTAsIGluIHBhcnRpY3VsYXIgdGhlIGl0 ZW1pemVkIGxpc3QgYXQgdGhlIGVuZCBvZg0KPiA+Pj4+PiB0aGF0IHNlY3Rpb24gYW5kIHRoZSBw YXJhZ3JhcGggdGhhdCBpbnRyb2R1Y2VzIHRoYXQgbGlzdDoNCj4gPj4+Pj4gICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTAjc2VjdGlvbi01DQo+ID4+Pj4gSWYgSSdtIG5v dCBtaXN0YWtlbiwgc3VjaCBtZWNoYW5pc21zIGFyZSBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZQ0K PiA+Pj4+IGRvY3VtZW50IGFuZCB5b3UgcmVhbGx5IGFyZSBqdXN0IGFza2luZyB0aGVtIHRvIGJl IChyZSlsaXN0ZWQgdG8gZW5zdXJlDQo+ID4+Pj4gdGhhdCB0aGlzIGltcG9ydCBwb2ludCBpc24n dCBtaXNzZWQuwqAgSXMgdGhpcyBjb3JyZWN0PyBCZXNpZGVzIHdoYXQgaXMNCj4gPj4+PiBtZW50 aW9uZWQgYWJvdmUsIGlzIHRoZXJlIGFueXRoaW5nIGVsc2UgbWlzc2luZz8NCj4gPj4+Pg0KPiA+ Pj4+IFRoYW5rcyENCj4gPj4+Pg0KPiA+Pj4+IExvdQ0KPiA+Pj4+DQo+ID4+Pj4+IFRoYW5rcywg LS1EYXZpZA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g Pj4+Pj4+IEZyb206IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSsOhbm9zDQo+IEZhcmthcw0KPiA+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNl bWJlciAxOSwgMjAxOCAxMDo1NCBBTQ0KPiA+Pj4+Pj4gVG86IERldE5ldCBXRw0KPiA+Pj4+Pj4g U3ViamVjdDogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFtFWFRFUk5BTCBFTUFJTF0NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBIaSwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGUgRGV0TmV0IGFyY2hpdGVjdHVyZSBkb2N1 bWVudCBoYXMgYmVlbiB1cGRhdGVkIHRvIGFkZHJlc3MgdGhlDQo+ID4+Pj4+PiBjb21tZW50cy4g VGhlIG5ldyByZXZpc2lvbiAodjEwKSBpcyBhdmFpbGFibGUgYXQNCj4gPj4+Pj4+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTAuDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGRpc2N1c3Npb24g aXRlbXMgZW1haWxzIG9uIHRoZSBsaXN0LiBUaGUNCj4gPj4+Pj4+IHVwZGF0ZXMgYXJlIGFsb25n IHRoZSBtYWpvciBkaXNjdXNzaW9uIGl0ZW1zLCB3aGljaCBhbHNvIGNvdmVyIHRoZQ0KPiA+Pj4+ Pj4gZGVyaXZhdGl2ZSBkaXNjdXNzaW9ucywgYWRkcmVzcyB0aGUgY29tbWVudHMuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gVGhlIG1ham9yIGl0ZW1zIGhhdmUgYmVlbiBzdW1tYXJpemVkIGluOg0KPiA+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVu dC9tc2cwMTk2OC5odG1sLg0KPiA+Pj4+Pj4gRm9sbG93IHVwIGRpc2N1c3Npb25zIGltcGxpZWQg dGVybWlub2xvZ3kgY2hhbmdlcyBzdW1tYXJpemVkIGluOg0KPiA+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMjAzNi5odG1sOg0K PiA+Pj4+Pj4gcmVwbGFjZSAidHJhbnNwb3J0IHN1Yi1sYXllciIgd2l0aCAiZm9yd2FyZGluZyBz dWItbGF5ZXIiDQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2RldG5ldC9jdXJyZW50L21zZzAyMDM4Lmh0bWw6DQo+ID4+Pj4+PiByZXBsYWNlICJjb25nZXN0 aW9uIHByb3RlY3Rpb24iIHdpdGggInJlc291cmNlIiBhbGxvY2F0aW9uIg0KPiA+Pj4+Pj4gQ29u c2VxdWVudGx5LCB0aGUgZG9jdW1lbnQgaGFkIGEgZ29vZCAnc2N1cmIiLg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IEluIGFkZGl0aW9uLCBvdXRzdGFuZGluZyBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVz c2VkIGFsb25nDQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2RldG5ldC9jdXJyZW50L21zZzAxOTQzLmh0bWwuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNl IGxldCB1cyBrbm93IGlmIGFueSBjb21tZW50IGhhcHBlbmVkIHRvIGJlIHJlbWFpbmVkIG9wZW4u DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+Pj4gSmFub3MNCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+Pj4+Pj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4gZGV0bmV0QGlldGYu b3JnDQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5l dA0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IGRldG5ldEBpZXRmLm9yZw0K PiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPiA+ Pj4+Pg0K From nobody Tue Jan 8 10:38:16 2019 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 43FF8130F7B for ; Tue, 8 Jan 2019 10:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 Dm5EJ_BJmE7J for ; Tue, 8 Jan 2019 10:38:11 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780104.outbound.protection.outlook.com [40.107.78.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 B8249130F72 for ; Tue, 8 Jan 2019 10:38:10 -0800 (PST) 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=mKH2gH5VT2Dgwnv+56AKrwrQazqLMjCDEdFiwWRGn20=; b=jfeMXECVJpe0u65nXHMa3SEDM+lCQL7efJIWnxeGRMCYvhifqoLvcMzO91MmJzmy7U6q8WPLJwXBgHoFfbyfDiH5rJVkEMuvWcv777SjdUkfLP20EjZXh4WSBBgjvKwa8iOxBN8uY/m3AY3wai08LlehAujOyhu879W11tHW5Ok= Received: from MN2PR06MB5664.namprd06.prod.outlook.com (20.178.243.214) by MN2PR06MB5440.namprd06.prod.outlook.com (20.178.244.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Tue, 8 Jan 2019 18:38:06 +0000 Received: from MN2PR06MB5664.namprd06.prod.outlook.com ([fe80::359b:a550:22dd:11af]) by MN2PR06MB5664.namprd06.prod.outlook.com ([fe80::359b:a550:22dd:11af%5]) with mapi id 15.20.1495.011; Tue, 8 Jan 2019 18:38:06 +0000 From: "Grossman, Ethan A." To: "Pascal Thubert (pthubert)" , "Black, David" CC: "detnet@ietf.org" , "ekr@rtfm.com" Thread-Topic: DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic Thread-Index: AdSX+/sLTp7DPyO1QkG1vyM68OeTlQAEW9GwAAoIQfAAUfnZsAAUxF1sA2vo08A= Date: Tue, 8 Jan 2019 18:38:06 +0000 Message-ID: References: <85ff3ddbde5f498ab1c680e1a7d97641@XCH-RCD-001.cisco.com>, <8B0117C3-ABCC-4B50-8BAF-5BE1D6D4329F@cisco.com> In-Reply-To: <8B0117C3-ABCC-4B50-8BAF-5BE1D6D4329F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTg1MGIyNDkzLTEzNzQtMTFlOS04MjA5LWFjYmMzMjdhNTFjNlxhbWUtdGVzdFw4NTBiMjQ5NS0xMzc0LTExZTktODIwOS1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIxMzAyMCIgdD0iMTMxOTE0NDYyNzkxMDQ5NTgzIiBoPSJNcUMzaU9yRHBYMVVMZGs0eWl3c1Erem5rOWM9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MN2PR06MB5440; 6:cGwBJsw2oKUzGJOzkO1dp+53WDlLiT0DpC+T+JU6716kNNNrAx5QyBgiQjX3JzGyClavpoORjERC+OfEYE6SHvGBDHEcWs5HE65MxK+pjZINHVYwdyOMk7TQM2SZaorZ7wjUz+ombhrv11UlbPvKWBvauI+oRrAgJJzGT77VoC3RlWAKolwWceaQS0XGziM1RHRzbUD/oa9srNioCgKnDXZbya0omnqLaSPgefJZtV9313jbSSTp3uCbEGvwJyFNE+uPMfR4DcKP713EWAguMtWqPAYZ2Egiuf6BZAgyzn6qRpHhtXxVc6KUN3Tof5dye7LHv0ep4RnoA8yeYsg2WIpRJ6Qs49D0+c5KGjv5h/86ZH1flrp0p5KJHlbjRPRLOYyHQrVHtVSPNIBBe7ekWh336AJdnfIFqa8HxRYC4pWMJnmDDzzklX3Oc7BdpfrW96QF7BYDOHFPDOfSrNbcTg==; 5:K9CiYjaInOndNzHbvye/Yr1SNO7xP+6j9CsfiiPX6kpjXMC4ERhRiJUAeLY0wHWCUwXblxiZJeKx2SLm1gbukzQGbOwzdrLjw2jsaBSKGTfI7bxRz0PQ/5lnQENMJ8ly9dEGr/lsdO6HQ+O6uESccjArDujR5YT6YE5xNJue1fpqA93JzzJc3der0ulSLIZX4iIQZbZSL0DS9+fLexsLsQ==; 7:wKIi/IWXMKfD1+/n8ZWRkLSy+8tnBA+/5AB/ugwg/LBLx1Vwhap1Rm7OxFJqAqeTWmGlwlkKRbTeYuHwLNUJ1rhh218nPhp0gqBLBxC0vHXhr0X/Wl4yHqrXuwuU+4deDZsNxLRoWNWh6lO6yoDXGQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dfd449ae-e1a4-401e-ece1-08d675986e70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR06MB5440; x-ms-traffictypediagnostic: MN2PR06MB5440: x-microsoft-antispam-prvs: x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(366004)(376002)(396003)(53754006)(199004)(189003)(71200400001)(7736002)(81166006)(6306002)(256004)(53936002)(11346002)(68736007)(236005)(99286004)(2420400007)(9686003)(74316002)(15650500001)(55016002)(2906002)(53546011)(3846002)(86362001)(7110500001)(446003)(66574012)(26005)(102836004)(10710500007)(478600001)(790700001)(6116002)(6346003)(186003)(486006)(54896002)(476003)(229853002)(66066001)(71190400001)(4326008)(105586002)(76176011)(6506007)(106356001)(8676002)(33656002)(316002)(93886005)(110136005)(6246003)(5660300001)(8936002)(14444005)(97736004)(14454004)(25786009)(81156014)(54906003)(6436002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR06MB5440; H:MN2PR06MB5664.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8IEjbzDDlsPV6CmuGIw4OFt4XysSHU6XVJ+lP8gXSuLa9OMEKGkVf1dn4LZeruLQqnIRLRMtoAM60EIAQJIJ19qvfRbfpMVxxwBTu5c0nWPhIGV89FMHUx6W11CvIFvlvz97Xspl2UjAaKz+j7e0HAg9eu87MMmR7VHSS/O6yy8UAxxcGyH0sVPgW42Q2qE+UrlOjyQrvWN5WofZTKfI27asJWTEmRzZeIcI60UQA/1UpZ+iZZGpkzzzBlQjoFWVRhLY4VvGzZ0C3Afv0C6ulmmlaeN7f+dS131B8lrG5Ru/Czw1bpPedzsut2wQ4wIi spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MN2PR06MB56643A81E6ACE0D495E42F96C48A0MN2PR06MB5664namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfd449ae-e1a4-401e-ece1-08d675986e70 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 18:38:06.6936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR06MB5440 Archived-At: Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic 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, 08 Jan 2019 18:38:14 -0000 --_000_MN2PR06MB56643A81E6ACE0D495E42F96C48A0MN2PR06MB5664namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhdmlkIGFuZCBQYXNjYWwgZm9yIHRoZXNlIHRob3VnaHRzOyBpdCBsb29rcyBsaWtl IHRoZXJlIGlzIGVub3VnaCBzcGVjaWZpYyBpbmZvcm1hdGlvbiBoZXJlIGZvciBtZSB0byBzcGlu IHVwIGEgc2VjdGlvbiBmb3IgdGhlIERldE5ldCBTZWN1cml0eSBkcmFmdCwgc29tZXRoaW5nIGxp a2Ug4oCcRW5jcnlwdGlvbiBDb25zaWRlcmF0aW9ucyBmb3IgRGV0TmV04oCdLiBBdCB0aGlzIHBv aW50IGl0IGxvb2tzIGxpa2UgaXQgd291bGQgYmUgaW4gdGhlIGZvcm0gb2YgZGVzY3JpYmluZyB0 aGUgc2l0dWF0aW9uLCB0aGVuIGRlc2NyaWJpbmcgdGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHVz ZSBvZiBzeW1tZXRyaWMgdnMgYXN5bW1ldHJpYyBjcnlwdG8gaW4gdGhpcyBjb250ZXh0IChhcyBu b3RlZCBiZWxvdykuDQoNCklmIHnigJlhbGwgb3IgYW55b25lIGVsc2Ugb24gdGhlIGxpc3QgKERl dE5ldCBTZWN1cml0eSBkcmFmdCBjby1hdXRob3JzPz8pIGhhcyBhbnkgZnVydGhlciBpbnB1dCBv biB0aGlzIHRvcGljIEkgd291bGQgbG92ZSB0byBpbmNvcnBvcmF0ZSBpdC4NClRoYW5rcywNCkV0 aGFuIChhcyBEZXROZXQgU2VjdXJpdHkgZHJhZnQgZWRpdG9yKS4NCg0KRnJvbTogUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPg0KU2VudDogU2F0dXJkYXksIERl Y2VtYmVyIDIyLCAyMDE4IDEyOjMwIEFNDQpUbzogQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0Bk ZWxsLmNvbT4NCkNjOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb20+OyBkZXRu ZXRAaWV0Zi5vcmc7IGVrckBydGZtLmNvbQ0KU3ViamVjdDogUmU6IERldE5ldCBVc2UgQ2FzZXMg Y29tbWVudCAtIHRpbWUgcHJvcGVydGllcyBvZiBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgdXNl ZCB0byB2ZXJpZnkgdHJhZmZpYw0KDQpIZWxsbyBEYXZpZA0KDQpXZSB3YW50IGV2ZXJ5IGludGVy bWVkaWF0ZSBub2RlIHRvIGJlIGFibGUgdG8gZGV0ZWN0IGJhZCBwYWNrZXRzIGFzIHBhcnQgb2Yg aW5ncmVzcyBmaWx0ZXJpbmcuIElmIHdlIHVzZSBzeW1tZXRyaWNhbCBrZXlzIHRoZW4gdGhlIGtl eSBtdXN0IGJlIGdpdmVuIHRvIGFsbCByZWxheXMgd2hpY2ggYXVnbWVudHMgdGhlIHJpc2sgb2Yg YSBsZWFrLiBBbmQgaWYgYW55IHJlbGF5IGlzIGNvbXByb21pc2VkIG9yIG1pc2JlaGF2aW5nIGl0 IG1heSBpbmplY3QgdHJhZmZpYyBpbiB0aGUgZmxvdy4NClRoaXMgaXMgd2h5IGlmIHdlIGNvdWxk IGFmZm9yZCBpdCBhbiBhc3ltbWV0cmljYWwgY3J5cHRvIHdvdWxkIGJlIHByZWZlcmFibGUuDQoN Ck1lcnJ5IENocmlzdG1hcyENCg0KUGFzY2FsDQoNCkxlIDIxIGTDqWMuIDIwMTggw6AgMjM6NTMs IEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5jb208bWFpbHRvOkRhdmlkLkJsYWNrQGRl bGwuY29tPj4gYSDDqWNyaXQgOg0KSGkgUGFzY2FsLA0KDQpJIHdvdWxkIG5vdCBwcmVjbHVkZSB0 aGF0LCBidXQgSSB3b3VsZCBkaXNjb3VyYWdlIGl0LCBhcywgaWYgSSB1bmRlcnN0YW5kIHdoYXQg aXMgcHJvcG9zZWQsIGl0IGludm9sdmVzIGNoZWNraW5nIGEgZGlnaXRhbCBzaWduYXR1cmUgb24g ZWFjaCBwYWNrZXQgYXQgYXJiaXRyYXJ5IGludGVybWVkaWF0ZSBwb2ludHMgYWxvbmcgdGhlIGZs b3csIHdoaWNoIGlzIGluZGVlZCByYXRoZXIgZXhwZW5zaXZlLg0KDQpJZiBvbmx5IGVuZHBvaW50 IGNoZWNrcyBvciBjaGVja3MgYXQgYSBzbWFsbCBudW1iZXIgb2YgaW50ZXJtZWRpYXRlIHBvaW50 cyBhcmUgcmVxdWlyZWQsIGEgbW9yZSBlZmZlY3RpdmUgYXBwcm9hY2ggaXMgdG8gdXNlIGFzeW1t ZXRyaWMgY3J5cHRvIHRvIGF1dGhlbnRpY2F0ZSBkaXN0cmlidXRpb24gb3IgZXhjaGFuZ2Ugb2Yg YSBzZWNyZXQga2V5IGZvciBzeW1tZXRyaWMgY3J5cHRvIOKAkyBhIHN1Y2Nlc3NmdWwgY2hlY2sg YmFzZWQgb24gdGhhdCBrZXkgcHJvdmlkZXMgdHJhZmZpYyBvcmlnaW4gdmVyaWZpY2F0aW9uIGFz IGxvbmcgYXMgdGhlIGtleSBpcyBrZXB0IHNlY3JldCBieSB0aGUgcGFydGljaXBhbnRzLiAgQm90 aCBUTFMgYW5kIElLRSAoZm9yIElQc2VjKSBhcmUgZXhhbXBsZXMgb2YgdGhpcyBmb3IgZW5kcG9p bnQgY2hlY2tzLg0KDQpJbiBib3RoIGNhc2VzLCBvcmlnaW4gdmVyaWZpY2F0aW9uIGFsc28gcmVx dWlyZXMgcmVwbGF5IGRldGVjdGlvbiBtZWNoYW5pc20gYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg cHJvdG9jb2wgdG8gcHJldmVudCBhbiBhdHRhY2tlciBmcm9tIHJlY29yZGluZyBhbmQgcmVzZW5k aW5nIHRyYWZmaWMsIGUuZy4sIGFzIGEgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrIG9uIGZsb3cg Zm9yd2FyZGluZyByZXNvdXJjZXMuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBkZXRuZXQg W21haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxOCAyOjM0IEFN DQpUbzogQmxhY2ssIERhdmlkOyBHcm9zc21hbiwgRXRoYW4gQS47IGRldG5ldEBpZXRmLm9yZzxt YWlsdG86ZGV0bmV0QGlldGYub3JnPg0KQ2M6IGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0u Y29tPg0KU3ViamVjdDogUmU6IFtEZXRuZXRdIERldE5ldCBVc2UgQ2FzZXMgY29tbWVudCAtIHRp bWUgcHJvcGVydGllcyBvZiBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgdXNlZCB0byB2ZXJpZnkg dHJhZmZpYw0KDQoNCltFWFRFUk5BTCBFTUFJTF0NCkhlbGxvIERhdmlkIDoNCg0KQXN5bW1ldHJp YyBpcyBhIGxvdCBtb3JlIGV4cGVuc2l2ZSwgSeKAmW0gaGVhcmluZywgYnV0IGNvdWxkIGJlIHZl cnkgdXNlZnVsIHRvIGVuc3VyZSB0aGF0IHRoZSBwYWNrZXRzIGluIGEgRGV0TmV0IGZsb3cgYXJl IGZyb20gdGhlIHByb3BlciBzb3VyY2UuDQpTYXkgdGhhdCB0aGUgRGV0TmV0IGZsb3cgaXMgYXNz b2NpYXRlZCB3aXRoIGEga2V5cGFpciwgYW5kIHRoYXQgdGhlIHByaXZhdGUga2V5IGlzIGF2YWls YWJsZSB0byB0aGUgc291cmNlIG9mIHRoZSBmbG93IHdoZXJlYXMgdGhlIHB1YmxpYyBrZXkgaXMg ZGlzdHJpYnV0ZWQgd2l0aCB0aGUgZmxvdyBpbmZvcm1hdGlvbi4NCldlIHNob3VsZCBub3QgcHJl Y2x1ZGUgdGhhdCBzaG91bGQgd2U/IEFzIGxvbmcgYXMgdGhlIGNyeXB0byB0aW1lIGlzIGJvdW5k ZWQgd2Ugc2hvdWxkIGJlIE9LLg0KDQpBbGwgdGhlIGJlc3QNCg0KcGFzY2FsDQoNCkZyb206IGRl dG5ldCA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYu b3JnPj4gT24gQmVoYWxmIE9mIEJsYWNrLCBEYXZpZA0KU2VudDogamV1ZGkgMjAgZMOpY2VtYnJl IDIwMTggMDM6NDcNClRvOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb208bWFp bHRvOmVhZ3Jvc0Bkb2xieS5jb20+PjsgZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0 Zi5vcmc+DQpDYzogZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+DQpTdWJqZWN0OiBS ZTogW0RldG5ldF0gRGV0TmV0IFVzZSBDYXNlcyBjb21tZW50IC0gdGltZSBwcm9wZXJ0aWVzIG9m IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvIHZlcmlmeSB0cmFmZmljDQoNCj4gR29v ZCBxdWVzdGlvbiwgZm9yIGV4YW1wbGUgZG8gc3VjaCBhbGdvcml0aG1zIGhhdmUgZGV0ZXJtaW5p c3RpYyBleGVjdXRpb24gdGltZXM/DQoNCkdlbmVyYWxseSwgeWVzLCB0byBhIGZpcnN0IGFwcHJv eGltYXRpb24sIGFzIHRoZSBhbGdvcml0aG1zIHVzZWQgdG8gZW5jcnlwdCBhbmQgdmVyaWZ5IHRy YWZmaWMgYXJlIHVzdWFsbHkgc3ltbWV0cmljIGNyeXB0byBhbGdvcml0aG1zIHN1Y2ggYXMgQUVT IGFuZCBTSEEtMiB3aGljaCBwZXJmb3JtIHRoZSBzYW1lIGNvbXB1dGF0aW9uIHJlZ2FyZGxlc3Mg b2YgaW5wdXQuICAgTm9uLWRldGVybWluaXN0aWMgZXhlY3V0aW9uIHRpbWVzIGFyZSBhc3NvY2lh dGVkIHdpdGggYXN5bW1ldHJpYyBjcnlwdG8gYWxnb3JpdGhtcyAoZS5nLiwgcHVibGljIGtleSBh bGdvcml0aG1zKSwgd2hpY2ggYXJlIG5vdCB0eXBpY2FsbHkgdXNlZCBvbiBhIHBhY2tldC1ieS1w YWNrZXQgYmFzaXMgLSB0aGV54oCZcmUgdXNlZCBmb3Igc2Vzc2lvbiBzZXR1cCwgaW5jbHVkaW5n IGtleSBleGNoYW5nZSwgZnJvbSB3aGljaCBrZXlzIGFyZSBkZXJpdmVkIGZvciB0aGUgc3ltbWV0 cmljIGFsZ29yaXRobXMuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBkZXRuZXQgW21haWx0 bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyb3NzbWFuLCBFdGhhbiBB Lg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxOCA3OjQyIFBNDQpUbzogZGV0bmV0 QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQpDYzogZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+DQpTdWJqZWN0OiBbRGV0bmV0XSBEZXROZXQgVXNlIENhc2VzIGNvbW1l bnQgLSB0aW1lIHByb3BlcnRpZXMgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHVzZWQgdG8g dmVyaWZ5IHRyYWZmaWMNCg0KDQpbRVhURVJOQUwgRU1BSUxdDQoNCkhpIEFsbCwNCg0KSW4gZ29p bmcgb3ZlciB0aGUgcmVtYWluaW5nIElFU0cgcmV2aWV3IGNvbW1lbnRzLCB0aGVyZSBpcyB0aGlz IHF1ZXN0aW9uIG9uIFNlYyAxMS41IChTZWN1cml0eSkuIEkgZG9u4oCZdCB0aGluayBpdCBpcyB3 b3J0aCBob2xkaW5nIHVwIHRoZSBVc2UgQ2FzZXMgZHJhZnQgZm9yLCBidXQgaXQgc2VlbXMgd29y dGggYSBjb252ZXJzYXRpb24gb24gdGhlIGxpc3QuDQoNCg0KDQpUZXh0IGZyb20gU2VjdGlvbiAx MS41Og0KDQo+ICAgICAgYWRkaXRpb24gdG8gYXJyaXZpbmcgd2l0aCB0aGUgZGF0YSBjb250ZW50 IGFzIGludGVuZGVkLCB0aGUgZGF0YSBtdXN0DQoNCj4gICAgICBhbHNvIGFycml2ZSBhdCB0aGUg ZXhwZWN0ZWQgdGltZS4gIFRoaXMgbWF5IHByZXNlbnQgIm5ldyIgc2VjdXJpdHkNCg0KPiAgICAg IGNoYWxsZW5nZXMgdG8gaW1wbGVtZW50ZXJzLCBhbmQgbXVzdCBiZSBhZGRyZXNzZWQgYWNjb3Jk aW5nbHkuICBUaGVyZQ0KDQo+ICAgICAgYXJlIG90aGVyIHNlY3VyaXR5IGltcGxpY2F0aW9ucywg aW5jbHVkaW5nIChidXQgbm90IGxpbWl0ZWQgdG8pIHRoZQ0KDQo+ICAgICAgY2hhbmdlIGluIGF0 dGFjayBzdXJmYWNlIHByZXNlbnRlZCBieSBwYWNrZXQgcmVwbGljYXRpb24gYW5kDQoNCj4gICAg ICBlbGltaW5hdGlvbi4NCg0KDQoNClJldmlld2Vy4oCZcyBDb21tZW50Og0KDQpEbyB0aGVzZSBy ZXF1aXJlbWVudHMgaW1wb3NlIG5ldyByZXF1aXJlbWVudHMgb24gdGhlIGNyeXB0b2dyYXBoaWMg YWxnb3JpdGhtcyB1c2VkIHRvIHZlcmlmeSB0cmFmZmljPw0KDQoNCg0KRXRoYW7igJlzIHRob3Vn aHRzOg0KDQpHb29kIHF1ZXN0aW9uLCBmb3IgZXhhbXBsZSBkbyBzdWNoIGFsZ29yaXRobXMgaGF2 ZSBkZXRlcm1pbmlzdGljIGV4ZWN1dGlvbiB0aW1lcz8gSXMgdGhlcmUgYSBsYXJnZSBzcHJlYWQg YmV0d2VlbiBiZXN0LSBhbmQgd29yc3QtY2FzZSBleGVjdXRpb24gdGltZXM/IElzIHRoaXMgYSB0 b3BpYyBmb3IgdGhlIFNlY3VyaXR5IGRyYWZ0PyBUaGUgQXJjaGl0ZWN0dXJlIGRyYWZ0PyBPciBp cyB0aGlzIGEgbW9yZSBnZW5lcmFsIG1hdHRlciBvZiBuZXR3b3JrIChvciBuZXR3b3JrIHNpbGlj b24pIGRlc2lnbi9pbXBsZW1lbnRhdGlvbi9wZXJmb3JtYW5jZSwgYW5kIHRodXMgZG9lc27igJl0 IGdldCBjb3ZlcmVkIGluIERldE5ldCBkcmFmdHM/DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_MN2PR06MB56643A81E6ACE0D495E42F96C48A0MN2PR06MB5664namp_ 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 bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiM5OTMzNjY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIERhdmlkIGFuZCBQ YXNjYWwgZm9yIHRoZXNlIHRob3VnaHRzOyBpdCBsb29rcyBsaWtlIHRoZXJlIGlzIGVub3VnaCBz cGVjaWZpYyBpbmZvcm1hdGlvbiBoZXJlIGZvciBtZSB0byBzcGluIHVwIGEgc2VjdGlvbiBmb3Ig dGhlIERldE5ldCBTZWN1cml0eSBkcmFmdCwgc29tZXRoaW5nIGxpa2Ug4oCcRW5jcnlwdGlvbiBD b25zaWRlcmF0aW9ucyBmb3IgRGV0TmV04oCdLiBBdCB0aGlzIHBvaW50IGl0IGxvb2tzDQogbGlr ZSBpdCB3b3VsZCBiZSBpbiB0aGUgZm9ybSBvZiBkZXNjcmliaW5nIHRoZSBzaXR1YXRpb24sIHRo ZW4gZGVzY3JpYmluZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdXNlIG9mIHN5bW1ldHJpYyB2 cyBhc3ltbWV0cmljIGNyeXB0byBpbiB0aGlzIGNvbnRleHQgKGFzIG5vdGVkIGJlbG93KS4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB54oCZYWxsIG9yIGFueW9uZSBlbHNlIG9uIHRoZSBs aXN0IChEZXROZXQgU2VjdXJpdHkgZHJhZnQgY28tYXV0aG9ycz8/KSBoYXMgYW55IGZ1cnRoZXIg aW5wdXQgb24gdGhpcyB0b3BpYyBJIHdvdWxkIGxvdmUgdG8gaW5jb3Jwb3JhdGUgaXQuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV0aGFuIChhcyBEZXROZXQgU2VjdXJpdHkgZHJhZnQgZWRp dG9yKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVy dEBjaXNjby5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgRGVjZW1iZXIgMjIs IDIwMTggMTI6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZCAmbHQ7RGF2aWQuQmxh Y2tAZGVsbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBHcm9zc21hbiwgRXRoYW4gQS4gJmx0O2Vh Z3Jvc0Bkb2xieS5jb20mZ3Q7OyBkZXRuZXRAaWV0Zi5vcmc7IGVrckBydGZtLmNvbTxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogRGV0TmV0IFVzZSBDYXNlcyBjb21tZW50IC0gdGltZSBwcm9wZXJ0 aWVzIG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvIHZlcmlmeSB0cmFmZmljPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBEYXZpZCA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+V2Ugd2FudCBldmVyeSBpbnRlcm1lZGlhdGUgbm9kZSB0byBiZSBhYmxlIHRv IGRldGVjdCBiYWQgcGFja2V0cyBhcyBwYXJ0IG9mIGluZ3Jlc3MgZmlsdGVyaW5nLiBJZiB3ZSB1 c2Ugc3ltbWV0cmljYWwga2V5cyB0aGVuIHRoZSBrZXkgbXVzdCBiZSBnaXZlbiB0byBhbGwgcmVs YXlzIHdoaWNoIGF1Z21lbnRzIHRoZSByaXNrIG9mIGEgbGVhay4gQW5kIGlmIGFueQ0KIHJlbGF5 IGlzIGNvbXByb21pc2VkIG9yIG1pc2JlaGF2aW5nIGl0IG1heSBpbmplY3QgdHJhZmZpYyBpbiB0 aGUgZmxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBpcyB3aHkgaWYgd2UgY291bGQgYWZmb3JkIGl0IGFuIGFzeW1tZXRyaWNhbCBjcnlw dG8gd291bGQgYmUgcHJlZmVyYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVycnkgQ2hyaXN0bWFzITxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpMZSAyMSBkw6ljLiAyMDE4IMOgIDIzOjUzLCBCbGFjaywg RGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbSI+RGF2aWQuQmxh Y2tAZGVsbC5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMz NjYiPkhpIFBhc2NhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPkkgd291 bGQgbm90IHByZWNsdWRlIHRoYXQsIGJ1dCBJIHdvdWxkIGRpc2NvdXJhZ2UgaXQsIGFzLCBpZiBJ IHVuZGVyc3RhbmQgd2hhdCBpcyBwcm9wb3NlZCwgaXQgaW52b2x2ZXMgY2hlY2tpbmcgYSBkaWdp dGFsIHNpZ25hdHVyZSBvbiBlYWNoIHBhY2tldCBhdCBhcmJpdHJhcnkgaW50ZXJtZWRpYXRlIHBv aW50cyBhbG9uZyB0aGUgZmxvdywgd2hpY2ggaXMgaW5kZWVkDQogcmF0aGVyIGV4cGVuc2l2ZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk5MzM2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPklmIG9ubHkgZW5kcG9pbnQgY2hl Y2tzIG9yIGNoZWNrcyBhdCBhIHNtYWxsIG51bWJlciBvZiBpbnRlcm1lZGlhdGUgcG9pbnRzIGFy ZSByZXF1aXJlZCwgYSBtb3JlIGVmZmVjdGl2ZSBhcHByb2FjaCBpcyB0byB1c2UgYXN5bW1ldHJp YyBjcnlwdG8gdG8gYXV0aGVudGljYXRlIGRpc3RyaWJ1dGlvbiBvciBleGNoYW5nZSBvZiBhIHNl Y3JldCBrZXkgZm9yIHN5bW1ldHJpYw0KIGNyeXB0byDigJMgYSBzdWNjZXNzZnVsIGNoZWNrIGJh c2VkIG9uIHRoYXQga2V5IHByb3ZpZGVzIHRyYWZmaWMgb3JpZ2luIHZlcmlmaWNhdGlvbiBhcyBs b25nIGFzIHRoZSBrZXkgaXMga2VwdCBzZWNyZXQgYnkgdGhlIHBhcnRpY2lwYW50cy4mbmJzcDsg Qm90aCBUTFMgYW5kIElLRSAoZm9yIElQc2VjKSBhcmUgZXhhbXBsZXMgb2YgdGhpcyBmb3IgZW5k cG9pbnQgY2hlY2tzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+SW4gYm90 aCBjYXNlcywgb3JpZ2luIHZlcmlmaWNhdGlvbiBhbHNvIHJlcXVpcmVzIHJlcGxheSBkZXRlY3Rp b24gbWVjaGFuaXNtIGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IHByb3RvY29sIHRvIHByZXZlbnQg YW4gYXR0YWNrZXIgZnJvbSByZWNvcmRpbmcgYW5kIHJlc2VuZGluZyB0cmFmZmljLCBlLmcuLCBh cyBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFjayBvbg0KIGZsb3cgZm9yd2FyZGluZyByZXNvdXJj ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM5OTMzNjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+VGhhbmtzLCAt LURhdmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZGV0bmV0IFs8YSBocmVmPSJt YWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDE4IDI6MzQgQU08YnI+ DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZDsgR3Jvc3NtYW4sIEV0aGFuIEEuOyA8YSBocmVmPSJt YWlsdG86ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbRGV0bmV0XSBEZXROZXQgVXNlIENhc2VzIGNvbW1lbnQgLSB0aW1l IHByb3BlcnRpZXMgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHVzZWQgdG8gdmVyaWZ5IHRy YWZmaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImNvbG9yOiNDRTExMjYiPltFWFRFUk5BTCBFTUFJTF0gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+SGVsbG8gRGF2aWQm bmJzcDs6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzeW1tZXRyaWMgaXMgYSBsb3QgbW9yZSBleHBlbnNpdmUsIEnigJltIGhlYXJpbmcsIGJ1 dCBjb3VsZCBiZSB2ZXJ5IHVzZWZ1bCB0byBlbnN1cmUgdGhhdCB0aGUgcGFja2V0cyBpbiBhIERl dE5ldCBmbG93IGFyZSBmcm9tIHRoZSBwcm9wZXIgc291cmNlLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TYXkgdGhhdCB0aGUgRGV0TmV0IGZsb3cgaXMgYXNzb2NpYXRl ZCB3aXRoIGEga2V5cGFpciwgYW5kIHRoYXQgdGhlIHByaXZhdGUga2V5IGlzIGF2YWlsYWJsZSB0 byB0aGUgc291cmNlIG9mIHRoZSBmbG93IHdoZXJlYXMgdGhlIHB1YmxpYyBrZXkgaXMgZGlzdHJp YnV0ZWQgd2l0aCB0aGUgZmxvdyBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIHNob3VsZCBub3QgcHJlY2x1ZGUgdGhhdCBzaG91bGQgd2U/IEFzIGxv bmcgYXMgdGhlIGNyeXB0byB0aW1lIGlzIGJvdW5kZWQgd2Ugc2hvdWxkIGJlIE9LLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbGwgdGhlIGJlc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGFz Y2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGRldG5ldCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnIj5kZXRuZXQtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJsYWNrLCBEYXZpZDxicj4NCjxiPlNl bnQ6PC9iPiBqZXVkaSAyMCBkw6ljZW1icmUgMjAxOCAwMzo0Nzxicj4NCjxiPlRvOjwvYj4gR3Jv c3NtYW4sIEV0aGFuIEEuICZsdDs8YSBocmVmPSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSI+ZWFn cm9zQGRvbGJ5LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RldG5l dF0gRGV0TmV0IFVzZSBDYXNlcyBjb21tZW50IC0gdGltZSBwcm9wZXJ0aWVzIG9mIGNyeXB0b2dy YXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvIHZlcmlmeSB0cmFmZmljPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgR29vZCBx dWVzdGlvbiwgZm9yIGV4YW1wbGUgZG8gc3VjaCBhbGdvcml0aG1zIGhhdmUgZGV0ZXJtaW5pc3Rp YyBleGVjdXRpb24gdGltZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5HZW5lcmFsbHksIHllcywgdG8gYSBmaXJzdCBhcHByb3hpbWF0aW9uLCBh cyB0aGUgYWxnb3JpdGhtcyB1c2VkIHRvIGVuY3J5cHQgYW5kIHZlcmlmeSB0cmFmZmljIGFyZSB1 c3VhbGx5IHN5bW1ldHJpYyBjcnlwdG8gYWxnb3JpdGhtcyBzdWNoIGFzIEFFUyBhbmQgU0hBLTIg d2hpY2ggcGVyZm9ybSB0aGUgc2FtZSBjb21wdXRhdGlvbiByZWdhcmRsZXNzIG9mIGlucHV0LiZu YnNwOyZuYnNwOw0KIE5vbi1kZXRlcm1pbmlzdGljIGV4ZWN1dGlvbiB0aW1lcyBhcmUgYXNzb2Np YXRlZCB3aXRoIGFzeW1tZXRyaWMgY3J5cHRvIGFsZ29yaXRobXMgKGUuZy4sIHB1YmxpYyBrZXkg YWxnb3JpdGhtcyksIHdoaWNoIGFyZSBub3QgdHlwaWNhbGx5IHVzZWQgb24gYSBwYWNrZXQtYnkt cGFja2V0IGJhc2lzIC0gdGhleeKAmXJlIHVzZWQgZm9yIHNlc3Npb24gc2V0dXAsIGluY2x1ZGlu ZyBrZXkgZXhjaGFuZ2UsIGZyb20gd2hpY2gga2V5cyBhcmUgZGVyaXZlZA0KIGZvciB0aGUgc3lt bWV0cmljIGFsZ29yaXRobXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+VGhhbmtzLCAtLURhdmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZGV0 bmV0IFs8YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkZXRu ZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyb3NzbWFuLCBF dGhhbiBBLjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDE5LCAyMDE4IDc6 NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRl dG5ldEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpla3JAcnRm bS5jb20iPmVrckBydGZtLmNvbTwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RldG5ldF0gRGV0 TmV0IFVzZSBDYXNlcyBjb21tZW50IC0gdGltZSBwcm9wZXJ0aWVzIG9mIGNyeXB0b2dyYXBoaWMg YWxnb3JpdGhtcyB1c2VkIHRvIHZlcmlmeSB0cmFmZmljPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiNDRTExMjYiPltFWFRFUk5BTCBFTUFJTF0gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBBbGws PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiBnb2luZyBvdmVyIHRo ZSByZW1haW5pbmcgSUVTRyByZXZpZXcgY29tbWVudHMsIHRoZXJlIGlzIHRoaXMgcXVlc3Rpb24g b24gU2VjIDExLjUgKFNlY3VyaXR5KS4gSSBkb27igJl0IHRoaW5rIGl0IGlzIHdvcnRoIGhvbGRp bmcgdXAgdGhlIFVzZSBDYXNlcyBkcmFmdCBmb3IsIGJ1dCBpdCBzZWVtcyB3b3J0aCBhIGNvbnZl cnNhdGlvbiBvbiB0aGUgbGlzdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UZXh0 IGZyb20gU2VjdGlvbiAxMS41OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRkaXRpb24gdG8gYXJyaXZp bmcgd2l0aCB0aGUgZGF0YSBjb250ZW50IGFzIGludGVuZGVkLCB0aGUgZGF0YSBtdXN0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFsc28gYXJyaXZlIGF0IHRoZSBleHBlY3RlZCB0aW1lLiZuYnNwOyBUaGlz IG1heSBwcmVzZW50ICZxdW90O25ldyZxdW90OyBzZWN1cml0eTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj aGFsbGVuZ2VzIHRvIGltcGxlbWVudGVycywgYW5kIG11c3QgYmUgYWRkcmVzc2VkIGFjY29yZGlu Z2x5LiZuYnNwOyBUaGVyZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgb3RoZXIgc2VjdXJpdHkgaW1w bGljYXRpb25zLCBpbmNsdWRpbmcgKGJ1dCBub3QgbGltaXRlZCB0bykgdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNoYW5nZSBpbiBhdHRhY2sgc3VyZmFjZSBwcmVzZW50ZWQgYnkgcGFja2V0IHJlcGxp Y2F0aW9uIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbGltaW5hdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+UmV2aWV3ZXLigJlzIENvbW1lbnQ6IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+RG8gdGhlc2UgcmVxdWlyZW1lbnRzIGltcG9zZSBuZXcgcmVx dWlyZW1lbnRzIG9uIHRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgdXNlZCB0byB2ZXJpZnkg dHJhZmZpYz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RXRoYW7igJlzIHRob3VnaHRz OiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5Hb29kIHF1ZXN0aW9uLCBmb3IgZXhhbXBsZSBkbyBzdWNoIGFsZ29yaXRobXMg aGF2ZSBkZXRlcm1pbmlzdGljIGV4ZWN1dGlvbiB0aW1lcz8gSXMgdGhlcmUgYSBsYXJnZSBzcHJl YWQgYmV0d2VlbiBiZXN0LSBhbmQgd29yc3QtY2FzZSBleGVjdXRpb24gdGltZXM/IElzIHRoaXMg YSB0b3BpYyBmb3IgdGhlIFNlY3VyaXR5IGRyYWZ0PyBUaGUgQXJjaGl0ZWN0dXJlDQogZHJhZnQ/ IE9yIGlzIHRoaXMgYSBtb3JlIGdlbmVyYWwgbWF0dGVyIG9mIG5ldHdvcmsgKG9yIG5ldHdvcmsg c2lsaWNvbikgZGVzaWduL2ltcGxlbWVudGF0aW9uL3BlcmZvcm1hbmNlLCBhbmQgdGh1cyBkb2Vz buKAmXQgZ2V0IGNvdmVyZWQgaW4gRGV0TmV0IGRyYWZ0cz8mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_MN2PR06MB56643A81E6ACE0D495E42F96C48A0MN2PR06MB5664namp_-- From nobody Tue Jan 8 14:38:51 2019 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 C8B7A1311C5; Tue, 8 Jan 2019 14:38:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , db3546@att.com, Lou Berger , Janos Farkas , draft-ietf-detnet-problem-statement@ietf.org, janos.farkas@ericsson.com, detnet-chairs@ietf.org, detnet@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <154698712373.25486.14398433491751796587.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2019 14:38:43 -0800 Archived-At: Subject: [Detnet] Document Action: 'Deterministic Networking Problem Statement' to Informational RFC (draft-ietf-detnet-problem-statement-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: Tue, 08 Jan 2019 22:38:44 -0000 The IESG has approved the following document: - 'Deterministic Networking Problem Statement' (draft-ietf-detnet-problem-statement-09.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-problem-statement/ Technical Summary This document summarizes the need for Deterministic Networking (DetNet) and describes the problems to be solved by DetNet. The document lists key features to be provided by a DetNet network and collects main technical components to be supported to achieve the goals of DetNet. Working Group Summary There is consensus in the WG to proceed with the publication of the document as an Informational RFC. This document is an important input to the work of the WG to guide the solution documents and for the industry to understand the problem space which detnet is addressing. Document Quality It is a good quality document. The Shepherd reviewed the latest version (-06) and found no issues. Personnel Who is the Document Shepherd for this document? János Farkas Who is the Responsible Area Director? Deborah Brungard From nobody Tue Jan 8 14:42:04 2019 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 3C18F1311CF; Tue, 8 Jan 2019 14:42:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , detnet@ietf.org, db3546@att.com, Lou Berger , draft-ietf-detnet-use-cases@ietf.org, detnet-chairs@ietf.org, lberger@labn.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154698732220.25486.7882121851902040511.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2019 14:42:02 -0800 Archived-At: Subject: [Detnet] Document Action: 'Deterministic Networking Use Cases' to Informational RFC (draft-ietf-detnet-use-cases-20.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: Tue, 08 Jan 2019 22:42:02 -0000 The IESG has approved the following document: - 'Deterministic Networking Use Cases' (draft-ietf-detnet-use-cases-20.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ Technical Summary This document describes a number of uses cases for Deterministic Networking (DetNet). For each case, it will identify the application, identify representative solutions used today, and the improvements IETF DetNet solutions may enable. Working Group Summary Nothing particular worth noting. Document Quality The document is one of the foundation documents for other DetNet WG activities. It notably has had contributions from the end-user part of the market. Personnel Who is the Document Shepherd for this document? Lou Berger Who is the Responsible Area Director? Deborah Brungard From nobody Thu Jan 10 14:01:11 2019 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 E95ED13127E for ; Thu, 10 Jan 2019 14:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cFeqT-4ByBhM for ; Thu, 10 Jan 2019 14:01:07 -0800 (PST) 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 D7190131218 for ; Thu, 10 Jan 2019 14:01:06 -0800 (PST) Received: from lhrpml401-hub.exmail.huawei.com (unknown [172.18.7.66]) by Forcepoint Email with ESMTP id 785BE7F18A8FD30210D2; Thu, 10 Jan 2019 22:01:03 +0000 (GMT) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.41]) by lhrpml401-hub.exmail.huawei.com ([10.201.4.160]) with mapi id 14.03.0415.000; Thu, 10 Jan 2019 22:00:58 +0000 From: Norman Finn To: "Grossman, Ethan A." , "Pascal Thubert (pthubert)" , "Black, David" CC: "ekr@rtfm.com" , "detnet@ietf.org" Thread-Topic: DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic Thread-Index: AdSX+/sLTp7DPyO1QkG1vyM68OeTlQAEW9GwAAoIQfAAUfnZsAAUxF1sA2vo08AAa6kP6g== Date: Thu, 10 Jan 2019 22:00:57 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F80172307E@lhrpml504-mbx.exmail.huawei.com> References: <85ff3ddbde5f498ab1c680e1a7d97641@XCH-RCD-001.cisco.com>, <8B0117C3-ABCC-4B50-8BAF-5BE1D6D4329F@cisco.com>, In-Reply-To: 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_3DF0466E9510274382F5B74499ACD6F80172307Elhrpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic 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, 10 Jan 2019 22:01:10 -0000 --_000_3DF0466E9510274382F5B74499ACD6F80172307Elhrpml504mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Certainly, this is meat for the security draft. Some comments -- The time required to perform crypto processing is either unbounded, in whic= h case that method is not suitable for DetNet, or it is bounded, in which c= ase we're OK. Maybe slow, but still deterministic. To give differentiated QoS on a flow-by-flow basis, you must be able to ide= ntify the flows. This opens one up to traffic analysis. That cost of DetN= et. Many encryption suites (e.g. MACsec) can be configured to provide message i= ntegrity without obscuring all of the data. The IP/TCP headers, for exampl= e, can be left in the clear by MACsec. That allows hop-by-hop deep inspect= ion, if that's what you want to do. Crypto considerations make it even more desirable to export the flow ID to = lower layers (e.g., to the MPLS label or destination MAC address), rather t= han depending on deep packet inspection at every hop. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Grossman, Ethan A. [eag= ros@dolby.com] Sent: Tuesday, January 08, 2019 10:38 AM To: Pascal Thubert (pthubert); Black, David Cc: ekr@rtfm.com; detnet@ietf.org Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptog= raphic algorithms used to verify traffic Thanks David and Pascal for these thoughts; it looks like there is enough s= pecific information here for me to spin up a section for the DetNet Securit= y draft, something like =93Encryption Considerations for DetNet=94. At this= point it looks like it would be in the form of describing the situation, t= hen describing the pros and cons of the use of symmetric vs asymmetric cryp= to in this context (as noted below). If y=92all or anyone else on the list (DetNet Security draft co-authors??) = has any further input on this topic I would love to incorporate it. Thanks, Ethan (as DetNet Security draft editor). From: Pascal Thubert (pthubert) Sent: Saturday, December 22, 2018 12:30 AM To: Black, David Cc: Grossman, Ethan A. ; detnet@ietf.org; ekr@rtfm.com Subject: Re: DetNet Use Cases comment - time properties of cryptographic al= gorithms used to verify traffic Hello David We want every intermediate node to be able to detect bad packets as part of= ingress filtering. If we use symmetrical keys then the key must be given t= o all relays which augments the risk of a leak. And if any relay is comprom= ised or misbehaving it may inject traffic in the flow. This is why if we could afford it an asymmetrical crypto would be preferabl= e. Merry Christmas! Pascal Le 21 d=E9c. 2018 =E0 23:53, Black, David > a =E9crit : Hi Pascal, I would not preclude that, but I would discourage it, as, if I understand w= hat is proposed, it involves checking a digital signature on each packet at= arbitrary intermediate points along the flow, which is indeed rather expen= sive. If only endpoint checks or checks at a small number of intermediate points = are required, a more effective approach is to use asymmetric crypto to auth= enticate distribution or exchange of a secret key for symmetric crypto =96 = a successful check based on that key provides traffic origin verification a= s long as the key is kept secret by the participants. Both TLS and IKE (fo= r IPsec) are examples of this for endpoint checks. In both cases, origin verification also requires replay detection mechanism= as part of the security protocol to prevent an attacker from recording and= resending traffic, e.g., as a denial of service attack on flow forwarding = resources. Thanks, --David From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Thursday, December 20, 2018 2:34 AM To: Black, David; Grossman, Ethan A.; detnet@ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptog= raphic algorithms used to verify traffic [EXTERNAL EMAIL] Hello David : Asymmetric is a lot more expensive, I=92m hearing, but could be very useful= to ensure that the packets in a DetNet flow are from the proper source. Say that the DetNet flow is associated with a keypair, and that the private= key is available to the source of the flow whereas the public key is distr= ibuted with the flow information. We should not preclude that should we? As long as the crypto time is bounde= d we should be OK. All the best pascal From: detnet > On B= ehalf Of Black, David Sent: jeudi 20 d=E9cembre 2018 03:47 To: Grossman, Ethan A. >; detnet@= ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptog= raphic algorithms used to verify traffic > Good question, for example do such algorithms have deterministic executio= n times? Generally, yes, to a first approximation, as the algorithms used to encrypt= and verify traffic are usually symmetric crypto algorithms such as AES and= SHA-2 which perform the same computation regardless of input. Non-determ= inistic execution times are associated with asymmetric crypto algorithms (e= .g., public key algorithms), which are not typically used on a packet-by-pa= cket basis - they=92re used for session setup, including key exchange, from= which keys are derived for the symmetric algorithms. Thanks, --David From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Wednesday, December 19, 2018 7:42 PM To: detnet@ietf.org Cc: ekr@rtfm.com Subject: [Detnet] DetNet Use Cases comment - time properties of cryptograph= ic algorithms used to verify traffic [EXTERNAL EMAIL] Hi All, In going over the remaining IESG review comments, there is this question on= Sec 11.5 (Security). I don=92t think it is worth holding up the Use Cases = draft for, but it seems worth a conversation on the list. Text from Section 11.5: > addition to arriving with the data content as intended, the data mus= t > also arrive at the expected time. This may present "new" security > challenges to implementers, and must be addressed accordingly. Ther= e > are other security implications, including (but not limited to) the > change in attack surface presented by packet replication and > elimination. Reviewer=92s Comment: Do these requirements impose new requirements on the cryptographic algorith= ms used to verify traffic? Ethan=92s thoughts: Good question, for example do such algorithms have deterministic execution = times? Is there a large spread between best- and worst-case execution times= ? Is this a topic for the Security draft? The Architecture draft? Or is thi= s a more general matter of network (or network silicon) design/implementati= on/performance, and thus doesn=92t get covered in DetNet drafts? -------------------------------------------------- --_000_3DF0466E9510274382F5B74499ACD6F80172307Elhrpml504mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Certainly, this is meat for the security draft.  Some comments --=

The time required to perform crypto processing is either unbounded, in= which case that method is not suitable for DetNet, or it is bounded, in wh= ich case we're OK.  Maybe slow, but still deterministic.

To give differentiated QoS on a flow-by-flow basis, you must be able t= o identify the flows.  This opens one up to traffic analysis.  Th= at cost of DetNet.

Many encryption suites (e.g. MACsec) can be configured to provide mess= age integrity without obscuring all of the data.  The IP/TCP headers, = for example, can be left in the clear by MACsec.  That allows hop-by-h= op deep inspection, if that's what you want to do.

Crypto considerations make it even more desirable to export the flow I= D to lower layers (e.g., to the MPLS label or destination MAC address), rat= her than depending on deep packet inspection at every hop.

-- Norm

From: detnet [detnet-bounces@ietf.org] on= behalf of Grossman, Ethan A. [eagros@dolby.com]
Sent: Tuesday, January 08, 2019 10:38 AM
To: Pascal Thubert (pthubert); Black, David
Cc: ekr@rtfm.com; detnet@ietf.org
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of = cryptographic algorithms used to verify traffic

Thanks David and Pascal for these thoughts; it looks= like there is enough specific information here for me to spin up a section= for the DetNet Security draft, something like =93Encryption Considerations= for DetNet=94. At this point it looks like it would be in the form of describing the situation, then describing = the pros and cons of the use of symmetric vs asymmetric crypto in this cont= ext (as noted below).

 

If y=92all or anyone else on the list (DetNet Securi= ty draft co-authors??) has any further input on this topic I would love to = incorporate it.

Thanks,

Ethan (as DetNet Security draft editor).

 

From: Pascal Thubert (pthubert) <pthubert@= cisco.com>
Sent: Saturday, December 22, 2018 12:30 AM
To: Black, David <David.Black@dell.com>
Cc: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org; ek= r@rtfm.com
Subject: Re: DetNet Use Cases comment - time properties of cryptogra= phic algorithms used to verify traffic

 

Hello David

 

We want every interme= diate node to be able to detect bad packets as part of ingress filtering. I= f we use symmetrical keys then the key must be given to all relays which au= gments the risk of a leak. And if any relay is compromised or misbehaving it may inject traffic in the flow.

This is why if we could afford it an asymmetrical cr= ypto would be preferable.

 

Merry Christmas!

 

Pascal


Le 21 d=E9c. 2018 =E0 23:53, Black, David <David.Black@dell.c= om> a =E9crit :

Hi Pascal,

 

I would not preclude t= hat, but I would discourage it, as, if I understand what is proposed, it in= volves checking a digital signature on each packet at arbitrary intermediat= e points along the flow, which is indeed rather expensive.

 

If only endpoint check= s or checks at a small number of intermediate points are required, a more e= ffective approach is to use asymmetric crypto to authenticate distribution = or exchange of a secret key for symmetric crypto =96 a successful check based on that key provides traffic origin ve= rification as long as the key is kept secret by the participants.  Bot= h TLS and IKE (for IPsec) are examples of this for endpoint checks.<= /p>

 

In both cases, origin = verification also requires replay detection mechanism as part of the securi= ty protocol to prevent an attacker from recording and resending traffic, e.= g., as a denial of service attack on flow forwarding resources.

 

Thanks, --David=

 

From: detnet [mailto:detnet-bou= nces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, December 20, 2018 2:34 AM
To: Black, David; Grossman, Ethan A.; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of = cryptographic algorithms used to verify traffic

 

[EXTERNAL EMAIL]

Hello David :

 

Asymmetric is a lot more expensive, I=92m hearing, b= ut could be very useful to ensure that the packets in a DetNet flow are fro= m the proper source.

Say that the DetNet flow is associated with a keypai= r, and that the private key is available to the source of the flow whereas = the public key is distributed with the flow information.

We should not preclude that should we? As long as th= e crypto time is bounded we should be OK.

 

All the best

 

pascal

 

From: detnet <detnet-bounces= @ietf.org> On Behalf Of Black, David
Sent: jeudi 20 d=E9cembre 2018 03:47
To: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of = cryptographic algorithms used to verify traffic

 

> Good question, for example do such algorithms h= ave deterministic execution times?

 

Generally, yes, to a f= irst approximation, as the algorithms used to encrypt and verify traffic ar= e usually symmetric crypto algorithms such as AES and SHA-2 which perform t= he same computation regardless of input.   Non-deterministic execution times are associated with asymmetric crypto al= gorithms (e.g., public key algorithms), which are not typically used on a p= acket-by-packet basis - they=92re used for session setup, including key exc= hange, from which keys are derived for the symmetric algorithms.

 

Thanks, --David=

 

From: detnet [mailto:detnet-bou= nces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Wednesday, December 19, 2018 7:42 PM
To: detnet@ietf.org
Cc: ekr@rtfm.com
Subject: [Detnet] DetNet Use Cases comment - time properties of cryp= tographic algorithms used to verify traffic

 

[EXTERNAL EMAIL]

Hi All,

In going over the remaining IESG review comments,= there is this question on Sec 11.5 (Security). I don=92t think it is worth= holding up the Use Cases draft for, but it seems worth a conversation on t= he list.

 

Text from Section 11.5:

>      addition to ar= riving 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 secu= rity implications, including (but not limited to) the

>      change in atta= ck surface presented by packet replication and

>      elimination.

 

Reviewer=92s Comment:

Do these requirements impose new requirements on = the cryptographic algorithms used to verify traffic?

 

Ethan=92s thoughts:

Good question, for exa= mple do such algorithms have deterministic execution times? Is there a larg= e spread between best- and worst-case execution times? Is this a topic for = the Security draft? The Architecture draft? Or is this a more general matter of network (or network silicon) de= sign/implementation/performance, and thus doesn=92t get covered in DetNet d= rafts? 

--------------------------------------------------

--_000_3DF0466E9510274382F5B74499ACD6F80172307Elhrpml504mbxexm_-- From nobody Fri Jan 11 01:18:49 2019 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 B6BB112D4E9 for ; Fri, 11 Jan 2019 01:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.875 X-Spam-Level: X-Spam-Status: No, score=-7.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, 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 header.b=VKEd3cCP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=H7zbtWSP 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 EejIleq9vuNG for ; Fri, 11 Jan 2019 01:18:44 -0800 (PST) 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 2E852128CB7 for ; Fri, 11 Jan 2019 01:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547198322; x=1549790322; 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=pG/pejWb7JFF9hdZejy3VSsEw9u1qIHYTWhTMb33RaQ=; b=VKEd3cCPTtf7o0giNhBM2IcAb7tXv9aF6qN1cswwYGeNS+8W0EEDZXbECRNa9LGk c7nLkFVZJmU8SP1X4IVo0RLDhLYLu4r6UCnBKMepDCULf+rwipT9sIYvT7h2krbK uexNrpISpjNira38+YC7olOCu9xnJFGLIK385dEKgdY=; X-AuditID: c1b4fb2d-2198b9e00000062f-0c-5c385f7247a5 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A5.8A.01583.27F583C5; Fri, 11 Jan 2019 10:18:42 +0100 (CET) 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; Fri, 11 Jan 2019 10:18:42 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) 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; Fri, 11 Jan 2019 10:18:41 +0100 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=pG/pejWb7JFF9hdZejy3VSsEw9u1qIHYTWhTMb33RaQ=; b=H7zbtWSPTfM97XxIr6nNsi57RJzSvXETtlWPJOFhLVoEqL7JOLC0ZoPXwUKKmVepKTGLIQF8C+aGKa9QzOIN0X+KtO05qNhWoQoH0ZGe9Z6RMckPsaOs81QdbPB6n6YnKVH1Y2MPIlFMq1QqFqWudU0s/4xAj8GpROJgi2fHJMs= Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com (10.169.152.15) by AM5PR0701MB2627.eurprd07.prod.outlook.com (10.173.92.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Fri, 11 Jan 2019 09:18:40 +0000 Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36]) by AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36%2]) with mapi id 15.20.1537.013; Fri, 11 Jan 2019 09:18:37 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: "Black, David" , Lou Berger , Janos Farkas , DetNet WG Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7MXufweEKzT502ZhTyUzi0RYqWGU60AgAgIgYCAAFcPAIAA/84AgBRdMwCAAGYNgIABTmMAgAQlUIA= Date: Fri, 11 Jan 2019 09:18:37 +0000 Message-ID: References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.249.253.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2627; 6:l3usd9g96QXtRYlqP4FbGO+HX6f81U8QR7ZwtxNEX7DBN3RFdlSewHVAIl0BuM3NTZGNyTdFi4EwxmXEdTA/8GWF3O1qQmuDyPtf97vpNKsVMJeYpvVk0Bx5e/RJuCkPiwdmyqgrQUh0gQ/L7adJSX68s9RKOyv/+qufp9WO8dG/xGYATn3lbmZTpoTaHyWJmM1kraOQ8WuQxAZCsN2QdzJ5feKsApz1Qqiew3d9WKqow17UfNMos7lEdLJXCjAW3Zi+5ayi2tj1fESFK+0jzmEo1plmSb4uaSOazN37iPtFHGS1fK0YcwHzH5SODJ2p4bJQTkJJxaIJFBwHjrOLl99qi/TSgPHFc3QYOT6Bg/QB5M06Yp5qyvO+Rz+8rAs1ZAA+D2JwEMe7IygfIcqMQ/VBGKrBuU5q7nQ4kgg1YAdB7TflsnWuhoT7zZAvKzIdUvJs7ES4vS41CLIKrlQyFg==; 5:I+o3NlZBBr7kRqIM8buHu6kw8ClJhnHlyXLOBY/aYg3zFVqAm7dAzINwYt6e8c1nEuxCF3Dd8iDOd8zunWYfUGNcWbVhBHgkMsqwDLu5JcwwKwtfg8VcO6lzUHXz5smMg5MgA4h4TSBEi5i/TIp2+ASSzDPEn9RKU7bCE4B99ASxAtmnqJNKJpd/tVaFqDu+sylgKfwnIybujKEYS9GSCw==; 7:Zf89eWf0smvUPFCHA78jfP0rCOwVezzuZMHuNw+dHlk9cI501e4Er+qt6m6lzhHjg9G993veJFKu+G0Miyjs60HmQ6R1888+lCkQYubcOW5BPiU1gB8YT/B5cyDIoZ0Z4UfxCPz2LHnyxbZhKIGfPA== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(346002)(366004)(376002)(13464003)(189003)(199004)(51444003)(93886005)(85182001)(26005)(186003)(6506007)(14454004)(33656002)(6306002)(71200400001)(9686003)(6246003)(53936002)(30864003)(71190400001)(53546011)(7696005)(102836004)(476003)(3846002)(11346002)(6116002)(446003)(76176011)(66574012)(486006)(86362001)(6346003)(68736007)(8936002)(81156014)(8676002)(229853002)(81166006)(105586002)(106356001)(85202003)(7736002)(305945005)(5660300001)(97736004)(2906002)(14444005)(256004)(6436002)(55016002)(966005)(74316002)(478600001)(66066001)(25786009)(99286004)(110136005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2627; H:AM5PR0701MB2292.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: 15952ec4-3ae2-42f6-2e75-08d677a5c505 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2627; x-ms-traffictypediagnostic: AM5PR0701MB2627: x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AwKQ9pvEgwjvjakFE6qAhTfPd8zOhLxUPm15iB6Oq2lP0URJhc3mHmCgSytLOo2MRDa5aLZhjyvGSSPD85mwHiozmfdvtRMmHVKR3jTIrD0W1YYs9sCqk63ZQBo3+tYlhBHww0TIfyYp/F5eE/jPyuZXqeEKcuySDKNg5w83IwppBea6EhP3dZwObYnJcdOrAUietTCOgFMNAtyQhIP4OBXT6mgwL1O4rWhN6aNQ3TeG9vRWXpFI1BtIPYCRaCfm03+OSRGhW1rEB7odL7Bl9GwDsasoJu+mLEwiCBFkTuyHC2OvgB7U5Y+cDkgaCE4a6QWyyBi8sK1ntBxn/mwEkq5A9Ew7jjrdTqeUdYX2s+4fNnfTFh5NL65Y2qd3ZlM1ipP9Em/8Td3IG7tbnu0nPtxOC7r5off22F9U5bhsBzA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 15952ec4-3ae2-42f6-2e75-08d677a5c505 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 09:18:37.6742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2627 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbv7q7LxePSPFnDHPgh0S1NaoFKL1YmGRERYaIuvU1Np9xr 5kuiYpI6KTXNlxQtpaWpWzPIlrkpRiWhIpERgolamhRmEcjM2nYN+vY753/O/znn8NCEtFro RSdrMxlWq06VU2Ky4dyTKwFsnCpm95Jum+p7Yxupsq3cIVWlxV/JA0REdUM9EdHeviqIWDYV U6eIaHFIIpOanMWwyrB4cVKvuZfMGGpC2RXGu6gQWetROXKhAQfDfWM/VY7EtBQPI6i2lQr5 4BeCkUnLhtIugFd6I+kISFxJwOTHOhGv1Alg9t004oNPCJZ1awKHM4XDoc/U5DRzx1UIZlr/ EA5hC94Hi/NVziJ3rILl2imK5wvw/GaRyMEk9oUfhQukgyU4HowzegH/wjwBnas2Z7MLPgkV t+bsRTSNsAxmulWONIE94cNci4BfD0N7/xjBswcszq4LefaB0ZJpkmcZTLTonBsAviaCtroX Il4IhJcdlo3mDgp0Zcd5joLrhi4h3zCB4Iv5DeUYArA/1LxX8DXpUHbPuuGzA8pN1c57SzED +u4SJyMcCzZLIVGJFI3/zd1odyLwLjCYlXzaB2p0M6JG5ync4HXDHNmKyE7kwTEcl6YJ2qNg 2OQEjkvXKrRMpgnZf8rgY1tAH3q4dHAIYRrJXSVHTqtipEJ1FpeTNoSAJuTuEmG4PSVJVOfk Mmx6HHs5leGG0HaalHtK1qRuMVKsUWcylxgmg2H/qQLaxasQhV4twFsXm0atA2FvpwL8H60r UybyIrOfyvSbImu9fRfOc8eO/u6BMxeJ3m8ag7UCfT7U0ZxiPZG3MhJUFhAY6kp3hScY1sWx t8eCZSFn25qjLYZuY/Gw2ftnVO7mAs24cqAo2XBjf8/ATmpv0GDByINn+Qaq5LBmdjxlPN/v nZzkktSBfgTLqf8C6s6ZJyUDAAA= Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 11 Jan 2019 09:18:48 -0000 R3JlYXQuIEkgYW0gZmluZSB0byBhZGQgdGhlc2UgZXhwbGljaXQgc3RhdGVtZW50cyB0byBtYWtl IHRleHQgbW9yZSBjbGVhci4NCg0KTmV3IHRleHQgaXMgaW5saW5lIHdpdGggdGhlIGdlbmVyYWwg c3RhdGVtZW50IGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRyYWZ0Og0KIiAgRGV0TmV0IGlz IGZvciBuZXR3b3JrcyB0aGF0IGFyZSB1bmRlciBhIHNpbmdsZQ0KICAgYWRtaW5pc3RyYXRpdmUg Y29udHJvbCBvciB3aXRoaW4gYSBjbG9zZWQgZ3JvdXAgb2YgYWRtaW5pc3RyYXRpdmUNCiAgIGNv bnRyb2w7IHRoZXNlIGluY2x1ZGUgY2FtcHVzLXdpZGUgbmV0d29ya3MgYW5kIHByaXZhdGUgV0FO cy4gIERldE5ldA0KICAgaXMgbm90IGZvciBsYXJnZSBncm91cHMgb2YgZG9tYWlucyBzdWNoIGFz IHRoZSBJbnRlcm5ldC4gICINCg0KQ2hlZXJzDQpCYWxhJ3pzDQoNClBzOiBBbHNvLCBub3RlIHRo YXQgIkRldE5ldCBmbG93cyIgYXJlIHVuaWRpcmVjdGlvbmFsIC4uLiA6LS0tKSkpKQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIEJsYWNrLCBEYXZpZA0KU2VudDogVHVlc2RheSwgSmFudWFyeSA4 LCAyMDE5IDY6NDYgUE0NClRvOiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjsgSmFub3Mg RmFya2FzIDxKYW5vcy5GYXJrYXNAZXJpY3Nzb24uY29tPjsgRGV0TmV0IFdHIDxkZXRuZXRAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0 dXJlLTEwDQoNClRoYXQncyBmaW5lIGFuZCB3aGF0IHdhcyBpbnRlbmRlZC4NCg0KVGhhbmtzLCAt LURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG91IEJlcmdl ciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSA3LCAy MDE5IDQ6NDkgUE0NCj4gVG86IEJsYWNrLCBEYXZpZDsgSsOhbm9zIEZhcmthczsgRGV0TmV0IFdH DQo+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUt MTANCj4gDQo+IA0KPiBbRVhURVJOQUwgRU1BSUxdDQo+IA0KPiBEYXZpZCwNCj4gDQo+ICDCoMKg wqAgVGhpcyBsb29rcyBnb29kL3JpZ2h0IHRvIG1lLsKgIFRoZSBvbmx5IHNwZWNpZmljIGNoYW5n ZSBJJ2QgYWRkIGlzIA0KPiB0byBjbGFyaWZ5IHRoYXQgd2UncmUgdGFsa2luZyBQRVJPRiB0cmFm ZmljIHdoZW4gc2F5aW5nICJEZXROZXQgDQo+IHJlcGxpY2F0ZWQgdHJhZmZpYyIuDQo+IA0KPiBU aGFua3MhDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDEvNy8yMDE5IDEwOjQ0IEFNLCBCbGFjaywgRGF2 aWQgd3JvdGU6DQo+ID4gTG91LA0KPiA+DQo+ID4gQXR0ZW1wdGluZyB0byBzdW1tYXJpemUgd2hh dCBuZWVkcyB0byBiZSBzdGF0ZWQgd2l0aG91dCB1c2luZw0KPiBNVVNUL1NIT1VMRC9NQVk6DQo+ ID4NCj4gPiBbMV0gU2VuZGluZyBEZXROZXQgdHJhZmZpYyBpbnRvIG5ldHdvcmtzIHRoYXQgaGF2 ZSBub3QgYmVlbiANCj4gPiBwcm92aXNpb25lZCBpbg0KPiBhZHZhbmNlIHRvIGhhbmRsZSB0aGF0 IERldE5ldCB0cmFmZmljIGhhcyB0byBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuICANCj4gRWdyZXNz IHRyYWZmaWMgZmlsdGVycyB0byBwcmV2ZW50IHRoaXMgZnJvbSBoYXBwZW5pbmcgYXJlIHN0cm9u Z2x5IA0KPiByZWNvbW1lbmRlZCBhdCB0aGUgZWRnZXMgb2YgRGV0TmV0IG5ldHdvcmtzIGFuZCBE ZXROZXQgc3VwcG9ydGluZyANCj4gbmV0d29ya3MuICBJbiB0aGlzIGNvbnRleHQsIHRoZSB0ZXJt ICdwcm92aXNpb25lZCcgaGFzIGEgYnJvYWQgDQo+IG1lYW5pbmcsIGUuZy4sIHByb3Zpc2lvbmlu ZyBjb3VsZCBiZSBwZXJmb3JtZWQgdmlhIGFuIGFkbWluaXN0cmF0aXZlIA0KPiBkZWNpc2lvbiB0 aGF0IHRoZSBkb3duc3RyZWFtIG5ldHdvcmsgaGFzIHRoZSBhdmFpbGFibGUgY2FwYWNpdHkgdG8g Y2FycnkgdGhlIERldE5ldCB0cmFmZmljIHRoYXQgaXMgYmVpbmcgc2VudCBpbnRvIGl0Lg0KPiA+ DQo+ID4gWzJdIFNlbmRpbmcgbm9uLWNvbmdlc3Rpb24tY29udHJvbGxlZCBEZXROZXQgdHJhZmZp YyAoaS5lLiwgRGV0TmV0IA0KPiA+IHRyYWZmaWMgdGhhdA0KPiBkb2VzIG5vdCBjb21wbHkgd2l0 aCBCQ1AgNDEvUkZDIDI5MTQpIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgbm90IA0KPiBwcm92aXNp b25lZCB0byBoYW5kbGUgdGhhdCB0cmFmZmljIGhhcyB0byBiZSBwcmV2ZW50ZWQgaW4gYWRkaXRp b24gdG8gYmVpbmcgdHJlYXRlZCBhcyBhIGZhdWx0Lg0KPiBEZXROZXQgdHJhZmZpYyB0aGF0IGlz IG5vdCBrbm93biB0byBiZSBjb25nZXN0aW9uIGNvbnRyb2xsZWQgaGFzIHRvIGJlIA0KPiB0cmVh dGVkIGFzIG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgRGV0TmV0IHRyYWZmaWMgZm9yIHRoaXMg DQo+IHJlcXVpcmVtZW50LiAgRGV0TmV0IHJlcGxpY2F0ZWQgdHJhZmZpYyBpcyBhbHdheXMgDQo+ IG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgZXZlbiBpZiB0aGUgb3JpZ2luYWwgRGV0TmV0IGZs b3cgaXMgDQo+IGNvbmdlc3Rpb24tY29udHJvbGxlZCBiZWNhdXNlIERldE5ldCBwYWNrZXQgZWxp bWluYXRpb24gY2FuIGhpZGUgDQo+IGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgKGUuZy4sIGRyb3Bz LCBFQ04gQ0UgbWFya3MsIGluY3JlYXNlZCBsYXRlbmN5KSANCj4gZnJvbSBlbmRwb2ludHMuICBU aGUgcmVzcG9uc2liaWxpdHkgZm9yIGRlYWxpbmcgd2l0aCB0aGVzZSANCj4gcmVxdWlyZW1lbnRz IGluIGdlbmVyYWwsIGFuZCByZXBsaWNhdGVkIHRyYWZmaWMgaW4gcGFydGljdWxhciwgaXMgDQo+ IHNvbHV0aW9uLXNwZWNpZmljLCBhcyB0aGVyZSBhcmUgTVBMUyBtZWNoYW5pc21zIHRoYXQgY2Fu bm90IGJlIGFwcGxpZWQgdG8gdGhlIElQIHNvbHV0aW9uLCBhbmQgbW9yZW92ZXIsIHRoZSBjdXJy ZW50IElQIHNvbHV0aW9uIGRvZXNuJ3Qgc3VwcG9ydCBEZXROZXQgdHJhZmZpYyByZXBsaWNhdGlv bi4NCj4gPg0KPiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0 XQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyNSwgMjAxOCAxMTo0NSBBTQ0KPiA+PiBU bzogQmxhY2ssIERhdmlkOyBKw6Fub3MgRmFya2FzOyBEZXROZXQgV0cNCj4gPj4gU3ViamVjdDog UmU6IFtEZXRuZXRdIGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMA0KPiA+Pg0KPiA+ Pg0KPiA+PiBbRVhURVJOQUwgRU1BSUxdDQo+ID4+DQo+ID4+IEhpIERhdmlkLA0KPiA+Pg0KPiA+ PiBPbiAxMi8yNC8yMDE4IDg6MjkgUE0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IEhpIExv dSwNCj4gPj4+DQo+ID4+PiBFeGNlcnB0aW5nIGtleSBwYXJhZ3JhcGhzIC4uLg0KPiA+Pj4NCj4g Pj4+PiBUbyBtZSBjbGVhciwgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgdGV4dCBiZSBhZGRlZCB0 byBzYXkgdGhhdCANCj4gPj4+PiBzZW5kaW5nIGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1kZXRu ZXQgaW50ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPj4+PiBJcyB0aGlz IGNvcnJlY3Q/DQo+ID4+PiBOb3QgZXhhY3RseSAuLi4NCj4gPj4+DQo+ID4+Pj4gSWYgc28sIEkg dGhpbmsgdGhpcyBpcyB0b28gYnJvYWQgY29uc2lkZXJpbmcgdGhhdCB0aGVyZSBhcmUgDQo+ID4+ Pj4gbmV0d29ya3MgdGhhdCBjYW4gcHJvdmlkZWQgdGhlIHJlcXVpcmVkIGRldG5ldCBmb3J3YXJk aW5nIA0KPiA+Pj4+IHN1Yi1sYXllciBzZXJ2aWNlIHRoYXQgYXJlIG5vdCBkZXRuZXQgc2Vydmlj ZSBhd2FyZSBhcyBpcyANCj4gPj4+PiBtZW50aW9uZWQgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDQu My4yLiAoSSdsbCByZWZlciB0byBzdWNoIGFzIA0KPiA+Pj4+ICJEZXROZXQgc3VwcG9ydGluZyBu ZXR3b3JrcyIgaW4gdGhlIG5leHQgcGFyYWdyYXBoLikNCj4gPj4+IEkgYWdyZWUgd2l0aCB3aGVy ZSB0aGlzIGlzIGhlYWRlZCAtIHNlbmRpbmcgRGV0TmV0IHRyYWZmaWMgaW50byBhIA0KPiA+Pj4g bmV0d29yayB0aGF0IGhhcyBub3QgYmVlbiBwcm92aXNpb25lZCB0byBwcm92aWRlIHRoZSByZXF1 aXJlZCANCj4gPj4+IGRldG5ldCBmb3J3YXJkaW5nIHNlcnZpY2UgdG8gdGhhdCB0cmFmZmljIGhh cyB0byBiZSB0cmVhdGVkIGFzIGEgDQo+ID4+PiBmYXVsdC4gIEluIHRoaXMgc3RhdGVtZW50LCAi cHJvdmlzaW9uZWQiIHNob3VsZCBiZSByZWFkIGJyb2FkbHksIA0KPiA+Pj4gZS5nLiwgaXQgY291 bGQgYmUgcmVhbGl6ZWQgdmlhIGFuIGFkbWluaXN0cmF0aXZlIGRlY2lzaW9uIHRoYXQgdGhlIA0K PiA+Pj4gRGV0TmV0IHN1cHBvcnRpbmcgbmV0d29yayBoYXMgdGhlIGF2YWlsYWJsZSBjYXBhY2l0 eSB0byBjYXJyeSB0aGUgRGV0TmV0IHRyYWZmaWMgdGhhdCBpcyBiZWluZyBzZW50IGludG8gaXQu DQo+ID4+IGFncmVlZC4NCj4gPj4+PiBUaGlzIHNhaWQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVh c29uYWJsZSB0byBtYWtlIGl0IGEgDQo+ID4+Pj4gcmVxdWlyZW1lbnQgdGhhdCBEZXROZXQgbm9k ZXMgbXVzdCBub3QgZm9yd2FyZCB0cmFmZmljIHRoYXQgDQo+ID4+Pj4gZG9lc24ndCBjb25mb3Jt IHdpdGggQkNQNDEgb3ZlciBhIG5ldHdvcmsgdGhhdCBpcyBuZWl0aGVyIGEgDQo+ID4+Pj4gRGV0 bmV0IG5ldHdvcmsgb3IgYSBEZXROZXQgc3VwcG9ydGluZyBuZXR3b3JrLiAgQWx0aG91Z2ggdGhp cyANCj4gPj4+PiB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIHRoZSBEZXROZXQgc2VydmljZSBt b2RlbCwgaS5lLiwgIHRvIGtub3cgd2hpY2ggdHJhZmZpYyB3YXMgY29uZm9ybWFudC9ub24tY29u Zm9ybWFudC4NCj4gPj4+IFRoYXQncyBmaW5lIHdpdGggb25lIGltcG9ydGFudCB0d2lzdDoNCj4g Pj4+DQo+ID4+PiBBbnkgdHJhZmZpYyB0aGF0IGhhcyBiZWVuIHJlcGxpY2F0ZWQgYnkgRGV0TmV0 IHBhY2tldCByZXBsaWNhdGlvbiANCj4gPj4+IGhhcyB0byBiZSB0cmVhdGVkIGFzIG5vdCBjb25m b3JtaW5nIHdpdGggQkNQNDEgYmVjYXVzZSBEZXROZXQgDQo+ID4+PiBwYWNrZXQgZWxpbWluYXRp b24gKG9mIHJlcGxpY2F0ZWQgcGFja2V0cykgbWF5IGhpZGUgY29uZ2VzdGlvbiANCj4gPj4+IGlu ZGljYXRpb25zIChlLmcuLCBkZWxheSwgRUNOIENFIG1hcmtzLCBkcm9wcykgZnJvbSB0aGUgZW5k cG9pbnRzIA0KPiA+Pj4gLSBhIHNjZW5hcmlvIG9mIHBhcnRpY3VsYXIgY29uY2VybiBpbnZvbHZl cyB0aGUgb3RoZXIgZmxvdyBvZiANCj4gPj4+IHJlcGxpY2F0ZWQgcGFja2V0cyBmb2xsb3dpbmcg YSBEZXROZXQgbmV0d29yayBwYXRoIGFsb25nIHdoaWNoIG5vdGhpbmcgZ29lcyB3cm9uZy4NCj4g Pj4+IEJDUDQxIGlzIGFib3V0IGVuZC10by1lbmQtY29uZ2VzdGlvbiBjb250cm9sLCB3aGljaCBk b2VzIG5vdCBkbyANCj4gPj4+IGFueXRoaW5nIGlmIERldE5ldCBwYWNrZXQgZWxpbWluYXRpb24g aGlkZXMgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyANCj4gPj4+IGZyb20gdGhlIGVuZHBvaW50cy4N Cj4gPj4gVGhpcyBzZWVtcyByZWFzb25hYmxlIHRvIG1lLg0KPiA+Pg0KPiA+Pg0KPiA+Pj4+PiBC ZXlvbmQgdGhpcywgSSB0aGluayBhICJTSE9VTEQiIHJlcXVpcmVtZW50IHRvIGRpc2NhcmQgRGV0 TmV0IA0KPiA+Pj4+PiB0cmFmZmljIHRoYXQgd291bGQgb3RoZXJ3aXNlIGVzY2FwZSBpcyBuZWVk ZWQsIGFuZCB0aGUgc3RhdGVtZW50IA0KPiA+Pj4+PiBvZiB0aGF0IHJlcXVpcmVtZW50IG91Z2h0 IHRvIGJlIGNvbm5lY3RlZCB0byB0aGUgZXhwbGFuYXRpb24gb2YgDQo+ID4+Pj4+IGhvdyB0byBp bXBsZW1lbnQgdGhhdCByZXF1aXJlbWVudC4NCj4gPj4+PiBJIHRoaW5rIGFkZGluZyBhIHN0YXRl bWVudCBvbiBvdXRwdXQgZmlsdGVycyAoYW5kIHBvbGljZXJzKSB0byANCj4gPj4+PiB0aGlzIHNl Y3Rpb24gaXMgcmVhc29uYWJsZS4NCj4gPj4+IExldCdzIHN0YXJ0IHdpdGggdGhlIGluY2x1c2lv biBvZiBvdXRwdXQgZmlsdGVycyAoYW5kIHBvbGljZXJzKSBpbiANCj4gPj4+IHRoZSAzLjMuMiB0 ZXh0IHdpdGggdGhlIHVzZSBvZiB1cHBlci1jYXNlICJTSE9VTEQiIGFzIHN1Z2dlc3RlZCBieSAN Cj4gPj4+IFBhc2NhbCAtIEkgd2lsbCBsb29rIHRoaXMgb3ZlciBhbmQgc3VnZ2VzdCBhbnkgYWRk aXRpb25hbCB0ZXh0IA0KPiA+Pj4gdGhhdCBJIHRoaW5rIG91Z2h0IHRvIGJlIGluY2x1ZGVkLg0K PiA+PiBBcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIHRoZSBhdXRob3JzL1dHIG1hZGUgdGhl IGNhbGwgdG8gbm90IA0KPiA+PiB1c2UgY29uZm9ybWFuY2UgY2FwaXRhbGl6YXRpb24gb3IgcmVm ZXJlbmNlIDIxMTkvODE3NC7CoCBJIHRoaW5rIA0KPiA+PiB0aGlzIHRyYW5zbGF0ZXMgdG8gdGhl IGNvbmZvcm1hbmNlIGxhbmd1YWdlIG5lZWRpbmcgdG8gYmUgYWRkZWQgdG8gDQo+ID4+IHRoZSBk YXRhIHBsYW5lIHNvbHV0aW9uIGRvY3VtZW50cy4NCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+Pg0K PiA+PiBMb3UNCj4gPj4NCj4gPj4NCj4gPj4+IFRoYW5rcywgLS1EYXZpZA0KPiA+Pj4NCj4gPj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IExvdSBCZXJnZXIgW21h aWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjQs IDIwMTggMzoxOCBQTQ0KPiA+Pj4+IFRvOiBCbGFjaywgRGF2aWQ7IErDoW5vcyBGYXJrYXM7IERl dE5ldCBXRw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1h cmNoaXRlY3R1cmUtMTANCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gW0VYVEVSTkFMIEVNQUlMXQ0K PiA+Pj4+DQo+ID4+Pj4gSGkgRGF2aWQsDQo+ID4+Pj4NCj4gPj4+PiBPbiAxMi8xOS8yMDE4IDEy OjM3IFBNLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ID4+Pj4+IEphbm9zLA0KPiA+Pj4+Pg0KPiA+ Pj4+PiBUaGUgdGVybWlub2xvZ3kgaXMgZGVmaW5pdGVseSBpbXByb3ZlZCAtIHRoZSByZXN1bHRp bmcgZHJhZnQgaXMgDQo+ID4+Pj4+IG11Y2ggY2xlYXJlciAtIG1hbnkgdGhhbmtzIHRvIHlvdSBh bmQgdGhlIGF1dGhvcnMgZm9yIGRvaW5nIHRoYXQuDQo+ID4+Pj4gSGFwcHkgdG8gaGVhciB0aGF0 Lg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gV2hlcmUgZG8gd2Ugc3RhbmQgb24gdGhlIGNvbmNl cm4gYWJvdXQgcHJvdGVjdGluZyBleHRlcm5hbCANCj4gPj4+Pj4gbm9uLURldE5ldCBuZXR3b3Jr cyBmcm9tIERldE5ldCBmbG93cyB0aGF0IGVzY2FwZSBhIERldE5ldCANCj4gPj4+Pj4gbmV0d29y aywgZS5nLiwgZHVlIHRvIGFuIGVycm9uZW91cyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gY2hhbmdl Pw0KPiA+Pj4+IEknbSBub3Qgc3VyZSB3ZSBoYXZlIGdlbmVyYWwgc29sdXRpb25zIGluIHRoZSBp bnRlcm5ldCANCj4gPj4+PiBhcmNoaXRlY3R1cmUgZm9yIG1pc3MtY29uZmlndXJlZC9idWdneSBz eXN0ZW1zIG90aGVyIHRoYW4gDQo+ID4+Pj4gZHJvcHBpbmcgdGhlIHBhY2tldHMgb24gdGhlIGZs b29yIChlLmcuLCBkdWUgdG8gbm8gcm91dGUsIG5vIA0KPiA+Pj4+IGxhYmVsLCBvciB0dGwgZXhw aXJ5KS7CoCBXaGF0IHR5cGUgb2YgcHJvdGVjdGlvbiBhcmUgeW91IGxvb2tpbmcgDQo+ID4+Pj4g Zm9yIGhlcmUsIGFuZCBjYW4geW91IHByb3ZpZGUgYSByZWZlcmVuY2UgdG8gdGhlIHR5cGUgb2Yg cm91dGVyIA0KPiA+Pj4+IGJlaGF2aW9yIHlvdSB3b3VsZCBsaWtlIHRvIHNlZT/CoCBJIGhhdmUg YSBzdWdnZXN0aW9uIHRoYXQgbWlnaHQgDQo+ID4+Pj4gYWRkcmVzcyB5b3VyIGNvbmNlcm4gYmVs b3cgZWxhdGVkIHRvIG5vbi1CQ1A0MSBjb25mb3JtYW50IHRyYWZmaWMsIGJ1dCBhbSB1bnN1cmUg aWYgdGhpcyBpcyB3aGF0IHlvdSBhcmUgY29uY2VybmVkIGFib3V0Lg0KPiA+Pj4+DQo+ID4+Pj4+ IE15IGN1cnJlbnQgdmlld3MgYXJlIC4uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGVyZSdzIG5vIHRo cm90dGxpbmcgaW4gRGV0TmV0LCBlLmcuLCB0aGlzIHRleHQgaW4gNC4zLjI6DQo+ID4+Pj4+DQo+ ID4+Pj4+ICAgICAgIFRoZXJlIGlzIG5vIHByb3Zpc2lvbiBpbiBEZXROZXQgZm9yIHRocm90dGxp bmcgRGV0TmV0IGZsb3dzLCBpLmUuLA0KPiA+Pj4+PiAgICAgICB0aGUgdHJhbnNtaXNzaW9uIHJh dGUgY2Fubm90IGJlIHJlZHVjZWQgdmlhIGV4cGxpY2l0IGNvbmdlc3Rpb24NCj4gPj4+Pj4gICAg ICAgbm90aWZpY2F0aW9uIFtSRkMzMTY4XS4gIFRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgYSBEZXRO ZXQgZmxvdywgdG8gYmUNCj4gPj4+Pj4gICAgICAgdXNlZnVsLCBtdXN0IGJlIGRlbGl2ZXJlZCBp biBpdHMgZW50aXJldHkuDQo+ID4+Pj4gV2VsbCBsb29raW5nIGF0IGl0IHRoaXMgd2F5LCB0aGVy ZSBpcyBubyB0aHJvdHRsaW5nIGluIGFueSBJUCANCj4gPj4+PiBuZXR3b3JrIGFzIHRoZSByb3V0 ZXJzIGdlbmVyYXRlIHRoZSBDTiBhbmQgb25seSBkcm9wIHdoZW4gdGhlaXIgDQo+ID4+Pj4gcXVl dWVzIGFyZSBmdWxsIG9yIGltcGxlbWVudGluZyBzb21lIHNvcnQgb2YgUkVELg0KPiA+Pj4+DQo+ ID4+Pj4gSW4gRGV0TmV0IHRoZXJlIGlzIGFuIGV4cGVjdGF0aW9uIHRoYXQgaW50ZXJtZWRpYXRl IG5vZGVzIGRvIG1vcmUgDQo+ID4+Pj4gdGhhbiB0aGlzLsKgIFNwZWNpZmljYWxseSwgc2VlIHNl Y3Rpb24gNC41OiAiUXVldWluZywgU2hhcGluZywgDQo+ID4+Pj4gU2NoZWR1bGluZywgYW5kIFBy ZWVtcHRpb24iIGFuZCBwb2xpY2luZywgd2hpY2ggaXMgbWVudGlvbmVkIGFzIA0KPiA+Pj4+IHJl cXVpcmVtZW50IGluIHNlY3Rpb24gMy4zLjEuDQo+ID4+Pj4NCj4gPj4+Pj4gYW5kIG5vIGFzc3Vy YW5jZSB0aGF0IGFsbCBEZXROZXQtdXNpbmcgYXBwbGljYXRpb25zIHdpbGwgY2Vhc2UgDQo+ID4+ Pj4+IGFuZCBkZXNpc3QgaW4gdGhlIGZhY2Ugb2YgcGFja2V0IGRyb3BzIHRoYXQgaW5kaWNhdGUg Y29uZ2VzdGlvbi4NCj4gPj4+PiBJIHRoaW5rIHRoaXMgaXMgY29ycmVjdC4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4+IFBhY2tldCBSZXBsaWNhdGlvbiBhbmQgRWxpbWluYXRpb24gbWFrZXMgdGhp cyB3b3JzZSB2aWEgaXRzIA0KPiA+Pj4+PiBhYmlsaXR5IHRvDQo+IGhpZGUNCj4gPj4+Pj4gbmV0 d29yayBwYWNrZXQgZHJvcHMgYW5kIGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgZnJvbSBlbmRwb2lu dHMsIA0KPiA+Pj4+PiBlLmcuLCBvZiB0aG9zZSBkcm9wcyBhbmQvb3IgY29uZ2VzdGlvbiBpbmRp Y2F0aW9ucyBvY2N1ciBvbiBvbmx5IA0KPiA+Pj4+PiBvbmUgb2YgdGhlIHBhdGhzIHVzZWQgYnkg cmVwbGljYXRlZCBwYWNrZXRzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgZmlyc3QgcGFyYWdyYXBo IGluIHNlY3Rpb24gMy4zLjIgaXMgYSBnb29kIHN0YXJ0LCBidXQgSSANCj4gPj4+Pj4gdGhpbmsg aXRzIGxvd2VyIGNhc2UgInNob3VsZCIgaXMgdG9vIHdlYWs6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAg ICAgIFJvYnVzdCByZWFsLXRpbWUgc3lzdGVtcyByZXF1aXJlIHRvIHJlZHVjZSB0aGUgbnVtYmVy IG9mIHBvc3NpYmxlDQo+ID4+Pj4+ICAgICAgIGZhaWx1cmVzLiAgRmlsdGVycyBhbmQgcG9saWNl cnMgc2hvdWxkIGJlIHVzZWQgaW4gYSBEZXROZXQgbmV0d29yayB0bw0KPiA+Pj4+PiAgICAgICBk ZXRlY3QgaWYgRGV0TmV0IHBhY2tldHMgYXJlIHJlY2VpdmVkIG9uIHRoZSB3cm9uZyBpbnRlcmZh Y2UsIG9yIGF0DQo+ID4+Pj4+ICAgICAgIHRoZSB3cm9uZyB0aW1lLCBvciBpbiB0b28gZ3JlYXQg YSB2b2x1bWUuICBGdXJ0aGVybW9yZSwgZmlsdGVycyBhbmQNCj4gPj4+Pj4gICAgICAgcG9saWNl cnMgY2FuIHRha2UgYWN0aW9ucyB0byBkaXNjYXJkIHRoZSBvZmZlbmRpbmcgcGFja2V0cyBvciBm bG93cywNCj4gPj4+Pj4gICAgICAgb3IgdHJpZ2dlciBzaHV0dGluZyBkb3duIHRoZSBvZmZlbmRp bmcgZmxvdyBvciB0aGUgb2ZmZW5kaW5nDQo+ID4+Pj4+ICAgICAgIGludGVyZmFjZS4NCj4gPj4+ Pj4NCj4gPj4+Pj4gQXQgYSBtaW5pbXVtLCBJIHRoaW5rIHRoYXQgdGhlIHJlcXVpcmVtZW50IHRv IGRpc2NhcmQgRGV0TmV0IA0KPiA+Pj4+PiB0cmFmZmljIHRoYXQgd291bGQgb3RoZXJ3aXNlIGVz Y2FwZSBhIERldE5ldCBuZXR3b3JrIGhhcyB0byBiZSANCj4gPj4+Pj4gc3RhdGVkIGFzIGEgIk1V U1QiIHJlcXVpcmVtZW50IGZvciBhbnkgRGV0TmV0IG5ldHdvcmsgdGhhdCANCj4gPj4+Pj4gc3Vw cG9ydHMgUGFja2V0IFJlcGxpY2F0aW9uIGFuZCBFbGltaW5hdGlvbiBkdWUgdG8gdGhlIGFiaWxp dHkgDQo+ID4+Pj4+IG9mIHRoYXQgZnVuY3Rpb25hbGl0eSB0byBoaWRlIGNvbmdlc3Rpb24gZnJv bSBlbmRwb2ludHMsIG1ha2luZyANCj4gPj4+Pj4gaXQgaW1wb3NzaWJsZSBmb3IgaGlnaGVyIGxh eWVycyBvZiB0aGUgcHJvdG9jb2wgc3RhY2sgdG8gcmVzcG9uZC4NCj4gPj4+PiBUbyBtZSBjbGVh ciwgeW91ciBhcmUgc3VnZ2VzdGluZyB0aGF0IHRleHQgYmUgYWRkZWQgdG8gc2F5IHRoYXQgDQo+ ID4+Pj4gc2VuZGluZyBkZXRuZXQgdHJhZmZpYyBvdXQgYSBub24tZGV0bmV0IGludGVyZmFjZXMg bXVzdCBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuDQo+ID4+Pj4gSXMgdGhpcyBjb3JyZWN0P8KgIElm IHNvLCBJIHRoaW5rIHRoaXMgaXMgdG9vIGJyb2FkIGNvbnNpZGVyaW5nIA0KPiA+Pj4+IHRoYXQg dGhlcmUgYXJlIG5ldHdvcmtzIHRoYXQgY2FuIHByb3ZpZGVkIHRoZSByZXF1aXJlZCBkZXRuZXQg DQo+ID4+Pj4gZm9yd2FyZGluZyBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBub3QgZGV0bmV0 IHNlcnZpY2UgYXdhcmUgYXMgDQo+ID4+Pj4gaXMgbWVudGlvbmVkIGF0IHRoZSBlbmQgb2Ygc2Vj dGlvbiA0LjMuMi4gKEknbGwgcmVmZXIgdG8gc3VjaCBhcyANCj4gPj4+PiAiRGV0TmV0IHN1cHBv cnRpbmcgbmV0d29ya3MiIGluIHRoZSBuZXh0IHBhcmFncmFwaC4pDQo+ID4+Pj4NCj4gPj4+PiBU aGlzIHNhaWQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0byBtYWtlIGl0IGEgDQo+ ID4+Pj4gcmVxdWlyZW1lbnQgdGhhdCBEZXROZXQgbm9kZXMgbXVzdCBub3QgZm9yd2FyZCB0cmFm ZmljIHRoYXQgDQo+ID4+Pj4gZG9lc24ndCBjb25mb3JtIHdpdGggQkNQNDEgb3ZlciBhIG5ldHdv cmsgdGhhdCBpcyBuZWl0aGVyIGEgDQo+ID4+Pj4gRGV0bmV0IG5ldHdvcmsgb3IgYSBEZXROZXQg c3VwcG9ydGluZyBuZXR3b3JrLsKgIEFsdGhvdWdoIHRoaXMgDQo+ID4+Pj4gd291bGQgcmVxdWly ZSBhIGNoYW5nZSB0byB0aGUgRGV0TmV0IHNlcnZpY2UgbW9kZWwsIGkuZS4swqAgdG8ga25vdyB3 aGljaCB0cmFmZmljIHdhcyBjb25mb3JtYW50L25vbi1jb25mb3JtYW50Lg0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pj4gQmV5b25kIHRoaXMsIEkgdGhpbmsgYSAiU0hPVUxEIiByZXF1aXJlbWVudCB0 byBkaXNjYXJkIERldE5ldCANCj4gPj4+Pj4gdHJhZmZpYyB0aGF0IHdvdWxkIG90aGVyd2lzZSBl c2NhcGUgaXMgbmVlZGVkLCBhbmQgdGhlIHN0YXRlbWVudCANCj4gPj4+Pj4gb2YgdGhhdCByZXF1 aXJlbWVudCBvdWdodCB0byBiZSBjb25uZWN0ZWQgdG8gdGhlIGV4cGxhbmF0aW9uIG9mIA0KPiA+ Pj4+PiBob3cgdG8gaW1wbGVtZW50IHRoYXQgcmVxdWlyZW1lbnQuDQo+ID4+Pj4gSSB0aGluayBh ZGRpbmcgYSBzdGF0ZW1lbnQgb24gb3V0cHV0IGZpbHRlcnMgKGFuZCBwb2xpY2llcnMpIHRvIA0K PiA+Pj4+IHRoaXMgc2VjdGlvbiBpcyByZWFzb25hYmxlLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pj4gVGhlIHRleHQgaW4gU2VjdGlvbiAzLjMuMiBoYXMgYSBsb3Qgb2YgdGhlIGNvbnRlbnQgbmVl ZGVkIC0gZm9yIA0KPiA+Pj4+PiBhIHdvcmtlZCBleGFtcGxlIG9mIHN1Y2ggIlNIT1VMRCIgdGV4 dCwgc2VlIFNlY3Rpb24gNSBvZiBSRkMgDQo+ID4+Pj4+IDc1MTAsIGluIHBhcnRpY3VsYXIgdGhl IGl0ZW1pemVkIGxpc3QgYXQgdGhlIGVuZCBvZiB0aGF0IHNlY3Rpb24gDQo+ID4+Pj4+IGFuZCB0 aGUgcGFyYWdyYXBoIHRoYXQgaW50cm9kdWNlcyB0aGF0IGxpc3Q6DQo+ID4+Pj4+ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTEwI3NlY3Rpb24tNQ0KPiA+Pj4+IElmIEkn bSBub3QgbWlzdGFrZW4sIHN1Y2ggbWVjaGFuaXNtcyBhcmUgYWxyZWFkeSBpbmNsdWRlZCBpbiB0 aGUgDQo+ID4+Pj4gZG9jdW1lbnQgYW5kIHlvdSByZWFsbHkgYXJlIGp1c3QgYXNraW5nIHRoZW0g dG8gYmUgKHJlKWxpc3RlZCB0byANCj4gPj4+PiBlbnN1cmUgdGhhdCB0aGlzIGltcG9ydCBwb2lu dCBpc24ndCBtaXNzZWQuwqAgSXMgdGhpcyBjb3JyZWN0PyANCj4gPj4+PiBCZXNpZGVzIHdoYXQg aXMgbWVudGlvbmVkIGFib3ZlLCBpcyB0aGVyZSBhbnl0aGluZyBlbHNlIG1pc3Npbmc/DQo+ID4+ Pj4NCj4gPj4+PiBUaGFua3MhDQo+ID4+Pj4NCj4gPj4+PiBMb3UNCj4gPj4+Pg0KPiA+Pj4+PiBU aGFua3MsIC0tRGF2aWQNCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4+PiBGcm9tOiBkZXRuZXQgW21haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIA0KPiA+Pj4+Pj4gSsOhbm9zDQo+IEZhcmthcw0KPiA+Pj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBEZWNlbWJlciAxOSwgMjAxOCAxMDo1NCBBTQ0KPiA+Pj4+Pj4gVG86IERl dE5ldCBXRw0KPiA+Pj4+Pj4gU3ViamVjdDogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJj aGl0ZWN0dXJlLTEwDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFtFWFRFUk5BTCBFTUFJ TF0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIaSwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGUgRGV0TmV0 IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBoYXMgYmVlbiB1cGRhdGVkIHRvIGFkZHJlc3MgDQo+ID4+ Pj4+PiB0aGUgY29tbWVudHMuIFRoZSBuZXcgcmV2aXNpb24gKHYxMCkgaXMgYXZhaWxhYmxlIGF0 IA0KPiA+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0 LWFyY2hpdGVjdHVyZS0xMC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGVyZSBoYXZlIGJlZW4gYSBu dW1iZXIgb2YgZGlzY3Vzc2lvbiBpdGVtcyBlbWFpbHMgb24gdGhlIA0KPiA+Pj4+Pj4gbGlzdC4g VGhlIHVwZGF0ZXMgYXJlIGFsb25nIHRoZSBtYWpvciBkaXNjdXNzaW9uIGl0ZW1zLCB3aGljaCAN Cj4gPj4+Pj4+IGFsc28gY292ZXIgdGhlIGRlcml2YXRpdmUgZGlzY3Vzc2lvbnMsIGFkZHJlc3Mg dGhlIGNvbW1lbnRzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBtYWpvciBpdGVtcyBoYXZlIGJl ZW4gc3VtbWFyaXplZCBpbjoNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDE5NjguaHRtbC4NCj4gPj4+Pj4+IEZvbGxvdyB1 cCBkaXNjdXNzaW9ucyBpbXBsaWVkIHRlcm1pbm9sb2d5IGNoYW5nZXMgc3VtbWFyaXplZCBpbjoN Cj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1 cnJlbnQvbXNnMDIwMzYuaHRtbDoNCj4gPj4+Pj4+IHJlcGxhY2UgInRyYW5zcG9ydCBzdWItbGF5 ZXIiIHdpdGggImZvcndhcmRpbmcgc3ViLWxheWVyIg0KPiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMjAzOC5odG1sOg0KPiA+ Pj4+Pj4gcmVwbGFjZSAiY29uZ2VzdGlvbiBwcm90ZWN0aW9uIiB3aXRoICJyZXNvdXJjZSIgYWxs b2NhdGlvbiINCj4gPj4+Pj4+IENvbnNlcXVlbnRseSwgdGhlIGRvY3VtZW50IGhhZCBhIGdvb2Qg J3NjdXJiIi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJbiBhZGRpdGlvbiwgb3V0c3RhbmRpbmcgY29t bWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBhbG9uZyANCj4gPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDE5NDMuaHRtbC4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGNvbW1lbnQgaGFwcGVu ZWQgdG8gYmUgcmVtYWluZWQgb3Blbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMs DQo+ID4+Pj4+PiBKYW5vcw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+PiBkZXRuZXQgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+PiBkZXRuZXRAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4g Pj4+Pj4gZGV0bmV0QGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGV0bmV0DQo+ID4+Pj4+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZGV0bmV0IG1haWxpbmcgbGlzdA0KZGV0bmV0QGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0K From nobody Fri Jan 11 01:36:55 2019 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 9708E128CB7 for ; Fri, 11 Jan 2019 01:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 header.b=frd+Q5o3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=buCS1MEr 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 a9VxCwrbSyQv for ; Fri, 11 Jan 2019 01:36:51 -0800 (PST) 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 81E4A12DD85 for ; Fri, 11 Jan 2019 01:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547199408; x=1549791408; 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=tKrODoMK00/MabIZ0c+NYs7ksc8zmWoK50OH3IO0Z1U=; b=frd+Q5o3Ti8tsDaFM1Y83LJ7q1Cmw8mv5mnL4BPWGF0T5USZyTV6vko6lha1t+CJ 8jCcp3ysto0x1JeH8nlhCqIomu9VfNs5COQB1vQ8/l4GpwWEo0Aanva4dbfdH3Ip pqqSQrkOukLqLYZCTpaodC8xUukcUjUrinSsgZJdHk4=; X-AuditID: c1b4fb2d-2198b9e00000062f-de-5c3863b06afd Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.5E.01583.0B3683C5; Fri, 11 Jan 2019 10:36:48 +0100 (CET) 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; Fri, 11 Jan 2019 10:36:46 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Fri, 11 Jan 2019 10:36:45 +0100 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=tKrODoMK00/MabIZ0c+NYs7ksc8zmWoK50OH3IO0Z1U=; b=buCS1MErmuB6hpKGBnFj/boUQfxywwxUkXDj3jEY/JhHoqll2uu8gohkeh472+44zbJDuxu8Z9B/vDrZQ6OtyaBomTGzqwVMZtReCXq34fkPCL28MeWCJzHxi7GuFurSKYLewhj+VebWEoS+IWrCxrUFpZzS2IOwoke4MReTbno= Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com (10.169.152.15) by AM5PR0701MB2962.eurprd07.prod.outlook.com (10.168.156.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Fri, 11 Jan 2019 09:36:44 +0000 Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36]) by AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36%2]) with mapi id 15.20.1537.013; Fri, 11 Jan 2019 09:36:43 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: Norman Finn , "Andrew G. Malis" , Lou Berger CC: detnet WG , Janos Farkas , "Black, David" Thread-Topic: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) Thread-Index: AQHUm8axlQxqvWEDxkeaQEj+Jds84KWOVmYAgBUUCICABn0QsA== Date: Fri, 11 Jan 2019 09:36:43 +0000 Message-ID: References: , <3DF0466E9510274382F5B74499ACD6F801720DDC@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F801720DDC@lhrpml504-mbx.exmail.huawei.com> 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: [92.249.253.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2962; 6:QsqmMQTmpH4Rbw9JZRJ9ZYJijF3zawYSC7bUkM2TIDky9UISA28mr68A1rvo7UH/7vP4pCWwBk6bD5b3bNoByzqJEovU0eEahmi0WWAfSUZkBBZlW/xhXFmyuVLLbTMXESo/xbMl1hyvrThA9f1feMH7abmOaxSxU/K/x7/9MLxfEOI8Q12PtIoEXYVd2FJnqylk60n7Whxmu/TjXhSbjKFlgpy0o8Jv4QgPpJA30NVyVlwx+qCSIC6Wtsj1b0F0MHpe7z5S1RAQT8BA7qM0dJixGSBg52Cyf01+shdHuwwLbf4kBekqScVADrCbIVN39bnJW13qNoXIPeJKW3i2Ir6SqRScCum+SrGZSggdrVQ3sQW/a/teFy0ID40elSTWTHB76ZqpbQvTn9sdsNkOmuqZdYa90WH0RI5zrIbkXfcq/xK488s2XOf6Ys9i6HbQu5QUFZgGm4VqbQO8pL/22g==; 5:zDcwhpL3PyQ+6KMMXOXcKz/mY4ES9eUGulpUQBNrJH4jFrcOCKAkmyJ32qfb+4PXO0zW59vSaK2xNuFA7OIVUZWafBgop/73V0BCEhoXp2l20YZRAtW7fvxdeiGV9zCvRHYO9So3k6Hwt3+Fr5OyW7GtLc7Hpsqd+CXcYQttmS5yrEU2ROWSN4g2f/upustRO/aqtc6XclTynpFlJnxu+A==; 7:RW/WyqNXw1pNS524pogUIG/s0fyu6aEDTAjY8/buAEaJQKnYI5XMo1dJvWEjA5yKl9xwOKgCr5rs9hjQ+nsGwbu0jLBBW6uPX9kdUGCqVwr9KHXy6dHd5tv8OMBhIQvvTIK2CHh3hmNMammxWQNBvw== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(376002)(396003)(189003)(199004)(110136005)(68736007)(74316002)(54906003)(105586002)(71190400001)(71200400001)(102836004)(6506007)(53546011)(9326002)(8676002)(11346002)(186003)(8936002)(93886005)(26005)(76176011)(446003)(9686003)(86362001)(66066001)(99286004)(6306002)(54896002)(316002)(7696005)(7736002)(236005)(55016002)(5660300001)(53936002)(486006)(39060400002)(478600001)(66574012)(2906002)(4326008)(229853002)(33656002)(106356001)(14454004)(6246003)(3846002)(256004)(14444005)(6436002)(25786009)(790700001)(81166006)(476003)(97736004)(81156014)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2962; H:AM5PR0701MB2292.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: a22fe2df-5104-4a39-a668-08d677a84c38 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2962; x-ms-traffictypediagnostic: AM5PR0701MB2962: x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DmRF4NgUUZkj+Wjp6N0iVY7UmfCvhq1I5dDbR000ySGLeKCAFd1vEC1XCb/FYWwuEm120Qu+FybRP63KUCa31VWmTyTuMPJrQ8GlkeHfK6ofKxdgfDzc8mPx2viSnZBRpdtpsjPJkjxUZYMVJ7uJ70nTyOJXNrekeBVl79sYKgKu7hZf+ACnEQlPRaIAtx7WQTQ+pSoCKkUWzSdtfG/GkDNZXn1+/9UkkKakaEltvI/Qu3xHphYd8yfk92u29Vobr45zJUN1csiEjutwYhmMcu+5kczICe1MGxXBIKunq5fuHm9oRXai/OOaIozx0vAGCWBwUJkmMUg9luW5avRhSINdthZRDjz9xMnhZiI1iZQ/k6xM291YJRI415gP36nlWd1kW25LMcZC8Lwa7l+AkCV2gJT0ep5BdmXG8euhU3c= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2292FE60CF854E74F1EC7F37AC850AM5PR0701MB2292_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a22fe2df-5104-4a39-a668-08d677a84c38 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 09:36:43.5635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2962 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyxVYRjHe+8595xD7hw38kz5o2u2Ji5Kdf5o1q/b7vppbaU1K3ecIVyc I6K15EcTWw5judq4IpG1yY9hkVAJyxV/JK10sWTys4ZGlntfbf77Pt/P87zf93n3MoTyndyF idDH84JeF6WibEnDpcZEr5oQLsinQHLjeid6KG6+qIzkVhYeklxm2jTJVbzplR2Wa/MMhYS2 uegLrS0v/yPTztWmUdqmum/yAPll20OhfFREAi94+wfbhldm9NGxJXE3Kl9lkCmoLSQL2TDA +sGToRmUhWwZJfsaQfXb+zQuFhHMLnbKcFEuA2lulLKMkKxEQEO7IwaFMmhqnSZw8R1BlmmI tnRRrAZ+ZZqtE45sInxK7UcWTbACdGbMW3u2sbEgmZbWI5j1nji483E7bj8KuY8ebIS5w4uW x1atYINhtT+HxFm5BDSWjpEWYMMGQv34Gmk5B7GuYH7G4ShnGB4vkeE9WShvMRFYO8Hk2Jrc ohF7BVbaUjb8XdCXMUJi7QoDJdnWdwE2nYb3koHCwBe6qtoIDEopWKr7SmNwBnLaxikMBhCM DHQjDDxhsilvIyIGUuZnN/ydkFWbhySkLtp0W6xjoLDsL11k3doBug3jJPbVMFSQT2G9BypK pwisvaBwrYPc7BsR/RQ5ibwoRoft3afmhYgQUYzRq/V8fC1a/1/t9SteTah66kgHYhmkslNo znNBSrkuQUyK7kDAECpHhfz4uqUI1SUl80LMVeF6FC92oB0MqXJWrCodgpRsmC6ej+T5WF74 T2WMjUsKKtYbtfnFmt8KN0aaCZpQbj3V5V+3xcc887n5pHDAMJS+PM2F9dpH0jW3as8mmFbM ownzp4efC3cDfzqPjuSfkIyd1/R+P+xNHhdcJm96e+4P8SEPnnMvES/a9WiNbqnJkmd6ABwb zN2t0czoGuS31VWtC9VgHmypX355L/uDihTDdb4ehCDq/gEu9EePWwMAAA== Archived-At: Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) 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, 11 Jan 2019 09:36:54 -0000 --_000_AM5PR0701MB2292FE60CF854E74F1EC7F37AC850AM5PR0701MB2292_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Norm, > 1. You may well need more than one DSCP for DetNet region for different c= lasses of service. Yes, and we have defined the 6-tupple match for flow identification, what a= llows multiple DSCP values. > 2. You don't want to discard unexpected packets with a DetNet DSCP -- you= want to remark > them to a non-DSCP code point. Not good if configuring (or misconfigurin= g) a QoS feature > destroys a bystander's connectivity. That is an interesting topic. What do You mean by "unexpected packet"? If i= t breaks the traffic profile we must drop. I am not sure remarking is a good idea. What = do You mean by "non-DSCP code point"? General, I think configuration errors may destroy DetNet (and any other) fl= ows connectivity. We have to live with that. You can mitigate them e.g., by "proper maintenan= ce procedures", etc. That points to the importance of DetNet OAM being able to detect confi= guration (and other) errors. Cheers Bala'zs From: detnet On Behalf Of Norman Finn Sent: Monday, January 7, 2019 7:20 AM To: Andrew G. Malis ; Lou Berger Cc: detnet WG ; Janos Farkas ; = Black, David Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) 1. You may well need more than one DSCP for DetNet region for different cla= sses of service. 2. You don't want to discard unexpected packets with a DetNet DSCP -- you w= ant to remark them to a non-DSCP code point. Not good if configuring (or m= isconfiguring) a QoS feature destroys a bystander's connectivity. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmali= s@gmail.com] Sent: Monday, December 24, 2018 12:26 PM To: Lou Berger Cc: detnet WG; Black, David; J=E1nos Farkas Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Lou, Thanks for following up. Cheers, Andy On Mon, Dec 24, 2018 at 3:24 PM Lou Berger > wrote: Andy, Just following up on one point on DetNet-specific DSCPs: On 12/19/2018 1:11 PM, Andrew G. Malis wrote: > In that case, the DetNet flows would most probably be a using > DetNet-specific DSCP, and if the ingress interface isn't properly > provisioned to know how to process packets with that DSCP, they'll at > least be reduced to best-effort treatment.. We can also recommend that > packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such packets= . While I personally think use of DSCPs will be useful in supporting aggregated DetNet flows, the IP solution draft has no requirement that operators or vendors restrict DetNet flows to a specific DSCP value. -- I personally think this is an important design point. Happy Holidays! Lou --_000_AM5PR0701MB2292FE60CF854E74F1EC7F37AC850AM5PR0701MB2292_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Norm,

 

> 1. You may well need more than one = DSCP for DetNet region for different classes of service.<= /p>

Yes, and we have defined the 6-tupple ma= tch for flow identification, what allows multiple DSCP

values.

 

> 2. You don't want to discard unexpe= cted packets with a DetNet DSCP -- you want to remark

> them to a non-DSCP code point. = ; Not good if configuring (or misconfiguring) a QoS feature

> destroys a bystander's connectivity= .

That is an interesting topic. What do Yo= u mean by “unexpected packet”? If it breaks the

traffic profile we must drop. I am not s= ure remarking is a good idea. What do You mean by

“non-DSCP code point”?<= /o:p>

 

General, I think configuration errors ma= y destroy DetNet (and any other) flows connectivity.

We have to live with that. You can mitig= ate them e.g., by “proper maintenance procedures”,

etc. That points to the importance of De= tNet OAM being able to detect configuration (and

other) errors.

 

Cheers

Bala’zs

 

From: detnet <detnet-bounces@ietf.org> = On Behalf Of Norman Finn
Sent: Monday, January 7, 2019 7:20 AM
To: Andrew G. Malis <agmalis@gmail.com>; Lou Berger <lberge= r@labn.net>
Cc: detnet WG <detnet@ietf.org>; Janos Farkas <Janos.Farkas= @ericsson.com>; Black, David <David.Black@dell.com>
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

 

1. You may well need more than one DSCP = for DetNet region for different classes of service.

2. You don't want to discard unexpected = packets with a DetNet DSCP -- you want to remark them to a non-DSCP code po= int.  Not good if configuring (or misconfiguring) a QoS feature destroys a bystander's connectivity.

 

-- Norm

 

From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmalis@gmail.com]
Sent: Monday, December 24, 2018 12:26 PM
To: Lou Berger
Cc: detnet WG; Black, David; J=E1nos Farkas
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

Lou,

 

Thanks for following up.<= /span>

 

Cheers,

Andy

 

 

On Mon, Dec 24, 2018 at 3:24 PM Lou = Berger <lberger@la= bn.net> wrote:

Andy,=

Just following up on one point on DetNet-specific DSCPs:

On 12/19/2018 1:11 PM, Andrew G. Malis wrote:
> In that case, the DetNet flows would most probably be a using
> DetNet-specific DSCP, and if the ingress interface isn't properly
> provisioned to know how to process packets with that DSCP, they'll at =
> least be reduced to best-effort treatment.. We can also recommend that=
> packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such pack= ets.

While I personally think use of DSCPs will be useful in supporting
aggregated DetNet flows, the IP solution draft has no requirement that
operators or vendors restrict DetNet flows to a specific DSCP value.  = --
I personally think this is an important design point.

Happy Holidays!

Lou

--_000_AM5PR0701MB2292FE60CF854E74F1EC7F37AC850AM5PR0701MB2292_-- From nobody Fri Jan 11 10:16:30 2019 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 322B5127AC2 for ; Fri, 11 Jan 2019 10:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=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 nxaZnUih7pOI for ; Fri, 11 Jan 2019 10:16:25 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4F51277CC for ; Fri, 11 Jan 2019 10:16:24 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8A568548080; Fri, 11 Jan 2019 19:16:19 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 78C70440210; Fri, 11 Jan 2019 19:16:19 +0100 (CET) Date: Fri, 11 Jan 2019 19:16:19 +0100 From: Toerless Eckert To: Bal?zs Varga A Cc: "Black, David" , Lou Berger , Janos Farkas , DetNet WG Message-ID: <20190111181619.fz7dosbqbgyt55uj@faui48f.informatik.uni-erlangen.de> References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 11 Jan 2019 18:16:28 -0000 I really don't know what the benefit of this text would be. IMHO it is mostly IESG code language but not really helpfull IMHO. Something like Googles worldwide network could support DetNet if Google wanted to ?! Its a private WAN, right ? Aka: there is no physcial scale limitation, right ? Why don't we say that ? What is a "large number of domains" ? How about a nationwide research network such as Internet 2 with hundreds of attached organizations. If Internet2 introduced DetNet services and allowed interested Internet2 participants to participate in it, extending DetNet services into their couses ? How about a nationwide service provider and its customers ? We do want DetNet service, right ? The only real requirement for DetNet between A and B is that all transit domains between A and B support DetNet. This is fundamentally not different from the requirement to make ECN work. As soon as i have a single hop along a path not supporting ECN, my ECN based congestion control will have to fall back to delay-variation or loss-based. And ECN is defined to be an Internet technology. So why would DetNet not be ? "When we finally get to DetNet Control Plane, we don't want to bother with all the complexity of multi-operator control plane because its hard enough to figure out how to make one DetNet SDN controller work" Thats one possible honest exlanation, but given how i think we can not precdit what type of multi-opeator environments control plane the community will have interest to work on over time, it might be more appropriate to say that and not to come up with an underspecified binary distinction of what is and what is not DetNet. Cheers Toerless On Fri, Jan 11, 2019 at 09:18:37AM +0000, Bal?zs Varga A wrote: > Great. I am fine to add these explicit statements to make text more clear. > > New text is inline with the general statement in the introduction of the draft: > " 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. " > > Cheers > Bala'zs > > Ps: Also, note that "DetNet flows" are unidirectional ... :---)))) > > -----Original Message----- > From: detnet On Behalf Of Black, David > Sent: Tuesday, January 8, 2019 6:46 PM > To: Lou Berger ; Janos Farkas ; DetNet WG > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > That's fine and what was intended. > > Thanks, --David > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Monday, January 7, 2019 4:49 PM > > To: Black, David; János Farkas; DetNet WG > > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > > > > [EXTERNAL EMAIL] > > > > David, > > > >     This looks good/right to me.  The only specific change I'd add is > > to clarify that we're talking PEROF traffic when saying "DetNet > > replicated traffic". > > > > Thanks! > > > > Lou > > > > On 1/7/2019 10:44 AM, Black, David wrote: > > > Lou, > > > > > > Attempting to summarize what needs to be stated without using > > MUST/SHOULD/MAY: > > > > > > [1] Sending DetNet traffic into networks that have not been > > > provisioned in > > advance to handle that DetNet traffic has to be treated as a fault. > > Egress traffic filters to prevent this from happening are strongly > > recommended at the edges of DetNet networks and DetNet supporting > > networks. In this context, the term 'provisioned' has a broad > > meaning, e.g., provisioning could be performed via an administrative > > decision that the downstream network has the available capacity to carry the DetNet traffic that is being sent into it. > > > > > > [2] Sending non-congestion-controlled DetNet traffic (i.e., DetNet > > > traffic that > > does not comply with BCP 41/RFC 2914) into a network that is not > > provisioned to handle that traffic has to be prevented in addition to being treated as a fault. > > DetNet traffic that is not known to be congestion controlled has to be > > treated as non-congestion-controlled DetNet traffic for this > > requirement. DetNet replicated traffic is always > > non-congestion-controlled even if the original DetNet flow is > > congestion-controlled because DetNet packet elimination can hide > > congestion indications (e.g., drops, ECN CE marks, increased latency) > > from endpoints. The responsibility for dealing with these > > requirements in general, and replicated traffic in particular, is > > solution-specific, as there are MPLS mechanisms that cannot be applied to the IP solution, and moreover, the current IP solution doesn't support DetNet traffic replication. > > > > > > Thanks, --David > > > > > >> -----Original Message----- > > >> From: Lou Berger [mailto:lberger@labn.net] > > >> Sent: Tuesday, December 25, 2018 11:45 AM > > >> To: Black, David; János Farkas; DetNet WG > > >> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > >> > > >> > > >> [EXTERNAL EMAIL] > > >> > > >> Hi David, > > >> > > >> On 12/24/2018 8:29 PM, Black, David wrote: > > >>> Hi Lou, > > >>> > > >>> Excerpting key paragraphs ... > > >>> > > >>>> To me clear, you are suggesting that text be added to say that > > >>>> sending detnet traffic out a non-detnet interfaces must be treated as a fault. > > >>>> Is this correct? > > >>> Not exactly ... > > >>> > > >>>> If so, I think this is too broad considering that there are > > >>>> networks that can provided the required detnet forwarding > > >>>> sub-layer service that are not detnet service aware as is > > >>>> mentioned at the end of section 4.3.2. (I'll refer to such as > > >>>> "DetNet supporting networks" in the next paragraph.) > > >>> I agree with where this is headed - sending DetNet traffic into a > > >>> network that has not been provisioned to provide the required > > >>> detnet forwarding service to that traffic has to be treated as a > > >>> fault. In this statement, "provisioned" should be read broadly, > > >>> e.g., it could be realized via an administrative decision that the > > >>> DetNet supporting network has the available capacity to carry the DetNet traffic that is being sent into it. > > >> agreed. > > >>>> This said, I think it would be reasonable to make it a > > >>>> requirement that DetNet nodes must not forward traffic that > > >>>> doesn't conform with BCP41 over a network that is neither a > > >>>> Detnet network or a DetNet supporting network. Although this > > >>>> would require a change to the DetNet service model, i.e., to know which traffic was conformant/non-conformant. > > >>> That's fine with one important twist: > > >>> > > >>> Any traffic that has been replicated by DetNet packet replication > > >>> has to be treated as not conforming with BCP41 because DetNet > > >>> packet elimination (of replicated packets) may hide congestion > > >>> indications (e.g., delay, ECN CE marks, drops) from the endpoints > > >>> - a scenario of particular concern involves the other flow of > > >>> replicated packets following a DetNet network path along which nothing goes wrong. > > >>> BCP41 is about end-to-end-congestion control, which does not do > > >>> anything if DetNet packet elimination hides congestion indications > > >>> from the endpoints. > > >> This seems reasonable to me. > > >> > > >> > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > >>>>> traffic that would otherwise escape is needed, and the statement > > >>>>> of that requirement ought to be connected to the explanation of > > >>>>> how to implement that requirement. > > >>>> I think adding a statement on output filters (and policers) to > > >>>> this section is reasonable. > > >>> Let's start with the inclusion of output filters (and policers) in > > >>> the 3.3.2 text with the use of upper-case "SHOULD" as suggested by > > >>> Pascal - I will look this over and suggest any additional text > > >>> that I think ought to be included. > > >> As an architecture document, the authors/WG made the call to not > > >> use conformance capitalization or reference 2119/8174.  I think > > >> this translates to the conformance language needing to be added to > > >> the data plane solution documents. > > >> > > >> Cheers, > > >> > > >> Lou > > >> > > >> > > >>> Thanks, --David > > >>> > > >>>> -----Original Message----- > > >>>> From: Lou Berger [mailto:lberger@labn.net] > > >>>> Sent: Monday, December 24, 2018 3:18 PM > > >>>> To: Black, David; János Farkas; DetNet WG > > >>>> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > >>>> > > >>>> > > >>>> [EXTERNAL EMAIL] > > >>>> > > >>>> Hi David, > > >>>> > > >>>> On 12/19/2018 12:37 PM, Black, David wrote: > > >>>>> Janos, > > >>>>> > > >>>>> The terminology is definitely improved - the resulting draft is > > >>>>> much clearer - many thanks to you and the authors for doing that. > > >>>> Happy to hear that. > > >>>> > > >>>> > > >>>>> Where do we stand on the concern about protecting external > > >>>>> non-DetNet networks from DetNet flows that escape a DetNet > > >>>>> network, e.g., due to an erroneous network configuration change? > > >>>> I'm not sure we have general solutions in the internet > > >>>> architecture for miss-configured/buggy systems other than > > >>>> dropping the packets on the floor (e.g., due to no route, no > > >>>> label, or ttl expiry).  What type of protection are you looking > > >>>> for here, and can you provide a reference to the type of router > > >>>> behavior you would like to see?  I have a suggestion that might > > >>>> address your concern below elated to non-BCP41 conformant traffic, but am unsure if this is what you are concerned about. > > >>>> > > >>>>> My current views are ... > > >>>>> > > >>>>> There's no throttling in DetNet, e.g., this text in 4.3.2: > > >>>>> > > >>>>> There is no provision in DetNet for throttling DetNet flows, i.e., > > >>>>> the transmission rate cannot be reduced via explicit congestion > > >>>>> notification [RFC3168]. The assumption is that a DetNet flow, to be > > >>>>> useful, must be delivered in its entirety. > > >>>> Well looking at it this way, there is no throttling in any IP > > >>>> network as the routers generate the CN and only drop when their > > >>>> queues are full or implementing some sort of RED. > > >>>> > > >>>> In DetNet there is an expectation that intermediate nodes do more > > >>>> than this.  Specifically, see section 4.5: "Queuing, Shaping, > > >>>> Scheduling, and Preemption" and policing, which is mentioned as > > >>>> requirement in section 3.3.1. > > >>>> > > >>>>> and no assurance that all DetNet-using applications will cease > > >>>>> and desist in the face of packet drops that indicate congestion. > > >>>> I think this is correct. > > >>>> > > >>>> > > >>>>> Packet Replication and Elimination makes this worse via its > > >>>>> ability to > > hide > > >>>>> network packet drops and congestion indications from endpoints, > > >>>>> e.g., of those drops and/or congestion indications occur on only > > >>>>> one of the paths used by replicated packets. > > >>>>> > > >>>>> The first paragraph in section 3.3.2 is a good start, but I > > >>>>> think its lower case "should" is too weak: > > >>>>> > > >>>>> 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 a volume. Furthermore, filters and > > >>>>> policers can take actions to discard the offending packets or flows, > > >>>>> or trigger shutting down the offending flow or the offending > > >>>>> interface. > > >>>>> > > >>>>> At a minimum, I think that the requirement to discard DetNet > > >>>>> traffic that would otherwise escape a DetNet network has to be > > >>>>> stated as a "MUST" requirement for any DetNet network that > > >>>>> supports Packet Replication and Elimination due to the ability > > >>>>> of that functionality to hide congestion from endpoints, making > > >>>>> it impossible for higher layers of the protocol stack to respond. > > >>>> To me clear, your are suggesting that text be added to say that > > >>>> sending detnet traffic out a non-detnet interfaces must be treated as a fault. > > >>>> Is this correct?  If so, I think this is too broad considering > > >>>> that there are networks that can provided the required detnet > > >>>> forwarding sub-layer service that are not detnet service aware as > > >>>> is mentioned at the end of section 4.3.2. (I'll refer to such as > > >>>> "DetNet supporting networks" in the next paragraph.) > > >>>> > > >>>> This said, I think it would be reasonable to make it a > > >>>> requirement that DetNet nodes must not forward traffic that > > >>>> doesn't conform with BCP41 over a network that is neither a > > >>>> Detnet network or a DetNet supporting network.  Although this > > >>>> would require a change to the DetNet service model, i.e.,  to know which traffic was conformant/non-conformant. > > >>>> > > >>>> > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > >>>>> traffic that would otherwise escape is needed, and the statement > > >>>>> of that requirement ought to be connected to the explanation of > > >>>>> how to implement that requirement. > > >>>> I think adding a statement on output filters (and policiers) to > > >>>> this section is reasonable. > > >>>> > > >>>> > > >>>>> The text in Section 3.3.2 has a lot of the content needed - for > > >>>>> a worked example of such "SHOULD" text, see Section 5 of RFC > > >>>>> 7510, in particular the itemized list at the end of that section > > >>>>> and the paragraph that introduces that list: > > >>>>> https://tools.ietf.org/html/rfc7510#section-5 > > >>>> If I'm not mistaken, such mechanisms are already included in the > > >>>> document and you really are just asking them to be (re)listed to > > >>>> ensure that this import point isn't missed.  Is this correct? > > >>>> Besides what is mentioned above, is there anything else missing? > > >>>> > > >>>> Thanks! > > >>>> > > >>>> Lou > > >>>> > > >>>>> Thanks, --David > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of > > >>>>>> János > > Farkas > > >>>>>> Sent: Wednesday, December 19, 2018 10:54 AM > > >>>>>> To: DetNet WG > > >>>>>> Subject: [Detnet] draft-ietf-detnet-architecture-10 > > >>>>>> > > >>>>>> > > >>>>>> [EXTERNAL EMAIL] > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> The DetNet architecture document has been updated to address > > >>>>>> the comments. The new revision (v10) is available at > > >>>>>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. > > >>>>>> > > >>>>>> There have been a number of discussion items emails on the > > >>>>>> list. The updates are along the major discussion items, which > > >>>>>> also cover the derivative discussions, address the comments. > > >>>>>> > > >>>>>> The major items have been summarized in: > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. > > >>>>>> Follow up discussions implied terminology changes summarized in: > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: > > >>>>>> replace "transport sub-layer" with "forwarding sub-layer" > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: > > >>>>>> replace "congestion protection" with "resource" allocation" > > >>>>>> Consequently, the document had a good 'scurb". > > >>>>>> > > >>>>>> In addition, outstanding comments have been addressed along > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. > > >>>>>> > > >>>>>> Please let us know if any comment happened to be remained open. > > >>>>>> > > >>>>>> Best 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 -- --- tte@cs.fau.de From nobody Fri Jan 11 13:44:43 2019 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 4DB27128B14 for ; Fri, 11 Jan 2019 13:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JHiRNhb9sLJS for ; Fri, 11 Jan 2019 13:44:36 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 52EF712958B for ; Fri, 11 Jan 2019 13:44:36 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id y16so7413543qki.7 for ; Fri, 11 Jan 2019 13:44:36 -0800 (PST) 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=tliMBAEiYUL6eChB0dZ/Az28GdYlaTEXsJm7CrZv0AQ=; b=OEpDFKWOOVJOqj37DBP4x+Nt3vkYDmUdQjN7m1B9yCdRXt4aU9Oo8XMVrVArLEzspK XNLgsr81NIMVPmpJZXwQ3IsgkP/7OEC0rHu8K1XrW1HXc887WpUykuevMEpiuCNTfxR2 GNcPIw5iKN/hM2FlFT3kZoK6cNkb5arHpntPhaeEtikuAsclioe5HMFs2t/Y4l3yw2rS 9JiRXXpU0+VUbumai1hgddwvMyk1clcsYATTSLoli6f3VotUlREdUgPCQDFZcOA0W4EP +fXxWmiDog/Kfw+/pob16clV/DrABZVoX+ZucooiCBtKG7O51bkScOqTzyl5Xm8Bd17f 3LrA== 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=tliMBAEiYUL6eChB0dZ/Az28GdYlaTEXsJm7CrZv0AQ=; b=r+4Y2xMOa4KF1qtzzx9Rf/SiHqkehjcTq/EyxFz1vS9R9aDhib5MwKYe6HnpXWKiCD Yj0+KZQ68v1o3IOKMCICDKoMAwyQvWvAALIYp3OB6B9f0vgBM1Kd99voNcdv4+pS6XrP pAZC76GLwOHaCVTbyoQwG97L7o2Nb+cvCYtzgGCqzUshVhEvRsc4ZOYk5Jxp2mGUSIot B9jMtw4JZ4dqOD8ZDeNxS2p/oEssR0fXywL45V1pmJmPLr8fZ/bwLbxs5oCVea5MFI39 WMKytBr2bO+nIxd0ejvv2A3Spu2I3dfnH+Yw145lyWY/JavvIHazvsOoo+EPV9JvuhnI Whlg== X-Gm-Message-State: AJcUukeMFs55p7b2e/4aMSFzANDsY85xqy+VgKVxouzlDaxOyplS06Uj xtghVmH3hRImldhcTd4ZeQo/oX5U0uFi/tjp31w= X-Google-Smtp-Source: ALg8bN4BOMksaB2WiF9UKlU9Gh35CNbnBzvNyHd6Tjx1T42BfZE64x+7H+prutJgLjiKcyAvwadPoQ6YWqJAWUsgrI0= X-Received: by 2002:a37:99c5:: with SMTP id b188mr15225103qke.100.1547243075169; Fri, 11 Jan 2019 13:44:35 -0800 (PST) MIME-Version: 1.0 References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> <20190111181619.fz7dosbqbgyt55uj@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190111181619.fz7dosbqbgyt55uj@faui48f.informatik.uni-erlangen.de> From: "Andrew G. Malis" Date: Fri, 11 Jan 2019 16:44:23 -0500 Message-ID: To: Toerless Eckert Cc: "Bal?zs Varga A" , DetNet WG , "Black, David" , Janos Farkas , Lou Berger Content-Type: multipart/alternative; boundary="000000000000e073cf057f3599b2" Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 11 Jan 2019 21:44:41 -0000 --000000000000e073cf057f3599b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Toerless, We could certainly truthfully say that it's not intended for the multidomain best-effort public Internet infrastructure. Cheers, Andy On Fri, Jan 11, 2019 at 1:16 PM Toerless Eckert wrote: > I really don't know what the benefit of this text would be. IMHO it is > mostly IESG code language but not really helpfull IMHO. > > Something like Googles worldwide network could support DetNet if Google > wanted to ?! Its a private WAN, right ? Aka: there is no physcial scale > limitation, right ? Why don't we say that ? > > What is a "large number of domains" ? How about a nationwide research > network such as Internet 2 with hundreds of attached organizations. If > Internet2 introduced DetNet services and allowed interested Internet2 > participants to participate in it, extending DetNet services into their > couses ? How about a nationwide service provider and its customers ? > We do want DetNet service, right ? > > The only real requirement for DetNet between A and B is that all transit > domains between A and B support DetNet. This is fundamentally not > different from the requirement to make ECN work. As soon as i have a > single hop along a path not supporting ECN, my ECN based congestion > control will have to fall back to delay-variation or loss-based. And ECN = is > defined to be an Internet technology. So why would DetNet not be ? > > "When we finally get to DetNet Control Plane, we don't want to bother > with all the complexity of multi-operator control plane because its > hard enough to figure out how to make one DetNet SDN controller work" > > Thats one possible honest exlanation, but given how i think we can not > precdit what type of multi-opeator environments control plane the > community will have interest to work on over time, it might be more > appropriate to say that and not to come up with an underspecified binary > distinction of what is and what is not DetNet. > > Cheers > Toerless > > On Fri, Jan 11, 2019 at 09:18:37AM +0000, Bal?zs Varga A wrote: > > Great. I am fine to add these explicit statements to make text more > clear. > > > > New text is inline with the general statement in the introduction of th= e > draft: > > " 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. DetNe= t > > is not for large groups of domains such as the Internet. " > > > > Cheers > > Bala'zs > > > > Ps: Also, note that "DetNet flows" are unidirectional ... :---)))) > > > > -----Original Message----- > > From: detnet On Behalf Of Black, David > > Sent: Tuesday, January 8, 2019 6:46 PM > > To: Lou Berger ; Janos Farkas < > Janos.Farkas@ericsson.com>; DetNet WG > > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > > That's fine and what was intended. > > > > Thanks, --David > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Monday, January 7, 2019 4:49 PM > > > To: Black, David; J=C3=A1nos Farkas; DetNet WG > > > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > > > > > > > [EXTERNAL EMAIL] > > > > > > David, > > > > > > This looks good/right to me. The only specific change I'd add i= s > > > to clarify that we're talking PEROF traffic when saying "DetNet > > > replicated traffic". > > > > > > Thanks! > > > > > > Lou > > > > > > On 1/7/2019 10:44 AM, Black, David wrote: > > > > Lou, > > > > > > > > Attempting to summarize what needs to be stated without using > > > MUST/SHOULD/MAY: > > > > > > > > [1] Sending DetNet traffic into networks that have not been > > > > provisioned in > > > advance to handle that DetNet traffic has to be treated as a fault. > > > Egress traffic filters to prevent this from happening are strongly > > > recommended at the edges of DetNet networks and DetNet supporting > > > networks. In this context, the term 'provisioned' has a broad > > > meaning, e.g., provisioning could be performed via an administrative > > > decision that the downstream network has the available capacity to > carry the DetNet traffic that is being sent into it. > > > > > > > > [2] Sending non-congestion-controlled DetNet traffic (i.e., DetNet > > > > traffic that > > > does not comply with BCP 41/RFC 2914) into a network that is not > > > provisioned to handle that traffic has to be prevented in addition to > being treated as a fault. > > > DetNet traffic that is not known to be congestion controlled has to b= e > > > treated as non-congestion-controlled DetNet traffic for this > > > requirement. DetNet replicated traffic is always > > > non-congestion-controlled even if the original DetNet flow is > > > congestion-controlled because DetNet packet elimination can hide > > > congestion indications (e.g., drops, ECN CE marks, increased latency) > > > from endpoints. The responsibility for dealing with these > > > requirements in general, and replicated traffic in particular, is > > > solution-specific, as there are MPLS mechanisms that cannot be applie= d > to the IP solution, and moreover, the current IP solution doesn't support > DetNet traffic replication. > > > > > > > > Thanks, --David > > > > > > > >> -----Original Message----- > > > >> From: Lou Berger [mailto:lberger@labn.net] > > > >> Sent: Tuesday, December 25, 2018 11:45 AM > > > >> To: Black, David; J=C3=A1nos Farkas; DetNet WG > > > >> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > >> > > > >> > > > >> [EXTERNAL EMAIL] > > > >> > > > >> Hi David, > > > >> > > > >> On 12/24/2018 8:29 PM, Black, David wrote: > > > >>> Hi Lou, > > > >>> > > > >>> Excerpting key paragraphs ... > > > >>> > > > >>>> To me clear, you are suggesting that text be added to say that > > > >>>> sending detnet traffic out a non-detnet interfaces must be > treated as a fault. > > > >>>> Is this correct? > > > >>> Not exactly ... > > > >>> > > > >>>> If so, I think this is too broad considering that there are > > > >>>> networks that can provided the required detnet forwarding > > > >>>> sub-layer service that are not detnet service aware as is > > > >>>> mentioned at the end of section 4.3.2. (I'll refer to such as > > > >>>> "DetNet supporting networks" in the next paragraph.) > > > >>> I agree with where this is headed - sending DetNet traffic into a > > > >>> network that has not been provisioned to provide the required > > > >>> detnet forwarding service to that traffic has to be treated as a > > > >>> fault. In this statement, "provisioned" should be read broadly, > > > >>> e.g., it could be realized via an administrative decision that th= e > > > >>> DetNet supporting network has the available capacity to carry the > DetNet traffic that is being sent into it. > > > >> agreed. > > > >>>> This said, I think it would be reasonable to make it a > > > >>>> requirement that DetNet nodes must not forward traffic that > > > >>>> doesn't conform with BCP41 over a network that is neither a > > > >>>> Detnet network or a DetNet supporting network. Although this > > > >>>> would require a change to the DetNet service model, i.e., to > know which traffic was conformant/non-conformant. > > > >>> That's fine with one important twist: > > > >>> > > > >>> Any traffic that has been replicated by DetNet packet replication > > > >>> has to be treated as not conforming with BCP41 because DetNet > > > >>> packet elimination (of replicated packets) may hide congestion > > > >>> indications (e.g., delay, ECN CE marks, drops) from the endpoints > > > >>> - a scenario of particular concern involves the other flow of > > > >>> replicated packets following a DetNet network path along which > nothing goes wrong. > > > >>> BCP41 is about end-to-end-congestion control, which does not do > > > >>> anything if DetNet packet elimination hides congestion indication= s > > > >>> from the endpoints. > > > >> This seems reasonable to me. > > > >> > > > >> > > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > > >>>>> traffic that would otherwise escape is needed, and the statemen= t > > > >>>>> of that requirement ought to be connected to the explanation of > > > >>>>> how to implement that requirement. > > > >>>> I think adding a statement on output filters (and policers) to > > > >>>> this section is reasonable. > > > >>> Let's start with the inclusion of output filters (and policers) i= n > > > >>> the 3.3.2 text with the use of upper-case "SHOULD" as suggested b= y > > > >>> Pascal - I will look this over and suggest any additional text > > > >>> that I think ought to be included. > > > >> As an architecture document, the authors/WG made the call to not > > > >> use conformance capitalization or reference 2119/8174. I think > > > >> this translates to the conformance language needing to be added to > > > >> the data plane solution documents. > > > >> > > > >> Cheers, > > > >> > > > >> Lou > > > >> > > > >> > > > >>> Thanks, --David > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Lou Berger [mailto:lberger@labn.net] > > > >>>> Sent: Monday, December 24, 2018 3:18 PM > > > >>>> To: Black, David; J=C3=A1nos Farkas; DetNet WG > > > >>>> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > >>>> > > > >>>> > > > >>>> [EXTERNAL EMAIL] > > > >>>> > > > >>>> Hi David, > > > >>>> > > > >>>> On 12/19/2018 12:37 PM, Black, David wrote: > > > >>>>> Janos, > > > >>>>> > > > >>>>> The terminology is definitely improved - the resulting draft is > > > >>>>> much clearer - many thanks to you and the authors for doing tha= t. > > > >>>> Happy to hear that. > > > >>>> > > > >>>> > > > >>>>> Where do we stand on the concern about protecting external > > > >>>>> non-DetNet networks from DetNet flows that escape a DetNet > > > >>>>> network, e.g., due to an erroneous network configuration change= ? > > > >>>> I'm not sure we have general solutions in the internet > > > >>>> architecture for miss-configured/buggy systems other than > > > >>>> dropping the packets on the floor (e.g., due to no route, no > > > >>>> label, or ttl expiry). What type of protection are you looking > > > >>>> for here, and can you provide a reference to the type of router > > > >>>> behavior you would like to see? I have a suggestion that might > > > >>>> address your concern below elated to non-BCP41 conformant > traffic, but am unsure if this is what you are concerned about. > > > >>>> > > > >>>>> My current views are ... > > > >>>>> > > > >>>>> There's no throttling in DetNet, e.g., this text in 4.3.2: > > > >>>>> > > > >>>>> There is no provision in DetNet for throttling DetNet > flows, i.e., > > > >>>>> the transmission rate cannot be reduced via explicit > congestion > > > >>>>> notification [RFC3168]. The assumption is that a DetNet > flow, to be > > > >>>>> useful, must be delivered in its entirety. > > > >>>> Well looking at it this way, there is no throttling in any IP > > > >>>> network as the routers generate the CN and only drop when their > > > >>>> queues are full or implementing some sort of RED. > > > >>>> > > > >>>> In DetNet there is an expectation that intermediate nodes do mor= e > > > >>>> than this. Specifically, see section 4.5: "Queuing, Shaping, > > > >>>> Scheduling, and Preemption" and policing, which is mentioned as > > > >>>> requirement in section 3.3.1. > > > >>>> > > > >>>>> and no assurance that all DetNet-using applications will cease > > > >>>>> and desist in the face of packet drops that indicate congestion= . > > > >>>> I think this is correct. > > > >>>> > > > >>>> > > > >>>>> Packet Replication and Elimination makes this worse via its > > > >>>>> ability to > > > hide > > > >>>>> network packet drops and congestion indications from endpoints, > > > >>>>> e.g., of those drops and/or congestion indications occur on onl= y > > > >>>>> one of the paths used by replicated packets. > > > >>>>> > > > >>>>> The first paragraph in section 3.3.2 is a good start, but I > > > >>>>> think its lower case "should" is too weak: > > > >>>>> > > > >>>>> Robust real-time systems require to reduce the number of > possible > > > >>>>> failures. Filters and policers should be used in a DetNe= t > network to > > > >>>>> detect if DetNet packets are received on the wrong > interface, or at > > > >>>>> the wrong time, or in too great a volume. Furthermore, > filters and > > > >>>>> policers can take actions to discard the offending packet= s > or flows, > > > >>>>> or trigger shutting down the offending flow or the > offending > > > >>>>> interface. > > > >>>>> > > > >>>>> At a minimum, I think that the requirement to discard DetNet > > > >>>>> traffic that would otherwise escape a DetNet network has to be > > > >>>>> stated as a "MUST" requirement for any DetNet network that > > > >>>>> supports Packet Replication and Elimination due to the ability > > > >>>>> of that functionality to hide congestion from endpoints, making > > > >>>>> it impossible for higher layers of the protocol stack to respon= d. > > > >>>> To me clear, your are suggesting that text be added to say that > > > >>>> sending detnet traffic out a non-detnet interfaces must be > treated as a fault. > > > >>>> Is this correct? If so, I think this is too broad considering > > > >>>> that there are networks that can provided the required detnet > > > >>>> forwarding sub-layer service that are not detnet service aware a= s > > > >>>> is mentioned at the end of section 4.3.2. (I'll refer to such as > > > >>>> "DetNet supporting networks" in the next paragraph.) > > > >>>> > > > >>>> This said, I think it would be reasonable to make it a > > > >>>> requirement that DetNet nodes must not forward traffic that > > > >>>> doesn't conform with BCP41 over a network that is neither a > > > >>>> Detnet network or a DetNet supporting network. Although this > > > >>>> would require a change to the DetNet service model, i.e., to > know which traffic was conformant/non-conformant. > > > >>>> > > > >>>> > > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > > >>>>> traffic that would otherwise escape is needed, and the statemen= t > > > >>>>> of that requirement ought to be connected to the explanation of > > > >>>>> how to implement that requirement. > > > >>>> I think adding a statement on output filters (and policiers) to > > > >>>> this section is reasonable. > > > >>>> > > > >>>> > > > >>>>> The text in Section 3.3.2 has a lot of the content needed - for > > > >>>>> a worked example of such "SHOULD" text, see Section 5 of RFC > > > >>>>> 7510, in particular the itemized list at the end of that sectio= n > > > >>>>> and the paragraph that introduces that list: > > > >>>>> https://tools.ietf.org/html/rfc7510#section-5 > > > >>>> If I'm not mistaken, such mechanisms are already included in the > > > >>>> document and you really are just asking them to be (re)listed to > > > >>>> ensure that this import point isn't missed. Is this correct? > > > >>>> Besides what is mentioned above, is there anything else missing? > > > >>>> > > > >>>> Thanks! > > > >>>> > > > >>>> Lou > > > >>>> > > > >>>>> Thanks, --David > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of > > > >>>>>> J=C3=A1nos > > > Farkas > > > >>>>>> Sent: Wednesday, December 19, 2018 10:54 AM > > > >>>>>> To: DetNet WG > > > >>>>>> Subject: [Detnet] draft-ietf-detnet-architecture-10 > > > >>>>>> > > > >>>>>> > > > >>>>>> [EXTERNAL EMAIL] > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> The DetNet architecture document has been updated to address > > > >>>>>> the comments. The new revision (v10) is available at > > > >>>>>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. > > > >>>>>> > > > >>>>>> There have been a number of discussion items emails on the > > > >>>>>> list. The updates are along the major discussion items, which > > > >>>>>> also cover the derivative discussions, address the comments. > > > >>>>>> > > > >>>>>> The major items have been summarized in: > > > >>>>>> > https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. > > > >>>>>> Follow up discussions implied terminology changes summarized i= n: > > > >>>>>> > https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: > > > >>>>>> replace "transport sub-layer" with "forwarding sub-layer" > > > >>>>>> > https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: > > > >>>>>> replace "congestion protection" with "resource" allocation" > > > >>>>>> Consequently, the document had a good 'scurb". > > > >>>>>> > > > >>>>>> In addition, outstanding comments have been addressed along > > > >>>>>> > https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. > > > >>>>>> > > > >>>>>> Please let us know if any comment happened to be remained open= . > > > >>>>>> > > > >>>>>> Best 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 > > -- > --- > tte@cs.fau.de > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --000000000000e073cf057f3599b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Toerless,

We could certainly truthfully= say that it's not intended for the multidomain best-effort public Inte= rnet infrastructure.

Cheers,
Andy
<= div>

On Fri,= Jan 11, 2019 at 1:16 PM Toerless Eckert <tte@cs.fau.de> wrote:
I really don't know what the benefit of this text would= be. IMHO it is
mostly IESG code language but not really helpfull IMHO.

Something like Googles worldwide network could support DetNet if Google
wanted to ?! Its a private WAN, right ? Aka: there is no physcial scale
limitation, right ? Why don't we say that ?

What is a "large number of domains" ? How about a nationwide rese= arch
network such as Internet 2 with hundreds of attached organizations. If
Internet2 introduced DetNet services and allowed interested Internet2
participants to participate in it, extending DetNet services into their
couses ? How about a nationwide service provider and its customers ?
We do want DetNet service, right ?

The only real requirement for DetNet between A and B is that all transit domains between A and B support DetNet. This is fundamentally not
different from the requirement to make ECN work. As soon as i have a
single hop along a path not supporting ECN, my ECN based congestion
control will have to fall back to delay-variation or loss-based. And ECN is=
defined to be an Internet technology. So why would DetNet not be ?

"When we finally get to DetNet Control Plane, we don't want to bot= her
with all the complexity of multi-operator control plane because its
hard enough to figure out how to make one DetNet SDN controller work"<= br>
Thats one possible honest exlanation, but given how i think we can not
precdit what type of multi-opeator environments control plane the
community will have interest to work on over time, it might be more
appropriate to say that and not to come up with an underspecified binary distinction of what is and what is not DetNet.

Cheers
=C2=A0 =C2=A0 Toerless

On Fri, Jan 11, 2019 at 09:18:37AM +0000, Bal?zs Varga A wrote:
> Great. I am fine to add these explicit statements to make text more cl= ear.
>
> New text is inline with the general statement in the introduction of t= he draft:
> "=C2=A0 DetNet is for networks that are under a single
>=C2=A0 =C2=A0 administrative control or within a closed group of admini= strative
>=C2=A0 =C2=A0 control; these include campus-wide networks and private W= ANs.=C2=A0 DetNet
>=C2=A0 =C2=A0 is not for large groups of domains such as the Internet.= =C2=A0 "
>
> Cheers
> Bala'zs
>
> Ps: Also, note that "DetNet flows" are unidirectional ... :-= --))))
>
> -----Original Message-----
> From: detnet <detnet-bounces@ietf.org> On Behalf Of Black, David
> Sent: Tuesday, January 8, 2019 6:46 PM
> To: Lou Berger <lberger@labn.net>; Janos Farkas <Janos.Farkas@ericsson.com>; DetNet= WG <detnet@ietf.or= g>
> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10
>
> That's fine and what was intended.
>
> Thanks, --David
>
> > -----Original Message-----
> > From: Lou Berger [mailto:lberger@labn.net]
> > Sent: Monday, January 7, 2019 4:49 PM
> > To: Black, David; J=C3=A1nos Farkas; DetNet WG
> > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10
> >
> >
> > [EXTERNAL EMAIL]
> >
> > David,
> >
> >=C2=A0 =C2=A0=C2=A0=C2=A0 This looks good/right to me.=C2=A0 The o= nly specific change I'd add is
> > to clarify that we're talking PEROF traffic when saying "= ;DetNet
> > replicated traffic".
> >
> > Thanks!
> >
> > Lou
> >
> > On 1/7/2019 10:44 AM, Black, David wrote:
> > > Lou,
> > >
> > > Attempting to summarize what needs to be stated without usin= g
> > MUST/SHOULD/MAY:
> > >
> > > [1] Sending DetNet traffic into networks that have not been =
> > > provisioned in
> > advance to handle that DetNet traffic has to be treated as a faul= t.=C2=A0
> > Egress traffic filters to prevent this from happening are strongl= y
> > recommended at the edges of DetNet networks and DetNet supporting=
> > networks.=C2=A0 In this context, the term 'provisioned' h= as a broad
> > meaning, e.g., provisioning could be performed via an administrat= ive
> > decision that the downstream network has the available capacity t= o carry the DetNet traffic that is being sent into it.
> > >
> > > [2] Sending non-congestion-controlled DetNet traffic (i.e., = DetNet
> > > traffic that
> > does not comply with BCP 41/RFC 2914) into a network that is not =
> > provisioned to handle that traffic has to be prevented in additio= n to being treated as a fault.
> > DetNet traffic that is not known to be congestion controlled has = to be
> > treated as non-congestion-controlled DetNet traffic for this
> > requirement.=C2=A0 DetNet replicated traffic is always
> > non-congestion-controlled even if the original DetNet flow is > > congestion-controlled because DetNet packet elimination can hide =
> > congestion indications (e.g., drops, ECN CE marks, increased late= ncy)
> > from endpoints.=C2=A0 The responsibility for dealing with these <= br> > > requirements in general, and replicated traffic in particular, is=
> > solution-specific, as there are MPLS mechanisms that cannot be ap= plied to the IP solution, and moreover, the current IP solution doesn't= support DetNet traffic replication.
> > >
> > > Thanks, --David
> > >
> > >> -----Original Message-----
> > >> From: Lou Berger [mailto:lberger@labn.net]
> > >> Sent: Tuesday, December 25, 2018 11:45 AM
> > >> To: Black, David; J=C3=A1nos Farkas; DetNet WG
> > >> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10<= br> > > >>
> > >>
> > >> [EXTERNAL EMAIL]
> > >>
> > >> Hi David,
> > >>
> > >> On 12/24/2018 8:29 PM, Black, David wrote:
> > >>> Hi Lou,
> > >>>
> > >>> Excerpting key paragraphs ...
> > >>>
> > >>>> To me clear, you are suggesting that text be add= ed to say that
> > >>>> sending detnet traffic out a non-detnet interfac= es must be treated as a fault.
> > >>>> Is this correct?
> > >>> Not exactly ...
> > >>>
> > >>>> If so, I think this is too broad considering tha= t there are
> > >>>> networks that can provided the required detnet f= orwarding
> > >>>> sub-layer service that are not detnet service aw= are as is
> > >>>> mentioned at the end of section 4.3.2. (I'll= refer to such as
> > >>>> "DetNet supporting networks" in the ne= xt paragraph.)
> > >>> I agree with where this is headed - sending DetNet t= raffic into a
> > >>> network that has not been provisioned to provide the= required
> > >>> detnet forwarding service to that traffic has to be = treated as a
> > >>> fault.=C2=A0 In this statement, "provisioned&qu= ot; should be read broadly,
> > >>> e.g., it could be realized via an administrative dec= ision that the
> > >>> DetNet supporting network has the available capacity= to carry the DetNet traffic that is being sent into it.
> > >> agreed.
> > >>>> This said, I think it would be reasonable to mak= e it a
> > >>>> requirement that DetNet nodes must not forward t= raffic that
> > >>>> doesn't conform with BCP41 over a network th= at is neither a
> > >>>> Detnet network or a DetNet supporting network.= =C2=A0 Although this
> > >>>> would require a change to the DetNet service mod= el, i.e.,=C2=A0 to know which traffic was conformant/non-conformant.
> > >>> That's fine with one important twist:
> > >>>
> > >>> Any traffic that has been replicated by DetNet packe= t replication
> > >>> has to be treated as not conforming with BCP41 becau= se DetNet
> > >>> packet elimination (of replicated packets) may hide = congestion
> > >>> indications (e.g., delay, ECN CE marks, drops) from = the endpoints
> > >>> - a scenario of particular concern involves the othe= r flow of
> > >>> replicated packets following a DetNet network path a= long which nothing goes wrong.
> > >>> BCP41 is about end-to-end-congestion control, which = does not do
> > >>> anything if DetNet packet elimination hides congesti= on indications
> > >>> from the endpoints.
> > >> This seems reasonable to me.
> > >>
> > >>
> > >>>>> Beyond this, I think a "SHOULD" re= quirement to discard DetNet
> > >>>>> traffic that would otherwise escape is neede= d, and the statement
> > >>>>> of that requirement ought to be connected to= the explanation of
> > >>>>> how to implement that requirement.
> > >>>> I think adding a statement on output filters (an= d policers) to
> > >>>> this section is reasonable.
> > >>> Let's start with the inclusion of output filters= (and policers) in
> > >>> the 3.3.2 text with the use of upper-case "SHOU= LD" as suggested by
> > >>> Pascal - I will look this over and suggest any addit= ional text
> > >>> that I think ought to be included.
> > >> As an architecture document, the authors/WG made the cal= l to not
> > >> use conformance capitalization or reference 2119/8174.= =C2=A0 I think
> > >> this translates to the conformance language needing to b= e added to
> > >> the data plane solution documents.
> > >>
> > >> Cheers,
> > >>
> > >> Lou
> > >>
> > >>
> > >>> Thanks, --David
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Lou Berger [mailto:lberger@labn.net]
> > >>>> Sent: Monday, December 24, 2018 3:18 PM
> > >>>> To: Black, David; J=C3=A1nos Farkas; DetNet WG > > >>>> Subject: Re: [Detnet] draft-ietf-detnet-architec= ture-10
> > >>>>
> > >>>>
> > >>>> [EXTERNAL EMAIL]
> > >>>>
> > >>>> Hi David,
> > >>>>
> > >>>> On 12/19/2018 12:37 PM, Black, David wrote:
> > >>>>> Janos,
> > >>>>>
> > >>>>> The terminology is definitely improved - the= resulting draft is
> > >>>>> much clearer - many thanks to you and the au= thors for doing that.
> > >>>> Happy to hear that.
> > >>>>
> > >>>>
> > >>>>> Where do we stand on the concern about prote= cting external
> > >>>>> non-DetNet networks from DetNet flows that e= scape a DetNet
> > >>>>> network, e.g., due to an erroneous network c= onfiguration change?
> > >>>> I'm not sure we have general solutions in th= e internet
> > >>>> architecture for miss-configured/buggy systems o= ther than
> > >>>> dropping the packets on the floor (e.g., due to = no route, no
> > >>>> label, or ttl expiry).=C2=A0 What type of protec= tion are you looking
> > >>>> for here, and can you provide a reference to the= type of router
> > >>>> behavior you would like to see?=C2=A0 I have a s= uggestion that might
> > >>>> address your concern below elated to non-BCP41 c= onformant traffic, but am unsure if this is what you are concerned about. > > >>>>
> > >>>>> My current views are ...
> > >>>>>
> > >>>>> There's no throttling in DetNet, e.g., t= his text in 4.3.2:
> > >>>>>
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0There is no provis= ion in DetNet for throttling DetNet flows, i.e.,
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the transmission r= ate cannot be reduced via explicit congestion
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0notification [RFC3= 168].=C2=A0 The assumption is that a DetNet flow, to be
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0useful, must be de= livered in its entirety.
> > >>>> Well looking at it this way, there is no throttl= ing in any IP
> > >>>> network as the routers generate the CN and only = drop when their
> > >>>> queues are full or implementing some sort of RED= .
> > >>>>
> > >>>> In DetNet there is an expectation that intermedi= ate nodes do more
> > >>>> than this.=C2=A0 Specifically, see section 4.5: = "Queuing, Shaping,
> > >>>> Scheduling, and Preemption" and policing, w= hich is mentioned as
> > >>>> requirement in section 3.3.1.
> > >>>>
> > >>>>> and no assurance that all DetNet-using appli= cations will cease
> > >>>>> and desist in the face of packet drops that = indicate congestion.
> > >>>> I think this is correct.
> > >>>>
> > >>>>
> > >>>>> Packet Replication and Elimination makes thi= s worse via its
> > >>>>> ability to
> > hide
> > >>>>> network packet drops and congestion indicati= ons from endpoints,
> > >>>>> e.g., of those drops and/or congestion indic= ations occur on only
> > >>>>> one of the paths used by replicated packets.=
> > >>>>>
> > >>>>> The first paragraph in section 3.3.2 is a go= od start, but I
> > >>>>> think its lower case "should" is t= oo weak:
> > >>>>>
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Robust real-time s= ystems require to reduce the number of possible
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0failures.=C2=A0 Fi= lters and policers should be used in a DetNet network to
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0detect if DetNet p= ackets are received on the wrong interface, or at
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the wrong time, or= in too great a volume.=C2=A0 Furthermore, filters and
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0policers can take = actions to discard the offending packets or flows,
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0or trigger shuttin= g down the offending flow or the offending
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0interface.
> > >>>>>
> > >>>>> At a minimum, I think that the requirement t= o discard DetNet
> > >>>>> traffic that would otherwise escape a DetNet= network has to be
> > >>>>> stated as a "MUST" requirement for= any DetNet network that
> > >>>>> supports Packet Replication and Elimination = due to the ability
> > >>>>> of that functionality to hide congestion fro= m endpoints, making
> > >>>>> it impossible for higher layers of the proto= col stack to respond.
> > >>>> To me clear, your are suggesting that text be ad= ded to say that
> > >>>> sending detnet traffic out a non-detnet interfac= es must be treated as a fault.
> > >>>> Is this correct?=C2=A0 If so, I think this is to= o broad considering
> > >>>> that there are networks that can provided the re= quired detnet
> > >>>> forwarding sub-layer service that are not detnet= service aware as
> > >>>> is mentioned at the end of section 4.3.2. (I'= ;ll refer to such as
> > >>>> "DetNet supporting networks" in the ne= xt paragraph.)
> > >>>>
> > >>>> This said, I think it would be reasonable to mak= e it a
> > >>>> requirement that DetNet nodes must not forward t= raffic that
> > >>>> doesn't conform with BCP41 over a network th= at is neither a
> > >>>> Detnet network or a DetNet supporting network.= =C2=A0 Although this
> > >>>> would require a change to the DetNet service mod= el, i.e.,=C2=A0 to know which traffic was conformant/non-conformant.
> > >>>>
> > >>>>
> > >>>>> Beyond this, I think a "SHOULD" re= quirement to discard DetNet
> > >>>>> traffic that would otherwise escape is neede= d, and the statement
> > >>>>> of that requirement ought to be connected to= the explanation of
> > >>>>> how to implement that requirement.
> > >>>> I think adding a statement on output filters (an= d policiers) to
> > >>>> this section is reasonable.
> > >>>>
> > >>>>
> > >>>>> The text in Section 3.3.2 has a lot of the c= ontent needed - for
> > >>>>> a worked example of such "SHOULD" = text, see Section 5 of RFC
> > >>>>> 7510, in particular the itemized list at the= end of that section
> > >>>>> and the paragraph that introduces that list:=
> > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/rfc7510#section-5
> > >>>> If I'm not mistaken, such mechanisms are alr= eady included in the
> > >>>> document and you really are just asking them to = be (re)listed to
> > >>>> ensure that this import point isn't missed.= =C2=A0 Is this correct?
> > >>>> Besides what is mentioned above, is there anythi= ng else missing?
> > >>>>
> > >>>> Thanks!
> > >>>>
> > >>>> Lou
> > >>>>
> > >>>>> Thanks, --David
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On B= ehalf Of
> > >>>>>> J=C3=A1nos
> > Farkas
> > >>>>>> Sent: Wednesday, December 19, 2018 10:54= AM
> > >>>>>> To: DetNet WG
> > >>>>>> Subject: [Detnet] draft-ietf-detnet-arch= itecture-10
> > >>>>>>
> > >>>>>>
> > >>>>>> [EXTERNAL EMAIL]
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> The DetNet architecture document has bee= n updated to address
> > >>>>>> the comments. The new revision (v10) is = available at
> > >>>>>> http= s://tools.ietf.org/html/draft-ietf-detnet-architecture-10.
> > >>>>>>
> > >>>>>> There have been a number of discussion i= tems emails on the
> > >>>>>> list. The updates are along the major di= scussion items, which
> > >>>>>> also cover the derivative discussions, a= ddress the comments.
> > >>>>>>
> > >>>>>> The major items have been summarized in:=
> > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. > > >>>>>> Follow up discussions implied terminolog= y changes summarized in:
> > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: > > >>>>>> replace "transport sub-layer" = with "forwarding sub-layer"
> > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: > > >>>>>> replace "congestion protection"= ; with "resource" allocation"
> > >>>>>> Consequently, the document had a good &#= 39;scurb".
> > >>>>>>
> > >>>>>> In addition, outstanding comments have b= een addressed along
> > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. > > >>>>>>
> > >>>>>> Please let us know if any comment happen= ed to be remained open.
> > >>>>>>
> > >>>>>> Best 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/mail= man/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
--
---
tte@cs.fau.de

_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
--000000000000e073cf057f3599b2-- From nobody Sun Jan 13 14:44:31 2019 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 19F0E12D4EB for ; Sun, 13 Jan 2019 14:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 4giEjCL8d_-q for ; Sun, 13 Jan 2019 14:44:27 -0800 (PST) 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 EC72312D4EA for ; Sun, 13 Jan 2019 14:44:26 -0800 (PST) Received: from lhrpml401-hub.exmail.huawei.com (unknown [172.18.7.66]) by Forcepoint Email with ESMTP id 96F322AAFA39B1B24E0D; Sun, 13 Jan 2019 22:44:24 +0000 (GMT) Received: from LHRPML504-MBX.exmail.huawei.com ([169.254.5.41]) by lhrpml401-hub.exmail.huawei.com ([10.201.4.160]) with mapi id 14.03.0415.000; Sun, 13 Jan 2019 22:44:22 +0000 From: Norman Finn To: =?Windows-1252?Q?Bal=E1zs_Varga_A?= , "Andrew G. Malis" , Lou Berger CC: detnet WG , Janos Farkas , "Black, David" Thread-Topic: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) Thread-Index: AQHUm8a22Hrj2HelzUCAo4Xy//CLeaWOVmYAgBUS/YCABoFigIAD//Hy Date: Sun, 13 Jan 2019 22:44:21 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F8017231C9@lhrpml504-mbx.exmail.huawei.com> References: , <3DF0466E9510274382F5B74499ACD6F801720DDC@lhrpml504-mbx.exmail.huawei.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.7.95] Content-Type: multipart/alternative; boundary="_000_3DF0466E9510274382F5B74499ACD6F8017231C9lhrpml504mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) 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, 13 Jan 2019 22:44:30 -0000 --_000_3DF0466E9510274382F5B74499ACD6F8017231C9lhrpml504mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We may have been talking about different things, and I mistyped. I identified DetNet flows that exceed bandwidth must be dropped. Traffic that cannot be identified as a DetNet flow, but have a DetNet DSCP,= may need to be marked down. For example, a host that is not authorized to= transmit DetNet traffic sends something with the DetNet DSCP. In a networ= k using CQF, you don't need to identify every packet's flow by 6-tuple; the= DSCP is sufficient to assign the packet to the right DetNet queue. You ma= y well do 6-tuple flow identification at the edge, only. So, a non-DetNet = packet with a DetNet DSCP has to be remarked. That's the case I was talkin= g about. -- Norm ________________________________ From: Bal=E1zs Varga A [balazs.a.varga@ericsson.com] Sent: Friday, January 11, 2019 1:36 AM To: Norman Finn; Andrew G. Malis; Lou Berger Cc: detnet WG; Janos Farkas; Black, David Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Hi Norm, > 1. You may well need more than one DSCP for DetNet region for different c= lasses of service. Yes, and we have defined the 6-tupple match for flow identification, what a= llows multiple DSCP values. > 2. You don't want to discard unexpected packets with a DetNet DSCP -- you= want to remark > them to a non-DSCP code point. Not good if configuring (or misconfigurin= g) a QoS feature > destroys a bystander's connectivity. That is an interesting topic. What do You mean by =93unexpected packet=94? = If it breaks the traffic profile we must drop. I am not sure remarking is a good idea. What = do You mean by =93non-DSCP code point=94? General, I think configuration errors may destroy DetNet (and any other) fl= ows connectivity. We have to live with that. You can mitigate them e.g., by =93proper mainten= ance procedures=94, etc. That points to the importance of DetNet OAM being able to detect confi= guration (and other) errors. Cheers Bala=92zs From: detnet On Behalf Of Norman Finn Sent: Monday, January 7, 2019 7:20 AM To: Andrew G. Malis ; Lou Berger Cc: detnet WG ; Janos Farkas ; = Black, David Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) 1. You may well need more than one DSCP for DetNet region for different cla= sses of service. 2. You don't want to discard unexpected packets with a DetNet DSCP -- you w= ant to remark them to a non-DSCP code point. Not good if configuring (or m= isconfiguring) a QoS feature destroys a bystander's connectivity. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmali= s@gmail.com] Sent: Monday, December 24, 2018 12:26 PM To: Lou Berger Cc: detnet WG; Black, David; J=E1nos Farkas Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Lou, Thanks for following up. Cheers, Andy On Mon, Dec 24, 2018 at 3:24 PM Lou Berger > wrote: Andy, Just following up on one point on DetNet-specific DSCPs: On 12/19/2018 1:11 PM, Andrew G. Malis wrote: > In that case, the DetNet flows would most probably be a using > DetNet-specific DSCP, and if the ingress interface isn't properly > provisioned to know how to process packets with that DSCP, they'll at > least be reduced to best-effort treatment.. We can also recommend that > packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such packets= . While I personally think use of DSCPs will be useful in supporting aggregated DetNet flows, the IP solution draft has no requirement that operators or vendors restrict DetNet flows to a specific DSCP value. -- I personally think this is an important design point. Happy Holidays! Lou --_000_3DF0466E9510274382F5B74499ACD6F8017231C9lhrpml504mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We may have been talking about different things, and I mistyped.

I identified DetNet flows that exceed bandwidth must be dropped.

Traffic that cannot be identified as a DetNet flow, but have a DetNet = DSCP, may need to be marked down.  For example, a host that is not aut= horized to transmit DetNet traffic sends something with the DetNet DSCP.&nb= sp; In a network using CQF, you don't need to identify every packet's flow by 6-tuple; the DSCP is sufficient to assi= gn the packet to the right DetNet queue.  You may well do 6-tuple flow= identification at the edge, only.  So, a non-DetNet packet with a Det= Net DSCP has to be remarked.  That's the case I was talking about.

-- Norm

From: Bal=E1zs Varga A [balazs.a.varga@eri= csson.com]
Sent: Friday, January 11, 2019 1:36 AM
To: Norman Finn; Andrew G. Malis; Lou Berger
Cc: detnet WG; Janos Farkas; Black, David
Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

Hi Norm,

 

> 1. You may well need more than on= e DSCP for DetNet region for different classes of service.

Yes, and we have defined the 6-tupple = match for flow identification, what allows multiple DSCP

values.

 

> 2. You don't want to discard unex= pected packets with a DetNet DSCP -- you want to remark

> them to a non-DSCP code point.&nb= sp; Not good if configuring (or misconfiguring) a QoS feature

> destroys a bystander's connectivi= ty.

That is an interesting topic. What do = You mean by =93unexpected packet=94? If it breaks the

traffic profile we must drop. I am not= sure remarking is a good idea. What do You mean by

=93non-DSCP code point=94?

 

General, I think configuration errors = may destroy DetNet (and any other) flows connectivity.

We have to live with that. You can mit= igate them e.g., by =93proper maintenance procedures=94,

etc. That points to the importance of = DetNet OAM being able to detect configuration (and

other) errors.

 

Cheers

Bala=92zs

 

From: detnet <detnet-bounces@ietf.org> = On Behalf Of Norman Finn
Sent: Monday, January 7, 2019 7:20 AM
To: Andrew G. Malis <agmalis@gmail.com>; Lou Berger <lberge= r@labn.net>
Cc: detnet WG <detnet@ietf.org>; Janos Farkas <Janos.Farkas= @ericsson.com>; Black, David <David.Black@dell.com>
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

 

1. You may well need more than one DSC= P for DetNet region for different classes of service.

2. You don't want to discard unexpecte= d packets with a DetNet DSCP -- you want to remark them to a non-DSCP code = point.  Not good if configuring (or misconfiguring) a QoS feature destroys a bystander's connectivity.

 

-- Norm

 

From= : detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmalis@gmail.com]
Sent: Monday, December 24, 2018 12:26 PM
To: Lou Berger
Cc: detnet WG; Black, David; J=E1nos Farkas
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)<= /p>

Lou,

 

Thanks for following up.

 

Cheers,

Andy

 

 

On Mon, Dec 24, 2018 at 3:24 PM Lo= u Berger <lberger@labn.net> wrote:

And= y,

Just following up on one point on DetNet-specific DSCPs:

On 12/19/2018 1:11 PM, Andrew G. Malis wrote:
> In that case, the DetNet flows would most probably be a using
> DetNet-specific DSCP, and if the ingress interface isn't properly
> provisioned to know how to process packets with that DSCP, they'll at =
> least be reduced to best-effort treatment.. We can also recommend that=
> packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such pack= ets.

While I personally think use of DSCPs will be useful in supporting
aggregated DetNet flows, the IP solution draft has no requirement that
operators or vendors restrict DetNet flows to a specific DSCP value.  = --
I personally think this is an important design point.

Happy Holidays!

Lou

--_000_3DF0466E9510274382F5B74499ACD6F8017231C9lhrpml504mbxexm_-- From nobody Sun Jan 13 22:12:13 2019 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 2FC84130F4F for ; Sun, 13 Jan 2019 22:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.873 X-Spam-Level: X-Spam-Status: No, score=-7.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, 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 header.b=O5MDk8pY; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lrDrwuoK 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 PH3JXUC_qXvv for ; Sun, 13 Jan 2019 22:12:07 -0800 (PST) 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 2BBE412008A for ; Sun, 13 Jan 2019 22:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547446324; x=1550038324; 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=3oGsi9RDOKzSDAROV9DrWL038lmKkvsgM1Uty7rP5OA=; b=O5MDk8pYuJ2r5bZIpKeQhYcDfZTkra2otJmz57KmD/AOSTDsbjVI6hD25xHN5B9v 9iBULEjMP4wIHNFwpAIb8ajHifs5J05mWVVhN9qghYKkBTqGg9Q7jlJkrUJ6RWIk 1lsyQYGgQz7vqmuB1gDYheD4aoTIpBjcces1cOPBj/w=; X-AuditID: c1b4fb30-f93ff7000000355c-65-5c3c2834c48e Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.8D.13660.4382C3C5; Mon, 14 Jan 2019 07:12:04 +0100 (CET) Received: from ESESSMB504.ericsson.se (153.88.183.165) 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; Mon, 14 Jan 2019 07:12:03 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) 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; Mon, 14 Jan 2019 07:12:03 +0100 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=3oGsi9RDOKzSDAROV9DrWL038lmKkvsgM1Uty7rP5OA=; b=lrDrwuoKC7ngxOEFjZ7NixRTNtfIhWejZbtmKgi4Im/OKqQyMpFqWketooMbIs/xOOP5FY5GmeE6Xo4pn/ObN7P700eqGC2wEgBdmomoZF+lM5iXGTwXBvxn5l+vdsz9JZzVb1X7qzMk0I2ydraJZgIFZuuaL4DPcKFK+1O+Jt4= Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com (10.169.152.15) by AM5PR0701MB2947.eurprd07.prod.outlook.com (10.168.156.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Mon, 14 Jan 2019 06:12:02 +0000 Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36]) by AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36%2]) with mapi id 15.20.1537.018; Mon, 14 Jan 2019 06:12:01 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: "Andrew G. Malis" , Toerless Eckert CC: DetNet WG , "Black, David" , "Janos Farkas" , Lou Berger Thread-Topic: [Detnet] draft-ietf-detnet-architecture-10 Thread-Index: AQHUl7MXufweEKzT502ZhTyUzi0RYqWGU60AgAgIgYCAAFcPAIAA/84AgBRdMwCAAGYNgIABTmMAgAQlUICAAJobgIAAOiKAgAOxkxA= Date: Mon, 14 Jan 2019 06:12:01 +0000 Message-ID: References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> <20190111181619.fz7dosbqbgyt55uj@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2947; 6:BSXXOy0jo8nxXiTTVMXuFZNU2MbkkiX+/h8IPdZQUvSQKJcRJ/mylG6YWf+CxPbYRNqGTmfNHJISrndML2uktW52hzkp8rGKG2gJlyR6+EwIyuWVV/ZlTm4NqCRV2cd7Ul3dmZcJYPnlotxxPVFbAhgjdgALZHDuLaISAKSFZKMDx5kuyY3Aci8Sfia8H+ieTIj0QCvqJmcs1TzMjZuu9RB/HxdU6kLAbwV5Qofc1y0ZhtlblBTrqABJ7VDNT66ynQM6ZhSdvC8uZllqHD/XNYEsjJvZsQylPo40gMOfL9SEwRqpAr01WD2cIhTPXTLVGdUGvltAfvSFCHid79x28RayM+ZDQV6ueglqdLH7K1ZGmn4w1pepSHFrKXrfmLuDu2WKdAS/ba0G/X2IBZHlnsw1oOLTdA9kbpli+tO0KhJ1rgVuSWiA+otjS0W0qXIuaSMhUZwRpKaVed20Q8uOaw==; 5:mpquHrV4xw8Z2agDYcWE9CexckSll5ZKLZX/6XV/ljFlfu0CEFrG4q4ikcZ795ff/uluMDb50UIc8GvDHEGVI1nPWum/pdLYHa3P+ZGsjX+5edk1GMC9EXXC/ZnUF3ORSQG0UWHFYDElrJPoE2aAyy+o5SoGE2l/NUXPDNRsa7xltHCp+xZb9UBuni6gypDVb/HHBWJBcs3LMBYzOXxDQw==; 7:sHAADwDjevg7ZvwWAUP6/UBDSParvoERE31EPN2BPw5NZDkXmPNhNVd4LErM2DM/Nk4urie/Y5GVbavAaHocBCaQfBAEdP32wa0E/lU12fo0Tc3JyoYET7x2FSy7+06QQYt+r9//vjvKBnIr3UTa5g== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(979002)(366004)(396003)(376002)(346002)(39860400002)(136003)(189003)(199004)(51444003)(13464003)(606006)(236005)(53936002)(74316002)(21615005)(7696005)(790700001)(6116002)(3846002)(6346003)(93886005)(9686003)(9326002)(68736007)(8936002)(97736004)(53546011)(55016002)(25786009)(85182001)(54896002)(6306002)(4326008)(66066001)(86362001)(99286004)(39060400002)(102836004)(71200400001)(6246003)(71190400001)(7736002)(14454004)(486006)(478600001)(6506007)(85202003)(966005)(33656002)(11346002)(66574012)(446003)(229853002)(476003)(8676002)(30864003)(105586002)(6436002)(316002)(54906003)(110136005)(106356001)(5024004)(26005)(256004)(2906002)(5660300001)(14444005)(81166006)(81156014)(186003)(76176011)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2947; H:AM5PR0701MB2292.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: cea819fb-a937-4dd9-21f1-08d679e732a7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2947; x-ms-traffictypediagnostic: AM5PR0701MB2947: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: G1J4QO/KSslp/ybgY8fXk4d3DxKoYekETBzw/Gw2IFp4k80t+LuXHzQyuWrT5D+K+z1pZrcI+DwxtTPeqBhOiNcOvtyrSdmcWRF4gdpnJ2zp9RlQFyOhMBVxx4VNgCyasdU+z1OPK2Ph7IcXBZFJjB9yro+k/n4mk1PoShEcH61gNwNZgV7TNYRl6ED5hY1AUXSCwjM6OLPvOxAl7oLhCJbRxW2k9jqPmKaRR9b8ivVqsw/BI9hiaxT39nb44CuMR2AnxWj8ndNpkebEuJ9RTII4sB6r5RHhdiG1HR00RwvuOCfvJq9CQSQT2t3mJEiyrDtEPJkEf83Tv2cq5mygIXJB1err0ZenhQPj5g5x+SkZEXC7dTnDuFXdbiVZ/XpM1AvHG1jkYb8+n/CB3Md4GTBc5PMh5o53VXuhyi1GeWM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB229243977255EA5DF23CDF9EAC800AM5PR0701MB2292_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cea819fb-a937-4dd9-21f1-08d679e732a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 06:12:01.2232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2947 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3bv3a4vo8eleTKVGoQWvmO1QiohYhWBQlGIoCsvavmydk20 vljLDBf5Tm5aio00a5amzSwtxcyWZU4qsRaabzkxbIFWE23zLvDb75z/+Z/znMNDEyID5UUn p2UwijRZipjvTKpP6C8EhvtHxIZc/8qXvJky8CU/NbdJidVSQUquKmdJybtPVmIfJVU3ziJp sbqckD7RmARSrfYPTzrXpORHUTHOEQlMSnImowjeE++cVDZ5TD5XQGZdzPuMclD5JTIfOdGA w0HZMiWwswh3IzBoD+QjZxvPI/g2oSa5QMuDHEMHZQ9IXEhAwVClQ7nBg5cmI48LJhGU9pau NObj/dDaVEnZ2R0fgn5Lw4qdwCUICvSTfLuwDu+E6YkiHlckgbmyL3yOM6Fm/juyM4m3QFlf /0ojIY6HimWlgJtmoGBm8A5hF5xwNBTf+msz0DTCPjCqk9jTBPaE4fEqHrcpBu2zfoJjD5ge W6I4FkO5edjBPmCsUiF7f8CXBTCkGuFzQii8uvuc4IRGAehNtQ7HETDdb+ZxgtF2v9wex4gA mNd1O46cDnX3HjsM3vDxVw3FHZyBWl0uKkRBmlWv5TgdRgfbCc3K1m7wWj1OamzLEXgrPGgL 5ko2Q6lqVMCxP+RW3hSszlcjQT3yYBn2ZGpiWFgQo0g+xbLpaUFpTEYTsv2wzmZrSCuanors QphGYlfh4PqIWBEly2SzU7sQ0ITYXaha2B0rEibIss8zivQ4xbkUhu1CG2lS7ClcFLnFinCi LIM5wzByRvFf5dFOXjlIvnf7uMdinsuPopkwv1n5I/PbzKOBJXEfzpb26oqrx1osI7672N8D HU5Psw/7kZ1m88BBfc2C72nK4lUxbFxT37bh+KjbErOj4X2f0KTya4jHMYWuVmVA3mSW16G1 YSN+TXoXc1SnZVnXU3Qlcipl08NrY+LoF8J2Y3F4Xao3KSbZJFnoNkLByv4BtsQaMF0DAAA= Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 14 Jan 2019 06:12:11 -0000 --_000_AM5PR0701MB229243977255EA5DF23CDF9EAC800AM5PR0701MB2292_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpZZXMgd2UgY2FuLCBhcyBpdCB3YXMgc3RhdGVkIGluIHRoZSBjaGFydGVyOg0K4oCcDQpU aGUgV29ya2luZyBHcm91cCB3aWxsIGluaXRpYWxseSBmb2N1cyBvbiBzb2x1dGlvbnMgZm9yIG5l dHdvcmtzIHRoYXQNCmFyZSB1bmRlciBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9y IHdpdGhpbiBhIGNsb3NlZCBncm91cCBvZg0KYWRtaW5pc3RyYXRpdmUgY29udHJvbDsgdGhlc2Ug aW5jbHVkZSBub3Qgb25seSBjYW1wdXMtd2lkZSBuZXR3b3JrcyBidXQNCmFsc28gY2FuIGluY2x1 ZGUgcHJpdmF0ZSBXQU5zLiBUaGUgRGV0TmV0IFdHIHdpbGwgbm90IHNwZW5kIGVuZXJneSBvbg0K c29sdXRpb25zIGZvciBsYXJnZSBncm91cHMgb2YgZG9tYWlucyBzdWNoIGFzIHRoZSBJbnRlcm5l dC4NCuKAnQ0KQ2hlZXJzDQpCYWxh4oCZenMNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIDxhZ21h bGlzQGdtYWlsLmNvbT4NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxMSwgMjAxOSAxMDo0NCBQTQ0K VG86IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4NCkNjOiBCYWzDoXpzIFZhcmdhIEEg PGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbT47IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3Jn PjsgQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbT47IEphbm9zIEZhcmthcyA8SmFu b3MuRmFya2FzQGVyaWNzc29uLmNvbT47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpT dWJqZWN0OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwDQoN ClRvZXJsZXNzLA0KDQpXZSBjb3VsZCBjZXJ0YWlubHkgdHJ1dGhmdWxseSBzYXkgdGhhdCBpdCdz IG5vdCBpbnRlbmRlZCBmb3IgdGhlIG11bHRpZG9tYWluIGJlc3QtZWZmb3J0IHB1YmxpYyBJbnRl cm5ldCBpbmZyYXN0cnVjdHVyZS4NCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIEZyaSwgSmFuIDEx LCAyMDE5IGF0IDE6MTYgUE0gVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPG1haWx0bzp0 dGVAY3MuZmF1LmRlPj4gd3JvdGU6DQpJIHJlYWxseSBkb24ndCBrbm93IHdoYXQgdGhlIGJlbmVm aXQgb2YgdGhpcyB0ZXh0IHdvdWxkIGJlLiBJTUhPIGl0IGlzDQptb3N0bHkgSUVTRyBjb2RlIGxh bmd1YWdlIGJ1dCBub3QgcmVhbGx5IGhlbHBmdWxsIElNSE8uDQoNClNvbWV0aGluZyBsaWtlIEdv b2dsZXMgd29ybGR3aWRlIG5ldHdvcmsgY291bGQgc3VwcG9ydCBEZXROZXQgaWYgR29vZ2xlDQp3 YW50ZWQgdG8gPyEgSXRzIGEgcHJpdmF0ZSBXQU4sIHJpZ2h0ID8gQWthOiB0aGVyZSBpcyBubyBw aHlzY2lhbCBzY2FsZQ0KbGltaXRhdGlvbiwgcmlnaHQgPyBXaHkgZG9uJ3Qgd2Ugc2F5IHRoYXQg Pw0KDQpXaGF0IGlzIGEgImxhcmdlIG51bWJlciBvZiBkb21haW5zIiA/IEhvdyBhYm91dCBhIG5h dGlvbndpZGUgcmVzZWFyY2gNCm5ldHdvcmsgc3VjaCBhcyBJbnRlcm5ldCAyIHdpdGggaHVuZHJl ZHMgb2YgYXR0YWNoZWQgb3JnYW5pemF0aW9ucy4gSWYNCkludGVybmV0MiBpbnRyb2R1Y2VkIERl dE5ldCBzZXJ2aWNlcyBhbmQgYWxsb3dlZCBpbnRlcmVzdGVkIEludGVybmV0Mg0KcGFydGljaXBh bnRzIHRvIHBhcnRpY2lwYXRlIGluIGl0LCBleHRlbmRpbmcgRGV0TmV0IHNlcnZpY2VzIGludG8g dGhlaXINCmNvdXNlcyA/IEhvdyBhYm91dCBhIG5hdGlvbndpZGUgc2VydmljZSBwcm92aWRlciBh bmQgaXRzIGN1c3RvbWVycyA/DQpXZSBkbyB3YW50IERldE5ldCBzZXJ2aWNlLCByaWdodCA/DQoN ClRoZSBvbmx5IHJlYWwgcmVxdWlyZW1lbnQgZm9yIERldE5ldCBiZXR3ZWVuIEEgYW5kIEIgaXMg dGhhdCBhbGwgdHJhbnNpdA0KZG9tYWlucyBiZXR3ZWVuIEEgYW5kIEIgc3VwcG9ydCBEZXROZXQu IFRoaXMgaXMgZnVuZGFtZW50YWxseSBub3QNCmRpZmZlcmVudCBmcm9tIHRoZSByZXF1aXJlbWVu dCB0byBtYWtlIEVDTiB3b3JrLiBBcyBzb29uIGFzIGkgaGF2ZSBhDQpzaW5nbGUgaG9wIGFsb25n IGEgcGF0aCBub3Qgc3VwcG9ydGluZyBFQ04sIG15IEVDTiBiYXNlZCBjb25nZXN0aW9uDQpjb250 cm9sIHdpbGwgaGF2ZSB0byBmYWxsIGJhY2sgdG8gZGVsYXktdmFyaWF0aW9uIG9yIGxvc3MtYmFz ZWQuIEFuZCBFQ04gaXMNCmRlZmluZWQgdG8gYmUgYW4gSW50ZXJuZXQgdGVjaG5vbG9neS4gU28g d2h5IHdvdWxkIERldE5ldCBub3QgYmUgPw0KDQoiV2hlbiB3ZSBmaW5hbGx5IGdldCB0byBEZXRO ZXQgQ29udHJvbCBQbGFuZSwgd2UgZG9uJ3Qgd2FudCB0byBib3RoZXINCndpdGggYWxsIHRoZSBj b21wbGV4aXR5IG9mIG11bHRpLW9wZXJhdG9yIGNvbnRyb2wgcGxhbmUgYmVjYXVzZSBpdHMNCmhh cmQgZW5vdWdoIHRvIGZpZ3VyZSBvdXQgaG93IHRvIG1ha2Ugb25lIERldE5ldCBTRE4gY29udHJv bGxlciB3b3JrIg0KDQpUaGF0cyBvbmUgcG9zc2libGUgaG9uZXN0IGV4bGFuYXRpb24sIGJ1dCBn aXZlbiBob3cgaSB0aGluayB3ZSBjYW4gbm90DQpwcmVjZGl0IHdoYXQgdHlwZSBvZiBtdWx0aS1v cGVhdG9yIGVudmlyb25tZW50cyBjb250cm9sIHBsYW5lIHRoZQ0KY29tbXVuaXR5IHdpbGwgaGF2 ZSBpbnRlcmVzdCB0byB3b3JrIG9uIG92ZXIgdGltZSwgaXQgbWlnaHQgYmUgbW9yZQ0KYXBwcm9w cmlhdGUgdG8gc2F5IHRoYXQgYW5kIG5vdCB0byBjb21lIHVwIHdpdGggYW4gdW5kZXJzcGVjaWZp ZWQgYmluYXJ5DQpkaXN0aW5jdGlvbiBvZiB3aGF0IGlzIGFuZCB3aGF0IGlzIG5vdCBEZXROZXQu DQoNCkNoZWVycw0KICAgIFRvZXJsZXNzDQoNCk9uIEZyaSwgSmFuIDExLCAyMDE5IGF0IDA5OjE4 OjM3QU0gKzAwMDAsIEJhbD96cyBWYXJnYSBBIHdyb3RlOg0KPiBHcmVhdC4gSSBhbSBmaW5lIHRv IGFkZCB0aGVzZSBleHBsaWNpdCBzdGF0ZW1lbnRzIHRvIG1ha2UgdGV4dCBtb3JlIGNsZWFyLg0K Pg0KPiBOZXcgdGV4dCBpcyBpbmxpbmUgd2l0aCB0aGUgZ2VuZXJhbCBzdGF0ZW1lbnQgaW4gdGhl IGludHJvZHVjdGlvbiBvZiB0aGUgZHJhZnQ6DQo+ICIgIERldE5ldCBpcyBmb3IgbmV0d29ya3Mg dGhhdCBhcmUgdW5kZXIgYSBzaW5nbGUNCj4gICAgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvciB3 aXRoaW4gYSBjbG9zZWQgZ3JvdXAgb2YgYWRtaW5pc3RyYXRpdmUNCj4gICAgY29udHJvbDsgdGhl c2UgaW5jbHVkZSBjYW1wdXMtd2lkZSBuZXR3b3JrcyBhbmQgcHJpdmF0ZSBXQU5zLiAgRGV0TmV0 DQo+ICAgIGlzIG5vdCBmb3IgbGFyZ2UgZ3JvdXBzIG9mIGRvbWFpbnMgc3VjaCBhcyB0aGUgSW50 ZXJuZXQuICAiDQo+DQo+IENoZWVycw0KPiBCYWxhJ3pzDQo+DQo+IFBzOiBBbHNvLCBub3RlIHRo YXQgIkRldE5ldCBmbG93cyIgYXJlIHVuaWRpcmVjdGlvbmFsIC4uLiA6LS0tKSkpKQ0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkZXRuZXQgPGRldG5ldC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBC bGFjaywgRGF2aWQNCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSA4LCAyMDE5IDY6NDYgUE0NCj4g VG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ PjsgSmFub3MgRmFya2FzIDxKYW5vcy5GYXJrYXNAZXJpY3Nzb24uY29tPG1haWx0bzpKYW5vcy5G YXJrYXNAZXJpY3Nzb24uY29tPj47IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpk ZXRuZXRAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRu ZXQtYXJjaGl0ZWN0dXJlLTEwDQo+DQo+IFRoYXQncyBmaW5lIGFuZCB3aGF0IHdhcyBpbnRlbmRl ZC4NCj4NCj4gVGhhbmtzLCAtLURhdmlkDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86 bGJlcmdlckBsYWJuLm5ldD5dDQo+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDcsIDIwMTkgNDo0 OSBQTQ0KPiA+IFRvOiBCbGFjaywgRGF2aWQ7IErDoW5vcyBGYXJrYXM7IERldE5ldCBXRw0KPiA+ IFN1YmplY3Q6IFJlOiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTAN Cj4gPg0KPiA+DQo+ID4gW0VYVEVSTkFMIEVNQUlMXQ0KPiA+DQo+ID4gRGF2aWQsDQo+ID4NCj4g PiAgICAgIFRoaXMgbG9va3MgZ29vZC9yaWdodCB0byBtZS4gIFRoZSBvbmx5IHNwZWNpZmljIGNo YW5nZSBJJ2QgYWRkIGlzDQo+ID4gdG8gY2xhcmlmeSB0aGF0IHdlJ3JlIHRhbGtpbmcgUEVST0Yg dHJhZmZpYyB3aGVuIHNheWluZyAiRGV0TmV0DQo+ID4gcmVwbGljYXRlZCB0cmFmZmljIi4NCj4g Pg0KPiA+IFRoYW5rcyENCj4gPg0KPiA+IExvdQ0KPiA+DQo+ID4gT24gMS83LzIwMTkgMTA6NDQg QU0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPiA+IExvdSwNCj4gPiA+DQo+ID4gPiBBdHRlbXB0 aW5nIHRvIHN1bW1hcml6ZSB3aGF0IG5lZWRzIHRvIGJlIHN0YXRlZCB3aXRob3V0IHVzaW5nDQo+ ID4gTVVTVC9TSE9VTEQvTUFZOg0KPiA+ID4NCj4gPiA+IFsxXSBTZW5kaW5nIERldE5ldCB0cmFm ZmljIGludG8gbmV0d29ya3MgdGhhdCBoYXZlIG5vdCBiZWVuDQo+ID4gPiBwcm92aXNpb25lZCBp bg0KPiA+IGFkdmFuY2UgdG8gaGFuZGxlIHRoYXQgRGV0TmV0IHRyYWZmaWMgaGFzIHRvIGJlIHRy ZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPiBFZ3Jlc3MgdHJhZmZpYyBmaWx0ZXJzIHRvIHByZXZlbnQg dGhpcyBmcm9tIGhhcHBlbmluZyBhcmUgc3Ryb25nbHkNCj4gPiByZWNvbW1lbmRlZCBhdCB0aGUg ZWRnZXMgb2YgRGV0TmV0IG5ldHdvcmtzIGFuZCBEZXROZXQgc3VwcG9ydGluZw0KPiA+IG5ldHdv cmtzLiAgSW4gdGhpcyBjb250ZXh0LCB0aGUgdGVybSAncHJvdmlzaW9uZWQnIGhhcyBhIGJyb2Fk DQo+ID4gbWVhbmluZywgZS5nLiwgcHJvdmlzaW9uaW5nIGNvdWxkIGJlIHBlcmZvcm1lZCB2aWEg YW4gYWRtaW5pc3RyYXRpdmUNCj4gPiBkZWNpc2lvbiB0aGF0IHRoZSBkb3duc3RyZWFtIG5ldHdv cmsgaGFzIHRoZSBhdmFpbGFibGUgY2FwYWNpdHkgdG8gY2FycnkgdGhlIERldE5ldCB0cmFmZmlj IHRoYXQgaXMgYmVpbmcgc2VudCBpbnRvIGl0Lg0KPiA+ID4NCj4gPiA+IFsyXSBTZW5kaW5nIG5v bi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgRGV0TmV0IHRyYWZmaWMgKGkuZS4sIERldE5ldA0KPiA+ ID4gdHJhZmZpYyB0aGF0DQo+ID4gZG9lcyBub3QgY29tcGx5IHdpdGggQkNQIDQxL1JGQyAyOTE0 KSBpbnRvIGEgbmV0d29yayB0aGF0IGlzIG5vdA0KPiA+IHByb3Zpc2lvbmVkIHRvIGhhbmRsZSB0 aGF0IHRyYWZmaWMgaGFzIHRvIGJlIHByZXZlbnRlZCBpbiBhZGRpdGlvbiB0byBiZWluZyB0cmVh dGVkIGFzIGEgZmF1bHQuDQo+ID4gRGV0TmV0IHRyYWZmaWMgdGhhdCBpcyBub3Qga25vd24gdG8g YmUgY29uZ2VzdGlvbiBjb250cm9sbGVkIGhhcyB0byBiZQ0KPiA+IHRyZWF0ZWQgYXMgbm9uLWNv bmdlc3Rpb24tY29udHJvbGxlZCBEZXROZXQgdHJhZmZpYyBmb3IgdGhpcw0KPiA+IHJlcXVpcmVt ZW50LiAgRGV0TmV0IHJlcGxpY2F0ZWQgdHJhZmZpYyBpcyBhbHdheXMNCj4gPiBub24tY29uZ2Vz dGlvbi1jb250cm9sbGVkIGV2ZW4gaWYgdGhlIG9yaWdpbmFsIERldE5ldCBmbG93IGlzDQo+ID4g Y29uZ2VzdGlvbi1jb250cm9sbGVkIGJlY2F1c2UgRGV0TmV0IHBhY2tldCBlbGltaW5hdGlvbiBj YW4gaGlkZQ0KPiA+IGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgKGUuZy4sIGRyb3BzLCBFQ04gQ0Ug bWFya3MsIGluY3JlYXNlZCBsYXRlbmN5KQ0KPiA+IGZyb20gZW5kcG9pbnRzLiAgVGhlIHJlc3Bv bnNpYmlsaXR5IGZvciBkZWFsaW5nIHdpdGggdGhlc2UNCj4gPiByZXF1aXJlbWVudHMgaW4gZ2Vu ZXJhbCwgYW5kIHJlcGxpY2F0ZWQgdHJhZmZpYyBpbiBwYXJ0aWN1bGFyLCBpcw0KPiA+IHNvbHV0 aW9uLXNwZWNpZmljLCBhcyB0aGVyZSBhcmUgTVBMUyBtZWNoYW5pc21zIHRoYXQgY2Fubm90IGJl IGFwcGxpZWQgdG8gdGhlIElQIHNvbHV0aW9uLCBhbmQgbW9yZW92ZXIsIHRoZSBjdXJyZW50IElQ IHNvbHV0aW9uIGRvZXNuJ3Qgc3VwcG9ydCBEZXROZXQgdHJhZmZpYyByZXBsaWNhdGlvbi4NCj4g PiA+DQo+ID4gPiBUaGFua3MsIC0tRGF2aWQNCj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJu Lm5ldDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD5dDQo+ID4gPj4gU2VudDogVHVlc2RheSwgRGVj ZW1iZXIgMjUsIDIwMTggMTE6NDUgQU0NCj4gPiA+PiBUbzogQmxhY2ssIERhdmlkOyBKw6Fub3Mg RmFya2FzOyBEZXROZXQgV0cNCj4gPiA+PiBTdWJqZWN0OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0 Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IFtFWFRFUk5B TCBFTUFJTF0NCj4gPiA+Pg0KPiA+ID4+IEhpIERhdmlkLA0KPiA+ID4+DQo+ID4gPj4gT24gMTIv MjQvMjAxOCA4OjI5IFBNLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ID4gPj4+IEhpIExvdSwNCj4g PiA+Pj4NCj4gPiA+Pj4gRXhjZXJwdGluZyBrZXkgcGFyYWdyYXBocyAuLi4NCj4gPiA+Pj4NCj4g PiA+Pj4+IFRvIG1lIGNsZWFyLCB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCB0ZXh0IGJlIGFkZGVk IHRvIHNheSB0aGF0DQo+ID4gPj4+PiBzZW5kaW5nIGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1k ZXRuZXQgaW50ZXJmYWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC4NCj4gPiA+Pj4+IElz IHRoaXMgY29ycmVjdD8NCj4gPiA+Pj4gTm90IGV4YWN0bHkgLi4uDQo+ID4gPj4+DQo+ID4gPj4+ PiBJZiBzbywgSSB0aGluayB0aGlzIGlzIHRvbyBicm9hZCBjb25zaWRlcmluZyB0aGF0IHRoZXJl IGFyZQ0KPiA+ID4+Pj4gbmV0d29ya3MgdGhhdCBjYW4gcHJvdmlkZWQgdGhlIHJlcXVpcmVkIGRl dG5ldCBmb3J3YXJkaW5nDQo+ID4gPj4+PiBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFyZSBub3Qg ZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMgaXMNCj4gPiA+Pj4+IG1lbnRpb25lZCBhdCB0aGUgZW5k IG9mIHNlY3Rpb24gNC4zLjIuIChJJ2xsIHJlZmVyIHRvIHN1Y2ggYXMNCj4gPiA+Pj4+ICJEZXRO ZXQgc3VwcG9ydGluZyBuZXR3b3JrcyIgaW4gdGhlIG5leHQgcGFyYWdyYXBoLikNCj4gPiA+Pj4g SSBhZ3JlZSB3aXRoIHdoZXJlIHRoaXMgaXMgaGVhZGVkIC0gc2VuZGluZyBEZXROZXQgdHJhZmZp YyBpbnRvIGENCj4gPiA+Pj4gbmV0d29yayB0aGF0IGhhcyBub3QgYmVlbiBwcm92aXNpb25lZCB0 byBwcm92aWRlIHRoZSByZXF1aXJlZA0KPiA+ID4+PiBkZXRuZXQgZm9yd2FyZGluZyBzZXJ2aWNl IHRvIHRoYXQgdHJhZmZpYyBoYXMgdG8gYmUgdHJlYXRlZCBhcyBhDQo+ID4gPj4+IGZhdWx0LiAg SW4gdGhpcyBzdGF0ZW1lbnQsICJwcm92aXNpb25lZCIgc2hvdWxkIGJlIHJlYWQgYnJvYWRseSwN Cj4gPiA+Pj4gZS5nLiwgaXQgY291bGQgYmUgcmVhbGl6ZWQgdmlhIGFuIGFkbWluaXN0cmF0aXZl IGRlY2lzaW9uIHRoYXQgdGhlDQo+ID4gPj4+IERldE5ldCBzdXBwb3J0aW5nIG5ldHdvcmsgaGFz IHRoZSBhdmFpbGFibGUgY2FwYWNpdHkgdG8gY2FycnkgdGhlIERldE5ldCB0cmFmZmljIHRoYXQg aXMgYmVpbmcgc2VudCBpbnRvIGl0Lg0KPiA+ID4+IGFncmVlZC4NCj4gPiA+Pj4+IFRoaXMgc2Fp ZCwgSSB0aGluayBpdCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIG1ha2UgaXQgYQ0KPiA+ID4+Pj4g cmVxdWlyZW1lbnQgdGhhdCBEZXROZXQgbm9kZXMgbXVzdCBub3QgZm9yd2FyZCB0cmFmZmljIHRo YXQNCj4gPiA+Pj4+IGRvZXNuJ3QgY29uZm9ybSB3aXRoIEJDUDQxIG92ZXIgYSBuZXR3b3JrIHRo YXQgaXMgbmVpdGhlciBhDQo+ID4gPj4+PiBEZXRuZXQgbmV0d29yayBvciBhIERldE5ldCBzdXBw b3J0aW5nIG5ldHdvcmsuICBBbHRob3VnaCB0aGlzDQo+ID4gPj4+PiB3b3VsZCByZXF1aXJlIGEg Y2hhbmdlIHRvIHRoZSBEZXROZXQgc2VydmljZSBtb2RlbCwgaS5lLiwgIHRvIGtub3cgd2hpY2gg dHJhZmZpYyB3YXMgY29uZm9ybWFudC9ub24tY29uZm9ybWFudC4NCj4gPiA+Pj4gVGhhdCdzIGZp bmUgd2l0aCBvbmUgaW1wb3J0YW50IHR3aXN0Og0KPiA+ID4+Pg0KPiA+ID4+PiBBbnkgdHJhZmZp YyB0aGF0IGhhcyBiZWVuIHJlcGxpY2F0ZWQgYnkgRGV0TmV0IHBhY2tldCByZXBsaWNhdGlvbg0K PiA+ID4+PiBoYXMgdG8gYmUgdHJlYXRlZCBhcyBub3QgY29uZm9ybWluZyB3aXRoIEJDUDQxIGJl Y2F1c2UgRGV0TmV0DQo+ID4gPj4+IHBhY2tldCBlbGltaW5hdGlvbiAob2YgcmVwbGljYXRlZCBw YWNrZXRzKSBtYXkgaGlkZSBjb25nZXN0aW9uDQo+ID4gPj4+IGluZGljYXRpb25zIChlLmcuLCBk ZWxheSwgRUNOIENFIG1hcmtzLCBkcm9wcykgZnJvbSB0aGUgZW5kcG9pbnRzDQo+ID4gPj4+IC0g YSBzY2VuYXJpbyBvZiBwYXJ0aWN1bGFyIGNvbmNlcm4gaW52b2x2ZXMgdGhlIG90aGVyIGZsb3cg b2YNCj4gPiA+Pj4gcmVwbGljYXRlZCBwYWNrZXRzIGZvbGxvd2luZyBhIERldE5ldCBuZXR3b3Jr IHBhdGggYWxvbmcgd2hpY2ggbm90aGluZyBnb2VzIHdyb25nLg0KPiA+ID4+PiBCQ1A0MSBpcyBh Ym91dCBlbmQtdG8tZW5kLWNvbmdlc3Rpb24gY29udHJvbCwgd2hpY2ggZG9lcyBub3QgZG8NCj4g PiA+Pj4gYW55dGhpbmcgaWYgRGV0TmV0IHBhY2tldCBlbGltaW5hdGlvbiBoaWRlcyBjb25nZXN0 aW9uIGluZGljYXRpb25zDQo+ID4gPj4+IGZyb20gdGhlIGVuZHBvaW50cy4NCj4gPiA+PiBUaGlz IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUuDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+Pj4+IEJleW9u ZCB0aGlzLCBJIHRoaW5rIGEgIlNIT1VMRCIgcmVxdWlyZW1lbnQgdG8gZGlzY2FyZCBEZXROZXQN Cj4gPiA+Pj4+PiB0cmFmZmljIHRoYXQgd291bGQgb3RoZXJ3aXNlIGVzY2FwZSBpcyBuZWVkZWQs IGFuZCB0aGUgc3RhdGVtZW50DQo+ID4gPj4+Pj4gb2YgdGhhdCByZXF1aXJlbWVudCBvdWdodCB0 byBiZSBjb25uZWN0ZWQgdG8gdGhlIGV4cGxhbmF0aW9uIG9mDQo+ID4gPj4+Pj4gaG93IHRvIGlt cGxlbWVudCB0aGF0IHJlcXVpcmVtZW50Lg0KPiA+ID4+Pj4gSSB0aGluayBhZGRpbmcgYSBzdGF0 ZW1lbnQgb24gb3V0cHV0IGZpbHRlcnMgKGFuZCBwb2xpY2VycykgdG8NCj4gPiA+Pj4+IHRoaXMg c2VjdGlvbiBpcyByZWFzb25hYmxlLg0KPiA+ID4+PiBMZXQncyBzdGFydCB3aXRoIHRoZSBpbmNs dXNpb24gb2Ygb3V0cHV0IGZpbHRlcnMgKGFuZCBwb2xpY2VycykgaW4NCj4gPiA+Pj4gdGhlIDMu My4yIHRleHQgd2l0aCB0aGUgdXNlIG9mIHVwcGVyLWNhc2UgIlNIT1VMRCIgYXMgc3VnZ2VzdGVk IGJ5DQo+ID4gPj4+IFBhc2NhbCAtIEkgd2lsbCBsb29rIHRoaXMgb3ZlciBhbmQgc3VnZ2VzdCBh bnkgYWRkaXRpb25hbCB0ZXh0DQo+ID4gPj4+IHRoYXQgSSB0aGluayBvdWdodCB0byBiZSBpbmNs dWRlZC4NCj4gPiA+PiBBcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIHRoZSBhdXRob3JzL1dH IG1hZGUgdGhlIGNhbGwgdG8gbm90DQo+ID4gPj4gdXNlIGNvbmZvcm1hbmNlIGNhcGl0YWxpemF0 aW9uIG9yIHJlZmVyZW5jZSAyMTE5LzgxNzQuICBJIHRoaW5rDQo+ID4gPj4gdGhpcyB0cmFuc2xh dGVzIHRvIHRoZSBjb25mb3JtYW5jZSBsYW5ndWFnZSBuZWVkaW5nIHRvIGJlIGFkZGVkIHRvDQo+ ID4gPj4gdGhlIGRhdGEgcGxhbmUgc29sdXRpb24gZG9jdW1lbnRzLg0KPiA+ID4+DQo+ID4gPj4g Q2hlZXJzLA0KPiA+ID4+DQo+ID4gPj4gTG91DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+PiBUaGFu a3MsIC0tRGF2aWQNCj4gPiA+Pj4NCj4gPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldDxtYWls dG86bGJlcmdlckBsYWJuLm5ldD5dDQo+ID4gPj4+PiBTZW50OiBNb25kYXksIERlY2VtYmVyIDI0 LCAyMDE4IDM6MTggUE0NCj4gPiA+Pj4+IFRvOiBCbGFjaywgRGF2aWQ7IErDoW5vcyBGYXJrYXM7 IERldE5ldCBXRw0KPiA+ID4+Pj4gU3ViamVjdDogUmU6IFtEZXRuZXRdIGRyYWZ0LWlldGYtZGV0 bmV0LWFyY2hpdGVjdHVyZS0xMA0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBbRVhURVJO QUwgRU1BSUxdDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSGkgRGF2aWQsDQo+ID4gPj4+Pg0KPiA+ID4+ Pj4gT24gMTIvMTkvMjAxOCAxMjozNyBQTSwgQmxhY2ssIERhdmlkIHdyb3RlOg0KPiA+ID4+Pj4+ IEphbm9zLA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gVGhlIHRlcm1pbm9sb2d5IGlzIGRlZmluaXRl bHkgaW1wcm92ZWQgLSB0aGUgcmVzdWx0aW5nIGRyYWZ0IGlzDQo+ID4gPj4+Pj4gbXVjaCBjbGVh cmVyIC0gbWFueSB0aGFua3MgdG8geW91IGFuZCB0aGUgYXV0aG9ycyBmb3IgZG9pbmcgdGhhdC4N Cj4gPiA+Pj4+IEhhcHB5IHRvIGhlYXIgdGhhdC4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+ Pj4+IFdoZXJlIGRvIHdlIHN0YW5kIG9uIHRoZSBjb25jZXJuIGFib3V0IHByb3RlY3RpbmcgZXh0 ZXJuYWwNCj4gPiA+Pj4+PiBub24tRGV0TmV0IG5ldHdvcmtzIGZyb20gRGV0TmV0IGZsb3dzIHRo YXQgZXNjYXBlIGEgRGV0TmV0DQo+ID4gPj4+Pj4gbmV0d29yaywgZS5nLiwgZHVlIHRvIGFuIGVy cm9uZW91cyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gY2hhbmdlPw0KPiA+ID4+Pj4gSSdtIG5vdCBz dXJlIHdlIGhhdmUgZ2VuZXJhbCBzb2x1dGlvbnMgaW4gdGhlIGludGVybmV0DQo+ID4gPj4+PiBh cmNoaXRlY3R1cmUgZm9yIG1pc3MtY29uZmlndXJlZC9idWdneSBzeXN0ZW1zIG90aGVyIHRoYW4N Cj4gPiA+Pj4+IGRyb3BwaW5nIHRoZSBwYWNrZXRzIG9uIHRoZSBmbG9vciAoZS5nLiwgZHVlIHRv IG5vIHJvdXRlLCBubw0KPiA+ID4+Pj4gbGFiZWwsIG9yIHR0bCBleHBpcnkpLiAgV2hhdCB0eXBl IG9mIHByb3RlY3Rpb24gYXJlIHlvdSBsb29raW5nDQo+ID4gPj4+PiBmb3IgaGVyZSwgYW5kIGNh biB5b3UgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byB0aGUgdHlwZSBvZiByb3V0ZXINCj4gPiA+Pj4+ IGJlaGF2aW9yIHlvdSB3b3VsZCBsaWtlIHRvIHNlZT8gIEkgaGF2ZSBhIHN1Z2dlc3Rpb24gdGhh dCBtaWdodA0KPiA+ID4+Pj4gYWRkcmVzcyB5b3VyIGNvbmNlcm4gYmVsb3cgZWxhdGVkIHRvIG5v bi1CQ1A0MSBjb25mb3JtYW50IHRyYWZmaWMsIGJ1dCBhbSB1bnN1cmUgaWYgdGhpcyBpcyB3aGF0 IHlvdSBhcmUgY29uY2VybmVkIGFib3V0Lg0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiBNeSBjdXJyZW50 IHZpZXdzIGFyZSAuLi4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IFRoZXJlJ3Mgbm8gdGhyb3R0bGlu ZyBpbiBEZXROZXQsIGUuZy4sIHRoaXMgdGV4dCBpbiA0LjMuMjoNCj4gPiA+Pj4+Pg0KPiA+ID4+ Pj4+ICAgICAgIFRoZXJlIGlzIG5vIHByb3Zpc2lvbiBpbiBEZXROZXQgZm9yIHRocm90dGxpbmcg RGV0TmV0IGZsb3dzLCBpLmUuLA0KPiA+ID4+Pj4+ICAgICAgIHRoZSB0cmFuc21pc3Npb24gcmF0 ZSBjYW5ub3QgYmUgcmVkdWNlZCB2aWEgZXhwbGljaXQgY29uZ2VzdGlvbg0KPiA+ID4+Pj4+ICAg ICAgIG5vdGlmaWNhdGlvbiBbUkZDMzE2OF0uICBUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IGEgRGV0 TmV0IGZsb3csIHRvIGJlDQo+ID4gPj4+Pj4gICAgICAgdXNlZnVsLCBtdXN0IGJlIGRlbGl2ZXJl ZCBpbiBpdHMgZW50aXJldHkuDQo+ID4gPj4+PiBXZWxsIGxvb2tpbmcgYXQgaXQgdGhpcyB3YXks IHRoZXJlIGlzIG5vIHRocm90dGxpbmcgaW4gYW55IElQDQo+ID4gPj4+PiBuZXR3b3JrIGFzIHRo ZSByb3V0ZXJzIGdlbmVyYXRlIHRoZSBDTiBhbmQgb25seSBkcm9wIHdoZW4gdGhlaXINCj4gPiA+ Pj4+IHF1ZXVlcyBhcmUgZnVsbCBvciBpbXBsZW1lbnRpbmcgc29tZSBzb3J0IG9mIFJFRC4NCj4g PiA+Pj4+DQo+ID4gPj4+PiBJbiBEZXROZXQgdGhlcmUgaXMgYW4gZXhwZWN0YXRpb24gdGhhdCBp bnRlcm1lZGlhdGUgbm9kZXMgZG8gbW9yZQ0KPiA+ID4+Pj4gdGhhbiB0aGlzLiAgU3BlY2lmaWNh bGx5LCBzZWUgc2VjdGlvbiA0LjU6ICJRdWV1aW5nLCBTaGFwaW5nLA0KPiA+ID4+Pj4gU2NoZWR1 bGluZywgYW5kIFByZWVtcHRpb24iIGFuZCBwb2xpY2luZywgd2hpY2ggaXMgbWVudGlvbmVkIGFz DQo+ID4gPj4+PiByZXF1aXJlbWVudCBpbiBzZWN0aW9uIDMuMy4xLg0KPiA+ID4+Pj4NCj4gPiA+ Pj4+PiBhbmQgbm8gYXNzdXJhbmNlIHRoYXQgYWxsIERldE5ldC11c2luZyBhcHBsaWNhdGlvbnMg d2lsbCBjZWFzZQ0KPiA+ID4+Pj4+IGFuZCBkZXNpc3QgaW4gdGhlIGZhY2Ugb2YgcGFja2V0IGRy b3BzIHRoYXQgaW5kaWNhdGUgY29uZ2VzdGlvbi4NCj4gPiA+Pj4+IEkgdGhpbmsgdGhpcyBpcyBj b3JyZWN0Lg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pj4gUGFja2V0IFJlcGxpY2F0aW9u IGFuZCBFbGltaW5hdGlvbiBtYWtlcyB0aGlzIHdvcnNlIHZpYSBpdHMNCj4gPiA+Pj4+PiBhYmls aXR5IHRvDQo+ID4gaGlkZQ0KPiA+ID4+Pj4+IG5ldHdvcmsgcGFja2V0IGRyb3BzIGFuZCBjb25n ZXN0aW9uIGluZGljYXRpb25zIGZyb20gZW5kcG9pbnRzLA0KPiA+ID4+Pj4+IGUuZy4sIG9mIHRo b3NlIGRyb3BzIGFuZC9vciBjb25nZXN0aW9uIGluZGljYXRpb25zIG9jY3VyIG9uIG9ubHkNCj4g PiA+Pj4+PiBvbmUgb2YgdGhlIHBhdGhzIHVzZWQgYnkgcmVwbGljYXRlZCBwYWNrZXRzLg0KPiA+ ID4+Pj4+DQo+ID4gPj4+Pj4gVGhlIGZpcnN0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDMuMy4yIGlz IGEgZ29vZCBzdGFydCwgYnV0IEkNCj4gPiA+Pj4+PiB0aGluayBpdHMgbG93ZXIgY2FzZSAic2hv dWxkIiBpcyB0b28gd2VhazoNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICAgICAgIFJvYnVzdCByZWFs LXRpbWUgc3lzdGVtcyByZXF1aXJlIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlDQo+ ID4gPj4+Pj4gICAgICAgZmFpbHVyZXMuICBGaWx0ZXJzIGFuZCBwb2xpY2VycyBzaG91bGQgYmUg dXNlZCBpbiBhIERldE5ldCBuZXR3b3JrIHRvDQo+ID4gPj4+Pj4gICAgICAgZGV0ZWN0IGlmIERl dE5ldCBwYWNrZXRzIGFyZSByZWNlaXZlZCBvbiB0aGUgd3JvbmcgaW50ZXJmYWNlLCBvciBhdA0K PiA+ID4+Pj4+ICAgICAgIHRoZSB3cm9uZyB0aW1lLCBvciBpbiB0b28gZ3JlYXQgYSB2b2x1bWUu ICBGdXJ0aGVybW9yZSwgZmlsdGVycyBhbmQNCj4gPiA+Pj4+PiAgICAgICBwb2xpY2VycyBjYW4g dGFrZSBhY3Rpb25zIHRvIGRpc2NhcmQgdGhlIG9mZmVuZGluZyBwYWNrZXRzIG9yIGZsb3dzLA0K PiA+ID4+Pj4+ICAgICAgIG9yIHRyaWdnZXIgc2h1dHRpbmcgZG93biB0aGUgb2ZmZW5kaW5nIGZs b3cgb3IgdGhlIG9mZmVuZGluZw0KPiA+ID4+Pj4+ICAgICAgIGludGVyZmFjZS4NCj4gPiA+Pj4+ Pg0KPiA+ID4+Pj4+IEF0IGEgbWluaW11bSwgSSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudCB0 byBkaXNjYXJkIERldE5ldA0KPiA+ID4+Pj4+IHRyYWZmaWMgdGhhdCB3b3VsZCBvdGhlcndpc2Ug ZXNjYXBlIGEgRGV0TmV0IG5ldHdvcmsgaGFzIHRvIGJlDQo+ID4gPj4+Pj4gc3RhdGVkIGFzIGEg Ik1VU1QiIHJlcXVpcmVtZW50IGZvciBhbnkgRGV0TmV0IG5ldHdvcmsgdGhhdA0KPiA+ID4+Pj4+ IHN1cHBvcnRzIFBhY2tldCBSZXBsaWNhdGlvbiBhbmQgRWxpbWluYXRpb24gZHVlIHRvIHRoZSBh YmlsaXR5DQo+ID4gPj4+Pj4gb2YgdGhhdCBmdW5jdGlvbmFsaXR5IHRvIGhpZGUgY29uZ2VzdGlv biBmcm9tIGVuZHBvaW50cywgbWFraW5nDQo+ID4gPj4+Pj4gaXQgaW1wb3NzaWJsZSBmb3IgaGln aGVyIGxheWVycyBvZiB0aGUgcHJvdG9jb2wgc3RhY2sgdG8gcmVzcG9uZC4NCj4gPiA+Pj4+IFRv IG1lIGNsZWFyLCB5b3VyIGFyZSBzdWdnZXN0aW5nIHRoYXQgdGV4dCBiZSBhZGRlZCB0byBzYXkg dGhhdA0KPiA+ID4+Pj4gc2VuZGluZyBkZXRuZXQgdHJhZmZpYyBvdXQgYSBub24tZGV0bmV0IGlu dGVyZmFjZXMgbXVzdCBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuDQo+ID4gPj4+PiBJcyB0aGlzIGNv cnJlY3Q/ICBJZiBzbywgSSB0aGluayB0aGlzIGlzIHRvbyBicm9hZCBjb25zaWRlcmluZw0KPiA+ ID4+Pj4gdGhhdCB0aGVyZSBhcmUgbmV0d29ya3MgdGhhdCBjYW4gcHJvdmlkZWQgdGhlIHJlcXVp cmVkIGRldG5ldA0KPiA+ID4+Pj4gZm9yd2FyZGluZyBzdWItbGF5ZXIgc2VydmljZSB0aGF0IGFy ZSBub3QgZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMNCj4gPiA+Pj4+IGlzIG1lbnRpb25lZCBhdCB0 aGUgZW5kIG9mIHNlY3Rpb24gNC4zLjIuIChJJ2xsIHJlZmVyIHRvIHN1Y2ggYXMNCj4gPiA+Pj4+ ICJEZXROZXQgc3VwcG9ydGluZyBuZXR3b3JrcyIgaW4gdGhlIG5leHQgcGFyYWdyYXBoLikNCj4g PiA+Pj4+DQo+ID4gPj4+PiBUaGlzIHNhaWQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVhc29uYWJs ZSB0byBtYWtlIGl0IGENCj4gPiA+Pj4+IHJlcXVpcmVtZW50IHRoYXQgRGV0TmV0IG5vZGVzIG11 c3Qgbm90IGZvcndhcmQgdHJhZmZpYyB0aGF0DQo+ID4gPj4+PiBkb2Vzbid0IGNvbmZvcm0gd2l0 aCBCQ1A0MSBvdmVyIGEgbmV0d29yayB0aGF0IGlzIG5laXRoZXIgYQ0KPiA+ID4+Pj4gRGV0bmV0 IG5ldHdvcmsgb3IgYSBEZXROZXQgc3VwcG9ydGluZyBuZXR3b3JrLiAgQWx0aG91Z2ggdGhpcw0K PiA+ID4+Pj4gd291bGQgcmVxdWlyZSBhIGNoYW5nZSB0byB0aGUgRGV0TmV0IHNlcnZpY2UgbW9k ZWwsIGkuZS4sICB0byBrbm93IHdoaWNoIHRyYWZmaWMgd2FzIGNvbmZvcm1hbnQvbm9uLWNvbmZv cm1hbnQuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiBCZXlvbmQgdGhpcywgSSB0aGlu ayBhICJTSE9VTEQiIHJlcXVpcmVtZW50IHRvIGRpc2NhcmQgRGV0TmV0DQo+ID4gPj4+Pj4gdHJh ZmZpYyB0aGF0IHdvdWxkIG90aGVyd2lzZSBlc2NhcGUgaXMgbmVlZGVkLCBhbmQgdGhlIHN0YXRl bWVudA0KPiA+ID4+Pj4+IG9mIHRoYXQgcmVxdWlyZW1lbnQgb3VnaHQgdG8gYmUgY29ubmVjdGVk IHRvIHRoZSBleHBsYW5hdGlvbiBvZg0KPiA+ID4+Pj4+IGhvdyB0byBpbXBsZW1lbnQgdGhhdCBy ZXF1aXJlbWVudC4NCj4gPiA+Pj4+IEkgdGhpbmsgYWRkaW5nIGEgc3RhdGVtZW50IG9uIG91dHB1 dCBmaWx0ZXJzIChhbmQgcG9saWNpZXJzKSB0bw0KPiA+ID4+Pj4gdGhpcyBzZWN0aW9uIGlzIHJl YXNvbmFibGUuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiBUaGUgdGV4dCBpbiBTZWN0 aW9uIDMuMy4yIGhhcyBhIGxvdCBvZiB0aGUgY29udGVudCBuZWVkZWQgLSBmb3INCj4gPiA+Pj4+ PiBhIHdvcmtlZCBleGFtcGxlIG9mIHN1Y2ggIlNIT1VMRCIgdGV4dCwgc2VlIFNlY3Rpb24gNSBv ZiBSRkMNCj4gPiA+Pj4+PiA3NTEwLCBpbiBwYXJ0aWN1bGFyIHRoZSBpdGVtaXplZCBsaXN0IGF0 IHRoZSBlbmQgb2YgdGhhdCBzZWN0aW9uDQo+ID4gPj4+Pj4gYW5kIHRoZSBwYXJhZ3JhcGggdGhh dCBpbnRyb2R1Y2VzIHRoYXQgbGlzdDoNCj4gPiA+Pj4+PiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzUxMCNzZWN0aW9uLTUNCj4gPiA+Pj4+IElmIEknbSBub3QgbWlzdGFr ZW4sIHN1Y2ggbWVjaGFuaXNtcyBhcmUgYWxyZWFkeSBpbmNsdWRlZCBpbiB0aGUNCj4gPiA+Pj4+ IGRvY3VtZW50IGFuZCB5b3UgcmVhbGx5IGFyZSBqdXN0IGFza2luZyB0aGVtIHRvIGJlIChyZSls aXN0ZWQgdG8NCj4gPiA+Pj4+IGVuc3VyZSB0aGF0IHRoaXMgaW1wb3J0IHBvaW50IGlzbid0IG1p c3NlZC4gIElzIHRoaXMgY29ycmVjdD8NCj4gPiA+Pj4+IEJlc2lkZXMgd2hhdCBpcyBtZW50aW9u ZWQgYWJvdmUsIGlzIHRoZXJlIGFueXRoaW5nIGVsc2UgbWlzc2luZz8NCj4gPiA+Pj4+DQo+ID4g Pj4+PiBUaGFua3MhDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gTG91DQo+ID4gPj4+Pg0KPiA+ID4+Pj4+ IFRoYW5rcywgLS1EYXZpZA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPj4+Pj4+IEZyb206IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZg0K PiA+ID4+Pj4+PiBKw6Fub3MNCj4gPiBGYXJrYXMNCj4gPiA+Pj4+Pj4gU2VudDogV2VkbmVzZGF5 LCBEZWNlbWJlciAxOSwgMjAxOCAxMDo1NCBBTQ0KPiA+ID4+Pj4+PiBUbzogRGV0TmV0IFdHDQo+ ID4gPj4+Pj4+IFN1YmplY3Q6IFtEZXRuZXRdIGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVy ZS0xMA0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBbRVhURVJOQUwgRU1BSUxd DQo+ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+IEhpLA0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBUaGUg RGV0TmV0IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBoYXMgYmVlbiB1cGRhdGVkIHRvIGFkZHJlc3MN Cj4gPiA+Pj4+Pj4gdGhlIGNvbW1lbnRzLiBUaGUgbmV3IHJldmlzaW9uICh2MTApIGlzIGF2YWls YWJsZSBhdA0KPiA+ID4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBUaGVyZSBo YXZlIGJlZW4gYSBudW1iZXIgb2YgZGlzY3Vzc2lvbiBpdGVtcyBlbWFpbHMgb24gdGhlDQo+ID4g Pj4+Pj4+IGxpc3QuIFRoZSB1cGRhdGVzIGFyZSBhbG9uZyB0aGUgbWFqb3IgZGlzY3Vzc2lvbiBp dGVtcywgd2hpY2gNCj4gPiA+Pj4+Pj4gYWxzbyBjb3ZlciB0aGUgZGVyaXZhdGl2ZSBkaXNjdXNz aW9ucywgYWRkcmVzcyB0aGUgY29tbWVudHMuDQo+ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+IFRoZSBt YWpvciBpdGVtcyBoYXZlIGJlZW4gc3VtbWFyaXplZCBpbjoNCj4gPiA+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMTk2OC5odG1s Lg0KPiA+ID4+Pj4+PiBGb2xsb3cgdXAgZGlzY3Vzc2lvbnMgaW1wbGllZCB0ZXJtaW5vbG9neSBj aGFuZ2VzIHN1bW1hcml6ZWQgaW46DQo+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDIwMzYuaHRtbDoNCj4gPiA+Pj4+Pj4g cmVwbGFjZSAidHJhbnNwb3J0IHN1Yi1sYXllciIgd2l0aCAiZm9yd2FyZGluZyBzdWItbGF5ZXIi DQo+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGV0bmV0 L2N1cnJlbnQvbXNnMDIwMzguaHRtbDoNCj4gPiA+Pj4+Pj4gcmVwbGFjZSAiY29uZ2VzdGlvbiBw cm90ZWN0aW9uIiB3aXRoICJyZXNvdXJjZSIgYWxsb2NhdGlvbiINCj4gPiA+Pj4+Pj4gQ29uc2Vx dWVudGx5LCB0aGUgZG9jdW1lbnQgaGFkIGEgZ29vZCAnc2N1cmIiLg0KPiA+ID4+Pj4+Pg0KPiA+ ID4+Pj4+PiBJbiBhZGRpdGlvbiwgb3V0c3RhbmRpbmcgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJl c3NlZCBhbG9uZw0KPiA+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2RldG5ldC9jdXJyZW50L21zZzAxOTQzLmh0bWwuDQo+ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+ IFBsZWFzZSBsZXQgdXMga25vdyBpZiBhbnkgY29tbWVudCBoYXBwZW5lZCB0byBiZSByZW1haW5l ZCBvcGVuLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPj4+Pj4+ IEphbm9zDQo+ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4g PiA+Pj4+Pj4gZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQo+ID4gPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+ID4gPj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ Pj4+PiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4gPj4+Pj4gZGV0bmV0QGlldGYub3JnPG1haWx0 bzpkZXRuZXRAaWV0Zi5vcmc+DQo+ID4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kZXRuZXQNCj4gPiA+Pj4+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+IGRldG5ldEBp ZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+IGRldG5ldEBpZXRmLm9y ZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RldG5ldA0KDQotLQ0KLS0tDQp0dGVAY3MuZmF1LmRlPG1haWx0bzp0dGVAY3Mu ZmF1LmRlPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KZGV0bmV0IG1haWxpbmcgbGlzdA0KZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0K --_000_AM5PR0701MB229243977255EA5DF23CDF9EAC800AM5PR0701MB2292_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgd2UgY2FuLCBhcyBpdCB3YXMgc3Rh dGVkIGluIHRoZSBjaGFydGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ 4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5UaGUgV29ya2luZyBHcm91cCB3aWxs IGluaXRpYWxseSBmb2N1cyBvbiBzb2x1dGlvbnMgZm9yIG5ldHdvcmtzIHRoYXQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMjIyMjIiPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5hcmUgdW5kZXIgYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvciB3 aXRoaW4gYSBjbG9zZWQgZ3JvdXAgb2Y8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPmFkbWluaXN0cmF0aXZlIGNvbnRyb2w7IHRoZXNlIGluY2x1ZGUgbm90IG9ubHkg Y2FtcHVzLXdpZGUgbmV0d29ya3MgYnV0PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5hbHNvIGNhbiBpbmNsdWRlIHByaXZhdGUgV0FOcy4gVGhlIERldE5ldCBXRyB3 aWxsIG5vdCBzcGVuZCBlbmVyZ3kgb248L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPnNvbHV0aW9ucyBmb3IgbGFyZ2UgZ3JvdXBzIG9mIGRvbWFpbnMgc3VjaCBhcyB0 aGUgSW50ZXJuZXQuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWxh4oCZenM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFuZHJldyBHLiBNYWxpcyAmbHQ7YWdtYWxpc0BnbWFp bC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMTEsIDIwMTkgMTA6 NDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFRvZXJsZXNzIEVja2VydCAmbHQ7dHRlQGNzLmZhdS5kZSZn dDs8YnI+DQo8Yj5DYzo8L2I+IEJhbMOhenMgVmFyZ2EgQSAmbHQ7YmFsYXpzLmEudmFyZ2FAZXJp Y3Nzb24uY29tJmd0OzsgRGV0TmV0IFdHICZsdDtkZXRuZXRAaWV0Zi5vcmcmZ3Q7OyBCbGFjaywg RGF2aWQgJmx0O0RhdmlkLkJsYWNrQGRlbGwuY29tJmd0OzsgSmFub3MgRmFya2FzICZsdDtKYW5v cy5GYXJrYXNAZXJpY3Nzb24uY29tJmd0OzsgTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5l dCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRuZXRdIGRyYWZ0LWlldGYtZGV0bmV0 LWFyY2hpdGVjdHVyZS0xMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9lcmxlc3Ms PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjb3VsZCBj ZXJ0YWlubHkgdHJ1dGhmdWxseSBzYXkgdGhhdCBpdCdzIG5vdCBpbnRlbmRlZCBmb3IgdGhlIG11 bHRpZG9tYWluIGJlc3QtZWZmb3J0IHB1YmxpYyBJbnRlcm5ldCBpbmZyYXN0cnVjdHVyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEZyaSwgSmFuIDExLCAyMDE5IGF0IDE6MTYgUE0gVG9lcmxlc3MgRWNrZXJ0ICZsdDs8YSBo cmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSI+dHRlQGNzLmZhdS5kZTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSByZWFsbHkgZG9uJ3Qga25vdyB3aGF0IHRoZSBiZW5lZml0IG9mIHRoaXMgdGV4dCB3b3VsZCBi ZS4gSU1ITyBpdCBpczxicj4NCm1vc3RseSBJRVNHIGNvZGUgbGFuZ3VhZ2UgYnV0IG5vdCByZWFs bHkgaGVscGZ1bGwgSU1ITy48YnI+DQo8YnI+DQpTb21ldGhpbmcgbGlrZSBHb29nbGVzIHdvcmxk d2lkZSBuZXR3b3JrIGNvdWxkIHN1cHBvcnQgRGV0TmV0IGlmIEdvb2dsZTxicj4NCndhbnRlZCB0 byA/ISBJdHMgYSBwcml2YXRlIFdBTiwgcmlnaHQgPyBBa2E6IHRoZXJlIGlzIG5vIHBoeXNjaWFs IHNjYWxlPGJyPg0KbGltaXRhdGlvbiwgcmlnaHQgPyBXaHkgZG9uJ3Qgd2Ugc2F5IHRoYXQgPzxi cj4NCjxicj4NCldoYXQgaXMgYSAmcXVvdDtsYXJnZSBudW1iZXIgb2YgZG9tYWlucyZxdW90OyA/ IEhvdyBhYm91dCBhIG5hdGlvbndpZGUgcmVzZWFyY2g8YnI+DQpuZXR3b3JrIHN1Y2ggYXMgSW50 ZXJuZXQgMiB3aXRoIGh1bmRyZWRzIG9mIGF0dGFjaGVkIG9yZ2FuaXphdGlvbnMuIElmPGJyPg0K SW50ZXJuZXQyIGludHJvZHVjZWQgRGV0TmV0IHNlcnZpY2VzIGFuZCBhbGxvd2VkIGludGVyZXN0 ZWQgSW50ZXJuZXQyPGJyPg0KcGFydGljaXBhbnRzIHRvIHBhcnRpY2lwYXRlIGluIGl0LCBleHRl bmRpbmcgRGV0TmV0IHNlcnZpY2VzIGludG8gdGhlaXI8YnI+DQpjb3VzZXMgPyBIb3cgYWJvdXQg YSBuYXRpb253aWRlIHNlcnZpY2UgcHJvdmlkZXIgYW5kIGl0cyBjdXN0b21lcnMgPzxicj4NCldl IGRvIHdhbnQgRGV0TmV0IHNlcnZpY2UsIHJpZ2h0ID88YnI+DQo8YnI+DQpUaGUgb25seSByZWFs IHJlcXVpcmVtZW50IGZvciBEZXROZXQgYmV0d2VlbiBBIGFuZCBCIGlzIHRoYXQgYWxsIHRyYW5z aXQ8YnI+DQpkb21haW5zIGJldHdlZW4gQSBhbmQgQiBzdXBwb3J0IERldE5ldC4gVGhpcyBpcyBm dW5kYW1lbnRhbGx5IG5vdDxicj4NCmRpZmZlcmVudCBmcm9tIHRoZSByZXF1aXJlbWVudCB0byBt YWtlIEVDTiB3b3JrLiBBcyBzb29uIGFzIGkgaGF2ZSBhPGJyPg0Kc2luZ2xlIGhvcCBhbG9uZyBh IHBhdGggbm90IHN1cHBvcnRpbmcgRUNOLCBteSBFQ04gYmFzZWQgY29uZ2VzdGlvbjxicj4NCmNv bnRyb2wgd2lsbCBoYXZlIHRvIGZhbGwgYmFjayB0byBkZWxheS12YXJpYXRpb24gb3IgbG9zcy1i YXNlZC4gQW5kIEVDTiBpczxicj4NCmRlZmluZWQgdG8gYmUgYW4gSW50ZXJuZXQgdGVjaG5vbG9n eS4gU28gd2h5IHdvdWxkIERldE5ldCBub3QgYmUgPzxicj4NCjxicj4NCiZxdW90O1doZW4gd2Ug ZmluYWxseSBnZXQgdG8gRGV0TmV0IENvbnRyb2wgUGxhbmUsIHdlIGRvbid0IHdhbnQgdG8gYm90 aGVyPGJyPg0Kd2l0aCBhbGwgdGhlIGNvbXBsZXhpdHkgb2YgbXVsdGktb3BlcmF0b3IgY29udHJv bCBwbGFuZSBiZWNhdXNlIGl0czxicj4NCmhhcmQgZW5vdWdoIHRvIGZpZ3VyZSBvdXQgaG93IHRv IG1ha2Ugb25lIERldE5ldCBTRE4gY29udHJvbGxlciB3b3JrJnF1b3Q7PGJyPg0KPGJyPg0KVGhh dHMgb25lIHBvc3NpYmxlIGhvbmVzdCBleGxhbmF0aW9uLCBidXQgZ2l2ZW4gaG93IGkgdGhpbmsg d2UgY2FuIG5vdDxicj4NCnByZWNkaXQgd2hhdCB0eXBlIG9mIG11bHRpLW9wZWF0b3IgZW52aXJv bm1lbnRzIGNvbnRyb2wgcGxhbmUgdGhlPGJyPg0KY29tbXVuaXR5IHdpbGwgaGF2ZSBpbnRlcmVz dCB0byB3b3JrIG9uIG92ZXIgdGltZSwgaXQgbWlnaHQgYmUgbW9yZTxicj4NCmFwcHJvcHJpYXRl IHRvIHNheSB0aGF0IGFuZCBub3QgdG8gY29tZSB1cCB3aXRoIGFuIHVuZGVyc3BlY2lmaWVkIGJp bmFyeTxicj4NCmRpc3RpbmN0aW9uIG9mIHdoYXQgaXMgYW5kIHdoYXQgaXMgbm90IERldE5ldC48 YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQombmJzcDsgJm5ic3A7IFRvZXJsZXNzPGJyPg0KPGJyPg0K T24gRnJpLCBKYW4gMTEsIDIwMTkgYXQgMDk6MTg6MzdBTSAmIzQzOzAwMDAsIEJhbD96cyBWYXJn YSBBIHdyb3RlOjxicj4NCiZndDsgR3JlYXQuIEkgYW0gZmluZSB0byBhZGQgdGhlc2UgZXhwbGlj aXQgc3RhdGVtZW50cyB0byBtYWtlIHRleHQgbW9yZSBjbGVhci48YnI+DQomZ3Q7IDxicj4NCiZn dDsgTmV3IHRleHQgaXMgaW5saW5lIHdpdGggdGhlIGdlbmVyYWwgc3RhdGVtZW50IGluIHRoZSBp bnRyb2R1Y3Rpb24gb2YgdGhlIGRyYWZ0Ojxicj4NCiZndDsgJnF1b3Q7Jm5ic3A7IERldE5ldCBp cyBmb3IgbmV0d29ya3MgdGhhdCBhcmUgdW5kZXIgYSBzaW5nbGU8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9yIHdpdGhpbiBhIGNsb3NlZCBncm91cCBvZiBh ZG1pbmlzdHJhdGl2ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGNvbnRyb2w7IHRoZXNlIGluY2x1 ZGUgY2FtcHVzLXdpZGUgbmV0d29ya3MgYW5kIHByaXZhdGUgV0FOcy4mbmJzcDsgRGV0TmV0PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgaXMgbm90IGZvciBsYXJnZSBncm91cHMgb2YgZG9tYWlucyBz dWNoIGFzIHRoZSBJbnRlcm5ldC4mbmJzcDsgJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENo ZWVyczxicj4NCiZndDsgQmFsYSd6czxicj4NCiZndDsgPGJyPg0KJmd0OyBQczogQWxzbywgbm90 ZSB0aGF0ICZxdW90O0RldE5ldCBmbG93cyZxdW90OyBhcmUgdW5pZGlyZWN0aW9uYWwgLi4uIDot LS0pKSkpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyBGcm9tOiBkZXRuZXQgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg T24gQmVoYWxmIE9mIEJsYWNrLCBEYXZpZDxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSmFudWFy eSA4LCAyMDE5IDY6NDYgUE08YnI+DQomZ3Q7IFRvOiBMb3UgQmVyZ2VyICZsdDs8YSBocmVmPSJt YWlsdG86bGJlcmdlckBsYWJuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmxiZXJnZXJAbGFibi5uZXQ8 L2E+Jmd0OzsgSmFub3MgRmFya2FzICZsdDs8YSBocmVmPSJtYWlsdG86SmFub3MuRmFya2FzQGVy aWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkphbm9zLkZhcmthc0Blcmljc3Nvbi5jb208L2E+ Jmd0OzsgRGV0TmV0IFdHICZsdDs8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+ZGV0bmV0QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJl OiBbRGV0bmV0XSBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgVGhhdCdzIGZpbmUgYW5kIHdoYXQgd2FzIGludGVuZGVkLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBUaGFua3MsIC0tRGF2aWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBMb3UgQmVyZ2VyIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVy Z2VyQGxhYm4ubmV0PC9hPl08YnI+DQomZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBKYW51YXJ5IDcs IDIwMTkgNDo0OSBQTTxicj4NCiZndDsgJmd0OyBUbzogQmxhY2ssIERhdmlkOyBKw6Fub3MgRmFy a2FzOyBEZXROZXQgV0c8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtEZXRuZXRdIGRyYWZ0 LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IFtFWFRFUk5BTCBFTUFJTF08YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IERhdmlkLDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7IFRoaXMgbG9va3MgZ29vZC9yaWdodCB0byBtZS4mbmJzcDsgVGhlIG9u bHkgc3BlY2lmaWMgY2hhbmdlIEknZCBhZGQgaXMgPGJyPg0KJmd0OyAmZ3Q7IHRvIGNsYXJpZnkg dGhhdCB3ZSdyZSB0YWxraW5nIFBFUk9GIHRyYWZmaWMgd2hlbiBzYXlpbmcgJnF1b3Q7RGV0TmV0 IDxicj4NCiZndDsgJmd0OyByZXBsaWNhdGVkIHRyYWZmaWMmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGFua3MhPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBM b3U8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIDEvNy8yMDE5IDEwOjQ0IEFNLCBC bGFjaywgRGF2aWQgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgTG91LDxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXR0ZW1wdGluZyB0byBzdW1tYXJpemUgd2hhdCBu ZWVkcyB0byBiZSBzdGF0ZWQgd2l0aG91dCB1c2luZzxicj4NCiZndDsgJmd0OyBNVVNUL1NIT1VM RC9NQVk6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBbMV0gU2VuZGlu ZyBEZXROZXQgdHJhZmZpYyBpbnRvIG5ldHdvcmtzIHRoYXQgaGF2ZSBub3QgYmVlbiA8YnI+DQom Z3Q7ICZndDsgJmd0OyBwcm92aXNpb25lZCBpbjxicj4NCiZndDsgJmd0OyBhZHZhbmNlIHRvIGhh bmRsZSB0aGF0IERldE5ldCB0cmFmZmljIGhhcyB0byBiZSB0cmVhdGVkIGFzIGEgZmF1bHQuJm5i c3A7IDxicj4NCiZndDsgJmd0OyBFZ3Jlc3MgdHJhZmZpYyBmaWx0ZXJzIHRvIHByZXZlbnQgdGhp cyBmcm9tIGhhcHBlbmluZyBhcmUgc3Ryb25nbHkgPGJyPg0KJmd0OyAmZ3Q7IHJlY29tbWVuZGVk IGF0IHRoZSBlZGdlcyBvZiBEZXROZXQgbmV0d29ya3MgYW5kIERldE5ldCBzdXBwb3J0aW5nIDxi cj4NCiZndDsgJmd0OyBuZXR3b3Jrcy4mbmJzcDsgSW4gdGhpcyBjb250ZXh0LCB0aGUgdGVybSAn cHJvdmlzaW9uZWQnIGhhcyBhIGJyb2FkIDxicj4NCiZndDsgJmd0OyBtZWFuaW5nLCBlLmcuLCBw cm92aXNpb25pbmcgY291bGQgYmUgcGVyZm9ybWVkIHZpYSBhbiBhZG1pbmlzdHJhdGl2ZSA8YnI+ DQomZ3Q7ICZndDsgZGVjaXNpb24gdGhhdCB0aGUgZG93bnN0cmVhbSBuZXR3b3JrIGhhcyB0aGUg YXZhaWxhYmxlIGNhcGFjaXR5IHRvIGNhcnJ5IHRoZSBEZXROZXQgdHJhZmZpYyB0aGF0IGlzIGJl aW5nIHNlbnQgaW50byBpdC48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IFsyXSBTZW5kaW5nIG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQgRGV0TmV0IHRyYWZmaWMgKGku ZS4sIERldE5ldCA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0cmFmZmljIHRoYXQ8YnI+DQomZ3Q7ICZn dDsgZG9lcyBub3QgY29tcGx5IHdpdGggQkNQIDQxL1JGQyAyOTE0KSBpbnRvIGEgbmV0d29yayB0 aGF0IGlzIG5vdCA8YnI+DQomZ3Q7ICZndDsgcHJvdmlzaW9uZWQgdG8gaGFuZGxlIHRoYXQgdHJh ZmZpYyBoYXMgdG8gYmUgcHJldmVudGVkIGluIGFkZGl0aW9uIHRvIGJlaW5nIHRyZWF0ZWQgYXMg YSBmYXVsdC48YnI+DQomZ3Q7ICZndDsgRGV0TmV0IHRyYWZmaWMgdGhhdCBpcyBub3Qga25vd24g dG8gYmUgY29uZ2VzdGlvbiBjb250cm9sbGVkIGhhcyB0byBiZSA8YnI+DQomZ3Q7ICZndDsgdHJl YXRlZCBhcyBub24tY29uZ2VzdGlvbi1jb250cm9sbGVkIERldE5ldCB0cmFmZmljIGZvciB0aGlz IDxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVudC4mbmJzcDsgRGV0TmV0IHJlcGxpY2F0ZWQgdHJh ZmZpYyBpcyBhbHdheXMgPGJyPg0KJmd0OyAmZ3Q7IG5vbi1jb25nZXN0aW9uLWNvbnRyb2xsZWQg ZXZlbiBpZiB0aGUgb3JpZ2luYWwgRGV0TmV0IGZsb3cgaXMgPGJyPg0KJmd0OyAmZ3Q7IGNvbmdl c3Rpb24tY29udHJvbGxlZCBiZWNhdXNlIERldE5ldCBwYWNrZXQgZWxpbWluYXRpb24gY2FuIGhp ZGUgPGJyPg0KJmd0OyAmZ3Q7IGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgKGUuZy4sIGRyb3BzLCBF Q04gQ0UgbWFya3MsIGluY3JlYXNlZCBsYXRlbmN5KSA8YnI+DQomZ3Q7ICZndDsgZnJvbSBlbmRw b2ludHMuJm5ic3A7IFRoZSByZXNwb25zaWJpbGl0eSBmb3IgZGVhbGluZyB3aXRoIHRoZXNlIDxi cj4NCiZndDsgJmd0OyByZXF1aXJlbWVudHMgaW4gZ2VuZXJhbCwgYW5kIHJlcGxpY2F0ZWQgdHJh ZmZpYyBpbiBwYXJ0aWN1bGFyLCBpcyA8YnI+DQomZ3Q7ICZndDsgc29sdXRpb24tc3BlY2lmaWMs IGFzIHRoZXJlIGFyZSBNUExTIG1lY2hhbmlzbXMgdGhhdCBjYW5ub3QgYmUgYXBwbGllZCB0byB0 aGUgSVAgc29sdXRpb24sIGFuZCBtb3Jlb3ZlciwgdGhlIGN1cnJlbnQgSVAgc29sdXRpb24gZG9l c24ndCBzdXBwb3J0IERldE5ldCB0cmFmZmljIHJlcGxpY2F0aW9uLjxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmtzLCAtLURhdmlkPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsgRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+bGJlcmdlckBsYWJuLm5ldDwv YT5dPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDI1LCAy MDE4IDExOjQ1IEFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFRvOiBCbGFjaywgRGF2aWQ7IErD oW5vcyBGYXJrYXM7IERldE5ldCBXRzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBS ZTogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7IFtFWFRFUk5BTCBFTUFJTF08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgSGkgRGF2aWQsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7IE9uIDEyLzI0LzIwMTggODoyOSBQTSwgQmxhY2ssIERhdmlkIHdyb3RlOjxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSGkgTG91LDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEV4Y2VycHRpbmcga2V5IHBhcmFncmFw aHMgLi4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFRvIG1lIGNsZWFyLCB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCB0ZXh0IGJlIGFk ZGVkIHRvIHNheSB0aGF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNlbmRpbmcg ZGV0bmV0IHRyYWZmaWMgb3V0IGEgbm9uLWRldG5ldCBpbnRlcmZhY2VzIG11c3QgYmUgdHJlYXRl ZCBhcyBhIGZhdWx0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElzIHRoaXMgY29y cmVjdD88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IE5vdCBleGFjdGx5IC4uLjxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJZiBz bywgSSB0aGluayB0aGlzIGlzIHRvbyBicm9hZCBjb25zaWRlcmluZyB0aGF0IHRoZXJlIGFyZSA8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrcyB0aGF0IGNhbiBwcm92aWRl ZCB0aGUgcmVxdWlyZWQgZGV0bmV0IGZvcndhcmRpbmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgc3ViLWxheWVyIHNlcnZpY2UgdGhhdCBhcmUgbm90IGRldG5ldCBzZXJ2aWNlIGF3 YXJlIGFzIGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG1lbnRpb25lZCBhdCB0 aGUgZW5kIG9mIHNlY3Rpb24gNC4zLjIuIChJJ2xsIHJlZmVyIHRvIHN1Y2ggYXMgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7RGV0TmV0IHN1cHBvcnRpbmcgbmV0d29ya3Mm cXVvdDsgaW4gdGhlIG5leHQgcGFyYWdyYXBoLik8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 IEkgYWdyZWUgd2l0aCB3aGVyZSB0aGlzIGlzIGhlYWRlZCAtIHNlbmRpbmcgRGV0TmV0IHRyYWZm aWMgaW50byBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgbmV0d29yayB0aGF0IGhhcyBu b3QgYmVlbiBwcm92aXNpb25lZCB0byBwcm92aWRlIHRoZSByZXF1aXJlZCA8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IGRldG5ldCBmb3J3YXJkaW5nIHNlcnZpY2UgdG8gdGhhdCB0cmFmZmlj IGhhcyB0byBiZSB0cmVhdGVkIGFzIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBmYXVs dC4mbmJzcDsgSW4gdGhpcyBzdGF0ZW1lbnQsICZxdW90O3Byb3Zpc2lvbmVkJnF1b3Q7IHNob3Vs ZCBiZSByZWFkIGJyb2FkbHksIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgZS5nLiwgaXQg Y291bGQgYmUgcmVhbGl6ZWQgdmlhIGFuIGFkbWluaXN0cmF0aXZlIGRlY2lzaW9uIHRoYXQgdGhl IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgRGV0TmV0IHN1cHBvcnRpbmcgbmV0d29yayBo YXMgdGhlIGF2YWlsYWJsZSBjYXBhY2l0eSB0byBjYXJyeSB0aGUgRGV0TmV0IHRyYWZmaWMgdGhh dCBpcyBiZWluZyBzZW50IGludG8gaXQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IGFncmVlZC48 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIHNhaWQsIEkgdGhpbmsgaXQgd291 bGQgYmUgcmVhc29uYWJsZSB0byBtYWtlIGl0IGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgcmVxdWlyZW1lbnQgdGhhdCBEZXROZXQgbm9kZXMgbXVzdCBub3QgZm9yd2FyZCB0cmFm ZmljIHRoYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZG9lc24ndCBjb25mb3Jt IHdpdGggQkNQNDEgb3ZlciBhIG5ldHdvcmsgdGhhdCBpcyBuZWl0aGVyIGEgPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRGV0bmV0IG5ldHdvcmsgb3IgYSBEZXROZXQgc3VwcG9ydGlu ZyBuZXR3b3JrLiZuYnNwOyBBbHRob3VnaCB0aGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IHdvdWxkIHJlcXVpcmUgYSBjaGFuZ2UgdG8gdGhlIERldE5ldCBzZXJ2aWNlIG1vZGVs LCBpLmUuLCZuYnNwOyB0byBrbm93IHdoaWNoIHRyYWZmaWMgd2FzIGNvbmZvcm1hbnQvbm9uLWNv bmZvcm1hbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGF0J3MgZmluZSB3aXRoIG9u ZSBpbXBvcnRhbnQgdHdpc3Q6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgQW55IHRyYWZmaWMgdGhhdCBoYXMgYmVlbiByZXBsaWNhdGVkIGJ5 IERldE5ldCBwYWNrZXQgcmVwbGljYXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBo YXMgdG8gYmUgdHJlYXRlZCBhcyBub3QgY29uZm9ybWluZyB3aXRoIEJDUDQxIGJlY2F1c2UgRGV0 TmV0IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgcGFja2V0IGVsaW1pbmF0aW9uIChvZiBy ZXBsaWNhdGVkIHBhY2tldHMpIG1heSBoaWRlIGNvbmdlc3Rpb24gPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyBpbmRpY2F0aW9ucyAoZS5nLiwgZGVsYXksIEVDTiBDRSBtYXJrcywgZHJvcHMp IGZyb20gdGhlIGVuZHBvaW50cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0gYSBzY2Vu YXJpbyBvZiBwYXJ0aWN1bGFyIGNvbmNlcm4gaW52b2x2ZXMgdGhlIG90aGVyIGZsb3cgb2YgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyByZXBsaWNhdGVkIHBhY2tldHMgZm9sbG93aW5nIGEg RGV0TmV0IG5ldHdvcmsgcGF0aCBhbG9uZyB3aGljaCBub3RoaW5nIGdvZXMgd3JvbmcuPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBCQ1A0MSBpcyBhYm91dCBlbmQtdG8tZW5kLWNvbmdlc3Rp b24gY29udHJvbCwgd2hpY2ggZG9lcyBub3QgZG8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBhbnl0aGluZyBpZiBEZXROZXQgcGFja2V0IGVsaW1pbmF0aW9uIGhpZGVzIGNvbmdlc3Rpb24g aW5kaWNhdGlvbnMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBmcm9tIHRoZSBlbmRwb2lu dHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFRoaXMgc2VlbXMgcmVhc29uYWJsZSB0byBtZS48 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmV5b25kIHRoaXMsIEkgdGhpbmsgYSAmcXVvdDtT SE9VTEQmcXVvdDsgcmVxdWlyZW1lbnQgdG8gZGlzY2FyZCBEZXROZXQgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYWZmaWMgdGhhdCB3b3VsZCBvdGhlcndpc2UgZXNjYXBl IGlzIG5lZWRlZCwgYW5kIHRoZSBzdGF0ZW1lbnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG9mIHRoYXQgcmVxdWlyZW1lbnQgb3VnaHQgdG8gYmUgY29ubmVjdGVkIHRvIHRo ZSBleHBsYW5hdGlvbiBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaG93 IHRvIGltcGxlbWVudCB0aGF0IHJlcXVpcmVtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IEkgdGhpbmsgYWRkaW5nIGEgc3RhdGVtZW50IG9uIG91dHB1dCBmaWx0ZXJzIChhbmQg cG9saWNlcnMpIHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgc2VjdGlv biBpcyByZWFzb25hYmxlLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgTGV0J3Mgc3RhcnQg d2l0aCB0aGUgaW5jbHVzaW9uIG9mIG91dHB1dCBmaWx0ZXJzIChhbmQgcG9saWNlcnMpIGluIDxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhlIDMuMy4yIHRleHQgd2l0aCB0aGUgdXNlIG9m IHVwcGVyLWNhc2UgJnF1b3Q7U0hPVUxEJnF1b3Q7IGFzIHN1Z2dlc3RlZCBieSA8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IFBhc2NhbCAtIEkgd2lsbCBsb29rIHRoaXMgb3ZlciBhbmQgc3Vn Z2VzdCBhbnkgYWRkaXRpb25hbCB0ZXh0IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhh dCBJIHRoaW5rIG91Z2h0IHRvIGJlIGluY2x1ZGVkLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBB cyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQsIHRoZSBhdXRob3JzL1dHIG1hZGUgdGhlIGNhbGwg dG8gbm90IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB1c2UgY29uZm9ybWFuY2UgY2FwaXRhbGl6 YXRpb24gb3IgcmVmZXJlbmNlIDIxMTkvODE3NC4mbmJzcDsgSSB0aGluayA8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgdGhpcyB0cmFuc2xhdGVzIHRvIHRoZSBjb25mb3JtYW5jZSBsYW5ndWFnZSBu ZWVkaW5nIHRvIGJlIGFkZGVkIHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB0aGUgZGF0YSBw bGFuZSBzb2x1dGlvbiBkb2N1bWVudHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgTG91PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGFua3MsIC0tRGF2aWQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5u ZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPl08YnI+DQomZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBNb25kYXksIERlY2VtYmVyIDI0LCAyMDE4IDM6MTggUE08 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUbzogQmxhY2ssIERhdmlkOyBKw6Fub3Mg RmFya2FzOyBEZXROZXQgV0c8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogW0RldG5ldF0gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFtFWFRFUk5BTCBFTUFJTF08YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhp IERhdmlkLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgT24gMTIvMTkvMjAxOCAxMjozNyBQTSwgQmxhY2ssIERhdmlkIHdyb3Rl Ojxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKYW5vcyw8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlIHRlcm1pbm9sb2d5IGlzIGRlZmluaXRlbHkgaW1wcm92ZWQgLSB0aGUgcmVzdWx0aW5n IGRyYWZ0IGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtdWNoIGNsZWFy ZXIgLSBtYW55IHRoYW5rcyB0byB5b3UgYW5kIHRoZSBhdXRob3JzIGZvciBkb2luZyB0aGF0Ljxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhhcHB5IHRvIGhlYXIgdGhhdC48YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoZXJlIGRvIHdlIHN0YW5kIG9u IHRoZSBjb25jZXJuIGFib3V0IHByb3RlY3RpbmcgZXh0ZXJuYWwgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vbi1EZXROZXQgbmV0d29ya3MgZnJvbSBEZXROZXQgZmxvd3Mg dGhhdCBlc2NhcGUgYSBEZXROZXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG5ldHdvcmssIGUuZy4sIGR1ZSB0byBhbiBlcnJvbmVvdXMgbmV0d29yayBjb25maWd1cmF0aW9u IGNoYW5nZT88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJJ20gbm90IHN1cmUgd2Ug aGF2ZSBnZW5lcmFsIHNvbHV0aW9ucyBpbiB0aGUgaW50ZXJuZXQgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgYXJjaGl0ZWN0dXJlIGZvciBtaXNzLWNvbmZpZ3VyZWQvYnVnZ3kgc3lz dGVtcyBvdGhlciB0aGFuIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRyb3BwaW5n IHRoZSBwYWNrZXRzIG9uIHRoZSBmbG9vciAoZS5nLiwgZHVlIHRvIG5vIHJvdXRlLCBubyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBsYWJlbCwgb3IgdHRsIGV4cGlyeSkuJm5ic3A7 IFdoYXQgdHlwZSBvZiBwcm90ZWN0aW9uIGFyZSB5b3UgbG9va2luZyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBmb3IgaGVyZSwgYW5kIGNhbiB5b3UgcHJvdmlkZSBhIHJlZmVyZW5j ZSB0byB0aGUgdHlwZSBvZiByb3V0ZXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg YmVoYXZpb3IgeW91IHdvdWxkIGxpa2UgdG8gc2VlPyZuYnNwOyBJIGhhdmUgYSBzdWdnZXN0aW9u IHRoYXQgbWlnaHQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYWRkcmVzcyB5b3Vy IGNvbmNlcm4gYmVsb3cgZWxhdGVkIHRvIG5vbi1CQ1A0MSBjb25mb3JtYW50IHRyYWZmaWMsIGJ1 dCBhbSB1bnN1cmUgaWYgdGhpcyBpcyB3aGF0IHlvdSBhcmUgY29uY2VybmVkIGFib3V0Ljxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE15IGN1cnJlbnQgdmlld3MgYXJlIC4uLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSdzIG5v IHRocm90dGxpbmcgaW4gRGV0TmV0LCBlLmcuLCB0aGlzIHRleHQgaW4gNC4zLjI6PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlcmUgaXMgbm8gcHJvdmlzaW9uIGlu IERldE5ldCBmb3IgdGhyb3R0bGluZyBEZXROZXQgZmxvd3MsIGkuZS4sPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHRyYW5z bWlzc2lvbiByYXRlIGNhbm5vdCBiZSByZWR1Y2VkIHZpYSBleHBsaWNpdCBjb25nZXN0aW9uPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7bm90aWZpY2F0aW9uIFtSRkMzMTY4XS4mbmJzcDsgVGhlIGFzc3VtcHRpb24gaXMgdGhhdCBh IERldE5ldCBmbG93LCB0byBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZWZ1bCwgbXVzdCBiZSBkZWxpdmVyZWQgaW4gaXRz IGVudGlyZXR5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdlbGwgbG9va2luZyBh dCBpdCB0aGlzIHdheSwgdGhlcmUgaXMgbm8gdGhyb3R0bGluZyBpbiBhbnkgSVAgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yayBhcyB0aGUgcm91dGVycyBnZW5lcmF0ZSB0 aGUgQ04gYW5kIG9ubHkgZHJvcCB3aGVuIHRoZWlyIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IHF1ZXVlcyBhcmUgZnVsbCBvciBpbXBsZW1lbnRpbmcgc29tZSBzb3J0IG9mIFJFRC48 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IEluIERldE5ldCB0aGVyZSBpcyBhbiBleHBlY3RhdGlvbiB0aGF0IGludGVybWVkaWF0 ZSBub2RlcyBkbyBtb3JlIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYW4gdGhp cy4mbmJzcDsgU3BlY2lmaWNhbGx5LCBzZWUgc2VjdGlvbiA0LjU6ICZxdW90O1F1ZXVpbmcsIFNo YXBpbmcsIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNjaGVkdWxpbmcsIGFuZCBQ cmVlbXB0aW9uJnF1b3Q7IGFuZCBwb2xpY2luZywgd2hpY2ggaXMgbWVudGlvbmVkIGFzIDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50IGluIHNlY3Rpb24gMy4zLjEu PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgYW5kIG5vIGFzc3VyYW5jZSB0aGF0IGFsbCBEZXROZXQtdXNpbmcgYXBwbGlj YXRpb25zIHdpbGwgY2Vhc2UgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCBkZXNpc3QgaW4gdGhlIGZhY2Ugb2YgcGFja2V0IGRyb3BzIHRoYXQgaW5kaWNhdGUgY29uZ2Vz dGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoaXMgaXMgY29y cmVjdC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhY2tldCBS ZXBsaWNhdGlvbiBhbmQgRWxpbWluYXRpb24gbWFrZXMgdGhpcyB3b3JzZSB2aWEgaXRzIDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYmlsaXR5IHRvPGJyPg0KJmd0OyAmZ3Q7 IGhpZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yayBwYWNrZXQg ZHJvcHMgYW5kIGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgZnJvbSBlbmRwb2ludHMsIDxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlLmcuLCBvZiB0aG9zZSBkcm9wcyBhbmQvb3Ig Y29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBvY2N1ciBvbiBvbmx5IDxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBvbmUgb2YgdGhlIHBhdGhzIHVzZWQgYnkgcmVwbGljYXRlZCBwYWNr ZXRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZmlyc3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gMy4zLjIg aXMgYSBnb29kIHN0YXJ0LCBidXQgSSA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhpbmsgaXRzIGxvd2VyIGNhc2UgJnF1b3Q7c2hvdWxkJnF1b3Q7IGlzIHRvbyB3ZWFrOjxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JvYnVzdCByZWFsLXRpbWUg c3lzdGVtcyByZXF1aXJlIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZmFp bHVyZXMuJm5ic3A7IEZpbHRlcnMgYW5kIHBvbGljZXJzIHNob3VsZCBiZSB1c2VkIGluIGEgRGV0 TmV0IG5ldHdvcmsgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRlY3QgaWYgRGV0TmV0IHBhY2tldHMgYXJlIHJlY2VpdmVk IG9uIHRoZSB3cm9uZyBpbnRlcmZhY2UsIG9yIGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHdyb25nIHRpbWUsIG9yIGlu IHRvbyBncmVhdCBhIHZvbHVtZS4mbmJzcDsgRnVydGhlcm1vcmUsIGZpbHRlcnMgYW5kPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 cG9saWNlcnMgY2FuIHRha2UgYWN0aW9ucyB0byBkaXNjYXJkIHRoZSBvZmZlbmRpbmcgcGFja2V0 cyBvciBmbG93cyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtvciB0cmlnZ2VyIHNodXR0aW5nIGRvd24gdGhlIG9mZmVuZGluZyBm bG93IG9yIHRoZSBvZmZlbmRpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnRlcmZhY2UuPGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEF0IGEg bWluaW11bSwgSSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBkaXNjYXJkIERldE5ldCA8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhZmZpYyB0aGF0IHdvdWxkIG90 aGVyd2lzZSBlc2NhcGUgYSBEZXROZXQgbmV0d29yayBoYXMgdG8gYmUgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXRlZCBhcyBhICZxdW90O01VU1QmcXVvdDsgcmVxdWly ZW1lbnQgZm9yIGFueSBEZXROZXQgbmV0d29yayB0aGF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0cyBQYWNrZXQgUmVwbGljYXRpb24gYW5kIEVsaW1pbmF0aW9u IGR1ZSB0byB0aGUgYWJpbGl0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg b2YgdGhhdCBmdW5jdGlvbmFsaXR5IHRvIGhpZGUgY29uZ2VzdGlvbiBmcm9tIGVuZHBvaW50cywg bWFraW5nIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpdCBpbXBvc3NpYmxl IGZvciBoaWdoZXIgbGF5ZXJzIG9mIHRoZSBwcm90b2NvbCBzdGFjayB0byByZXNwb25kLjxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvIG1lIGNsZWFyLCB5b3VyIGFyZSBzdWdnZXN0 aW5nIHRoYXQgdGV4dCBiZSBhZGRlZCB0byBzYXkgdGhhdCA8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBzZW5kaW5nIGRldG5ldCB0cmFmZmljIG91dCBhIG5vbi1kZXRuZXQgaW50ZXJm YWNlcyBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBmYXVsdC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBJcyB0aGlzIGNvcnJlY3Q/Jm5ic3A7IElmIHNvLCBJIHRoaW5rIHRoaXMgaXMgdG9v IGJyb2FkIGNvbnNpZGVyaW5nIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQg dGhlcmUgYXJlIG5ldHdvcmtzIHRoYXQgY2FuIHByb3ZpZGVkIHRoZSByZXF1aXJlZCBkZXRuZXQg PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBzdWItbGF5ZXIgc2Vy dmljZSB0aGF0IGFyZSBub3QgZGV0bmV0IHNlcnZpY2UgYXdhcmUgYXMgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgaXMgbWVudGlvbmVkIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA0LjMu Mi4gKEknbGwgcmVmZXIgdG8gc3VjaCBhcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAmcXVvdDtEZXROZXQgc3VwcG9ydGluZyBuZXR3b3JrcyZxdW90OyBpbiB0aGUgbmV4dCBwYXJh Z3JhcGguKTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgVGhpcyBzYWlkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlYXNvbmFibGUg dG8gbWFrZSBpdCBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50 IHRoYXQgRGV0TmV0IG5vZGVzIG11c3Qgbm90IGZvcndhcmQgdHJhZmZpYyB0aGF0IDxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXNuJ3QgY29uZm9ybSB3aXRoIEJDUDQxIG92ZXIg YSBuZXR3b3JrIHRoYXQgaXMgbmVpdGhlciBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IERldG5ldCBuZXR3b3JrIG9yIGEgRGV0TmV0IHN1cHBvcnRpbmcgbmV0d29yay4mbmJzcDsg QWx0aG91Z2ggdGhpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB3b3VsZCByZXF1 aXJlIGEgY2hhbmdlIHRvIHRoZSBEZXROZXQgc2VydmljZSBtb2RlbCwgaS5lLiwmbmJzcDsgdG8g a25vdyB3aGljaCB0cmFmZmljIHdhcyBjb25mb3JtYW50L25vbi1jb25mb3JtYW50Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmV5b25kIHRoaXMsIEkgdGhpbmsg YSAmcXVvdDtTSE9VTEQmcXVvdDsgcmVxdWlyZW1lbnQgdG8gZGlzY2FyZCBEZXROZXQgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYWZmaWMgdGhhdCB3b3VsZCBvdGhlcndp c2UgZXNjYXBlIGlzIG5lZWRlZCwgYW5kIHRoZSBzdGF0ZW1lbnQgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoYXQgcmVxdWlyZW1lbnQgb3VnaHQgdG8gYmUgY29ubmVj dGVkIHRvIHRoZSBleHBsYW5hdGlvbiBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaG93IHRvIGltcGxlbWVudCB0aGF0IHJlcXVpcmVtZW50Ljxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgYWRkaW5nIGEgc3RhdGVtZW50IG9uIG91dHB1dCBmaWx0 ZXJzIChhbmQgcG9saWNpZXJzKSB0byA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0 aGlzIHNlY3Rpb24gaXMgcmVhc29uYWJsZS48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoZSB0ZXh0IGluIFNlY3Rpb24gMy4zLjIgaGFzIGEgbG90IG9mIHRoZSBj b250ZW50IG5lZWRlZCAtIGZvciA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YSB3b3JrZWQgZXhhbXBsZSBvZiBzdWNoICZxdW90O1NIT1VMRCZxdW90OyB0ZXh0LCBzZWUgU2Vj dGlvbiA1IG9mIFJGQyA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgNzUxMCwg aW4gcGFydGljdWxhciB0aGUgaXRlbWl6ZWQgbGlzdCBhdCB0aGUgZW5kIG9mIHRoYXQgc2VjdGlv biA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHRoZSBwYXJhZ3JhcGgg dGhhdCBpbnRyb2R1Y2VzIHRoYXQgbGlzdDo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzUxMCNzZWN0aW9uLTUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzUxMCNzZWN0aW9uLTU8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgSWYgSSdtIG5vdCBtaXN0YWtlbiwgc3VjaCBtZWNoYW5pc21zIGFyZSBh bHJlYWR5IGluY2x1ZGVkIGluIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBk b2N1bWVudCBhbmQgeW91IHJlYWxseSBhcmUganVzdCBhc2tpbmcgdGhlbSB0byBiZSAocmUpbGlz dGVkIHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGVuc3VyZSB0aGF0IHRoaXMg aW1wb3J0IHBvaW50IGlzbid0IG1pc3NlZC4mbmJzcDsgSXMgdGhpcyBjb3JyZWN0PyA8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBCZXNpZGVzIHdoYXQgaXMgbWVudGlvbmVkIGFib3Zl LCBpcyB0aGVyZSBhbnl0aGluZyBlbHNlIG1pc3Npbmc/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MhPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBM b3U8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGFua3MsIC0tRGF2aWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBGcm9tOiBkZXRuZXQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBKw6Fub3M8 YnI+DQomZ3Q7ICZndDsgRmFya2FzPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE5LCAyMDE4IDEwOjU0IEFNPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogRGV0TmV0IFdHPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBbRGV0bmV0XSBkcmFmdC1pZXRm LWRldG5ldC1hcmNoaXRlY3R1cmUtMTA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0VYVEVSTkFMIEVNQUlMXTxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEhpLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBEZXROZXQgYXJjaGl0 ZWN0dXJlIGRvY3VtZW50IGhhcyBiZWVuIHVwZGF0ZWQgdG8gYWRkcmVzcyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjb21tZW50cy4gVGhlIG5ldyByZXZpc2lv biAodjEwKSBpcyBhdmFpbGFibGUgYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1k ZXRuZXQtYXJjaGl0ZWN0dXJlLTEwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTEwPC9hPi48YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgZGlzY3Vzc2lvbiBp dGVtcyBlbWFpbHMgb24gdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbGlzdC4gVGhlIHVwZGF0ZXMgYXJlIGFsb25nIHRoZSBtYWpvciBkaXNjdXNzaW9uIGl0ZW1z LCB3aGljaCA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFsc28gY292 ZXIgdGhlIGRlcml2YXRpdmUgZGlzY3Vzc2lvbnMsIGFkZHJlc3MgdGhlIGNvbW1lbnRzLjxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBtYWpvciBpdGVtcyBoYXZlIGJlZW4gc3VtbWFyaXplZCBp bjo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDE5Njgu aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMTk2OC5odG1sPC9hPi48YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZvbGxvdyB1cCBkaXNjdXNzaW9ucyBpbXBsaWVkIHRlcm1p bm9sb2d5IGNoYW5nZXMgc3VtbWFyaXplZCBpbjo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDIwMzYuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cwMjAzNi5o dG1sPC9hPjo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcGxhY2Ug JnF1b3Q7dHJhbnNwb3J0IHN1Yi1sYXllciZxdW90OyB3aXRoICZxdW90O2ZvcndhcmRpbmcgc3Vi LWxheWVyJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RldG5ldC9jdXJyZW50 L21zZzAyMDM4Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvZGV0bmV0L2N1cnJlbnQvbXNnMDIwMzguaHRtbDwvYT46PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXBsYWNlICZxdW90O2Nvbmdlc3Rpb24g cHJvdGVjdGlvbiZxdW90OyB3aXRoICZxdW90O3Jlc291cmNlJnF1b3Q7IGFsbG9jYXRpb24mcXVv dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENvbnNlcXVlbnRseSwg dGhlIGRvY3VtZW50IGhhZCBhIGdvb2QgJ3NjdXJiJnF1b3Q7Ljxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEluIGFkZGl0aW9uLCBvdXRzdGFuZGluZyBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2Vk IGFsb25nIDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZXRuZXQvY3VycmVudC9tc2cw MTk0My5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2RldG5ldC9jdXJyZW50L21zZzAxOTQzLmh0bWw8L2E+Ljxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBpZiBhbnkgY29tbWVudCBoYXBwZW5lZCB0byBi ZSByZW1haW5lZCBvcGVuLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEphbm9zPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldG5ldCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpkZXRuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldG5l dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRldG5ldEBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGRldG5ldCBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGRldG5l dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9hPjxicj4N Cjxicj4NCi0tIDxicj4NCi0tLTxicj4NCjxhIGhyZWY9Im1haWx0bzp0dGVAY3MuZmF1LmRlIiB0 YXJnZXQ9Il9ibGFuayI+dHRlQGNzLmZhdS5kZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRldG5ldCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZGV0bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGV0bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM5PR0701MB229243977255EA5DF23CDF9EAC800AM5PR0701MB2292_-- From nobody Sun Jan 13 22:20:04 2019 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 5B94B130F4F for ; Sun, 13 Jan 2019 22:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 header.b=Vc4gyNyc; dkim=pass (1024-bit key) header.d=ericsson.com header.b=RLN8O4Sg 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 yvrX_YyLc80l for ; Sun, 13 Jan 2019 22:20:00 -0800 (PST) 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 EEEEB130F55 for ; Sun, 13 Jan 2019 22:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547446798; x=1550038798; 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=5YM3H5ZfKidymip6urxBOW0A5CT71G72x8IqaEqQXBI=; b=Vc4gyNycu081sydy+yaKJb58pd6TqwXcHZBj/QkiOSYPoluT4tXtkC/MBqYr3wTs RG0khY/tLjJuksFtDe+BE7qNgG1AkRtjn1DZHL+UQw+JM7k7m/lT1hrSI442AU+H sL+koLKKMF3bm+so2HIvkA9I3UKDURYMNzgWI7tOkI8=; X-AuditID: c1b4fb25-209009e000005ff7-20-5c3c2a0e8920 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.74.24567.E0A2C3C5; Mon, 14 Jan 2019 07:19:58 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) 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; Mon, 14 Jan 2019 07:19:57 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Mon, 14 Jan 2019 07:19:57 +0100 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=5YM3H5ZfKidymip6urxBOW0A5CT71G72x8IqaEqQXBI=; b=RLN8O4SgSYscxtoExfZNKHjjk0XU1B/ts2EWR0z2kUqmk+fY+z5kQ8PA5PcHSifVwB3FEqqKobBN+Tozf1cT7/TjH2/EcJMCGPZu6qI0jwfiBwXUUOQ+p8dhFAMw/YG9rdkgFYDMfTK3FjBwxnnfsreEg26HYW8xq2B7LfLMpsA= Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com (10.169.152.15) by AM5PR0701MB2500.eurprd07.prod.outlook.com (10.169.153.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.17; Mon, 14 Jan 2019 06:19:51 +0000 Received: from AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36]) by AM5PR0701MB2292.eurprd07.prod.outlook.com ([fe80::8430:c69e:941b:ca36%2]) with mapi id 15.20.1537.018; Mon, 14 Jan 2019 06:19:50 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: Norman Finn , "Andrew G. Malis" , Lou Berger CC: detnet WG , Janos Farkas , "Black, David" Thread-Topic: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) Thread-Index: AQHUm8axlQxqvWEDxkeaQEj+Jds84KWOVmYAgBUUCICABn0QsIAEBACAgAB+z4A= Date: Mon, 14 Jan 2019 06:19:50 +0000 Message-ID: References: , <3DF0466E9510274382F5B74499ACD6F801720DDC@lhrpml504-mbx.exmail.huawei.com>, <3DF0466E9510274382F5B74499ACD6F8017231C9@lhrpml504-mbx.exmail.huawei.com> In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8017231C9@lhrpml504-mbx.exmail.huawei.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2500; 6:3raxe0JNx9YKQhK7JkyxN5kcrqwZ0uECT5AZjThxn61gS5nZqE6bfDQJ9q6ni5EWVI1PJbpIsWthV35VjVMtr9fU0laSwf2ZLI9s71JO7qHI6HNCPp6erisfrLAiOltXw3+sD1HN7A0dDDR4RstTlXK7kn2feH5WzUfxrKgCmZNNu0xqu2bt5Q0e1tuDgxvClLFgNtPmf4Yo3IYwpoluXUkiln0C22a1AH5c0YuPftoYn8Z9JDouQmMeYyRXArvNwZnEC2kJyrxLXGE8msX/c6kmVNQ8iN8P62089B/LTBOFBGFuyvc7QDQN8uJBXN0GPF12I6AxtDAvZQqlYmXU702XJztUBp8+Y9ZQKVKUQa7h0prmsuszHU12QaGLItrtvKlj7IfUTtjyEMk3BaDCKkLCD33JLU8zkIb/mK6VGyaUCYeXE6YwlDux/iUGmC+f+jUdSXq8WZPbN3Lz552KhQ==; 5:pkXZGZkAUysFKzGdB44FujcWVyhl303qOFGlOEnb98GgMtTlM8YfEqmv1Nb6jdm9DDAE8rP55y5A4X+7oEjqbldh4pAQlLhewIEUU9ppiMNwDU7vIWio2XtSOu98IZzhTkc+MVHl8f0el6Q0pvGSVPC0zflM2VW2ohUX/yit93b+c1uYA6XnTZEBKAEUlZbg5WrcPWqz8vh/6FJdLBWDow==; 7:yvmoe+JCF1F6rncJZ2RsR2oFmJvndS/SNtBVmcalVxpXqrbmRyJwADbaoPWB+z7ZlthtNrreKatZ02ZOFDYcoHUwotuNYCFr6k58oWa3GRpE257Fxsj1BzOIS7jbCOw3f4dvYfPwYFBBNaLUxD0y5g== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(376002)(396003)(51914003)(189003)(199004)(476003)(446003)(33656002)(97736004)(6246003)(99286004)(9326002)(6306002)(71200400001)(53546011)(54906003)(6506007)(486006)(53936002)(11346002)(54896002)(66574012)(71190400001)(9686003)(110136005)(3846002)(790700001)(6116002)(14454004)(478600001)(256004)(25786009)(236005)(55016002)(106356001)(14444005)(105586002)(93886005)(6346003)(66066001)(229853002)(39060400002)(26005)(186003)(102836004)(4326008)(76176011)(74316002)(7696005)(316002)(5660300001)(86362001)(68736007)(2906002)(81166006)(6436002)(7736002)(8936002)(8676002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2500; H:AM5PR0701MB2292.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: cb3888f7-c4f3-4d60-ba5e-08d679e84a5d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2500; x-ms-traffictypediagnostic: AM5PR0701MB2500: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Rt1ek5xr7nlEMBBHQYv/22CvD+G3ia17NxGyDpXLE7+3gKF8TwNlVj5N4pUAEQnh8Kk4uE0GZj/S931vBRZG3ahfpUfcBOlTZzRXFlBoWQnXQpvWZ94UxaK3pzna1idnRU3V84FX6+B/l0CzduSokXjlBKysFhCTak2V3qfSsgZ2usqX3YldiUDgi692sZhDbySAnewk4UQIDq/1FwAe+RMztB5/5C/nhqn99/LMnGQcI1hFMXC/ummQsSVXUCG4Woj7pYjArkVdJ5Cp8/UC7uVEGDgUi14H9tKO92Iz7UdZ5LgrHuPN6oP34PJkvJP7RkI6lL2qsFABuumkgbujcTUpVk8sR7Ovp1NpmJ+yrIHy4dDvxBAkPztd45UgASYT/ot6CkKarw/rPU/fQV6y/3gs/5EViGsR0niwiFeZuEo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB229249FFB06AA5EA205C7063AC800AM5PR0701MB2292_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cb3888f7-c4f3-4d60-ba5e-08d679e84a5d X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 06:19:50.5052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2500 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUiTYRTHe/a+e/dqrh6n5snchRNv/FiaXQxboRfRLrKkoESkXPmiMnX2 zky98jPMjzBxpFulrTExsmhKLgxipoUusQy0RCvLD1ILp6TpQnJ7DLz7/c//PP9zDjwsJRkQ BrFZufkcn6vOljHedHNyNx+1J1yZGm1cwQrH3CCjcBoe0ArXspFWVJX/pBWWfocgXqhqaG6i VM8NkyKV2bwuUC1ZyxmVrfOrMEmY4q1M57KzCjj+4LE078zBP2F5C09QobN7iSpBJiOqRl4s 4MPwrf62qBp5sxLch+DmdB9DxCqCLxumbWEWwNLddoFb0LiegtbJt9tvmgRg1dspImYR/B5v ZNzJDD4OK1VTHvbH1+BT2TvPRArz8KrSKXKzH86D+uG1rVh2q+cKlI7tI+2nYLHOIXQzjcOg wTTkYTFOA4elHZFZnTR0l76m3YYXPg/vl28hdw7CUpjqUJBRgTA+3SIgh2IwvximCAfAj++b QsIyaJof32YpjLTUePIBV4hgw2ncNmLgTftLihhdDDSU1YqIkQj2VYuAGCMIJqpaGWJEwuPm dc9lgLXQXs6TcjCMrpg8oRLMQVtHJapHcsOOZQlroVt/HRk8R/vCQPM0Tepy+KhvZAhHgOX+ AkU4Cpo2e+md9VYkeogCdJzuUk7GoVg5x2dd1um0ufJcLt+Ktj6YvcsVZkMfFhN6EWaRzEc8 F6hMlQjVBbqinF4ELCXzF9esxaVKxOnqomKO117kr2Zzul50gKVlgeK/Et9UCc5Q53Majsvj +P+ugPUKKkGcUGIpNJz9fOZk4oJPqHy1pTNSkRCij9Mm7n82Ort6Z++EtXbJZksyz2iSLdGU sXOQVlnNLml8XFHEzOnQRwlR4p5fmhP3qoJDQo7eCG6zo90Nxf368LHoNa3DLp3vOZJUXXHB FORXN/RUGRvqn6MeKNZU90jbdp2LdKVoLDJal6mOCad4nfofOz4PA1wDAAA= Archived-At: Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re: draft-ietf-detnet-architecture-10) 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, 14 Jan 2019 06:20:03 -0000 --_000_AM5PR0701MB229249FFB06AA5EA205C7063AC800AM5PR0701MB2292_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Norm, OK, now I see your case better. Thanks for the clarification. In such a case remarking is OK. :--))) Cheers Bala'zs From: Norman Finn Sent: Sunday, January 13, 2019 11:44 PM To: Bal=E1zs Varga A ; Andrew G. Malis ; Lou Berger Cc: detnet WG ; Janos Farkas ; = Black, David Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) We may have been talking about different things, and I mistyped. I identified DetNet flows that exceed bandwidth must be dropped. Traffic that cannot be identified as a DetNet flow, but have a DetNet DSCP,= may need to be marked down. For example, a host that is not authorized to= transmit DetNet traffic sends something with the DetNet DSCP. In a networ= k using CQF, you don't need to identify every packet's flow by 6-tuple; the= DSCP is sufficient to assign the packet to the right DetNet queue. You ma= y well do 6-tuple flow identification at the edge, only. So, a non-DetNet = packet with a DetNet DSCP has to be remarked. That's the case I was talkin= g about. -- Norm ________________________________ From: Bal=E1zs Varga A [balazs.a.varga@ericsson.com] Sent: Friday, January 11, 2019 1:36 AM To: Norman Finn; Andrew G. Malis; Lou Berger Cc: detnet WG; Janos Farkas; Black, David Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Hi Norm, > 1. You may well need more than one DSCP for DetNet region for different c= lasses of service. Yes, and we have defined the 6-tupple match for flow identification, what a= llows multiple DSCP values. > 2. You don't want to discard unexpected packets with a DetNet DSCP -- you= want to remark > them to a non-DSCP code point. Not good if configuring (or misconfigurin= g) a QoS feature > destroys a bystander's connectivity. That is an interesting topic. What do You mean by "unexpected packet"? If i= t breaks the traffic profile we must drop. I am not sure remarking is a good idea. What = do You mean by "non-DSCP code point"? General, I think configuration errors may destroy DetNet (and any other) fl= ows connectivity. We have to live with that. You can mitigate them e.g., by "proper maintenan= ce procedures", etc. That points to the importance of DetNet OAM being able to detect confi= guration (and other) errors. Cheers Bala'zs From: detnet > On B= ehalf Of Norman Finn Sent: Monday, January 7, 2019 7:20 AM To: Andrew G. Malis >; Lou Berg= er > Cc: detnet WG >; Janos Farkas >; Black, David > Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) 1. You may well need more than one DSCP for DetNet region for different cla= sses of service. 2. You don't want to discard unexpected packets with a DetNet DSCP -- you w= ant to remark them to a non-DSCP code point. Not good if configuring (or m= isconfiguring) a QoS feature destroys a bystander's connectivity. -- Norm ________________________________ From: detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmali= s@gmail.com] Sent: Monday, December 24, 2018 12:26 PM To: Lou Berger Cc: detnet WG; Black, David; J=E1nos Farkas Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (was Re:= draft-ietf-detnet-architecture-10) Lou, Thanks for following up. Cheers, Andy On Mon, Dec 24, 2018 at 3:24 PM Lou Berger > wrote: Andy, Just following up on one point on DetNet-specific DSCPs: On 12/19/2018 1:11 PM, Andrew G. Malis wrote: > In that case, the DetNet flows would most probably be a using > DetNet-specific DSCP, and if the ingress interface isn't properly > provisioned to know how to process packets with that DSCP, they'll at > least be reduced to best-effort treatment.. We can also recommend that > packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such packets= . While I personally think use of DSCPs will be useful in supporting aggregated DetNet flows, the IP solution draft has no requirement that operators or vendors restrict DetNet flows to a specific DSCP value. -- I personally think this is an important design point. Happy Holidays! Lou --_000_AM5PR0701MB229249FFB06AA5EA205C7063AC800AM5PR0701MB2292_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Norm,

OK, now I see your case better. Thanks for the clari= fication.

In such a case remarking is OK. :--)))

Cheers

Bala’zs

 

From: Norman Finn <norman.finn@mail01.huaw= ei.com>
Sent: Sunday, January 13, 2019 11:44 PM
To: Bal=E1zs Varga A <balazs.a.varga@ericsson.com>; Andrew G. = Malis <agmalis@gmail.com>; Lou Berger <lberger@labn.net>
Cc: detnet WG <detnet@ietf.org>; Janos Farkas <Janos.Farkas= @ericsson.com>; Black, David <David.Black@dell.com>
Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

 

We may have been talking about different= things, and I mistyped.

 

I identified DetNet flows that exceed ba= ndwidth must be dropped.

 

Traffic that cannot be identified as a D= etNet flow, but have a DetNet DSCP, may need to be marked down.  For e= xample, a host that is not authorized to transmit DetNet traffic sends something with the DetNet DSCP.  In a network using CQF= , you don't need to identify every packet's flow by 6-tuple; the DSCP is su= fficient to assign the packet to the right DetNet queue.  You may well= do 6-tuple flow identification at the edge, only.  So, a non-DetNet packet with a DetNet DSCP has to be remarked.=   That's the case I was talking about.

 

-- Norm

 

From:<= /span> Bal=E1zs Varga A [balazs.a.varga@ericsson.com]
Sent: Friday, January 11, 2019 1:36 AM
To: Norman Finn; Andrew G. Malis; Lou Berger
Cc: detnet WG; Janos Farkas; Black, David
Subject: RE: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

Hi Norm,

 

> 1. You may well need more than one = DSCP for DetNet region for different classes of service.

Yes, and we have defined the 6-tupple ma= tch for flow identification, what allows multiple DSCP

values.

 

> 2. You don't want to discard unexpe= cted packets with a DetNet DSCP -- you want to remark

> them to a non-DSCP code point. = ; Not good if configuring (or misconfiguring) a QoS feature

> destroys a bystander's connectivity= .

That is an interesting topic. What do Yo= u mean by “unexpected packet”? If it breaks the

traffic profile we must drop. I am not s= ure remarking is a good idea. What do You mean by

“non-DSCP code point”?

 

General, I think configuration errors ma= y destroy DetNet (and any other) flows connectivity.

We have to live with that. You can mitig= ate them e.g., by “proper maintenance procedures”,

etc. That points to the importance of De= tNet OAM being able to detect configuration (and

other) errors.

 

Cheers=

Bala’zs=

 =

From: detnet <detnet-bounces@ietf.org> On Behalf Of Norman Finn
Sent: Monday, January 7, 2019 7:20 AM
To: Andrew G. Malis <agmalis= @gmail.com>; Lou Berger <lber= ger@labn.net>
Cc: detnet WG <detnet@ietf.org= >; Janos Farkas <Jan= os.Farkas@ericsson.com>; Black, David <David.Black@dell.com>
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

 =

1. You may well need more than one DSCP = for DetNet region for different classes of service.

2. You don't want to discard unexpected = packets with a DetNet DSCP -- you want to remark them to a non-DSCP code po= int.  Not good if configuring (or misconfiguring) a QoS feature destroys a bystander's connectivity.

 

-- Norm

 

From:<= /span> detnet [detnet-bounces@ietf.org] on behalf of Andrew G. Malis [agmalis@gmail.com]
Sent: Monday, December 24, 2018 12:26 PM
To: Lou Berger
Cc: detnet WG; Black, David; J=E1nos Farkas
Subject: Re: [Detnet] IP Solution and use of DetNet-specific DSCPs (= was Re: draft-ietf-detnet-architecture-10)

Lou,

 

Thanks for following up.

 

Cheers,

Andy

 

 

On Mon, Dec 24, 2018 at 3:24 PM Lou = Berger <lberger@la= bn.net> wrote:<= /p>

Andy,=

Just following up on one point on DetNet-specific DSCPs:

On 12/19/2018 1:11 PM, Andrew G. Malis wrote:
> In that case, the DetNet flows would most probably be a using
> DetNet-specific DSCP, and if the ingress interface isn't properly
> provisioned to know how to process packets with that DSCP, they'll at =
> least be reduced to best-effort treatment.. We can also recommend that=
> packets with DetNet-specific DSCPs be dropped if they arrive at an > ingress interface that isn't otherwise provisioned to expect such pack= ets.

While I personally think use of DSCPs will be useful in supporting
aggregated DetNet flows, the IP solution draft has no requirement that
operators or vendors restrict DetNet flows to a specific DSCP value.  = --
I personally think this is an important design point.

Happy Holidays!

Lou

--_000_AM5PR0701MB229249FFB06AA5EA205C7063AC800AM5PR0701MB2292_-- From nobody Mon Jan 14 01:02:42 2019 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 7DD7A12D4E7; Mon, 14 Jan 2019 01:02:32 -0800 (PST) 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.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154745655245.4739.7035605148642143912@ietfa.amsl.com> Date: Mon, 14 Jan 2019 01:02:32 -0800 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-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, 14 Jan 2019 09:02:33 -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) Configuration YANG Model Authors : Xuesong Geng Mach(Guoyi) Chen Zhenqiang Li Reshad Rahman Filename : draft-ietf-detnet-yang-01.txt Pages : 37 Date : 2019-01-14 Abstract: This document contains the specification for Deterministic Networking flow configuration YANG Model. The model allows for provisioning of end-to-end DetNet service along the path without dependency on any signaling protocol. The YANG module defined in this document conforms 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-yang-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 Fri Jan 25 05:51:16 2019 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 0221912785F; Fri, 25 Jan 2019 05:51:15 -0800 (PST) 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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154842427494.29144.3209523421511089911@ietfa.amsl.com> Date: Fri, 25 Jan 2019 05:51:14 -0800 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-topology-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: Fri, 25 Jan 2019 13:51: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 : Deterministic Networking (DetNet) Topology YANG Model Authors : Xuesong Geng Mach(Guoyi) Chen Zhenqiang Li Reshad Rahman Filename : draft-ietf-detnet-topology-yang-00.txt Pages : 18 Date : 2019-01-14 Abstract: This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-topology-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-topology-yang-00 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-topology-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 Sat Jan 26 12:45:08 2019 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 CE8DF130FFE for ; Sat, 26 Jan 2019 12:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 iP3I84E2AwqM for ; Sat, 26 Jan 2019 12:45:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BDA130FFA for ; Sat, 26 Jan 2019 12:45:01 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 121A2548341; Sat, 26 Jan 2019 21:44:55 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EFCBC440210; Sat, 26 Jan 2019 21:44:54 +0100 (CET) Date: Sat, 26 Jan 2019 21:44:54 +0100 From: Toerless Eckert To: Bal?zs Varga A Cc: "Andrew G. Malis" , DetNet WG , "Black, David" , Janos Farkas , Lou Berger Message-ID: <20190126204454.356wkgtkfubavzid@faui48f.informatik.uni-erlangen.de> References: <31151608-0a6b-1aee-3f86-d3727b77d5d5@labn.net> <90f0d465-4ec7-3ec6-7040-b67bd7afd108@labn.net> <20190111181619.fz7dosbqbgyt55uj@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 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, 26 Jan 2019 20:45:07 -0000 Sure, but there is no useful technical explanation in the DetNet documents why those are out of scope, and even less so text to make readers understand what actually is in scope. This was the type of text i was suggesting in my first email: "The more operators are involved in the end-to-end path, the more difficult it will be to guarantee well-coordinated hop-by-hop guarantee of DetNet properties" - That would be an explanation of calling multi-operator networks to be out of scope. But what is a "private WAN" ? If i would guess then every reader would interpret this differently. I for once think that DetNet should be possible to offer by SPs as an extension of L3VPN services. But most readers likely think thats not a private WAN. So instead they would build DetNet on top of ethernet pseudowire services they buy from some ISP. Of course: ROTFL, there is no fundamental difference except that in the ethernet case, the enterprise might be lucky and find an actual TSN enabled metro-ethernet service. Whereas the enterprise wanting to use DetNet and the ISP wanting to offer it as part of L3VPN read the DetNet RFCs and wonder what it means. Aka: I can easily see that its easier to build a larger scale TSN than DetNet service if i was trying to interpret the applicability statements in DetNet. So, i continue to claim that the current text rather has the opportunity to stop DetNet in its tracks and can only serve to attempt to fend of solving any issues that might be brough up. There is not even a statement that DetNet should be supported in at least those scenarios where TSN would be feasible, if not for the need to support L3 or MPLS. Cheers Toerless On Mon, Jan 14, 2019 at 06:12:01AM +0000, Bal?zs Varga A wrote: > Hi, > Yes we can, as it was stated in the charter: > ??? > The Working Group will initially focus on solutions for networks that > are under a single administrative control or within a closed group of > administrative control; these include not only campus-wide networks but > also can include private WANs. The DetNet WG will not spend energy on > solutions for large groups of domains such as the Internet. > ??? > Cheers > Bala???zs > > From: Andrew G. Malis > Sent: Friday, January 11, 2019 10:44 PM > To: Toerless Eckert > Cc: Balázs Varga A ; DetNet WG ; Black, David ; Janos Farkas ; Lou Berger > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > Toerless, > > We could certainly truthfully say that it's not intended for the multidomain best-effort public Internet infrastructure. > > Cheers, > Andy > > > On Fri, Jan 11, 2019 at 1:16 PM Toerless Eckert > wrote: > I really don't know what the benefit of this text would be. IMHO it is > mostly IESG code language but not really helpfull IMHO. > > Something like Googles worldwide network could support DetNet if Google > wanted to ?! Its a private WAN, right ? Aka: there is no physcial scale > limitation, right ? Why don't we say that ? > > What is a "large number of domains" ? How about a nationwide research > network such as Internet 2 with hundreds of attached organizations. If > Internet2 introduced DetNet services and allowed interested Internet2 > participants to participate in it, extending DetNet services into their > couses ? How about a nationwide service provider and its customers ? > We do want DetNet service, right ? > > The only real requirement for DetNet between A and B is that all transit > domains between A and B support DetNet. This is fundamentally not > different from the requirement to make ECN work. As soon as i have a > single hop along a path not supporting ECN, my ECN based congestion > control will have to fall back to delay-variation or loss-based. And ECN is > defined to be an Internet technology. So why would DetNet not be ? > > "When we finally get to DetNet Control Plane, we don't want to bother > with all the complexity of multi-operator control plane because its > hard enough to figure out how to make one DetNet SDN controller work" > > Thats one possible honest exlanation, but given how i think we can not > precdit what type of multi-opeator environments control plane the > community will have interest to work on over time, it might be more > appropriate to say that and not to come up with an underspecified binary > distinction of what is and what is not DetNet. > > Cheers > Toerless > > On Fri, Jan 11, 2019 at 09:18:37AM +0000, Bal?zs Varga A wrote: > > Great. I am fine to add these explicit statements to make text more clear. > > > > New text is inline with the general statement in the introduction of the draft: > > " 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. " > > > > Cheers > > Bala'zs > > > > Ps: Also, note that "DetNet flows" are unidirectional ... :---)))) > > > > -----Original Message----- > > From: detnet > On Behalf Of Black, David > > Sent: Tuesday, January 8, 2019 6:46 PM > > To: Lou Berger >; Janos Farkas >; DetNet WG > > > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > > That's fine and what was intended. > > > > Thanks, --David > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Monday, January 7, 2019 4:49 PM > > > To: Black, David; János Farkas; DetNet WG > > > Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > > > > > > > [EXTERNAL EMAIL] > > > > > > David, > > > > > > This looks good/right to me. The only specific change I'd add is > > > to clarify that we're talking PEROF traffic when saying "DetNet > > > replicated traffic". > > > > > > Thanks! > > > > > > Lou > > > > > > On 1/7/2019 10:44 AM, Black, David wrote: > > > > Lou, > > > > > > > > Attempting to summarize what needs to be stated without using > > > MUST/SHOULD/MAY: > > > > > > > > [1] Sending DetNet traffic into networks that have not been > > > > provisioned in > > > advance to handle that DetNet traffic has to be treated as a fault. > > > Egress traffic filters to prevent this from happening are strongly > > > recommended at the edges of DetNet networks and DetNet supporting > > > networks. In this context, the term 'provisioned' has a broad > > > meaning, e.g., provisioning could be performed via an administrative > > > decision that the downstream network has the available capacity to carry the DetNet traffic that is being sent into it. > > > > > > > > [2] Sending non-congestion-controlled DetNet traffic (i.e., DetNet > > > > traffic that > > > does not comply with BCP 41/RFC 2914) into a network that is not > > > provisioned to handle that traffic has to be prevented in addition to being treated as a fault. > > > DetNet traffic that is not known to be congestion controlled has to be > > > treated as non-congestion-controlled DetNet traffic for this > > > requirement. DetNet replicated traffic is always > > > non-congestion-controlled even if the original DetNet flow is > > > congestion-controlled because DetNet packet elimination can hide > > > congestion indications (e.g., drops, ECN CE marks, increased latency) > > > from endpoints. The responsibility for dealing with these > > > requirements in general, and replicated traffic in particular, is > > > solution-specific, as there are MPLS mechanisms that cannot be applied to the IP solution, and moreover, the current IP solution doesn't support DetNet traffic replication. > > > > > > > > Thanks, --David > > > > > > > >> -----Original Message----- > > > >> From: Lou Berger [mailto:lberger@labn.net] > > > >> Sent: Tuesday, December 25, 2018 11:45 AM > > > >> To: Black, David; János Farkas; DetNet WG > > > >> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > >> > > > >> > > > >> [EXTERNAL EMAIL] > > > >> > > > >> Hi David, > > > >> > > > >> On 12/24/2018 8:29 PM, Black, David wrote: > > > >>> Hi Lou, > > > >>> > > > >>> Excerpting key paragraphs ... > > > >>> > > > >>>> To me clear, you are suggesting that text be added to say that > > > >>>> sending detnet traffic out a non-detnet interfaces must be treated as a fault. > > > >>>> Is this correct? > > > >>> Not exactly ... > > > >>> > > > >>>> If so, I think this is too broad considering that there are > > > >>>> networks that can provided the required detnet forwarding > > > >>>> sub-layer service that are not detnet service aware as is > > > >>>> mentioned at the end of section 4.3.2. (I'll refer to such as > > > >>>> "DetNet supporting networks" in the next paragraph.) > > > >>> I agree with where this is headed - sending DetNet traffic into a > > > >>> network that has not been provisioned to provide the required > > > >>> detnet forwarding service to that traffic has to be treated as a > > > >>> fault. In this statement, "provisioned" should be read broadly, > > > >>> e.g., it could be realized via an administrative decision that the > > > >>> DetNet supporting network has the available capacity to carry the DetNet traffic that is being sent into it. > > > >> agreed. > > > >>>> This said, I think it would be reasonable to make it a > > > >>>> requirement that DetNet nodes must not forward traffic that > > > >>>> doesn't conform with BCP41 over a network that is neither a > > > >>>> Detnet network or a DetNet supporting network. Although this > > > >>>> would require a change to the DetNet service model, i.e., to know which traffic was conformant/non-conformant. > > > >>> That's fine with one important twist: > > > >>> > > > >>> Any traffic that has been replicated by DetNet packet replication > > > >>> has to be treated as not conforming with BCP41 because DetNet > > > >>> packet elimination (of replicated packets) may hide congestion > > > >>> indications (e.g., delay, ECN CE marks, drops) from the endpoints > > > >>> - a scenario of particular concern involves the other flow of > > > >>> replicated packets following a DetNet network path along which nothing goes wrong. > > > >>> BCP41 is about end-to-end-congestion control, which does not do > > > >>> anything if DetNet packet elimination hides congestion indications > > > >>> from the endpoints. > > > >> This seems reasonable to me. > > > >> > > > >> > > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > > >>>>> traffic that would otherwise escape is needed, and the statement > > > >>>>> of that requirement ought to be connected to the explanation of > > > >>>>> how to implement that requirement. > > > >>>> I think adding a statement on output filters (and policers) to > > > >>>> this section is reasonable. > > > >>> Let's start with the inclusion of output filters (and policers) in > > > >>> the 3.3.2 text with the use of upper-case "SHOULD" as suggested by > > > >>> Pascal - I will look this over and suggest any additional text > > > >>> that I think ought to be included. > > > >> As an architecture document, the authors/WG made the call to not > > > >> use conformance capitalization or reference 2119/8174. I think > > > >> this translates to the conformance language needing to be added to > > > >> the data plane solution documents. > > > >> > > > >> Cheers, > > > >> > > > >> Lou > > > >> > > > >> > > > >>> Thanks, --David > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Lou Berger [mailto:lberger@labn.net] > > > >>>> Sent: Monday, December 24, 2018 3:18 PM > > > >>>> To: Black, David; János Farkas; DetNet WG > > > >>>> Subject: Re: [Detnet] draft-ietf-detnet-architecture-10 > > > >>>> > > > >>>> > > > >>>> [EXTERNAL EMAIL] > > > >>>> > > > >>>> Hi David, > > > >>>> > > > >>>> On 12/19/2018 12:37 PM, Black, David wrote: > > > >>>>> Janos, > > > >>>>> > > > >>>>> The terminology is definitely improved - the resulting draft is > > > >>>>> much clearer - many thanks to you and the authors for doing that. > > > >>>> Happy to hear that. > > > >>>> > > > >>>> > > > >>>>> Where do we stand on the concern about protecting external > > > >>>>> non-DetNet networks from DetNet flows that escape a DetNet > > > >>>>> network, e.g., due to an erroneous network configuration change? > > > >>>> I'm not sure we have general solutions in the internet > > > >>>> architecture for miss-configured/buggy systems other than > > > >>>> dropping the packets on the floor (e.g., due to no route, no > > > >>>> label, or ttl expiry). What type of protection are you looking > > > >>>> for here, and can you provide a reference to the type of router > > > >>>> behavior you would like to see? I have a suggestion that might > > > >>>> address your concern below elated to non-BCP41 conformant traffic, but am unsure if this is what you are concerned about. > > > >>>> > > > >>>>> My current views are ... > > > >>>>> > > > >>>>> There's no throttling in DetNet, e.g., this text in 4.3.2: > > > >>>>> > > > >>>>> There is no provision in DetNet for throttling DetNet flows, i.e., > > > >>>>> the transmission rate cannot be reduced via explicit congestion > > > >>>>> notification [RFC3168]. The assumption is that a DetNet flow, to be > > > >>>>> useful, must be delivered in its entirety. > > > >>>> Well looking at it this way, there is no throttling in any IP > > > >>>> network as the routers generate the CN and only drop when their > > > >>>> queues are full or implementing some sort of RED. > > > >>>> > > > >>>> In DetNet there is an expectation that intermediate nodes do more > > > >>>> than this. Specifically, see section 4.5: "Queuing, Shaping, > > > >>>> Scheduling, and Preemption" and policing, which is mentioned as > > > >>>> requirement in section 3.3.1. > > > >>>> > > > >>>>> and no assurance that all DetNet-using applications will cease > > > >>>>> and desist in the face of packet drops that indicate congestion. > > > >>>> I think this is correct. > > > >>>> > > > >>>> > > > >>>>> Packet Replication and Elimination makes this worse via its > > > >>>>> ability to > > > hide > > > >>>>> network packet drops and congestion indications from endpoints, > > > >>>>> e.g., of those drops and/or congestion indications occur on only > > > >>>>> one of the paths used by replicated packets. > > > >>>>> > > > >>>>> The first paragraph in section 3.3.2 is a good start, but I > > > >>>>> think its lower case "should" is too weak: > > > >>>>> > > > >>>>> 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 a volume. Furthermore, filters and > > > >>>>> policers can take actions to discard the offending packets or flows, > > > >>>>> or trigger shutting down the offending flow or the offending > > > >>>>> interface. > > > >>>>> > > > >>>>> At a minimum, I think that the requirement to discard DetNet > > > >>>>> traffic that would otherwise escape a DetNet network has to be > > > >>>>> stated as a "MUST" requirement for any DetNet network that > > > >>>>> supports Packet Replication and Elimination due to the ability > > > >>>>> of that functionality to hide congestion from endpoints, making > > > >>>>> it impossible for higher layers of the protocol stack to respond. > > > >>>> To me clear, your are suggesting that text be added to say that > > > >>>> sending detnet traffic out a non-detnet interfaces must be treated as a fault. > > > >>>> Is this correct? If so, I think this is too broad considering > > > >>>> that there are networks that can provided the required detnet > > > >>>> forwarding sub-layer service that are not detnet service aware as > > > >>>> is mentioned at the end of section 4.3.2. (I'll refer to such as > > > >>>> "DetNet supporting networks" in the next paragraph.) > > > >>>> > > > >>>> This said, I think it would be reasonable to make it a > > > >>>> requirement that DetNet nodes must not forward traffic that > > > >>>> doesn't conform with BCP41 over a network that is neither a > > > >>>> Detnet network or a DetNet supporting network. Although this > > > >>>> would require a change to the DetNet service model, i.e., to know which traffic was conformant/non-conformant. > > > >>>> > > > >>>> > > > >>>>> Beyond this, I think a "SHOULD" requirement to discard DetNet > > > >>>>> traffic that would otherwise escape is needed, and the statement > > > >>>>> of that requirement ought to be connected to the explanation of > > > >>>>> how to implement that requirement. > > > >>>> I think adding a statement on output filters (and policiers) to > > > >>>> this section is reasonable. > > > >>>> > > > >>>> > > > >>>>> The text in Section 3.3.2 has a lot of the content needed - for > > > >>>>> a worked example of such "SHOULD" text, see Section 5 of RFC > > > >>>>> 7510, in particular the itemized list at the end of that section > > > >>>>> and the paragraph that introduces that list: > > > >>>>> https://tools.ietf.org/html/rfc7510#section-5 > > > >>>> If I'm not mistaken, such mechanisms are already included in the > > > >>>> document and you really are just asking them to be (re)listed to > > > >>>> ensure that this import point isn't missed. Is this correct? > > > >>>> Besides what is mentioned above, is there anything else missing? > > > >>>> > > > >>>> Thanks! > > > >>>> > > > >>>> Lou > > > >>>> > > > >>>>> Thanks, --David > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of > > > >>>>>> János > > > Farkas > > > >>>>>> Sent: Wednesday, December 19, 2018 10:54 AM > > > >>>>>> To: DetNet WG > > > >>>>>> Subject: [Detnet] draft-ietf-detnet-architecture-10 > > > >>>>>> > > > >>>>>> > > > >>>>>> [EXTERNAL EMAIL] > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> The DetNet architecture document has been updated to address > > > >>>>>> the comments. The new revision (v10) is available at > > > >>>>>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-10. > > > >>>>>> > > > >>>>>> There have been a number of discussion items emails on the > > > >>>>>> list. The updates are along the major discussion items, which > > > >>>>>> also cover the derivative discussions, address the comments. > > > >>>>>> > > > >>>>>> The major items have been summarized in: > > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01968.html. > > > >>>>>> Follow up discussions implied terminology changes summarized in: > > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02036.html: > > > >>>>>> replace "transport sub-layer" with "forwarding sub-layer" > > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg02038.html: > > > >>>>>> replace "congestion protection" with "resource" allocation" > > > >>>>>> Consequently, the document had a good 'scurb". > > > >>>>>> > > > >>>>>> In addition, outstanding comments have been addressed along > > > >>>>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01943.html. > > > >>>>>> > > > >>>>>> Please let us know if any comment happened to be remained open. > > > >>>>>> > > > >>>>>> Best 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 > > -- > --- > tte@cs.fau.de > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet -- --- tte@cs.fau.de