From nobody Fri Mar 1 13:18:49 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 704D1130FCA; Fri, 1 Mar 2019 13:10:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: detnet@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461645.6101.8494201970708629582.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:16 -0800 Archived-At: Subject: [Detnet] detnet - Requested session has been scheduled 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: Fri, 01 Mar 2019 21:10:33 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. detnet Session 1 (2:00 requested) Wednesday, 27 March 2019, Morning Session I 0900-1100 Room Name: Congress Hall 1 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/detnet.ics Request Information: --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: pce teas netmod mpls Second Priority: ccamp tsvwg lsr bess pals rtgwg 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 Sat Mar 2 10:22: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 419FF130DEF for ; Sat, 2 Mar 2019 10:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu2ZHeMStCfm for ; Sat, 2 Mar 2019 10:22:22 -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 9D3CF130E66 for ; Sat, 2 Mar 2019 10:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551550936; x=1554142936; 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=PAtK46KRVQmjAH6c7lGEXNPhmfXtQF8QVZZZsxnarIM=; b=VfY/G9RmCEVlt3sodD/WUw5U2GN4fqfoaYTWWXkGlxJP/f7pyenho+xDWDWFkJA2 vHGllBq8fRu4unz1/LUOqqvdVuaULTBywZJLj5/chxI8mUzw9uK14mymZZYxKGEG 4UuA7XOa+bvIejsULWeCi/EPt8ssULTK5OsubJzGcBk=; X-AuditID: c1b4fb2d-db5ff7000000062f-49-5c7ac9d837c8 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.B8.01583.8D9CA7C5; Sat, 2 Mar 2019 19:22:16 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) 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; Sat, 2 Mar 2019 19:22:15 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 19:22:14 +0100 To: Benjamin Kaduk CC: Lou Berger , , , The IESG , References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Sat, 2 Mar 2019 19:22:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7me6Nk1UxBj9mS1hc6//BYvH702wW iw/fZrJYzPgzkdli+caZTBYdzW9ZHNg8liz5yeTxYVMzm0fTmaPMAcxRXDYpqTmZZalF+nYJ XBl/N2YXTI6qOLlvI0sD4y7PLkZODgkBE4lL3XMZQWwhgSOMEnu+53QxcgHZXxklls/sZYJw DjNK3D3wgw2kSligUOLCwqlgHSICShKLz7awgRQxC0xllHjQfZ8VomMrk8S2jl/MIFVsAvYS dy9tALN5gexL+86xg9gsAioSaxedZQWxRQViJT5dWQxVIyhxcuYTFhCbU8BG4k/7SrB6ZgEL iZnzzzNC2PISzVtnM0PY4hK3nsxngvhBTeLT24fsExiFZiEZNQtJ+ywk7bOQtC9gZFnFKFqc Wlycm25krJdalJlcXJyfp5eXWrKJERgVB7f81t3BuPq14yFGAQ5GJR7evl1VMUKsiWXFlbmH GCU4mJVEeCfsBwrxpiRWVqUW5ccXleakFh9ilOZgURLn/SMkGCMkkJ5YkpqdmlqQWgSTZeLg lGpg9Nm5XE7m3aOzH4SWyMyXusQVvudrquGy+/OURSZIMipVTX9iNDnmwy3dvr1ivPW/go49 e7Ch8LfGu0XvfnEeT5wte2sW87a4fM6dW36f1qydXZ/QOvNZ8r7weesivkdbRiit3fe1Ysm6 B3ozVBawP/Izt2M896bvhoqbocwT8yuqL/nDhHTn71ViKc5INNRiLipOBADv3BMfhgIAAA== Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 18:22:24 -0000 Hi Benjamin, Thank you for your review! Focusing on the main point now: Section 5 Security Considerations. We could consolidate the section to address your comment. Would it be helpful to replace the section with the following text?: Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. This section considers exclusively security considerations which are specific to the DetNet Architecture. Security aspects which are unique to DetNet are those whose aim is to secure the specific quality of service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. A DetNet is implemented using MPLS and IP (including both v4 and v6) technologies, and thus inherits the security properties of those technologies at both the control plane and the data plane. Security considerations for DetNet are constrained (compared to, for example, the open Internet) because DetNet is defined to operate only within a single administrative domain (see Section 1).  The primary considerations are to secure the request and control of DetNet resources, maintain confidentiality of data traversing the DetNet, and provide uninterrupted availability of the DetNet quality of service. To secure the request and control of DetNet resources, authentication and authorization must be provided for each device connected to a DetNet domain, most importantly to network controller devices. Control of a DetNet network may be centralized or distributed (within a single administrative domain). In the case of centralized control, precedent for security considerations as defined for ACTN can be found in RFC8453, Section 9. In the case of a distributed control protocols, DetNet security is expected to be provided by the security properties of the protocols in use. In any case, the result must be that manipulation of administratively configurable parameters is limited to authorized entities. To maintain confidentiality of data traversing the DetNet, application flows must be protected through whatever means is provided by the underlying technology. For example, encryption may be used, such as that provided by IPSec for IP (Layer 3) flows and by MACSec for Ethernet (Layer 2) flows. DetNet flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows (when compared to networks that do not include per-flow identification); this is an inherent property of DetNet which has security implications which must be considered when determining if DetNet is a suitable technology for any given use case. Similar consideration may need to be given to the use of replicated packet flows, which result in increased surface for Reconnaissance attacks. In any case, the result must be that the confidentiality of the data is maintained to a degree sufficient for the use cases addressed by the given DetNet implementation. To provide uninterrupted availability of the DetNet quality of service, provisions must be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices must be prevented or mitigated, for example through the use of traffic admission control applied at the input of a DetNet domain, as described in Section 3.2.1.1, and through the fault mitigation methods described in Section 3.3.2. To prevent DetNet packets from being delayed, protection must be provided against Man-In-The-Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. Time synchronization methods are not specified by DetNet, however any time synchronization method used with DetNet must also be secured, using the security methods available for the given time synchronization mechanism, for example as described in [RFC7384]. In any case, the result must be that the DetNet is protected from DOS, delay, and time manipulation attacks to the extent sufficient for the use cases addressed by the given DetNet implementation. DetNet use cases are known to have widely divergent security requirements. The intent of this section is to provide a baseline for security considerations which are common to all DetNet designs and implementations, without burdening individual designs with specifics of security infrastructure which may not be germane to the given use case. Designers and Implementers of DetNet systems are expected to take use case specific considerations into account in their DetNet designs and implementations. Regards, Janos On 2/21/2019 9:32 PM, Lou Berger wrote: > Hi Benjamin, > > On 2/20/2019 4:21 PM, Benjamin Kaduk wrote: >> Hi Lou, >> >> On Wed, Feb 20, 2019 at 11:34:11AM -0500, Lou Berger wrote: >>> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote: >>>> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote: >>>>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote: >>>>>> I note that the DETNET WG is explicitly chartered with a work >>>>>> item for the >>>>>> "overall architecture: This work encompasses ... and security >>>>>> aspects". >>>>>> It seems incomplete to specify an architecture for a topic such as >>>>>> deterministic networking without specifically considering what >>>>>> threats are >>>>>> and are not in scope to be protected against. >>>>> The working group certainly recognizes that security is an important >>>>> topic and necessary part of the work. The WG's  approach to ensure >>>>> that >>>>> this significant topic is sufficiently covered is to have a  document >>>>> dedicated to the topic.  As you note below this work, >>>>> draft-ietf-detnet-security, is not at the same level maturity - so >>>>> please stay tuned.  Of course, the WG would welcome any input on this >>>>> security draft now or even a full early-review or security area >>>>> advisor. >>>> I do appreciate that the WG has taken the time to work on a dedicated >>>> security document, that goes through the (tedious!) effort to >>>> tabulate the >>>> various known attacker capabilities, threats, and their interactions. >>>> >>>> What I think is missing from the high-level architecture document is a >>>> sense for what security goals the architecture intends to achieve.  >>>> It's >>>> fine to have this be separate from the nitty-gritty stuff in the >>>> separate >>>> document, but these high-level questions can have an impact on the >>>> high-level design of the protocol ecosystem as a whole.  We have >>>> mounds of >>>> examples of "come up with a design; bolt security on as an >>>> afterthought" >>>> working poorly or being nigh-impossible, and I haven't seen any >>>> attempt at >>>> justification for why doing so here is likely to be any different. >>>> Including the security concepts from the start and wholly >>>> integrating them >>>> into the system tends to produce a much more elegant design and >>>> smoother >>>> outcomes all around. >>> We went back and forth on how much of the security topic to include in >>> the architecture document and settled on the current text of section 5 >>> where just high level security requirements are identified. From your >>> list below, the architecture covers the points you raise (non-detnet >>> traffic impacting detnet traffic, and detnet traffic trying to use more >>> than its allocation) mainly from a service delivery perspective.  It >>> does mention "shaping" as a security concern, the document could expand >>> these if helpful. But I think the real discussion point is how much of >>> the security details should be in the base (vs dedicated) document  -- >>> and that you disagree with where the WG has drawn the line. Is this >>> correct? >> Well, it's not as much that I disagree about where the line is drawn, as >> that I disagree with the characterization as "high level security >> requirements". >> >> The first paragraph covers topics worth including here, certainly -- an >> attacker that can introduce delay can inherently break the DetNet >> guarantees, and there is no further defense.  But the text could >> probably >> go further than its current version and explicitly call out that no >> technical measures can defend against such delay, other than by >> rerouting/avoiding the compromised position. >> >> The second paragraph also covers a topic worth noting, that entropy and >> Murphy as as important of risks to consider as active attacks. >> >> The rest of the section/list don't seem to match up with the high-level >> view, though -- "protection of the signaling protocol", but protection >> against what?  Authentication and authorization are important parts of >> security, but authorization is tied to actions and entities, not just >> entities in vacuo.  For "identification and shaping of DetNet flows", if >> security must cover them, what security properties are needed. Do we >> need >> to provide integrity protection for the marking, or confidentiality >> protection, too?  Does authentication/integrity need to be provided for >> in-line or are out-of-band considerations in play? >> >> The rest of the document presents a good high level picture of what >> pieces >> will be involved in a system, and how they fit together.  I'm hoping >> to see >> a high-level picture of what attacks/failures the architecture does and >> does not aim to protect against.  It's somewhat implied that we need to >> protect against the failure of any single node or link (except at the >> boundary) due to random faults; explicitly saying this would be a >> perfect >> hting to include in the security considerations here!  Once we get >> beyond >> entropy as an attack, into more active attack scenarios, though, we >> need to >> consider what capabilities an attacker might have.  Do we protect >> against >> an entity with the ability to inject various forms of traffic? Modify or >> drop valid traffic?  Are there any (classes of) credentials that we >> assume >> must be securely held, or will we attempt to protect against >> attackers that >> have some privilege within the system?  (Note that misbehaving >> hardware can >> sometimes present as similar or identical to such an attacker.) >> >> Does this give a better picture of what I'm thinking of as "high-level >> security requirements"?  I don't necessarily need details of specific >> hardware or credentials at play, and certainly not for the solutions, >> but I >> want to have a clear picture of what the scope of future security >> analysis >> will be.  "How will I be able to tell if the actual protocols meet the >> security requirements of the architecture?" > > I'll get with authors (of both the architecture and security docs) and > see how much they think can be reasonably be added to this document -- > to be clear you *are* asking for a change in how the WG decide to > address this topic and what would go in which document. > > Lou > >> -Benjamin >> >> _______________________________________________ >> 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 Sat Mar 2 11:06:28 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 DC235130DEF for ; Sat, 2 Mar 2019 11:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE-OoB8hrYTo for ; Sat, 2 Mar 2019 11:06:23 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E280127287 for ; Sat, 2 Mar 2019 11:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551553580; x=1554145580; 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=l2HPgQ2hlLe2rD6Q+1OfjxxQlZvN9qspKadeRDGPxIE=; b=DGNdlQ37RJMfkRqhoxY3XvHcw6s81BpildFQoqtGCvDG0OXm5RgZqEau38L55tzw ZU/MdBlNV7i7ntLti9WZtmULTcMFyYhN8od6yALalygXLacSfjA/TTH3tcY89mSF T4SMUe0BhJETS9uQEX3wNXMi8+ax+0Ts1SJKSIuiPEg=; X-AuditID: c1b4fb3a-5c9c29e00000672c-ea-5c7ad42c0cb8 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.B5.26412.C24DA7C5; Sat, 2 Mar 2019 20:06:20 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) 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; Sat, 2 Mar 2019 20:06:19 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 20:06:19 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.192) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 20:06:18 +0100 To: Ben Campbell CC: The IESG , , "Lou Berger" , , References: <155068628183.31466.17047287566875848268.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <468c8746-7506-899f-e901-cb0d6c1c7b42@ericsson.com> Date: Sat, 2 Mar 2019 20:06:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <155068628183.31466.17047287566875848268.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2J7ua7OlaoYg80NUhbzO0+zW1zr/8Fi 8fvTbBaLD99msljM+DOR2aKj+S2LA5vHkiU/mTw+bGpm85i18wlLAHMUl01Kak5mWWqRvl0C V8ak9qtsBUulKlZOecnWwLhVtIuRk0NCwERi36adzF2MXBxCAkcYJfbveskCkhAS+Moo8fhp Epz99EYMRNFhoPiCF8wgCWGBeInX846zgtgiAkoSz5u3soAUMQtMZ5ToPDybDaLbT2LVuQPs IDabgL3E3UsbwJp5gexbz9aCNbMIqEj0H5nNCGKLCsRKfLqyGKpGUOLkzCdgF3EK+EvcefcZ LM4sYCExc/55RghbXqJ562youLjErSfzmSD2qkm8b7jDOIFReBaSUbOQtM9C0j4LSfsCRpZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHRcnDLb6sdjAefOx5iFOBgVOLhvbinKkaINbGs uDL3EKMEB7OSCO+E/UAh3pTEyqrUovz4otKc1OJDjNIcLErivH+EBGOEBNITS1KzU1MLUotg skwcnFINjPEK15mOpL3OfT5l+jKZIz689xXcjlUyHQzk85J68fm8U7RGhsb2b+6hpZuZJnSX v3x3e1nN/OOrms5PSVpq+Kam4297bXup8+Tp8i7vzb4qbJrTfUVWlbcp9Mqx2Z/mz23huKuy 6PIf/d5YPn0HGa9lX6eeEEqaefuq3HrOurMOKyZejZvGdVmJpTgj0VCLuag4EQCW8iORkgIA AA== Archived-At: Subject: Re: [Detnet] Ben Campbell's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 19:06:26 -0000 Hi Ben, Thank you for your review! Please see in-line: On 2/20/2019 7:11 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-detnet-architecture-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Benjamin's and Alissa's DISCUSS positions. I also agree with the > several people who commented that this should be informational. Otherwise, I > have some minor comments: > > §3.2.1.2, > - first paragraph: Please expand "GigE" Replace "GigE" with "Gigabit Ethernet". > > - "In general, users are encouraged to use, instead of, "do this when you > get the packet," a combination of:" - Hard to parse. Simplify the sentence to: "In general, users are encouraged to use a combination of:" > > §3.2.2.2: Please expand "PREOF" on first use. I realize readers can probably > construct it from the previous few sentences, but it's more reader-friendly not > to require them to do so. Replace "PREOF" with "Packet Replication, Elimination, and Ordering Functions (PREOF)" > > §3.3.2: "Robust real-time systems require to reduce the number of possible > failures." - The sentence does not parse. Are there missing words prior to > "to"? Replace with: "Robust real-time systems require reducing the number of possible failures." > > §4.1.2: > > - "Distinguishing the function of two DetNet data plane sub-layers, the > DetNet service sub-layer and the DetNet forwarding sub-layer, helps > to explore and evaluate various combinations of the data plane > solutions available, some are illustrated in Figure 4." > > Hard to parse. Also, there is a comma splice. Replace with: "DetNet data plane is divided into two sub-layers: the DetNet service sub-layer and the DetNet forwarding sub-layer. This helps to explore and evaluate various combinations of the data plane solutions available. Some of them are illustrated in Figure 4." > > - "There are many valid options to create a data plane solution for > DetNet traffic by selecting a technology approach for the DetNet > service sub-layer and also selecting a technology approach for the > DetNet forwarding sub-layer. There are a high number of valid > combinations." > > Does this refer to implementation/deployment options, or protocol design > options? If the latter, are the choices still open? They are deployment options. > > §4.1.3: Please define or expand DetNet-UNI. Replace "DetNet-UNIs ("U" in ..." with: "DetNet User Network Interfaces (DetNet-UNIs) ("U" in ..." > > §4.2.1, first paragraph: Does L1 stand for Layer-1, etc? If so, please spell it > out. Replace "L1 or L2 or L3" with "Layer-1 or Layer-2 or Layer-3" Thank you, Janos From nobody Sat Mar 2 11:43: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 9942E124C04; Sat, 2 Mar 2019 11:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 2cGbewbIGsdA; Sat, 2 Mar 2019 11:43:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950A912008A; Sat, 2 Mar 2019 11:43:29 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x22JhLqk038382 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 2 Mar 2019 13:43:22 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551555803; bh=thdaMBZ4qnpjn1WM3JH0TJGIvToIYpqBxftGrsMwAV4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=KkGoAb92lSAYxCnf6raVcM4qGRU9yb5thPArQS8d2//5+/ke5BFJjPeqCMOuoL4C1 yjck23AHaVeCRq/YvqFxZpNz2rhMfU4ZCsxv13FsIt1SP5qXwFP8d3UBdC0QS7xEI1 ibGGa/7Q/+uK2EwEqiI+iKJRB7LtRr2ufxoqX5U8= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_002849A8-3104-4209-91C2-50946B050AB0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 2 Mar 2019 13:43:20 -0600 In-Reply-To: <468c8746-7506-899f-e901-cb0d6c1c7b42@ericsson.com> Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, Lou Berger , The IESG , detnet-chairs@ietf.org To: =?utf-8?Q?J=C3=A1nos_Farkas?= References: <155068628183.31466.17047287566875848268.idtracker@ietfa.amsl.com> <468c8746-7506-899f-e901-cb0d6c1c7b42@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Detnet] Ben Campbell's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 19:43:33 -0000 --Apple-Mail=_002849A8-3104-4209-91C2-50946B050AB0 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7A864C4-20A1-4DEB-BBA5-9550E51AFFAE" --Apple-Mail=_B7A864C4-20A1-4DEB-BBA5-9550E51AFFAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That all looks good, thanks! Ben. > On Mar 2, 2019, at 1:06 PM, J=C3=A1nos Farkas = wrote: >=20 > Hi Ben, >=20 > Thank you for your review! >=20 > Please see in-line: >=20 > On 2/20/2019 7:11 PM, Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> draft-ietf-detnet-architecture-11: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I support Benjamin's and Alissa's DISCUSS positions. I also agree = with the >> several people who commented that this should be informational. = Otherwise, I >> have some minor comments: >>=20 >> =C2=A73.2.1.2, >> - first paragraph: Please expand "GigE" > Replace "GigE" with "Gigabit Ethernet". >=20 >=20 >>=20 >> - "In general, users are encouraged to use, instead of, "do this when = you >> get the packet," a combination of:" - Hard to parse. > Simplify the sentence to: "In general, users are encouraged to use a = combination of:" >=20 >=20 >>=20 >> =C2=A73.2.2.2: Please expand "PREOF" on first use. I realize readers = can probably >> construct it from the previous few sentences, but it's more = reader-friendly not >> to require them to do so. > Replace "PREOF" with "Packet Replication, Elimination, and Ordering = Functions (PREOF)" >=20 >=20 >>=20 >> =C2=A73.3.2: "Robust real-time systems require to reduce the number = of possible >> failures." - The sentence does not parse. Are there missing words = prior to >> "to"? > Replace with: > "Robust real-time systems require reducing the number of possible = failures." >=20 >>=20 >> =C2=A74.1.2: >>=20 >> - "Distinguishing the function of two DetNet data plane sub-layers, = the >> DetNet service sub-layer and the DetNet forwarding sub-layer, helps >> to explore and evaluate various combinations of the data plane >> solutions available, some are illustrated in Figure 4." >>=20 >> Hard to parse. Also, there is a comma splice. > Replace with: > "DetNet data plane is divided into two sub-layers: the > DetNet service sub-layer and the DetNet forwarding sub-layer. > This helps to explore and evaluate various combinations of the data = plane > solutions available. Some of them are illustrated in Figure 4." >=20 >>=20 >> - "There are many valid options to create a data plane solution for >> DetNet traffic by selecting a technology approach for the DetNet >> service sub-layer and also selecting a technology approach for the >> DetNet forwarding sub-layer. There are a high number of valid >> combinations." >>=20 >> Does this refer to implementation/deployment options, or protocol = design >> options? If the latter, are the choices still open? > They are deployment options. >=20 >>=20 >> =C2=A74.1.3: Please define or expand DetNet-UNI. > Replace "DetNet-UNIs ("U" in ..." > with: "DetNet User Network Interfaces (DetNet-UNIs) ("U" in ..." >=20 >>=20 >> =C2=A74.2.1, first paragraph: Does L1 stand for Layer-1, etc? If so, = please spell it >> out. > Replace "L1 or L2 or L3" with "Layer-1 or Layer-2 or Layer-3" >=20 >=20 > Thank you, > Janos --Apple-Mail=_B7A864C4-20A1-4DEB-BBA5-9550E51AFFAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = all looks good, thanks!

Ben.

On Mar 2, 2019, at 1:06 PM, = J=C3=A1nos Farkas <janos.farkas@ericsson.com> wrote:

Hi Ben,

Thank you for your = review!

Please see = in-line:

On 2/20/2019 = 7:11 PM, Ben Campbell wrote:
Ben Campbell has entered the = following ballot position for
draft-ietf-detnet-architecture-11: No Objection

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


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


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



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I support Benjamin's and Alissa's = DISCUSS positions. I also agree with the
several people = who commented that this should be informational. Otherwise, I
have some minor comments:

=C2=A73.2.1.2,
- first paragraph: Please expand = "GigE"
Replace "GigE" with "Gigabit Ethernet".



- "In general, users are encouraged to use, instead of, "do = this when you
get the packet," a combination of:" - Hard = to parse.
Simplify the sentence to: "In general, users are encouraged = to use a combination of:"



=C2=A73.2.2.2: Please = expand "PREOF" on first use. I realize readers can probably
construct it from the previous few sentences, but it's more = reader-friendly not
to require them to do so.
Replace "PREOF" with "Packet Replication, Elimination, and = Ordering Functions (PREOF)"



=C2=A73.3.2: "Robust = real-time systems require to reduce the number of possible
failures." - The sentence does not parse.  Are there = missing words prior to
"to"?
Replace with:
"Robust real-time systems require reducing the number of = possible failures."


=C2=A74.1.2:

- "Distinguishing the function of two DetNet = data plane sub-layers, the
DetNet service sub-layer and = the DetNet forwarding sub-layer, helps
to explore and = evaluate various combinations of the data plane
solutions = available, some are illustrated in Figure 4."

Hard to parse. Also, there is a comma splice.
Replace with:
"DetNet data plane is divided into two sub-layers: = the
DetNet = service sub-layer and the DetNet forwarding sub-layer.
This helps to explore and = evaluate various combinations of the data plane
solutions available. Some of = them are illustrated in Figure 4."


- "There are many = valid options to create a data plane solution for
DetNet = traffic by selecting a technology approach for the DetNet
service sub-layer and also selecting a technology approach = for the
DetNet forwarding sub-layer. There are a high = number of valid
combinations."

Does this refer to implementation/deployment options, or = protocol design
options? If the latter, are the choices = still open?
They are deployment options.


=C2=A74.1.3: Please = define or expand DetNet-UNI.
Replace "DetNet-UNIs ("U" in = ..."
with: "DetNet = User Network Interfaces (DetNet-UNIs) ("U" in ..."


=C2=A74.2.1, first paragraph: Does L1 stand for Layer-1, etc? = If so, please spell it
out.
Replace "L1 or L2 or L3" with = "Layer-1 or Layer-2 or Layer-3"


Thank you,
Janos

= --Apple-Mail=_B7A864C4-20A1-4DEB-BBA5-9550E51AFFAE-- --Apple-Mail=_002849A8-3104-4209-91C2-50946B050AB0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx63NgACgkQgFZKbJXz 1A1ziBAAszV99o10PgE4YeWl3EJqXkVgzXjyOTqlSki6eo099IqfnbS0/KUxiYWf 48AijAELEhI1aPP5WiQWYXCIOAh89uiqYfc0exsVkvXMs2WlmB2Sba1uU+W9rKV+ 999ywMoS4g1BpSj9fx0kAeMKGQLCNEUOsObh+KUID2HzuOwq/mybrnLo3xw85HfY G9UV8wqx5bHiPMqZJXsPbY0QHuJrlsUxsom3qxVUNtCtU5jw/gU5icdRY2VUzovV L4meQEXHoGfNB4ng1h+iQAJzM4G24CqffHoKGHR2idpU2ma7tVv3dUq3yXTOa4R9 Uo0IhPcnoOl1zuX/66foJYFpmNT905dMaip0emLa/RUdzOpwJ6ErvnPUMTnJgUf1 K8DUrVOfcrTbZdnYhi1HryDZZ5nGh5OouHJ/SmZiZjcVw1ENvTyWuhvI7FXhFfFq doLEeWVgqGq3W8+2z2p8bhunbtAvMR34EHxb7Wu3cwajKT81hsM++VPMsW90KLPt 79vZEEmHObAayhdv9u0ni+Ogx6eq0V6nqbvJJbTqzd37XZXD7bcWSAzOZIizHnXu 2tKX1EVS4INY1ZExOinnObxwJFMaM2WFFDEB+1v54gCBkRaHO7U/Z2WEwK486+bk DAAkofxcJs5RYOZQBFtIUsyDEfe5glAVLkc7r2UGcyrvuRuOWnw= =xf7t -----END PGP SIGNATURE----- --Apple-Mail=_002849A8-3104-4209-91C2-50946B050AB0-- From nobody Sat Mar 2 12:12:40 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 7B743130E13 for ; Sat, 2 Mar 2019 12:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbsSwQM_5z6g for ; Sat, 2 Mar 2019 12:12:31 -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 F36C3130E27 for ; Sat, 2 Mar 2019 12:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551557544; x=1554149544; 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=h0+XPxh9/vl7RitIsfFGNcFde1MfjfeEvfXhCaTdaJg=; b=XrAet8+yAEdONm9DAB7BhoHYPaIZDsHu7QzznT5tmnQQUfOpuTD7WziIGYY/YmPN rAuUPE/DY/g64J2HUxCXxt0IsCO9aKjMPyG53Xa3uKF35l7nQISMM1Gc0CdAb0Sm q6hSoYxZGQ3bnmMfgJ8epQoRGuMZA/dppby2ysX6ybo=; X-AuditID: c1b4fb25-d89ff70000005ff7-6b-5c7ae3a8f7c4 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.C9.24567.8A3EA7C5; Sat, 2 Mar 2019 21:12:24 +0100 (CET) Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 21:12:24 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 21:12:24 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.192) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 21:12:23 +0100 References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Benjamin Kaduk CC: The IESG , , "Lou Berger" , , DetNet WG Message-ID: <1cd55c7d-6d1c-b56f-38d3-d6bd78b004e2@ericsson.com> Date: Sat, 2 Mar 2019 21:12:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7le6Kx1UxBvPmaFhc6//BYvH702wW iw/fZrJYzPgzkdli+caZTBYdzW9ZHNg8liz5yeTxYVMzm0fTmaPMAcxRXDYpqTmZZalF+nYJ XBlHjt5kLLgZW3Fs/Vn2Bsbz7l2MnBwSAiYS7Uv2s3QxcnEICRxhlLjb8pgdJCEk8JVRYvFE OTi7Y74ThH2YUeLOkZQuRg4OYYEMiVPTyyHCvhLnm56wgthsAvYSdy9tYAaxRQSUJBafbWED mc8ssJhR4sPbk2wgCV6goucHe8EaWARUJA6cesgCYosKxEp8urKYGaJGUOLkzCdgcU4BP4kj vw8zgtjMAhYSM+efh7LlJZq3zmaGsMUlbj2ZzwRxkJrE+4Y7jBMYhWchGTULSfssJO2zkLQv YGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYKQe3/FbdwXj5jeMhRgEORiUe3j/XqmKE WBPLiitzDzFKcDArifCWPgAK8aYkVlalFuXHF5XmpBYfYpTmYFES5/0jJBgjJJCeWJKanZpa kFoEk2Xi4JRqYOR+mcxcvExifwSX1IFf07MYAwXuzOBb/4Xn5hb/usSVivkx/WkvQ1apNDnM PLf8vLj8u7iwuklGJ3W6pxrWh1yem8boKWbXtXrh/7tCDNPOqG/4McddPeI7x9lbhx99mid9 tUSJtT3/UJL96cJVslESrV5SFvfXCImLKX+7XbMoq7RPYlFNvRJLcUaioRZzUXEiANaTF9eQ AgAA Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 20:12:34 -0000 Hi Benjamin, Coming to your detailed comments. Please see in-line. Thank you, Janos On 2/20/2019 4:44 AM, Benjamin Kaduk wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > Abstract > > DetNet operates at the IP layer and > delivers service over sub-network technologies such as MPLS and IEEE > 802.1 Time-Sensitive Networking (TSN). > > I don't know what "sub-network technologies" means. (Should I? Is it > defined somewhere we can reference?) > > More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network" > that lies between specific layers or classes of layer? Does DetNet > itself have component "sub-layers" that provide distinct DetNet > functionality? These are good questions to address early on in the > document so the reader is familiar with the concepts as they progress > through the document. Please note that the WG has reached consensus on introducing the term "sub-layer", in particular using the terms "DetNet Service sub-layer" and DetNet Forwarding sub-layer", see: https://mailarchive.ietf.org/arch/msg/detnet/TR6oXu7IMWhelrH_I-tOuHGfDqo. These are explained in detail in Section 4. DetNet Architecture. I do not see how to bring it earlier in the document. Section 4. DetNet Architecture also explains what is meant by sub-network. Figure 3 shows it and the text above Figure 3 explains. I don't see how could be this explanation earlier in the document. As for the abstract, would it help to replace?: OLD: DetNet operates at the IP layer and    delivers service over sub-network technologies such as MPLS and IEEE    802.1 Time-Sensitive Networking (TSN). with NEW: DetNet operates at the IP layer and    delivers service over lower layer technologies such as MPLS and IEEE    802.1 Time-Sensitive Networking (TSN). Similar replacement could be done in the introduction: OLD:    DetNet operates at the IP layer and delivers service over sub-network    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking    (TSN). NEW:    DetNet operates at the IP layer and delivers service over lower layer    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking    (TSN). The next occurrence of sub-network is with a cross-reference to the section with Figure 3 and description. I think it is fine this way as the reader can jump there and check the details. > > Section 1 > > 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. > > side note: Campus-wide networks at educational institutions are basically > guaranteed to have untrusted entities participating in them, just as a > backdrop for security considerations. > > Section 3.1 > > This mechanism distributes the contents of > DetNet flows over multiple paths in time and/or space, so that the > loss of some of the paths does need not cause the loss of any > > The failure models for which this statement is absolutely true as opposed > to probabilistically true seem rather unrealistic models of real physical > systems. > > Section 3.2.1.1 > > The primary means by which DetNet achieves its QoS assurances is to > reduce, or even completely eliminate packet loss due to output packet > contention within a DetNet node as a cause of packet loss. [...] > > editing error? > > Note that App-flows are generally > not expected to be responsive to implicit [RFC2914] or explicit > congestion notification [RFC3168]. > > I note that the word "implicit" does not appear in RFC 2914; it may be > worth a bit more detailed of a mapping from concept to reference. > (This text/reference also appears in Section 4.3.2.) Would it help to change the text?: OLD:    There is no expectation in DetNet for App-flows to be responsive to    implicit [RFC2914] or explicit congestion notification [RFC3168]. NEW:    There is no expectation in DetNet for App-flows to be responsive to    congestion control [RFC2914] or explicit congestion notification [RFC3168]. > > Section 3.2.1.2 > > In > general, users are encouraged to use, instead of, "do this when you > get the packet," a combination of: > > It seems that an architecture would be within its rights to *mandate* such > application design, rather than just encourage it. What sorts of > exceptions would cause us to not want to mandate this design? This is not mandatory. For instance, it is not mandatory to use time synchronization. There may be DetNet services that do not require time synchronization. > > Section 3.2.2.2 > > Please expand SRLG (it is only used once, so the abbreviation itself may > not be needed at all). Replace "SRLG" with "Shared Risk Link Group (SRLG)" > > Section 3.2.3 > > Out-of-order packet delivery can be a side effect of distributing a > single flow over multiple paths especially when there is a change > from one path to another when combining the flow. [...] > > nit: comma before "especially". Add comma. > > Resource allocation > The DetNet forwarding sub-layer provides resource allocation. > See Section 4.5. The actual queuing and shaping mechanisms > are typically provided by underlying subnet, these can be > > nit: is this usage of "subnet" common? Figure 3 shows it and the text above Figure 3 explains sub-net. > Also, this comma looks to be a comma splice. Make it two sentences. > > closely associated with the means of providing paths for > DetNet flows, the path and the resource allocation are > conflated in this figure. > > nit: Hmm, actually, is this comma *also* a comma splice? Make it two sentences. > > Operations, Administration, and Maintenance (OAM) leverages in-band > and out-of-band signaling that validates whether the service is > effectively obtained within QoS constraints. [...] > > nit: is there a singular/plural mismatch here ("the service"/"service" vs. > "effectively within"/"effectively obtained within")? Seems good to me. > > Section 4.1.1 > > This figure would have helped me a lot several sections earlier. > > Section 4.1.2 > > A "Deterministic Network" will be composed of DetNet enabled end > systems, DetNet edge nodes, DetNet relay nodes and collectively > deliver DetNet services. DetNet relay and edge nodes are > > Nit: I think this is intended to be: > A "Deterministic Network" will be composed of DetNet-enabled end > systems, DetNet edge nodes, and DetNet relay nodes, which collectively > deliver DetNet services. DetNet relay and edge nodes are Fine by me to make the cahnge. > > Examples of > sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. [...] > > nit: are these sub-networks or protocols used by sub-networks? These are sub-network technologies. They may include/use multiple protocols. > > Distinguishing the function of two DetNet data plane sub-layers, the > DetNet service sub-layer and the DetNet forwarding sub-layer, helps > to explore and evaluate various combinations of the data plane > solutions available, some are illustrated in Figure 4. This > > nit: this last comma is a comma splice. Suggest to replace with: "DetNet data plane is divided into two sub-layers: the DetNet service sub-layer and the DetNet forwarding sub-layer. This helps to explore and evaluate various combinations of the data plane solutions available. Some of them are illustrated in Figure 4." (https://mailarchive.ietf.org/arch/msg/detnet/JvPTAFVTJwxjhzZYEF9uCnUTFBA) > > There are many valid options to create a data plane solution for > DetNet traffic by selecting a technology approach for the DetNet > service sub-layer and also selecting a technology approach for the > DetNet forwarding sub-layer. There are a high number of valid > combinations. > > nit: I think "large number" is more conventional prose. Replace "high number" with "large number". > > Section 4.3.1 > > I think I'm confused about how, for these flows that "require the > feature", whether that means that the DetNet implementation must provide > , or that it is required for the application to have implemented the > feature. A mapping (if it makes sense) to the categorization of end > systems in Section 4.2.1 would be a big help. The notation is crafted such that to provide mapping. > > Section 4.3.2 > > Asynchronous DetNet flows are characterized by: > > o A maximum packet size; > > o An observation interval; and > > o A maximum number of transmissions during that observation > interval. > > Is there necessarily only a single tier of observation interval/rate? > (E.g., could there be a burst cap in a small interval and then a lower > overall baseline rate over large intervals?) We intentionally have a simple model here. > > That is, while any useful application is written to > expect a certain number of lost packets, the real-time applications > of interest to DetNet demand that the loss of data due to the network > is a rare event. > > (I might even go with "vanishingly rare".) Yes, there are extremely low loss requirements in certain use cases. That's why we have PREOF. > > Section 4.4.1 > > (Is there a standard reference for "Northbound"? I know we're all used to > it, but it's probably best to have a reference if we can.) RFC7426 is a reference. It is cited at the very beginning of the section. > > Section 4.4.2 > > The deterministic sequence can > typically be more complex than a direct sequence and include > redundancy path, with one or more packet replication and elimination > points. [...] > > nit: "redundancy paths", plural? Replace "redundancy paths", "redundant paths". > > Section 4.8 > > How does *provisioning* require knowledge of *dynamic* state? I guess the idea was that the resource may change dynamically. Would it help to delete "dynamic"? Thus get: "The state of a DetNet node's DetNet resources." > > Section 4.9 > > Does aggregation like this pose a risk of all the aggregatees getting > affected when one exceeds their allocation substantially (so as to also > cause the aggregate to exceed the aggregate's allocation)? One way could be to apply rate limitation for each member flow being aggregated at the input of the aggregate flow. The need to apply rate limitation is explained at multiple places in the document. > > Section 6 > > The ability for an attacker to use QoS markings as part of traffic > correlation/inspection is not new with DetNet, but is probably still worth > mentioning explicitly. Do you mean mention it in Section 5 Security Considerations? The text in my previous mail (https://mailarchive.ietf.org/arch/msg/detnet/mOzgdXOJ5lGr4gLBGAapYt6Azl8) has a paragraph starting: "To provide uninterrupted availability of the DetNet quality of service, provisions must be made against DOS attacks and delay attacks." Would it be good to extend that paragraph with a sentence, e.g.,?: "Malicious QoS marking should be also considered". From nobody Sat Mar 2 13:04:02 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 16CD2130DEF for ; Sat, 2 Mar 2019 13:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pN5faOCZi1E for ; Sat, 2 Mar 2019 13:03:52 -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 E3370130EA2 for ; Sat, 2 Mar 2019 13:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551560629; x=1554152629; 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=dPZH3gAoQkLEAIMZB2rYk9AKMWkpj5eSWOU+rlDVWyw=; b=eBYSaijXLZcuisBRxg7EE9qYJQ9o8lddhTVLyMygUhE5clTaCDL2WMsqoQbLLGNk ETShkQo8GTxFM30mookX90bDSEAGxX33YPRidf6xIB3PZ5Jsl0tuiidYWvF16KZR 3szwW3Dfet9tOPdoudTxtO3EGH60EnWSsFwD2corcp8=; X-AuditID: c1b4fb30-fabff7000000355c-c4-5c7aefb54a1f Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.E2.13660.5BFEA7C5; Sat, 2 Mar 2019 22:03:49 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 22:03:49 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 22:03:48 +0100 To: Suresh Krishnan CC: The IESG , , Lou Berger , , References: <155075828359.8615.9538259641487527490.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Sat, 2 Mar 2019 22:03:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <155075828359.8615.9538259641487527490.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7ie7W91UxBs+va1hc6//BYvH702wW iw/fZrJYzPgzkdmio/kti8W2rlMsDmweS5b8ZPI4f2UGu8eHTc1sAcxRXDYpqTmZZalF+nYJ XBkHrv5iLdikX/HvZBdzA+M31S5GDg4JAROJexv1uxi5OIQEjjBK3DuxiBXC+coo8bhrHQuE c5hRYsP0zUxdjJwcwgJJEp//72UFsUUE1CUWNV4E62AWmMoose3jOTaQhJCAj8TrM9/ZQWw2 AXuJu5c2MIPYvED2wid/GUFsFgEViU0rfoANFRWIlfh0ZTFUjaDEyZlPWEBsTgFfibY/D8Dm MAtYSMycf54RwpaXaN46mxnCFpe49WQ+E8ReNYlPbx+yT2AUmoVk1Cwk7bOQtM9C0r6AkWUV o2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBUHNzy22AH48vnjocYBTgYlXh4n9+oihFiTSwr rsw9xCjBwawkwlv6ACjEm5JYWZValB9fVJqTWnyIUZqDRUmc94+QYIyQQHpiSWp2ampBahFM lomDU6qBUXrFvbsTPxnJbXutcl6WMcEtZpa/RMfDm4seGa9S61xrsu5cXazipZuaOl4ND57V bWpPO3FMeBWj6nlrozUXp1959G2jytJAE9a8NmWDK4/ChWb/FePpZ/Tv1Krr/JwTvyD/67Vz r7WmvOG+vGBj5NnoI/a+OWcfTj9Xp3JzBvv1LtbFa9OfZSixFGckGmoxFxUnAgCIiQDihgIA AA== Archived-At: Subject: Re: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 21:03:55 -0000 Hi Suresh, Thank you for your review! Please see in-line: On 2/21/2019 3:11 PM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-detnet-architecture-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3.2.1.1. > > Given that we also know some of the downsides as well of large buffers, I think > a pointer to some background might be warranted here. I would recommend a basic > reference to something like > > Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January > 2012, Add reference with new sentence at the end of the paragraph: "Note that large buffers have some issues, see, e.g., [BUFFERBLOAT]." > > * Section 3.2.2.2. > > It is not obvious to me how the POF cannot be the last operation at the > receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see > the need for them to do PRF and PEFs but I am not sure applying the POF at > intermediate nodes can necessarily help the low latency and low jitter goals. > > The order in which a DetNet node applies PEF, POF, and PRF to a > DetNet flow is implementation specific. The intention here is not to bound any specific order of the PREOF functions within a device, or not even bound which device implements which function. There can be complex network set-ups created. Furthermore, different implementations may have different pros and cons with respect to the order of PREOF functions. As pointed out, this is mainly valid for PRF and PEF; however, the same leave it open approach can be carried on all of the PREOF functions including POF. Would it help to replace the sentence with?:   The order in which a DetNet node applies PEF, POF, and PRF to a    DetNet flow is left open for implementations. > * Section 3.2.3. > > RFC7426 does not contain much specific information about explicit route setup. > Is there a particular section you want to point to. If not, I don't think this > reference is of much use. RFC8453 is listed twice. Delete RFC7426 and one of the RFC8453s. > > * Section 3.3.1. > > Not sure why this is a requirement but I do wish to note that there are no such > worst-case latency guarantees for best effort traffic (aka non-Detnet) in > current networks. Can you clarify? > > o DetNet flows can be shaped or scheduled, in order to ensure that > the highest-priority non-DetNet packet is also ensured a worst- > case latency. This is to protect the QoS of non-DetNet flows if needed.DetNet flows have stringent QoS requirements. There may be non-DetNet flows that are not best-effort, but have some QoS requirements, although, less stringent than that of the DetNet flows. > > * Section 4.1.1. > > This text "Peers with Duplicate elimination." seems to be completely out of > place under the "Packet sequencing" heading below Figure 2. Copy and paste > error? Packet sequencing peers with duplicate elimination. It is explained under duplicate elimination as well, and they are leveled in the figure. Would merging the two sentences help?:            As part of DetNet service protection, supplies the sequence            number for packet replication and elimination (Section 3.4),            thus peers with Duplicate elimination. > > * Section 4.3.2. > > I found the expression "number of bit times" confusing. I have understood "bit > time" to mean the amount of time taken to emit a bit from a network interface. > Based on that definition, this expression does not make sense. Is there a > better reference/definition of what you mean? Would it help to rewrite?: OLD:    These parameters, together with knowledge of the protocol stack used    (and thus the size of the various headers added to a packet), limit    the number of bit times per observation interval that the DetNet flow    can occupy the physical medium. NEW:    These parameters, together with knowledge of the protocol stack used    (and thus the size of the various headers added to a packet), provide the    bandwidth that is needed for the the DetNet flow. > > * Section 4.5. > > There might be some other recent IETF defined mechanisms that might be relevant > to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc. Add RFC8289 and RFC8033 with a new sentence as the penultimate sentence of the section: "Further techniques are defined by the IETF, e.g., [RFC8289] and [RFC8033]." > > * Section 4.7.2. > > While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure > what kind of mapping you were thinking for IPv4. If this is not possible, I > think a note to that effect might be useful here. Flow identification details for IP data plane are described in draft-ietf-detnet-dp-sol-ip. Would it help to add the following introductory text to Section 4.7?: "This section discusses what needs to be done at technology borders including Ethernet as one of the technologies. Flow identification details for MPLS and IP data planes are described in [I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip], respectively." > > * Sections 5 and 6 > > I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and > would like to see them addressed. > > Thank you, Janos From nobody Sat Mar 2 13:25: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 5023C130EA2 for ; Sat, 2 Mar 2019 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBcyIcEjItr7 for ; Sat, 2 Mar 2019 13:24:40 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74898130EA9 for ; Sat, 2 Mar 2019 13:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551561875; x=1554153875; 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=VdZ+MIR0bFzZSoM6MT8L9L3zcD469m3dq9c8upbmNR8=; b=CnkECYymMtfSnA0Z3krgUk3a/MfJAc+uQW9WbzpL79S3vZsPk89CUBzzNtU/Ts6O LBw0hmEdLuB8ePKnkUAS27ddThp05A34vwGmpJ/3fcIMpx40r9cnSnfIgXzGQwBQ RbEcKdGmbC4W5cETM1H3LpKt2BBWl7LvzTxuPNxONkI=; X-AuditID: c1b4fb3a-14fff7000000672c-7e-5c7af493cb87 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.DE.26412.394FA7C5; Sat, 2 Mar 2019 22:24:35 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) 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; Sat, 2 Mar 2019 22:24:35 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 22:24:35 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.189) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 22:24:34 +0100 From: =?UTF-8?Q?J=c3=a1nos_Farkas?= References: <10e5a672-9a78-14b1-532c-272634a5e5ef@ericsson.com> To: CC: , , , , DetNet WG Message-ID: <0462874a-ad80-44f2-1608-b20b38bbcaf6@ericsson.com> Date: Sat, 2 Mar 2019 22:24:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <10e5a672-9a78-14b1-532c-272634a5e5ef@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbG9SHfyl6oYg22fVC2u9f9gsfj9aTaL xYdvM1ksZvyZyGzR0fyWxeLwsctMDmweS5b8ZPK4feMPu8eHTc1sAcxRXDYpqTmZZalF+nYJ XBlP+lcwFvTKVFzbdYOpgfGHWBcjJ4eEgInE2XsL2boYuTiEBI4wSvQvWw3lfGWU2NDawQTn bDv/hBHCOcwo8frUIUaQfmGBBImtW76xgthsAvYSdy9tYAaxhYDsbevfMoHYIgLiEjdP/2IG aWYW6GaUOHnlDFgDL1DR9t17gYo4OFgEVCQmfssACYsKxEp8urKYGaJEUOLkzCcsIDangIPE vrO7wVqZBSwkZs4/zwhhy0s0b53NDGGLS9x6Mp8J4gY1ifcNdxgnMArPQjJqFpL2WUjaZyFp X8DIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMF4ObvlttYPx4HPHQ4wCHIxKPLylH6pi hFgTy4orcw8xSnAwK4nwlj4ACvGmJFZWpRblxxeV5qQWH2KU5mBREuf9IyQYIySQnliSmp2a WpBaBJNl4uCUamDMN9h53U31qPlGp0o3t5cnUxtZty+5dW+l7Uehv067+6f5Cm+qqY3xXMXZ t1vR82744QN+ZsGX4/u1Nq/iZzx+P9V7kifr3cM3jmm2bdFs+m0fPWv9hzlbmi1fJ7Ce/JIf LXbN7o5ngrOmYPWC5WqizyOXrnjpY3D77wonbbuz88UfxIvrPTZWYinOSDTUYi4qTgQAkb11 95MCAAA= Archived-At: Subject: Re: [Detnet] Warren Kumari's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 21:24:42 -0000 Hi Warren, Thank you for your review! Please see in-line: > Warren Kumari has entered the following ballot position for > draft-ietf-detnet-architecture-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you, this is a very well written, and easy to follow. > > I do have some minor comments and nits. > > 1: 3.2.1.2.  Jitter Reduction > "A core objective of DetNet is to enable the convergence of sensitive > non-IP networks onto a common network infrastructure." > You *do* say this in the introduction, etc, but this sentence is the > clearest description - consider moving it up to the top. Suggest to extend the corresponding sentence in the introduction: OLD:    A goal of DetNet is a converged network in all respects.  That is,    the presence of DetNet flows ... NEW:    A goal of DetNet is a converged network in all respects including the    convergence of sensitive non-IP networks onto a common network    infrastructure.  The presence of DetNet flows ... > > 2: 3.2.2.  Service Protection >    "Service protection aims to mitigate or eliminate packet loss due > to equipment failures, random media and/or memory faults." > This talks about memory faults, but what about (the common case) of > memory corruption? AFAICT, the protocol itself doesn't do anything > about this - perhaps it should mention this, and say that strong > checksums / integrity is the responsibility of the upper layer > protocol? "Extraordinary claims require extraordinary evidence"- Carl > Sagan. Suggest to change the sentence to:    "Service protection aims to mitigate or eliminate packet loss due to equipment failures, including random media and/or memory faults." This is really about protection against failures. DetNet is about to meet QoS requirements. Service protection is for stringent loss requirements. As suggested, going beyond is the responsibility of upper layers, hence beyond DetNet. > > 3: "The DetNet service sub-layer includes the packet replication (PRF), >    the packet elimination (PEF), and the packet ordering functionality >    (POF) for use in DetNet edge, relay node, and end system packet >    processing.  Either of these functions can be enabled in a DetNet >    edge node, relay node or end system." > This says "either" about three things. Suggest to delete "Either of" to get: "These functions can be enabled in a DetNet ..." > > 4: "3.3.2.  Fault Mitigation >    Robust real-time systems require to reduce the number of possible >    failures." > Apologies, I don't have suggested test to fix this, but "require to > reduce" reads oddly -- perhaps "require a reduction in"? Suggest to replace with: "Robust real-time systems require reducing the number of possible failures." (suggested the same change in: https://mailarchive.ietf.org/arch/msg/detnet/JvPTAFVTJwxjhzZYEF9uCnUTFBA) Thank you! Janos From nobody Sat Mar 2 13:51:02 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 D84B3130E58 for ; Sat, 2 Mar 2019 13:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGSfuWUxtjLw for ; Sat, 2 Mar 2019 13:50:57 -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 09749130F3B for ; Sat, 2 Mar 2019 13:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551563454; x=1554155454; 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=hCG/iTlIcue5vm6s1kGVRvxOYCMGWhGh87vJrpTpO9c=; b=TpKAcCrEb1+WCvvn8+9ZxH3v4FoICReCCSJIkDB4E5onmLannGWvNWkQr4ELiyKO gFp6OtEAYx7wPb23m4YCr9N92pt+CA4nyodgn/WmY/tBXKBq5rFLOw7/FfPYhUQ9 ufVhcpG7DsC5EJTlDreQirMmKZbsJbo/6JYjZZL7/ho=; X-AuditID: c1b4fb30-f93ff7000000355c-c1-5c7afabee6e2 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.A5.13660.EBAFA7C5; Sat, 2 Mar 2019 22:50:54 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) 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; Sat, 2 Mar 2019 22:50:53 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 2 Mar 2019 22:50:53 +0100 Received: from [100.94.35.103] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.191) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 2 Mar 2019 22:50:53 +0100 References: <102272239.6720.1549492535222.JavaMail.nobody@jva2tc258.webex.com> To: DetNet WG From: =?UTF-8?Q?J=c3=a1nos_Farkas?= X-Forwarded-Message-Id: <102272239.6720.1549492535222.JavaMail.nobody@jva2tc258.webex.com> Message-ID: Date: Sat, 2 Mar 2019 22:50:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <102272239.6720.1549492535222.JavaMail.nobody@jva2tc258.webex.com> Content-Type: multipart/mixed; boundary="------------12A64E7B42BAB9B2C999CCFA" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2J7ke6+X1UxBo+OSFn8/jSbxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXfW7GUteNfKWHH7xjXWBsbboV2MnBwSAiYSU/c+Z+1i5OIQ EjjCKLHi1loo5yujRNOas4xwzqKvDewQzmFGiaPrfzCC9AsLeEhcnbiZFcQWEvCTuHDqNQuI LSIgL9HY+5kdxGYTsJe4e2kDM8S+KIn9kzrB6nmB4huedjGB2CwCKhLLDp1iA7FFBWIlPl1Z zAxRIyhxcuYToJkcHJwC/hLdcy1AwswCARLLv7xggbDFJW49mc8EcYKaxPuGO4wTGIVmIeme haRlFpIWCDtMouf5DTYI20Ji5vzzjBC2vETz1tnMELaGROucueyY4g4Sv282Q81UlJjS/RCq xlZiTt8ilgWM3KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAiPv4JbfBjsYXz53PMQowMGo xMNb8qEqRog1say4MvcQowrQnEcbVl9glGLJy89LVRLhLX0AlOZNSaysSi3Kjy8qzUktPsQo zcGiJM77R0gwRkggPbEkNTs1tSC1CCbLxMEp1cCo85ypbHLXrJX+wW4upnIrYrx3nnwobHT/ 6GOZgJY3x+67PBB3kBa5e/OT86ysZMEqFtbbHO/5UmfWeu0QlZ8y2WfyzhSNmX08i9r4Ln/g 42KumH2s6R6LSFrs3CVcIa7nfu5edlDypfkfR7czeRN2PEzavTLzwXJ3Fw0J79snqoWt/4gX n3iuxFKckWioxVxUnAgAnWhiz8QCAAA= Archived-At: Subject: [Detnet] DetNet Data Plane drafts updates- Webex meeting - March 5, 2019 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, 02 Mar 2019 21:51:01 -0000 --------------12A64E7B42BAB9B2C999CCFA Content-Type: multipart/alternative; boundary="------------78372B283B10FA11E6CA9905" --------------78372B283B10FA11E6CA9905 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, We are discussing updating the data plane drafts on March 5 4pm CET: https://ietf.webex.com/ietf/j.php?MTID=mbbf080311dfab77ca7b1c3d17fef333c. Anyone interested is welcome to join. Regards, Janos -------- Forwarded Message -------- You can forward this invitation to others. Hello, DetNet Working Group invites you to join this Webex meeting. *DetNet Data Plane drafts progressing* Tuesday, March 5, 2019 4:00 pm  |  Sweden Time (Stockholm, GMT+01:00)  |  1 hr 30 mins Meeting number (access code): 642 076 634 Meeting password: DataPlane Add to Calendar When it's time, join the meeting . *Join by phone* *1-650-479-3208 * Call-in toll number (US/Canada) Can't join the meeting? IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. --------------78372B283B10FA11E6CA9905 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,

We are discussing updating the data plane drafts on March 5 4pm CET: https://ietf.webex.com/ietf/j.php?MTID=mbbf080311dfab77ca7b1c3d17fef333c.
Anyone interested is welcome to join.

Regards,
Janos


-------- Forwarded Message --------

You can forward this invitation to others.
Hello,
DetNet Working Group invites you to join this Webex meeting.
 
DetNet Data Plane drafts progressing
Tuesday, March 5, 2019
4:00 pm  |  Sweden Time (Stockholm, GMT+01:00)  |  1 hr 30 mins
Meeting number (access code): 642 076 634
Meeting password: DataPlane


 
Add to Calendar
When it's time, join the meeting.
 
Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
 
Can't join the meeting?
 
IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.
--------------78372B283B10FA11E6CA9905-- --------------12A64E7B42BAB9B2C999CCFA Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxv b2sgMTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpW VElNRVpPTkUKVFpJRDpTd2VkZW4gVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTcx MDAxVDAzMDAwMApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0xMApUWk9GRlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3Rh bmRhcmQgVGltZQpFTkQ6U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE3MDMw MVQwMjAwMDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9O VEg9MwpUWk9GRlNFVEZST006KzAxMDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGln aHQgU2F2aW5ncyBUaW1lCkVORDpEQVlMSUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVO VApBVFRFTkRFRTtDTj0iRGV0TmV0IFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1JTVlA9VFJVRTpNQUlMVE86ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZwpPUkdBTklaRVI7 Q049IkRldE5ldCBXb3JraW5nIEdyb3VwIjpNQUlMVE86ZGV0bmV0LWNoYWlyc0BpZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IlN3ZWRlbiBUaW1lIjoyMDE5MDMwNVQxNjAwMDAKRFRFTkQ7VFpJ RD0iU3dlZGVuIFRpbWUiOjIwMTkwMzA1VDE3MzAwMApMT0NBVElPTjpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNTQ5NDkyNTM1ClVJRDoy MThjZjM2NS01YjBmLTQzMzktODMxZC1lY2VkNTRiMTE3MDkKRFRTVEFNUDoyMDE5MDMwNVQx NTAwMDBaCkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYTU3NjEwYzJjMTg0ZjczNGNmNTE1 MTQ4MDRhY2Y4YWRcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MiAwNzYgNjM0 XG5NZWV0aW5nIHBhc3N3b3JkOiBEYXRhUGxhbmVcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkgXG5UYXAgaGVy ZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0 ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDIwNzY2MzQlMjMlMjMqMDEqXG5cblxuXG5D YW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNj by5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3 aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n IHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3Vz cyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFD RT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj4JCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1hNTc2MTBjMmMxODRmNzM0Y2Y1MTUxNDgwNGFjZjhhZCI+PEZPTlQgU0la RT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYmV4IG1lZXRpbmc8 L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2Vz cyBjb2RlKTogNjQyIDA3NiA2MzQ8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFi bGU+CQkJCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EYXRhUGxhbmU8L0ZPTlQ+ PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PGJyPjxGT05UIHNpemU9IjIiIENPTE9SPSIj RkYwMDAwIj48L0ZPTlQ+PGJyPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8 QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQg U0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9G T05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj48c3Ryb25nPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MjA3 NjYzNCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9u Om5vbmU7Jz4xLTY1MC00NzktMzIwODwvYT48L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwg bnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZu YnNwOzxCUj4JPGEgaHJlZj0iaHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20v YXJ0aWNsZS9XQlgwMDAwMjkwNTUiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIg RkFDRT0iQXJpYWwiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPjwvYT4JJm5ic3A7 PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJp YWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2 aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhl IHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4g YSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGlj YWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50 IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9z dCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOkRl dE5ldCBEYXRhIFBsYW5lIGRyYWZ0cyBwcm9ncmVzc2luZwpQUklPUklUWTo1CkNMQVNTOlBV QkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQ VElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --------------12A64E7B42BAB9B2C999CCFA-- From nobody Sat Mar 2 16:24: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 8ACE7124408 for ; Sat, 2 Mar 2019 16:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnFF_uz5ccHJ for ; Sat, 2 Mar 2019 16:24:02 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740134.outbound.protection.outlook.com [40.107.74.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E5C1271FF for ; Sat, 2 Mar 2019 16:24:01 -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=L4uvbfmosXez7UPobOQ2LkhNWAcnXhKmPtTwD6nNxLM=; b=cJVzZY/Fc43oZVDbuQFlupvjmA46QEoT3HqKUCdUSJ97IdAp7ayOEWrC5vCSiiFiZNKNEkR/Wj63ChsdJWteO7sT1wr9JE6Ct/Bk2rTJDQ/Mn0ZsmKaEtcNhFdl3835Ql2vv6iJu8m5p+2QyobbSI+DXCgeeFGrjLHG4tig1LP0= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB6279.namprd06.prod.outlook.com (20.178.234.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Sun, 3 Mar 2019 00:23:57 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500%6]) with mapi id 15.20.1643.022; Sun, 3 Mar 2019 00:23:57 +0000 From: "Grossman, Ethan A." To: Henrik Austad , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AdTCk1I+rewKQpliQKSaD45oyDyx+QA4UwMAA3aSJ+A= Date: Sun, 3 Mar 2019 00:23:57 +0000 Message-ID: References: <20190213081754.GB11908@sisyphus.home.austad.us> In-Reply-To: <20190213081754.GB11908@sisyphus.home.austad.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcZWFncm9zXGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctYTEwZmNlMGMtM2Q0YS0xMWU5LWFlM2MtYWNiYzMyN2E1MWM2XGFtZS10ZXN0XGExMGZjZTBkLTNkNGEtMTFlOS1hZTNjLWFjYmMzMjdhNTFjNmJvZHkudHh0IiBzej0iODY1MCIgdD0iMTMxOTYwNDYyMzYwODY0Njg3IiBoPSJFWGZFY3J2Wk1vNmgxL3lDS0EzeW9LRVJZekU9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7f321f0-4934-4f0f-e4fd-08d69f6e86f7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB6279; x-ms-traffictypediagnostic: BYAPR06MB6279: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB6279; 23:QLdwnwy1YB+KnEuK0pKbFAfg/7kubZ0kXennP1G6Z?= =?us-ascii?Q?1XIFRy+vIog51d2RbyQE6EoJnvgLX0+dDk0UAaAaDWx9rH/x1NnSEFiDYJzi?= =?us-ascii?Q?mqgtEu/tfOQIprXUM6wRVevSZSGm8FM7PYKJuUG7yC+GqEWiSF9QXqVKOxm1?= =?us-ascii?Q?4hTGLTz1OSdEsECzyOWisX3g7HqZawyXuqBEuIQ/gJIy2SH9yXtAX8XeMhMC?= =?us-ascii?Q?4LNLhfs2Z4RNtqqT9HAROKsaKa3WUOk0AbrBCMfVoXfvaTXwjI0L1peVbI/m?= =?us-ascii?Q?CUjZoNYOvJzWklhmXwg2+mc+6f3wq6pBEEDwa/wqpvBYg6fN3ltr1Ev7KzBW?= =?us-ascii?Q?n/748ctK4nMIxDr9MMeC4vrQsiVIcTnEDvP9c1fmXn7S7VBfRgMESu6ghoX+?= =?us-ascii?Q?bHb6QL20varl7R/p5L/56t5AbtLb4mwGMFQ1oJQwGJkGQ2ZltBIvyKj4yW98?= =?us-ascii?Q?LHgT//LLFSIB9BtMXe6NiGgXFEyJuc4mzwYgvQbmh6Oq6DMMnNM8V3/r01gj?= =?us-ascii?Q?i1WaOSWJJj59MwOyueuQ80bG9EI+1SB3cVjcBhco06YUaGWZoMD/UilBCL9d?= =?us-ascii?Q?Lem/U+ruYMsFq8OBZJa0BeEw7k/lf9kpIuPNk5P9NVIIchITDBkM7o63M0Nj?= =?us-ascii?Q?L2zaNQztn0jVwankRDoxhj0hawfgan5uWt5eQrT1e1zSylAF3i9gIZRcDwuh?= =?us-ascii?Q?qIBj538I1HdgHTHGqsfV0Slj6xOxeOPukKqZCBwbuYNEe1ZRyTJEKdVspNVh?= =?us-ascii?Q?aTMArLR1uRcddIUELOSpxPkOtNm/Yzt0b+DaMvsygiMc5fE8xWg0uliUb/+H?= =?us-ascii?Q?qRptLUHmULVL795LSH4AYgPqbxrae8v3v9vcQ6kE1l7cf6YDGOzQaNP05VPt?= =?us-ascii?Q?jzGvyVlm1HfmLzsi/KS57hd1z2ZhYIEFF9z3AWyyQwYW7EkWefYn58CvcwX4?= =?us-ascii?Q?Po0xP9SzZ6dSyOt8U7D99tXsCMpp0lM6DyNcaJgoIFyU4c5Z4WeghhWd2QZk?= =?us-ascii?Q?WHn70yHIAtNQ0cQa9cat6hJlyO4ebFxFjrPIypjNwAKufrlc2z+btwe2u7eJ?= =?us-ascii?Q?cC++Ud25r2vvgq8WRyBEFRO+HNmK+Dubu9Yh3gEvRD6tMdPhkEnHL2/zCkXb?= =?us-ascii?Q?hKpI7xG7jOpbcNXfWd1mFzj+UxEHQAqLgeuKPtfbKUhK2ojiFxLIJDTnVABA?= =?us-ascii?Q?GEgYxYRkcwVDuWwDOyfNUClRaHwXOwPXszWWgMc6MFy0hyfjio95aQVhnAui?= =?us-ascii?Q?cBMmZcz0oJiH13lUSehbDJRDpPpGBo8Rs3ji9PqpFzV2KUvubgMk86S+XJUl?= =?us-ascii?Q?apaDF7PTvIAOGwNqdoQ2aU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39850400004)(376002)(346002)(136003)(53754006)(13464003)(189003)(199004)(2906002)(81156014)(15650500001)(2501003)(14454004)(81166006)(52536013)(97736004)(86362001)(9686003)(68736007)(8676002)(66066001)(256004)(316002)(14444005)(11346002)(229853002)(110136005)(53546011)(446003)(6506007)(76176011)(476003)(7696005)(486006)(5660300002)(99286004)(25786009)(71200400001)(71190400001)(102836004)(106356001)(6436002)(55016002)(26005)(105586002)(305945005)(3846002)(33656002)(74316002)(6246003)(7736002)(6116002)(8936002)(186003)(478600001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB6279; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BzZLZkQEStr1oPgxKVndipVfbrHQYCjcJGf36WrYIG9BhpI+lgoaF3VrZIarTyPlV7tVwgEBvP2pQLZLYd4F9HtZ7Lsfe2XzItPOgre+OSGrwGdreFCuoxudSXAxh9jabqDTHLkTb94qw+dwfr1egaxDBw+6UeIp7QW5FwO9dEhIoA5ae41fRt2fuHb/cBq13l5laF5C/gr5bB24ShYZBsK7HK9O6VQNZTLoBXdPlBTd5pHKIF8g95Oa/2HSw1QkYcCMRqjGUM2Ef1UlGc5ANqkjvDy/rxYsutaAO/mmm5d/t2LnwcetmhgFRcZHPG8Jyb4noj5218A7wJPdX7om0/hnDgYM1GjkXNdXHq02cyWEWW+5PDBMFMiqlRQxIqgBBny9aCVv0KXj4NUuHjzJ7EdSsqyZ8xnW7pfmHInKNxw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7f321f0-4934-4f0f-e4fd-08d69f6e86f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2019 00:23:57.7544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB6279 Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption 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, 03 Mar 2019 00:24:05 -0000 Hi Henrik, Oops, my turn to be sorry - until now I missed your notes that were inline = with my text below. I just went through them and put my comments inline bel= ow (prefixed EAG:). I also noted the resulting changes I will make in my te= xt for this update to the DetNet Security draft. Some points are certainly = worth further discussion; for now I am limiting my scope of revision to the= current proposed section text. Others on the list are encouraged to add th= eir thoughts to this thread, and I can incorporate them into the next revis= ion.=20 Thanks again for your contribution, Ethan. -----Original Message----- From: Henrik Austad =20 Sent: Wednesday, February 13, 2019 12:18 AM To: Grossman, Ethan A. Cc: detnet@ietf.org; ekr@rtfm.com Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption On Tue, Feb 12, 2019 at 05:25:40AM +0000, Grossman, Ethan A. wrote: > Hi All, Hi Ethan, > I have consolidated the list discussion about the pros and cons of=20 > encryption algorithms into the Mitigation-Encryption section of the=20 > security draft (text of the section as it now reads is below). I would=20 > like the WG to review it before I publish it in a new version of the=20 > Security draft. I must have missed that discussion - sorry! (If this means that I'm covering old, settled points below, please just ign= ore my ramblings) Question (relevant for my points below): Do we plan to *encrypt* the header of the DetNet flows in transit, or will = it be sufficient that the header is cryptographically signed? EAG: My understanding is that this would depend on the requirements of the = use case, i.e. the design/implementation of a given DetNet. That is, some u= se cases that require very high levels of security might want to encrypt th= e header, and be willing to accept the performance hit. Others might requir= e minimum latency and not require that the headers be encrypted, or perhaps= even signed. However I think this would make a good discussion for the lis= t to see if there is anything we can agree on that would apply to all DetNe= ts. Having said that, you already sent this email to the list and we got no= further discussion on the topic, but maybe this will revive the discussion= .=20 Follow up; if we go with signing, will intermidate nodes have a need to upd= ate the DetNet header, and if so, how do we solve the key-management proble= m for a per-flow set of signing keys to all relevant nodes? EAG: Referring back to my comment above, I hope that this level of specific= ity can be left as an exercise to the DetNet designer. If you are saying th= at this is something that has to be resolved at the DetNet Architecture lev= el, please let us know so that we can address it.=20 -H > Thanks, > Ethan (as editor of the DetNet Security draft) > -------------------------------------------------------------------- > 5. Security Threat Mitigation > 5.4. Encryption > Description > DetNet flows can be forwarded in encrypted form. > Related attacks > Encryption can be used to mitigate recon attacks (Section 3.2.7).=20 > However, for the DetNet to give differentiated quality of service on a=20 > flow-by-flow basis, it must be able to identify the flows individually. > This implies that in a recon attack the attacker may also be able to=20 > track individual flows to learn more about the system. > > Encryption can also provide traffic origin verification, i.e. to=20 > verify that each packet in a DetNet flow is from a verified source,=20 > for example as part of ingress filtering. Since this covers more than 1 vector, perhaps it would be worthwhile to dis= tinguish between confidentiality (encrypting the payload of the stream, pre= ferrably in an end-to-end manner) and integrity (of the header itself using= some sort of HMAC). As Maik pointed out in another email, we must make a p= oint about crypto agility. The payload itself should be end-to-end encrypted, the nodes should not hav= e any need to inspect the payload itself. We can probably push the responsi= bility of this to the DetNet-application, the protocol should be data-agnos= tic. EAG: I am trying hard to limit the scope of the DetNet Security draft to se= curity considerations related specifically to time-sensitive aspects of Det= Net. It seems to me that the discussion about confidentially vs integrity i= s a very good point, as is the point about crypto-agility, but I'm hoping t= hat these are generic enough to be "considered to be covered elsewhere". Do= you agree? =20 > 5.4.1. Encryption Considerations for DetNet > > Any time spent on encryption and decryption processing ("crypto") must=20 > be included in the flow latency calculations. Thus, crypto algorithms=20 > used in a DetNet must have bounded execution times. Some crypto=20 > algorithms are symmetric in encode/decode time (such as AES and SHA-2)=20 > and others are asymmetric (such as public key algorithms). Nitpick SHA-2 is a hashing algorithm, not a crypto-algorithm. Also, Since SHA-2 is very similar to SHA-1 (which is considered broken), SHA-3 was born. As with crypto agility, we should make a note about hash-fu= nction agility. EAG: OK I will remove the reference to SHA-2, it isn't necessary to have a = second example there.=20 > There are advantages and disadvantages to the use of either type in a=20 > given DetNet context. Asymmetrical crypto is typically not used in=20 > networks on a packet-by-packet basis due to its computational cost.=20 > For example, if only endpoint checks or checks at a small number of=20 > intermediate points are required, one can use asymmetric crypto to=20 > authenticate distribution or exchange of a secret symmetric crypto=20 > key; a successful check based on that key will provide traffic origin=20 > verification as long as the key is kept secret by the participants.=20 > Both TLS and IKE (for IPsec) are examples of this for endpoint checks. Not only TLS and IKE; this is pretty much how asymmetric crypto works. You = create a symmetric key and you use asymmetrci crypto to share that secret b= etween Alice and Bob. EAG: OK, I suppose I can leave my existing text as it is.=20 Then you also re-generate the symmetric keys periodically. This is perhaps = something we should make a not of, as that will add some additional cost, t= hus affecting the determinstic behaviour. EAG: This is a highly relevant point. I added the following: "If crypto ke= ys are to be regenerated over the duration of the flow then the time requir= ed to accomplish this must be accounted for in the latency calculations." > However, if we use secret symmetrical keys for this purpose we must=20 > give the key to all relays, which increases the probability of a=20 > secret key being leaked. Also, if any relay is compromised or=20 > misbehaving it may inject traffic into the flow. Hence the need to split the header from the payload, regenerate symmetric k= eys etc. EAG: Right. Again I think this is a generic consideration?=20 > Alternatively, asymmetric crypto can provide traffic origin=20 > verification at every intermediate node. Signature verification using public keys is a pretty deterministic operatio= n I think, generate the hash, verify the signature. I need to dig through s= ome books to be sure. EAG: I don't think we want to make any particular claims about specific alg= orithms or processes here, just a general comparison between technologies.= =20 > For example, a DetNet flow can be associated with an (asymmetric)=20 > keypair, such that the private key is available to the source of the=20 > flow and the public key is distributed with the flow information,=20 > allowing verification at every node for every packet. However, this is=20 > more computationally expensive. In either case, origin verification=20 > also requires replay detection mechanism as part of the security=20 > protocol to prevent an attacker from recording and resending traffic,=20 > e.g., as a denial of service attack on flow forwarding resources. There are ways to avoid replay-attacks when you have secure hashes, but you= must store some state on each node. Since each frame contains both a seque= nce-number and a stream-id, what we need are available to detect replays. T= his means that the header must either be transported in the clear, or that = we can decrypt it in transit though. EAG: I believe that this is covered by the phrase "also requires replay det= ection" - your comments are about how to implement such a mechanism, right?= =20 --=20 Henrik Austad From nobody Sat Mar 2 17:10:45 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 3D434124408; Sat, 2 Mar 2019 17:10:44 -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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <155157544420.27185.10498779285399131382@ietfa.amsl.com> Date: Sat, 02 Mar 2019 17:10:44 -0800 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-security-04.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 01:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking (DetNet) Security Considerations Authors : Tal Mizrahi Ethan Grossman Andrew J. Hacker Subir Das John Dowdell Henrik Austad Kevin Stanton Norman Finn Filename : draft-ietf-detnet-security-04.txt Pages : 41 Date : 2019-03-02 Abstract: A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-security-04 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-04 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 Mar 2 17:24:34 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 666061200D8 for ; Sat, 2 Mar 2019 17:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5it-vrY3U4Re for ; Sat, 2 Mar 2019 17:24:30 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780100.outbound.protection.outlook.com [40.107.78.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04176124B0C for ; Sat, 2 Mar 2019 17:24:29 -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=HhesrYDR6xtLzJltmgTgW96rCkORDnTvSfEO5gNPiVc=; b=AJ8j28KZ5Rp6YCnchJ5wmwMuqrOqq92umZc0K6AjB4IHIl5vglYY3IVeCHHn02tvBt9iPsUgkviISpkKmDsRvjiT3FbdTKz7O2wd2yODRj/1bZpgCTgSUmALeVaVmeGuXtAWNSkM8d4HZe41++yo3FCxp8ACZ/AdQEYnO4iFa2g= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB3861.namprd06.prod.outlook.com (52.135.197.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Sun, 3 Mar 2019 01:24:26 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500%6]) with mapi id 15.20.1643.022; Sun, 3 Mar 2019 01:24:26 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-04.txt Thread-Index: AQHU0V3y1bXIqVW8QkS0r1168oFHIqX5GVQg Date: Sun, 3 Mar 2019 01:24:26 +0000 Message-ID: References: <155157544420.27185.10498779285399131382@ietfa.amsl.com> In-Reply-To: <155157544420.27185.10498779285399131382@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcZWFncm9zXGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctMTQyNWU0NDktM2Q1My0xMWU5LWFlM2MtYWNiYzMyN2E1MWM2XGFtZS10ZXN0XDE0MjVlNDRiLTNkNTMtMTFlOS1hZTNjLWFjYmMzMjdhNTFjNmJvZHkudHh0IiBzej0iNDAwMiIgdD0iMTMxOTYwNDk4NjUxMjc0MjcyIiBoPSJWMW9zTjhnb2hFLzNjM05QK0lvLzgvb0FNYnc9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 996da5c8-1f67-4c8c-e18b-08d69f76f9db x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB3861; x-ms-traffictypediagnostic: BYAPR06MB3861: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB3861; 23:8UtR74sI0srahGafQjc6fOZZzSPHbx8Xu0cj0vwBx?= =?us-ascii?Q?J5nPQz+90NMKO/Ct3L8vNkx0jj52fVvpA3WAh9Qn/n6oAnoP926Xs1wgrxP6?= =?us-ascii?Q?HGWkehbqFw4303xjLpsyUwCVl3mRJzH44YCFEc+YSmlxkQASdAPDD9GsfZ9e?= =?us-ascii?Q?aDbNb8QYDVAdAlOWsEb1eMYjmF6nSFt4PxuavYbL10vZQRpthrdPvZ1SNmn2?= =?us-ascii?Q?+nOAaiUSmu2Yx3Ndjr0xTLYqr5Od14CC+XIHp2Ob1E+6YS8jrYihruAzcoeP?= =?us-ascii?Q?Nea+fjhRWi84NeBiXtxDDhEZg+ZEK5oQuqepgJmMKFZezpjHd+MJ4DXgxHIf?= =?us-ascii?Q?0NuLxasntawEEimcKokhPwaQQrCgJABUg5nJvNt1zhB3KA+eC8/jeUAbpZ9a?= =?us-ascii?Q?RvkOl+ZUB05cKsbTQEPERK7ESXIgJCZKQVE8XuLMT87pkHY1vCv0X1xA6aRz?= =?us-ascii?Q?7bJBvauR5bs3w1YXq9ru3a9iee7btOeh+wGoJPystRcKmEeMVmKlqI4CCps9?= =?us-ascii?Q?mBLFDS+Y0UCuRNkM4jTqIy1Y7hxxTURljVpj0DGYYVe9CaOrEI3PxyWLNey/?= =?us-ascii?Q?5SVQgpIadttqtH7Ehq01eDvWBCFITDXuAuT35LMuZn7E7aZe9NGvarotohn2?= =?us-ascii?Q?10tHZSvF7nKHt9ZadxtK3mLffW79kd8S8Wb9q9GbJUnnBqrGJ0iL+pvBPlj3?= =?us-ascii?Q?B7HFwwn1Fk+LpGAVJeQiS0Es48IpUgao1vbD4KbodIY1DCch95QbWiDE6jXd?= =?us-ascii?Q?HgAo5EvIpz0VbCSLlf3JauAP/pD3iUuw5SoSJaM69Nhbluj0DDGN26Zt4Dpc?= =?us-ascii?Q?SMQHYA5LlfeDa+SY5Binhm5TjDsiBJqTaMYmU0qm9IRqvv+wbNdH6oeDKG/l?= =?us-ascii?Q?J3wxEV2a/uEihmQQQ7Z2yfdBG6IRlzYuxXoPF4EtZTLAdV4BmupgIoXqdquu?= =?us-ascii?Q?LPkPjOOxaL7lF//AqiVKiMbD0GqoQFdCOszk3+EEzk1m3RMc+OZMux1E69XF?= =?us-ascii?Q?u6dxMELiA1TE8Yalv3urnq0lG0B2hhkWRerJJcj8cqdGj4QFsILgxDj2j/xk?= =?us-ascii?Q?GCO2NhpG9BdKLe3JWAmsFkBQD/3Z+uIG+V4nroVIEJALxnoS8pjsb08jR0/L?= =?us-ascii?Q?6DFGMdO+8jdMI152uth/hksqqusgWpHb/GSuQWFwn8TvknaBf2xtkc6Abh0e?= =?us-ascii?Q?bgEbt2L2Nxk6NV3QDj3aaaCiEgQw/TfF0uUJoSshLyJJdTk9QKhErnau+r20?= =?us-ascii?Q?fieYkk+t/vD0UL77FhmSjXua3CQrCMTDSNYVwq9oiZbnJSNNxGEZUv97CMmR?= =?us-ascii?Q?tVsaR1Imz+J4FrpohfOm4LqjJcO39PdJHyq54MM62pifPWaviFlvbHgVTTRk?= =?us-ascii?Q?JjqUoVaIDej3G+DU7L86QSUmWpn8gEAgp5UvyYVdoXuVSocU4sxC1cpfU+S+?= =?us-ascii?Q?7Kdvepndw=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(136003)(396003)(366004)(346002)(376002)(13464003)(199004)(53754006)(189003)(8676002)(2906002)(2501003)(86362001)(52536013)(2351001)(105586002)(81156014)(81166006)(7736002)(26005)(106356001)(229853002)(66066001)(66574012)(68736007)(76176011)(316002)(5660300002)(8936002)(53936002)(14454004)(256004)(97736004)(15650500001)(99286004)(55016002)(33656002)(14444005)(6916009)(305945005)(74316002)(3846002)(5640700003)(6116002)(6436002)(966005)(7696005)(9686003)(6246003)(6506007)(486006)(476003)(186003)(6306002)(71200400001)(71190400001)(25786009)(478600001)(102836004)(446003)(53546011)(11346002)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB3861; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vINVU9RO5zhiIsjRxFA56i+DDQkyIf8EloLfWBRdHY4YzwXxT6ypsZWb3Ds9z0yumrIxJmuHF+4Kk6aVrkzLJLxqgO5e6qEKPI9811WsLP+KlJJoLBrJuLX+msLxsGIy5O8NL1TUiRmZReK5WSLj50ByQISUjUObrE14SbTRHn2gmelvOoC0x447BJKeAJaI/xsvSkXLfMkq9jhyUEHpsCmNvHXQbFtUMIXdlR7yRniSPNDsJ6HqrQWFsJU8gsHtxDCM52Kspx0YvU2IR7m2qs72A1E4VBxTBQxZi29S/AA0BsM+g9vmotO73IAqmZ6AwIVq5qDYLavEOqHSyehbbYZjLQC+UlFTtfK4t4+AyrbzSrKQXwo/4CI5OD3Ta1v/6PIBorRvGGtwuud2uTbCXL/9oVu37QL87OmxgChQhtQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 996da5c8-1f67-4c8c-e18b-08d69f76f9db X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2019 01:24:26.4636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB3861 Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-04.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 01:24:32 -0000 Hi All, This update incorporates the discussion from the list regarding timing cons= iderations in the use of Encryption in DetNet networks, plus a few other sm= all items. These are minor changes, so this notice constitutes the status u= pdate for the DetNet Security Considerations draft for IETF 104.=20 Having said that, there has been discussion recently about the degree to wh= ich the DetNet Architecture should include specific security expectations f= or any DetNet system, regardless of the use case for that system. My intent= is to convene a side-meeting at IETF 104 on DetNet security topics in gene= ral, including this one. If those of you who will be attending have any int= erest in this, please let me know. =20 Thanks, Ethan (as DetNet Security Draft editor) -----Original Message----- From: detnet On Behalf Of internet-drafts@ietf.or= g Sent: Saturday, March 02, 2019 5:11 PM To: i-d-announce@ietf.org Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-security-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking (DetNet) Security Consid= erations Authors : Tal Mizrahi Ethan Grossman Andrew J. Hacker Subir Das John Dowdell Henrik Austad Kevin Stanton Norman Finn Filename : draft-ietf-detnet-security-04.txt Pages : 41 Date : 2019-03-02 Abstract: A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-security-04 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-security-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Sat Mar 2 20:42:53 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 16392129A87; Sat, 2 Mar 2019 20:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 j4YGkkJNbQ7s; Sat, 2 Mar 2019 20:42:50 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700131.outbound.protection.outlook.com [40.107.70.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DB1126D00; Sat, 2 Mar 2019 20:42:49 -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=oDzqq5dK5vdLMnm5RgjAMl51sxeI8+d1N2d1ZabbvOw=; b=CYW6clMCCkfsGIid43vLcXgHiTMj6Ms8DKC2N//pK9KX4G9c6EATN8Qvm/SBnOKN30S10MCCI4tEyuJljtwADV2pq95PWytUnfsi+G+edJehr2FzRQt/Z1qdMZcJjYiqxHyxWLV8hDV5EwwqSKAAvwL2nsp64z53a+XCdU3IEE8= Received: from DM6PR06MB4329.namprd06.prod.outlook.com (20.176.108.74) by DM6PR06MB5962.namprd06.prod.outlook.com (20.179.163.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Sun, 3 Mar 2019 04:42:47 +0000 Received: from DM6PR06MB4329.namprd06.prod.outlook.com ([fe80::74cc:8a2f:72da:c52d]) by DM6PR06MB4329.namprd06.prod.outlook.com ([fe80::74cc:8a2f:72da:c52d%2]) with mapi id 15.20.1665.017; Sun, 3 Mar 2019 04:42:47 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" CC: "detnet-chairs@ietf.org" Thread-Topic: IETF 104 Prague - DetNet Meeting Slot Requests Thread-Index: AdTReQex1F+xgNmXSJqcMtZOU5wPyA== Date: Sun, 3 Mar 2019 04:42:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [73.162.193.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ad8ac8c-36b9-4f39-f010-08d69f92af10 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR06MB5962; x-ms-traffictypediagnostic: DM6PR06MB5962: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; DM6PR06MB5962; 23:m1h97noEXF6yxDVL3QZEJcwuNP21She0z7xDmFKUH?= =?us-ascii?Q?M3dcDozESJJbpTbzMnfECseGPjzEIvFM3vmoHOczKskQnSKyPlrU168XmTXN?= =?us-ascii?Q?7X4YIAvU30+NoF58cbfelspyBfKvUHYJRDxgl5tfq/qo81rddcDErOgvMtF3?= =?us-ascii?Q?QhGIHaSKPIvCUuM1hnXoo2l5uY191r/NzbxUP31YsTXScgHD6Sq9C6vZ3rwT?= =?us-ascii?Q?7S5D/M73dEcjMhTn+ryn/bMQ6EtB1BBnC34C6racPgmDBIjD1xBYAjomMLbr?= =?us-ascii?Q?m+gW2VV2SCFlF6Rlr2bW3/q6QJR+ien3Llf0+sFE+o+ydCSrUiYe2FzgJ99o?= =?us-ascii?Q?MwOUWhMcGmcr0VkB4fS4nqgI8oGv5dTpPmIc4FFZK/tgngvrx8OUQ6qCKvXG?= =?us-ascii?Q?e8ZVXR4YVcyrzIrlt7rt+o4UG8WpbNAyKDX0I3q14fjd8lUnVb4EDoiLIpML?= =?us-ascii?Q?LA+mqdt+W9ljCLGNBE8/K68nu0OuxaVboFwHc+JocWII1em03rptHe86NpPT?= =?us-ascii?Q?OpigdDfXQwQykWJMMAnu8S0bmcdN5UuEoRkmXSErklDSF3EeYcyfPuCOe0Yy?= =?us-ascii?Q?qU6SO/ms+seHI2Fa6igEqQUOBCdxeAMaQFu3kSm42cFHYNy9DqKSAbSs4WeA?= =?us-ascii?Q?jUz72sMMAY/iM2GxDAcWU5Aa+yy7HdOzRfWJUAXI4fYWdWEHCRCH9uF/3F4I?= =?us-ascii?Q?iNRlQC7Ga+k+lDj0Dj7L6N2hzAKxN9pbnWOxP/RYH4TJlZtwCoKoaWvtsHfg?= =?us-ascii?Q?TNKskjTH4SO9GzhBSdKPmvr7YYyX6FnQrfz6kUeIFsOLNwZ8YCJTDdKU9PDH?= =?us-ascii?Q?GfwdighXbiQcNhPsZ3FFJ2n0ny3bzT+QAOkMcZ4G0d2hG8y00Qz1QOadF5u5?= =?us-ascii?Q?2Kj22167VDw7Kr0kIhJTlkc/2xYJvVsqBEMuupiJLuEeuonOhkDOlEB4NWyG?= =?us-ascii?Q?/SLZBtCtuS81/Oxw1U5q+C0JMd+bxd6LZT/bwDyB0ZmlHoiF5V0WJ2x6wBu9?= =?us-ascii?Q?odNafkd+TrEz5eMAerdgaIgSgvfuKoNNmfb4ad0d3MLrAbsOfX7qJFHkwtwm?= =?us-ascii?Q?Lr0M645gWX9/mPXBCp75RmxaH7XbbxfSjRJJPwoLylJ7LfEYc0lXXbGwWLAf?= =?us-ascii?Q?9LWIL3ASgFJdTDwwmc+bhvgaIsHySLe4rubBTQuIpgp+OGKzJTtHmt/aUBQv?= =?us-ascii?Q?tPW0EdbPW24ggTwFKgGK+auyvrYhNQrZ8wnUaM9tovGidA8gc7WssoXn18NB?= =?us-ascii?Q?3IWB9YHVxZTQuWVp9pL6BPKB3V1XUT7gqF783lnNDDEtVen3YGQt833kMaW0?= =?us-ascii?Q?iwTPHAD0DGCmvY1spvHFS2FCAwbCURx0ZBH0GhgpBT1S7K3a17T5rRC35Yl7?= =?us-ascii?Q?6QmSZgBu6PZoICSvfY/jF/XqgwdMBmDm3Z6jHJvnRQi6BQK?= x-microsoft-antispam-prvs: x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(396003)(39850400004)(189003)(199004)(53754006)(54014002)(52536013)(2351001)(66066001)(5660300002)(106356001)(3846002)(105586002)(9686003)(54896002)(236005)(4744005)(5640700003)(53936002)(55016002)(6116002)(6436002)(6306002)(14444005)(256004)(790700001)(2501003)(86362001)(97736004)(606006)(14454004)(7696005)(478600001)(6506007)(450100002)(99286004)(966005)(186003)(2906002)(74316002)(8676002)(7736002)(8936002)(26005)(9326002)(68736007)(1730700003)(476003)(102836004)(33656002)(486006)(4326008)(25786009)(71190400001)(81156014)(71200400001)(316002)(6916009)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR06MB5962; H:DM6PR06MB4329.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cbNmwmXdr9AuUoe1mClxEFS5phdoky062H/gAqpJTYm8255k6K9buO6YMrYRdf1FQqsmxxR0lr3Lbt+xet1ljaRwaNw9syPWw2rB1c3SADPmaO3UPJMAAwpzQ0UPGoibHDLeO1gDkDXj4o7hb28QC6UTpVH1iz7kbTWb+UQk4cLAHnvjeRGUvxv/HC0bz0dxctP140+9vppKyaSn6IPkVLHWh3WfAQT1KsaMdsKlzhQkHunoHdEeuQS9jE8gPrLYSDqoTxurMjH08gHOHm3IGNJ/4cV0MDJvEN1epmXOIzKGeTDNlDsJ++Bc5mUihj2b8q/hmEZx6HuJuOjJk/5l4LfCE/x+e+FvZ3MVQ64YUowz0dsbLc6+8SmdFRCZf8xhu5L5vX/Ntic+X1FfwspjmSOm5GRfjIvEE4As61XsLig= Content-Type: multipart/alternative; boundary="_000_DM6PR06MB4329AA91ECBF98E88B8F35F3C4700DM6PR06MB4329namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ad8ac8c-36b9-4f39-f010-08d69f92af10 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2019 04:42:46.9007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5962 Archived-At: Subject: [Detnet] IETF 104 Prague - DetNet Meeting Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 04:42:53 -0000 --_000_DM6PR06MB4329AA91ECBF98E88B8F35F3C4700DM6PR06MB4329namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The IETF 104 Prague agenda has been posted: https://datatracker.ietf.org/meeting/104/agenda/ We're scheduled to meet: Wednesday, March 27, 2019 (CET) (+01) 9:00-11:00 Wednesday Morning session I, in Congress Hall 1 Please send any slot requests to the chairs email alias (see above) no late= r than Monday March 11, 5pm Pacific Daylight Time (-07). Please include dr= aft names(s), presenter and desired slot length. Please keep in mind that = priority for presentation slots is given to WG drafts and other drafts/topi= cs discussed on the mailing list. The cutoff date for draft submissions is also Monday March 11th, see https:= //datatracker.ietf.org/meeting/important-dates/ See you in Prague! Ethan (as DetNet WG Secretary). --_000_DM6PR06MB4329AA91ECBF98E88B8F35F3C4700DM6PR06MB4329namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The IETF 104 Prague agenda = has been posted:

 

https://datatracker.ietf.org/meeting/104/= agenda/

 

We're scheduled to meet:

Wednesday, March 27, 2019 (= CET) (+01)

9:00-11:00  Wednesday = Morning session I, in Congress Hall 1

 

Please send any slot reques= ts to the chairs email alias (see above) no later than Monday March 11= , 5pm Pacific Daylight Time (-07).  Please include draft names(s), presenter and desired slot length.  Please keep = in mind that priority for presentation slots is given to WG drafts and = ;other drafts/topics discussed on the mailing list.

 

The cutoff date for draft s= ubmissions is also Monday March 11th, see https://datatracker.ietf.org/meeting/important-dates/

 

See you in Prague!

Ethan (as DetNet WG Secreta= ry).

 

--_000_DM6PR06MB4329AA91ECBF98E88B8F35F3C4700DM6PR06MB4329namp_-- From nobody Sun Mar 3 18:46: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 E8476130EE4; Sun, 3 Mar 2019 18:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 flT6ZtdMiH1c; Sun, 3 Mar 2019 18:46:05 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780127.outbound.protection.outlook.com [40.107.78.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1BA130EDA; Sun, 3 Mar 2019 18:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9A+N1SwnfQ7+q5S38YzYFCbptAtVX0GtOh3E9yinqFE=; b=uqsIlnvYuh8aoJE30nw8hOW55c3vuHm0EEhjQW7EA/x8DEVDZjt704uEXi0zGGTCX7ygtyd8hZW+r23OKkbkil43OxVnViK7/sBC//tAMDse7rXw7Q/diAfaOPZ1zxj1Rr/0HIu/egAlnbhOTcv5b/Ru+Vs2tk8pZxvQabGGoIE= Received: from MN2PR01CA0029.prod.exchangelabs.com (2603:10b6:208:10c::42) by MN2PR01MB5616.prod.exchangelabs.com (2603:10b6:208:11c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Mon, 4 Mar 2019 02:46:02 +0000 Received: from BY2NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::200) by MN2PR01CA0029.outlook.office365.com (2603:10b6:208:10c::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.16 via Frontend Transport; Mon, 4 Mar 2019 02:46:02 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT023.mail.protection.outlook.com (10.152.84.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 4 Mar 2019 02:46:01 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x242jvcO004242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 Mar 2019 21:45:59 -0500 Date: Sun, 3 Mar 2019 20:45:57 -0600 From: Benjamin Kaduk To: "Grossman, Ethan A." CC: "draft-ietf-detnet-architecture@ietf.org" , "detnet@ietf.org" , The IESG , "detnet-chairs@ietf.org" Message-ID: <20190304024557.GK53396@kduck.mit.edu> References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@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: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(376002)(39860400002)(2980300002)(189003)(199004)(129404003)(13464003)(51444003)(229853002)(14444005)(5660300002)(30864003)(26005)(186003)(53546011)(76176011)(23756003)(104016004)(86362001)(6246003)(356004)(2870700001)(88552002)(55016002)(4326008)(6306002)(1076003)(7696005)(6916009)(305945005)(33656002)(478600001)(26826003)(8676002)(486006)(956004)(126002)(476003)(446003)(2906002)(106002)(54906003)(58126008)(336012)(426003)(8936002)(246002)(316002)(786003)(36906005)(93886005)(50466002)(966005)(11346002)(106466001)(53416004)(47776003)(75432002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR01MB5616; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bcf1663b-9915-4550-bb2a-08d6a04b8a20 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:MN2PR01MB5616; X-MS-TrafficTypeDiagnostic: MN2PR01MB5616: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; MN2PR01MB5616; 20:4DLnw61EfS/FdIdmuX9eHFCRLEOoYnJUgDnIgtfP+PYjG2URki0Chdy0+WgGMvnhgEXToUj1H/22nOMVsvsULrfwrdCN7nx2aqQP+3LLA8amandGz9WwL7s5tSJVstpkINOovC+p6fNoV1mo27NAUhI1abeNvGGarU5MxrHeSlpekaWKJJ8rGP+34/Bf/AAdncuwDpE0aiQFK98oIW6vbwes59lmTYlTL5CDFw8VEryeZn3x1cEn8uEeEvtKLYEKtW5jmvrzuIXYVeepoEPnIaGayOqYUUV42/fAThnz5XC8tGYA/O7u9ylBhH4nVNdCj/9IwH5GttZroFaCEm6CUoMATBeh7DfNI/b57jk3dkt+WVaZAeXExPXgjKQ948UvYLJ6Pxayhc9KHCmVeFpizP3YdJ7Zmf07FrbuKROKuGCPrP4YtWIgNFnAAoGVcClv/qyZEHln/X0DP/VJ0ZCEIGmEQ2nprHNis0rXl295YKeQdlWBeyjBV1Q1oi2OTRl3p7arZacuJPw6GAxhuhNUiNgE/uWdnu96uWOkH+UMSKsL8Sr12Qoa0c7+TqCoGtc2cJlXpUz09CBG2eQhHhl8CySHKuQUSjw+m56EEE8jfhs= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09669DB681 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MN2PR01MB5616; 23:9lucA/hJ/swkxwhCu90p9RCjsvGm+5uSQe1Lrj/?= =?iso-8859-1?Q?lxOcyGEX14frQOl3PjWV74jFlLcaI/vio+0pVshV5Ycf5M/MF1bvjBJVIZ?= =?iso-8859-1?Q?+Ec320qdcrXBEHfBE9FZE8CCr87o0pNJMfn/3zhHywQPR1f62M8qaquCm6?= =?iso-8859-1?Q?HRy4be+1W6dtUPHPEZCjlqk4zQzinewQxYCkicc1ju2OB37047B6pEKP0v?= =?iso-8859-1?Q?1D+9dIaHt7xFTrvaWxEsKOinicdGbE4zU9H8SzaiaoLYwvj9eNV+AxUPU1?= =?iso-8859-1?Q?so8HI4mbE453kB3KIRDInmQVBdPC49LjenO84JhReAI/aN8SsOZDRG1TUh?= =?iso-8859-1?Q?jdm9hVU0D+aDZ7gsdTeQSOcu5USEC/pRTbqWCAgtm4smD42y3yI56KE2wc?= =?iso-8859-1?Q?Oa+7gMjf6TeXRCDzmU+ffz0Xy+M7qe8ZMXAyf/eZlXe8e3I2bDGhiKfx3M?= =?iso-8859-1?Q?95mj2NdKOjmHoWsJt6EQEUpiAH88ZwIN2fpkscHFZ6bOUb48whrhfk+nrA?= =?iso-8859-1?Q?8c/bBeDg7eSWIN3BzuWPPs0AVd0nfFvS2t3Pen3mTYtt9+LqGAOjKqxZB+?= =?iso-8859-1?Q?gplajo90M6YPsRue9GwGyCbl2+LESQELzO695tg31IGIp8A8WdQ94KGtLk?= =?iso-8859-1?Q?3cfg7RnUfehXitphqSvGjpU9qg9jL1zhEgl9ffXZZl9GtLpIC9Lq20VJZV?= =?iso-8859-1?Q?mTFfWtGsxLZM8izs8fxVW65qySJaDHkQ0yGhGZTgEdzF2zCVsj5yK/UVH1?= =?iso-8859-1?Q?bQjZ1srBJa8FIyrMaTkR5hOBVhfUV7pm87QdusWZzYQhaztyW6F+g1eodU?= =?iso-8859-1?Q?+UG5xeiN7lII+QOF6zMsu4fQGCxjdWfmKH+h0i8Ny/HnZsLWa15wE00m9j?= =?iso-8859-1?Q?r1Aassjs6mpD/eJi30lP8B5zenMqmeg10kn+kjIuncI1xtudZAIS3mlzk0?= =?iso-8859-1?Q?Se2NAiwgadj+Dm/TwkK5f55I+IkFKi5I69LfrN685tVyQpl+Pc0iWdKru0?= =?iso-8859-1?Q?tJjjZbc5UHfw7YECNJ+CToXtxGaGEaS6K0yIuv+FXAwZQUpPvYpq5T4CNX?= =?iso-8859-1?Q?CsNvL93FJtqT1hiDReic/ypvhgVygHW0ouNmUnIv4lwcW/NRUdMfxj8LAX?= =?iso-8859-1?Q?0SaoZwixpDCltD3gWXrez+Lz2dcGAZvSmR+N+k5SY4wEWZ1nU9wBeoLi2/?= =?iso-8859-1?Q?q4RDySlTGulZcO/eYw8c40izQ5fKuzDJI90eBNpEuyFVGqDLK8CvVMuy4O?= =?iso-8859-1?Q?gS3qftxA9kRmmFPi4OwFn2dPLz0qKa3xGBvF5ArvWohrdcQry6ILUPFNx5?= =?iso-8859-1?Q?eDoubn7LbBMAOI2swnpRZQxJrMCxBXErqPcau4SLlwmFf15+5sFGfw4rXT?= =?iso-8859-1?Q?5kQNqbFpHJPeR3rz5K4cBoktHy3rY?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PsMzf8eoO98ZORl82LO09aAnehQ+ZdukSr1q/XddoNg9VhPuKOaa40ZFwWTfLac5L99ex0tZAcZkXPBAoOi+jnol7ShJzwlJx5LY0F/hOvl66sMPLjxYylwGwKTWnoixX+inDNkI7Xj7bDwTMuJ/b1rd+URh+a1GGzigdYefij6aJEYX0ZypFIp/2/0mSvwsuxMK+FKszqWZVbrNnfudvHls3OBF7YB6Bp4LHDyGDMHF9AEBW5hGn/8SF0uytJYhLUbQaEldH17OtgDqIiItZ2f5YBa6xAIddVIPnGxyHpT3+Rl1XYmk70f/xyHqk8RrvGTIVeSH6c7xxklXSKKL21xj3ke8Bwy1aeQz38v3fmCl3s150Ez0lnns0pcIY9LiOV3CUhUNxxDzB/fJMfIh2lNq+UfjZol0ZZYHFp3hnj8= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2019 02:46:01.5099 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bcf1663b-9915-4550-bb2a-08d6a04b8a20 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR01MB5616 Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 02:46:08 -0000 Hi Ethan, On Mon, Feb 25, 2019 at 06:31:16AM +0000, Grossman, Ethan A. wrote: > Hi Benjamin, > As editor and co-author of the DetNet Security draft, I thank you very much for your comments regarding the security aspects of the DetNet Architecture and Security draft. Indeed it is our intent to ensure that security is considered throughout the design process and not "bolted on" at the end; this is why we have been developing the Security draft in parallel with the Architecture, Data Plane and other drafts. Here are a couple of my initial thoughts on your comments; I present them for discussion, not as a defense of a pre-determined outcome. Understood. > I follow your concern that we have not made a distinction between the laundry list of possible threats versus those threats that designs based on the architecture must address in order to satisfy the security requirements of the architecture. Excellent point, in that I for one have not considered the topic in that light before, and I appreciate the need to do so now. > > Up until this point, i.e. prior to your comments, we have been working > based on at least two guiding principles. One is that we are only > addressing security considerations which are specific to time-sensitive, > routed, centrally-administered networks, so anything that could be > considered to be "covered elsewhere" we have intentionally omitted. For > example you cite "using HMAC for message integrity protection without > mention of infrastructure for distributing the keys for keying the HMAC"; > I would expect that this topic could be regarded as "covered elsewhere", > but please correct me if I'm missing something here. I think it's fine to say that DetNet only needs to provide solutions for addressing security considerations that are specific to these time-sensitive networks, but that doesn't necessarily mean that we can completely ignore the more mundane "generic" considerations. That is, we can and should still be aware of what security properties we expect of the traffic flowing through detnet installations, and choose the other technologies that are used to build solutions accordingly. As a complete example, not necessarily even relevant to detnet, we can say that if we want confidentiality protection for IP traffic, IPsec is an option, but we also would need to know that to actually use IPsec we'd either need to pull in IKE or have pre-established shared keys to use. Similarly for HMAC to provide integrity protection -- the underlying technology and its usage is well-understood, but comes with the caveat that the participants need some way to share the secret keys it uses. The idea is not necessarily to say that detnet must specify a single way of doing things, but rather to be clear about what it does (and does not!) require, and to have pointers for how a solution *could* be built using existing technologies, without requiring it to be done in that way. > Another main thread running through almost every aspect of DetNet is that as noted in the Use Cases draft, there are many and diverse applications for DetNet, spanning networks contained within a single machine all the way through networks spanning a nation. As such it is difficult to make generalizations about almost anything in DetNet - everything has to be framed as "scalable" so that we don't mandate something that makes sense for one use case but not for another. > > So the intent of the Security draft (in conjunction with security text in the other DetNet drafts) thus far has been to provide some insights into the aspects of security that are introduced with time-sensitivity to routed networks, with a nod as to how they might be addressed, while being almost completely non-prescriptive about it, leaving the details as an exercise for the reader based on their particular use case. > > In other words, as soon as we say "a DetNet must include [any specific security property]", someone will inevitably come up with a use case for which that didn't make sense (insufficient time, insufficient CPU cycles, not required in this case because blah, etc.) For example when I look at your questions like "Do we need to provide integrity protection for the marking, or confidentiality protection, too? Does authentication/integrity need to be provided for in-line or are out-of-band considerations in play?" my thought would be to say "well it depends on the use case, i.e. the specific implementation". In a similar vein to what I note above, I think that at the architectural level the questions we want to ask are things like "does the architecture need to support use cases where the deterministic traffic is given confidentiality protection by the network?" We don't need to require that it be used, and potentially not even require that every instantiation of the architecture have the ability to provide it (though for confidentiality protection in particular that will definitely be a discussion to have), but we establish it as something that we need to think about in the protocol design. The flip side of this, of course, is that we also have the ability to explicitly disclaim responsibility for some types of protection, and not have to worry about that in the protocol design, thus leaving any protections for that threat to be at a different layer. > So at this point I don't know whether this stance is valid, or whether it is an abdication of our responsibility, or whether there are some stakes in the ground that we can actually claim will fit all use cases, and thus we should be stating as mandatory. Certainly we would like to avoid the outcome that the architecture leaves open questions as to whether a given implementation satisfies its security requirements. We also want to avoid being overly prescriptive such that "exceptions" would need to be made to accommodate diverse use cases. At this point I'm not necessarily looking for hard security requirements, but rather a requirement for things that we include in the security analysis of the system. The answer may well be that (e.g.) it's hard to defend against an attacker that can delay packets, so all we can do is document the threat and move on; there could be other cases where a technical defense is possible, but expensive, so we can provide an optional mechanism and document the tradeoffs, so that individual use cases can make their own decisions. Hope this helps, Benjamin > Please let us know how this line of thinking affects your assessment of our situation, if at all. My short term goal here is to unblock publication of the Architecture draft, but not at the expense of adequate coverage and integration of security. > > Thanks again for your review, > Sincerely, > Ethan (as editor and co-author of the DetNet Security draft and the DetNet Use Cases draft). > > > -----Original Message----- > From: detnet On Behalf Of Lou Berger > Sent: Thursday, February 21, 2019 12:32 PM > To: Benjamin Kaduk > Cc: draft-ietf-detnet-architecture@ietf.org; detnet@ietf.org; The IESG ; detnet-chairs@ietf.org > Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) > > Hi Benjamin, > > On 2/20/2019 4:21 PM, Benjamin Kaduk wrote: > > Hi Lou, > > > > On Wed, Feb 20, 2019 at 11:34:11AM -0500, Lou Berger wrote: > >> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote: > >>> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote: > >>>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote: > >>>>> I note that the DETNET WG is explicitly chartered with a work item > >>>>> for the "overall architecture: This work encompasses ... and security aspects". > >>>>> It seems incomplete to specify an architecture for a topic such as > >>>>> deterministic networking without specifically considering what > >>>>> threats are and are not in scope to be protected against. > >>>> The working group certainly recognizes that security is an > >>>> important topic and necessary part of the work. The WG's approach > >>>> to ensure that this significant topic is sufficiently covered is to > >>>> have a document dedicated to the topic. As you note below this > >>>> work, draft-ietf-detnet-security, is not at the same level maturity > >>>> - so please stay tuned. Of course, the WG would welcome any input > >>>> on this security draft now or even a full early-review or security area advisor. > >>> I do appreciate that the WG has taken the time to work on a > >>> dedicated security document, that goes through the (tedious!) effort > >>> to tabulate the various known attacker capabilities, threats, and their interactions. > >>> > >>> What I think is missing from the high-level architecture document is > >>> a sense for what security goals the architecture intends to achieve. > >>> It's fine to have this be separate from the nitty-gritty stuff in > >>> the separate document, but these high-level questions can have an > >>> impact on the high-level design of the protocol ecosystem as a > >>> whole. We have mounds of examples of "come up with a design; bolt security on as an afterthought" > >>> working poorly or being nigh-impossible, and I haven't seen any > >>> attempt at justification for why doing so here is likely to be any different. > >>> Including the security concepts from the start and wholly > >>> integrating them into the system tends to produce a much more > >>> elegant design and smoother outcomes all around. > >> We went back and forth on how much of the security topic to include > >> in the architecture document and settled on the current text of > >> section 5 where just high level security requirements are identified. > >> From your list below, the architecture covers the points you raise > >> (non-detnet traffic impacting detnet traffic, and detnet traffic > >> trying to use more than its allocation) mainly from a service > >> delivery perspective. It does mention "shaping" as a security > >> concern, the document could expand these if helpful. But I think the > >> real discussion point is how much of the security details should be > >> in the base (vs dedicated) document -- and that you disagree with > >> where the WG has drawn the line. Is this correct? > > Well, it's not as much that I disagree about where the line is drawn, > > as that I disagree with the characterization as "high level security > > requirements". > > > > The first paragraph covers topics worth including here, certainly -- > > an attacker that can introduce delay can inherently break the DetNet > > guarantees, and there is no further defense. But the text could > > probably go further than its current version and explicitly call out > > that no technical measures can defend against such delay, other than > > by rerouting/avoiding the compromised position. > > > > The second paragraph also covers a topic worth noting, that entropy > > and Murphy as as important of risks to consider as active attacks. > > > > The rest of the section/list don't seem to match up with the > > high-level view, though -- "protection of the signaling protocol", but > > protection against what? Authentication and authorization are > > important parts of security, but authorization is tied to actions and > > entities, not just entities in vacuo. For "identification and shaping > > of DetNet flows", if security must cover them, what security > > properties are needed. Do we need to provide integrity protection for > > the marking, or confidentiality protection, too? Does > > authentication/integrity need to be provided for in-line or are out-of-band considerations in play? > > > > The rest of the document presents a good high level picture of what > > pieces will be involved in a system, and how they fit together. I'm > > hoping to see a high-level picture of what attacks/failures the > > architecture does and does not aim to protect against. It's somewhat > > implied that we need to protect against the failure of any single node > > or link (except at the > > boundary) due to random faults; explicitly saying this would be a > > perfect hting to include in the security considerations here! Once we > > get beyond entropy as an attack, into more active attack scenarios, > > though, we need to consider what capabilities an attacker might have. > > Do we protect against an entity with the ability to inject various > > forms of traffic? Modify or drop valid traffic? Are there any > > (classes of) credentials that we assume must be securely held, or will > > we attempt to protect against attackers that have some privilege > > within the system? (Note that misbehaving hardware can sometimes > > present as similar or identical to such an attacker.) > > > > Does this give a better picture of what I'm thinking of as "high-level > > security requirements"? I don't necessarily need details of specific > > hardware or credentials at play, and certainly not for the solutions, > > but I want to have a clear picture of what the scope of future > > security analysis will be. "How will I be able to tell if the actual > > protocols meet the security requirements of the architecture?" > > I'll get with authors (of both the architecture and security docs) and see how much they think can be reasonably be added to this document -- to be clear you *are* asking for a change in how the WG decide to address this topic and what would go in which document. > > Lou > > > -Benjamin > > > > _______________________________________________ > > 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 Sun Mar 3 19:25:42 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 B83F8130EFC; Sun, 3 Mar 2019 19:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 LvfmTynvH7Z8; Sun, 3 Mar 2019 19:25:31 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720095.outbound.protection.outlook.com [40.107.72.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46275130ED4; Sun, 3 Mar 2019 19:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRHzW2T5KSvfGZ+D1N2h5Evivod7JbNR+6ESLZYarzE=; b=xcmJmkFtu8KancPxi5mqEGO+TGVuC+HbQSOqRiOFpZefYE6g19WoJhNcdkcYRZ9h0svqtc+P8VzFkMEAvvqBwQKYS010wrONOwkW5AUvXv1qFv3QH4xsp54o4YNaUojmkh/dKfV3jZS0/HQ7FIDW9n8WG7dxYpnG98FKd4HpO0c= Received: from CY4PR01CA0017.prod.exchangelabs.com (2603:10b6:903:1f::27) by BYAPR01MB4853.prod.exchangelabs.com (2603:10b6:a03:91::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Mon, 4 Mar 2019 03:25:29 +0000 Received: from DM3NAM03FT054.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::202) by CY4PR01CA0017.outlook.office365.com (2603:10b6:903:1f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.16 via Frontend Transport; Mon, 4 Mar 2019 03:25:29 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT054.mail.protection.outlook.com (10.152.83.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 4 Mar 2019 03:25:28 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x243POsu014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 Mar 2019 22:25:26 -0500 Date: Sun, 3 Mar 2019 21:25:24 -0600 From: Benjamin Kaduk To: =?iso-8859-1?Q?J=E1nos?= Farkas CC: Lou Berger , , , The IESG , Message-ID: <20190304032524.GM53396@kduck.mit.edu> References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@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: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(136003)(396003)(2980300002)(51914003)(189003)(199004)(75432002)(305945005)(106466001)(966005)(6246003)(246002)(50466002)(26005)(4326008)(33656002)(6306002)(55016002)(14444005)(86362001)(54906003)(126002)(53546011)(486006)(476003)(106002)(356004)(229853002)(6916009)(36906005)(786003)(58126008)(53416004)(316002)(336012)(76176011)(104016004)(7696005)(446003)(11346002)(23756003)(956004)(186003)(8936002)(426003)(30864003)(2906002)(66574012)(478600001)(2870700001)(1076003)(88552002)(26826003)(93886005)(8676002)(5660300002)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB4853; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 135d31a7-a22b-4732-9d6f-08d6a0510d11 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BYAPR01MB4853; X-MS-TrafficTypeDiagnostic: BYAPR01MB4853: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB4853; 20:A4Bpr2yWCSiXGnlWbjoBbZIJMKUU1zJrUcLPEKvtqlWbm92kkyd/Z4ssaS2HHau8iA2Qz6mB4O7gAROMxTbErf6CYfuatBRMnsbcv+Am1xdH49/5vHbilSnGHPGV0qr1+1E/e5nT1/CFazN7pexzwVho0GChTpT6vO0ADGlZOhVdIJ6EeaKvgj6pKclvrDKhH1yvpRg64jYZONm0cZ80/bcAuQ66Hcz49gLHCupVbl2qv0lXe6GRcGnz090HsH1yzam4+LQc0kylULDsqsp0T6o/TuCssPTk4LD0TK1jWtJ/a1RN/3+nsFjWXy8anISlSBd88ZN0q/2J0RU4VSrvDWlBhmIBvdrLBY7x2rfB7V3zMGjhU0Rj+e8NfrHEjGIQ2Yfpos7ZGh/7oWx6OsrQ4fl/4qOnIr9DfuWBiUbLrhQ50esN+kGGp6tiiSW/TKlXSWc6dIlfFP0q+tJj7rTaN4rReYU5Dr66SX87ucpCWHy9NlxtgAqokuN8ToBXEsIc35xHznycVjiAelXZJ0RoChNbBMZO3E3oH3dBJw2R34PF+rBwmN4l1m2FXLXQkc7t4jxJBqTM0o+qaUvXxq1EAnM/ePCCQQzEAhpOY6HJ9d0= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09669DB681 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BYAPR01MB4853; 23:frSraWyzkSvD3wMVb3269igno8zTAQSbRDA2J7O?= =?iso-8859-1?Q?zHIVt++U8Bcx7PRNqFev2S5mAPA9noMkgiEsisqIt//0eohKoWrgZhXFlr?= =?iso-8859-1?Q?LihA8Xix1aAV0oMIYBHtLJz6+f8t8dxJ60V3Ud8NL4Isuj/hO7js8aWe8p?= =?iso-8859-1?Q?BHEYtPjVeG2YmxdMMZ4aSXUvzfNQaBSIP7a+PkMyUoDcUY0A5OGzaZMJsH?= =?iso-8859-1?Q?QYm4mpqLbWBLt42kTxtB/LJOkgW6Z2RAnQh0hVGIv3QrRgr5Tf08Zqfgh2?= =?iso-8859-1?Q?FWBNx7Fx86rYkGLX+X/M+f4cZtkNN4PSXJxDvA2RIWRzO5xs7SpkFJEIo9?= =?iso-8859-1?Q?4v48D6Egvi1SkIELW3f6X/5an13OaclPhzBK6FpZBy45uAMmgn+qlGUiGu?= =?iso-8859-1?Q?ztmWJzS9zYTEeRIFiAxSEViR/pg6FD4wOzCxrpbAuuA48G243V1cL6dtdH?= =?iso-8859-1?Q?w2wRTs++1DXXrmKeoURygUZk1CJZzWgGcGVQzMOfZwOyxuZhPhqupuesjt?= =?iso-8859-1?Q?RbqeprotTrAe8ruyXrDQwrOpjXFsWRJNtqjXreSrd7NEMWPDc8ddNnX1aF?= =?iso-8859-1?Q?ex6GxGTeA0uXVR+QdVu1uN85+QriSjNr3gQD0zNn6oqewllalK1I92idDA?= =?iso-8859-1?Q?1P861lOOEe1Y9MlBuFdx0t5u6VDAOlf9B1Sso6nvuuNLlzKIn+c2CYyrf1?= =?iso-8859-1?Q?Q7yhq++EyuQ4Eej++ERYPmO0Uq2Pec2LtQy7g8gqArHaZeGvduNBe6vDN7?= =?iso-8859-1?Q?89I7MH64uSUUmUJobHeBHNGTc1IQ2zi0cGsJHJLY5z7g2KP0d4l9dvfgSM?= =?iso-8859-1?Q?qI8q08OJ+j2UkJQMl5wEshJ5oiFhqXZerOim8UR/Ciq1Wf9dRbCGnNwiLb?= =?iso-8859-1?Q?aFSrNaFSge7ipT2Ne6i7hDEMlI7m3s+jeeuj/fJfrEj8QsqPzIuutVcAzR?= =?iso-8859-1?Q?n7CZ0OcXil2lndTUoYKfrW6znJCF7T3qE28dD+LpG7cC5BXeiit/l5hCs4?= =?iso-8859-1?Q?rcM5wVyv9vW+F4zCkOl1M8ws/ORNYVJqW1fHClsom2eSJhTqdnATL3vqEM?= =?iso-8859-1?Q?qoLqEi2nHT3/OrfFAw27YxRPYfIRz7JRoOAfFq6bU7rcvJLEjibLdFakjc?= =?iso-8859-1?Q?TawqvZAGltHSeRb/XQwM+FfVTm2ciElMU8zP7uaLqcekRNAi0JiBLw06m7?= =?iso-8859-1?Q?dDFLg7QZLP2/u4NXh1cSyh9AOfh/jqdVo3F9FyOQ0S2RBN68coBC8jv7dl?= =?iso-8859-1?Q?vs0G/IXNSg+KA3b2dv7o92cz2f6fwh2TjpBnG+xnbn/3chpuLAJ/0m77fu?= =?iso-8859-1?Q?4fg2bGqXadIbLjdvOTStwBoB1Sm+zoR9Mzp0d/iZAGIfWHTv4Tm9WGo04j?= =?iso-8859-1?Q?jPqQnnU8=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: GpHaSPphbnd23h2jJeax4PDIhmVVBY4tMHUVkKlDx5pBBPXPCoy2fikp9E39pXLWqSFe59sQY7zJD/VakHYs1Ed7nvw50MZftGeD9rteU038aKR9dpPAq7Ho1JsE8SfYjhuSNoDVG5DhU02Mmpnr0a633IgzaGW8fb9Dvkgb5LjK46pBb4Umxmm2w2W6zvSFKDSfd3eT7SVVv96xl8AxbKDPUsx1ja7qAcIeLWLAa+4NWq89aPXQo29JTQzK2US3BFzlPuLlld//n6hIuf+53r7thgeEdUSlwG7Zulp8i90XnEcd+0cJmzR0ZTeQ0YJ8wJ72GYM922huAr3Q4q6BLVt9/+wX8oGpfn2Mq+KHLjOBiNjxPgg5XuaMf4IZQwuOZcbyJO4oKIr+55LTOh8FWnvp9vrlUugy5/G6bxG6IqQ= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2019 03:25:28.7243 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 135d31a7-a22b-4732-9d6f-08d6a0510d11 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB4853 Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 03:25:34 -0000 Hi Jnos, Thanks for the new text. These are some great things to be thinking about, but I'm a little worried that it's just specifying mechanism without describing the motiviations; in fact, it may even be more detailed than we need for this document. More inline... On Sat, Mar 02, 2019 at 07:22:15PM +0100, Jnos Farkas wrote: > Hi Benjamin, > > Thank you for your review! > > Focusing on the main point now: Section 5 Security Considerations. We > could consolidate the section to address your comment. Would it be > helpful to replace the section with the following text?: > > > Security considerations for DetNet are described in detail in > [I-D.ietf-detnet-security]. This section considers exclusively security > considerations which are specific to the DetNet Architecture. > > Security aspects which are unique to DetNet are those whose aim is to > secure the specific quality of service aspects of DetNet, which are > primarily to deliver data flows with extremely low packet loss rates and > bounded end-to-end delivery latency. A DetNet is implemented using MPLS > and IP (including both v4 and v6) technologies, and thus inherits the > security properties of those technologies at both the control plane and > the data plane. > > Security considerations for DetNet are constrained (compared to, for > example, the open Internet) because DetNet is defined to operate only > within a single administrative domain (see Section 1). The primary > considerations are to secure the request and control of DetNet > resources, maintain confidentiality of data traversing the DetNet, and > provide uninterrupted availability of the DetNet quality of service. "secure" (verb) can mean many different things in different contexts. So when we want to "secure" the request and control of resources, that would presumably be something like denying unauthorized entities the ability to use the resources, and probably also to limit the consumption of any given entity. This probably also means that the ability of resources external to DetNet to disrupt the DetNet resources should be limited in some fashion, but the exact details are still unclear to me. Similarly, the "uninterrupted availability" is not without qualifications: an EMP or nuclear blast may not be something in the threat model that we need to defend against. But if we just say "uninterrupted availability", the reader has no way to know that. To be clear, I'm not saying that this introductory text has to change, but if we keep it, the follow-on paragraphs need to provide the motivation/reasoning that is missing here. > To secure the request and control of DetNet resources, authentication > and authorization must be provided for each device connected to a DetNet > domain, most importantly to network controller devices. Control of a We require authn/authz because there is/are some risk(s) that we are trying to protect against. What is/are that risk? > DetNet network may be centralized or distributed (within a single > administrative domain). In the case of centralized control, precedent > for security considerations as defined for ACTN can be found in RFC8453, > Section 9. In the case of a distributed control protocols, DetNet > security is expected to be provided by the security properties of the > protocols in use. In any case, the result must be that manipulation of > administratively configurable parameters is limited to authorized entities. Deferring on control protocol security is a fine thing to do. > To maintain confidentiality of data traversing the DetNet, application > flows must be protected through whatever means is provided by the > underlying technology. For example, encryption may be used, such as that > provided by IPSec for IP (Layer 3) flows and by MACSec for Ethernet > (Layer 2) flows. DetNet flows are identified on a per-flow basis, which (I wouldn't care whether the "For example" sentence is present or not; we aren't necessarily obligated to provide it.) > may provide attackers with additional information about the data flows > (when compared to networks that do not include per-flow identification); > this is an inherent property of DetNet which has security implications > which must be considered when determining if DetNet is a suitable > technology for any given use case. Similar consideration may need to be > given to the use of replicated packet flows, which result in increased > surface for Reconnaissance attacks. In any case, the result must be that > the confidentiality of the data is maintained to a degree sufficient for > the use cases addressed by the given DetNet implementation. I could consider putting this in a new paragraph. I'd also consider trimming it down: the key point at this level is that detnet provides a new type of information on packets that can be used by an attacker in the network looking at metadata. The specific details of that could be shunted off to the other document with no real harm. > To provide uninterrupted availability of the DetNet quality of service, > provisions must be made against DOS attacks and delay attacks. To > protect against DOS attacks, excess traffic due to malicious or > malfunctioning devices must be prevented or mitigated, for example > through the use of traffic admission control applied at the input of a > DetNet domain, as described in Section 3.2.1.1, and through the fault > mitigation methods described in Section 3.3.2. This is getting closer to the sort of thing I was looking for -- we need to provide availability *in the face of DOS attacks and delay attacks*. We could probably say more about where the boundary is between "external" entities that could threaten DOS and "internal" entities that we assume behave properly -- is it the boundary of the DetNet domain, or will we consider the risk of misbehaving/compromised equipment in the domain? > To prevent DetNet packets from being delayed, protection must be > provided against Man-In-The-Middle attacks, for example through use of > authentication and authorization of devices within the DetNet domain. (nit: maybe join this into the previous paragraph, since that paragraph's topic sentence also mentions delay) This is also pretty close to what I hoped for: it implies that we need to keep the traffic inside our trusted elements (by avoiding the MITM), since the MITM is untrusted and could introduce delay, but the internal elements are trusted to not delay. So this could be "prevent DetNet packets from being delayed by external network entities", which implicitly disclaims an attempt to protect against a compromised DetNet router. > Time synchronization methods are not specified by DetNet, however any > time synchronization method used with DetNet must also be secured, using > the security methods available for the given time synchronization > mechanism, for example as described in [RFC7384]. > In any case, the result must be that the DetNet is protected from DOS, > delay, and time manipulation attacks to the extent sufficient for the > use cases addressed by the given DetNet implementation. I'd consider rephrasing this more like "Because DetNet mechanisms can make heavy use of methods that require precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC7384]." We may not need the rest of the details in this document. > DetNet use cases are known to have widely divergent security > requirements. The intent of this section is to provide a baseline for > security considerations which are common to all DetNet designs and > implementations, without burdening individual designs with specifics of > security infrastructure which may not be germane to the given use case. > Designers and Implementers of DetNet systems are expected to take use > case specific considerations into account in their DetNet designs and > implementations. This is good. -Benjamin > > Regards, > Janos > > > > On 2/21/2019 9:32 PM, Lou Berger wrote: > > Hi Benjamin, > > > > On 2/20/2019 4:21 PM, Benjamin Kaduk wrote: > >> Hi Lou, > >> > >> On Wed, Feb 20, 2019 at 11:34:11AM -0500, Lou Berger wrote: > >>> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote: > >>>> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote: > >>>>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote: > >>>>>> I note that the DETNET WG is explicitly chartered with a work > >>>>>> item for the > >>>>>> "overall architecture: This work encompasses ... and security > >>>>>> aspects". > >>>>>> It seems incomplete to specify an architecture for a topic such as > >>>>>> deterministic networking without specifically considering what > >>>>>> threats are > >>>>>> and are not in scope to be protected against. > >>>>> The working group certainly recognizes that security is an important > >>>>> topic and necessary part of the work. The WG's approach to ensure > >>>>> that > >>>>> this significant topic is sufficiently covered is to have a document > >>>>> dedicated to the topic. As you note below this work, > >>>>> draft-ietf-detnet-security, is not at the same level maturity - so > >>>>> please stay tuned. Of course, the WG would welcome any input on this > >>>>> security draft now or even a full early-review or security area > >>>>> advisor. > >>>> I do appreciate that the WG has taken the time to work on a dedicated > >>>> security document, that goes through the (tedious!) effort to > >>>> tabulate the > >>>> various known attacker capabilities, threats, and their interactions. > >>>> > >>>> What I think is missing from the high-level architecture document is a > >>>> sense for what security goals the architecture intends to achieve. > >>>> It's > >>>> fine to have this be separate from the nitty-gritty stuff in the > >>>> separate > >>>> document, but these high-level questions can have an impact on the > >>>> high-level design of the protocol ecosystem as a whole. We have > >>>> mounds of > >>>> examples of "come up with a design; bolt security on as an > >>>> afterthought" > >>>> working poorly or being nigh-impossible, and I haven't seen any > >>>> attempt at > >>>> justification for why doing so here is likely to be any different. > >>>> Including the security concepts from the start and wholly > >>>> integrating them > >>>> into the system tends to produce a much more elegant design and > >>>> smoother > >>>> outcomes all around. > >>> We went back and forth on how much of the security topic to include in > >>> the architecture document and settled on the current text of section 5 > >>> where just high level security requirements are identified. From your > >>> list below, the architecture covers the points you raise (non-detnet > >>> traffic impacting detnet traffic, and detnet traffic trying to use more > >>> than its allocation) mainly from a service delivery perspective. It > >>> does mention "shaping" as a security concern, the document could expand > >>> these if helpful. But I think the real discussion point is how much of > >>> the security details should be in the base (vs dedicated) document -- > >>> and that you disagree with where the WG has drawn the line. Is this > >>> correct? > >> Well, it's not as much that I disagree about where the line is drawn, as > >> that I disagree with the characterization as "high level security > >> requirements". > >> > >> The first paragraph covers topics worth including here, certainly -- an > >> attacker that can introduce delay can inherently break the DetNet > >> guarantees, and there is no further defense. But the text could > >> probably > >> go further than its current version and explicitly call out that no > >> technical measures can defend against such delay, other than by > >> rerouting/avoiding the compromised position. > >> > >> The second paragraph also covers a topic worth noting, that entropy and > >> Murphy as as important of risks to consider as active attacks. > >> > >> The rest of the section/list don't seem to match up with the high-level > >> view, though -- "protection of the signaling protocol", but protection > >> against what? Authentication and authorization are important parts of > >> security, but authorization is tied to actions and entities, not just > >> entities in vacuo. For "identification and shaping of DetNet flows", if > >> security must cover them, what security properties are needed. Do we > >> need > >> to provide integrity protection for the marking, or confidentiality > >> protection, too? Does authentication/integrity need to be provided for > >> in-line or are out-of-band considerations in play? > >> > >> The rest of the document presents a good high level picture of what > >> pieces > >> will be involved in a system, and how they fit together. I'm hoping > >> to see > >> a high-level picture of what attacks/failures the architecture does and > >> does not aim to protect against. It's somewhat implied that we need to > >> protect against the failure of any single node or link (except at the > >> boundary) due to random faults; explicitly saying this would be a > >> perfect > >> hting to include in the security considerations here! Once we get > >> beyond > >> entropy as an attack, into more active attack scenarios, though, we > >> need to > >> consider what capabilities an attacker might have. Do we protect > >> against > >> an entity with the ability to inject various forms of traffic? Modify or > >> drop valid traffic? Are there any (classes of) credentials that we > >> assume > >> must be securely held, or will we attempt to protect against > >> attackers that > >> have some privilege within the system? (Note that misbehaving > >> hardware can > >> sometimes present as similar or identical to such an attacker.) > >> > >> Does this give a better picture of what I'm thinking of as "high-level > >> security requirements"? I don't necessarily need details of specific > >> hardware or credentials at play, and certainly not for the solutions, > >> but I > >> want to have a clear picture of what the scope of future security > >> analysis > >> will be. "How will I be able to tell if the actual protocols meet the > >> security requirements of the architecture?" > > > > I'll get with authors (of both the architecture and security docs) and > > see how much they think can be reasonably be added to this document -- > > to be clear you *are* asking for a change in how the WG decide to > > address this topic and what would go in which document. > > > > Lou > > > >> -Benjamin > >> > >> _______________________________________________ > >> 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 Sun Mar 3 19:41: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 47C51130F41; Sun, 3 Mar 2019 19:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 8wXCkd7oxhsf; Sun, 3 Mar 2019 19:41:39 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790129.outbound.protection.outlook.com [40.107.79.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB57130F40; Sun, 3 Mar 2019 19:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OCyfYOyuqQ964kvEx+QCHXGlgqOZyjUm7nJjTSzbxLQ=; b=AENWIA8RfXSb75CAo8ZYKp4pW7/TDjG/y1VOLdLkK78qlLeqw/cTkWrxmeGVoMEkCXB8JCsyrnvnm9wC4RQ6JU2U8AjDKM6KKuf4zgWVDxzLKwkPvAbJ9ZscaWwF8FkFKUod+TzsIiHDIc/oZ+78SfKnQADsYuZsQdFXICfXJBs= Received: from SN6PR0102CA0033.prod.exchangelabs.com (2603:10b6:805:1::46) by BN6PR01MB3282.prod.exchangelabs.com (2603:10b6:404:d3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Mon, 4 Mar 2019 03:41:37 +0000 Received: from BY2NAM03FT003.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::207) by SN6PR0102CA0033.outlook.office365.com (2603:10b6:805:1::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.16 via Frontend Transport; Mon, 4 Mar 2019 03:41:36 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT003.mail.protection.outlook.com (10.152.84.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 4 Mar 2019 03:41:35 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x243fWGK018367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 3 Mar 2019 22:41:34 -0500 Date: Sun, 3 Mar 2019 21:41:31 -0600 From: Benjamin Kaduk To: =?iso-8859-1?Q?J=E1nos?= Farkas CC: The IESG , , Lou Berger , , DetNet WG Message-ID: <20190304034131.GN53396@kduck.mit.edu> References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <1cd55c7d-6d1c-b56f-38d3-d6bd78b004e2@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1cd55c7d-6d1c-b56f-38d3-d6bd78b004e2@ericsson.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(39860400002)(136003)(396003)(2980300002)(199004)(189003)(75432002)(6306002)(2906002)(104016004)(58126008)(316002)(786003)(55016002)(446003)(47776003)(305945005)(14444005)(26005)(6666004)(5660300002)(7696005)(8936002)(23756003)(30864003)(76176011)(50466002)(356004)(26826003)(36906005)(106002)(106466001)(54906003)(478600001)(126002)(246002)(53546011)(6916009)(966005)(486006)(229853002)(33656002)(6246003)(476003)(53416004)(8676002)(186003)(1076003)(86362001)(4326008)(66574012)(11346002)(2870700001)(88552002)(426003)(336012)(956004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR01MB3282; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 008f7bf3-5348-4c93-ebdb-08d6a0534d94 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BN6PR01MB3282; X-MS-TrafficTypeDiagnostic: BN6PR01MB3282: X-MS-Exchange-PUrlCount: 3 X-Microsoft-Exchange-Diagnostics: 1; BN6PR01MB3282; 20:OhKDhbxU2iFNDP28AS5zGH1VnUqk+ALyxMIvSnyaNnOWYyrn3qGfoXt5FQw0rkyDfoI2PX7eWYaCynw/LJgRWXQWSBW5VHE3218G+koDfqEeqBVb/mgssHn81oezie/WZnpZL4LQBnWgY95p4jOP+iEcpZvRZgkCO3x7xjqBTxbiL1XBf4U3bUQ9Sef2lGiET6VCBgGMy+/Fz3VmTiTXhYxdORHWHKa68eDaychCGaq/V+Uf9qJjnXSLomUG+rkpO9fUyZf5LiEYWbzLU9RnSfHXOHgHGrUbvAZ8bzq6pKFbeFWI+a1p0Jwve3zm5NqtkhKMIwq/qWB7s52csZk8CETxb6NceaDaPEuSt3Q3tOTH5ZvxTefcqAvRlkJvfeRyCMmXOFa58CQrfa5v4mWpUwOyBNLDr1joPzfdGP02aqLTadfJC/mxjVsQEsbWWGUREHJQjEUSvmKZrUQGQrEaNweRzeoyRRJFOlM3vRMq9Jj7rC8NYW/BJliTa7GwDroEc4o2Isv3jL8Eh0hEe3M4jcoV884ZPbMJHwmerBuYkWGNVG5MepsJBIFYnaOd2OsPX939oaUUMEHiX4nP6id1yJzZ35tql7Sgf6OWo9CxB6I= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09669DB681 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN6PR01MB3282; 23:rLIyXTCbB031UxIwy+cldwNZJEEYsKwBuZKN+CS?= =?iso-8859-1?Q?chK4TAaZfDCwYjRYMYd6W2gdQgWQThOaEU3RJ3UNitnPVrX4WQONHHuAdL?= =?iso-8859-1?Q?AEVaDxIStmDMWC0sDKjTkEBzFpjQvNaDHXTgWYgFj8tn9R/GMc0ifLUpQb?= =?iso-8859-1?Q?6401l+UblAZJcj0yeiMgHppj5E07n7ILguvAksxNe+3PURrt58O4g1qL7c?= =?iso-8859-1?Q?1ujpjzdYDXVZAJgiVCQoNnJnug80au3GKfvz2lCrPYgmPZ2KCf8aOsJanZ?= =?iso-8859-1?Q?Z6dAzOOf9zIgB+izl4FfLUpbLIv+4Ukf5DJ2q36bBLlgLDMidRFg/zcM7I?= =?iso-8859-1?Q?nCod4baDv1UsAsKC5WenYbp+srHfNTp5iLR114fvvJKVIRCQpvD7nBKF1K?= =?iso-8859-1?Q?JsEB8q+wU/iyKFPCbg7t7l8ZX5JKTiC+/DBMDqdZCzupJ+7cONMw5F9PhQ?= =?iso-8859-1?Q?ioXG2Mna4XuazTOl8fNGUhNHg75JSy/YWpgieDsotQVTfWfZqkrwoYKIGA?= =?iso-8859-1?Q?E5XtPCnprfOzLeX9Ex3iFt7EmmnZulnH6lh6wAK/AnjkkVcCL/8TvwaMMf?= =?iso-8859-1?Q?tdluXTSctipYp129eg8Aji6PMZ2seDPrS3OIA2wg2gM6NYvIl96rIFXtgr?= =?iso-8859-1?Q?jpKlsZALjlCTswTD+quBI5n0A0R41gXY2zk6+Vdm3IBHzsxagBBP3znoYe?= =?iso-8859-1?Q?WzSqos2pWuW+nZJtyMRSTQ69FMi8CmnKvi0PLF9VoIvy6xNqVS3n1oNb1O?= =?iso-8859-1?Q?7JlPAqisl9gHaxggxTRvO2i6MkLV2KjTRnd2GZlth6CRqRBKBQY44zAYwi?= =?iso-8859-1?Q?DtP2pm/LJyNA0X2vfJvSgRdta52xeqmYPQmopgKOrnmlMdocLReofgVWsO?= =?iso-8859-1?Q?SsYSoc/upVQyZlTNk2hJFRC1v6b0SNWB3zojvRwihq92sGHV81fYqRNmuW?= =?iso-8859-1?Q?IMLPI8DFWL8MPIZT2loD2n331GCmilxvUZi95TKmRL6X+pA6EbRYaMigVl?= =?iso-8859-1?Q?+c77VSC80dFygExBE9vspK+lWLS68uqO/E8l+k1Y9UYfygbgLuY16xWFgP?= =?iso-8859-1?Q?VPQI6X8fKoReV9IYzBhg9VTJDRHgHZ7PLeIV8773TwbDDr6JAIoc2HNmbd?= =?iso-8859-1?Q?eI6cawzKha2cHIciyqDYVKa2Asahh8lzFTYwwBjogs68hJS9wN7tNq2+8P?= =?iso-8859-1?Q?hzf42ATVoJr1Ykc9UyyY1U/s9TJ2HjabEnEAAOFaBzeF0Yw3xFeJ06vtNQ?= =?iso-8859-1?Q?8Z/ZMdKqzLNwn61kaSp2AVLmbh0JbdS51LkQouutUPM3HBb9YHy69lQkwf?= =?iso-8859-1?Q?MP2NVqeBOD5vDRc3jhn9RlYcXy83subpXy4Z19oykQqgNKLr6Yop+4mmW6?= =?iso-8859-1?Q?zktYbxSczl1GUkw+7rVYwPV+aY1fa+bWQFZFow7xOEd07Fi5TexuVf20/J?= =?iso-8859-1?Q?OUCI+E4I6dGQOk=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: U6p+UYQh487vPIWdzbg0sP/TSdgPVrg7qgSXzxTmC1f1Sks/gwe+UEXkSjdVIvcGfOMNV4tgX3jCx1jMTaCkwU3PfZWgPu76swBlDA0E1gbg7dlnN0qwxf47zKQTHcexHdP9XTXR+IgkMry0uvDdlnIGK82HkaGG+ImEmWHS3xb/oab32ybsUpYyJv6CiDM1p7dYXcSD3PGxIR2qYZ5kbUOy8kvy0qud1vsZ/0wVD6ZhCmYmXQkQkwTGq0tHQ0d9OjdV1MvEgRxv3sSiFQXp0JTLoyWFkHFsz4UDOV75w/tcknjkjgbKzev9JiGGcFDNeoL0jhrG2IY7HNQ5GmUhDImRhpgGmxkv/b49h7zhCW5+rP2g63Wy+7OsuP2lTeYlnv8oZIEc6jEjuIJmvla8nMkNz5NH55M/MDjUYNbuNLo= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2019 03:41:35.9055 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 008f7bf3-5348-4c93-ebdb-08d6a0534d94 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR01MB3282 Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 03:41:42 -0000 On Sat, Mar 02, 2019 at 09:12:23PM +0100, Jnos Farkas wrote: > Hi Benjamin, > > Coming to your detailed comments. > Please see in-line. > > Thank you, > Janos > > > On 2/20/2019 4:44 AM, Benjamin Kaduk wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > > > Abstract > > > > DetNet operates at the IP layer and > > delivers service over sub-network technologies such as MPLS and IEEE > > 802.1 Time-Sensitive Networking (TSN). > > > > I don't know what "sub-network technologies" means. (Should I? Is it > > defined somewhere we can reference?) > > > > More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network" > > that lies between specific layers or classes of layer? Does DetNet > > itself have component "sub-layers" that provide distinct DetNet > > functionality? These are good questions to address early on in the > > document so the reader is familiar with the concepts as they progress > > through the document. > Please note that the WG has reached consensus on introducing the term > "sub-layer", in particular using the terms "DetNet Service sub-layer" > and DetNet Forwarding sub-layer", see: > https://mailarchive.ietf.org/arch/msg/detnet/TR6oXu7IMWhelrH_I-tOuHGfDqo. > These are explained in detail in Section 4. DetNet Architecture. I do > not see how to bring it earlier in the document. That's a fair point. I guess I would consider adding a Terminology entry for "Sub-layer" that notes that "The DetNet architecture divides the DetNet functionality into two sub-layers, the forwarding sub-layer and the service sub-layer.", but use your judgement. > Section 4. DetNet Architecture also explains what is meant by > sub-network. Figure 3 shows it and the text above Figure 3 explains. > I don't see how could be this explanation earlier in the document. > > As for the abstract, would it help to replace?: > > OLD: > DetNet operates at the IP layer and > delivers service over sub-network technologies such as MPLS and IEEE > 802.1 Time-Sensitive Networking (TSN). > > with > > NEW: > DetNet operates at the IP layer and > delivers service over lower layer technologies such as MPLS and IEEE > 802.1 Time-Sensitive Networking (TSN). > > Similar replacement could be done in the introduction: > > OLD: > DetNet operates at the IP layer and delivers service over sub-network > technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking > (TSN). > > NEW: > DetNet operates at the IP layer and delivers service over lower layer > technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking > (TSN). > > > The next occurrence of sub-network is with a cross-reference to the > section with Figure 3 and description. I think it is fine this way as > the reader can jump there and check the details. I agree; these two replacements in abstract+introduction would alleviate the main question of whether this usage is some existing well-known thing that the reader should be familiar with, and the rest of the document is well-contained. > > > > > Section 1 > > > > 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. > > > > side note: Campus-wide networks at educational institutions are basically > > guaranteed to have untrusted entities participating in them, just as a > > backdrop for security considerations. > > > > Section 3.1 > > > > This mechanism distributes the contents of > > DetNet flows over multiple paths in time and/or space, so that the > > loss of some of the paths does need not cause the loss of any > > > > The failure models for which this statement is absolutely true as opposed > > to probabilistically true seem rather unrealistic models of real physical > > systems. > > > > Section 3.2.1.1 > > > > The primary means by which DetNet achieves its QoS assurances is to > > reduce, or even completely eliminate packet loss due to output packet > > contention within a DetNet node as a cause of packet loss. [...] > > > > editing error? > > > > Note that App-flows are generally > > not expected to be responsive to implicit [RFC2914] or explicit > > congestion notification [RFC3168]. > > > > I note that the word "implicit" does not appear in RFC 2914; it may be > > worth a bit more detailed of a mapping from concept to reference. > > (This text/reference also appears in Section 4.3.2.) > Would it help to change the text?: > > OLD: > There is no expectation in DetNet for App-flows to be responsive to > implicit [RFC2914] or explicit congestion notification [RFC3168]. > > NEW: > There is no expectation in DetNet for App-flows to be responsive to > congestion control [RFC2914] or explicit congestion notification > [RFC3168]. Sure, thanks. > > > > > Section 3.2.1.2 > > > > In > > general, users are encouraged to use, instead of, "do this when you > > get the packet," a combination of: > > > > It seems that an architecture would be within its rights to *mandate* such > > application design, rather than just encourage it. What sorts of > > exceptions would cause us to not want to mandate this design? > This is not mandatory. > For instance, it is not mandatory to use time synchronization. There may > be DetNet services that do not require time synchronization. I was basically asking if you could list an example for me (here in email, not necessarily in the document). > > > > > Section 3.2.2.2 > > > > Please expand SRLG (it is only used once, so the abbreviation itself may > > not be needed at all). > Replace "SRLG" with "Shared Risk Link Group (SRLG)" > > > > > Section 3.2.3 > > > > Out-of-order packet delivery can be a side effect of distributing a > > single flow over multiple paths especially when there is a change > > from one path to another when combining the flow. [...] > > > > nit: comma before "especially". > Add comma. > > > > > Resource allocation > > The DetNet forwarding sub-layer provides resource allocation. > > See Section 4.5. The actual queuing and shaping mechanisms > > are typically provided by underlying subnet, these can be > > > > nit: is this usage of "subnet" common? > Figure 3 shows it and the text above Figure 3 explains sub-net. > > > Also, this comma looks to be a comma splice. > Make it two sentences. > > > > > closely associated with the means of providing paths for > > DetNet flows, the path and the resource allocation are > > conflated in this figure. > > > > nit: Hmm, actually, is this comma *also* a comma splice? > Make it two sentences. > > > > > Operations, Administration, and Maintenance (OAM) leverages in-band > > and out-of-band signaling that validates whether the service is > > effectively obtained within QoS constraints. [...] > > > > nit: is there a singular/plural mismatch here ("the service"/"service" vs. > > "effectively within"/"effectively obtained within")? > Seems good to me. > > > > > Section 4.1.1 > > > > This figure would have helped me a lot several sections earlier. > > > > Section 4.1.2 > > > > A "Deterministic Network" will be composed of DetNet enabled end > > systems, DetNet edge nodes, DetNet relay nodes and collectively > > deliver DetNet services. DetNet relay and edge nodes are > > > > Nit: I think this is intended to be: > > A "Deterministic Network" will be composed of DetNet-enabled end > > systems, DetNet edge nodes, and DetNet relay nodes, which collectively > > deliver DetNet services. DetNet relay and edge nodes are > Fine by me to make the cahnge. > > > > > Examples of > > sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. [...] > > > > nit: are these sub-networks or protocols used by sub-networks? > These are sub-network technologies. They may include/use multiple protocols. Should this be "examples of sub-networking technologies" then? > > > > > Distinguishing the function of two DetNet data plane sub-layers, the > > DetNet service sub-layer and the DetNet forwarding sub-layer, helps > > to explore and evaluate various combinations of the data plane > > solutions available, some are illustrated in Figure 4. This > > > > nit: this last comma is a comma splice. > Suggest to replace with: > "DetNet data plane is divided into two sub-layers: the > DetNet service sub-layer and the DetNet forwarding sub-layer. > This helps to explore and evaluate various combinations of the data plane > solutions available. Some of them are illustrated in Figure 4." > (https://mailarchive.ietf.org/arch/msg/detnet/JvPTAFVTJwxjhzZYEF9uCnUTFBA) Thanks. > > > > There are many valid options to create a data plane solution for > > DetNet traffic by selecting a technology approach for the DetNet > > service sub-layer and also selecting a technology approach for the > > DetNet forwarding sub-layer. There are a high number of valid > > combinations. > > > > nit: I think "large number" is more conventional prose. > Replace "high number" with "large number". > > > > > Section 4.3.1 > > > > I think I'm confused about how, for these flows that "require the > > feature", whether that means that the DetNet implementation must provide > > , or that it is required for the application to have implemented the > > feature. A mapping (if it makes sense) to the categorization of end > > systems in Section 4.2.1 would be a big help. > The notation is crafted such that to provide mapping. I inferred that intent, yet. I'm claiming that "It only requires" confused me about which entity required what. Changing to "It only uses" would remove that confusion (but would implicitly deny the ability for opportunistic use of other features, so is not a perfect replacement). > > > > > Section 4.3.2 > > > > Asynchronous DetNet flows are characterized by: > > > > o A maximum packet size; > > > > o An observation interval; and > > > > o A maximum number of transmissions during that observation > > interval. > > > > Is there necessarily only a single tier of observation interval/rate? > > (E.g., could there be a burst cap in a small interval and then a lower > > overall baseline rate over large intervals?) > We intentionally have a simple model here. OK. > > > > > That is, while any useful application is written to > > expect a certain number of lost packets, the real-time applications > > of interest to DetNet demand that the loss of data due to the network > > is a rare event. > > > > (I might even go with "vanishingly rare".) > Yes, there are extremely low loss requirements in certain use cases. > That's why we have PREOF. > > > > > Section 4.4.1 > > > > (Is there a standard reference for "Northbound"? I know we're all used to > > it, but it's probably best to have a reference if we can.) > RFC7426 is a reference. It is cited at the very beginning of the section. > > > > > Section 4.4.2 > > > > The deterministic sequence can > > typically be more complex than a direct sequence and include > > redundancy path, with one or more packet replication and elimination > > points. [...] > > > > nit: "redundancy paths", plural? > > Replace "redundancy paths", "redundant paths". > > > > > > Section 4.8 > > > > How does *provisioning* require knowledge of *dynamic* state? > I guess the idea was that the resource may change dynamically. > > Would it help to delete "dynamic"? > Thus get: "The state of a DetNet node's DetNet resources." That would probably help, yes. Maybe even "The current state", but I didn't think about it very hard. > > > > Section 4.9 > > > > Does aggregation like this pose a risk of all the aggregatees getting > > affected when one exceeds their allocation substantially (so as to also > > cause the aggregate to exceed the aggregate's allocation)? > One way could be to apply rate limitation for each member flow being > aggregated at the input of the aggregate flow. The need to apply rate > limitation is explained at multiple places in the document. OK > > > > Section 6 > > > > The ability for an attacker to use QoS markings as part of traffic > > correlation/inspection is not new with DetNet, but is probably still worth > > mentioning explicitly. > Do you mean mention it in Section 5 Security Considerations? That's not what I had in mind, no. I was thinking OLD: DetNet is provides a Quality of Service (QoS), and as such, does not directly raise any new privacy considerations. NEW: DetNet provides a Quality of Service (QoS) mechanism, and the generic considerations for such mechanisms apply. In particular, such markings allow for an attacker to correlate flows or to select particular types of flow for more detailed inspection. > The text in my previous mail > (https://mailarchive.ietf.org/arch/msg/detnet/mOzgdXOJ5lGr4gLBGAapYt6Azl8) > has a paragraph starting: > "To provide uninterrupted availability of the DetNet quality of service, > provisions must be made against DOS attacks and delay attacks." > > Would it be good to extend that paragraph with a sentence, e.g.,?: > "Malicious QoS marking should be also considered". I wouldn't oppose something like that, but it may not be needed in the architecture document (as opposed to the documents that actually describe the QoS markings). -Benjamin From nobody Tue Mar 5 02:28:21 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 E3C13130FBB; Tue, 5 Mar 2019 02:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckcaiZOhZ46K; Tue, 5 Mar 2019 02:28:17 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBA51293B1; Tue, 5 Mar 2019 02:28:16 -0800 (PST) Received: from sessfw99-sesbfw99-92.ericsson.net ([192.176.1.92] helo=[10.156.247.140]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h17J0-0004iu-6g; Tue, 05 Mar 2019 11:28:14 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5a998fcf-0572-82f6-8bee-2cac21635117@ericsson.com> Date: Tue, 5 Mar 2019 11:28:12 +0100 Cc: Lou Berger , The IESG , draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9CC0A271-BBF4-4EDF-8D4F-46038B9D7648@kuehlewind.net> References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net> <5a998fcf-0572-82f6-8bee-2cac21635117@ericsson.com> To: =?utf-8?Q?J=C3=A1nos_Farkas?= X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1551781696;b53dbce9; X-HE-SMSGID: 1h17J0-0004iu-6g Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 10:28:20 -0000 Hi Janos, sorry for my late'ish reply. Your changes look good to me. Thanks! Mirja > Am 26.02.2019 um 13:45 schrieb J=C3=A1nos Farkas = : >=20 > Hi Mirja, >=20 > Thank you for your review! >=20 > Please see in-line changes suggested to address your comments. >=20 >=20 > On 2/20/2019 5:24 PM, Lou Berger wrote: >> Hi Mirja,=20 >>=20 >> See below.=20 >>=20 >> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:=20 >>> Hi Lou,=20 >>>=20 >>> I=E2=80=99m happy to see that my concerns seem to be cover. So maybe = this is mostly a point about wording. Please see below.=20 >>>=20 >>>> Am 20.02.2019 um 15:46 schrieb Lou Berger :=20 >>>>=20 >>>> Hi Mirja,=20 >>>>=20 >>>> I'm responding as doc shepherd (and chair). Thank you for your = comments. Please see below for specific responses.=20 >>>>=20 >>>> On 2/20/2019 8:05 AM, Mirja K=C3=BChlewind wrote:=20 >>>>> Mirja K=C3=BChlewind has entered the following ballot position for=20= >>>>> draft-ietf-detnet-architecture-11: Discuss=20 >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all=20 >>>>> email addresses included in the To and CC lines. (Feel free to cut = this=20 >>>>> introductory paragraph, however.)=20 >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html=20 >>>>> for more information about IESG DISCUSS and COMMENT positions.=20 >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here:=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/=20= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ----------------------------------------------------------------------=20= >>>>> DISCUSS:=20 >>>>> = ----------------------------------------------------------------------=20= >>>>>=20 >>>>> Thanks for addressing the tsv-art review comments (and big thanks = to Michael=20 >>>>> and David!) and all the work done so far! I think the document is = in good shape=20 >>>>> and I only have one minor comment that I would like to see = addressed/more=20 >>>>> explicitly spelled out. However, this should be done quickly with = potentially=20 >>>>> 2-3 small changes in the draft. See below.=20 >>>> The input from Michael and David certainly led to a much improved = document. If you can help the authors with some specific text = suggestions that would be most helpful.=20 >>>>=20 >>>>=20 >>>>> Given that DetNet traffic is often assumed to be not congestion = controlled, it=20 >>>>> is important that there is also some network function that makes = sure the=20 >>>>> source traffic stays within the requested bandwidth limit in-order = to protect=20 >>>>> non-Detnet traffic. This is to some extended discussed in section = 3.3.2 but I=20 >>>>> think it should be more clearly spelled out that this would = require a rate=20 >>>>> limiting function at each DetNet source/relay (tunnel ingress). = Currently sec=20 >>>>> 3.3.2 says:=20 >>>>>=20 >>>>> "Filters and policers should be used in a DetNet network to=20 >>>>> detect if DetNet packets are received on the wrong interface, = or at=20 >>>>> the wrong time, or in too great a volume."=20 >>>>>=20 >>>>> However, maybe this case of limiting non-congestion controlled = traffic (in case=20 >>>>> the source in not keeping to the limits on purpose/in order to = cheat, because=20 >>>>> it couldn't estimate the needed bandwidth requirement an better, = or due to=20 >>>>> timely fluctuations) could be explained more clearing and the = respective=20 >>>>> requirement to implement rate limiting could be state separately = and more=20 >>>>> strongly...?=20 >>>> Section 3.2.1.1 days:=20 >>>>=20 >>>> Ensuring adequate buffering requires, in turn, that the source, = and=20 >>>> every DetNet node along the path to the destination (or nearly = every=20 >>>> node, see Section 4.3.3) be careful to regulate its output to = not=20 >>>> exceed the data rate for any DetNet flow, except for brief = periods=20 >>>> when making up for interfering traffic. Any packet sent ahead = of its=20 >>>> time potentially adds to the number of buffers required by the = next=20 >>>> hop DetNet node and may thus exceed the resources allocated for = a=20 >>>> particular DetNet flow.=20 >>>>=20 >>>> Section 3.3.1 also says:=20 >>>>=20 >>>> Starvation of non-DetNet traffic must be avoided, e.g., by = traffic=20 >>>> policing functions (e.g., [RFC2475]). Thus, the net effect of = the=20 >>>> presence of DetNet flows in a network on the non-DetNet flows is=20= >>>> primarily a reduction in the available bandwidth.=20 >>>>=20 >>>> Is this not sufficient? If not, can you suggest some additional = language?=20 >>> My question is mostly if you only need to protect _complete_ = starvation or any over-use by DetNet flows and how you would do that. If = the answer is to rate limit the DetNet flows at ingress to the allocated = bandwidth, that would completely address my concern. However note that = buffer dimensioning and rate limiting is not the same. Rate limiting is = usually a scheduling question, e.g. using a token bucket scheme or a = fixed non-work conserving scheduler. Therefore it would be nice to add = one additional sentence in section 3.2 that spells that out directly. = e.g. something like:=20 >>>=20 >>> =E2=80=9EIn order to protect non-DetNet traffic from potentially = misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token = bucket scheme, at each tunnel ingress must be applied.=E2=80=9C=20 >>=20 >>> I=E2=80=99m sure you can adapt the wording to make it more = DetNet-like language and maybe you also want to add another sentence = explaining the problem, please feel free to do so but that=E2=80=99s = more or less what I=E2=80=99m looking for.=20 >>=20 >> I do agree that we seem to be having a terminology issue here - and = that we are on the same page with what should happen. The terminology = I've used/seen in past RFCs has usually used the terms 'shaping' and = 'policing' - and these are what we've been using within the WG. For = example, both of these terms are used in RFC2475 but 'rate limiting' is = not. Would it work for you for the draft to use/adapt the rest of your = language, but keep 'by traffic policing functions (e.g., [RFC2475])' = rather than 'rate limiting, e.g. using a token bucket scheme,' ?=20 >=20 > We could extend the 2nd paragraph in 3.2.1.1 = (https://tools.ietf.org/html/draft-ietf-detnet-architecture-11#section-3.2= .1.1) to capture this comment: >=20 > OLD: > Ensuring adequate buffering requires, in turn, that the = source, and every DetNet > node along the path to the destination (or nearly every = node, see > ) be careful to regulate its = output to not exceed the > data rate for any DetNet flow, except for brief periods = when making up for > interfering traffic. Any packet sent ahead of its time = potentially adds to the > number of buffers required by the next hop DetNet node and = may thus exceed the resources > allocated for a particular DetNet flow. >=20 > NEW: >=20 > Ensuring adequate buffering requires, in turn, that the = source, and every DetNet > node along the path to the destination (or nearly every = node, see > ) be careful to regulate its = output to not exceed the > data rate for any DetNet flow, except for brief periods = when making up for > interfering traffic. Any packet sent ahead of its time = potentially adds to the > number of buffers required by the next hop DetNet node and = may thus exceed the resources > allocated for a particular DetNet flow. Furthermore, rate = limiting, e.g., using traffic=20 > policing and shaping functions, e.g., , at the ingress of the=20 > DetNet domain must be applied. This is needed for meeting = the requirements of DetNet=20 > flows as well as for protecting non-DetNet traffic from = potentially misbehaving DetNet > traffic sources. >=20 >=20 > Furthermore, replace the two occurrences of "policing" with "policing = and shaping": >=20 > OLD: > Starvation of non-DetNet traffic must be avoided, e.g., by traffic > policing functions (e.g., [RFC2475]). =20 >=20 > NEW: > Starvation of non-DetNet traffic must be avoided, e.g., by traffic > policing and shaping functions (e.g., [RFC2475]). =20 >=20 >=20 > OLD: > Examples of such techniques include traffic policing > functions (e.g., [RFC2475]) and separating flows into per-flow = rate- > limited queues. >=20 > NEW: > Examples of such techniques include traffic policing and shaping > functions (e.g., [RFC2475]) and separating flows into per-flow = rate- > limited queues. >=20 >>=20 >>=20 >>>=20 >>>>> One related comment on this sentence in Sec 3.1:=20 >>>>>=20 >>>>> "As DetNet provides allocated resources (including provisioned = capacity)=20 >>>>> to DetNet flows the use of transport layer congestion control=20= >>>>> [RFC2914] by App-flows is explicitly not required."=20 >>>>>=20 >>>>> I guess congestion control should still be a requirement if the = App-flow also=20 >>>>> passes not-DetNet-aware segments of the path, e.g. maybe the first = hop.=20 >>>> This point is addressed in section 3.3.2=20 >>>>=20 >>>> Note that the sending of App-flows that do not use transport = layer=20 >>>> congestion control per [RFC2914] into a network that is not=20 >>>> provisioned to handle such DetNet traffic has to be treated as a=20= >>>> fault and prevented.=20 >>>>=20 >>>>> Usually=20 >>>>> use of congestion control for application limited flows is also = not a problem=20 >>>>> if sufficient bandwidth is available. Also note that, as I stated = above, the=20 >>>>> important part for not requiring congestion control is actually = not only that=20 >>>>> resources are allocated but also that rate limiting is in place to = make sure=20 >>>>> resources usage cannot be exceeded above the reserved allocation. = Maybe this=20 >>>>> sentence could also be further clarified in the draft...?=20 >>>> Is the above sufficient? If not, can you suggest some additional = language?=20 >>> Maybe we can just extend the above statement a bit in order to be = crystal clear about this, e.g.:=20 >>>=20 >>> "As DetNet flow are assumed to be rate-limited and DetNet is = designed to provide sufficient allocated resources (including = provisioned capacity), the use of transport layer congestion control = [RFC2914] for end-to-end DetNet flows is not required, however, if = resources are allocated appropriately, use of congestion control should = not impact transmission negatively.=E2=80=9C=20 >> Great! (I'll leave it to the authors to do the final wording = adaptation)=20 >=20 > "App-flow" seems to be better than "end-to-end DetNet flow". The = change with that would be: >=20 > OLD: > As > DetNet provides allocated resources (including provisioned = capacity) > to DetNet flows the use of transport layer congestion control > [RFC2914] by App-flows is explicitly not required. >=20 > NEW: > As=20 > DetNet flows are assumed to be rate-limited and DetNet is = designed > to provide sufficient allocated resources (including = provisioned > capacity), the use of transport layer congestion control = [RFC2914]=20 > for App-flows is not required; however, if resources are = allocated > appropriately, use of congestion control should not impact > transmission negatively. >=20 >>>=20 >>>>> And then one more small comment that is also related. Sec 3.2.2.2 = says:=20 >>>>>=20 >>>>> "If packet replication and elimination is used over paths with=20 >>>>> resource allocation (Section 3.2.1), ..."=20 >>>>>=20 >>>>> My assumption was that all DetNet traffic is send over = pre-allocated=20 >>>>> resources...? If that is not true that has implication on = congestion control=20 >>>>> and needs some additional considerations. Can you please confirm = that and maybe=20 >>>>> clarify in the draft! Thanks!=20 >>>> The intent was to cover sending over non-pre-allocated paths as a = fault case, and cover it in section 3.3.2.=20 >>> If that is the case, maybe we can just removed the half-sentence I = cited above?=20 >>=20 >> WFM!=20 >=20 > The sentence after removing the text as you suggest: >=20 > OLD: > If packet replication and elimination is used over paths with > resource allocation (Section 3.2.1), and member flows that take > different-length paths through the network are combined, a merge > point may require extra buffering to equalize the delays over the > different paths. >=20 > NEW: > If member flows that take different-length paths through the=20 > network are combined, a merge point may require extra buffering > to equalize the delays over the different paths. >=20 >=20 > Thank you! > Janos >=20 >=20 >>=20 >> Thank you!=20 >>=20 >>>=20 >>> Thanks!=20 >>> Mirja=20 >>>=20 >>>> In addition to the previously quoted text, the section also says:=20= >>>>=20 >>>> PRF generated DetNet member flows also need to=20 >>>> be treated as not using transport layer congestion control even = if=20 >>>> the original App-flow supports transport layer congestion = control=20 >>>> because PREOF can remove congestion indications at the PEF and=20= >>>> thereby hide such indications (e.g., drops, ECN markings, = increased=20 >>>> latency) from end systems.=20 >>>>=20 >>>> Does this address your concern?=20 >>>>> = ----------------------------------------------------------------------=20= >>>>> COMMENT:=20 >>>>> = ----------------------------------------------------------------------=20= >>>>>=20 >>>>> I agree with Alexey and Benjamin that this document should be = informational.=20 >>>>> Informational documents can also have IETF consensus, so that = cannot be the =20 >>>>> reason to go for PS. However, this document does not specify a = protocol or any=20 >>>>> requirements that are mandatory to implement for interoperability = and therefore=20 >>>>> should not be PS.=20 >>>>>=20 >>>> I defer to the IESG and AD on this...=20 >>>>=20 >>>> Thank you!=20 >>>>=20 >>>> Lou=20 >>>>=20 >>>>> _______________________________________________=20 >>>>> detnet mailing list=20 >>>>> detnet@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/detnet=20 >>>>=20 >>>=20 >=20 From nobody Tue Mar 5 02:30: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 3EFE213103F for ; Tue, 5 Mar 2019 02:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BSXSNh2mXt3 for ; Tue, 5 Mar 2019 02:30:12 -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 03CC31200B3 for ; Tue, 5 Mar 2019 02:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551781810; x=1554373810; 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=3ofFr3IMhvahbx+XFwQRY0Wq3y6LFKUbCgXwInPBDD8=; b=N4wL0JcyZ3bAu8eFOOiIHhs4QW6E6KI4F86rWW2wlNFUg6mqw18Su6u/kYUjcpLX GnqcxaCbCGLGjqgYqIY+rSe9UwRcAkjQUHC1Hh9Wef4anbdok//7XZRjIBHo23Pe t+ZeO0fjX985JRgi034sZDGJgW3/VvbNXCjr/CeDWxk=; X-AuditID: c1b4fb30-fabff7000000355c-12-5c7e4fb2af00 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.0C.13660.2BF4E7C5; Tue, 5 Mar 2019 11:30:10 +0100 (CET) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESBMB504.ericsson.se (153.88.183.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 11:30:09 +0100 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 11:30:09 +0100 Received: from [131.160.180.67] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 11:30:09 +0100 To: "Mirja Kuehlewind (IETF)" CC: Lou Berger , The IESG , , , References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net> <5a998fcf-0572-82f6-8bee-2cac21635117@ericsson.com> <9CC0A271-BBF4-4EDF-8D4F-46038B9D7648@kuehlewind.net> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Tue, 5 Mar 2019 11:30:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9CC0A271-BBF4-4EDF-8D4F-46038B9D7648@kuehlewind.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2J7qe4m/7oYgxOdAhbX+n+wWPz+NJvF 4sO3mSwWM/5MZLZ4cf0js0VH81sWBzaPJUt+Mnm0fFzI6vFhUzNbAHMUl01Kak5mWWqRvl0C V8aJ6TEFFwoqZjw+zNbAeDSyi5GDQ0LARGLqfLUuRi4OIYEjjBKX101khnC+Mkp8vvSApYuR E8K5/9MWwgaq+vEiAaRIWGAeo8ScxbuYQBIiAsYShyd/ZwVJMAtMZ5Q4P/8FG8Soa0wSHyc+ YgOpYhOwl7h7aQMziM0LZE9fdxQsziKgIvHs/QqwdaICsRKfriyGqhGUODnzCVicU8BJ4ui1 I4wgNrOAhcTM+eehbHmJ5q2zmSFscYlbT+YzQZyqJvG+4Q7jBEbhWUhGzULSPgtJ+ywk7QsY WVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbLwS2/DXYwvnzueIhRgINRiYe326QuRog1 say4MvcQowQHs5II7x9xoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeP0KCMUIC6YklqdmpqQWp RTBZJg5OqQZGbbPlNpV57v7Tps/51Xi7M+xY6plj9je4qrfvSBM4MztPheeD3dfTOU8P/inV f/Bx9TnRnbVhl/XXLTSc3//xXalqhvU17fUMepIzTmUy8O+p3KDx3vlAI0fDX90LUqllH3hY dzsHpRQv3avYcKOy4uLN3Y5h1fX7uy6cU3lVoBcXsuTWDJ4eJZbijERDLeai4kQAQasYtpIC AAA= Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 10:30:15 -0000 Thank you Mirja! We are implementing the changes in the next revision of the draft. Janos On 3/5/2019 11:28 AM, Mirja Kuehlewind (IETF) wrote: > Hi Janos, > > sorry for my late'ish reply. Your changes look good to me. Thanks! > > Mirja > > > >> Am 26.02.2019 um 13:45 schrieb János Farkas : >> >> Hi Mirja, >> >> Thank you for your review! >> >> Please see in-line changes suggested to address your comments. >> >> >> On 2/20/2019 5:24 PM, Lou Berger wrote: >>> Hi Mirja, >>> >>> See below. >>> >>> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote: >>>> Hi Lou, >>>> >>>> I’m happy to see that my concerns seem to be cover. So maybe this is mostly a point about wording. Please see below. >>>> >>>>> Am 20.02.2019 um 15:46 schrieb Lou Berger : >>>>> >>>>> Hi Mirja, >>>>> >>>>> I'm responding as doc shepherd (and chair). Thank you for your comments. Please see below for specific responses. >>>>> >>>>> On 2/20/2019 8:05 AM, Mirja Kühlewind wrote: >>>>>> Mirja Kühlewind has entered the following ballot position for >>>>>> draft-ietf-detnet-architecture-11: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Thanks for addressing the tsv-art review comments (and big thanks to Michael >>>>>> and David!) and all the work done so far! I think the document is in good shape >>>>>> and I only have one minor comment that I would like to see addressed/more >>>>>> explicitly spelled out. However, this should be done quickly with potentially >>>>>> 2-3 small changes in the draft. See below. >>>>> The input from Michael and David certainly led to a much improved document. If you can help the authors with some specific text suggestions that would be most helpful. >>>>> >>>>> >>>>>> Given that DetNet traffic is often assumed to be not congestion controlled, it >>>>>> is important that there is also some network function that makes sure the >>>>>> source traffic stays within the requested bandwidth limit in-order to protect >>>>>> non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I >>>>>> think it should be more clearly spelled out that this would require a rate >>>>>> limiting function at each DetNet source/relay (tunnel ingress). Currently sec >>>>>> 3.3.2 says: >>>>>> >>>>>> "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." >>>>>> >>>>>> However, maybe this case of limiting non-congestion controlled traffic (in case >>>>>> the source in not keeping to the limits on purpose/in order to cheat, because >>>>>> it couldn't estimate the needed bandwidth requirement an better, or due to >>>>>> timely fluctuations) could be explained more clearing and the respective >>>>>> requirement to implement rate limiting could be state separately and more >>>>>> strongly...? >>>>> Section 3.2.1.1 days: >>>>> >>>>> Ensuring adequate buffering requires, in turn, that the source, and >>>>> every DetNet node along the path to the destination (or nearly every >>>>> node, see Section 4.3.3) be careful to regulate its output to not >>>>> exceed the data rate for any DetNet flow, except for brief periods >>>>> when making up for interfering traffic. Any packet sent ahead of its >>>>> time potentially adds to the number of buffers required by the next >>>>> hop DetNet node and may thus exceed the resources allocated for a >>>>> particular DetNet flow. >>>>> >>>>> Section 3.3.1 also says: >>>>> >>>>> Starvation of non-DetNet traffic must be avoided, e.g., by traffic >>>>> policing functions (e.g., [RFC2475]). Thus, the net effect of the >>>>> presence of DetNet flows in a network on the non-DetNet flows is >>>>> primarily a reduction in the available bandwidth. >>>>> >>>>> Is this not sufficient? If not, can you suggest some additional language? >>>> My question is mostly if you only need to protect _complete_ starvation or any over-use by DetNet flows and how you would do that. If the answer is to rate limit the DetNet flows at ingress to the allocated bandwidth, that would completely address my concern. However note that buffer dimensioning and rate limiting is not the same. Rate limiting is usually a scheduling question, e.g. using a token bucket scheme or a fixed non-work conserving scheduler. Therefore it would be nice to add one additional sentence in section 3.2 that spells that out directly. e.g. something like: >>>> >>>> „In order to protect non-DetNet traffic from potentially misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token bucket scheme, at each tunnel ingress must be applied.“ >>>> I’m sure you can adapt the wording to make it more DetNet-like language and maybe you also want to add another sentence explaining the problem, please feel free to do so but that’s more or less what I’m looking for. >>> I do agree that we seem to be having a terminology issue here - and that we are on the same page with what should happen. The terminology I've used/seen in past RFCs has usually used the terms 'shaping' and 'policing' - and these are what we've been using within the WG. For example, both of these terms are used in RFC2475 but 'rate limiting' is not. Would it work for you for the draft to use/adapt the rest of your language, but keep 'by traffic policing functions (e.g., [RFC2475])' rather than 'rate limiting, e.g. using a token bucket scheme,' ? >> We could extend the 2nd paragraph in 3.2.1.1 (https://tools.ietf.org/html/draft-ietf-detnet-architecture-11#section-3.2.1.1) to capture this comment: >> >> OLD: >> Ensuring adequate buffering requires, in turn, that the source, and every DetNet >> node along the path to the destination (or nearly every node, see >> ) be careful to regulate its output to not exceed the >> data rate for any DetNet flow, except for brief periods when making up for >> interfering traffic. Any packet sent ahead of its time potentially adds to the >> number of buffers required by the next hop DetNet node and may thus exceed the resources >> allocated for a particular DetNet flow. >> >> NEW: >> >> Ensuring adequate buffering requires, in turn, that the source, and every DetNet >> node along the path to the destination (or nearly every node, see >> ) be careful to regulate its output to not exceed the >> data rate for any DetNet flow, except for brief periods when making up for >> interfering traffic. Any packet sent ahead of its time potentially adds to the >> number of buffers required by the next hop DetNet node and may thus exceed the resources >> allocated for a particular DetNet flow. Furthermore, rate limiting, e.g., using traffic >> policing and shaping functions, e.g., , at the ingress of the >> DetNet domain must be applied. This is needed for meeting the requirements of DetNet >> flows as well as for protecting non-DetNet traffic from potentially misbehaving DetNet >> traffic sources. >> >> >> Furthermore, replace the two occurrences of "policing" with "policing and shaping": >> >> OLD: >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic >> policing functions (e.g., [RFC2475]). >> >> NEW: >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic >> policing and shaping functions (e.g., [RFC2475]). >> >> >> OLD: >> Examples of such techniques include traffic policing >> functions (e.g., [RFC2475]) and separating flows into per-flow rate- >> limited queues. >> >> NEW: >> Examples of such techniques include traffic policing and shaping >> functions (e.g., [RFC2475]) and separating flows into per-flow rate- >> limited queues. >> >>> >>>>>> One related comment on this sentence in Sec 3.1: >>>>>> >>>>>> "As DetNet provides allocated resources (including provisioned capacity) >>>>>> to DetNet flows the use of transport layer congestion control >>>>>> [RFC2914] by App-flows is explicitly not required." >>>>>> >>>>>> I guess congestion control should still be a requirement if the App-flow also >>>>>> passes not-DetNet-aware segments of the path, e.g. maybe the first hop. >>>>> This point is addressed in section 3.3.2 >>>>> >>>>> Note that the sending of App-flows that do not use transport layer >>>>> congestion control per [RFC2914] into a network that is not >>>>> provisioned to handle such DetNet traffic has to be treated as a >>>>> fault and prevented. >>>>> >>>>>> Usually >>>>>> use of congestion control for application limited flows is also not a problem >>>>>> if sufficient bandwidth is available. Also note that, as I stated above, the >>>>>> important part for not requiring congestion control is actually not only that >>>>>> resources are allocated but also that rate limiting is in place to make sure >>>>>> resources usage cannot be exceeded above the reserved allocation. Maybe this >>>>>> sentence could also be further clarified in the draft...? >>>>> Is the above sufficient? If not, can you suggest some additional language? >>>> Maybe we can just extend the above statement a bit in order to be crystal clear about this, e.g.: >>>> >>>> "As DetNet flow are assumed to be rate-limited and DetNet is designed to provide sufficient allocated resources (including provisioned capacity), the use of transport layer congestion control [RFC2914] for end-to-end DetNet flows is not required, however, if resources are allocated appropriately, use of congestion control should not impact transmission negatively.“ >>> Great! (I'll leave it to the authors to do the final wording adaptation) >> "App-flow" seems to be better than "end-to-end DetNet flow". The change with that would be: >> >> OLD: >> As >> DetNet provides allocated resources (including provisioned capacity) >> to DetNet flows the use of transport layer congestion control >> [RFC2914] by App-flows is explicitly not required. >> >> NEW: >> As >> DetNet flows are assumed to be rate-limited and DetNet is designed >> to provide sufficient allocated resources (including provisioned >> capacity), the use of transport layer congestion control [RFC2914] >> for App-flows is not required; however, if resources are allocated >> appropriately, use of congestion control should not impact >> transmission negatively. >> >>>>>> And then one more small comment that is also related. Sec 3.2.2.2 says: >>>>>> >>>>>> "If packet replication and elimination is used over paths with >>>>>> resource allocation (Section 3.2.1), ..." >>>>>> >>>>>> My assumption was that all DetNet traffic is send over pre-allocated >>>>>> resources...? If that is not true that has implication on congestion control >>>>>> and needs some additional considerations. Can you please confirm that and maybe >>>>>> clarify in the draft! Thanks! >>>>> The intent was to cover sending over non-pre-allocated paths as a fault case, and cover it in section 3.3.2. >>>> If that is the case, maybe we can just removed the half-sentence I cited above? >>> WFM! >> The sentence after removing the text as you suggest: >> >> OLD: >> If packet replication and elimination is used over paths with >> resource allocation (Section 3.2.1), and member flows that take >> different-length paths through the network are combined, a merge >> point may require extra buffering to equalize the delays over the >> different paths. >> >> NEW: >> If member flows that take different-length paths through the >> network are combined, a merge point may require extra buffering >> to equalize the delays over the different paths. >> >> >> Thank you! >> Janos >> >> >>> Thank you! >>> >>>> Thanks! >>>> Mirja >>>> >>>>> In addition to the previously quoted text, the section also says: >>>>> >>>>> PRF generated DetNet member flows also need to >>>>> be treated as not using transport layer congestion control even if >>>>> the original App-flow supports transport layer congestion control >>>>> because PREOF can remove congestion indications at the PEF and >>>>> thereby hide such indications (e.g., drops, ECN markings, increased >>>>> latency) from end systems. >>>>> >>>>> Does this address your concern? >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> I agree with Alexey and Benjamin that this document should be informational. >>>>>> Informational documents can also have IETF consensus, so that cannot be the >>>>>> reason to go for PS. However, this document does not specify a protocol or any >>>>>> requirements that are mandatory to implement for interoperability and therefore >>>>>> should not be PS. >>>>>> >>>>> I defer to the IESG and AD on this... >>>>> >>>>> Thank you! >>>>> >>>>> Lou >>>>> >>>>>> _______________________________________________ >>>>>> detnet mailing list >>>>>> detnet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Mar 5 09:38: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 BEC1D131122 for ; Tue, 5 Mar 2019 09:38:05 -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 STxZij6a8FZp for ; Tue, 5 Mar 2019 09:38:03 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 CB1C3131113 for ; Tue, 5 Mar 2019 09:38:00 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id x6so5218865qki.6 for ; Tue, 05 Mar 2019 09:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aoNTNNw7MWPqZenCjdAL3sDknQNE0q9LbIbfGBHtj/0=; b=X1LJmyMMZXimbWyZul4YMfS7Pmg+T3CjqTYF+74a9rH7H14m9j3luI648OeqXJSV9R 26i2x/bU4482D1GHeGK471FAyAjs3QwZFLwc42wY4LRupEXQmqyx4wbbE+WjjwMAjJtE W5ExPlGkIuq4NSsZr8YFhY85OiHtK+g8GuBdA1wP1DoW7ryauxaHwvnKiVhS7w44Cj/M hYuVY/pDJRMRpW9dVb5pARSwonBqiy5UI3biHvcAzcGCfwFVzKSt3cPcYOjlsyQpNhp2 Ot0NsCRLsWC2GITCNJrGzbkJGmT8QZuCe0MIZxcUsmlHVMDHs7bCjqD+qY4pn4tC7GZV 6n4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aoNTNNw7MWPqZenCjdAL3sDknQNE0q9LbIbfGBHtj/0=; b=su0O3LbV9nMi5eQNtm+h2Z823eal/8z6NgHJwTvLJHaVj+FrT4llh0bIlDkxgJ1QE3 ceEQW0a85rTeiq+tBdnbEAAg7vTWle/AyWucVZ/81nwSCUpPvvI/EiiM5LAMyp7sypGe poTd2eEhSgnzb1wm1PoH1T1m9j/VXXr2vy0vTVQNf3CqUamBEUU5uNeaIhQXUcNclwJp TaG3J+4XLFmbGRXPJMLbZeNHmG2PjkCitFX0vwXfPyyLk4I+81XoxCpILCketlwbzNeJ jlu3ifl9Y/gppmVer55oSfDj1FPaCl4Zy9FOYjGUG8mEWYZo692qs0zozxyqrb29QZHO nOvQ== X-Gm-Message-State: APjAAAXPG9L9XjlZhLg+3YxbJ3Pknie2p9lxtKNvfS/1wE3F7hOX+bWX YaWk+40JoCIK9ZJFP3CgvKP1/umZRIyjUXOZ5nv5F+er X-Google-Smtp-Source: APXvYqwT/Sx/LzLAAYO/ISAtVHDAVduOSww+PBu7P/o7mRAPZJvmD+YRQL/ljsnSb/5/+lPs3OFQKumPFFAXmLB319Q= X-Received: by 2002:a37:4887:: with SMTP id v129mr2711366qka.100.1551807479465; Tue, 05 Mar 2019 09:37:59 -0800 (PST) MIME-Version: 1.0 From: "Andrew G. Malis" Date: Tue, 5 Mar 2019 12:37:48 -0500 Message-ID: To: detnet WG Content-Type: multipart/alternative; boundary="00000000000092cd6e05835c5513" Archived-At: Subject: [Detnet] A few suggested updates to draft-ietf-detnet-architecture-11 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, 05 Mar 2019 17:38:06 -0000 --00000000000092cd6e05835c5513 Content-Type: text/plain; charset="UTF-8" This morning we had a DetNet data plane design team call to work on the MPLS and IP data plane drafts in preparation for Prague. We had a discussion of terminology in the drafts that led us back to the terminology definitions in the Architecture draft. As a result, we have a few suggested terminology improvements: In section 2.1: Replace these old definitions: App-flow The native format of a DetNet flow. DetNet flow A DetNet flow is a sequence of packets from one source to one or more destinations, which conform uniquely to a flow identifier, and to which the DetNet service is to be provided. with these: App-Flow The payload (data) carried over a DetNet service. DetNet flow A DetNet flow is a sequence of packets which conform uniquely to a flow identifier, and to which the DetNet service is to be provided. It includes any DetNet headers added to support the DetNet service and forwarding sub-layers. These new definitions provide more clarity to the difference between the terms. We also had two other minor changes to suggest. In section 4.2.1, remove the first sentence: The native data flow between the source/destination end systems is referred to as application-flow (App-flow). This is redundant to the definition in section 2.1. In section 4.3.1, change: o App-flow: native format of the data carried over a DetNet flow. It does not contain any DetNet related attributes. to: o App-flow: the payload carried over a DetNet flow. It does not contain any DetNet related attributes. This is consistent with the definition in section 2.1. Thanks, Andy --00000000000092cd6e05835c5513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This morning we had a DetNet data plane design team call t= o work on the MPLS and IP data plane drafts in preparation for Prague. We h= ad a discussion of terminology in the drafts that led us back to the termin= ology definitions in the Architecture draft.

As a result= , we have a few suggested terminology improvements:

In section 2.1:

Replace these old definitions:

   App-flow
           The native format of a DetNet flow.


   DetNet flow
           A DetNet flow is a sequence of packets from one source to one
           or more destinations, which conform uniquely to a flow
           identifier, and to which the DetNet service is to be
           provided.

with these:<= /div>

App-Flow

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The payload (data) c= arried over a DetNet service.


=C2=A0 D= etNet flow

=C2=A0=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 A DetNet flow is a sequence of packets = =C2=A0

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= which conform uniquely to a flow

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identifie= r, and to which the DetNet service is to be

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 provi= ded. It includes any DetNet headers added to support=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DetNe= t service and forwarding sub-layers.


These new de= finitions provide more clarity to the difference between the terms.

=


We also had two other minor changes to suggest.

<= p class=3D"gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-v= ariant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:nor= mal;font-family:"Helvetica Neue"">

In section 4.2.1, remove the first sentence:


   The native data flow between the source/destina=
tion end systems is
   referred to as application-flow (App-flow).


= This is redundant to the definition in section 2.1.


In section 4.3.1, change:

o App-flo= w: native format of the data carried over a DetNet flow. It does not contain any DetNet related attributes.


to:<= /p>


=C2=A0=C2=A0 o=C2=A0 App-flow: the payload carried over a DetN= et flow.

=C2=A0 =C2=A0 =C2=A0 =C2=A0It does not contain any= DetNet related attributes.


This is consistent wi= th the definition in section 2.1.


Thanks,

Andy


--00000000000092cd6e05835c5513-- From nobody Tue Mar 5 13:40:20 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 1D43E131095 for ; Tue, 5 Mar 2019 13:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.29 X-Spam-Level: X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bGuSddHB1iy for ; Tue, 5 Mar 2019 13:40:14 -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 F0A98131096 for ; Tue, 5 Mar 2019 13:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551822006; x=1554414006; 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=SEbnkGBx+wlmVNWX25ldH745wp3wfiZE+l0hQqMYIH0=; b=Y+3Wy+hcZ1qmm0pYxyQPu59LYGap/ogn7QuJ0ny8zi1TaguvBa2g320E9KxuAK0o vrsM76IizFC3GbFM8MfBvNx7rcIBbb+dO1+jTGq5aadRrCLO9jrqXkqyHOY8E5tA 7m7dk+M7Za9eewKj2fgoZhIYfVs9q1PpXI4HQrXVTy8=; X-AuditID: c1b4fb2d-d9dff7000000062f-5f-5c7eecb60682 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.C7.01583.6BCEE7C5; Tue, 5 Mar 2019 22:40:06 +0100 (CET) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 22:40:05 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 22:40:05 +0100 Received: from [100.94.49.140] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.188) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 22:40:05 +0100 References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net> <20190304032524.GM53396@kduck.mit.edu> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Benjamin Kaduk CC: Lou Berger , , , The IESG , "detnet-chairs@ietf.org" Message-ID: Date: Tue, 5 Mar 2019 22:40:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190304032524.GM53396@kduck.mit.edu> Content-Type: multipart/mixed; boundary="------------9A8FF83CD59895F99BBB2518" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2J7ue62N3UxBhMWsVpc6//BYvH702wW iw/fZrJYzPgzkdli+caZTBYdzW9ZHNg8liz5yeTxYVMzm0fTmaPMAcxRXDYpqTmZZalF+nYJ XBnnn0xjLdh1nLli6/IfrA2Ml1YydzFyckgImEgs/zOZrYuRi0NI4AijxJw3a5ghnK+MEjsO /meCc2Z938YO4RxmlJh+uJ8FpF9YoFDiwsKpjBCJKcwSV5ZdARvMJmAvcffSBjBbREBJYvHZ FjYQm1lgA6PElB8qIDYvUM2G3uusXYwcHCwCKhKfV2WAhEUFYiU+XVnMDFEiKHFy5hOwXZwC xhLTXvSwQIwJkJjx9TQzhC0ucevJfCYQW0hATeJ9wx3GCYxCs5C0z0LSMgtJC4RtITFz/nlG CFteonnrbKgaS4l/095D1ShKTOl+yA5hm0hM69jHuICRYxWjaHFqcXFuupGxXmpRZnJxcX6e Xl5qySZGYOwd3PJbdwfj6teOhxgFOBiVeHj9H9TFCLEmlhVX5h5iVAGa82jD6guMUix5+Xmp SiK88+8CpXlTEiurUovy44tKc1KLDzFKc7AoifP+ERKMERJITyxJzU5NLUgtgskycXBKNTAq Tzt44ML3DQK2R4NPRzNv0PdwbwrVu7zYzrthM0uN8ZsdEu/f8Qu+5nq66HKx6ay0NWddL+n8 Td+4YLeZaGHWzJhrmnX7czZs/X7qfF7igz1vXARYqoI33N01da7VnktZrzZlBb3PcJnZdSiv PczMP1nxXU19Z/Yiw69THDf1BmrxuE3frX5ciaU4I9FQi7moOBEAVtx3pMUCAAA= Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:40:18 -0000 --------------9A8FF83CD59895F99BBB2518 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin, I'm glad that we are progressing. :-) Thank you! Please see in-line. On 3/4/2019 4:25 AM, Benjamin Kaduk wrote: > Hi János, > > Thanks for the new text. These are some great things to be thinking about, > but I'm a little worried that it's just specifying mechanism without > describing the motiviations; in fact, it may even be more detailed than we > need for this document. More inline... > > On Sat, Mar 02, 2019 at 07:22:15PM +0100, János Farkas wrote: >> Hi Benjamin, >> >> Thank you for your review! >> >> Focusing on the main point now: Section 5 Security Considerations. We >> could consolidate the section to address your comment. Would it be >> helpful to replace the section with the following text?: >> >> >> Security considerations for DetNet are described in detail in >> [I-D.ietf-detnet-security]. This section considers exclusively security >> considerations which are specific to the DetNet Architecture. >> >> Security aspects which are unique to DetNet are those whose aim is to >> secure the specific quality of service aspects of DetNet, which are >> primarily to deliver data flows with extremely low packet loss rates and >> bounded end-to-end delivery latency. A DetNet is implemented using MPLS >> and IP (including both v4 and v6) technologies, and thus inherits the >> security properties of those technologies at both the control plane and >> the data plane. >> >> Security considerations for DetNet are constrained (compared to, for >> example, the open Internet) because DetNet is defined to operate only >> within a single administrative domain (see Section 1).  The primary >> considerations are to secure the request and control of DetNet >> resources, maintain confidentiality of data traversing the DetNet, and >> provide uninterrupted availability of the DetNet quality of service. > "secure" (verb) can mean many different things in different contexts. So > when we want to "secure" the request and control of resources, that would > presumably be something like denying unauthorized entities the ability to > use the resources, and probably also to limit the consumption of any > given entity. This probably also means that the ability of resources > external to DetNet to disrupt the DetNet resources should be limited in > some fashion, but the exact details are still unclear to me. "secure is not the right word in this sentence. I suggest to replace it with "provide" to get:           Security aspects which are unique to DetNet are those whose aim is to           provide the specific quality of service aspects of DetNet, which are           primarily to deliver data flows with extremely low packet loss rates           and bounded end-to-end delivery latency. > Similarly, the "uninterrupted availability" is not without qualifications: > an EMP or nuclear blast may not be something in the threat model that we > need to defend against. But if we just say "uninterrupted availability", > the reader has no way to know that. "uninterrupted availability" is not a good phrase here, can be confused with zero loss. Suggest to replace "uninterrupted availability" with "the" to get:           Security considerations for DetNet are constrained (compared to, for           example, the open Internet) because DetNet is defined to operate only           within a single administrative domain (see Section 1). The primary           considerations are to secure the request and control of DetNet           resources, maintain confidentiality of data traversing the DetNet,           and provide the availability of the DetNet quality of service. > > To be clear, I'm not saying that this introductory text has to change, but > if we keep it, the follow-on paragraphs need to provide the > motivation/reasoning that is missing here. > >> To secure the request and control of DetNet resources, authentication >> and authorization must be provided for each device connected to a DetNet >> domain, most importantly to network controller devices. Control of a > We require authn/authz because there is/are some risk(s) that we are trying to > protect against. What is/are that risk? What we want to prevent is having unauthorized device placed within a DetNet domain, or attached to the DetNet domain; or unauthorized person accessing DetNet domain. This helps preventing some of the attacks, e.g., man-in-the-middle, diverging the routes of DetNet flows. > >> DetNet network may be centralized or distributed (within a single >> administrative domain). In the case of centralized control, precedent >> for security considerations as defined for ACTN can be found in RFC8453, >> Section 9. In the case of a distributed control protocols, DetNet >> security is expected to be provided by the security properties of the >> protocols in use. In any case, the result must be that manipulation of >> administratively configurable parameters is limited to authorized entities. > Deferring on control protocol security is a fine thing to do. > >> To maintain confidentiality of data traversing the DetNet, application >> flows must be protected through whatever means is provided by the >> underlying technology. For example, encryption may be used, such as that >> provided by IPSec for IP (Layer 3) flows and by MACSec for Ethernet >> (Layer 2) flows. DetNet flows are identified on a per-flow basis, which > (I wouldn't care whether the "For example" sentence is present or not; we > aren't necessarily obligated to provide it.) I think the examples are useful to make it clearer what is meant. > >> may provide attackers with additional information about the data flows >> (when compared to networks that do not include per-flow identification); >> this is an inherent property of DetNet which has security implications >> which must be considered when determining if DetNet is a suitable >> technology for any given use case. Similar consideration may need to be >> given to the use of replicated packet flows, which result in increased >> surface for Reconnaissance attacks. In any case, the result must be that >> the confidentiality of the data is maintained to a degree sufficient for >> the use cases addressed by the given DetNet implementation. > I could consider putting this in a new paragraph. I'd also consider > trimming it down: the key point at this level is that detnet provides a new > type of information on packets that can be used by an attacker in the > network looking at metadata. The specific details of that could be shunted > off to the other document with no real harm. OK, make it a new paragraph. A shorter version: OLD:           DetNet flows are identified on a per-flow basis, which may provide           attackers with additional information about the data flows (when           compared to networks that do not include per-flow identification);           this is an inherent property of DetNet which has security           implications which must be considered when determining if DetNet is           a suitable technology for any given use case. Similar consideration           may need to be given to the use of replicated packet flows, which           result in increased surface for Reconnaissance attacks. In any case,           the result must be that the confidentiality of the data is           maintained to a degree sufficient for the use cases addressed by the           given DetNet implementation. NEW:           DetNet flows are identified on a per-flow basis, which may provide           attackers with additional information about the data flows (when           compared to networks that do not include per-flow identification).           This is an inherent property of DetNet which has security           implications which should be considered when determining if DetNet is           a suitable technology for any given use case. > >> To provide uninterrupted availability of the DetNet quality of service, >> provisions must be made against DOS attacks and delay attacks. To >> protect against DOS attacks, excess traffic due to malicious or >> malfunctioning devices must be prevented or mitigated, for example >> through the use of traffic admission control applied at the input of a >> DetNet domain, as described in Section 3.2.1.1, and through the fault >> mitigation methods described in Section 3.3.2. > This is getting closer to the sort of thing I was looking for -- we need to > provide availability *in the face of DOS attacks and delay attacks*. We > could probably say more about where the boundary is between "external" > entities that could threaten DOS and "internal" entities that we assume > behave properly -- is it the boundary of the DetNet domain, or will we > consider the risk of misbehaving/compromised equipment in the domain? > >> To prevent DetNet packets from being delayed, protection must be >> provided against Man-In-The-Middle attacks, for example through use of >> authentication and authorization of devices within the DetNet domain. > (nit: maybe join this into the previous paragraph, since that paragraph's > topic sentence also mentions delay) OK to merge it. > This is also pretty close to what I hoped for: it implies that we need to > keep the traffic inside our trusted elements (by avoiding the MITM), since > the MITM is untrusted and could introduce delay, but the internal elements > are trusted to not delay. So this could be "prevent DetNet packets from > being delayed by external network entities", which implicitly disclaims an > attempt to protect against a compromised DetNet router. I like your proposal. to make it clear that external is relative to the DetNet domain, I suggest to have: "To prevent DetNet packets from being delayed by an entity external to a DetNet domain, " Got another comment suggesting not to use "protection" here. With that the suggested new text:                                                                "To prevent DetNet packets from           being delayed by an entity external to a DetNet domain, DetNet           technology definition must allow for the mitigation of           Man-In-The-Middle attacks, for example through use of           authentication and authorization of devices within the DetNet domain." > >> Time synchronization methods are not specified by DetNet, however any >> time synchronization method used with DetNet must also be secured, using >> the security methods available for the given time synchronization >> mechanism, for example as described in [RFC7384]. >> In any case, the result must be that the DetNet is protected from DOS, >> delay, and time manipulation attacks to the extent sufficient for the >> use cases addressed by the given DetNet implementation. > I'd consider rephrasing this more like "Because DetNet mechanisms can make > heavy use of methods that require precise time synchronization, the > accuracy, availability, and integrity of time synchronization is of > critical importance. Extensive discussion of this topic can be found in > [RFC7384]." We may not need the rest of the details in this document. I like your proposal. I suggest to replace OLD: "Time synchronization methods are not specified by DetNet, however any time synchronization method used with DetNet must also be secured, using the security methods available for the given time synchronization mechanism, for example as described in [RFC7384]." with: NEW:           Because DetNet mechanisms or applications that rely on DetNet can           make heavy use of methods that require precise time synchronization,           the accuracy, availability, and integrity of time synchronization is           of critical importance. Extensive discussion of this topic can be           found in [RFC7384]. That is, I suggest to add "or applications that rely on DetNet" to the text you proposed. I suggest to capture that time synchronization can be important to the application running on an end system. There may be cases when a particular DetNet deployment does not rely on time synchronization, but it is still needed for an application. Based on your proposal delete: "          In any case, the result must be that the DetNet is protected from DOS,           delay, and time manipulation attacks to the extent sufficient for the           use cases addressed by the given DetNet implementation." > >> DetNet use cases are known to have widely divergent security >> requirements. The intent of this section is to provide a baseline for >> security considerations which are common to all DetNet designs and >> implementations, without burdening individual designs with specifics of >> security infrastructure which may not be germane to the given use case. >> Designers and Implementers of DetNet systems are expected to take use >> case specific considerations into account in their DetNet designs and >> implementations. > This is good. > > -Benjamin > We've got a few more comments. The main one is to remove "must" from the security section because the use of security mechanisms is a deployment choice, not that of the IETF. A diff is attached to show the changes described above. Thank you, Janos --------------9A8FF83CD59895F99BBB2518 Content-Type: text/html; charset="UTF-8"; name="diff.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="diff.htm" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRp b25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFu c2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NzogcmZjZGlm ZiAgLS0+IAo8IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0 LjAxIFRyYW5zaXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAz LjIuMC01LWFtZDY0ICMxIFNNUCBEZWJpYW4gMy4yLjk2LTMgeDg2XzY0IEdOVS9MaW51eCAt LT4gCjwhLS0gVXNpbmcgYXdrOiAvdXNyL2Jpbi9nYXdrOiBHTlUgQXdrIDQuMC4xIC0tPiAK PCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9kaWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAz LjIgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3 ZGlmZikgMS4xLjIgLS0+IAo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94 aHRtbCI+IAo8aGVhZD4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIC8+IAogIDxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiIC8+IAogIDx0aXRsZT5E aWZmOiBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTItaW5pdGlhbC50eHQgLSBk cmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTIudHh0PC90aXRsZT4gCiAgPHN0eWxl IHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2lu LXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUt c3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRv cDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZl bTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFs aWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAg ICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29s b3I6ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAK ICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7 IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1j b2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9 IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJy IHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVk OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWdu OiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1j b2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RE RDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAg ICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5yYmxv Y2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFj a2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMg dGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICAgIHNw YW4uaGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNvbG9yOiAjYWFhO30gICAgYTpob3ZlciBzcGFu IHsgZGlzcGxheTogaW5saW5lOyB9ICAgIHRyLmNoYW5nZSB7IGJhY2tncm91bmQtY29sb3I6 IGdyYXk7IH0gCiAgICB0ci5jaGFuZ2UgYSB7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgY29s b3I6IGJsYWNrIH0gCiAgPC9zdHlsZT4gCiAgICAgPHNjcmlwdD4KdmFyIGNodW5rX2luZGV4 ID0gMDsKdmFyIG9sZF9jaHVuayA9IG51bGw7CgpmdW5jdGlvbiBmb3JtYXRfY2h1bmsoaW5k ZXgpIHsKICAgIHZhciBwcmVmaXggPSAiZGlmZiI7CiAgICB2YXIgc3RyID0gaW5kZXgudG9T dHJpbmcoKTsKICAgIGZvciAoeD0wOyB4PCg0LXN0ci5sZW5ndGgpOyArK3gpIHsKICAgICAg ICBwcmVmaXgrPScwJzsKICAgIH0KICAgIHJldHVybiBwcmVmaXggKyBzdHI7Cn0KCmZ1bmN0 aW9uIGZpbmRfY2h1bmsobil7CiAgICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3Rvcign dHJbaWQkPSInICsgbiArICciXScpOwp9CgpmdW5jdGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0 KSB7CiAgICB2YXIgaW5kZXggPSBjaHVua19pbmRleCArIG9mZnNldDsKICAgIHZhciBuZXdf c3RyOwogICAgdmFyIG5ld19jaHVuazsKCiAgICBuZXdfc3RyID0gZm9ybWF0X2NodW5rKGlu ZGV4KTsKICAgIG5ld19jaHVuayA9IGZpbmRfY2h1bmsobmV3X3N0cik7CiAgICBpZiAoIW5l d19jaHVuaykgewogICAgICAgIHJldHVybjsKICAgIH0KICAgIGlmIChvbGRfY2h1bmspIHsK ICAgICAgICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIiOwogICAgfQogICAgb2xkX2No dW5rID0gbmV3X2NodW5rOwogICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiMXB4IHNv bGlkIHJlZCI7CiAgICB3aW5kb3cubG9jYXRpb24ucmVwbGFjZSgiIyIgKyBuZXdfc3RyKQog ICAgd2luZG93LnNjcm9sbEJ5KDAsLTEwMCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9 Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5 Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAgICAg YnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7CiAgICAgICAg YnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIg aWQ9InBhcnQtMSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTItaW5pdGlhbC50 eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+ Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZGV0bmV0LWFyY2hpdGVjdHVyZS0xMi1pbml0aWFsLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgi PmRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMi1pbml0aWFsLnR4dDwvYT4mbmJz cDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZS0xMi50eHQiIHN0eWxl PSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUtMTIudHh0PC9h PiZuYnNwOzxhIGhyZWY9Ii9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0 ZWN0dXJlLTEyLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25l OyI+Jmd0OzwvYT48L3RoPjx0aD48L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0icGFydC0xIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTEiPjxlbT4gcGFnZSAzLCBs aW5lIDIwPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48 dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy ZWY9IiNwYXJ0LTEiPjxlbT4gcGFnZSAzLCBsaW5lIDIwPHNwYW4gY2xhc3M9ImhpZGUiPiAm cGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNC43LjEuICBF eHBvcnRpbmcgZmxvdyBpZGVudGlmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MzI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNC43LjEuICBFeHBv cnRpbmcgZmxvdyBpZGVudGlmaWNhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA0LjcuMi4gIEZsb3cgYXR0 cmlidXRlIG1hcHBpbmcgYmV0d2VlbiBsYXllcnMgLiAuIC4gLiAuIC4gLiAuICAzNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjcuMi4gIEZsb3cgYXR0cmli dXRlIG1hcHBpbmcgYmV0d2VlbiBsYXllcnMgLiAuIC4gLiAuIC4gLiAuICAzNDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDQuNy4zLiAgRmxvdy1JRCBtYXBwaW5n IGV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM1PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDQuNy4zLiAgRmxvdy1JRCBtYXBwaW5nIGV4 YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM1PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuOC4gIEFkdmVydGlzaW5nIHJlc291cmNlcywgY2Fw YWJpbGl0aWVzIGFuZCBhZGphY2VuY2llcyAuIC4gLiAgMzY8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgIDQuOC4gIEFkdmVydGlzaW5nIHJlc291cmNlcywgY2FwYWJp bGl0aWVzIGFuZCBhZGphY2VuY2llcyAuIC4gLiAgMzY8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgNC45LiAgU2NhbGluZyB0byBsYXJnZXIgbmV0d29ya3MgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgNC45LiAgU2NhbGluZyB0byBsYXJnZXIgbmV0d29ya3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICA0LjEwLiBDb21wYXRpYmlsaXR5IHdpdGggTGF5ZXItMiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDM3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICA0LjEwLiBDb21wYXRpYmlsaXR5IHdpdGggTGF5ZXItMiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDM3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA1 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMzc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA1LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMzc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDYuICBQcml2 YWN5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDYuICBQcml2YWN5 IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzOTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNy4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gIElBTkEgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM5PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgQWNrbm93bGVkZ2VtZW50cyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzk8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzk8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDEiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgOS4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjQwPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA5LiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNw YW4gY2xhc3M9Imluc2VydCI+Mzk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyB0aGUgb3ZlcmFsbCBhcmNoaXRl Y3R1cmUgZm9yIERldGVybWluaXN0aWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHRoZSBvdmVyYWxsIGFyY2hpdGVjdHVyZSBm b3IgRGV0ZXJtaW5pc3RpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTmV0 d29ya2luZyAoRGV0TmV0KSwgd2hpY2ggcHJvdmlkZXMgYSBjYXBhYmlsaXR5IGZvciB0aGUg ZGVsaXZlcnkgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBOZXR3b3Jr aW5nIChEZXROZXQpLCB3aGljaCBwcm92aWRlcyBhIGNhcGFiaWxpdHkgZm9yIHRoZSBkZWxp dmVyeSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGF0YSBmbG93cyB3 aXRoIGV4dHJlbWVseSBsb3cgcGFja2V0IGxvc3MgcmF0ZXMgYW5kIGJvdW5kZWQgZW5kLXRv LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRhdGEgZmxvd3Mgd2l0aCBl eHRyZW1lbHkgbG93IHBhY2tldCBsb3NzIHJhdGVzIGFuZCBib3VuZGVkIGVuZC10by08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVuZCBkZWxpdmVyeSBsYXRlbmN5LiAg RGV0TmV0IGlzIGZvciBuZXR3b3JrcyB0aGF0IGFyZSB1bmRlciBhIHNpbmdsZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGVuZCBkZWxpdmVyeSBsYXRlbmN5LiAgRGV0 TmV0IGlzIGZvciBuZXR3b3JrcyB0aGF0IGFyZSB1bmRlciBhIHNpbmdsZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBvciB3aXRo aW4gYSBjbG9zZWQgZ3JvdXAgb2YgYWRtaW5pc3RyYXRpdmU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9yIHdpdGhpbiBhIGNs b3NlZCBncm91cCBvZiBhZG1pbmlzdHJhdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgY29udHJvbDsgdGhlc2UgaW5jbHVkZSBjYW1wdXMtd2lkZSBuZXR3b3JrcyBh bmQgcHJpdmF0ZSBXQU5zLiAgRGV0TmV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgY29udHJvbDsgdGhlc2UgaW5jbHVkZSBjYW1wdXMtd2lkZSBuZXR3b3JrcyBhbmQg cHJpdmF0ZSBXQU5zLiAgRGV0TmV0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIiA+PHRk PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9 IiNwYXJ0LTIiPjxlbT4gcGFnZSAzNywgbGluZSA1MTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBh cmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC0yIj48ZW0+IHBhZ2UgMzcsIGxp bmUgNTE8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHNlcnZpY2UgdG8sIGEgaGlnaGVyIGxheWVyIERldE5ldCBzeXN0ZW0u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2VydmljZSB0bywgYSBoaWdo ZXIgbGF5ZXIgRGV0TmV0IHN5c3RlbS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+NS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+NS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIGZvciBEZXROZXQgYXJlIGRlc2NyaWJlZCBpbiBkZXRhaWwgaW48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Ig RGV0TmV0IGFyZSBkZXNjcmliZWQgaW4gZGV0YWlsIGluPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtZGV0bmV0LXNlY3VyaXR5XS4gIFRoaXMgc2VjdGlv biBjb25zaWRlcnMgZXhjbHVzaXZlbHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBbSS1ELmlldGYtZGV0bmV0LXNlY3VyaXR5XS4gIFRoaXMgc2VjdGlvbiBjb25zaWRl cnMgZXhjbHVzaXZlbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHdoaWNoIGFyZSBzcGVjaWZpYyB0byB0aGUgRGV0TmV0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgd2hpY2ggYXJlIHNwZWNpZmljIHRvIHRoZSBEZXROZXQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEFyY2hpdGVjdHVyZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBBcmNoaXRlY3R1cmUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFNlY3VyaXR5IGFzcGVjdHMgd2hpY2ggYXJlIHVuaXF1ZSB0byBE ZXROZXQgYXJlIHRob3NlIHdob3NlIGFpbSBpcyB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFNlY3VyaXR5IGFzcGVjdHMgd2hpY2ggYXJlIHVuaXF1ZSB0byBEZXRO ZXQgYXJlIHRob3NlIHdob3NlIGFpbSBpcyB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMiI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3Bh biBjbGFzcz0iZGVsZXRlIj5zZWN1cjwvc3Bhbj5lIHRoZSBzcGVjaWZpYyBxdWFsaXR5IG9m IHNlcnZpY2UgYXNwZWN0cyBvZiBEZXROZXQsIHdoaWNoIGFyZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wcm92aWQ8L3NwYW4+ ZSB0aGUgc3BlY2lmaWMgcXVhbGl0eSBvZiBzZXJ2aWNlIGFzcGVjdHMgb2YgRGV0TmV0LCB3 aGljaCBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByaW1hcmlseSB0 byBkZWxpdmVyIGRhdGEgZmxvd3Mgd2l0aCBleHRyZW1lbHkgbG93IHBhY2tldCBsb3NzIHJh dGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJpbWFyaWx5IHRvIGRl bGl2ZXIgZGF0YSBmbG93cyB3aXRoIGV4dHJlbWVseSBsb3cgcGFja2V0IGxvc3MgcmF0ZXM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MDMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgYW5kIGJvdW5kZWQgZW5kLXRvLWVuZCBkZWxpdmVyeSBs YXRlbmN5LiAgQSBEZXROZXQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aXM8L3NwYW4+IGltcGxl bWVudGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZCBib3VuZGVk IGVuZC10by1lbmQgZGVsaXZlcnkgbGF0ZW5jeS4gIEEgRGV0TmV0IDxzcGFuIGNsYXNzPSJp bnNlcnQiPm1heSBiZTwvc3Bhbj4gaW1wbGVtZW50ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgdXNpbmcgTVBMUyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5hbmQ8L3Nw YW4+IElQIChpbmNsdWRpbmcgYm90aCB2NCBhbmQgdjYpIHRlY2hub2xvZ2llcywgYW5kIHRo dXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdXNpbmcgTVBMUyA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5hbmQvb3I8L3NwYW4+IElQIChpbmNsdWRpbmcgYm90aCB2NCBh bmQgdjYpIHRlY2hub2xvZ2llcywgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGluaGVyaXRzIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRob3NlIHRlY2hu b2xvZ2llcyBhdCBib3RoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICB0aHVzIGluaGVyaXRzIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRob3NlIHRlY2hu b2xvZ2llcyBhdCBib3RoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGNv bnRyb2wgcGxhbmUgYW5kIHRoZSBkYXRhIHBsYW5lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICB0aGUgY29udHJvbCBwbGFuZSBhbmQgdGhlIGRhdGEgcGxhbmUuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGZvciBEZXROZXQgYXJlIGNvbnN0cmFpbmVkIChjb21wYXJlZCB0bywg Zm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIERldE5ldCBhcmUgY29uc3RyYWluZWQgKGNvbXBhcmVkIHRvLCBmb3I8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4YW1wbGUsIHRoZSBvcGVuIElu dGVybmV0KSBiZWNhdXNlIERldE5ldCBpcyBkZWZpbmVkIHRvIG9wZXJhdGUgb25seTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4YW1wbGUsIHRoZSBvcGVuIEludGVy bmV0KSBiZWNhdXNlIERldE5ldCBpcyBkZWZpbmVkIHRvIG9wZXJhdGUgb25seTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2l0aGluIGEgc2luZ2xlIGFkbWluaXN0cmF0 aXZlIGRvbWFpbiAoc2VlIFNlY3Rpb24gMSkuICBUaGUgcHJpbWFyeTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBk b21haW4gKHNlZSBTZWN0aW9uIDEpLiAgVGhlIHByaW1hcnk8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGNvbnNpZGVyYXRpb25zIGFyZSB0byBzZWN1cmUgdGhlIHJlcXVl c3QgYW5kIGNvbnRyb2wgb2YgRGV0TmV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgY29uc2lkZXJhdGlvbnMgYXJlIHRvIHNlY3VyZSB0aGUgcmVxdWVzdCBhbmQgY29u dHJvbCBvZiBEZXROZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlc291 cmNlcywgbWFpbnRhaW4gY29uZmlkZW50aWFsaXR5IG9mIGRhdGEgdHJhdmVyc2luZyB0aGUg RGV0TmV0LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlc291cmNlcywg bWFpbnRhaW4gY29uZmlkZW50aWFsaXR5IG9mIGRhdGEgdHJhdmVyc2luZyB0aGUgRGV0TmV0 LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAwNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhbmQgcHJvdmlkZSA8c3BhbiBjbGFzcz0iZGVsZXRl Ij51bmludGVycnVwdGVkPC9zcGFuPiBhdmFpbGFiaWxpdHkgb2YgdGhlIERldE5ldCBxdWFs aXR5IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZCBwcm92aWRl IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZTwvc3Bhbj4gYXZhaWxhYmlsaXR5IG9mIHRoZSBE ZXROZXQgcXVhbGl0eSBvZiBzZXJ2aWNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBzZXJ2aWNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVG8gc2VjdXJlIHRo ZSByZXF1ZXN0IGFuZCBjb250cm9sIG9mIERldE5ldCByZXNvdXJjZXMsIGF1dGhlbnRpY2F0 aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVG8gc2VjdXJlIHRoZSBy ZXF1ZXN0IGFuZCBjb250cm9sIG9mIERldE5ldCByZXNvdXJjZXMsIGF1dGhlbnRpY2F0aW9u PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYw MDA1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFuZCBhdXRob3JpemF0aW9uIDxzcGFuIGNsYXNzPSJk ZWxldGUiPm11c3Q8L3NwYW4+IGJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPnByb3ZpZGVkPC9z cGFuPiBmb3IgZWFjaCBkZXZpY2UgY29ubmVjdGVkIHRvIGE8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgYW5kIGF1dGhvcml6YXRpb24gPHNwYW4gY2xhc3M9Imluc2Vy dCI+Y2FuPC9zcGFuPiBiZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij51c2VkPC9zcGFuPiBmb3Ig ZWFjaCBkZXZpY2UgY29ubmVjdGVkIHRvIGEgRGV0TmV0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIERldE5ldCBkb21haW4sIG1vc3QgaW1wb3J0YW50bHkgdG8gbmV0 d29yayBjb250cm9sbGVyIGRldmljZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIGRvbWFpbiwgbW9zdCBpbXBvcnRhbnRseSB0byBuZXR3b3JrIGNvbnRyb2xsZXIg ZGV2aWNlcy4gIENvbnRyb2wgb2YgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBDb250cm9sIG9mIGEgRGV0TmV0IG5ldHdvcmsgbWF5IGJlIGNlbnRyYWxpemVkIG9y IGRpc3RyaWJ1dGVkICh3aXRoaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgRGV0TmV0IG5ldHdvcmsgbWF5IGJlIGNlbnRyYWxpemVkIG9yIGRpc3RyaWJ1dGVkICh3 aXRoaW4gYSBzaW5nbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYSBz aW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluKS4gIEluIHRoZSBjYXNlIG9mIGNlbnRyYWxp emVkIGNvbnRyb2wsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFkbWlu aXN0cmF0aXZlIGRvbWFpbikuICBJbiB0aGUgY2FzZSBvZiBjZW50cmFsaXplZCBjb250cm9s LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJlY2VkZW50IGZvciBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhcyBkZWZpbmVkIGZvciBBYnN0cmFjdGlvbiBhbmQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcmVjZWRlbnQgZm9yIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGFzIGRlZmluZWQgZm9yIEFic3RyYWN0aW9uIGFuZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29udHJvbCBvZiBUcmFmZmljIEVuZ2luZWVy ZWQgTmV0d29ya3MgKEFDVE4pIGNhbiBiZSBmb3VuZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIENvbnRyb2wgb2YgVHJhZmZpYyBFbmdpbmVlcmVkIE5ldHdvcmtz IChBQ1ROKSBjYW4gYmUgZm91bmQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFtSRkM4NDUzXSwgU2VjdGlvbiA5LiAgSW4gdGhlIGNhc2Ugb2YgYSBkaXN0cmlidXRl ZCBjb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzg0NTNd LCBTZWN0aW9uIDkuICBJbiB0aGUgY2FzZSBvZiBhIGRpc3RyaWJ1dGVkIGNvbnRyb2w8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3RvY29scywgRGV0TmV0IHNlY3Vy aXR5IGlzIGV4cGVjdGVkIHRvIGJlIHByb3ZpZGVkIGJ5IHRoZSBzZWN1cml0eTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3RvY29scywgRGV0TmV0IHNlY3VyaXR5 IGlzIGV4cGVjdGVkIHRvIGJlIHByb3ZpZGVkIGJ5IHRoZSBzZWN1cml0eTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBwcm9wZXJ0aWVzIG9mIHRoZSBwcm90b2NvbHMgaW4gdXNlLiAgSW4gYW55 IGNhc2UsIHRoZSByZXN1bHQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bXVzdCBiZTwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcHJvcGVydGllcyBvZiB0aGUg cHJvdG9jb2xzIGluIHVzZS4gIEluIGFueSBjYXNlLCB0aGUgcmVzdWx0IDxzcGFuIGNsYXNz PSJpbnNlcnQiPmlzPC9zcGFuPiB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIHRoYXQgbWFuaXB1bGF0aW9uIG9mIGFkbWluaXN0cmF0aXZlbHkgY29uZmlndXJh YmxlIHBhcmFtZXRlcnMgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg bWFuaXB1bGF0aW9uIG9mIGFkbWluaXN0cmF0aXZlbHkgY29uZmlndXJhYmxlIHBhcmFtZXRl cnMgaXMgbGltaXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBsaW1p dGVkIHRvIGF1dGhvcml6ZWQgZW50aXRpZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHRvIGF1dGhvcml6ZWQgZW50aXRpZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRvIG1haW50YWluIGNvbmZpZGVudGlhbGl0eSBv ZiBkYXRhIHRyYXZlcnNpbmcgdGhlIERldE5ldCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBUbyBtYWludGFpbiBjb25maWRlbnRpYWxpdHkgb2YgZGF0YSB0cmF2ZXJz aW5nIHRoZSBEZXROZXQsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDA3Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFwcGxpY2F0aW9uIGZsb3dz IDxzcGFuIGNsYXNzPSJkZWxldGUiPm11c3Q8L3NwYW4+IGJlIHByb3RlY3RlZCB0aHJvdWdo IHdoYXRldmVyIG1lYW5zIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGFwcGxpY2F0aW9uIGZsb3dzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNhbjwvc3Bhbj4gYmUg cHJvdGVjdGVkIHRocm91Z2ggd2hhdGV2ZXIgbWVhbnMgaXMgcHJvdmlkZWQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcHJvdmlkZWQgYnkgdGhlIHVuZGVybHlpbmcg dGVjaG5vbG9neS4gIEZvciBleGFtcGxlLCBlbmNyeXB0aW9uIG1heTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBieSB0aGUgdW5kZXJseWluZyB0ZWNobm9sb2d5LiAg Rm9yIGV4YW1wbGUsIGVuY3J5cHRpb24gbWF5IGJlIHVzZWQsPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGJlIHVzZWQsIHN1Y2ggYXMgdGhhdCBwcm92aWRlZCBieSBJ UFNlYyBmb3IgSVAgKExheWVyIDMpIGZsb3dzIGFuZCBieTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBzdWNoIGFzIHRoYXQgcHJvdmlkZWQgYnkgSVBTZWMgPHNwYW4g Y2xhc3M9Imluc2VydCI+W1JGQzQzMDFdPC9zcGFuPiBmb3IgSVAgKExheWVyIDMpIGZsb3dz IGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBNQUNTZWMgZm9yIEV0 aGVybmV0IChMYXllciAyKSBmbG93cy4gIERldE5ldCBmbG93cyBhcmUgaWRlbnRpZmllZCBv bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBieSBNQUNTZWMgPHNwYW4g Y2xhc3M9Imluc2VydCI+W0lFRUU4MDIuMUFFLTIwMThdPC9zcGFuPiBmb3IgRXRoZXJuZXQg KExheWVyIDIpIGZsb3dzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBh IHBlci1mbG93IGJhc2lzLCB3aGljaCBtYXkgcHJvdmlkZSBhdHRhY2tlcnMgd2l0aCBhZGRp dGlvbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaW5mb3JtYXRpb24g YWJvdXQgdGhlIGRhdGEgZmxvd3MgKHdoZW4gY29tcGFyZWQgdG8gbmV0d29ya3MgdGhhdCBk bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBEZXROZXQgZmxvd3MgYXJl IGlkZW50aWZpZWQgb24gYSBwZXItZmxvdyBiYXNpcywgd2hpY2ggbWF5IHByb3ZpZGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbm90IGluY2x1ZGUgcGVyLWZsb3cg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+aWRlbnRpZmljYXRpb24pOyB0aGlzPC9zcGFuPiBpcyBh biBpbmhlcmVudCBwcm9wZXJ0eSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBhdHRhY2tlcnMgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBk YXRhIGZsb3dzICh3aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIERl dE5ldCB3aGljaCBoYXMgc2VjdXJpdHkgaW1wbGljYXRpb25zIHdoaWNoIDxzcGFuIGNsYXNz PSJkZWxldGUiPm11c3Q8L3NwYW4+IGJlIGNvbnNpZGVyZWQgd2hlbjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjb21wYXJlZCB0byBuZXR3b3JrcyB0aGF0IGRvIG5v dCBpbmNsdWRlIHBlci1mbG93IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmlkZW50aWZpY2F0aW9u KS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGRldGVybWlu aW5nIGlmIERldE5ldCBpcyBhIHN1aXRhYmxlIHRlY2hub2xvZ3kgZm9yIGFueSBnaXZlbiB1 c2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgVGhpczwvc3Bhbj4gaXMgYW4gaW5oZXJlbnQgcHJvcGVydHkgb2YgRGV0TmV0IHdo aWNoIGhhcyBzZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBj YXNlLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2ltaWxhciBjb25zaWRlcmF0aW9uIG1heSBu ZWVkIHRvIGJlIGdpdmVuIHRvIHRoZSB1c2Ugb2Y8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIGltcGxpY2F0aW9ucyB3aGljaCA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5zaG91bGQ8L3NwYW4+IGJlIGNvbnNpZGVyZWQgd2hlbiBkZXRlcm1pbmluZyBpZiBE ZXROZXQgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgcmVwbGljYXRlZCBwYWNrZXQgZmxvd3MsIHdoaWNoIHJlc3VsdCBpbiBp bmNyZWFzZWQgc3VyZmFjZSBmb3I8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIGEgc3VpdGFibGUgdGVjaG5vbG9neSBmb3IgYW55IGdpdmVuIHVzZSBjYXNl LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICBSZWNvbm5haXNzYW5jZSBhdHRhY2tzLiAgSW4gYW55IGNhc2UsIHRoZSByZXN1bHQg bXVzdCBiZSB0aGF0IHRoZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgZGF0YSBpcyBtYWludGFpbmVkIHRvIGEg ZGVncmVlIHN1ZmZpY2llbnQgZm9yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgdGhlIHVzZSBjYXNlcyBhZGRyZXNzZWQgYnkgdGhlIGdpdmVuIERldE5l dCBpbXBsZW1lbnRhdGlvbi48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBw cm92aWRlIHVuaW50ZXJydXB0ZWQgYXZhaWxhYmlsaXR5IG9mIHRoZSBEZXROZXQgcXVhbGl0 eSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRvIHByb3ZpZGUgdW5p bnRlcnJ1cHRlZCBhdmFpbGFiaWxpdHkgb2YgdGhlIERldE5ldCBxdWFsaXR5IG9mPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA4Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIHNlcnZpY2UsIHByb3Zpc2lvbnMgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+bXVzdDwvc3Bhbj4gYmUgbWFkZSBhZ2FpbnN0IERPUyBhdHRhY2tzIGFuZCBkZWxheTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzZXJ2aWNlLCBwcm92aXNpb25z IDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNhbjwvc3Bhbj4gYmUgbWFkZSBhZ2FpbnN0IERPUyBh dHRhY2tzIGFuZCBkZWxheTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXR0 YWNrcy4gIFRvIHByb3RlY3QgYWdhaW5zdCBET1MgYXR0YWNrcywgZXhjZXNzIHRyYWZmaWMg ZHVlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXR0YWNrcy4gIFRv IHByb3RlY3QgYWdhaW5zdCBET1MgYXR0YWNrcywgZXhjZXNzIHRyYWZmaWMgZHVlIHRvPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA5 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIG1hbGljaW91cyBvciBtYWxmdW5jdGlvbmluZyBkZXZpY2Vz IDxzcGFuIGNsYXNzPSJkZWxldGUiPm11c3Q8L3NwYW4+IGJlIHByZXZlbnRlZCBvciBtaXRp Z2F0ZWQsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG1hbGljaW91cyBv ciBtYWxmdW5jdGlvbmluZyBkZXZpY2VzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNhbjwvc3Bh bj4gYmUgcHJldmVudGVkIG9yIG1pdGlnYXRlZCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGZvciBleGFtcGxlIHRocm91Z2ggdGhlIHVzZSBvZiB0cmFmZmljIGFkbWlz c2lvbiBjb250cm9sIGFwcGxpZWQgYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBmb3IgZXhhbXBsZSB0aHJvdWdoIHRoZSB1c2Ugb2YgdHJhZmZpYyBhZG1pc3Npb24g Y29udHJvbCBhcHBsaWVkIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 aGUgaW5wdXQgb2YgYSBEZXROZXQgZG9tYWluLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjIuMSwgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIGlucHV0 IG9mIGEgRGV0TmV0IGRvbWFpbiwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLjEsIGFu ZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAxMCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aHJvdWdoIHRoZSBmYXVsdCBtaXRpZ2F0aW9uIG1l dGhvZHMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLjIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIHRocm91Z2ggdGhlIGZhdWx0IG1pdGlnYXRpb24gbWV0aG9kcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMuMi4gIFRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcHJldmVudCBEZXROZXQgcGFja2V0cyBmcm9tIGJlaW5nIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmRlbGF5ZWQgYnkgYW4gZW50aXR5IGV4dGVybmFsIHRvIGE8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRvIHByZXZlbnQgRGV0TmV0 IHBhY2tldHMgZnJvbSBiZWluZyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kZWxheWVkLCBwcm90 ZWN0aW9uIG11c3QgYmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIERldE5ldCBkb21haW4sIERldE5ldCB0ZWNobm9s b2d5IGRlZmluaXRpb24gY2FuIGFsbG93IGZvciB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHByb3ZpZGVkIGFn YWluc3Q8L3NwYW4+IE1hbi1Jbi1UaGUtTWlkZGxlIGF0dGFja3MsIGZvciBleGFtcGxlIHRo cm91Z2ggdXNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIG1pdGlnYXRpb24gb2Y8L3NwYW4+IE1hbi1Jbi1UaGUtTWlkZGxlIGF0 dGFja3MsIGZvciBleGFtcGxlIHRocm91Z2ggdXNlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIG9mIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9m IGRldmljZXMgd2l0aGluIHRoZSBEZXROZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gb2YgZGV2aWNlcyB3 aXRoaW4gdGhlIERldE5ldCBkb21haW4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGRvbWFpbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlRpbWUgc3luY2hyb25pemF0aW9uIG1l dGhvZHMgYXJlIG5vdCBzcGVjaWZpZWQgYnkgRGV0TmV0LCBob3dldmVyIGFueTwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHRpbWUgc3luY2hyb25pemF0 aW9uIG1ldGhvZCB1c2VkIHdpdGggRGV0TmV0IG11c3QgYWxzbyBiZSBzZWN1cmVkLDwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHVzaW5nIHRoZSBzZWN1 cml0eSBtZXRob2RzIGF2YWlsYWJsZSBmb3IgdGhlIGdpdmVuIHRpbWU8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBzeW5jaHJvbml6YXRpb24gbWVjaGFu aXNtLCBmb3IgZXhhbXBsZSBhcyBkZXNjcmliZWQgaW4gW1JGQzczODRdLjwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTEiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SW4gYW55IGNhc2UsIHRoZSByZXN1bHQg bXVzdCBiZTwvc3Bhbj4gdGhhdCA8c3BhbiBjbGFzcz0iZGVsZXRlIj50aGU8L3NwYW4+IERl dE5ldCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5pcyBwcm90ZWN0ZWQgZnJvbTwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ QmVjYXVzZSBEZXROZXQgbWVjaGFuaXNtcyBvciBhcHBsaWNhdGlvbnM8L3NwYW4+IHRoYXQg PHNwYW4gY2xhc3M9Imluc2VydCI+cmVseSBvbjwvc3Bhbj4gRGV0TmV0IDxzcGFuIGNsYXNz PSJpbnNlcnQiPmNhbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgRE9TLCBkZWxheSwgYW5kIHRpbWUgbWFuaXB1bGF0 aW9uIGF0dGFja3MgdG8gdGhlIGV4dGVudCBzdWZmaWNpZW50PC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBtYWtlIGhl YXZ5PC9zcGFuPiB1c2UgPHNwYW4gY2xhc3M9Imluc2VydCI+b2YgbWV0aG9kcyB0aGF0IHJl cXVpcmUgcHJlY2lzZSB0aW1lIHN5bmNocm9uaXphdGlvbiw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGZvciB0aGU8 L3NwYW4+IHVzZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5jYXNlcyBhZGRyZXNzZWQgYnk8L3Nw YW4+IHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5naXZlbiBEZXROZXQgaW1wbGVtZW50YXRp b24uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0aGUgPHNw YW4gY2xhc3M9Imluc2VydCI+YWNjdXJhY3ksIGF2YWlsYWJpbGl0eSwgYW5kIGludGVncml0 eSBvZiB0aW1lIHN5bmNocm9uaXphdGlvbiBpczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIG9mIGNyaXRpY2FsIGltcG9ydGFuY2UuICBFeHRlbnNpdmUg ZGlzY3Vzc2lvbiBvZiB0aGlzIHRvcGljIGNhbiBiZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgIGZvdW5kIGluIFtSRkM3Mzg0XS48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERldE5ldCB1c2UgY2Fz ZXMgYXJlIGtub3duIHRvIGhhdmUgd2lkZWx5IGRpdmVyZ2VudCBzZWN1cml0eTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERldE5ldCB1c2UgY2FzZXMgYXJlIGtub3du IHRvIGhhdmUgd2lkZWx5IGRpdmVyZ2VudCBzZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgcmVxdWlyZW1lbnRzLiAgVGhlIGludGVudCBvZiB0aGlzIHNlY3Rp b24gaXMgdG8gcHJvdmlkZSBhIGJhc2VsaW5lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcmVxdWlyZW1lbnRzLiAgVGhlIGludGVudCBvZiB0aGlzIHNlY3Rpb24gaXMg dG8gcHJvdmlkZSBhIGJhc2VsaW5lPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBmb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2ggYXJlIGNvbW1vbiB0byBhbGwg RGV0TmV0IGRlc2lnbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3Ig c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2ggYXJlIGNvbW1vbiB0byBhbGwgRGV0TmV0 IGRlc2lnbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCBpbXBsZW1l bnRhdGlvbnMsIHdpdGhvdXQgYnVyZGVuaW5nIGluZGl2aWR1YWwgZGVzaWducyB3aXRoPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIGltcGxlbWVudGF0aW9ucywg d2l0aG91dCBidXJkZW5pbmcgaW5kaXZpZHVhbCBkZXNpZ25zIHdpdGg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmljcyBvZiBzZWN1cml0eSBpbmZyYXN0cnVj dHVyZSB3aGljaCBtYXkgbm90IGJlIGdlcm1hbmUgdG8gdGhlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWNzIG9mIHNlY3VyaXR5IGluZnJhc3RydWN0dXJl IHdoaWNoIG1heSBub3QgYmUgZ2VybWFuZSB0byB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGdpdmVuIHVzZSBjYXNlLiAgRGVzaWduZXJzIGFuZCBJbXBsZW1lbnRl cnMgb2YgRGV0TmV0IHN5c3RlbXMgYXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgZ2l2ZW4gdXNlIGNhc2UuICBEZXNpZ25lcnMgYW5kIEltcGxlbWVudGVycyBvZiBE ZXROZXQgc3lzdGVtcyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4 cGVjdGVkIHRvIHRha2UgdXNlIGNhc2Ugc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMgaW50byBh Y2NvdW50IGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhwZWN0ZWQg dG8gdGFrZSB1c2UgY2FzZSBzcGVjaWZpYyBjb25zaWRlcmF0aW9ucyBpbnRvIGFjY291bnQg aW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZWlyIERldE5ldCBkZXNp Z25zIGFuZCBpbXBsZW1lbnRhdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdGhlaXIgRGV0TmV0IGRlc2lnbnMgYW5kIGltcGxlbWVudGF0aW9ucy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2NvbG9yPSJncmF5Ij48 dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDEx IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMi Pjx0ZD48L3RkPjx0aD48aT40NSBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48 dGg+PGk+IDwvaT48L3RoPjx0aD48aT4zNyBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwv dGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50 ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkg cmZjZGlmZiAxLjQ3LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEg aHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6 Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3Rh YmxlPgogICA8L2JvZHk+CiAgIDwvaHRtbD4K --------------9A8FF83CD59895F99BBB2518-- From nobody Tue Mar 5 14:16: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 EA5D7130DE4 for ; Tue, 5 Mar 2019 14:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id davcJVfK95uO for ; Tue, 5 Mar 2019 14:16: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 994BF130E16 for ; Tue, 5 Mar 2019 14:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551824203; x=1554416203; 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=mHcNNr2J9aFXnvVdHoghGQxxMcPK8sWu/opVLGfjzPw=; b=YQbOew9+TLslLr3YfNs+c6tJaz/nLkstaD6VEBLkURHEdF6QaGeZvSIAB/FvFJLv qIuIIutkvXS/U7Ykoyy42k8ILX/jURrhC1BM2ZpN04sTQ3zuXwreyjNpGh2VXXxk FYGMCJ1Np7fE9q9Q61ZoLwaZRlBrqOrafu5KOEQfM5U=; X-AuditID: c1b4fb2d-db5ff7000000062f-a6-5c7ef54b8ebc Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4F.6B.01583.B45FE7C5; Tue, 5 Mar 2019 23:16:43 +0100 (CET) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 23:16:42 +0100 Received: from [100.94.49.140] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.192) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 23:16:42 +0100 To: Benjamin Kaduk References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> <1cd55c7d-6d1c-b56f-38d3-d6bd78b004e2@ericsson.com> <20190304034131.GN53396@kduck.mit.edu> CC: , DetNet WG , Lou Berger , The IESG , "detnet-chairs@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <248e64f0-a2d8-a70c-e3fa-ad7047c6ff20@ericsson.com> Date: Tue, 5 Mar 2019 23:16:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190304034131.GN53396@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------58130BF58CBD16A337892626" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbG9XNf7a12MwcTfchbX+n+wWPz+NJvF 4sO3mSwWM/5MZLZYvnEmk0VH81sWBzaPJUt+Mnl82NTM5tF05ihzAHMUl01Kak5mWWqRvl0C V0br8Wb2gp03mSruf33D2sC4soupi5GTQ0LAROLGrOdANheHkMARRonT169BOV+BnC8tLBDO YUaJLav+M4K0CAsUSlxYOBXMFhFQklh8toUNomgNo0Tf+lVg7cwCuxglOvvWs4BUsQnYS9y9 tIEZxOYFsmduuAHWzSKgIrHq1ExWEFtUIFbi05XFUDWCEidnPgHr5RQwlvi68BlYPbNAmMTU Hd+gbHGJW0/mgz0hJKAm8entQ/YJjIKzkLTPQtIyC0kLhG0hMXP+eai4vETz1tnMELaGROuc uezI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbTwS2/dXcwrn7teIhRgINRiYfX /0FdjBBrYllxZe4hRgkOZiURXs8PQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8f4QEY4QE0hNL UrNTUwtSi2CyTBycUg2M2Rq+36f2cBxbcemsye1pl5++sFfr5t3Q81ToiY7BnolqjA35e7ax 28b8Ln637V7NBL5TGZtLJ2z+7PmpU9jJ9Mz2Cfk7Tncv+/DE8K/o1L6PHSf5La4c89qr3vRQ ISkoprsr9luc3ttE8+fHrRv0NAQPW0fkb/vh7MHz+f8C54oc+/ZDjbI/lFiKMxINtZiLihMB 5xN9naICAAA= Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 22:16:54 -0000 --------------58130BF58CBD16A337892626 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin, Please see in-line some further suggested changes based on your comments. On 3/4/2019 4:41 AM, Benjamin Kaduk wrote: > On Sat, Mar 02, 2019 at 09:12:23PM +0100, János Farkas wrote: >> Hi Benjamin, >> >> Coming to your detailed comments. >> Please see in-line. >> >> Thank you, >> Janos >> >> >> On 2/20/2019 4:44 AM, Benjamin Kaduk wrote: >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> Abstract >>> >>> DetNet operates at the IP layer and >>> delivers service over sub-network technologies such as MPLS and IEEE >>> 802.1 Time-Sensitive Networking (TSN). >>> >>> I don't know what "sub-network technologies" means. (Should I? Is it >>> defined somewhere we can reference?) >>> >>> More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network" >>> that lies between specific layers or classes of layer? Does DetNet >>> itself have component "sub-layers" that provide distinct DetNet >>> functionality? These are good questions to address early on in the >>> document so the reader is familiar with the concepts as they progress >>> through the document. >> Please note that the WG has reached consensus on introducing the term >> "sub-layer", in particular using the terms "DetNet Service sub-layer" >> and DetNet Forwarding sub-layer", see: >> https://mailarchive.ietf.org/arch/msg/detnet/TR6oXu7IMWhelrH_I-tOuHGfDqo. >> These are explained in detail in Section 4. DetNet Architecture. I do >> not see how to bring it earlier in the document. > That's a fair point. I guess I would consider adding a Terminology entry > for "Sub-layer" that notes that "The DetNet architecture divides the DetNet > functionality into two sub-layers, the forwarding sub-layer and the service > sub-layer.", but use your judgement. I suggest to extend the definitions of the two sub-layers instead of introducing a new one: OLD:    DetNet forwarding sub-layer            The DetNet layer that optionally provides resource allocation            for DetNet flows over paths provided by the underlying            network.    DetNet service sub-layer            The DetNet sub-layer at which A DetNet service, e.g., service            protection is provided. NEW:    DetNet forwarding sub-layer:                   DetNet functionality is divided into two sub-layers. One of                   them is the DetNet forwarding sub-layer, which optionally                   provides resource allocation for DetNet flows over paths                   provided by the underlying network.    DetNet service sub-layer:                   DetNet functionality is divided into two sub-layers. One of                   them is the DetNet service sub-layer, at which a DetNet service,                   e.g., service protection is provided. > >> Section 4. DetNet Architecture also explains what is meant by >> sub-network. Figure 3 shows it and the text above Figure 3 explains. >> I don't see how could be this explanation earlier in the document. >> >> As for the abstract, would it help to replace?: >> >> OLD: >> DetNet operates at the IP layer and >>    delivers service over sub-network technologies such as MPLS and IEEE >>    802.1 Time-Sensitive Networking (TSN). >> >> with >> >> NEW: >> DetNet operates at the IP layer and >>    delivers service over lower layer technologies such as MPLS and IEEE >>    802.1 Time-Sensitive Networking (TSN). >> >> Similar replacement could be done in the introduction: >> >> OLD: >>    DetNet operates at the IP layer and delivers service over sub-network >>    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking >>    (TSN). >> >> NEW: >>    DetNet operates at the IP layer and delivers service over lower layer >>    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking >>    (TSN). >> >> >> The next occurrence of sub-network is with a cross-reference to the >> section with Figure 3 and description. I think it is fine this way as >> the reader can jump there and check the details. > I agree; these two replacements in abstract+introduction would alleviate > the main question of whether this usage is some existing well-known thing > that the reader should be familiar with, and the rest of the document is > well-contained. > >>> Section 1 >>> >>> 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. >>> >>> side note: Campus-wide networks at educational institutions are basically >>> guaranteed to have untrusted entities participating in them, just as a >>> backdrop for security considerations. >>> >>> Section 3.1 >>> >>> This mechanism distributes the contents of >>> DetNet flows over multiple paths in time and/or space, so that the >>> loss of some of the paths does need not cause the loss of any >>> >>> The failure models for which this statement is absolutely true as opposed >>> to probabilistically true seem rather unrealistic models of real physical >>> systems. >>> >>> Section 3.2.1.1 >>> >>> The primary means by which DetNet achieves its QoS assurances is to >>> reduce, or even completely eliminate packet loss due to output packet >>> contention within a DetNet node as a cause of packet loss. [...] >>> >>> editing error? >>> >>> Note that App-flows are generally >>> not expected to be responsive to implicit [RFC2914] or explicit >>> congestion notification [RFC3168]. >>> >>> I note that the word "implicit" does not appear in RFC 2914; it may be >>> worth a bit more detailed of a mapping from concept to reference. >>> (This text/reference also appears in Section 4.3.2.) >> Would it help to change the text?: >> >> OLD: >>    There is no expectation in DetNet for App-flows to be responsive to >>    implicit [RFC2914] or explicit congestion notification [RFC3168]. >> >> NEW: >>    There is no expectation in DetNet for App-flows to be responsive to >>    congestion control [RFC2914] or explicit congestion notification >> [RFC3168]. > Sure, thanks. > >>> Section 3.2.1.2 >>> >>> In >>> general, users are encouraged to use, instead of, "do this when you >>> get the packet," a combination of: >>> >>> It seems that an architecture would be within its rights to *mandate* such >>> application design, rather than just encourage it. What sorts of >>> exceptions would cause us to not want to mandate this design? >> This is not mandatory. >> For instance, it is not mandatory to use time synchronization. There may >> be DetNet services that do not require time synchronization. > I was basically asking if you could list an example for me (here in email, > not necessarily in the document). There may be a DetNet service with very strict loss requirement, but not that strict delay and jitter requirement. In this case, we may not need any fine tuned QoS technique to address delay. However, we need PREOF to address loss. Time synchronization is not needed in this example. > >>> Section 3.2.2.2 >>> >>> Please expand SRLG (it is only used once, so the abbreviation itself may >>> not be needed at all). >> Replace "SRLG" with "Shared Risk Link Group (SRLG)" >> >>> Section 3.2.3 >>> >>> Out-of-order packet delivery can be a side effect of distributing a >>> single flow over multiple paths especially when there is a change >>> from one path to another when combining the flow. [...] >>> >>> nit: comma before "especially". >> Add comma. >> >>> Resource allocation >>> The DetNet forwarding sub-layer provides resource allocation. >>> See Section 4.5. The actual queuing and shaping mechanisms >>> are typically provided by underlying subnet, these can be >>> >>> nit: is this usage of "subnet" common? >> Figure 3 shows it and the text above Figure 3 explains sub-net. >> >>> Also, this comma looks to be a comma splice. >> Make it two sentences. >> >>> closely associated with the means of providing paths for >>> DetNet flows, the path and the resource allocation are >>> conflated in this figure. >>> >>> nit: Hmm, actually, is this comma *also* a comma splice? >> Make it two sentences. >> >>> Operations, Administration, and Maintenance (OAM) leverages in-band >>> and out-of-band signaling that validates whether the service is >>> effectively obtained within QoS constraints. [...] >>> >>> nit: is there a singular/plural mismatch here ("the service"/"service" vs. >>> "effectively within"/"effectively obtained within")? >> Seems good to me. >> >>> Section 4.1.1 >>> >>> This figure would have helped me a lot several sections earlier. >>> >>> Section 4.1.2 >>> >>> A "Deterministic Network" will be composed of DetNet enabled end >>> systems, DetNet edge nodes, DetNet relay nodes and collectively >>> deliver DetNet services. DetNet relay and edge nodes are >>> >>> Nit: I think this is intended to be: >>> A "Deterministic Network" will be composed of DetNet-enabled end >>> systems, DetNet edge nodes, and DetNet relay nodes, which collectively >>> deliver DetNet services. DetNet relay and edge nodes are >> Fine by me to make the cahnge. >> >>> Examples of >>> sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. [...] >>> >>> nit: are these sub-networks or protocols used by sub-networks? >> These are sub-network technologies. They may include/use multiple protocols. > Should this be "examples of sub-networking technologies" then? That would be clearer phrasing. Replace "Examples of sub-networks include MPLS TE, IEEE 802.1 TSN and OTN." with "Examples of sub-network technologies include MPLS TE, IEEE 802.1 TSN and OTN." (sub-networking sounds a bit strange to me, not used in the document) > >>> Distinguishing the function of two DetNet data plane sub-layers, the >>> DetNet service sub-layer and the DetNet forwarding sub-layer, helps >>> to explore and evaluate various combinations of the data plane >>> solutions available, some are illustrated in Figure 4. This >>> >>> nit: this last comma is a comma splice. >> Suggest to replace with: >> "DetNet data plane is divided into two sub-layers: the >> DetNet service sub-layer and the DetNet forwarding sub-layer. >> This helps to explore and evaluate various combinations of the data plane >> solutions available. Some of them are illustrated in Figure 4." >> (https://mailarchive.ietf.org/arch/msg/detnet/JvPTAFVTJwxjhzZYEF9uCnUTFBA) > Thanks. > >>> There are many valid options to create a data plane solution for >>> DetNet traffic by selecting a technology approach for the DetNet >>> service sub-layer and also selecting a technology approach for the >>> DetNet forwarding sub-layer. There are a high number of valid >>> combinations. >>> >>> nit: I think "large number" is more conventional prose. >> Replace "high number" with "large number". >> >>> Section 4.3.1 >>> >>> I think I'm confused about how, for these flows that "require the >>> feature", whether that means that the DetNet implementation must provide >>> , or that it is required for the application to have implemented the >>> feature. A mapping (if it makes sense) to the categorization of end >>> systems in Section 4.2.1 would be a big help. >> The notation is crafted such that to provide mapping. > I inferred that intent, yet. I'm claiming that "It only requires" confused > me about which entity required what. Changing to "It only uses" would > remove that confusion (but would implicitly deny the ability for > opportunistic use of other features, so is not a perfect replacement). We can make it clearer. What about the following update: OLD: A DetNet flow can have different formats while its packets are forwarded between the peer end systems. Therefore, the following possible types / formats of a DetNet flow are distinguished in this document: o App-flow: native format of the data carried over a DetNet flow. It does not contain any DetNet related attributes. NEW: A DetNet flow can have different formats while its packets are forwarded between the peer end systems depending on the type of the end systems. Corresponding to the end system types,  the following possible types / formats of a DetNet flow are distinguished in this document. The different flow types have different requirements to DetNet nodes. o App-flow: native format of the data carried over a DetNet flow between DetNet unaware end systems. An app-flow does not contain any DetNet related attributes and does not imply any specific requirement on DetNet nodes. > >>> Section 4.3.2 >>> >>> Asynchronous DetNet flows are characterized by: >>> >>> o A maximum packet size; >>> >>> o An observation interval; and >>> >>> o A maximum number of transmissions during that observation >>> interval. >>> >>> Is there necessarily only a single tier of observation interval/rate? >>> (E.g., could there be a burst cap in a small interval and then a lower >>> overall baseline rate over large intervals?) >> We intentionally have a simple model here. > OK. > >>> That is, while any useful application is written to >>> expect a certain number of lost packets, the real-time applications >>> of interest to DetNet demand that the loss of data due to the network >>> is a rare event. >>> >>> (I might even go with "vanishingly rare".) >> Yes, there are extremely low loss requirements in certain use cases. >> That's why we have PREOF. >> >>> Section 4.4.1 >>> >>> (Is there a standard reference for "Northbound"? I know we're all used to >>> it, but it's probably best to have a reference if we can.) >> RFC7426 is a reference. It is cited at the very beginning of the section. >> >>> Section 4.4.2 >>> >>> The deterministic sequence can >>> typically be more complex than a direct sequence and include >>> redundancy path, with one or more packet replication and elimination >>> points. [...] >>> >>> nit: "redundancy paths", plural? >> Replace "redundancy paths", "redundant paths". >> >> >>> Section 4.8 >>> >>> How does *provisioning* require knowledge of *dynamic* state? >> I guess the idea was that the resource may change dynamically. >> >> Would it help to delete "dynamic"? >> Thus get: "The state of a DetNet node's DetNet resources." > That would probably help, yes. Maybe even "The current state", but I > didn't think about it very hard. > >>> Section 4.9 >>> >>> Does aggregation like this pose a risk of all the aggregatees getting >>> affected when one exceeds their allocation substantially (so as to also >>> cause the aggregate to exceed the aggregate's allocation)? >> One way could be to apply rate limitation for each member flow being >> aggregated at the input of the aggregate flow. The need to apply rate >> limitation is explained at multiple places in the document. > OK > >>> Section 6 >>> >>> The ability for an attacker to use QoS markings as part of traffic >>> correlation/inspection is not new with DetNet, but is probably still worth >>> mentioning explicitly. >> Do you mean mention it in Section 5 Security Considerations? > That's not what I had in mind, no. I was thinking > > OLD: > DetNet is provides a Quality of Service (QoS), and as such, does not > directly raise any new privacy considerations. > > NEW: > DetNet provides a Quality of Service (QoS) mechanism, and the generic > considerations for such mechanisms apply. In particular, such markings > allow for an attacker to correlate flows or to select particular types > of flow for more detailed inspection. Looks good to me. (the word "attacker" made me unsure whether it goes to security) Combining with the change in https://mailarchive.ietf.org/arch/msg/detnet/QqUWlFnG9iJl5qXnuprPC6J4rDo, we'd get: NEW:    DetNet provides a Quality of Service (QoS) mechanism, and the generic    considerations for such mechanisms apply.  In particular, such markings    allow for an attacker to correlate flows or to select particular types    of flow for more detailed inspection.    DetNet provides a Quality of Service (QoS), and as such, is not expected to    directly raise any new privacy considerations, the generic considerations    for such mechanisms apply.  In particular, such markings allow for an   attacker to correlate flows or to select particular types of flow for more   detailed inspection. > >> The text in my previous mail >> (https://mailarchive.ietf.org/arch/msg/detnet/mOzgdXOJ5lGr4gLBGAapYt6Azl8) >> has a paragraph starting: >> "To provide uninterrupted availability of the DetNet quality of service, >> provisions must be made against DOS attacks and delay attacks." >> >> Would it be good to extend that paragraph with a sentence, e.g.,?: >> "Malicious QoS marking should be also considered". > I wouldn't oppose something like that, but it may not be needed in the > architecture document (as opposed to the documents that actually describe > the QoS markings). OK, leave it then out from the architecture document. Thank you, Janos > > -Benjamin > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------58130BF58CBD16A337892626 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Benjamin,

Please see in-line some further suggested changes based on your comments.

On 3/4/2019 4:41 AM, Benjamin Kaduk wrote:
On Sat, Mar 02, 2019 at 09:12:23PM +0100, János Farkas wrote:

Hi Benjamin,

Coming to your detailed comments.
Please see in-line.

Thank you,
Janos


On 2/20/2019 4:44 AM, Benjamin Kaduk wrote:

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



Abstract

                                  DetNet operates at the IP layer and
    delivers service over sub-network technologies such as MPLS and IEEE
    802.1 Time-Sensitive Networking (TSN).

I don't know what "sub-network technologies" means.  (Should I?  Is it
defined somewhere we can reference?)

More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network"
that lies between specific layers or classes of layer?  Does DetNet
itself have component "sub-layers" that provide distinct DetNet
functionality?  These are good questions to address early on in the
document so the reader is familiar with the concepts as they progress
through the document.

Please note that the WG has reached consensus on introducing the term 
"sub-layer", in particular using the terms "DetNet Service sub-layer" 
and DetNet Forwarding sub-layer", see: 
https://mailarchive.ietf.org/arch/msg/detnet/TR6oXu7IMWhelrH_I-tOuHGfDqo.
These are explained in detail in Section 4. DetNet Architecture. I do 
not see how to bring it earlier in the document.

That's a fair point.  I guess I would consider adding a Terminology entry
for "Sub-layer" that notes that "The DetNet architecture divides the DetNet
functionality into two sub-layers, the forwarding sub-layer and the service
sub-layer.", but use your judgement.
I suggest to extend the definitions of the two sub-layers instead of introducing a new one:

OLD:

   DetNet forwarding sub-layer
           The DetNet layer that optionally provides resource allocation
           for DetNet flows over paths provided by the underlying
           network.

   DetNet service sub-layer
           The DetNet sub-layer at which A DetNet service, e.g., service
           protection is provided.


NEW:

   DetNet forwarding sub-layer:
                  DetNet functionality is divided into two sub-layers. One of
                  them is the DetNet forwarding sub-layer, which optionally
                  provides resource allocation for DetNet flows over paths
                  provided by the underlying network.

   DetNet service sub-layer:
                  DetNet functionality is divided into two sub-layers. One of
                  them is the DetNet service sub-layer, at which a DetNet service,
                  e.g., service protection is provided.




Section 4. DetNet Architecture also explains what is meant by 
sub-network. Figure 3 shows it and the text above Figure 3 explains.
I don't see how could be this explanation earlier in the document.

As for the abstract, would it help to replace?:

OLD:
DetNet operates at the IP layer and
    delivers service over sub-network technologies such as MPLS and IEEE
    802.1 Time-Sensitive Networking (TSN).

with

NEW:
DetNet operates at the IP layer and
    delivers service over lower layer technologies such as MPLS and IEEE
    802.1 Time-Sensitive Networking (TSN).

Similar replacement could be done in the introduction:

OLD:
    DetNet operates at the IP layer and delivers service over sub-network
    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking
    (TSN).

NEW:
    DetNet operates at the IP layer and delivers service over lower layer
    technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking
    (TSN).


The next occurrence of sub-network is with a cross-reference to the 
section with Figure 3 and description. I think it is fine this way as 
the reader can jump there and check the details.

I agree; these two replacements in abstract+introduction would alleviate
the main question of whether this usage is some existing well-known thing
that the reader should be familiar with, and the rest of the document is
well-contained.



        

          
Section 1

                           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.

side note: Campus-wide networks at educational institutions are basically
guaranteed to have untrusted entities participating in them, just as a
backdrop for security considerations.

Section 3.1

                         This mechanism distributes the contents of
    DetNet flows over multiple paths in time and/or space, so that the
    loss of some of the paths does need not cause the loss of any

The failure models for which this statement is absolutely true as opposed
to probabilistically true seem rather unrealistic models of real physical
systems.

Section 3.2.1.1

    The primary means by which DetNet achieves its QoS assurances is to
    reduce, or even completely eliminate packet loss due to output packet
    contention within a DetNet node as a cause of packet loss.  [...]

editing error?

                                      Note that App-flows are generally
    not expected to be responsive to implicit [RFC2914] or explicit
    congestion notification [RFC3168].

I note that the word "implicit" does not appear in RFC 2914; it may be
worth a bit more detailed of a mapping from concept to reference.
(This text/reference also appears in Section 4.3.2.)


        

        
Would it help to change the text?:

OLD:
    There is no expectation in DetNet for App-flows to be responsive to
    implicit [RFC2914] or explicit congestion notification [RFC3168].

NEW:
    There is no expectation in DetNet for App-flows to be responsive to
    congestion control [RFC2914] or explicit congestion notification 
[RFC3168].


      

      
Sure, thanks.



      

        

        

          
Section 3.2.1.2

                                                                    In
    general, users are encouraged to use, instead of, "do this when you
    get the packet," a combination of:

It seems that an architecture would be within its rights to *mandate* such
application design, rather than just encourage it.  What sorts of
exceptions would cause us to not want to mandate this design?


        

        
This is not mandatory.
For instance, it is not mandatory to use time synchronization. There may 
be DetNet services that do not require time synchronization.


      

      
I was basically asking if you could list an example for me (here in email,
not necessarily in the document).

    

    There may be a DetNet service with very strict loss requirement, but
    not that strict delay and jitter requirement. In this case, we may
    not need any fine tuned QoS technique to address delay. However, we
    need PREOF to address loss. Time synchronization is not needed in
    this example.

    

    

    

      



      

        

        

          
Section 3.2.2.2

Please expand SRLG (it is only used once, so the abbreviation itself may
not be needed at all).


        

        
Replace "SRLG" with "Shared Risk Link Group (SRLG)"



        

          
Section 3.2.3

    Out-of-order packet delivery can be a side effect of distributing a
    single flow over multiple paths especially when there is a change
    from one path to another when combining the flow.  [...]

nit: comma before "especially".


        

        
Add comma.



        

          
    Resource allocation
            The DetNet forwarding sub-layer provides resource allocation.
            See Section 4.5.  The actual queuing and shaping mechanisms
            are typically provided by underlying subnet, these can be

nit: is this usage of "subnet" common?


        

        
Figure 3 shows it and the text above Figure 3 explains sub-net.



        

          
Also, this comma looks to be a comma splice.


        

        
Make it two sentences.



        

          
            closely associated with the means of providing paths for
            DetNet flows, the path and the resource allocation are
            conflated in this figure.

nit: Hmm, actually, is this comma *also* a comma splice?


        

        
Make it two sentences.



        

          
    Operations, Administration, and Maintenance (OAM) leverages in-band
    and out-of-band signaling that validates whether the service is
    effectively obtained within QoS constraints.  [...]

nit: is there a singular/plural mismatch here ("the service"/"service" vs.
"effectively within"/"effectively obtained within")?


        

        
Seems good to me.



        

          
Section 4.1.1

This figure would have helped me a lot several sections earlier.

Section 4.1.2

    A "Deterministic Network" will be composed of DetNet enabled end
    systems, DetNet edge nodes, DetNet relay nodes and collectively
    deliver DetNet services.  DetNet relay and edge nodes are

Nit: I think this is intended to be:
A "Deterministic Network" will be composed of DetNet-enabled end
systems, DetNet edge nodes, and DetNet relay nodes, which collectively
deliver DetNet services.  DetNet relay and edge nodes are


        

        
Fine by me to make the cahnge.



        

          
                                                              Examples of
    sub-networks include MPLS TE, IEEE 802.1 TSN and OTN.  [...]

nit: are these sub-networks or protocols used by sub-networks?


        

        
These are sub-network technologies. They may include/use multiple protocols.


      

      
Should this be "examples of sub-networking technologies" then?

    

    That would be clearer phrasing.

    Replace 

    "Examples of sub-networks include MPLS TE, IEEE 802.1 TSN and OTN."
    

    with 

    "Examples of sub-network technologies include MPLS TE, IEEE 802.1
    TSN and OTN." 

    

    (sub-networking sounds a bit strange to me, not used in the
    document)

    

    

    

      



      

        

        

          
    Distinguishing the function of two DetNet data plane sub-layers, the
    DetNet service sub-layer and the DetNet forwarding sub-layer, helps
    to explore and evaluate various combinations of the data plane
    solutions available, some are illustrated in Figure 4.  This

nit: this last comma is a comma splice.


        

        
Suggest to replace with:
"DetNet data plane is divided into two sub-layers: the
DetNet service sub-layer and the DetNet forwarding sub-layer.
This helps to explore and evaluate various combinations of the data plane
solutions available. Some of them are illustrated in Figure 4."
(https://mailarchive.ietf.org/arch/msg/detnet/JvPTAFVTJwxjhzZYEF9uCnUTFBA)


      

      
Thanks.



      

        

          
    There are many valid options to create a data plane solution for
    DetNet traffic by selecting a technology approach for the DetNet
    service sub-layer and also selecting a technology approach for the
    DetNet forwarding sub-layer.  There are a high number of valid
    combinations.

nit: I think "large number" is more conventional prose.


        

        
Replace "high number" with "large number".



        

          
Section 4.3.1

I think I'm confused about how, for these flows that "require the <foo>
feature", whether that means that the DetNet implementation must provide
<foo>, or that it is required for the application to have implemented the
<foo> feature.  A mapping (if it makes sense) to the categorization of end
systems in Section 4.2.1 would be a big help.


        

        
The notation is crafted such that to provide mapping.


      

      
I inferred that intent, yet.  I'm claiming that "It only requires" confused
me about which entity required what.  Changing to "It only uses" would
remove that confusion (but would implicitly deny the ability for
opportunistic use of other features, so is not a perfect replacement).

    

    We can make it clearer. What about the following update:

    

    OLD:

    
   A DetNet flow can have different formats while its packets are
   forwarded between the peer end systems.  Therefore, the following
   possible types / formats of a DetNet flow are distinguished in this
   document:

    
   o  App-flow: native format of the data carried over a DetNet flow.
      It does not contain any DetNet related attributes.

    

    NEW:

    
   A DetNet flow can have different formats while its packets are
   forwarded between the peer end systems depending on the type
   of the end systems.  Corresponding to the end system types,
   the following possible types / formats of a DetNet flow are 
   distinguished in this document. The different flow types have
   different requirements to DetNet nodes.

    
   o  App-flow: native format of the data carried over a DetNet flow
      between DetNet unaware end systems. An app-flow does not
      contain any DetNet related attributes and does not imply any
      specific requirement on DetNet nodes.

    

    

    

    

      



      

        

        

          
Section 4.3.2

    Asynchronous DetNet flows are characterized by:

    o  A maximum packet size;

    o  An observation interval; and

    o  A maximum number of transmissions during that observation
       interval.

Is there necessarily only a single tier of observation interval/rate?
(E.g., could there be a burst cap in a small interval and then a lower
overall baseline rate over large intervals?)


        

        
We intentionally have a simple model here.


      

      
OK.



      

        

        

          
                      That is, while any useful application is written to
    expect a certain number of lost packets, the real-time applications
    of interest to DetNet demand that the loss of data due to the network
    is a rare event.

(I might even go with "vanishingly rare".)


        

        
Yes, there are extremely low loss requirements in certain use cases. 
That's why we have PREOF.



        

          
Section 4.4.1

(Is there a standard reference for "Northbound"?  I know we're all used to
it, but it's probably best to have a reference if we can.)


        

        
RFC7426 is a reference. It is cited at the very beginning of the section.



        

          
Section 4.4.2

                                          The deterministic sequence can
    typically be more complex than a direct sequence and include
    redundancy path, with one or more packet replication and elimination
    points.  [...]

nit: "redundancy paths", plural?


        

        
Replace "redundancy paths", "redundant paths".




        

          
Section 4.8

How does *provisioning* require knowledge of *dynamic* state?


        

        
I guess the idea was that the resource may change dynamically.

Would it help to delete "dynamic"?
Thus get: "The state of a DetNet node's DetNet resources."


      

      
That would probably help, yes.  Maybe even "The current state", but I
didn't think about it very hard.



      

        

          
Section 4.9

Does aggregation like this pose a risk of all the aggregatees getting
affected when one exceeds their allocation substantially (so as to also
cause the aggregate to exceed the aggregate's allocation)?


        

        
One way could be to apply rate limitation for each member flow being 
aggregated at the input of the aggregate flow. The need to apply rate 
limitation is explained at multiple places in the document.


      

      
OK



      

        

          
Section 6

The ability for an attacker to use QoS markings as part of traffic
correlation/inspection is not new with DetNet, but is probably still worth
mentioning explicitly.


        

        
Do you mean mention it in Section 5 Security Considerations?


      

      
That's not what I had in mind, no. I was thinking

OLD:
   DetNet is provides a Quality of Service (QoS), and as such, does not
   directly raise any new privacy considerations.

NEW:
   DetNet provides a Quality of Service (QoS) mechanism, and the generic
   considerations for such mechanisms apply.  In particular, such markings
   allow for an attacker to correlate flows or to select particular types
   of flow for more detailed inspection.

    

    Looks good to me. (the word "attacker" made me unsure whether it
    goes to security)

    Combining with the change in
    https://mailarchive.ietf.org/arch/msg/detnet/QqUWlFnG9iJl5qXnuprPC6J4rDo,
    we'd get:

    

    NEW:

       DetNet provides a Quality of Service (QoS) mechanism, and the
    generic

       considerations for such mechanisms apply.  In particular, such
    markings

       allow for an attacker to correlate flows or to select particular
    types

       of flow for more detailed inspection.

    

       DetNet provides a Quality of Service (QoS), and as such, is not
    expected to

       directly raise any new privacy considerations, the generic
    considerations

       for such mechanisms apply.  In particular, such markings allow
    for an

      attacker to correlate flows or to select particular types of flow
    for more

      detailed inspection.

    

    

    

      



      

        
The text in my previous mail 
(https://mailarchive.ietf.org/arch/msg/detnet/mOzgdXOJ5lGr4gLBGAapYt6Azl8) 
has a paragraph starting:
"To provide uninterrupted availability of the DetNet quality of service, 
provisions must be made against DOS attacks and delay attacks."

Would it be good to extend that paragraph with a sentence, e.g.,?: 
"Malicious QoS marking should be also considered".


      

      
I wouldn't oppose something like that, but it may not be needed in the
architecture document (as opposed to the documents that actually describe
the QoS markings).

    

    OK, leave it then out from the architecture document.

    

    Thank you,

    Janos

    

    

      

-Benjamin

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


    

    

  


--------------58130BF58CBD16A337892626--


From nobody Tue Mar  5 15:02:46 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 A0D041200D8 for ; Tue,  5 Mar 2019 15:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rVTtPp6aVeN for ; Tue,  5 Mar 2019 15:02:37 -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 2FE3C130DE3 for ; Tue,  5 Mar 2019 15:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1551824255; x=1554416255; 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=cyMQE7pOMPo7DB5MnOxcSvewafUHaGR2B/JilK7gZzE=; b=FyqsjTy66hON/GsvfYXeW164Et+aLzAcY1aqFrcqgTWGB383CpKIDLOFr6HHNPKt DMue+eRCSG+FJ2u8lo+6RD3p6VNtG/Hqb8wrhp3weKt4oMrQtlbmO/oWBmC6Lwf1 aHe2SXkn50tytatG5l1Qw7LtMdnr+/tddTEWrRNFrrg=;
X-AuditID: c1b4fb2d-db5ff7000000062f-2c-5c7ef57f63ff
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.8B.01583.F75FE7C5; Tue,  5 Mar 2019 23:17:35 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 23:17:34 +0100
Received: from [100.94.49.140] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.189) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 23:17:34 +0100
To: "Andrew G. Malis" , detnet WG 
References: 
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <1f19f75a-ecce-dfc5-64bb-a01be8d2a478@ericsson.com>
Date: Tue, 5 Mar 2019 23:17:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------726AFCE03D9987F047C287D4"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2J7qW7917oYg1uPmCxOPz/FZvH702wW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj8MPZrAULiype3BJtYHwX1cXIwSEhYCLx uIG1i5GLQ0jgCKPEtU13gRxOIOcro8Sv854QicOMEls3vmcGSQgLhEh0TdjIBGKLCLhJTHx3 lxGiIUBielsPWDObgL3E3UsbwOp5gexFHcvZQGwWARWJmesXgMVFBWIlPl1ZDFUjKHFy5hMW EJtTIFDi350JYPXMAmESjy62sULY4hK3nsxngtilJvHp7UP2CYwCs5C0z0LSMgtJC4RtITFz /nlGCFteYvvbOcwQtoZE65y57DDx5q2zmRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnE CAz6g1t+6+5gXP3a8RCjAAejEg+v/4O6GCHWxLLiytxDjBIczEoivJ4fgEK8KYmVValF+fFF pTmpxYcYpTlYlMR5/wgJxggJpCeWpGanphakFsFkmTg4pRoYpRw3f9x7Ii/eVU7ocMei01LG 73MKujaJfarJ5HFU273qhNct56bluS+3lk74aqk9fWKbawHHam2b32u9kq46Js/7tPkmH8uJ 5CWLVp3r+vf5D9vxJ6ELawJ0uD7wbl40+1Hd3Id8kkd4RflFJ7zi5z5u+X2+kv35lGauJ8xN jZcKUuoj2T9dVGIpzkg01GIuKk4EAKhzg252AgAA
Archived-At: 
Subject: Re: [Detnet] A few suggested updates to draft-ietf-detnet-architecture-11
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, 05 Mar 2019 23:02:40 -0000

--------------726AFCE03D9987F047C287D4
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

The suggested changes look good to me.

Thanks,
Janos


On 3/5/2019 6:37 PM, Andrew G. Malis wrote:
> This morning we had a DetNet data plane design team call to work on 
> the MPLS and IP data plane drafts in preparation for Prague. We had a 
> discussion of terminology in the drafts that led us back to the 
> terminology definitions in the Architecture draft.
>
> As a result, we have a few suggested terminology improvements:
>
> In section 2.1:
>
> Replace these old definitions:
>
>     App-flow
>             The native format of a DetNet flow.
>     DetNet flow
>             A DetNet flow is a sequence of packets from one source to one
>             or more destinations, which conform uniquely to a flow
>             identifier, and to which the DetNet service is to be
>             provided.
>
> with these:
>
> App-Flow
>
> The payload (data) carried over a DetNet service.
>
>
> DetNet flow
>
> A DetNet flow is a sequence of packets
>
> which conform uniquely to a flow
>
> identifier, and to which the DetNet service is to be
>
> provided. It includes any DetNet headers added to support
>
> the DetNet service and forwarding sub-layers.
>
>
> These new definitions provide more clarity to the difference between 
> the terms.
>
>
> We also had two other minor changes to suggest.
>
>
> In section 4.2.1, remove the first sentence:
>
>
>     The native data flow between the source/destination end systems is
>     referred to as application-flow (App-flow).
>
>
> This is redundant to the definition in section 2.1.
>
>
> In section 4.3.1, change:
>
>
>     o  App-flow: native format of the data carried over a DetNet flow.
>        It does not contain any DetNet related attributes.
>
>
> to:
>
>
> oApp-flow: the payload carried over a DetNet flow.
>
> It does not contain any DetNet related attributes.
>
>
> This is consistent with the definition in section 2.1.
>
>
> Thanks,
>
> Andy
>
>
>
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet


--------------726AFCE03D9987F047C287D4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi,

    

    The suggested changes look good to me.

    

    Thanks,

    Janos

    

    

    
On 3/5/2019 6:37 PM, Andrew G. Malis
      wrote:

    

    

      
      
This morning we had a DetNet data plane design team
        call to work on the MPLS and IP data plane drafts in preparation
        for Prague. We had a discussion of terminology in the drafts
        that led us back to the terminology definitions in the
        Architecture draft.
        


        

        
As a result, we have a few suggested terminology
          improvements:

        


        

        
In section 2.1:

        


        

        
Replace these old definitions:

        


        

        

          
   App-flow
           The native format of a DetNet flow.


          

          
   DetNet flow
           A DetNet flow is a sequence of packets from one source to one
           or more destinations, which conform uniquely to a flow
           identifier, and to which the DetNet service is to be
           provided.


          

        

        
with these:

        


        

        

          
App-Flow

          
     
                 The payload (data) carried over a DetNet
            service.

          


          

          
  DetNet flow

          
           A
            DetNet flow is a sequence of packets  

          
           which
            conform uniquely to a flow

          
           identifier,
            and to which the DetNet service is to be

          
           provided.
            It includes any DetNet headers added to support 

          

          

          
     
                   the DetNet service and forwarding sub-layers.

          


          

          
These new definitions provide more clarity to
            the difference between the terms.

          

          


          

          
We also had two other minor changes to suggest.

          


          

          
In section 4.2.1, remove the first sentence:

          


          

          
   The native data flow between the source/destination end systems is
   referred to as application-flow (App-flow).

          


          

          
This is redundant to the definition in section
            2.1.

          


          

          
In section 4.3.1, change:

          


          

          
   o  App-flow: native format of the data carried over a DetNet flow.
      It does not contain any DetNet related attributes.


          


          

          
to:

          


          

          
   o  App-flow:
            the payload carried over a DetNet flow.

          

          

          
     
               It does not contain any DetNet related attributes.

          


          

          
This is consistent with the definition in
            section 2.1.

          


          

          
Thanks,

          
Andy

          


          

          


          

        

      

      

      

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


    

    

  


--------------726AFCE03D9987F047C287D4--


From nobody Tue Mar  5 21:56: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 D52C2130EE3 for ; Tue,  5 Mar 2019 21:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.04
X-Spam-Level: 
X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBzEHRgHJ9eZ for ; Tue,  5 Mar 2019 21:56:12 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3D0130EC8 for ; Tue,  5 Mar 2019 21:56:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1551851763; x=1554443763; 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=Z8BuHZJ4RIW0nzatEn6Uh93YXZSEdZ2ASV7TAmFokFI=; b=Ty3pkG4UEx/Rs/6+4tRjaBI8cp8jDdz/5ernO7CC7OzXnKo7PlMA3LARgiOlBrpI 61WXdE3m4zTEcK+nyL01NtQsJXEXyfwMM8cMJ/JHciAymioP6E4+H7uuuRMAiRjS Dlmjd0RAY2nfKhZzsgj2LnsEudYdyu+iODgDHMavSFE=;
X-AuditID: c1b4fb3a-14fff7000000672c-37-5c7f60f31709
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.E9.26412.3F06F7C5; Wed,  6 Mar 2019 06:56:03 +0100 (CET)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 06:56:03 +0100
Received: from [131.160.180.67] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 06:56:03 +0100
To: Alvaro Retana 
CC: Lou Berger , The IESG , , , 
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>  
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <150fb3c5-0f60-8426-0345-a17d9be984b9@ericsson.com>
Date: Wed, 6 Mar 2019 06:56:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6A122925EAB8A17805346115"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbG9WPdzQn2MwaFD5hY3Dm1gsrjW/4PF 4ven2SwWH77NZLGY8Wcis0VH81sWBzaPnbPusnssWfKTyePDpma2AOYoLpuU1JzMstQifbsE roy7J1cwFlxcwFSxeON75gbGXxcZuxg5OSQETCRWzOpn6mLk4hASOMIo8fTmJCjnK6PE/h8/ 2OAyb3oXsIG0CAsUSHw92sAOYosIaEnc3rmTHaSIWWA6o8T5+S/AioQEPjJJtJ0SALHZBOwl 7l7awAxi8wLZs/9NA7NZBFQk5nZBxEUFYiU+XVkMVSMocXLmExYQm1PARuLE6llgy5gFwiR+ //8NZYtL3Hoynwlil5rEp7cP2ScwCs5C0j4LScssJC0QtoXEzPnnGSFseYnmrbOZIWwNidY5 c9mRxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIylg1t+W+1gPPjc8RCjAAejEg/v Nb/6GCHWxLLiytxDjBIczEoivMEOQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8f4QEY4QE0hNL UrNTUwtSi2CyTBycUg2MKmr1zF3KCkYsb0/s/V7X9PuL2I2ve8PfPF8/48IaJpsop0KJpMaD xTM8L71t+796/9dYOfOT5299vXXXNoDh5kaOBjmbp++EDpcbdeaq79g0N7tn8wx+9qT9zGpz btkUd0ldf/iDs95Q6pUgX6+8QxdT+c6tCgwnOcXeHIp5XLvdaNWtjzy/lViKMxINtZiLihMB rQRSSaECAAA=
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Mar 2019 05:56:16 -0000

--------------6A122925EAB8A17805346115
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alvaro,

Do the updates we are making the security section resolve your comments:
https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o

The current proposed text:

5.  Security Considerations

    Security considerations for DetNet are described in detail in
    [I-D.ietf-detnet-security].  This section considers exclusively
    security considerations which are specific to the DetNet
    Architecture.

    Security aspects which are unique to DetNet are those whose aim is to
    provide the specific quality of service aspects of DetNet, which are
    primarily to deliver data flows with extremely low packet loss rates
    and bounded end-to-end delivery latency.  A DetNet may be implemented
    using MPLS and/or IP (including both v4 and v6) technologies, and
    thus inherits the security properties of those technologies at both
    the control plane and the data plane.

    Security considerations for DetNet are constrained (compared to, for
    example, the open Internet) because DetNet is defined to operate only
    within a single administrative domain (see Section 1).  The primary
    considerations are to secure the request and control of DetNet
    resources, maintain confidentiality of data traversing the DetNet,
    and provide the availability of the DetNet quality of service.

    To secure the request and control of DetNet resources, authentication
    and authorization can be used for each device connected to a DetNet
    domain, most importantly to network controller devices.  Control of a
    DetNet network may be centralized or distributed (within a single
    administrative domain).  In the case of centralized control,
    precedent for security considerations as defined for Abstraction and
    Control of Traffic Engineered Networks (ACTN) can be found in
    [RFC8453], Section 9.  In the case of a distributed control
    protocols, DetNet security is expected to be provided by the security
    properties of the protocols in use.  In any case, the result is that
    manipulation of administratively configurable parameters is limited
    to authorized entities.

    To maintain confidentiality of data traversing the DetNet,
    application flows can be protected through whatever means is provided
    by the underlying technology.  For example, encryption may be used,
    such as that provided by IPSec [RFC4301] for IP (Layer 3) flows and
    by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.

    DetNet flows are identified on a per-flow basis, which may provide
    attackers with additional information about the data flows (when
    compared to networks that do not include per-flow identification).
    This is an inherent property of DetNet which has security
    implications which should be considered when determining if DetNet is
    a suitable technology for any given use case.

    To provide uninterrupted availability of the DetNet quality of
    service, provisions can be made against DOS attacks and delay
    attacks.  To protect against DOS attacks, excess traffic due to
    malicious or malfunctioning devices can be prevented or mitigated,
    for example through the use of traffic admission control applied at
    the input of a DetNet domain, as described in Section 3.2.1, and
    through the fault mitigation methods described in Section 3.3.2. To
    prevent DetNet packets from being delayed by an entity external to a
    DetNet domain, DetNet technology definition can allow for the
    mitigation of Man-In-The-Middle attacks, for example through use of
    authentication and authorization of devices within the DetNet domain.

    Because DetNet mechanisms or applications that rely on DetNet can
    make heavy use of methods that require precise time synchronization,
    the accuracy, availability, and integrity of time synchronization is
    of critical importance.  Extensive discussion of this topic can be
    found in [RFC7384].

    DetNet use cases are known to have widely divergent security
    requirements.  The intent of this section is to provide a baseline
    for security considerations which are common to all DetNet designs
    and implementations, without burdening individual designs with
    specifics of security infrastructure which may not be germane to the
    given use case.  Designers and Implementers of DetNet systems are
    expected to take use case specific considerations into account in
    their DetNet designs and implementations.


Please let us know if you have any remaining comments and what they are.

Thank you!
Janos


On 2/23/2019 9:39 PM, Lou Berger wrote:
>
> Hi *Alvaro*,
>
> see below.
>
> On 2/22/2019 6:02 AM, Alvaro Retana wrote:
>> On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net 
>> ) wrote:
>>
>> Hi!
>>
>>> >>> ----------------------------------------------------------------------
>>> >>> DISCUSS:
>>> >>> 
>>> ----------------------------------------------------------------------
>>> >>>
>>> >>> I support Mirja's and Alissa's DISCUSSes...and have a related 
>>> set of concerns
>>> >>> about the coexistence with non-DetNet traffic and privacy:
>>> >>>
>>> >>> §3.3.1 talks about what I think is a hard to achieve balance 
>>> between coexisting
>>> >>> with non-DetNet traffic and keeping that traffic from disrupting 
>>> DetNet flows.
>>> >>> Because of the constraints, the intent of prioritizing DetNet 
>>> flows is clear
>>> >>> (and that is ok), but that may result in starvation of non-DetNet
>>> >>> traffic...even if the text does explicitly say that it "must be 
>>> avoided".
>>> >>>
>>> >>> I would like to see the potential case of starving non-DetNet 
>>> traffic called
>>> >>> out somewhere.
>>> >>
>>> >> This is the objective of section 3.3.1..
>>> >>
>>> >>
>>> >>> I'm looking for something similar to the first paragraph in §5,
>>> >>> but focused on the non-DetNet traffic.
>>> >>
>>> >> The current text reads:
>>> >>
>>> >> 3.3.1. Coexistence with normal traffic
>>> >>
>>> >> A DetNet network supports the dedication of a high proportion of the
>>> >> network bandwidth to DetNet flows. But, no matter how much is
>>> >> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>>> >> existing Class of Service schemes (e.g., DiffServ). It is also
>>> >> important that non-DetNet traffic not disrupt the DetNet flow, of
>>> >> course (see Section 3.3.2 and Section 5). For these reasons:
>>> >>
>>> >> o Bandwidth (transmission opportunities) not utilized by a DetNet
>>> >> flow is available to non-DetNet packets (though not to other
>>> >> DetNet flows).
>>> >>
>>> >> o DetNet flows can be shaped or scheduled, in order to ensure that
>>> >> the highest-priority non-DetNet packet is also ensured a worst-
>>> >> case latency.
>>> >>
>>> >> o When transmission opportunities for DetNet flows are scheduled in
>>> >> detail, then the algorithm constructing the schedule should leave
>>> >> sufficient opportunities for non-DetNet packets to satisfy the
>>> >> needs of the users of the network. Detailed scheduling can also
>>> >> permit the time-shared use of buffer resources by different DetNet
>>> >> flows.
>>> >>
>>> >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>> >> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>>> >> presence of DetNet flows in a network on the non-DetNet flows is
>>> >> primarily a reduction in the available bandwidth.
>>> >>
>>> >>
>>> >> I think we need a little bit more to understand what you'd like 
>>> to see changed or added. Can you suggest text or what specific topic 
>>> you'd like to see added/addressed?
>>> >
>>> > Yes, let me try to explain better…while comparing with the current
>>> > text in §5, which basically says that even though the objective of
>>> > DetNet is to provide bounded latency, a MIIM may delay the traffic and
>>> > the objective may not be achieved.
>>> >
>>> > For non-DetNet traffic, the objective is to not starve it, while
>>> > providing specific guarantees to the DetNet flows — said other way
>>> > (from the Introduction): "Unused reserved resources are available to
>>> > non-DetNet packets as long as all guarantees are fulfilled.”  However,
>>> > the algorithms (maybe error, misconfiguration…or even maliciously) may
>>> > end up*not* constructing the schedule to leave sufficient
>>> > opportunities for non-DetNet packets (as suggested in the text above
>>> > from §3.3.1).
>>> >
>>> > I see a parallel in how there is a risk of the intention for DetNet
>>> > flows not being met (because of an attack) and how the intention for
>>> > non-DetNet traffic may also not be met.
>>> >
>>> Okay, this sounds like basically the same point that Benjamin was
>>> making, i.e., there must be mechanisms preventing non-detnet traffic
>>> from impacting detnet traffic, and detnet traffic trying to use more
>>> than its allocation and impacting non-detnet traffic. Is this correct or
>>> are you asking for something different/additional?
>>
>> Yes.  I’m not asking so much for a mechanism, but for at least the 
>> recognition that it is a risk.
>>
> Fair enough- I expect the response a response for the architecture and 
> security draft authors to address this.  I'm sure you will confirm 
> that it does!
>
>
>>>
>>>
>>>
>>> >
>>> >>> Related to the above is the fact that the identification of 
>>> flows could be used
>>> >>> to specifically *not* include some of them as DetNet flows. This 
>>> is a
>>> >>> variation of the concern outlined in §6, but applied to 
>>> non-DetNet flows, with
>>> >>> the potential starvation mentioned above. Again, I would like to 
>>> at least see
>>> >>> some discussion of this risk.
>>> >>
>>> >> I don't follow - what is the risk that should be addressed?
>>> >>
>>> > §6 talks about potential privacy concerns due to the identification of
>>> > flows.  I interpret that as potentially being able to identify the
>>> > user (application, or both maybe).
>>> >
>>> Currently flow identification is based on IP headers (6 tuple) and/or
>>> MPLS labels.  So DetNet has the same privacy concerns as standard 
>>> IP/MPLS.
>>>
>>>
>>> > As far as I understand the architecture, DetNet flows are identified
>>> > at the edge and then assigned to specific paths.  If the
>>> > identification of flows can be used to identify the user (for
>>> > example), then it can be used to not only attack specific DetNet flow,
>>> > but also to decide to not provide guarantees to a specific flow based
>>> > on who the user or the application may be.
>>> >
>>> Given DetNet flow identification, is this any different than 
>>> standard PBR?
>>
>> Right, it is not really different.  It is just not mentioned anywhere 
>> that identification (or misidentification as it may be, maybe 
>> maliciously) can lead to not providing guarantees, potential 
>> starving, etc..
>>
> I thought the quotes capture in the various mails on the topic showed 
> how it was -- but let's wait for the updated text and see if it 
> sufficiently addresses your concern/point, and then go from there.
>
> Thanks again for the feedback.
>
> Lou
>
>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet


--------------6A122925EAB8A17805346115
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Alvaro,

    

    Do the updates we are making the security section resolve your
    comments:

https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o

    

    The current proposed text:

    

    5.  Security Considerations

    

       Security considerations for DetNet are described in detail in

       [I-D.ietf-detnet-security].  This section considers exclusively

       security considerations which are specific to the DetNet

       Architecture.

    

       Security aspects which are unique to DetNet are those whose aim
    is to

       provide the specific quality of service aspects of DetNet, which
    are

       primarily to deliver data flows with extremely low packet loss
    rates

       and bounded end-to-end delivery latency.  A DetNet may be
    implemented

       using MPLS and/or IP (including both v4 and v6) technologies, and

       thus inherits the security properties of those technologies at
    both

       the control plane and the data plane.

    

       Security considerations for DetNet are constrained (compared to,
    for

       example, the open Internet) because DetNet is defined to operate
    only

       within a single administrative domain (see Section 1).  The
    primary

       considerations are to secure the request and control of DetNet

       resources, maintain confidentiality of data traversing the
    DetNet,

       and provide the availability of the DetNet quality of service.

    

       To secure the request and control of DetNet resources,
    authentication

       and authorization can be used for each device connected to a
    DetNet

       domain, most importantly to network controller devices.  Control
    of a

       DetNet network may be centralized or distributed (within a single

       administrative domain).  In the case of centralized control,

       precedent for security considerations as defined for Abstraction
    and

       Control of Traffic Engineered Networks (ACTN) can be found in

       [RFC8453], Section 9.  In the case of a distributed control

       protocols, DetNet security is expected to be provided by the
    security

       properties of the protocols in use.  In any case, the result is
    that

       manipulation of administratively configurable parameters is
    limited

       to authorized entities.

    

       To maintain confidentiality of data traversing the DetNet,

       application flows can be protected through whatever means is
    provided

       by the underlying technology.  For example, encryption may be
    used,

       such as that provided by IPSec [RFC4301] for IP (Layer 3) flows
    and

       by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.

    

       DetNet flows are identified on a per-flow basis, which may
    provide

       attackers with additional information about the data flows (when

       compared to networks that do not include per-flow
    identification).

       This is an inherent property of DetNet which has security

       implications which should be considered when determining if
    DetNet is

       a suitable technology for any given use case.

    

       To provide uninterrupted availability of the DetNet quality of

       service, provisions can be made against DOS attacks and delay

       attacks.  To protect against DOS attacks, excess traffic due to

       malicious or malfunctioning devices can be prevented or
    mitigated,

       for example through the use of traffic admission control applied
    at

       the input of a DetNet domain, as described in Section 3.2.1, and

       through the fault mitigation methods described in Section 3.3.2. 
    To

       prevent DetNet packets from being delayed by an entity external
    to a

       DetNet domain, DetNet technology definition can allow for the

       mitigation of Man-In-The-Middle attacks, for example through use
    of

       authentication and authorization of devices within the DetNet
    domain.

    

       Because DetNet mechanisms or applications that rely on DetNet can

       make heavy use of methods that require precise time
    synchronization,

       the accuracy, availability, and integrity of time synchronization
    is

       of critical importance.  Extensive discussion of this topic can
    be

       found in [RFC7384].

    

       DetNet use cases are known to have widely divergent security

       requirements.  The intent of this section is to provide a
    baseline

       for security considerations which are common to all DetNet
    designs

       and implementations, without burdening individual designs with

       specifics of security infrastructure which may not be germane to
    the

       given use case.  Designers and Implementers of DetNet systems are

       expected to take use case specific considerations into account in

       their DetNet designs and implementations.

    

    

    Please let us know if you have any remaining comments and what they
    are.

    

    Thank you!

    Janos

    

    

    
On 2/23/2019 9:39 PM, Lou Berger wrote:

    

    

      
      
Hi *Alvaro*,

      
see below.

      

      
On 2/22/2019 6:02 AM, Alvaro Retana
        wrote:

      

      

        
        
On
          February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net)
          wrote:

        


        

        
Hi!

        


        

        

          

              

                
>>>
                  ---------------------------------------------------------------------- 

                  >>> DISCUSS: 

                  >>>
                  ---------------------------------------------------------------------- 

                  >>> 

                  >>> I support Mirja's and Alissa's
                  DISCUSSes...and have a related set of concerns 

                  >>> about the coexistence with non-DetNet
                  traffic and privacy: 

                  >>> 

                  >>> §3.3.1 talks about what I think is a hard
                  to achieve balance between coexisting 

                  >>> with non-DetNet traffic and keeping that
                  traffic from disrupting DetNet flows. 

                  >>> Because of the constraints, the intent of
                  prioritizing DetNet flows is clear 

                  >>> (and that is ok), but that may result in
                  starvation of non-DetNet 

                  >>> traffic...even if the text does
                  explicitly say that it "must be avoided". 

                  >>> 

                  >>> I would like to see the potential case of
                  starving non-DetNet traffic called 

                  >>> out somewhere. 

                  >> 

                  >> This is the objective of section 3.3.1.. 

                  >> 

                  >> 

                  >>> I'm looking for something similar to the
                  first paragraph in §5, 

                  >>> but focused on the non-DetNet traffic. 

                  >> 

                  >> The current text reads: 

                  >> 

                  >> 3.3.1. Coexistence with normal traffic 

                  >> 

                  >> A DetNet network supports the dedication of a
                  high proportion of the 

                  >> network bandwidth to DetNet flows. But, no
                  matter how much is 

                  >> dedicated for DetNet flows, it is a goal of
                  DetNet to coexist with 

                  >> existing Class of Service schemes (e.g.,
                  DiffServ). It is also 

                  >> important that non-DetNet traffic not disrupt
                  the DetNet flow, of 

                  >> course (see Section 3.3.2 and Section 5). For
                  these reasons: 

                  >> 

                  >> o Bandwidth (transmission opportunities) not
                  utilized by a DetNet 

                  >> flow is available to non-DetNet packets
                  (though not to other 

                  >> DetNet flows). 

                  >> 

                  >> o DetNet flows can be shaped or scheduled, in
                  order to ensure that 

                  >> the highest-priority non-DetNet packet is
                  also ensured a worst- 

                  >> case latency. 

                  >> 

                  >> o When transmission opportunities for DetNet
                  flows are scheduled in 

                  >> detail, then the algorithm constructing the
                  schedule should leave 

                  >> sufficient opportunities for non-DetNet
                  packets to satisfy the 

                  >> needs of the users of the network. Detailed
                  scheduling can also 

                  >> permit the time-shared use of buffer
                  resources by different DetNet 

                  >> flows. 

                  >> 

                  >> Starvation of non-DetNet traffic must be
                  avoided, e.g., by traffic 

                  >> policing functions (e.g., [RFC2475]). Thus,
                  the net effect of the 

                  >> presence of DetNet flows in a network on the
                  non-DetNet flows is 

                  >> primarily a reduction in the available
                  bandwidth. 

                  >> 

                  >> 

                  >> I think we need a little bit more to
                  understand what you'd like to see changed or added.
                  Can you suggest text or what specific topic you'd like
                  to see added/addressed? 

                  > 

                  > Yes, let me try to explain better…while comparing
                  with the current 

                  > text in §5, which basically says that even though
                  the objective of 

                  > DetNet is to provide bounded latency, a MIIM may
                  delay the traffic and 

                  > the objective may not be achieved. 

                  > 

                  > For non-DetNet traffic, the objective is to not
                  starve it, while 

                  > providing specific guarantees to the DetNet flows
                  — said other way 

                  > (from the Introduction): "Unused reserved
                  resources are available to 

                  > non-DetNet packets as long as all guarantees are
                  fulfilled.”  However, 

                  > the algorithms (maybe error, misconfiguration…or
                  even maliciously) may 

                  > end up*not* constructing the schedule to leave
                  sufficient 

                  > opportunities for non-DetNet packets (as
                  suggested in the text above 

                  > from §3.3.1). 

                  > 

                  > I see a parallel in how there is a risk of the
                  intention for DetNet 

                  > flows not being met (because of an attack) and
                  how the intention for 

                  > non-DetNet traffic may also not be met. 

                  > 

                  Okay, this sounds like basically the same point that
                  Benjamin was 

                  making, i.e., there must be mechanisms preventing
                  non-detnet traffic 

                  from impacting detnet traffic, and detnet traffic
                  trying to use more 

                  than its allocation and impacting non-detnet traffic.
                  Is this correct or 

                  are you asking for something different/additional? 

              

            

        

        
Yes.  I’m not asking so much for a mechanism, but for at
          least the recognition that it is a risk.

      

      
Fair enough- I expect the response a response for the
        architecture and security draft authors to address this.  I'm
        sure you will confirm that it does!

      


      

      

        

          

            

                

                  


                    

                    

                    > 

                    >>> Related to the above is the fact that
                    the identification of flows could be used 

                    >>> to specifically *not* include some of
                    them as DetNet flows. This is a 

                    >>> variation of the concern outlined in
                    §6, but applied to non-DetNet flows, with 

                    >>> the potential starvation mentioned
                    above. Again, I would like to at least see 

                    >>> some discussion of this risk. 

                    >> 

                    >> I don't follow - what is the risk that
                    should be addressed? 

                    >> 

                    > §6 talks about potential privacy concerns due
                    to the identification of 

                    > flows.  I interpret that as potentially being
                    able to identify the 

                    > user (application, or both maybe). 

                    > 

                    Currently flow identification is based on IP headers
                    (6 tuple) and/or 

                    MPLS labels.  So DetNet has the same privacy
                    concerns as standard IP/MPLS. 

                    

                    

                    > As far as I understand the architecture, DetNet
                    flows are identified 

                    > at the edge and then assigned to specific
                    paths.  If the 

                    > identification of flows can be used to identify
                    the user (for 

                    > example), then it can be used to not only
                    attack specific DetNet flow, 

                    > but also to decide to not provide guarantees to
                    a specific flow based 

                    > on who the user or the application may be. 

                    > 

                    Given DetNet flow identification, is this any
                    different than standard PBR? 

                

              

          

          
Right, it is not really different.  It is just not
            mentioned anywhere that identification (or misidentification
            as it may be, maybe maliciously) can lead to not providing
            guarantees, potential starving, etc..

        

      

      
I thought the quotes capture in the various mails on the topic
        showed how it was -- but let's wait for the updated text and see
        if it sufficiently addresses your concern/point, and then go
        from there.

      

      
Thanks again for the feedback.

      
Lou

      

      


      

      

        

          
Thanks!

          
Alvaro.

        

        

        

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


      

    

    

  


--------------6A122925EAB8A17805346115--


From nobody Wed Mar  6 13:04:57 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 5D9A0130DD6 for ; Wed,  6 Mar 2019 13:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCbAg-KezEO5 for ; Wed,  6 Mar 2019 13:04:49 -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 621E9130DDA for ; Wed,  6 Mar 2019 13:04:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1551906273; x=1554498273; 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=A59hlV4ITPFtBCBVtm9vh6XGPdrcyWkYsX163634DYw=; b=TLwG+aTbvtwzuYVGBFu49dmpdajt0fUEgo3tzjlHoi/5s+Hj+5+rktkEEVRLVfvZ INeKBtPcVjHJRLnRDyU8yC2tyfexlD+FfWfeirdpt+/9m6BD7IazG49gnh3PW+xB RUzY3Ajom9h2fmCKNdx1olcjy8ZwbD8Q0TLtDZrRud8=;
X-AuditID: c1b4fb25-da1ff70000005ff7-e2-5c8035e1db94
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.C0.24567.1E5308C5; Wed,  6 Mar 2019 22:04:33 +0100 (CET)
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 22:04:33 +0100
Received: from [100.94.33.89] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.188) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 22:04:32 +0100
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
To: The IESG , DetNet WG , Lou Berger 
Message-ID: 
Date: Wed, 6 Mar 2019 22:04:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2J7pe5D04YYgyXXVS1+f5rNYjHjz0Rm i47mtywOzB5Llvxk8viwqZktgCmKyyYlNSezLLVI3y6BK+PVst0sBZ85KibcusDewPiWvYuR k0NCwETi84QrzF2MXBxCAkcYJRZ8OsgI4XxllLiyZz8rSJWQwCFGiWuvJUFsNgF7ibuXNgB1 cHAIC1hIzLtVARIWEYiSmPxxOVg5L1DJzRm3mUBsFgEViSubG8GWiQrESny6spgZokZQ4uTM JywgNjPQmJnzzzNC2PISzVtnM0PY4hK3nsxngjhBTeLT24fsExj5ZyFpn4WkfRaS9llI2hcw sqxiFC1OLU7KTTcy1kstykwuLs7P08tLLdnECAzQg1t+q+5gvPzG8RCjAAejEg9viFFDjBBr YllxZS7Q3xzMSiK8ropAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rx/hARjhATSE0tSs1NTC1KL YLJMHJxSDYxVMRxunyvzVXcKbshZrXpCVd2xmrOxY8+bGw13+KW6FwotW3Q+9cTC4ISbAoct /hdN5ksVnihzXdpeqcjiXofUq2nbtYUl7ga8eb0t6cRzBscH548eWbB/Ycp85QknKlJ/3RXP 1lHlX6tQO4FrSdBu7k83Vz/WSbBh6tL7d29+oq73NM6Ma4VKLMUZiYZazEXFiQBhfcR7TAIA AA==
Archived-At: 
Subject: [Detnet] status update on draft-ietf-detnet-architecture
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Mar 2019 21:04:54 -0000

Hi,

We are working on resolving IESG comments in emails. The latest emails:


DISCUSS & COMMENT:

Alissa Cooper:
https://mailarchive.ietf.org/arch/msg/detnet/QqUWlFnG9iJl5qXnuprPC6J4rDo

Benjamin Kaduk:
https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
https://mailarchive.ietf.org/arch/msg/detnet/EII8VE1f_Ssel8G2lGgYUOjiCcg

Mirja Kühlewind
https://mailarchive.ietf.org/arch/msg/detnet/EII8VE1f_Ssel8G2lGgYUOjiCcg

Alvaro Retana:
https://mailarchive.ietf.org/arch/msg/detnet/EII8VE1f_Ssel8G2lGgYUOjiCcg


COMMENT with No Objection:

Ben Campbell:
https://mailarchive.ietf.org/arch/msg/detnet/0KUpocGxJNRAfDknzUQ9HcV0Re4

Suresh Krishnan:
https://mailarchive.ietf.org/arch/msg/detnet/eTlUleK0JyqNkUiU8VSFZfwcL8g

Warren Kumari:
https://mailarchive.ietf.org/arch/msg/detnet/Bl5owkhDpKN92XHcfcmRCRdVd2o


further comments:
https://mailarchive.ietf.org/arch/msg/detnet/EAQWmP2W-xJek1Sg7r3YE4rDz68


A revised version of the draft resolving the comments according to the 
email discussions will be uploaded this Saturday, or Sunday the latest.


Regards,
Janos
(co-author)


From nobody Thu Mar  7 08:41:19 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 CE0701277DB; Thu,  7 Mar 2019 08:41:16 -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=kaloom.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 Jj14G3gG9zzk; Thu,  7 Mar 2019 08:41:13 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660136.outbound.protection.outlook.com [40.107.66.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC9E12782C; Thu,  7 Mar 2019 08:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yMeWlXne++E2lqUox4j3GybGsX3gfhEcTUNVbAlqAcQ=; b=jNW9QwdUbxRDVPoXpQh4SFIZPQlHu3t9Y5h8lj1Ek67/OPIRX4/nKtUHPA4eTaAQKs3xKyXyoTo31jq/7/3n8c4I+L6FwONeZjOL5VwMSuWJcPo/7toami+eqnKOVzmTqbq7XpmTw3xsjIRS3Hzva3/YIvPJPkZAWiXD2jOTQLA=
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.44.159) by YTOPR0101MB1787.CANPRD01.PROD.OUTLOOK.COM (52.132.44.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Thu, 7 Mar 2019 16:41:05 +0000
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::648a:be37:d13:9c04]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::648a:be37:d13:9c04%3]) with mapi id 15.20.1665.020; Thu, 7 Mar 2019 16:41:05 +0000
From: Suresh Krishnan 
To: =?utf-8?B?SsOhbm9zIEZhcmthcw==?= 
CC: The IESG , "draft-ietf-detnet-architecture@ietf.org" , Lou Berger , "detnet-chairs@ietf.org" , "detnet@ietf.org" 
Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)
Thread-Index: AQHU0TtxBdrNaGLL0kelQKl9KXYhPKYAZqIA
Date: Thu, 7 Mar 2019 16:41:05 +0000
Message-ID: <5BB134C0-1C9C-4DC0-84E7-68F58EEEF053@kaloom.com>
References: <155075828359.8615.9538259641487527490.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; 
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ad395419-0e75-4085-264a-08d6a31bb1a9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1787; 
x-ms-traffictypediagnostic: YTOPR0101MB1787:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 096943F07A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(396003)(39840400004)(376002)(51914003)(189003)(199004)(316002)(7736002)(508600001)(54906003)(33656002)(54896002)(6246003)(102836004)(83716004)(71190400001)(26005)(6436002)(6512007)(2906002)(6306002)(36756003)(66066001)(80792005)(186003)(53546011)(53946003)(606006)(236005)(97736004)(6506007)(82746002)(71200400001)(14454004)(68736007)(53936002)(5660300002)(3846002)(8676002)(72206003)(229853002)(105586002)(486006)(14444005)(8936002)(256004)(446003)(4326008)(66574012)(76176011)(11346002)(81166006)(81156014)(106356001)(476003)(966005)(6116002)(21615005)(6916009)(2616005)(86362001)(99286004)(6486002)(25786009)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1787; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtZVE9QUjAxMDFNQjE3ODc7MjM6aFBvNVJ2WHhlZDZnNFNEOW9PZzV4c0FS?= =?utf-8?B?YVhMdHFUOUV1SmpoUk1ZSDAvQS9paERUa093MDhXa1AwMi9QdHZZTVlOTVFJ?= =?utf-8?B?eWhmZjJZQ0xkTFpuQVJwMk90bEFQRGtxNnlXa0cxcmtrSEUxV3BuL1ZFV240?= =?utf-8?B?VEJJZDZNRTdoVmVMdTYxRTIyVGQzQ2J5cG1XVXRhNXBsTWNNZmpxVTFzZUsy?= =?utf-8?B?dGV2eWo4R3hOSUloSGgrdFFWRHlhUzJtSm9MakhpdkxSeTlVTXBYSGliYmFm?= =?utf-8?B?QkhSWDM2bWh6Vld3UU1acUNlTGRITzlCRTdCSE84QVZyL0tVekhUMHh2Qmtq?= =?utf-8?B?VTJqYVc5bHdPenNPY1UxeEU1QVhpbVd4V3Q5dEswVGE5Yjc4SkJzWVkyOXFQ?= =?utf-8?B?dWwzREY3ODFZTnFVQjBuSS93dll4SWtRdTdKYnVFMGUvaDFiWnZUeEkyRVN0?= =?utf-8?B?bE9ubGVzMW5ycTNjZUJwUHh6REgrMG01anRqdU40eU5oZXZyZmhyUHN3alIr?= =?utf-8?B?MlRiY3pFbHYyUUZkQmlaUWkzRWUzYndZNGxiekxmY3MxWWx0Wjk3YUZVc3FJ?= =?utf-8?B?M29GMDVkdkJHZ1NLWFZXc0RVQjA1MGM3RDVLMjl5dWpsR3pxem45aDkyU2wz?= =?utf-8?B?NWx5dGU2bmRZUHZrSE8vYUE3R1RxNUJaKzdSd25oY21iOCtwaC80Nk1mZ2lh?= =?utf-8?B?NGNUZWpvYjZNaVZieVpIVkp3OVB2UGRzcGxGOHFEVW8vTElVb3B0SDA5L0tp?= =?utf-8?B?NzNtQ3M5MWUydzBqRDhCOFNNRW9VMHVPc1FGUlNDaHBiaWJTcG13Q0J5Q1Br?= =?utf-8?B?aFZzc1JFMkpVN1FHK09pTUZqQ1ppY3ZlRElvdERkRnVya3NrSjRCRklvQ1hR?= =?utf-8?B?UUNLQ25PUXViYXdUZmJ4R2JOQ1cyQ3JOb2tHOGZtRnNxVUVJQ3Y2VlVmemgz?= =?utf-8?B?MW9uYW5Ka2x1MWFPaU8zaDZiTVp6MjZ1cjVMUU1RVW1zTksrdUd5aHBlRWR4?= =?utf-8?B?cmZYWVhoSTdjVE9iMzd1ODYyd2xQakxwNVAvSWQ3WFZlQTVDQjVQN3RYeEFK?= =?utf-8?B?RHZSN0ZzMlY3VHQ1Y2JCRWwvTXR3RXI2L0puNDQyc1QxSE1DOTIvTVI4d1Y1?= =?utf-8?B?ZVg3bEg0cmE3QVZINU5hVnRZNUk3dVVPK2xHai9hSWxiWDR5Ni80NTY0OTFD?= =?utf-8?B?YjMvYXhHbnd3NS9SVnFJeWp6Vkl0bHRFOCt6dTV4MG5PZ0N2cVltcm5MQnFW?= =?utf-8?B?RlR4OWNMdWdRQVM4Y1RWWGJackdJS3NJNC8rNGViVjJKRHpUTUdVbndqQVd1?= =?utf-8?B?amFUczE3UnFteVc4ZDRuN25UbjU5QVBqM3VzdWVaRm1YcDdVZUV1T0dJMXNv?= =?utf-8?B?Vjl4L2wrazhlcHlWVVlyeE16ajVLNVlITlJLdHd5SW02dms0M1g5SlFRNmJZ?= =?utf-8?B?MVlxTkUzeDZLKy9OUkxOOTBkNkZmZ29LOG1IMXdDQzhzZGRNNW05ZWNIREcr?= =?utf-8?B?WTArVlo5b0RXMUtsZlNEUk80QkpXWUY5clBwUHRUUVVucmFlMFNZV1FXUXND?= =?utf-8?B?QU5MM3lPRXhlYzl2QlZnOUxRc3BGTHFieHB4WlVIem9haElLV045TkN5Ymtj?= =?utf-8?B?cGpyd3drZFBjalVyVDdaKzE0K1JEalB1bHhxTUpSaW11bWg5d3ZsZWJXN0VT?= =?utf-8?B?NEZSTURFaXlOMW4zbkpUeFByNFJDcnprRXl1dnJKZjJZVGh3Y0dzWlhDZlZ3?= =?utf-8?B?R0NJdDFNU3lMQzBoRUhjOWFJYWdrb3RsOGlKWU9TN2VrMXJMNzF0NjdlYjR2?= =?utf-8?B?VUl0N2lEQVF3UXRRRXJwc0xSSmh1YStkd3VuUnJ4WXUxV1FJclV6TW9icmlD?= =?utf-8?B?SllBaDhvemFkMnhEaW1yVHBEQ25vZ1Ryc2pTNUErQ1kvMVBJS1BlQWdUdWpH?= =?utf-8?B?cDRVWFRLb0RYSWpJUmJDcDhWaE9waHZSMzViWllPL2Q5SDkzRC9JNXhUNWlW?= =?utf-8?B?aWdHZVdEcXNZVFJZeElZeG13TUExVm55TURTL0JBPT0=?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Cuoyb0NxHkReT7oGY98aeg8m+nMpmlflG9MrQWonDXyHGDyW2ImEvbmz232k5VTIe7f2oKRhM6qEgab4v32ul+8Vgxhz8T60RuQkYlsvTxjm2DfcSSGr3FCnKTJxfEb8Dreik+eb7EQ7Pobni3qq2CrAASVeVwragdXvRGogMQUz2+LInT0VBtFDLw9omHULZ5qg3emKt+jPg7AN6nEW8pMhbbmEl7Rbt+VVKuLNOChxE6xmyqxZDVjEuffrp1QxBHkshyhrYYTF854v5Y1bRHI/9mqPuf0f6MFu+LfpuqFbnL1c3Yl9Dh6nxsL3Fs8TEBZWsXuwhxg2j1LqOcpl2cnlO7wmGzyt5nIgqBq8yMP99r9yWVGRvhjo/FfCqwTuRhL5AD9RdzSDhZNcePO+ksNbH/bRpvYU+xtf2x9CybU=
Content-Type: multipart/alternative; boundary="_000_5BB134C01C9C4DC084E768F58EEEF053kaloomcom_"
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ad395419-0e75-4085-264a-08d6a31bb1a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 16:41:05.8460 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1787
Archived-At: 
Subject: Re: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Mar 2019 16:41:17 -0000

--_000_5BB134C01C9C4DC084E768F58EEEF053kaloomcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB0aGUgdGV4dCBjaGFuZ2VzIErDoW5vcy4gVGhleSBsb29rIGdvb2QgdG8gbWUu
DQoNClJlZ2FyZHMNClN1cmVzaA0KDQpPbiBNYXIgMiwgMjAxOSwgYXQgNDowMyBQTSwgSsOhbm9z
IEZhcmthcyA8amFub3MuZmFya2FzQGVyaWNzc29uLmNvbTxtYWlsdG86amFub3MuZmFya2FzQGVy
aWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBTdXJlc2gsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBy
ZXZpZXchDQoNClBsZWFzZSBzZWUgaW4tbGluZToNCg0KT24gMi8yMS8yMDE5IDM6MTEgUE0sIFN1
cmVzaCBLcmlzaG5hbiB3cm90ZToNClN1cmVzaCBLcmlzaG5hbiBoYXMgZW50ZXJlZCB0aGUgZm9s
bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVy
ZS0xMTogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1
YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1
ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJv
ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczov
L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBt
b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu
DQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh
biBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KKiBTZWN0aW9uIDMuMi4xLjEuDQoNCkdpdmVuIHRoYXQgd2UgYWxz
byBrbm93IHNvbWUgb2YgdGhlIGRvd25zaWRlcyBhcyB3ZWxsIG9mIGxhcmdlIGJ1ZmZlcnMsIEkg
dGhpbmsNCmEgcG9pbnRlciB0byBzb21lIGJhY2tncm91bmQgbWlnaHQgYmUgd2FycmFudGVkIGhl
cmUuIEkgd291bGQgcmVjb21tZW5kIGEgYmFzaWMNCnJlZmVyZW5jZSB0byBzb21ldGhpbmcgbGlr
ZQ0KDQpCdWZmZXJibG9hdDogRGFyayBCdWZmZXJzIGluIHRoZSBJbnRlcm5ldCwgQ29tbXVuaWNh
dGlvbnMgb2YgdGhlIEFDTSwgSmFudWFyeQ0KMjAxMiwNCkFkZCByZWZlcmVuY2Ugd2l0aCBuZXcg
c2VudGVuY2UgYXQgdGhlIGVuZCBvZiB0aGUgcGFyYWdyYXBoOiAiTm90ZSB0aGF0IGxhcmdlIGJ1
ZmZlcnMgaGF2ZSBzb21lIGlzc3Vlcywgc2VlLCBlLmcuLCBbQlVGRkVSQkxPQVRdLiINCg0KDQoq
IFNlY3Rpb24gMy4yLjIuMi4NCg0KSXQgaXMgbm90IG9idmlvdXMgdG8gbWUgaG93IHRoZSBQT0Yg
Y2Fubm90IGJlIHRoZSBsYXN0IG9wZXJhdGlvbiBhdCB0aGUNCnJlY2VpdmVyLiBDYW4geW91IGNs
YXJpZnk/IEFsc28sIGRvIGludGVybWVkaWF0ZSBub2RlcyBhcHBseSB0aGUgUE9GPyBJIGNhbiBz
ZWUNCnRoZSBuZWVkIGZvciB0aGVtIHRvIGRvIFBSRiBhbmQgUEVGcyBidXQgSSBhbSBub3Qgc3Vy
ZSBhcHBseWluZyB0aGUgUE9GIGF0DQppbnRlcm1lZGlhdGUgbm9kZXMgY2FuIG5lY2Vzc2FyaWx5
IGhlbHAgdGhlIGxvdyBsYXRlbmN5IGFuZCBsb3cgaml0dGVyIGdvYWxzLg0KDQogICBUaGUgb3Jk
ZXIgaW4gd2hpY2ggYSBEZXROZXQgbm9kZSBhcHBsaWVzIFBFRiwgUE9GLCBhbmQgUFJGIHRvIGEN
CiAgIERldE5ldCBmbG93IGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0KVGhlIGludGVudGlv
biBoZXJlIGlzIG5vdCB0byBib3VuZCBhbnkgc3BlY2lmaWMgb3JkZXIgb2YgdGhlIFBSRU9GIGZ1
bmN0aW9ucyB3aXRoaW4gYSBkZXZpY2UsIG9yIG5vdCBldmVuIGJvdW5kIHdoaWNoIGRldmljZSBp
bXBsZW1lbnRzIHdoaWNoIGZ1bmN0aW9uLiBUaGVyZSBjYW4gYmUgY29tcGxleCBuZXR3b3JrIHNl
dC11cHMgY3JlYXRlZC4gRnVydGhlcm1vcmUsIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgbWF5
IGhhdmUgZGlmZmVyZW50IHByb3MgYW5kIGNvbnMgd2l0aCByZXNwZWN0IHRvIHRoZSBvcmRlciBv
ZiBQUkVPRiBmdW5jdGlvbnMuIEFzIHBvaW50ZWQgb3V0LCB0aGlzIGlzIG1haW5seSB2YWxpZCBm
b3IgUFJGIGFuZCBQRUY7IGhvd2V2ZXIsIHRoZSBzYW1lIGxlYXZlIGl0IG9wZW4gYXBwcm9hY2gg
Y2FuIGJlIGNhcnJpZWQgb24gYWxsIG9mIHRoZSBQUkVPRiBmdW5jdGlvbnMgaW5jbHVkaW5nIFBP
Ri4NCg0KV291bGQgaXQgaGVscCB0byByZXBsYWNlIHRoZSBzZW50ZW5jZSB3aXRoPzoNCiAgVGhl
IG9yZGVyIGluIHdoaWNoIGEgRGV0TmV0IG5vZGUgYXBwbGllcyBQRUYsIFBPRiwgYW5kIFBSRiB0
byBhDQogICBEZXROZXQgZmxvdyBpcyBsZWZ0IG9wZW4gZm9yIGltcGxlbWVudGF0aW9ucy4NCg0K
DQoqIFNlY3Rpb24gMy4yLjMuDQoNClJGQzc0MjYgZG9lcyBub3QgY29udGFpbiBtdWNoIHNwZWNp
ZmljIGluZm9ybWF0aW9uIGFib3V0IGV4cGxpY2l0IHJvdXRlIHNldHVwLg0KSXMgdGhlcmUgYSBw
YXJ0aWN1bGFyIHNlY3Rpb24geW91IHdhbnQgdG8gcG9pbnQgdG8uIElmIG5vdCwgSSBkb24ndCB0
aGluayB0aGlzDQpyZWZlcmVuY2UgaXMgb2YgbXVjaCB1c2UuIFJGQzg0NTMgaXMgbGlzdGVkIHR3
aWNlLg0KRGVsZXRlIFJGQzc0MjYgYW5kIG9uZSBvZiB0aGUgUkZDODQ1M3MuDQoNCg0KKiBTZWN0
aW9uIDMuMy4xLg0KDQpOb3Qgc3VyZSB3aHkgdGhpcyBpcyBhIHJlcXVpcmVtZW50IGJ1dCBJIGRv
IHdpc2ggdG8gbm90ZSB0aGF0IHRoZXJlIGFyZSBubyBzdWNoDQp3b3JzdC1jYXNlIGxhdGVuY3kg
Z3VhcmFudGVlcyBmb3IgYmVzdCBlZmZvcnQgdHJhZmZpYyAoYWthIG5vbi1EZXRuZXQpIGluDQpj
dXJyZW50IG5ldHdvcmtzLiBDYW4geW91IGNsYXJpZnk/DQoNCiAgIG8gIERldE5ldCBmbG93cyBj
YW4gYmUgc2hhcGVkIG9yIHNjaGVkdWxlZCwgaW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQNCiAgICAg
IHRoZSBoaWdoZXN0LXByaW9yaXR5IG5vbi1EZXROZXQgcGFja2V0IGlzIGFsc28gZW5zdXJlZCBh
IHdvcnN0LQ0KICAgICAgY2FzZSBsYXRlbmN5Lg0KVGhpcyBpcyB0byBwcm90ZWN0IHRoZSBRb1Mg
b2Ygbm9uLURldE5ldCBmbG93cyBpZiBuZWVkZWQuRGV0TmV0IGZsb3dzIGhhdmUgc3RyaW5nZW50
IFFvUyByZXF1aXJlbWVudHMuIFRoZXJlIG1heSBiZSBub24tRGV0TmV0IGZsb3dzIHRoYXQgYXJl
IG5vdCBiZXN0LWVmZm9ydCwgYnV0IGhhdmUgc29tZSBRb1MgcmVxdWlyZW1lbnRzLCBhbHRob3Vn
aCwgbGVzcyBzdHJpbmdlbnQgdGhhbiB0aGF0IG9mIHRoZSBEZXROZXQgZmxvd3MuDQoNCg0KDQoq
IFNlY3Rpb24gNC4xLjEuDQoNClRoaXMgdGV4dCAiUGVlcnMgd2l0aCBEdXBsaWNhdGUgZWxpbWlu
YXRpb24uIiBzZWVtcyB0byBiZSBjb21wbGV0ZWx5IG91dCBvZg0KcGxhY2UgdW5kZXIgdGhlICJQ
YWNrZXQgc2VxdWVuY2luZyIgaGVhZGluZyBiZWxvdyBGaWd1cmUgMi4gQ29weSBhbmQgcGFzdGUN
CmVycm9yPw0KUGFja2V0IHNlcXVlbmNpbmcgcGVlcnMgd2l0aCBkdXBsaWNhdGUgZWxpbWluYXRp
b24uIEl0IGlzIGV4cGxhaW5lZCB1bmRlciBkdXBsaWNhdGUgZWxpbWluYXRpb24gYXMgd2VsbCwg
YW5kIHRoZXkgYXJlIGxldmVsZWQgaW4gdGhlIGZpZ3VyZS4gV291bGQgbWVyZ2luZyB0aGUgdHdv
IHNlbnRlbmNlcyBoZWxwPzoNCiAgICAgICAgICAgQXMgcGFydCBvZiBEZXROZXQgc2VydmljZSBw
cm90ZWN0aW9uLCBzdXBwbGllcyB0aGUgc2VxdWVuY2UNCiAgICAgICAgICAgbnVtYmVyIGZvciBw
YWNrZXQgcmVwbGljYXRpb24gYW5kIGVsaW1pbmF0aW9uIChTZWN0aW9uIDMuNCksDQogICAgICAg
ICAgIHRodXMgcGVlcnMgd2l0aCBEdXBsaWNhdGUgZWxpbWluYXRpb24uDQoNCg0KKiBTZWN0aW9u
IDQuMy4yLg0KDQpJIGZvdW5kIHRoZSBleHByZXNzaW9uICJudW1iZXIgb2YgYml0IHRpbWVzIiBj
b25mdXNpbmcuIEkgaGF2ZSB1bmRlcnN0b29kICJiaXQNCnRpbWUiIHRvIG1lYW4gdGhlIGFtb3Vu
dCBvZiB0aW1lIHRha2VuIHRvIGVtaXQgYSBiaXQgZnJvbSBhIG5ldHdvcmsgaW50ZXJmYWNlLg0K
QmFzZWQgb24gdGhhdCBkZWZpbml0aW9uLCB0aGlzIGV4cHJlc3Npb24gZG9lcyBub3QgbWFrZSBz
ZW5zZS4gSXMgdGhlcmUgYQ0KYmV0dGVyIHJlZmVyZW5jZS9kZWZpbml0aW9uIG9mIHdoYXQgeW91
IG1lYW4/DQpXb3VsZCBpdCBoZWxwIHRvIHJld3JpdGU/Og0KDQpPTEQ6DQogICBUaGVzZSBwYXJh
bWV0ZXJzLCB0b2dldGhlciB3aXRoIGtub3dsZWRnZSBvZiB0aGUgcHJvdG9jb2wgc3RhY2sgdXNl
ZA0KICAgKGFuZCB0aHVzIHRoZSBzaXplIG9mIHRoZSB2YXJpb3VzIGhlYWRlcnMgYWRkZWQgdG8g
YSBwYWNrZXQpLCBsaW1pdA0KICAgdGhlIG51bWJlciBvZiBiaXQgdGltZXMgcGVyIG9ic2VydmF0
aW9uIGludGVydmFsIHRoYXQgdGhlIERldE5ldCBmbG93DQogICBjYW4gb2NjdXB5IHRoZSBwaHlz
aWNhbCBtZWRpdW0uDQoNCk5FVzoNCiAgIFRoZXNlIHBhcmFtZXRlcnMsIHRvZ2V0aGVyIHdpdGgg
a25vd2xlZGdlIG9mIHRoZSBwcm90b2NvbCBzdGFjayB1c2VkDQogICAoYW5kIHRodXMgdGhlIHNp
emUgb2YgdGhlIHZhcmlvdXMgaGVhZGVycyBhZGRlZCB0byBhIHBhY2tldCksIHByb3ZpZGUgdGhl
DQogICBiYW5kd2lkdGggdGhhdCBpcyBuZWVkZWQgZm9yIHRoZSB0aGUgRGV0TmV0IGZsb3cuDQoN
Cg0KDQoqIFNlY3Rpb24gNC41Lg0KDQpUaGVyZSBtaWdodCBiZSBzb21lIG90aGVyIHJlY2VudCBJ
RVRGIGRlZmluZWQgbWVjaGFuaXNtcyB0aGF0IG1pZ2h0IGJlIHJlbGV2YW50DQp0byBtZW50aW9u
IGhlcmUgYXMgd2VsbC4gZS5nLiBSRkM4Mjg5IChDb2RlbCksIFJGQzgwMzMgKFBJRSkgZXRjLg0K
DQpBZGQgUkZDODI4OSBhbmQgUkZDODAzMyB3aXRoIGEgbmV3IHNlbnRlbmNlIGFzIHRoZSBwZW51
bHRpbWF0ZSBzZW50ZW5jZSBvZiB0aGUgc2VjdGlvbjoNCiJGdXJ0aGVyIHRlY2huaXF1ZXMgYXJl
IGRlZmluZWQgYnkgdGhlIElFVEYsIGUuZy4sIFtSRkM4Mjg5XSBhbmQgW1JGQzgwMzNdLiINCg0K
DQoNCiogU2VjdGlvbiA0LjcuMi4NCg0KV2hpbGUgSVB2NiBkb2VzIG9mZmVyIGEgbWVjaGFuaXNt
IHRvIGFkZC9yZW1vdmUgYSBmbG93IGlkIChmbG93IGxhYmVsKSBub3Qgc3VyZQ0Kd2hhdCBraW5k
IG9mIG1hcHBpbmcgeW91IHdlcmUgdGhpbmtpbmcgZm9yIElQdjQuIElmIHRoaXMgaXMgbm90IHBv
c3NpYmxlLCBJDQp0aGluayBhIG5vdGUgdG8gdGhhdCBlZmZlY3QgbWlnaHQgYmUgdXNlZnVsIGhl
cmUuDQpGbG93IGlkZW50aWZpY2F0aW9uIGRldGFpbHMgZm9yIElQIGRhdGEgcGxhbmUgYXJlIGRl
c2NyaWJlZCBpbiBkcmFmdC1pZXRmLWRldG5ldC1kcC1zb2wtaXAuIFdvdWxkIGl0IGhlbHAgdG8g
YWRkIHRoZSBmb2xsb3dpbmcgaW50cm9kdWN0b3J5IHRleHQgdG8gU2VjdGlvbiA0Ljc/Og0KIlRo
aXMgc2VjdGlvbiBkaXNjdXNzZXMgd2hhdCBuZWVkcyB0byBiZSBkb25lIGF0IHRlY2hub2xvZ3kg
Ym9yZGVycyBpbmNsdWRpbmcgRXRoZXJuZXQgYXMgb25lIG9mIHRoZSB0ZWNobm9sb2dpZXMuIEZs
b3cgaWRlbnRpZmljYXRpb24gZGV0YWlscyBmb3IgTVBMUyBhbmQgSVAgZGF0YSBwbGFuZXMgYXJl
IGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtZGV0bmV0LWRwLXNvbC1tcGxzXSBhbmQgW0ktRC5pZXRm
LWRldG5ldC1kcC1zb2wtaXBdLCByZXNwZWN0aXZlbHkuIg0KDQoNCiogU2VjdGlvbnMgNSBhbmQg
Ng0KDQpJIGFsc28gc3VwcG9ydCBBbGlzc2EgYW5kIEJlbmphbWluJ3MgRElTQ1VTU2VzIChvbiBw
cml2YWN5IGFuZCBzZWN1cml0eSkgYW5kDQp3b3VsZCBsaWtlIHRvIHNlZSB0aGVtIGFkZHJlc3Nl
ZC4NCg0KDQoNClRoYW5rIHlvdSwNCkphbm9zDQoNCg==

--_000_5BB134C01C9C4DC084E768F58EEEF053kaloomcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <70CFED776E8F4647AAECE3FDA824B5AE@CANPRD01.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIHRleHQgY2hhbmdlcyBK
w6Fub3MuIFRoZXkgbG9vayBnb29kIHRvIG1lLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TdXJl
c2g8YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMiwgMjAxOSwgYXQgNDowMyBQTSwg
SsOhbm9zIEZhcmthcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbm9zLmZhcmthc0Blcmljc3Nvbi5j
b20iIGNsYXNzPSIiPmphbm9zLmZhcmthc0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rp
dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi
PjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk
aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkhpDQogU3VyZXNoLDwvc3Bhbj48
YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0
eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250
LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp
bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoYW5rDQogeW91IGZvciB5b3VyIHJldmlldyE8L3Nw
YW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxi
ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl
eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg
d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBz
dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTog
aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5QbGVhc2UNCiBzZWUgaW4tbGluZTo8L3NwYW4+
PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBz
dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls
ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s
aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Pbg0KIDIvMjEvMjAxOSAzOjExIFBNLCBTdXJlc2gg
S3Jpc2huYW4gd3JvdGU6PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh
dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs
YXNzPSIiPg0KU3VyZXNoIEtyaXNobmFuIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90
IHBvc2l0aW9uIGZvcjxiciBjbGFzcz0iIj4NCmRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVy
ZS0xMTogTm8gT2JqZWN0aW9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hlbiByZXNw
b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g
YWxsPGJyIGNsYXNzPSIiPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg
Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnIgY2xhc3M9IiI+DQppbnRyb2R1Y3Rv
cnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiBjbGFzcz0iIj4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnIg
Y2xhc3M9IiI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP
TU1FTlQgcG9zaXRpb25zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g
YmUgZm91bmQgaGVyZTo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUvIiBjbGFzcz0iIj5o
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRl
Y3R1cmUvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpDT01NRU5UOjxiciBjbGFz
cz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIFNlY3Rp
b24gMy4yLjEuMS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpHaXZlbiB0aGF0IHdlIGFs
c28ga25vdyBzb21lIG9mIHRoZSBkb3duc2lkZXMgYXMgd2VsbCBvZiBsYXJnZSBidWZmZXJzLCBJ
IHRoaW5rPGJyIGNsYXNzPSIiPg0KYSBwb2ludGVyIHRvIHNvbWUgYmFja2dyb3VuZCBtaWdodCBi
ZSB3YXJyYW50ZWQgaGVyZS4gSSB3b3VsZCByZWNvbW1lbmQgYSBiYXNpYzxiciBjbGFzcz0iIj4N
CnJlZmVyZW5jZSB0byBzb21ldGhpbmcgbGlrZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CkJ1ZmZlcmJsb2F0OiBEYXJrIEJ1ZmZlcnMgaW4gdGhlIEludGVybmV0LCBDb21tdW5pY2F0aW9u
cyBvZiB0aGUgQUNNLCBKYW51YXJ5PGJyIGNsYXNzPSIiPg0KMjAxMiw8YnIgY2xhc3M9IiI+DQo8
L2Jsb2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBm
bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5BZGQNCiBy
ZWZlcmVuY2Ugd2l0aCBuZXcgc2VudGVuY2UgYXQgdGhlIGVuZCBvZiB0aGUgcGFyYWdyYXBoOiAm
cXVvdDtOb3RlIHRoYXQgbGFyZ2UgYnVmZmVycyBoYXZlIHNvbWUgaXNzdWVzLCBzZWUsIGUuZy4s
IFtCVUZGRVJCTE9BVF0uJnF1b3Q7PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg
MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog
bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog
bm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog
YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiogU2VjdGlvbiAzLjIuMi4yLjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCkl0IGlzIG5vdCBvYnZpb3VzIHRvIG1lIGhvdyB0aGUgUE9GIGNhbm5v
dCBiZSB0aGUgbGFzdCBvcGVyYXRpb24gYXQgdGhlPGJyIGNsYXNzPSIiPg0KcmVjZWl2ZXIuIENh
biB5b3UgY2xhcmlmeT8gQWxzbywgZG8gaW50ZXJtZWRpYXRlIG5vZGVzIGFwcGx5IHRoZSBQT0Y/
IEkgY2FuIHNlZTxiciBjbGFzcz0iIj4NCnRoZSBuZWVkIGZvciB0aGVtIHRvIGRvIFBSRiBhbmQg
UEVGcyBidXQgSSBhbSBub3Qgc3VyZSBhcHBseWluZyB0aGUgUE9GIGF0PGJyIGNsYXNzPSIiPg0K
aW50ZXJtZWRpYXRlIG5vZGVzIGNhbiBuZWNlc3NhcmlseSBoZWxwIHRoZSBsb3cgbGF0ZW5jeSBh
bmQgbG93IGppdHRlciBnb2Fscy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm
bmJzcDsmbmJzcDtUaGUgb3JkZXIgaW4gd2hpY2ggYSBEZXROZXQgbm9kZSBhcHBsaWVzIFBFRiwg
UE9GLCBhbmQgUFJGIHRvIGE8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtEZXROZXQg
ZmxvdyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv
dGU+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9u
ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGUNCiBpbnRlbnRpb24g
aGVyZSBpcyBub3QgdG8gYm91bmQgYW55IHNwZWNpZmljIG9yZGVyIG9mIHRoZSBQUkVPRiBmdW5j
dGlvbnMgd2l0aGluIGEgZGV2aWNlLCBvciBub3QgZXZlbiBib3VuZCB3aGljaCBkZXZpY2UgaW1w
bGVtZW50cyB3aGljaCBmdW5jdGlvbi4gVGhlcmUgY2FuIGJlIGNvbXBsZXggbmV0d29yayBzZXQt
dXBzIGNyZWF0ZWQuIEZ1cnRoZXJtb3JlLCBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIG1heSBo
YXZlIGRpZmZlcmVudCBwcm9zDQogYW5kIGNvbnMgd2l0aCByZXNwZWN0IHRvIHRoZSBvcmRlciBv
ZiBQUkVPRiBmdW5jdGlvbnMuIEFzIHBvaW50ZWQgb3V0LCB0aGlzIGlzIG1haW5seSB2YWxpZCBm
b3IgUFJGIGFuZCBQRUY7IGhvd2V2ZXIsIHRoZSBzYW1lIGxlYXZlIGl0IG9wZW4gYXBwcm9hY2gg
Y2FuIGJlIGNhcnJpZWQgb24gYWxsIG9mIHRoZSBQUkVPRiBmdW5jdGlvbnMgaW5jbHVkaW5nIFBP
Ri48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls
eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12
YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6
IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0i
Ij4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8
c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlz
cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Xb3VsZA0KIGl0IGhlbHAgdG8gcmVw
bGFjZSB0aGUgc2VudGVuY2Ugd2l0aD86PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv
cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz
cz0iIj4mbmJzcDsNCiBUaGUgb3JkZXIgaW4gd2hpY2ggYSBEZXROZXQgbm9kZSBhcHBsaWVzIFBF
RiwgUE9GLCBhbmQgUFJGIHRvIGE8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw
YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp
b246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi
PiZuYnNwOyZuYnNwOw0KIERldE5ldCBmbG93IGlzIGxlZnQgb3BlbiBmb3IgaW1wbGVtZW50YXRp
b25zLjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz
PSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N
CjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KKiBTZWN0aW9uIDMu
Mi4zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJGQzc0MjYgZG9lcyBub3QgY29udGFp
biBtdWNoIHNwZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IGV4cGxpY2l0IHJvdXRlIHNldHVwLjxi
ciBjbGFzcz0iIj4NCklzIHRoZXJlIGEgcGFydGljdWxhciBzZWN0aW9uIHlvdSB3YW50IHRvIHBv
aW50IHRvLiBJZiBub3QsIEkgZG9uJ3QgdGhpbmsgdGhpczxiciBjbGFzcz0iIj4NCnJlZmVyZW5j
ZSBpcyBvZiBtdWNoIHVzZS4gUkZDODQ1MyBpcyBsaXN0ZWQgdHdpY2UuPGJyIGNsYXNzPSIiPg0K
PC9ibG9ja3F1b3RlPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsg
ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RGVsZXRl
DQogUkZDNzQyNiBhbmQgb25lIG9mIHRoZSBSRkM4NDUzcy48L3NwYW4+PGJyIHN0eWxlPSJjYXJl
dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6
IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u
dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29s
b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4
dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt
YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh
dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTZWN0aW9uIDMuMy4xLjxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdCBzdXJlIHdoeSB0aGlzIGlzIGEgcmVxdWly
ZW1lbnQgYnV0IEkgZG8gd2lzaCB0byBub3RlIHRoYXQgdGhlcmUgYXJlIG5vIHN1Y2g8YnIgY2xh
c3M9IiI+DQp3b3JzdC1jYXNlIGxhdGVuY3kgZ3VhcmFudGVlcyBmb3IgYmVzdCBlZmZvcnQgdHJh
ZmZpYyAoYWthIG5vbi1EZXRuZXQpIGluPGJyIGNsYXNzPSIiPg0KY3VycmVudCBuZXR3b3Jrcy4g
Q2FuIHlvdSBjbGFyaWZ5PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw
OyZuYnNwO28gJm5ic3A7RGV0TmV0IGZsb3dzIGNhbiBiZSBzaGFwZWQgb3Igc2NoZWR1bGVkLCBp
biBvcmRlciB0byBlbnN1cmUgdGhhdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3RoZSBoaWdoZXN0LXByaW9yaXR5IG5vbi1EZXROZXQgcGFja2V0IGlz
IGFsc28gZW5zdXJlZCBhIHdvcnN0LTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO2Nhc2UgbGF0ZW5jeS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+
DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsg
ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGlzDQogaXMgdG8gcHJvdGVj
dCB0aGUgUW9TIG9mIG5vbi1EZXROZXQgZmxvd3MgaWYgbmVlZGVkLkRldE5ldCBmbG93cyBoYXZl
IHN0cmluZ2VudCBRb1MgcmVxdWlyZW1lbnRzLiBUaGVyZSBtYXkgYmUgbm9uLURldE5ldCBmbG93
cyB0aGF0IGFyZSBub3QgYmVzdC1lZmZvcnQsIGJ1dCBoYXZlIHNvbWUgUW9TIHJlcXVpcmVtZW50
cywgYWx0aG91Z2gsIGxlc3Mgc3RyaW5nZW50IHRoYW4gdGhhdCBvZiB0aGUgRGV0TmV0IGZsb3dz
Ljwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5
OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIi
Pg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxi
ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl
eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg
d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
KiBTZWN0aW9uIDQuMS4xLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgdGV4dCAm
cXVvdDtQZWVycyB3aXRoIER1cGxpY2F0ZSBlbGltaW5hdGlvbi4mcXVvdDsgc2VlbXMgdG8gYmUg
Y29tcGxldGVseSBvdXQgb2Y8YnIgY2xhc3M9IiI+DQpwbGFjZSB1bmRlciB0aGUgJnF1b3Q7UGFj
a2V0IHNlcXVlbmNpbmcmcXVvdDsgaGVhZGluZyBiZWxvdyBGaWd1cmUgMi4gQ29weSBhbmQgcGFz
dGU8YnIgY2xhc3M9IiI+DQplcnJvcj88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bh
biBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl
eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg
d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxh
eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5QYWNrZXQNCiBzZXF1ZW5jaW5nIHBlZXJz
IHdpdGggZHVwbGljYXRlIGVsaW1pbmF0aW9uLiBJdCBpcyBleHBsYWluZWQgdW5kZXIgZHVwbGlj
YXRlIGVsaW1pbmF0aW9uIGFzIHdlbGwsIGFuZCB0aGV5IGFyZSBsZXZlbGVkIGluIHRoZSBmaWd1
cmUuIFdvdWxkIG1lcmdpbmcgdGhlIHR3byBzZW50ZW5jZXMgaGVscD86PC9zcGFuPjxiciBzdHls
ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i
Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l
ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiBBcyBwYXJ0IG9mIERldE5ldCBzZXJ2aWNlIHBy
b3RlY3Rpb24sIHN1cHBsaWVzIHRoZSBzZXF1ZW5jZTwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl
eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50
OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQogbnVtYmVyIGZvciBwYWNrZXQgcmVwbGljYXRpb24gYW5kIGVsaW1p
bmF0aW9uIChTZWN0aW9uIDMuNCksPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw
LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u
OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsNCiB0aHVzIHBlZXJzIHdpdGggRHVwbGljYXRlIGVsaW1pbmF0aW9uLjwvc3Bhbj48YnIg
c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250
LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln
aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIFNlY3Rp
b24gNC4zLjIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBmb3VuZCB0aGUgZXhwcmVz
c2lvbiAmcXVvdDtudW1iZXIgb2YgYml0IHRpbWVzJnF1b3Q7IGNvbmZ1c2luZy4gSSBoYXZlIHVu
ZGVyc3Rvb2QgJnF1b3Q7Yml0PGJyIGNsYXNzPSIiPg0KdGltZSZxdW90OyB0byBtZWFuIHRoZSBh
bW91bnQgb2YgdGltZSB0YWtlbiB0byBlbWl0IGEgYml0IGZyb20gYSBuZXR3b3JrIGludGVyZmFj
ZS48YnIgY2xhc3M9IiI+DQpCYXNlZCBvbiB0aGF0IGRlZmluaXRpb24sIHRoaXMgZXhwcmVzc2lv
biBkb2VzIG5vdCBtYWtlIHNlbnNlLiBJcyB0aGVyZSBhPGJyIGNsYXNzPSIiPg0KYmV0dGVyIHJl
ZmVyZW5jZS9kZWZpbml0aW9uIG9mIHdoYXQgeW91IG1lYW4/PGJyIGNsYXNzPSIiPg0KPC9ibG9j
a3F1b3RlPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6
IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+V291bGQNCiBpdCBo
ZWxwIHRvIHJld3JpdGU/Ojwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg
MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog
bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog
bm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm
b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h
bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy
LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250
LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZs
b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9MRDo8L3Nw
YW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxz
cGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNw
bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOw0KIFRoZXNlIHBh
cmFtZXRlcnMsIHRvZ2V0aGVyIHdpdGgga25vd2xlZGdlIG9mIHRoZSBwcm90b2NvbCBzdGFjayB1
c2VkPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9
IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9u
ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsNCiAo
YW5kIHRodXMgdGhlIHNpemUgb2YgdGhlIHZhcmlvdXMgaGVhZGVycyBhZGRlZCB0byBhIHBhY2tl
dCksIGxpbWl0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9h
dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJz
cDsNCiB0aGUgbnVtYmVyIG9mIGJpdCB0aW1lcyBwZXIgb2JzZXJ2YXRpb24gaW50ZXJ2YWwgdGhh
dCB0aGUgRGV0TmV0IGZsb3c8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs
IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZu
YnNwOyZuYnNwOw0KIGNhbiBvY2N1cHkgdGhlIHBoeXNpY2FsIG1lZGl1bS48L3NwYW4+PGJyIHN0
eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0i
Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246
IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2Fy
ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp
bXBvcnRhbnQ7IiBjbGFzcz0iIj5ORVc6PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv
cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz
cz0iIj4mbmJzcDsmbmJzcDsNCiBUaGVzZSBwYXJhbWV0ZXJzLCB0b2dldGhlciB3aXRoIGtub3ds
ZWRnZSBvZiB0aGUgcHJvdG9jb2wgc3RhY2sgdXNlZDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl
eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50
OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7DQogKGFuZCB0aHVzIHRoZSBzaXplIG9mIHRoZSB2YXJp
b3VzIGhlYWRlcnMgYWRkZWQgdG8gYSBwYWNrZXQpLCBwcm92aWRlIHRoZTwvc3Bhbj48YnIgc3R5
bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9
ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu
ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7DQogYmFuZHdpZHRoIHRoYXQgaXMg
bmVlZGVkIGZvciB0aGUgdGhlIERldE5ldCBmbG93Ljwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl
eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv
bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt
aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl
Y29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk
b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh
dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u
ZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTZWN0aW9uIDQuNS48YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBtaWdodCBiZSBzb21lIG90aGVyIHJlY2VudCBJRVRGIGRl
ZmluZWQgbWVjaGFuaXNtcyB0aGF0IG1pZ2h0IGJlIHJlbGV2YW50PGJyIGNsYXNzPSIiPg0KdG8g
bWVudGlvbiBoZXJlIGFzIHdlbGwuIGUuZy4gUkZDODI4OSAoQ29kZWwpLCBSRkM4MDMzIChQSUUp
IGV0Yy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg
Y2xhc3M9IiI+QWRkDQogUkZDODI4OSBhbmQgUkZDODAzMyB3aXRoIGEgbmV3IHNlbnRlbmNlIGFz
IHRoZSBwZW51bHRpbWF0ZSBzZW50ZW5jZSBvZiB0aGUgc2VjdGlvbjo8L3NwYW4+PGJyIHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250
LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJj
YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp
emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog
MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg
IWltcG9ydGFudDsiIGNsYXNzPSIiPiZxdW90O0Z1cnRoZXINCiB0ZWNobmlxdWVzIGFyZSBkZWZp
bmVkIGJ5IHRoZSBJRVRGLCBlLmcuLCBbUkZDODI4OV0gYW5kIFtSRkM4MDMzXS4mcXVvdDs8L3Nw
YW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxi
ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl
eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg
d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5
bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiogU2Vj
dGlvbiA0LjcuMi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGlsZSBJUHY2IGRvZXMg
b2ZmZXIgYSBtZWNoYW5pc20gdG8gYWRkL3JlbW92ZSBhIGZsb3cgaWQgKGZsb3cgbGFiZWwpIG5v
dCBzdXJlPGJyIGNsYXNzPSIiPg0Kd2hhdCBraW5kIG9mIG1hcHBpbmcgeW91IHdlcmUgdGhpbmtp
bmcgZm9yIElQdjQuIElmIHRoaXMgaXMgbm90IHBvc3NpYmxlLCBJPGJyIGNsYXNzPSIiPg0KdGhp
bmsgYSBub3RlIHRvIHRoYXQgZWZmZWN0IG1pZ2h0IGJlIHVzZWZ1bCBoZXJlLjxiciBjbGFzcz0i
Ij4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkZs
b3cNCiBpZGVudGlmaWNhdGlvbiBkZXRhaWxzIGZvciBJUCBkYXRhIHBsYW5lIGFyZSBkZXNjcmli
ZWQgaW4gZHJhZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLiBXb3VsZCBpdCBoZWxwIHRvIGFkZCB0
aGUgZm9sbG93aW5nIGludHJvZHVjdG9yeSB0ZXh0IHRvIFNlY3Rpb24gNC43Pzo8L3NwYW4+PGJy
IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0
eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp
bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZxdW90O1RoaXMNCiBzZWN0aW9uIGRpc2N1c3Nl
cyB3aGF0IG5lZWRzIHRvIGJlIGRvbmUgYXQgdGVjaG5vbG9neSBib3JkZXJzIGluY2x1ZGluZyBF
dGhlcm5ldCBhcyBvbmUgb2YgdGhlIHRlY2hub2xvZ2llcy4gRmxvdyBpZGVudGlmaWNhdGlvbiBk
ZXRhaWxzIGZvciBNUExTIGFuZCBJUCBkYXRhIHBsYW5lcyBhcmUgZGVzY3JpYmVkIGluIFtJLUQu
aWV0Zi1kZXRuZXQtZHAtc29sLW1wbHNdIGFuZCBbSS1ELmlldGYtZGV0bmV0LWRwLXNvbC1pcF0s
IHJlc3BlY3RpdmVseS4mcXVvdDs8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw
YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp
b246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh
dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTZWN0aW9ucyA1IGFuZCA2PGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KSSBhbHNvIHN1cHBvcnQgQWxpc3NhIGFuZCBCZW5qYW1pbidzIERJU0NV
U1NlcyAob24gcHJpdmFjeSBhbmQgc2VjdXJpdHkpIGFuZDxiciBjbGFzcz0iIj4NCndvdWxkIGxp
a2UgdG8gc2VlIHRoZW0gYWRkcmVzc2VkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw
LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u
OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i
Ij5UaGFuaw0KIHlvdSw8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm
b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h
bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy
LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7
IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkphbm9z
PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_5BB134C01C9C4DC084E768F58EEEF053kaloomcom_--


From nobody Thu Mar  7 18:37:23 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 76E7E13124F for ; Thu,  7 Mar 2019 18:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level: 
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 ZvfzFuKmE2wB for ; Thu,  7 Mar 2019 18:37:19 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005089.outbound.protection.outlook.com [40.92.5.89]) (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 33A3313124C for ; Thu,  7 Mar 2019 18:37:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ikwX3CDIuS/YzQ8CYlTkT1WI6t+AWhc80SSLblUTlOU=; b=clT6E0f9gGe2OenGg/dgkPuVDbf84YjgJgIihHxrX/7ZlYjxZRRUaPrNcaKaRvbhEsi3e0w1Be7uu1XjsUnOW/ew9I6iR36Et+4rFOwuUWQeM8IkkKGASxfPu0kB36M2ZRlnbxW2+KIeTavJK1xI1d5Fb8zI3QT6zuVea1b4WiN9ngl9w1qiZPw9cTFFrRyKrMKIooK4AOR5hm/zNZ3F6Ndn0MBzWCK2SdaIcwR02CnQE10LhUFNKDOjXsSJqeXrs3uYD2L4kyAmFP588v6IBQxKwbBfhUg7Kar/dVJAtbzlSC4gHYqfr1IkSH7SNyIc64aRmoE1VJTv5ntj7EaJfQ==
Received: from SN1NAM02FT023.eop-nam02.prod.protection.outlook.com (10.152.72.53) by SN1NAM02HT033.eop-nam02.prod.protection.outlook.com (10.152.73.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11; Fri, 8 Mar 2019 02:37:12 +0000
Received: from BN6PR22MB0771.namprd22.prod.outlook.com (10.152.72.51) by SN1NAM02FT023.mail.protection.outlook.com (10.152.72.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11 via Frontend Transport; Fri, 8 Mar 2019 02:37:12 +0000
Received: from BN6PR22MB0771.namprd22.prod.outlook.com ([fe80::3880:fd6c:25e7:2a75]) by BN6PR22MB0771.namprd22.prod.outlook.com ([fe80::3880:fd6c:25e7:2a75%5]) with mapi id 15.20.1665.021; Fri, 8 Mar 2019 02:37:12 +0000
From: Liang GENG 
To: "detnet@ietf.org" 
Thread-Topic: Detnet requirement draft on bounded latency
Thread-Index: AQHU1VfVNkyJ1VACdkK1+AfT2yrbNQ==
Date: Fri, 8 Mar 2019 02:37:12 +0000
Message-ID: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:388195B13F4C00C3465E68BDDB97BC0EC4BBC481413B587AA737970364012919; UpperCasedChecksum:BB39F838E8B8575F5B91F0B23B4B5D43B79D031ECBABB7F5BA21FC72F8A75D7F; SizeAsReceived:6583; Count:41
x-tmn: [UIzoKsALyGnPEtyTP3Hx0B2cv3FSOtE7]
x-ms-publictraffictype: Email
x-incomingheadercount: 41
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT033; 
x-ms-traffictypediagnostic: SN1NAM02HT033:
x-microsoft-antispam-message-info: 5u/PNpWY1AVB6GBKneDW/PD9YCv0nnLFIeaH/Ygoe/vbcp5RQi0IhE/rvWkNTOiQ
Content-Type: multipart/alternative; boundary="_000_BN6PR22MB07712C7040223B7D0E3252E9874D0BN6PR22MB0771namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4efc317b-1c99-44b9-59b0-08d6a36ef85e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 02:37:12.6975 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT033
Archived-At: 
Subject: [Detnet] Detnet requirement draft on bounded latency
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, 08 Mar 2019 02:37:21 -0000

--_000_BN6PR22MB07712C7040223B7D0E3252E9874D0BN6PR22MB0771namp_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNCg0KVGhlIGZvbGxvd2luZyByZXF1aXJlbWVudCBkcmFmdCB3YXMgc3VibWl0
dGVkLiBDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk
cmFmdC1nZW5nLWRldG5ldC1yZXF1aXJlbWVudHMtYm91bmRlZC1sYXRlbmN5LTAxLnR4dA0KDQpo
YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpIFFpYW5nIGFuZCBwb3N0ZWQgdG8g
dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWdlbmctZGV0bmV0
LXJlcXVpcmVtZW50cy1ib3VuZGVkLWxhdGVuY3kNCg0KUmV2aXNpb246ICAgICAgIDAxDQoNClRp
dGxlOiAgICAgICAgICAgICBUZWNobmljYWwgUmVxdWlyZW1lbnRzIG9mIEJvdW5kZWQgTGF0ZW5j
eSBGb3J3YXJkaW5nDQoNCkRvY3VtZW50IGRhdGU6ICAgMjAxOS0wMy0wOA0KDQpHcm91cDogICAg
ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAgICAgIDYNCg0KVVJM
OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1n
ZW5nLWRldG5ldC1yZXF1aXJlbWVudHMtYm91bmRlZC1sYXRlbmN5LTAxLnR4dA0KDQpTdGF0dXM6
ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VuZy1kZXRu
ZXQtcmVxdWlyZW1lbnRzLWJvdW5kZWQtbGF0ZW5jeS8NCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZW5nLWRldG5ldC1yZXF1aXJlbWVudHMtYm91
bmRlZC1sYXRlbmN5LTAxDQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9odG1sL2RyYWZ0LWdlbmctZGV0bmV0LXJlcXVpcmVtZW50cy1ib3VuZGVkLWxh
dGVuY3kNCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs
Mj1kcmFmdC1nZW5nLWRldG5ldC1yZXF1aXJlbWVudHMtYm91bmRlZC1sYXRlbmN5LTAxDQoNCkFi
c3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IGFuYWx5c2VzIHRoZSB0ZWNobmljYWwgcmVxdWly
ZW1lbnRzIHRoYXQgTGF5ZXIgMw0KDQogICBib3VuZGVkIGxhdGVuY3kgZm9yd2FyZGluZyBzY2hl
bWUgc2hvdWxkIHNhdGlzZnkuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg
Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo
dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu
DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQq3osvN19QgT3V0bG9vazxodHRwOi8vYWth
Lm1zL3dlYm91dGxvb2s+DQo=

--_000_BN6PR22MB07712C7040223B7D0E3252E9874D0BN6PR22MB0771namp_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Dear all,









The following requirement draft was submitted. Comment=
s are welcome.















A new version of I-D, draft-geng-detnet-requirements-b=
ounded-latency-01.txt



has been successfully submitted by Li Qiang and posted=
 to the IETF repository.







Name:   =
;        draft-geng-detnet-requir=
ements-bounded-latency



Revision:       01



Title:  &nbs=
p;          Technical R=
equirements of Bounded Latency Forwarding



Document date:   2019-03-08



Group:  &nbs=
p;       Individual Submission<=
/p>


Pages:  &nbs=
p;         6



URL:   =
;         https://www.ietf.org/internet-drafts/draft-geng-detnet-requiremen=
ts-bounded-latency-01.txt



Status:  &n=
bsp;      https://datatra=
cker.ietf.org/doc/draft-geng-detnet-requirements-bounded-latency/



Htmlized:  =
     https://tools.ietf.org/html/=
draft-geng-detnet-requirements-bounded-latency-01



Htmlized:  =
     https://datatracker.i=
etf.org/doc/html/draft-geng-detnet-requirements-bounded-latency<=
/p>


Diff:  &nbs=
p;        =
https://www.ietf.org/rfcdiff?url2=3Ddraft-geng-detnet-requirements-bounded-=
latency-01







Abstract:



   T=
his document analyses the technical requirements that Layer 3



   b=
ounded latency forwarding scheme should satisfy.







   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;  












Please note that it may take a couple of minutes from =
the time of submission until the htmlized version and diff are available at=
 tools.ietf.org.







The IETF Secretariat














=B7=A2=CB=CD=D7=D4 Outlook








--_000_BN6PR22MB07712C7040223B7D0E3252E9874D0BN6PR22MB0771namp_--


From nobody Thu Mar  7 19:47:46 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 51C3713129F for ; Thu,  7 Mar 2019 19:47:45 -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, 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 wpPVUp13zYTs for ; Thu,  7 Mar 2019 19:47:43 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F284C1312AB for ; Thu,  7 Mar 2019 19:47:41 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8A395FD2DBE1887B1C72; Fri,  8 Mar 2019 03:47:39 +0000 (GMT)
Received: from DGGEMI423-HUB.china.huawei.com (10.1.199.152) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 03:47:38 +0000
Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.238]) by dggemi423-hub.china.huawei.com ([10.1.199.152]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 11:47:29 +0800
From: "qiangli (D)" 
To: DetNet WG 
CC: Toerless Eckert , Liang Geng , "Liubingyang (Bryan)" 
Thread-Topic: New Version Notification for draft-qiang-detnet-large-scale-detnet-03.txt
Thread-Index: AQHU1WFXHGzr4jjWzEqoPbYX0WMU2aYBGBGg
Date: Fri, 8 Mar 2019 03:47:29 +0000
Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BE94EC@dggemi529-mbs.china.huawei.com>
References: <155201670688.5390.2861555161103704003.idtracker@ietfa.amsl.com>
In-Reply-To: <155201670688.5390.2861555161103704003.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.130.163.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Detnet] New Version Notification for draft-qiang-detnet-large-scale-detnet-03.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2019 03:47:45 -0000

SGkgQWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXFpYW5nLWRldG5ldC1sYXJnZS1zY2Fs
ZS1kZXRuZXQgaGFzIGJlZW4gdXBsb2FkZWQuIFJldmlldyBhbmQgY29tbWVudCBpcyBoaWdobHkg
YXBwcmVjaWF0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KQ3Jpc3RpbmEgUUlBTkcNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp
bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE1hcmNoIDA4LCAy
MDE5IDExOjQ1IEFNDQpUbzogVG9lcmxlc3MgRWNrZXJ0IDx0dGUraWV0ZkBjcy5mYXUuZGU+OyBx
aWFuZ2xpIChEKSA8cWlhbmdsaTNAaHVhd2VpLmNvbT47IExpYW5nIEdlbmcgPGdlbmdsaWFuZ0Bj
aGluYW1vYmlsZS5jb20+OyBMaXViaW5neWFuZyAoQnJ5YW4pIDxsaXViaW5neWFuZ0BodWF3ZWku
Y29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1xaWFuZy1k
ZXRuZXQtbGFyZ2Utc2NhbGUtZGV0bmV0LTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E
LCBkcmFmdC1xaWFuZy1kZXRuZXQtbGFyZ2Utc2NhbGUtZGV0bmV0LTAzLnR4dA0KaGFzIGJlZW4g
c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaSBRaWFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG
IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1xaWFuZy1kZXRuZXQtbGFyZ2Utc2NhbGUtZGV0
bmV0DQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJTGFyZ2UtU2NhbGUgRGV0ZXJtaW5pc3RpYyBOZXR3
b3JrDQpEb2N1bWVudCBkYXRlOgkyMDE5LTAzLTA4DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz
c2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1xaWFuZy1kZXRuZXQtbGFyZ2Utc2NhbGUtZGV0bmV0LTAzLnR4
dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXFpYW5nLWRldG5ldC1sYXJnZS1zY2FsZS1kZXRuZXQvDQpIdG1saXplZDogICAgICAgaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXFpYW5nLWRldG5ldC1sYXJnZS1zY2FsZS1kZXRu
ZXQtMDMNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o
dG1sL2RyYWZ0LXFpYW5nLWRldG5ldC1sYXJnZS1zY2FsZS1kZXRuZXQNCkRpZmY6ICAgICAgICAg
ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcWlhbmctZGV0bmV0LWxh
cmdlLXNjYWxlLWRldG5ldC0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2Vu
dHMgdGhlIG92ZXJhbGwgZnJhbWV3b3JrIGFuZCBrZXkgbWV0aG9kIGZvcg0KICAgTGFyZ2Utc2Nh
bGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JrIChMRE4pLiAgTEROIGNhbiBwcm92aWRlIGJvdW5kZWQN
CiAgIGxhdGVuY3kgYW5kIGRlbGF5IHZhcmlhdGlvbiAoaml0dGVyKSB3aXRob3V0IHJlcXVpcmlu
ZyBwcmVjaXNlIHRpbWUNCiAgIHN5bmNocm9uaXphdGlvbiBhbW9uZyBub2Rlcywgb3IgcGVyLWZs
b3cgc3RhdGUgaW4gdHJhbnNpdCBub2Rlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t
IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp
YXQNCg0K


From nobody Fri Mar  8 07:26:14 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 721E9131381; Fri,  8 Mar 2019 07:26:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: detnet@ietf.org
Message-ID: <155205877244.3287.17528603522230173262@ietfa.amsl.com>
Date: Fri, 08 Mar 2019 07:26:12 -0800
Archived-At: 
Subject: [Detnet] I-D Action: draft-ietf-detnet-flow-information-model-03.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Mar 2019 15:26:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : DetNet Flow Information Model
        Authors         : János Farkas
                          Balázs Varga
                          Rodney Cummings
                          Yuanlong Jiang
	Filename        : draft-ietf-detnet-flow-information-model-03.txt
	Pages           : 25
	Date            : 2019-03-08

Abstract:
   This document describes flow and service information model for
   Deterministic Networking (DetNet).  The DetNet service is provided
   either for a Layer 3 or a Layer 2 flow.  This document provides
   DetNet flow and service information model both for Layer 3 and Layer
   2 flows in an integrated fashion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-flow-information-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-03
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-flow-information-model-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-flow-information-model-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Mar  8 23:07:06 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 94ADA124D68 for ; Fri,  8 Mar 2019 23:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uV1ccOQfDW91 for ; Fri,  8 Mar 2019 23:07:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A274D124C04 for ; Fri,  8 Mar 2019 23:07:03 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AAE1E241A27E5FBC0880 for ; Sat,  9 Mar 2019 07:07:01 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 9 Mar 2019 07:07:01 +0000
Received: from DGGEMM511-MBS.china.huawei.com ([169.254.2.138]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Sat, 9 Mar 2019 15:06:49 +0800
From: "Chenzhe (Z)" 
To: "detnet@ietf.org" 
CC: "qiangli (D)" 
Thread-Topic: [Detnet] New Version Notification for draft-chen-detnet-det-vpn-00.txt
Thread-Index: AdTWRom/nWCgZDSpSdWbjd5pXyb31A==
Date: Sat, 9 Mar 2019 07:06:48 +0000
Message-ID: <9CEC02A9061421448CF80B7E967CE5BB0349A185@dggemm511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.130.163.212]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [Detnet] New Version Notification for draft-chen-detnet-det-vpn-00.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2019 07:07:06 -0000

SGkgQWxsLA0KDQpBIC0wMCBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0ZWQsIGFueSBjb21tZW50cyBh
cmUgd2VsY29tZS4NCg0KUmVnYXJkcywNClpoZQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N
Cj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxOeW5tDPmnIg55pelIDE1OjAwDQo+
IOaUtuS7tuS6ujogQ2hlbnpoZSAoWikgPGNoZW56aGUxN0BodWF3ZWkuY29tPjsgcWlhbmdsaSAo
RCkNCj4gPHFpYW5nbGkzQGh1YXdlaS5jb20+DQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC1jaGVuLWRldG5ldC1kZXQtdnBuLTAwLnR4dA0KPiANCj4gDQo+IEEg
bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGVuLWRldG5ldC1kZXQtdnBuLTAwLnR4dCBoYXMg
YmVlbiBzdWNjZXNzZnVsbHkNCj4gc3VibWl0dGVkIGJ5IFpoZSBDaGVuIGFuZCBwb3N0ZWQgdG8g
dGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1jaGVuLWRldG5ldC1kZXQt
dnBuDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCURldGVybWluaXN0aWMgVlBODQo+IERvY3Vt
ZW50IGRhdGU6CTIwMTktMDMtMDgNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g
UGFnZXM6CQk3DQo+IFVSTDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWNoZW4tZGV0bmV0LWRldC12cG4tMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLWRldG5ldC1kZXQtdnBuLw0K
PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4t
ZGV0bmV0LWRldC12cG4tMDANCj4gSHRtbGl6ZWQ6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2h0bWwvZHJhZnQtY2hlbi1kZXRuZXQtZGV0LXZwbg0KPiANCj4gDQo+IEFic3Ry
YWN0Og0KPiAgICBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcgKERldE5ldCkgc2VydmljZXMgYXJl
IGV4cGVjdGVkIHRvIGJlDQo+ICAgIGludGVncmF0ZWQgd2l0aCBWUE4gdGVjaG5vbG9naWVzLiAg
U3VjaCBkZXBsb3ltZW50IHNjZW5hcmlvcyBpbmNsdWRlDQo+ICAgIG1vYmlsZSBiYWNraGF1bHMg
YW5kIFRTTiBpc2xhbmRzIGludGVyLWNvbm5lY3Rpb25zLiAgVGhpcyBkb2N1bWVudA0KPiAgICBk
ZXNjcmliZXMgYW4gb3ZlcmFsbCBWUE4gZnJhbWV3b3JrIHRoYXQgcHJvdmlkZXMgZGV0ZXJtaW5p
c3RpYw0KPiAgICB0cmFuc3BvcnQgc2VydmljZXMgKGNhbGxlZCBkZXRlcm1pbmlzdGljIFZQTiks
IHNwZWNpZmllcw0KPiAgICBjb3JyZXNwb25kaW5nIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmUgcHJv
dG9jb2xzIHRoYXQgYXJlIHJlcXVpcmVkIHRvDQo+ICAgIHN1cHBvcnQgdGhlIGZyYW1ld29yaywg
YW5kIGluaXRpYWxseSBzdW1tYXJpemVzIHBvdGVudGlhbCBleHRlbnNpb25zDQo+ICAgIG9mIGV4
aXN0aW5nIHByb3RvY29scyB0byBlbmFibGUgZGV0ZXJtaW5pc3RpYyBWUE5zLg0KPiANCj4gDQo+
IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu
dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZl
cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRo
ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Sat Mar  9 14:28:56 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 C38671277CD; Sat,  9 Mar 2019 14:28:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: detnet@ietf.org
Message-ID: <155217052776.28605.9147648294871810530@ietfa.amsl.com>
Date: Sat, 09 Mar 2019 14:28:47 -0800
Archived-At: 
Subject: [Detnet] I-D Action: draft-ietf-detnet-architecture-12.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: Sat, 09 Mar 2019 22:28:48 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : Deterministic Networking Architecture
        Authors         : Norman Finn
                          Pascal Thubert
                          Balázs Varga
                          János Farkas
	Filename        : draft-ietf-detnet-architecture-12.txt
	Pages           : 45
	Date            : 2019-03-09

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-architecture-12
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-12


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 Mar  9 14:36: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 B696E130E64 for ; Sat,  9 Mar 2019 14:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkijXibfUdBW for ; Sat,  9 Mar 2019 14:36:45 -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 6DCB212958B for ; Sat,  9 Mar 2019 14:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1552171002; x=1554763002; 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=iZ106a/oNfpqJGHTPoLBmOG8qAf7B426CtvlhkQqchc=; b=IQzg2u0xqnsytqhJzBKO76Hv42jSPdgZrlI5guU7viobTT9B+aSHOyNsUDaTOdrA 8D5qSXI8dHZ79fK2WVXE8O9Y11sLh4Cf+G4ISDhc4RzLVgXJiCAi1tMS3FsLFUIq U1oBSYsBiTi2hHMih+wMldiA4EHJyCnZ0HRFlVJHtTg=;
X-AuditID: c1b4fb25-d89ff70000005ff7-d3-5c843ffa446f
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.2C.24567.AFF348C5; Sat,  9 Mar 2019 23:36:42 +0100 (CET)
Received: from ESESBMB502.ericsson.se (153.88.183.169) 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; Sat, 9 Mar 2019 23:36:41 +0100
Received: from [100.94.203.43] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 9 Mar 2019 23:36:39 +0100
To: Suresh Krishnan 
CC: The IESG , "draft-ietf-detnet-architecture@ietf.org" , Lou Berger , "detnet-chairs@ietf.org" , "detnet@ietf.org" 
References: <155075828359.8615.9538259641487527490.idtracker@ietfa.amsl.com>  <5BB134C0-1C9C-4DC0-84E7-68F58EEEF053@kaloom.com>
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: 
Date: Sat, 9 Mar 2019 23:36:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <5BB134C0-1C9C-4DC0-84E7-68F58EEEF053@kaloom.com>
Content-Type: multipart/alternative; boundary="------------8F2FAF035C961A17EA50F740"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbG9XPeXfUuMwZNrkhbX+n+wWPz+NJvF 4sO3mSwWM/5MZLboaH7LYrGt6xSLA5vHkiU/mTzOX5nB7vFhUzNbAHMUl01Kak5mWWqRvl0C V8aJd/9YClY8Zq6Y+XMZSwNj8wmmLkZODgkBE4kTF/+xdjFycQgJHGGUmNC4mwXC+coocWfJ DXYI5zCjxKtFsxhBWoQFkiQ+/98L1MLBISKgLvFwiQJIDbPAO0aJF79nM0E0bGOUeH7hCVgD m4C9xN1LG5hBbF4ge+rGt2wgNouAisTOGavA7hAViJX4dGUxVI2gxMmZT1hAbE4BO4nNfdfZ QWxmgTCJKfu6mSBscYlbT+aD2UICahKf3j5kn8AoOAtJ+ywkLbOQtEDYFhIz559nhLDlJZq3 zmaGsDUkWufMZUcWX8DIvopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJYObvmtuoPx8hvH Q4wCHIxKPLzfzVpihFgTy4orcw8xSnAwK4nwbvjQHCPEm5JYWZValB9fVJqTWnyIUZqDRUmc 94+QYIyQQHpiSWp2ampBahFMlomDU6qBcaJXhyu/8tL6+pzv4X4dWas4Finde/Pkgu+f3i4Z R5eKg9NW/e1ms7n1wKz3+d+Vf0oWyHTvsGXzNtkruFYkw9bvYOXFRb6LQjbzTFOTdvW0fPPz 1l/Bxr7w3acKX99auPmqiFa4i1HThq+ljr9NwgMl5MOPP+Tb43/zbMX1TRO+PLn449htPSWW 4oxEQy3mouJEAPZNqI2hAgAA
Archived-At: 
Subject: Re: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Mar 2019 22:36:48 -0000

--------------8F2FAF035C961A17EA50F740
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Thank you Suresh,
Janos

On 3/7/2019 5:41 PM, Suresh Krishnan wrote:
> Thanks for the text changes János. They look good to me.
>
> Regards
> Suresh
>
>> On Mar 2, 2019, at 4:03 PM, János Farkas > > wrote:
>>
>> Hi Suresh,
>>
>> Thank you for your review!
>>
>> Please see in-line:
>>
>> On 2/21/2019 3:11 PM, Suresh Krishnan wrote:
>>> Suresh Krishnan has entered the following ballot position for
>>> draft-ietf-detnet-architecture-11: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to 
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> * Section 3.2.1.1.
>>>
>>> Given that we also know some of the downsides as well of large 
>>> buffers, I think
>>> a pointer to some background might be warranted here. I would 
>>> recommend a basic
>>> reference to something like
>>>
>>> Bufferbloat: Dark Buffers in the Internet, Communications of the 
>>> ACM, January
>>> 2012,
>> Add reference with new sentence at the end of the paragraph: "Note 
>> that large buffers have some issues, see, e.g., [BUFFERBLOAT]."
>>
>>>
>>> * Section 3.2.2.2.
>>>
>>> It is not obvious to me how the POF cannot be the last operation at the
>>> receiver. Can you clarify? Also, do intermediate nodes apply the 
>>> POF? I can see
>>> the need for them to do PRF and PEFs but I am not sure applying the 
>>> POF at
>>> intermediate nodes can necessarily help the low latency and low 
>>> jitter goals.
>>>
>>>    The order in which a DetNet node applies PEF, POF, and PRF to a
>>>    DetNet flow is implementation specific.
>> The intention here is not to bound any specific order of the PREOF 
>> functions within a device, or not even bound which device implements 
>> which function. There can be complex network set-ups created. 
>> Furthermore, different implementations may have different pros and 
>> cons with respect to the order of PREOF functions. As pointed out, 
>> this is mainly valid for PRF and PEF; however, the same leave it open 
>> approach can be carried on all of the PREOF functions including POF.
>>
>> Would it help to replace the sentence with?:
>>   The order in which a DetNet node applies PEF, POF, and PRF to a
>>    DetNet flow is left open for implementations.
>>
>>
>>> * Section 3.2.3.
>>>
>>> RFC7426 does not contain much specific information about explicit 
>>> route setup.
>>> Is there a particular section you want to point to. If not, I don't 
>>> think this
>>> reference is of much use. RFC8453 is listed twice.
>> Delete RFC7426 and one of the RFC8453s.
>>
>>>
>>> * Section 3.3.1.
>>>
>>> Not sure why this is a requirement but I do wish to note that there 
>>> are no such
>>> worst-case latency guarantees for best effort traffic (aka 
>>> non-Detnet) in
>>> current networks. Can you clarify?
>>>
>>>    o  DetNet flows can be shaped or scheduled, in order to ensure that
>>>       the highest-priority non-DetNet packet is also ensured a worst-
>>>       case latency.
>> This is to protect the QoS of non-DetNet flows if needed.DetNet flows 
>> have stringent QoS requirements. There may be non-DetNet flows that 
>> are not best-effort, but have some QoS requirements, although, less 
>> stringent than that of the DetNet flows.
>>
>>
>>>
>>> * Section 4.1.1.
>>>
>>> This text "Peers with Duplicate elimination." seems to be completely 
>>> out of
>>> place under the "Packet sequencing" heading below Figure 2. Copy and 
>>> paste
>>> error?
>> Packet sequencing peers with duplicate elimination. It is explained 
>> under duplicate elimination as well, and they are leveled in the 
>> figure. Would merging the two sentences help?:
>>            As part of DetNet service protection, supplies the sequence
>>            number for packet replication and elimination (Section 3.4),
>>            thus peers with Duplicate elimination.
>>
>>>
>>> * Section 4.3.2.
>>>
>>> I found the expression "number of bit times" confusing. I have 
>>> understood "bit
>>> time" to mean the amount of time taken to emit a bit from a network 
>>> interface.
>>> Based on that definition, this expression does not make sense. Is 
>>> there a
>>> better reference/definition of what you mean?
>> Would it help to rewrite?:
>>
>> OLD:
>>    These parameters, together with knowledge of the protocol stack used
>>    (and thus the size of the various headers added to a packet), limit
>>    the number of bit times per observation interval that the DetNet flow
>>    can occupy the physical medium.
>>
>> NEW:
>>    These parameters, together with knowledge of the protocol stack used
>>    (and thus the size of the various headers added to a packet), 
>> provide the
>>    bandwidth that is needed for the the DetNet flow.
>>
>>
>>>
>>> * Section 4.5.
>>>
>>> There might be some other recent IETF defined mechanisms that might 
>>> be relevant
>>> to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc.
>>
>> Add RFC8289 and RFC8033 with a new sentence as the penultimate 
>> sentence of the section:
>> "Further techniques are defined by the IETF, e.g., [RFC8289] and 
>> [RFC8033]."
>>
>>
>>>
>>> * Section 4.7.2.
>>>
>>> While IPv6 does offer a mechanism to add/remove a flow id (flow 
>>> label) not sure
>>> what kind of mapping you were thinking for IPv4. If this is not 
>>> possible, I
>>> think a note to that effect might be useful here.
>> Flow identification details for IP data plane are described in 
>> draft-ietf-detnet-dp-sol-ip. Would it help to add the following 
>> introductory text to Section 4.7?:
>> "This section discusses what needs to be done at technology borders 
>> including Ethernet as one of the technologies. Flow identification 
>> details for MPLS and IP data planes are described in 
>> [I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip], 
>> respectively."
>>
>>>
>>> * Sections 5 and 6
>>>
>>> I also support Alissa and Benjamin's DISCUSSes (on privacy and 
>>> security) and
>>> would like to see them addressed.
>>>
>>>
>>
>> Thank you,
>> Janos
>


--------------8F2FAF035C961A17EA50F740
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Thank you Suresh,

    Janos

    

    
On 3/7/2019 5:41 PM, Suresh Krishnan
      wrote:

    

    

      
      Thanks for the text changes János. They look good to me.
      


      

      
Regards

      
Suresh

        


          

            
On Mar 2, 2019, at 4:03 PM, János Farkas <janos.farkas@ericsson.com>
              wrote:

            

            
Hi Suresh,

              

              Thank you for your review!

              

              Please see in-line:

              

              On 2/21/2019 3:11 PM, Suresh
                Krishnan wrote:

              

                Suresh Krishnan has entered the following ballot
                position for

                draft-ietf-detnet-architecture-11: No Objection

                

                When responding, please keep the subject line intact and
                reply to all

                email addresses included in the To and CC lines. (Feel
                free to cut this

                introductory paragraph, however.)

                

                

                Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

                for more information about IESG DISCUSS and COMMENT
                positions.

                

                

                The document, along with other ballot positions, can be
                found here:

                https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/

                

                

                

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

                COMMENT:

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

                

                * Section 3.2.1.1.

                

                Given that we also know some of the downsides as well of
                large buffers, I think

                a pointer to some background might be warranted here. I
                would recommend a basic

                reference to something like

                

                Bufferbloat: Dark Buffers in the Internet,
                Communications of the ACM, January

                2012,

              

              Add reference with new sentence at
                the end of the paragraph: "Note that large buffers have
                some issues, see, e.g., [BUFFERBLOAT]."

              

              

                

                * Section 3.2.2.2.

                

                It is not obvious to me how the POF cannot be the last
                operation at the

                receiver. Can you clarify? Also, do intermediate nodes
                apply the POF? I can see

                the need for them to do PRF and PEFs but I am not sure
                applying the POF at

                intermediate nodes can necessarily help the low latency
                and low jitter goals.

                

                   The order in which a DetNet node applies PEF, POF,
                and PRF to a

                   DetNet flow is implementation specific.

              

              The intention here is not to bound
                any specific order of the PREOF functions within a
                device, or not even bound which device implements which
                function. There can be complex network set-ups created.
                Furthermore, different implementations may have
                different pros and cons with respect to the order of
                PREOF functions. As pointed out, this is mainly valid
                for PRF and PEF; however, the same leave it open
                approach can be carried on all of the PREOF functions
                including POF.

              

              Would it help to replace the
                sentence with?:

                The order in which a DetNet node
                applies PEF, POF, and PRF to a

                 DetNet flow is left open for
                implementations.

              

              

              

                * Section 3.2.3.

                

                RFC7426 does not contain much specific information about
                explicit route setup.

                Is there a particular section you want to point to. If
                not, I don't think this

                reference is of much use. RFC8453 is listed twice.

              

              Delete RFC7426 and one of the
                RFC8453s.

              

              

                

                * Section 3.3.1.

                

                Not sure why this is a requirement but I do wish to note
                that there are no such

                worst-case latency guarantees for best effort traffic
                (aka non-Detnet) in

                current networks. Can you clarify?

                

                   o  DetNet flows can be shaped or scheduled, in order
                to ensure that

                      the highest-priority non-DetNet packet is also
                ensured a worst-

                      case latency.

              

              This is to protect the QoS of
                non-DetNet flows if needed.DetNet flows have stringent
                QoS requirements. There may be non-DetNet flows that are
                not best-effort, but have some QoS requirements,
                although, less stringent than that of the DetNet flows.

              

              

              

                

                * Section 4.1.1.

                

                This text "Peers with Duplicate elimination." seems to
                be completely out of

                place under the "Packet sequencing" heading below Figure
                2. Copy and paste

                error?

              

              Packet sequencing peers with
                duplicate elimination. It is explained under duplicate
                elimination as well, and they are leveled in the figure.
                Would merging the two sentences help?:

                         As part of DetNet
                service protection, supplies the sequence

                         number for packet
                replication and elimination (Section 3.4),

                         thus peers with
                Duplicate elimination.

              

              

                

                * Section 4.3.2.

                

                I found the expression "number of bit times" confusing.
                I have understood "bit

                time" to mean the amount of time taken to emit a bit
                from a network interface.

                Based on that definition, this expression does not make
                sense. Is there a

                better reference/definition of what you mean?

              

              Would it help to rewrite?:

              

              OLD:

                 These parameters, together with
                knowledge of the protocol stack used

                 (and thus the size of the
                various headers added to a packet), limit

                 the number of bit times per
                observation interval that the DetNet flow

                 can occupy the physical medium.

              

              NEW:

                 These parameters, together with
                knowledge of the protocol stack used

                 (and thus the size of the
                various headers added to a packet), provide the

                 bandwidth that is needed for
                the the DetNet flow.

              

              

              

                

                * Section 4.5.

                

                There might be some other recent IETF defined mechanisms
                that might be relevant

                to mention here as well. e.g. RFC8289 (Codel), RFC8033
                (PIE) etc.

              

              

              Add RFC8289 and RFC8033 with a new
                sentence as the penultimate sentence of the section:

              "Further techniques are defined by
                the IETF, e.g., [RFC8289] and [RFC8033]."

              

              

              

                

                * Section 4.7.2.

                

                While IPv6 does offer a mechanism to add/remove a flow
                id (flow label) not sure

                what kind of mapping you were thinking for IPv4. If this
                is not possible, I

                think a note to that effect might be useful here.

              

              Flow identification details for IP
                data plane are described in draft-ietf-detnet-dp-sol-ip.
                Would it help to add the following introductory text to
                Section 4.7?:

              "This section discusses what needs
                to be done at technology borders including Ethernet as
                one of the technologies. Flow identification details for
                MPLS and IP data planes are described in
                [I-D.ietf-detnet-dp-sol-mpls] and
                [I-D.ietf-detnet-dp-sol-ip], respectively."

              

              

                

                * Sections 5 and 6

                

                I also support Alissa and Benjamin's DISCUSSes (on
                privacy and security) and

                would like to see them addressed.

                

                

              

              

              Thank you,

              Janos

          

        

        

      

    

    

  


--------------8F2FAF035C961A17EA50F740--


From nobody Sat Mar  9 14:41:19 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 92647130EBA for ; Sat,  9 Mar 2019 14:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIExW1lPTWvp for ; Sat,  9 Mar 2019 14:41:07 -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 6C768130EDA for ; Sat,  9 Mar 2019 14:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1552171263; x=1554763263; 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=M+c49Ic7RBDaSKK9h6pGAGxd3ihSYre5OR3esMOVCuQ=; b=f9XFKTthcNWX2D5LxOC8v0+qHL1uEPO/L1mJmrqNvE2cp4eDv1jIUPOeRypH6BAJ mRWdAJ2ak5FEHjNdZV5NKggrlQBRONmQlcSSDbg/4H1i+ZUhMsHiYzyzpGIMaodS utPr0dxdb/2eOhfjC3ZA8w/tQosi5+9mVuUhV7rovrI=;
X-AuditID: c1b4fb2d-d9dff7000000062f-0f-5c8440fe458f
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.A9.01583.EF0448C5; Sat,  9 Mar 2019 23:41:02 +0100 (CET)
Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESSMB503.ericsson.se (153.88.183.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Mar 2019 23:41:02 +0100
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Mar 2019 23:41:01 +0100
Received: from [100.94.203.43] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Sat, 9 Mar 2019 23:41:00 +0100
References: <155217052806.28605.11692268467989935342.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
To: , DetNet WG 
X-Forwarded-Message-Id: <155217052806.28605.11692268467989935342.idtracker@ietfa.amsl.com>
Message-ID: <6fdf44a2-06f7-42d5-d86d-96be8f367504@ericsson.com>
Date: Sat, 9 Mar 2019 23:40:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <155217052806.28605.11692268467989935342.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------399BCD9C504D95583321E2C1"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7pe4/h5YYg859lha/P81msZjxZyKz A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyGuceYirYvouz4sz3XSwNjJOmcHQxcnJICJhI3Nxw lLGLkYtDSOAIo8Sqy+dYIJyvjBKb9k5lhnO6dz9gg3AOM0qsePaWCaRfWEBL4tmiL0BVHEAJ P4nGXk2QMJuAvcTdSxuYQWwRAQOJl7fuMUOsi5L4f3wBG4jNC1TzclIXK4jNIqAisf/dd7CR ogKxEp+uLGaGqBGUODnzCQuIzSngLzF/QxNYDbNAmMT+3mPsELa4xK0n88HiQgJqEu8b7jBO YBSahaR9FpKWWUhaIGwLiZnzzzNC2PISzVtnM0PYGhKtc+ayI4svYGRfxShanFpcnJtuZKyX WpSZXFycn6eXl1qyiREYJQe3/Nbdwbj6teMhRgEORiUeXifzlhgh1sSy4srcQ4wSHMxKIrwb PjTHCPGmJFZWpRblxxeV5qQWH2KU5mBREuf9IyQYIySQnliSmp2aWpBaBJNl4uCUamAM9z57 Mv8lawRL0QEF/X+2gSev3T5UfjrlbwL3DZ7cl9ef32YtVA9++ndV2vvVVkvz7T26zX40ipxK 1DdddvbOT0XTFY0++yNUWxb/FS9/qNuVYrg2Zqn9z3dNS8+9Kbv3NFNz8v0pzdunyTz9sUL+ ydu1pRwFAfyJqqflpZcKHrKf7bg4KnK9EktxRqKhFnNRcSIA0PmLTo4CAAA=
Archived-At: 
Subject: [Detnet] draft-ietf-detnet-architecture-12
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, 09 Mar 2019 22:41:10 -0000

--------------399BCD9C504D95583321E2C1
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

The DetNet architecture draft has been updated based on the comments 
received on draft-ietf-detnet-architecture-11. 
draft-ietf-detnet-architecture-12 resolves these comments as discussed 
on the list according to the following threads:
https://mailarchive.ietf.org/arch/msg/detnet/QqUWlFnG9iJl5qXnuprPC6J4rDo
https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
https://mailarchive.ietf.org/arch/msg/detnet/EII8VE1f_Ssel8G2lGgYUOjiCcg
https://mailarchive.ietf.org/arch/msg/detnet/tIEjWWUqY2gOvbUNkUlV1HDJB30
https://mailarchive.ietf.org/arch/msg/detnet/vU7eawHHcIEVcL_GnnAu2olQL3Y
https://mailarchive.ietf.org/arch/msg/detnet/0KUpocGxJNRAfDknzUQ9HcV0Re4
https://mailarchive.ietf.org/arch/msg/detnet/SxOHWdE87Q9GT_iI8igrfOwPaSM
https://mailarchive.ietf.org/arch/msg/detnet/Bl5owkhDpKN92XHcfcmRCRdVd2o
https://mailarchive.ietf.org/arch/msg/detnet/EAQWmP2W-xJek1Sg7r3YE4rDz68

The changes are shown here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-12

Best regards,
Janos

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-ietf-detnet-architecture-12.txt
Date: 	Sat, 9 Mar 2019 14:28:48 -0800
From: 	internet-drafts@ietf.org
To: 	Balazs Varga , Norman Finn 
, Pascal Thubert , 
Balázs Varga , Janos Farkas 
, János Farkas 




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

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

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



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------399BCD9C504D95583321E2C1
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  

    
  
  
    Hi,

    

    The DetNet architecture draft has been updated based on the comments
    received on draft-ietf-detnet-architecture-11.
    draft-ietf-detnet-architecture-12 resolves these comments as
    discussed on the list according to the following threads:

    
https://mailarchive.ietf.org/arch/msg/detnet/QqUWlFnG9iJl5qXnuprPC6J4rDo
      

https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
      

https://mailarchive.ietf.org/arch/msg/detnet/EII8VE1f_Ssel8G2lGgYUOjiCcg
    

    https://mailarchive.ietf.org/arch/msg/detnet/tIEjWWUqY2gOvbUNkUlV1HDJB30

https://mailarchive.ietf.org/arch/msg/detnet/vU7eawHHcIEVcL_GnnAu2olQL3Y

https://mailarchive.ietf.org/arch/msg/detnet/0KUpocGxJNRAfDknzUQ9HcV0Re4
    

    https://mailarchive.ietf.org/arch/msg/detnet/SxOHWdE87Q9GT_iI8igrfOwPaSM

https://mailarchive.ietf.org/arch/msg/detnet/Bl5owkhDpKN92XHcfcmRCRdVd2o
    
    
https://mailarchive.ietf.org/arch/msg/detnet/EAQWmP2W-xJek1Sg7r3YE4rDz68

      

      The changes are shown here:
      https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-12

      

      Best regards,

      Janos

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-ietf-detnet-architecture-12.txt
          

          

            Date: 
            Sat, 9 Mar 2019 14:28:48 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Balazs Varga <balazs.a.varga@ericsson.com>, Norman
              Finn <norman.finn@mail01.huawei.com>, Pascal Thubert
              <pthubert@cisco.com>, Balázs Varga
              <balazs.a.varga@ericsson.com>, Janos Farkas
              <janos.farkas@ericsson.com>, János Farkas
              <janos.farkas@ericsson.com>
          

        
      

      

      

      

      A new version of I-D, draft-ietf-detnet-architecture-12.txt

      has been successfully submitted by János Farkas and posted to the

      IETF repository.

      

      Name: draft-ietf-detnet-architecture

      Revision: 12

      Title: Deterministic Networking Architecture

      Document date: 2019-03-09

      Group: detnet

      Pages: 45

      URL:
https://www.ietf.org/internet-drafts/draft-ietf-detnet-architecture-12.txt

      Status:
      https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/

      Htmlized:
      https://tools.ietf.org/html/draft-ietf-detnet-architecture-12

      Htmlized:
      https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture

      Diff:
      https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-12

      

      Abstract:

      This document provides the overall architecture for Deterministic

      Networking (DetNet), which provides a capability to carry
      specified

      unicast or multicast data flows for real-time applications with

      extremely low data loss rates and bounded latency within a network

      domain. Techniques used include: 1) reserving data plane resources

      for individual (or aggregated) DetNet flows in some or all of the

      intermediate nodes along the path of the flow; 2) providing
      explicit

      routes for DetNet flows that do not immediately change with the

      network topology; and 3) distributing data from DetNet flow
      packets

      over time and/or space to ensure delivery of each packet's data in

      spite of the loss of a path. DetNet operates at the IP layer and

      delivers service over lower layer technologies such as MPLS and
      IEEE

      802.1 Time-Sensitive Networking (TSN).

      

      

      

      Please note that it may take a couple of minutes from the time of
      submission

      until the htmlized version and diff are available at
      tools.ietf.org.

      

      The IETF Secretariat

      

    

  


--------------399BCD9C504D95583321E2C1--


From nobody Sun Mar 10 09:44:12 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 F1CAF126D00; Sun, 10 Mar 2019 09:44:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: detnet@ietf.org
Message-ID: <155223625096.30991.6441457827310181606@ietfa.amsl.com>
Date: Sun, 10 Mar 2019 09:44:10 -0700
Archived-At: 
Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-ip-02.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Mar 2019 16:44:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : DetNet IP Data Plane Encapsulation
        Authors         : Jouni Korhonen
                          Balázs Varga
	Filename        : draft-ietf-detnet-dp-sol-ip-02.txt
	Pages           : 44
	Date            : 2019-03-10

Abstract:
   This document specifies the Deterministic Networking data plane when
   operating in an IP packet switched network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-02
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-ip-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-dp-sol-ip-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Mar 10 09:50:11 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 182A3127817; Sun, 10 Mar 2019 09:50:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: detnet@ietf.org
Message-ID: <155223660899.31077.12028918968993064585@ietfa.amsl.com>
Date: Sun, 10 Mar 2019 09:50:09 -0700
Archived-At: 
Subject: [Detnet] I-D Action: draft-ietf-detnet-dp-sol-mpls-02.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Mar 2019 16:50:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : DetNet MPLS Data Plane Encapsulation
        Authors         : Jouni Korhonen
                          Balázs Varga
	Filename        : draft-ietf-detnet-dp-sol-mpls-02.txt
	Pages           : 53
	Date            : 2019-03-10

Abstract:
   This document specifies the Deterministic Networking data plane when
   operating over an MPLS Packet Switched Networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-mpls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-02
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-mpls-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-dp-sol-mpls-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Mar 11 15:14:41 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 8ADCA1311C3; Mon, 11 Mar 2019 15:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level: 
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 cqnyrn8dX4UX; Mon, 11 Mar 2019 15:14:34 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780101.outbound.protection.outlook.com [40.107.78.101]) (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 06630131083; Mon, 11 Mar 2019 15:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/dQMEH+rCVxhHoXJDZZU9lEjG7hVCAScITXIyb8w4xE=; b=guqVfdhAdLPo5ydDQMKoFSadqYlDcm20cAVXG/MHFNfNbEAQ2mFA6hva11Jh9YTFkmiyg4ckkRT8iHBGg2owVLQcpA0MlwDkW6qH81suPRgXCNT5yDS+H/ya6y0wQH1F4n8Iwy6rAhzL/t7ol2UJssJ3DGOsPhAIEiymNWzVjjc=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB4104.namprd06.prod.outlook.com (52.135.193.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19; Mon, 11 Mar 2019 22:14:29 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500%6]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 22:14:29 +0000
From: "Grossman, Ethan A." 
To: "detnet@ietf.org" 
CC: "detnet-chairs@ietf.org" 
Thread-Topic: IETF 104 Prague - DetNet Meeting Slot Requests
Thread-Index: AdTReQex1F+xgNmXSJqcMtZOU5wPyAG3nOSA
Date: Mon, 11 Mar 2019 22:14:29 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTA4NzU5ZWI0LTQ0NGItMTFlOS1hZTNjLWFjYmMzMjdhNTFjNlxhbWUtdGVzdFwwODc1OWViNi00NDRiLTExZTktYWUzYy1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSI2NDY0IiB0PSIxMzE5NjgxNjA2NzY4MzM2MDQiIGg9ImJ0M1hvdXMycVo1UVprREJLTHZhSFJQMkFlQT0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4=
x-originating-ip: [8.39.141.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8ce5817c-e007-4719-a772-08d6a66eee39
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB4104; 
x-ms-traffictypediagnostic: BYAPR06MB4104:
x-ms-exchange-purlcount: 2
x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB4104; 23:n51YXX9DsA600yA4i4o3wgj1rTzkR6MnTnNVgwrWi?= =?us-ascii?Q?y4yv5dBNgtUUgq2xfBR2x5IEhKb8x9lRq5QlU4JzYNebi8QxljTItsbSYFed?= =?us-ascii?Q?N8wIy5+X931YAeSvkRPN6od0fbfuqZLBhAphNx50jzXJptAcerMfH41wjuWE?= =?us-ascii?Q?v3AHEHPkowpEHD3YiL3V+KUwsDZfLKBK8OrRWx1ruQkuHJkPT7QVJguyvnM/?= =?us-ascii?Q?kprWkaH4/ZsZ4YB7AKhVwJweEeIDIX8bxXB4vTDrpZxxYHIwSCe4JaeUulhf?= =?us-ascii?Q?YNdja00fmsOQuE15juRJ7brFnyDUPV0Bvucvoy6j3Ir/HQmF3IcjnnDcr7QJ?= =?us-ascii?Q?4wzCvfNlR3ils6hEC8gi3egO/M2eLK5fGmltBwjrqfmi9N2ObyiMT2fj2XaR?= =?us-ascii?Q?r2Pb0CG9+YgW8e57AC5OYtdCQm711GaFsE9YTMTiwEvTrf0Pc+UdodUboaSx?= =?us-ascii?Q?bwVBusNKrzW3upFkIoBxy8GmbyzBw54k45jF9kyRw/WCBkxjVLwPYVnUyAki?= =?us-ascii?Q?ePA5O/itLg3IH68Z9jdb8kjiy1CrJmGh63aYZvlXNOSvroFex9qKfqwG7xcE?= =?us-ascii?Q?P3v1qOEABZxgPgYZAbfESXsI6TEj75sMgDb8AKMCdSjcWxKo4kiBLjsI+OiG?= =?us-ascii?Q?MwmZ3GztNUNRW/8El1OXF8BLgiA76wYaKZPkbPppUyUV80qKOXU5ZR+nQaI+?= =?us-ascii?Q?KqrJR1vs9VNfIKeq5CdANtnT3cWaC8AjvfGoNcI7RggmHpL7Yqw23jABzsJH?= =?us-ascii?Q?a5BqocmUquHYKmIvRfxoKXtE2Mzf/AGnsEAc1kqQL/ZV3IGwjVhyDyAadmzm?= =?us-ascii?Q?MdIoc5QGWygqgv3TZI42A6VYJ+nf0aB0XTqXFGC9jmnHP7E44mPGprisVkXt?= =?us-ascii?Q?3YdFSe+AY0aivf1F/VwsG6OkL7bK7Tdel3LsC5hlJDLxfH3veTzbUNAO8DrH?= =?us-ascii?Q?D8xdtMPsNMFWE6nPB/ZL8pongoVlX+jGoMNv91atYNpudSEGYvhRB+E8VPsu?= =?us-ascii?Q?Ikb+mMJ6+SebftCZwo665uS6lyZ6GoKmG5vx8yhxMA5bRZRENjkYuDh+ebxE?= =?us-ascii?Q?GIGqi5SkpYuRlYvQBZVa5144Ga8fQnQi4RwYZeUT9zQ2Hn3lm/EKf+74ZI2b?= =?us-ascii?Q?HDqonC1hNMoPJ6+ASd9IZDltsMLYIJVmaA29HCLaPiH4k33vEaOeI7+V2Tgr?= =?us-ascii?Q?jIEz8oaapRRNbJZ674JXAmpndmDhIh9rtrP7RLDOXvuEqlG0wM07SrilzQb2?= =?us-ascii?Q?kQZe4p6NiHxw0hkPi9KTI9YVi+uHDlsujpW1KiP/oVvNwlLyR90FNSEY0Qxt?= =?us-ascii?Q?8zpYGrHtL/CIZDeueeitz+Xf7d2/6fowa5yloWRMgWITGRt/7ihyx7aYpCjc?= =?us-ascii?Q?Q7Z18nVx4UNU1/umJJTvbhCMOpu48EegLUCEfMtgqjwY+BginO8lrnjn3dFz?= =?us-ascii?Q?UiiZPzVCQMiNq9ie4Ishj+jwEhSKQMRXTaTig6iRezOm+hW/nBvNG+PdOZY/?= =?us-ascii?Q?jUXD9Y0rpNI01yJv04r7IeP6J37tJ1FdnGJ6uY9Z8TnQeaV+4qYzcu/?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09730BD177
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(376002)(346002)(54014002)(199004)(189003)(53434003)(53754006)(6916009)(486006)(476003)(4326008)(446003)(236005)(11346002)(53936002)(9686003)(186003)(105586002)(71190400001)(54896002)(6306002)(55016002)(106356001)(606006)(790700001)(316002)(2501003)(6116002)(52536013)(3846002)(33656002)(71200400001)(6346003)(26005)(66066001)(7696005)(25786009)(5660300002)(99286004)(2906002)(229853002)(6506007)(74316002)(5640700003)(2351001)(102836004)(81166006)(76176011)(8676002)(6246003)(450100002)(14444005)(7736002)(256004)(6436002)(97736004)(966005)(14454004)(8936002)(478600001)(86362001)(1730700003)(81156014)(68736007)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB4104; H:BYAPR06MB4325.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: vlKcr6wOHP/MSUAbqOyV43BUNaYefIJm9QqtWWVPAprLXt2EkHM5KdIgbQ6AIzJFWGVxNxbqWDHu/fv6Qp407IiMW22qmPccToUJLuR5EtAmH+dhbm3AqlxjlYVEVKNbVc/wiA/rrjTC3APdC7+uSu17gnoMjVm5bJfprm+L96p7U3mtx/aexl58Zbfb9yuOg1uMfXyYpMC9Tb6qAKXixGU4YmCNmUZrp67oAqLwyL7amDVcpBNBqFjm4LinvPZ4iwbrIz0AW+bOPiKPYlyR4qzqmcJme0I0rfH4Ktqfppo5+9kuaxloc8NPutgbwygxxCTwt9fHEUvFh/uxrtv0yU/s7Mx04x/jRSpHoZz/InsbLiLftPcpr3l9zK/OfznHAW4YChrqM9Cv4Wp/7uQdzPMDgLbr6EKXLSr8GKR7NDY=
Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325E9819172843CCDF5F6F2C4480BYAPR06MB4325namp_"
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8ce5817c-e007-4719-a772-08d6a66eee39
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 22:14:29.1402 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4104
Archived-At: 
Subject: Re: [Detnet] IETF 104 Prague - DetNet Meeting Slot Requests
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Mar 2019 22:14:37 -0000

--_000_BYAPR06MB4325E9819172843CCDF5F6F2C4480BYAPR06MB4325namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All, just a reminder that I will be collating the DetNet meeting slot re=
quests tonight, so if you have a slot request and haven't already sent it, =
please send it to the detnet-chairs alias by 6pm tonight California time.
Thanks,
Ethan (as DetNet Secretary).

From: Grossman, Ethan A.
Sent: Saturday, March 02, 2019 8:43 PM
To: detnet@ietf.org
Cc: detnet-chairs@ietf.org
Subject: IETF 104 Prague - DetNet Meeting Slot Requests

Hi All,

The IETF 104 Prague agenda has been posted:

https://datatracker.ietf.org/meeting/104/agenda/

We're scheduled to meet:
Wednesday, March 27, 2019 (CET) (+01)
9:00-11:00  Wednesday Morning session I, in Congress Hall 1

Please send any slot requests to the chairs email alias (see above) no late=
r than Monday March 11, 5pm Pacific Daylight Time (-07).  Please include dr=
aft names(s), presenter and desired slot length.  Please keep in mind that =
priority for presentation slots is given to WG drafts and other drafts/topi=
cs discussed on the mailing list.

The cutoff date for draft submissions is also Monday March 11th, see https:=
//datatracker.ietf.org/meeting/important-dates/

See you in Prague!
Ethan (as DetNet WG Secretary).


--_000_BYAPR06MB4325E9819172843CCDF5F6F2C4480BYAPR06MB4325namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All, just a reminder that I will be collating the=
 DetNet meeting slot requests tonight, so if you have a slot request and ha=
ven’t already sent it, please send it to the detnet-chairs alias by 6=
pm tonight California time.



Thanks,


Ethan (as DetNet Secretary). 


 






From: Grossman, Ethan A. 

Sent: Saturday, March 02, 2019 8:43 PM

To: detnet@ietf.org

Cc: detnet-chairs@ietf.org

Subject: IETF 104 Prague - DetNet Meeting Slot Requests





 


Hi All,


 


The IETF 104 Prague agenda has =
been posted:


 


https://datatracker.ietf.org/meeting/104/agen=
da/


 


We're scheduled to meet:=



Wednesday, March 27, 2019 (CET)=
 (+01)


9:00-11:00  Wednesday Morn=
ing session I, in Congress Hall 1


 


Please send any slot requests t=
o the chairs email alias (see above) no later than Monday March 11, 5p=
m Pacific Daylight Time (-07).  Please include draft
 names(s), presenter and desired slot length.  Please keep in min=
d that priority for presentation slots is given to WG drafts and other=
 drafts/topics discussed on the mailing list.


 


The cutoff date for draft submi=
ssions is also Monday March 11th, see https://datatra=
cker.ietf.org/meeting/important-dates/


 


See you in Prague!


Ethan (as DetNet WG Secretary).=



 






--_000_BYAPR06MB4325E9819172843CCDF5F6F2C4480BYAPR06MB4325namp_--


From nobody Fri Mar 15 04:24:20 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 0FADD131227 for ; Fri, 15 Mar 2019 04:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mAunwPZlVhVf for ; Fri, 15 Mar 2019 04:24:16 -0700 (PDT)
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 99E15127918 for ; Fri, 15 Mar 2019 04:24:16 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id B222114052D for ; Fri, 15 Mar 2019 05:24:12 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 4kwbh7iRHD8Rp4kwbhU2pf; Fri, 15 Mar 2019 05:24:09 -0600
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:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To: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=JtaEJIH160FLHfssJmszdW7vXx54GVcmrUvKUC2P8bA=; b=1RksRwDfApSKkXauUGOdYe/BuO jA7Usy5Qv4x8S+m2P7WCfWenpkxOpU0WuflOZJXmzN3jR/XmyUuXfsCBs86/XZjYE4lXU4BR1MVwa TQR52J+l5wcZN3Nd9Uc8GYUUO;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:45554 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h4kwb-001a9S-EG; Fri, 15 Mar 2019 05:24:09 -0600
To: DetNet WG 
Cc: DetNet Chairs 
From: Lou Berger 
Message-ID: 
Date: Fri, 15 Mar 2019 07:24:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1h4kwb-001a9S-EG
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]:45554
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [Detnet] Draft IETF 104 agenda available
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, 15 Mar 2019 11:24:18 -0000

Hi,

     We've uploaded a draft agenda -- 
https://datatracker.ietf.org/meeting/104/materials/agenda-104-detnet

Please send slides to detnet-chairs@ietf.org by the end of the day 
Sunday (any timezone) March 24 so that the slides can be uploaded in 
time for others to review prior to the meeting.

Please take a look and let us know if we missed anything.

The meeting details are:

Wednesday, March 27, 2019 (CET) (+01)
9:00-11:00  Wednesday Morning session I
Congress Hall 1
Slides: https://datatracker.ietf.org/meeting/104/session/detnet
Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-104-detnet
Meetecho: http://www.meetecho.com/ietf104/detnet/
Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1043.m3u
Jabber:    xmpp:detnet@jabber.ietf.org?join

Thank you!

Lou, Janos and Ethan



From nobody Mon Mar 18 17:15:12 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 13346130E66; Mon, 18 Mar 2019 17:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEQV8L9Bz4BA; Mon, 18 Mar 2019 17:15:08 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710096.outbound.protection.outlook.com [40.107.71.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC92130DC2; Mon, 18 Mar 2019 17:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xWnKJUp1ohuYFVjCGeQrlUDc7JkVYfngqEN3Xs4Vv3o=; b=aqq/9mgKvfPO32lAxM57gwP/YypDABHXGO75HLAXevR+5uxm5UOk552S6NOR44/4T04aLj5YTQWG6SV6X2NDPvUD86JgcDu9MiMAwZ/voHXgu7r91BOW0mEJ9vCx9o2oKpltLk4Mh5pzwIUhdadv05SiiJ3m2apVjcj+XT10p5A=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB4261.namprd06.prod.outlook.com (52.135.238.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Tue, 19 Mar 2019 00:14:57 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500%6]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 00:14:57 +0000
From: "Grossman, Ethan A." 
To: DetNet WG 
CC: "detnet-chairs@ietf.org" 
Thread-Topic: Draft IETF 104 agenda available
Thread-Index: AQHU2yGiCUkIrVhtvUaN+QVIyaDluqYSB6DQ
Date: Tue, 19 Mar 2019 00:14:57 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcZWFncm9zXGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctOWE2YWUxMjQtNDlkNC0xMWU5LWFlM2MtYWNiYzMyN2E1MWM2XGFtZS10ZXN0XDlhNmFlMTI1LTQ5ZDQtMTFlOS1hZTNjLWFjYmMzMjdhNTFjNmJvZHkudHh0IiBzej0iMTM3OSIgdD0iMTMxOTc0MjQ5MTAwMjIxNTA5IiBoPSJCSUxNWWxsTWswWGFWTGs2aTFYdkZ0MFh3elE9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; 
x-originating-ip: [8.39.141.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a2962d1b-53f0-4743-264a-08d6abffebb5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB4261; 
x-ms-traffictypediagnostic: BYAPR06MB4261:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(376002)(346002)(396003)(13464003)(199004)(53754006)(189003)(3846002)(68736007)(33656002)(316002)(8936002)(97736004)(8676002)(81166006)(81156014)(2906002)(106356001)(6116002)(6916009)(256004)(7736002)(74316002)(478600001)(105586002)(305945005)(5660300002)(4326008)(450100002)(71190400001)(229853002)(71200400001)(14454004)(966005)(6436002)(6306002)(486006)(53936002)(86362001)(52536014)(6506007)(186003)(102836004)(99286004)(53546011)(66066001)(26005)(76176011)(6246003)(55016002)(476003)(446003)(25786009)(7696005)(9686003)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB4261; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: c6sIXONTRfO8U7mQOw8MX6JhBiIL0Rg3FCqTDqxVSpCVhyptjhRsYz+DkPAsILOWJfNR4WKaPNmCSrbfhJYNiPaSaUYSA5BM15Gogx1JwWHHZMuA+EmabTHvCn0213VqUPvflrpyEGNGTt1cbOvOM3VQ9nBSl5a+hId0AOcTxUW4SuznGEYMjTjm87zNldp/rx+rvoPHSP2FfVzpcD/frqKanW7AiLbNeaKyhmEnSra8jK7JKeiGc+6feXddC/9L7juC0qesZErudTJO+ffG216CmkEPELZfU4/ROpxarGLlIsqcLdxfqtEP1LvI5JxZsWmY0AtXFAK4NpbdlNQ3cCby32RVgMb4bGzPBoUI6x4qzA6TG7kjG3WddluHJgbqBage+jAtjU/faHVhiFcuTRqOql+2HaIh39dWHzHZK2E=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2962d1b-53f0-4743-264a-08d6abffebb5
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 00:14:57.6900 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4261
Archived-At: 
Subject: Re: [Detnet] Draft IETF 104 agenda available
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, 19 Mar 2019 00:15:11 -0000

SGkgQWxsLA0KQUZBSUsgd2UgZG9uJ3QgaGF2ZSBhbnkgcmVtb3RlIHByZXNlbnRhdGlvbnMsIGJ1
dCBpZiB5b3UgYXJlIHBsYW5uaW5nIHRvIHByZXNlbnQgcmVtb3RlbHksIHBsZWFzZSBlbWFpbCB0
aGUgZGV0bmV0LWNoYWlycyBhbGlhcyB0byBsZXQgdXMga25vdyBiZWZvcmUgTWFyY2ggMjMgc28g
dGhhdCB3ZSBjYW4gcmVnaXN0ZXIgeW91IGEgdGltZSBzbG90IHdpdGggTWVldGVjaG8uIA0KVGhh
bmtzLA0KRXRoYW4gKGFzIERldE5ldCBTZWNyZXRhcnkpLiANCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0KU2VudDogRnJp
ZGF5LCBNYXJjaCAxNSwgMjAxOSA0OjI0IEFNDQpUbzogRGV0TmV0IFdHIDxkZXRuZXRAaWV0Zi5v
cmc+DQpDYzogRGV0TmV0IENoYWlycyA8ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6
IERyYWZ0IElFVEYgMTA0IGFnZW5kYSBhdmFpbGFibGUNCg0KSGksDQoNCiDCoMKgwqAgV2UndmUg
dXBsb2FkZWQgYSBkcmFmdCBhZ2VuZGEgLS0NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
bWVldGluZy8xMDQvbWF0ZXJpYWxzL2FnZW5kYS0xMDQtZGV0bmV0DQoNClBsZWFzZSBzZW5kIHNs
aWRlcyB0byBkZXRuZXQtY2hhaXJzQGlldGYub3JnIGJ5IHRoZSBlbmQgb2YgdGhlIGRheSBTdW5k
YXkgKGFueSB0aW1lem9uZSkgTWFyY2ggMjQgc28gdGhhdCB0aGUgc2xpZGVzIGNhbiBiZSB1cGxv
YWRlZCBpbiB0aW1lIGZvciBvdGhlcnMgdG8gcmV2aWV3IHByaW9yIHRvIHRoZSBtZWV0aW5nLg0K
DQpQbGVhc2UgdGFrZSBhIGxvb2sgYW5kIGxldCB1cyBrbm93IGlmIHdlIG1pc3NlZCBhbnl0aGlu
Zy4NCg0KVGhlIG1lZXRpbmcgZGV0YWlscyBhcmU6DQoNCldlZG5lc2RheSwgTWFyY2ggMjcsIDIw
MTkgKENFVCkgKCswMSkNCjk6MDAtMTE6MDDCoCBXZWRuZXNkYXkgTW9ybmluZyBzZXNzaW9uIEkN
CkNvbmdyZXNzIEhhbGwgMQ0KU2xpZGVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l
ZXRpbmcvMTA0L3Nlc3Npb24vZGV0bmV0DQpFdGhlcnBhZDogaHR0cDovL2V0aGVycGFkLnRvb2xz
LmlldGYub3JnL3Avbm90ZXMtaWV0Zi0xMDQtZGV0bmV0DQpNZWV0ZWNobzogaHR0cDovL3d3dy5t
ZWV0ZWNoby5jb20vaWV0ZjEwNC9kZXRuZXQvDQpBdWRpbyBzdHJlYW06IGh0dHA6Ly9tcDMuY29u
Zi5tZWV0ZWNoby5jb20vaWV0Zi9pZXRmMTA0My5tM3UNCkphYmJlcjrCoMKgwqAgeG1wcDpkZXRu
ZXRAamFiYmVyLmlldGYub3JnP2pvaW4NCg0KVGhhbmsgeW91IQ0KDQpMb3UsIEphbm9zIGFuZCBF
dGhhbg0KDQoNCg==


From nobody Mon Mar 25 04:52: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 455E71203E3; Mon, 25 Mar 2019 04:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaNUeVR7S7ZU; Mon, 25 Mar 2019 04:52:11 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680110.outbound.protection.outlook.com [40.107.68.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E11120482; Mon, 25 Mar 2019 04:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i+z4gP+KO9Lnn9uFIDRet+lMXX8ARW+73g+7xCcbdiQ=; b=UI4euiyQWy4lqHdf5io71vVrpdGh4OxWuXUC+s+0ZkwrgKqzjdhf0b4NXsK0oYBDvry/JfRDpQanF23dhPZutUujY11mSQ9uDIs45uQAwRhpqeXlszaBcHPAbZT6RiNEy27yfwdu/jNcps/NRQxdNqtI1UiY1LAHeQ3OT9NmeAU=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB5078.namprd06.prod.outlook.com (20.177.186.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Mon, 25 Mar 2019 11:52:02 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::b89f:9d03:a203:c6a4]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::b89f:9d03:a203:c6a4%2]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 11:52:02 +0000
From: "Grossman, Ethan A." 
To: DetNet WG 
CC: DetNet Chairs 
Thread-Topic: Draft IETF 104 agenda available - Slides!
Thread-Index: AdTi/2ntWjdxpQ0yQqqpnOx7TY22Iw==
Date: Mon, 25 Mar 2019 11:52:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcZWFncm9zXGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctZGY5NjMxZjktNGVmMi0xMWU5LTg0NzgtYWNiYzMyN2E1MWM2XGFtZS10ZXN0XGRmOTYzMWZiLTRlZjItMTFlOS04NDc4LWFjYmMzMjdhNTFjNmJvZHkudHh0IiBzej0iMTI1MyIgdD0iMTMxOTc5ODc2NjYxOTI1MzA1IiBoPSIyN0t4SUNwOE15ZnFpVUhPUnJGL0t1WWtlWU09IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; 
x-originating-ip: [31.133.147.206]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b12e1272-ced5-4360-64be-08d6b1184bcf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB5078; 
x-ms-traffictypediagnostic: BYAPR06MB5078:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(376002)(366004)(39850400004)(199004)(189003)(13464003)(6506007)(14444005)(450100002)(256004)(7736002)(6246003)(102836004)(53546011)(3846002)(25786009)(6116002)(53936002)(86362001)(186003)(33656002)(26005)(8936002)(6436002)(229853002)(5660300002)(81166006)(81156014)(8676002)(55016002)(9686003)(6306002)(14454004)(66066001)(966005)(478600001)(305945005)(74316002)(7696005)(99286004)(71200400001)(71190400001)(2906002)(68736007)(486006)(52536014)(316002)(4326008)(6916009)(105586002)(97736004)(476003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB5078; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sMERO8PW0Bp0vsdTanrxIVIrSOQfs9uYw8AFliP4MH60h+Vcqv6oJqSaGlSjFe1CsGkIGh8b7szTOPTRrIGeUGky6yNI2LmWA5LcOxpKIv3CBSylCLZrwV2pJHFFE2PL4f8YBPyNxKNTG7zEdiSG/R+04qqV7tBMYyMj1HzNyMzXdOEomjxyDL7W4D6rnPTnuOq3qwB3e55nDEnTdI0EnMljBCPiSbG6ii1ABNAVuJF+zZvGFpe2Gjn49Rvvio43BLD8ZDAmjtGRrWkPSNCTU5SGJ4/BW1239Bm9pWslGC6Rb61zrVcPwQflzHZrm6NrNd3fjMySAaiXwJSq5q0SyR67vvzRHLq+ayyZ7OHq0tYgeNjcRxd5wWDT7iBNVdNFHKkumQgaLSAOhjGszRwPi2ezHL9hTHcuNUkwCbpjAWw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b12e1272-ced5-4360-64be-08d6b1184bcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 11:52:02.7117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5078
Archived-At: 
Subject: Re: [Detnet] Draft IETF 104 agenda available - Slides!
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, 25 Mar 2019 11:52:15 -0000

UmVtaW5kZXIgLSBJZiB5b3UgYXJlIHByZXNlbnRpbmcgYXQgdGhlIERldE5ldCBzZXNzaW9uLCBw
bGVhc2Ugc2VuZCB5b3VyIHNsaWRlIGRlY2sgdG8gdGhlIGRldG5ldC1jaGFpcnMgYWxpYXMgQVNB
UCEgDQpFdGhhbi4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVy
Z2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiANClNlbnQ6IEZyaWRheSwgTWFyY2ggMTUsIDIwMTkgMTI6
MjQgUE0NClRvOiBEZXROZXQgV0cgPGRldG5ldEBpZXRmLm9yZz4NCkNjOiBEZXROZXQgQ2hhaXJz
IDxkZXRuZXQtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogRHJhZnQgSUVURiAxMDQgYWdlbmRh
IGF2YWlsYWJsZQ0KDQpIaSwNCg0KIMKgwqDCoCBXZSd2ZSB1cGxvYWRlZCBhIGRyYWZ0IGFnZW5k
YSAtLQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9tYXRlcmlhbHMv
YWdlbmRhLTEwNC1kZXRuZXQNCg0KUGxlYXNlIHNlbmQgc2xpZGVzIHRvIGRldG5ldC1jaGFpcnNA
aWV0Zi5vcmcgYnkgdGhlIGVuZCBvZiB0aGUgZGF5IFN1bmRheSAoYW55IHRpbWV6b25lKSBNYXJj
aCAyNCBzbyB0aGF0IHRoZSBzbGlkZXMgY2FuIGJlIHVwbG9hZGVkIGluIHRpbWUgZm9yIG90aGVy
cyB0byByZXZpZXcgcHJpb3IgdG8gdGhlIG1lZXRpbmcuDQoNClBsZWFzZSB0YWtlIGEgbG9vayBh
bmQgbGV0IHVzIGtub3cgaWYgd2UgbWlzc2VkIGFueXRoaW5nLg0KDQpUaGUgbWVldGluZyBkZXRh
aWxzIGFyZToNCg0KV2VkbmVzZGF5LCBNYXJjaCAyNywgMjAxOSAoQ0VUKSAoKzAxKQ0KOTowMC0x
MTowMMKgIFdlZG5lc2RheSBNb3JuaW5nIHNlc3Npb24gSQ0KQ29uZ3Jlc3MgSGFsbCAxDQpTbGlk
ZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvc2Vzc2lvbi9kZXRu
ZXQNCkV0aGVycGFkOiBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rlcy1pZXRm
LTEwNC1kZXRuZXQNCk1lZXRlY2hvOiBodHRwOi8vd3d3Lm1lZXRlY2hvLmNvbS9pZXRmMTA0L2Rl
dG5ldC8NCkF1ZGlvIHN0cmVhbTogaHR0cDovL21wMy5jb25mLm1lZXRlY2hvLmNvbS9pZXRmL2ll
dGYxMDQzLm0zdQ0KSmFiYmVyOsKgwqDCoCB4bXBwOmRldG5ldEBqYWJiZXIuaWV0Zi5vcmc/am9p
bg0KDQpUaGFuayB5b3UhDQoNCkxvdSwgSmFub3MgYW5kIEV0aGFuDQoNCg0K


From nobody Mon Mar 25 09:17: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 9421C1204BF for ; Mon, 25 Mar 2019 09:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbNZOZfVyhc8 for ; Mon, 25 Mar 2019 09:16:53 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96A5120412 for ; Mon, 25 Mar 2019 09:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553530610; x=1556122610; 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=NLSo9Z8BSOcvI1e+Q8fGo4nLMdfixLOhGgzKTH7C94Q=; b=V/HW7bxQPl5Xgr6CQBaFu//kXzjw9v9z3N3yt74or06rlQAWMV+lOgaflyDOtpNs h/WrhJgSQ17zrb0cVL9fR72BV5QXTZ3BUOmPQfKA20wKECT9avUg2SLLzY2k1npz 8S8+ksQTfM14KnjscqSCFTwAhMka9mV/ZBw58jIa5IA=;
X-AuditID: c1b4fb3a-02fff70000001645-ad-5c98fef2bcc0
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.62.05701.2FEF89C5; Mon, 25 Mar 2019 17:16:50 +0100 (CET)
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:16:50 +0100
Received: from [100.94.53.247] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.187) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 17:16:49 +0100
To: Alissa Cooper 
CC: Lou Berger , ,  , The IESG , 
References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in>  
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <0f7e2d9a-bf74-b5ea-6898-29ad2129a0c0@ericsson.com>
Date: Mon, 25 Mar 2019 17:16:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------67EBBAAC3F9926E7F2F29495"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbG9WPfTvxkxBps/yFpMP/OX0eJa/w8W i9+fZrNYfPg2k8Vixp+JzBYdzW9ZHNg8vjx5yeSxZMlPJo8Pm5rZApijuGxSUnMyy1KL9O0S uDL6t+1nLVi6hbGib8MvlgbGe9VdjJwcEgImElO3z2brYuTiEBI4wijx9OxjFpCEkMA3Rolp n1khbKDE1N5wEFtYoECi/8JyZhBbREBV4uqxH2DNzAJTGSUedN9nhZg0i0miYeEHNpAqNgF7 ibuXNoB18ALZd26/AtvAAtR9+ec+JhBbVCBW4tOVxVA1ghInZz4Bq+EUcJDYs+Mv2BXMAmES 7/7+ZYOwxSVuPZnPBHGdmsSntw/ZJzAKzkLSPgtJyywkLbMYOYBse4kHW8sgwvISzVtnM0PY +hLX79xnRRZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwig5u+W21g/Hgc8dDjAIc jEo8vEc+zIgRYk0sK67MPcQowcGsJML7RBQoxJuSWFmVWpQfX1Sak1p8iFGag0VJnPePkGCM kEB6YklqdmpqQWoRTJaJg1OqgbGiKSxjXs+cS2y9Scc2ffqjWWJ32uZF3OXWlqyTj5o+J/5d Pe//yyV/+7fohEun8ahahLi4z8ws80jJC8isiYwNev1SveOEbGCCgoLKokMHjv4RfXevfYui UTYnA/9HU+YEheYr7AlFBY/cv9jy+L6KNLDx0Z80Ta3jtdU6h59e24T/KT34qcRSnJFoqMVc VJwIAKKonOGeAgAA
Archived-At: 
Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 16:17:02 -0000

--------------67EBBAAC3F9926E7F2F29495
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alissa,

We believe that we have addressed your comments in the most recent 
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear 
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you 
would like to discuss.

Regards,
Janos


On 2/26/2019 2:20 PM, Jnos Farkas wrote:
> Hi Alissa,
>
> Thank you for your review!
>
> We can replace
> "DetNet is provides a Quality of Service (QoS), and as such, does not
>  directly raise any new privacy considerations."
> with
> "DetNet provides a Quality of Service (QoS), and as such, is not 
> expected to
>  directly raise any new privacy considerations."
>
> I'm not sure what "references to new flow IDs and OAM tags should be 
> removed"?
>
> Could you point to the text that should be changed?
>
> Thank you!
> Janos
>
>
> On 2/20/2019 4:39 PM, Lou Berger wrote:
>>
>>
>> On 2/20/2019 10:25 AM, Alissa Cooper wrote:
>>>
>>>
>>>> On Feb 20, 2019, at 7:17 AM, Lou Berger >>> > wrote:
>>>>
>>>> Hi Alissa,
>>>>
>>>> Thanks for the comments - see below.
>>>>
>>>> On 2/20/2019 9:54 AM, Alissa Cooper wrote:
>>>>> Alissa Cooper has entered the following ballot position for
>>>>> draft-ietf-detnet-architecture-11: Discuss
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut 
>>>>> this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to 
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> = Section 6 =
>>>>>
>>>>> "DetNet is provides a Quality of Service (QoS), and as such, does not
>>>>> directly raise any new privacy considerations."
>>>>>
>>>>> This seems like a false statement given the possibility that 
>>>>> DetNet may require
>>>>> novel flow IDs and OAM tags that create additional identification and
>>>>> correlation risk beyond existing fields used to support QoS today.
>>>>
>>>> Based on the other work in the WG, I think "is not expected" is 
>>>> more accurate than "does not". This is based on the WG solutions 
>>>> for the DetNet data plane using existing IP (v4 or 6) headers or 
>>>> MPLS labels for flow identification.
>>>
>>> If that is the case then the references to new flow IDs and OAM tags 
>>> should be removed from the architecture.
>>
>> sounds reasonable. Can you point to the specific offending text?
>>
>> Thanks,
>>
>> Lou
>>
>>>
>>>>
>>>> Would changing to "is not expected" address your concern?
>>>
>>> Combined with the above removals, that would work for me.
>>>
>>> Thanks,
>>> Alissa
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet
>


--------------67EBBAAC3F9926E7F2F29495
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Alissa,

    

    We believe that we have addressed your comments in the most recent
    revision:
    https://tools.ietf.org/html/draft-ietf-detnet-architecture-12.
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

    

    Please let us know what else you would like to see done before you
    clear your DISCUSS.

    

    I/we would be happy to meet with you this week if there is anything
    you would like to discuss.

    

    Regards,

    Janos

    

    

    
On 2/26/2019 2:20 PM, Jnos Farkas
      wrote:

    

    

      
      Hi Alissa,

      

      Thank you for your review!

      

      We can replace 

      "DetNet is provides a Quality of Service (QoS), and as such, does
      not

       directly raise any new privacy considerations."

      with

      "DetNet provides a Quality of Service (QoS), and as such, is not
      expected to

       directly raise any new privacy considerations."

      

      I'm not sure what "references to new flow IDs and OAM tags should
      be removed"?

      

      Could you point to the text that should be changed?

      

      Thank you!

      Janos

      

      

      
On 2/20/2019 4:39 PM, Lou Berger
        wrote:

      

      

        


        

        
On 2/20/2019 10:25 AM, Alissa
          Cooper wrote:

        

        
 

          


            

              
On Feb 20, 2019, at 7:17 AM, Lou Berger <lberger@labn.net> wrote:

              

              
Hi Alissa,

                

                Thanks for
                  the comments - see below.

                

                On
                  2/20/2019 9:54 AM, Alissa Cooper wrote:

                
Alissa Cooper has entered the
                  following ballot position for

                  draft-ietf-detnet-architecture-11: Discuss

                  

                  When responding, please keep the subject line intact
                  and reply to all

                  email addresses included in the To and CC lines. (Feel
                  free to cut this

                  introductory paragraph, however.)

                  

                  

                  Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

                  for more information about IESG DISCUSS and COMMENT
                  positions.

                  

                  

                  The document, along with other ballot positions, can
                  be found here:

                  https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/

                  

                  

                  

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

                  DISCUSS:

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

                  

                  = Section 6 =

                  

                  "DetNet is provides a Quality of Service (QoS), and as
                  such, does not

                  directly raise any new privacy considerations."

                  

                  This seems like a false statement given the
                  possibility that DetNet may require

                  novel flow IDs and OAM tags that create additional
                  identification and

                  correlation risk beyond existing fields used to
                  support QoS today.

                

                

                Based on
                  the other work in the WG, I think "is not expected" is
                  more accurate than "does not". This is based on the WG
                  solutions for the DetNet data plane using existing IP
                  (v4 or 6) headers or MPLS labels for flow
                  identification.

              

            

            


            

            
If that is the case then the references to new flow IDs
              and OAM tags should be removed from the architecture.

          

        

        
sounds reasonable. Can you point to the specific offending
          text?

        
Thanks,

        
Lou

        

        

          


            

              


                Would
                  changing to "is not expected" address your concern?

              

            

            


            

            
Combined with the above removals, that would work for
              me.

            


            

            
Thanks,

            
Alissa

            

            

              


                Thanks,

                

                Lou

            

          

          

          

          

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


        

      

      

    

    

  


--------------67EBBAAC3F9926E7F2F29495--


From nobody Mon Mar 25 09:18: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 0061512040B for ; Mon, 25 Mar 2019 09:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpqcSShtBnH0 for ; Mon, 25 Mar 2019 09:18:07 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DBC120416 for ; Mon, 25 Mar 2019 09:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553530680; x=1556122680; 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=O0USSjkqhCVIKqRzXME3XTqZdSfWoupJYXaIIgcWX/o=; b=T1Fa3FG15YIl8IHEyse0rqZ9L8uHlBkaOUjUKTCjbia9L7qzXkOxWiCN9SEFStf5 Va5OZbSCPnr2vF4YG6bp6Umytt29jfkx5tWHOyYPRlSMUgtaDFcd3IM72Wrgq1Op TXTzgzsLW7JfVEXWyEtj9kgxR6D1oBZA7Cv1cv1hSE4=;
X-AuditID: c1b4fb30-307ff70000007fec-4d-5c98ff38e6fe
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.96.32748.83FF89C5; Mon, 25 Mar 2019 17:18:00 +0100 (CET)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:18:00 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:17:59 +0100
Received: from [100.94.53.247] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 17:17:59 +0100
To: Benjamin Kaduk 
CC: Lou Berger , ,  , The IESG , "detnet-chairs@ietf.org" 
References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com>  <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net>  <20190304032524.GM53396@kduck.mit.edu> 
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <7346abb6-c4bf-4d15-c438-9bfc438e81a8@ericsson.com>
Date: Mon, 25 Mar 2019 17:17:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2J7pa7F/xkxBhvOc1hc6//BYvH702wW iw/fZrJYzPgzkdli+caZTBYdzW9ZHNg8liz5yeTxYVMzm0fTmaPMAcxRXDYpqTmZZalF+nYJ XBm3/n5iKlhXUrHnSj9LA+OUuC5GTg4JAROJnRteMYPYQgJHGCXeLDbrYuQCsr8xSkz5N4UZ zrl/fgc7hANUtfHEF1aQFmGBQokLC6cygtgiAkoSi8+2sIHYzAIbgNp/qEA0nGKWuLerCyzB JmAvcffSBqCxHBy8QPaEaVwgYRYBVYl3e26AzREViJX4dGUx2Em8AoISJ2c+YQGxOQUcJDZO u8UEMd9CYub884wQtrxE89bZzBC2uMStJ/OZIN5Rk3jfcIdxAqPwLCSjZiFpn4WkfRaS9gWM LKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPl4JbfBjsYXz53PMQowMGoxMN74MOMGCHW xLLiytxDjBIczEoivE9EgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5/wgJxggJpCeWpGanphak FsFkmTg4pRoYXa991bDUuq8e9GfS+q50nhj3W2/rFdoOvNnbcoK1n0/eeU14emSgXrT117TZ tzmy2RJdXJb3mM5/eWZrsntA+Jm1V3k7lpkY/NapfhuuoTA3P07f7MSFDU2nHjExNAt8SDCd ISVUtthkutnkRdNupXxOOeg8a/Lf40orzwtpl2Q/fzzvyhIzJZbijERDLeai4kQAS9maJ5IC AAA=
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 16:18:10 -0000

Hi Benjamin,

We believe that we have addressed your comments in the most recent 
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear 
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you 
would like to discuss.

Regards,
Janos


On 3/5/2019 10:40 PM, János Farkas wrote:
> Hi Benjamin,
>
> I'm glad that we are progressing. :-)
> Thank you!
>
> Please see in-line.
>
> On 3/4/2019 4:25 AM, Benjamin Kaduk wrote:
>> Hi János,
>>
>> Thanks for the new text.  These are some great things to be thinking 
>> about,
>> but I'm a little worried that it's just specifying mechanism without
>> describing the motiviations; in fact, it may even be more detailed 
>> than we
>> need for this document.  More inline...
>>
>> On Sat, Mar 02, 2019 at 07:22:15PM +0100, János Farkas wrote:
>>> Hi Benjamin,
>>>
>>> Thank you for your review!
>>>
>>> Focusing on the main point now: Section 5 Security Considerations. We
>>> could consolidate the section to address your comment. Would it be
>>> helpful to replace the section with the following text?:
>>>
>>>
>>> Security considerations for DetNet are described in detail in
>>> [I-D.ietf-detnet-security]. This section considers exclusively security
>>> considerations which are specific to the DetNet Architecture.
>>>
>>> Security aspects which are unique to DetNet are those whose aim is to
>>> secure the specific quality of service aspects of DetNet, which are
>>> primarily to deliver data flows with extremely low packet loss rates 
>>> and
>>> bounded end-to-end delivery latency. A DetNet is implemented using MPLS
>>> and IP (including both v4 and v6) technologies, and thus inherits the
>>> security properties of those technologies at both the control plane and
>>> the data plane.
>>>
>>> Security considerations for DetNet are constrained (compared to, for
>>> example, the open Internet) because DetNet is defined to operate only
>>> within a single administrative domain (see Section 1).  The primary
>>> considerations are to secure the request and control of DetNet
>>> resources, maintain confidentiality of data traversing the DetNet, and
>>> provide uninterrupted availability of the DetNet quality of service.
>> "secure" (verb) can mean many different things in different 
>> contexts.  So
>> when we want to "secure" the request and control of resources, that 
>> would
>> presumably be something like denying unauthorized entities the 
>> ability to
>> use the resources, and probably also to limit the consumption of any
>> given entity.  This probably also means that the ability of resources
>> external to DetNet to disrupt the DetNet resources should be limited in
>> some fashion, but the exact details are still unclear to me.
> "secure is not the right word in this sentence. I suggest to replace 
> it with "provide" to get:
>
>           Security aspects which are unique to DetNet are those whose 
> aim is to
>           provide the specific quality of service aspects of DetNet, 
> which are
>           primarily to deliver data flows with extremely low packet 
> loss rates
>           and bounded end-to-end delivery latency.
>
>
>> Similarly, the "uninterrupted availability" is not without 
>> qualifications:
>> an EMP or nuclear blast may not be something in the threat model that we
>> need to defend against.  But if we just say "uninterrupted 
>> availability",
>> the reader has no way to know that.
> "uninterrupted availability" is not a good phrase here, can be 
> confused with zero loss.
> Suggest to replace "uninterrupted availability" with "the" to get:
>
>           Security considerations for DetNet are constrained (compared 
> to, for
>           example, the open Internet) because DetNet is defined to 
> operate only
>           within a single administrative domain (see Section 1). The 
> primary
>           considerations are to secure the request and control of DetNet
>           resources, maintain confidentiality of data traversing the 
> DetNet,
>           and provide the availability of the DetNet quality of service.
>
>>
>> To be clear, I'm not saying that this introductory text has to 
>> change, but
>> if we keep it, the follow-on paragraphs need to provide the
>> motivation/reasoning that is missing here.
>>
>>> To secure the request and control of DetNet resources, authentication
>>> and authorization must be provided for each device connected to a 
>>> DetNet
>>> domain, most importantly to network controller devices. Control of a
>> We require authn/authz because there is/are some risk(s) that we are 
>> trying to
>> protect against.  What is/are that risk?
>
> What we want to prevent is having unauthorized device placed within a 
> DetNet domain, or attached to the DetNet domain; or unauthorized 
> person accessing DetNet domain. This helps preventing some of the 
> attacks, e.g., man-in-the-middle, diverging the routes of DetNet flows.
>
>>
>>> DetNet network may be centralized or distributed (within a single
>>> administrative domain). In the case of centralized control, precedent
>>> for security considerations as defined for ACTN can be found in 
>>> RFC8453,
>>> Section 9. In the case of a distributed control protocols, DetNet
>>> security is expected to be provided by the security properties of the
>>> protocols in use. In any case, the result must be that manipulation of
>>> administratively configurable parameters is limited to authorized 
>>> entities.
>> Deferring on control protocol security is a fine thing to do.
>>
>>> To maintain confidentiality of data traversing the DetNet, application
>>> flows must be protected through whatever means is provided by the
>>> underlying technology. For example, encryption may be used, such as 
>>> that
>>> provided by IPSec for IP (Layer 3) flows and by MACSec for Ethernet
>>> (Layer 2) flows. DetNet flows are identified on a per-flow basis, which
>> (I wouldn't care whether the "For example" sentence is present or 
>> not; we
>> aren't necessarily obligated to provide it.)
> I think the examples are useful to make it clearer what is meant.
>
>>
>>> may provide attackers with additional information about the data flows
>>> (when compared to networks that do not include per-flow 
>>> identification);
>>> this is an inherent property of DetNet which has security implications
>>> which must be considered when determining if DetNet is a suitable
>>> technology for any given use case. Similar consideration may need to be
>>> given to the use of replicated packet flows, which result in increased
>>> surface for Reconnaissance attacks. In any case, the result must be 
>>> that
>>> the confidentiality of the data is maintained to a degree sufficient 
>>> for
>>> the use cases addressed by the given DetNet implementation.
>> I could consider putting this in a new paragraph.  I'd also consider
>> trimming it down: the key point at this level is that detnet provides 
>> a new
>> type of information on packets that can be used by an attacker in the
>> network looking at metadata.  The specific details of that could be 
>> shunted
>> off to the other document with no real harm.
> OK, make it a new paragraph.
>
> A shorter version:
>
> OLD:
>           DetNet flows are identified on a per-flow basis, which may 
> provide
>           attackers with additional information about the data flows 
> (when
>           compared to networks that do not include per-flow 
> identification);
>           this is an inherent property of DetNet which has security
>           implications which must be considered when determining if 
> DetNet is
>           a suitable technology for any given use case. Similar 
> consideration
>           may need to be given to the use of replicated packet flows, 
> which
>           result in increased surface for Reconnaissance attacks. In 
> any case,
>           the result must be that the confidentiality of the data is
>           maintained to a degree sufficient for the use cases 
> addressed by the
>           given DetNet implementation.
>
> NEW:
>           DetNet flows are identified on a per-flow basis, which may 
> provide
>           attackers with additional information about the data flows 
> (when
>           compared to networks that do not include per-flow 
> identification).
>           This is an inherent property of DetNet which has security
>           implications which should be considered when determining if 
> DetNet is
>           a suitable technology for any given use case.
>
>>
>>> To provide uninterrupted availability of the DetNet quality of service,
>>> provisions must be made against DOS attacks and delay attacks. To
>>> protect against DOS attacks, excess traffic due to malicious or
>>> malfunctioning devices must be prevented or mitigated, for example
>>> through the use of traffic admission control applied at the input of a
>>> DetNet domain, as described in Section 3.2.1.1, and through the fault
>>> mitigation methods described in Section 3.3.2.
>> This is getting closer to the sort of thing I was looking for -- we 
>> need to
>> provide availability *in the face of DOS attacks and delay attacks*.  We
>> could probably say more about where the boundary is between "external"
>> entities that could threaten DOS and "internal" entities that we assume
>> behave properly -- is it the boundary of the DetNet domain, or will we
>> consider the risk of misbehaving/compromised equipment in the domain?
>>
>>> To prevent DetNet packets from being delayed, protection must be
>>> provided against Man-In-The-Middle attacks, for example through use of
>>> authentication and authorization of devices within the DetNet domain.
>> (nit: maybe join this into the previous paragraph, since that 
>> paragraph's
>> topic sentence also mentions delay)
> OK to merge it.
>
>> This is also pretty close to what I hoped for: it implies that we 
>> need to
>> keep the traffic inside our trusted elements (by avoiding the MITM), 
>> since
>> the MITM is untrusted and could introduce delay, but the internal 
>> elements
>> are trusted to not delay.  So this could be "prevent DetNet packets from
>> being delayed by external network entities", which implicitly 
>> disclaims an
>> attempt to protect against a compromised DetNet router.
> I like your proposal.
> to make it clear that external is relative to the DetNet domain, I 
> suggest to have:
> "To prevent DetNet packets from being delayed by an entity external to 
> a DetNet domain, "
>
> Got another comment suggesting not to use "protection" here. With that 
> the suggested new text:
>
>                                                                "To 
> prevent DetNet packets from
>           being delayed by an entity external to a DetNet domain, DetNet
>           technology definition must allow for the mitigation of
>           Man-In-The-Middle attacks, for example through use of
>           authentication and authorization of devices within the 
> DetNet domain."
>
>>
>>> Time synchronization methods are not specified by DetNet, however any
>>> time synchronization method used with DetNet must also be secured, 
>>> using
>>> the security methods available for the given time synchronization
>>> mechanism, for example as described in [RFC7384].
>>> In any case, the result must be that the DetNet is protected from DOS,
>>> delay, and time manipulation attacks to the extent sufficient for the
>>> use cases addressed by the given DetNet implementation.
>> I'd consider rephrasing this more like "Because DetNet mechanisms can 
>> make
>> heavy use of methods that require precise time synchronization, the
>> accuracy, availability, and integrity of time synchronization is of
>> critical importance.  Extensive discussion of this topic can be found in
>> [RFC7384]."  We may not need the rest of the details in this document.
> I like your proposal.
>
> I suggest to replace
>
> OLD:
> "Time synchronization methods are not specified by DetNet, however any
> time synchronization method used with DetNet must also be secured, using
> the security methods available for the given time synchronization
> mechanism, for example as described in [RFC7384]."
>
> with:
>
> NEW:
>           Because DetNet mechanisms or applications that rely on 
> DetNet can
>           make heavy use of methods that require precise time 
> synchronization,
>           the accuracy, availability, and integrity of time 
> synchronization is
>           of critical importance. Extensive discussion of this topic 
> can be
>           found in [RFC7384].
>
> That is, I suggest to add "or applications that rely on DetNet" to the 
> text you proposed.
> I suggest to capture that time synchronization can be important to the 
> application running on an end system. There may be cases when a 
> particular DetNet deployment does not rely on time synchronization, 
> but it is still needed for an application.
>
> Based on your proposal delete:
> "          In any case, the result must be that the DetNet is 
> protected from DOS,
>           delay, and time manipulation attacks to the extent 
> sufficient for the
>           use cases addressed by the given DetNet implementation."
>
>
>>
>>> DetNet use cases are known to have widely divergent security
>>> requirements. The intent of this section is to provide a baseline for
>>> security considerations which are common to all DetNet designs and
>>> implementations, without burdening individual designs with specifics of
>>> security infrastructure which may not be germane to the given use case.
>>> Designers and Implementers of DetNet systems are expected to take use
>>> case specific considerations into account in their DetNet designs and
>>> implementations.
>> This is good.
>>
>> -Benjamin
>>
>
> We've got a few more comments. The main one is to remove "must" from 
> the security section because the use of security mechanisms is a 
> deployment choice, not that of the IETF.
>
> A diff is attached to show the changes described above.
>
> Thank you,
> Janos


From nobody Mon Mar 25 09:19: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 6DE9312040B for ; Mon, 25 Mar 2019 09:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHbGVBU87qC6 for ; Mon, 25 Mar 2019 09:19:01 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625B4120419 for ; Mon, 25 Mar 2019 09:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553530737; x=1556122737; 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=06vCDSx4ykH5+Yt94dxZkPBMG9JTveXBesaUK2600N4=; b=JRozmGozyXfgmEGbshkQWx3Bk/tUWyua2xtiQydmp2DlXeliJMsUEfXucgsxbKlM yl/TnAqio2FgeiphVdtKcCIIiSqU6cWLGfDY532xeax4D5UXYQp/4y3Y4XiMl1NN 9ca47omA2PL+Px8RtXiZhVqvtiPhw26W7t1Ehh+qMIU=;
X-AuditID: c1b4fb3a-017ff70000001645-de-5c98ff715953
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.A2.05701.17FF89C5; Mon, 25 Mar 2019 17:18:57 +0100 (CET)
Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESBMB502.ericsson.se (153.88.183.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:18:57 +0100
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:18:56 +0100
Received: from [100.94.53.247] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.191) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 17:18:56 +0100
To: "Mirja Kuehlewind (IETF)" 
CC: Lou Berger , The IESG , , , 
References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net> <5a998fcf-0572-82f6-8bee-2cac21635117@ericsson.com> <9CC0A271-BBF4-4EDF-8D4F-46038B9D7648@kuehlewind.net> 
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: 
Date: Mon, 25 Mar 2019 17:18:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbG9WLfw/4wYg4Y9GhbX+n+wWPz+NJvF 4sO3mSwWM/5MZLZ4cf0js0VH81sWBzaPJUt+Mnm0fFzI6vFhUzNbAHMUl01Kak5mWWqRvl0C V8b2XV1sBW8aGSs2vT/C3sD4NauLkZNDQsBEYtGh1axdjFwcQgJHGCXmT7rEDuF8Y5Q4sGU+ K0gVmNO6TAauampbLyOIIywwj1FizuJdTCBVIgLGEocnfwebxSwwnVHi/PwXbBDtPcwS23pY QGw2AXuJu5c2MIPYvEB275ZX7CA2i4CqxIo3K8HWiQrESny6shiqRlDi5MwnQL0cHJwCDhIP LjiAhJkFLCRmzj/PCGHLSzRvnc0MYYtL3HoynwlirZrE+4Y7jBMYhWchmTQLSfssJO2zkLQv YGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYMQe3/LbawXjwueMhRgEORiUe3iMfZsQI sSaWFVfmHmKU4GBWEuF9IgoU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzvtHSDBGSCA9sSQ1OzW1 ILUIJsvEwSnVwDhP/uOb9CPq0mUqfxUMu1Ur+ZvStr35cuGI7Oprzw8f/H+j79Ss6+uONUhm Shc2ftp1auux8K2RkfeYXYJvci9JTL2T5HBaMkJqV8i3a3wrued/SMm6kXDijF3cntePA1zz Tt3yXvfe6rW5VsqsrzP2CeX5bl8+/wDP1ysyH/8nStX9vjXbVttSiaU4I9FQi7moOBEAwd9+ /pQCAAA=
Archived-At: 
Subject: Re: [Detnet]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 16:19:07 -0000

Hi Mirja,

We believe that we have addressed your comments in the most recent 
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear 
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you 
would like to discuss.

Regards,
Janos


On 3/5/2019 11:30 AM, János Farkas wrote:
> Thank you Mirja!
> We are implementing the changes in the next revision of the draft.
> Janos
>
> On 3/5/2019 11:28 AM, Mirja Kuehlewind (IETF) wrote:
>> Hi Janos,
>>
>> sorry for my late'ish reply. Your changes look good to me. Thanks!
>>
>> Mirja
>>
>>
>>
>>> Am 26.02.2019 um 13:45 schrieb János Farkas 
>>> :
>>>
>>> Hi Mirja,
>>>
>>> Thank you for your review!
>>>
>>> Please see in-line changes suggested to address your comments.
>>>
>>>
>>> On 2/20/2019 5:24 PM, Lou Berger wrote:
>>>> Hi Mirja,
>>>>
>>>>      See below.
>>>>
>>>> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
>>>>> Hi Lou,
>>>>>
>>>>> I’m happy to see that my concerns seem to be cover. So maybe this 
>>>>> is mostly a point about wording. Please see below.
>>>>>
>>>>>> Am 20.02.2019 um 15:46 schrieb Lou Berger :
>>>>>>
>>>>>> Hi Mirja,
>>>>>>
>>>>>> I'm responding as doc shepherd (and chair). Thank you for your 
>>>>>> comments.  Please see below for specific responses.
>>>>>>
>>>>>> On 2/20/2019 8:05 AM, Mirja Kühlewind wrote:
>>>>>>> Mirja Kühlewind has entered the following ballot position for
>>>>>>> draft-ietf-detnet-architecture-11: Discuss
>>>>>>>
>>>>>>> When responding, please keep the subject line intact and reply 
>>>>>>> to all
>>>>>>> email addresses included in the To and CC lines. (Feel free to 
>>>>>>> cut this
>>>>>>> introductory paragraph, however.)
>>>>>>>
>>>>>>>
>>>>>>> Please refer to 
>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>>
>>>>>>>
>>>>>>> The document, along with other ballot positions, can be found here:
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------- 
>>>>>>>
>>>>>>> DISCUSS:
>>>>>>> ---------------------------------------------------------------------- 
>>>>>>>
>>>>>>>
>>>>>>> Thanks for addressing the tsv-art review comments (and big 
>>>>>>> thanks to Michael
>>>>>>> and David!) and all the work done so far! I think the document 
>>>>>>> is in good shape
>>>>>>> and I only have one minor comment that I would like to see 
>>>>>>> addressed/more
>>>>>>> explicitly spelled out. However, this should be done quickly 
>>>>>>> with potentially
>>>>>>> 2-3 small changes in the draft. See below.
>>>>>> The input from Michael and David certainly led to a much improved 
>>>>>> document.  If you can help the authors with some specific text 
>>>>>> suggestions that would be most helpful.
>>>>>>
>>>>>>
>>>>>>> Given that DetNet traffic is often assumed to be not congestion 
>>>>>>> controlled, it
>>>>>>> is important that there is also some network function that makes 
>>>>>>> sure the
>>>>>>> source traffic stays within the requested bandwidth limit 
>>>>>>> in-order to protect
>>>>>>> non-Detnet traffic. This is to some extended discussed in 
>>>>>>> section 3.3.2 but I
>>>>>>> think it should be more clearly spelled out that this would 
>>>>>>> require a rate
>>>>>>> limiting function at each DetNet source/relay (tunnel ingress). 
>>>>>>> Currently sec
>>>>>>> 3.3.2 says:
>>>>>>>
>>>>>>> "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."
>>>>>>>
>>>>>>> However, maybe this case of limiting non-congestion controlled 
>>>>>>> traffic (in case
>>>>>>> the source in not keeping to the limits on purpose/in order to 
>>>>>>> cheat, because
>>>>>>> it couldn't estimate the needed bandwidth requirement an better, 
>>>>>>> or due to
>>>>>>> timely fluctuations) could be explained more clearing and the 
>>>>>>> respective
>>>>>>> requirement to implement rate limiting could be state separately 
>>>>>>> and more
>>>>>>> strongly...?
>>>>>> Section 3.2.1.1 days:
>>>>>>
>>>>>>     Ensuring adequate buffering requires, in turn, that the 
>>>>>> source, and
>>>>>>     every DetNet node along the path to the destination (or 
>>>>>> nearly every
>>>>>>     node, see Section 4.3.3) be careful to regulate its output to 
>>>>>> not
>>>>>>     exceed the data rate for any DetNet flow, except for brief 
>>>>>> periods
>>>>>>     when making up for interfering traffic.  Any packet sent 
>>>>>> ahead of its
>>>>>>     time potentially adds to the number of buffers required by 
>>>>>> the next
>>>>>>     hop DetNet node and may thus exceed the resources allocated 
>>>>>> for a
>>>>>>     particular DetNet flow.
>>>>>>
>>>>>> Section 3.3.1 also says:
>>>>>>
>>>>>>     Starvation of non-DetNet traffic must be avoided, e.g., by 
>>>>>> traffic
>>>>>>     policing functions (e.g., [RFC2475]).  Thus, the net effect 
>>>>>> of the
>>>>>>     presence of DetNet flows in a network on the non-DetNet flows is
>>>>>>     primarily a reduction in the available bandwidth.
>>>>>>
>>>>>> Is this not sufficient?  If not, can you suggest some additional 
>>>>>> language?
>>>>> My question is mostly if you only need to protect _complete_ 
>>>>> starvation or any over-use by DetNet flows and how you would do 
>>>>> that. If the answer is to rate limit the DetNet flows at ingress 
>>>>> to the allocated bandwidth, that would completely address my 
>>>>> concern. However note that buffer dimensioning and rate limiting 
>>>>> is not the same. Rate limiting is usually a scheduling question, 
>>>>> e.g. using a token bucket scheme or a fixed non-work conserving 
>>>>> scheduler. Therefore it would be nice to add one additional 
>>>>> sentence in section 3.2 that spells that out directly. e.g. 
>>>>> something like:
>>>>>
>>>>> „In order to protect non-DetNet traffic from potentially 
>>>>> misbehaving DetNet-Traffic sources, rate limiting, e.g. using a 
>>>>> token bucket scheme, at each tunnel ingress must be applied.“
>>>>> I’m sure you can adapt the wording to make it more DetNet-like 
>>>>> language and maybe you also want to add another sentence 
>>>>> explaining the problem, please feel free to do so but that’s more 
>>>>> or less what I’m looking for.
>>>> I do agree that we seem to be having a terminology issue here - and 
>>>> that we are on the same page with what should happen.  The 
>>>> terminology I've used/seen in past RFCs has usually used the terms 
>>>> 'shaping' and 'policing' - and these are what we've been using 
>>>> within the WG.  For example, both of these terms are used in 
>>>> RFC2475 but 'rate limiting' is not. Would it work for you for the 
>>>> draft to use/adapt the rest of your language, but keep 'by traffic 
>>>> policing functions (e.g., [RFC2475])' rather than 'rate limiting, 
>>>> e.g. using a token bucket scheme,' ?
>>> We could extend the 2nd paragraph in 3.2.1.1 
>>> (https://tools.ietf.org/html/draft-ietf-detnet-architecture-11#section-3.2.1.1) 
>>> to capture this comment:
>>>
>>> OLD:
>>>              Ensuring adequate buffering requires, in turn, that the 
>>> source, and every DetNet
>>>              node along the path to the destination (or nearly every 
>>> node, see
>>>              ) be careful to regulate its 
>>> output to not exceed the
>>>              data rate for any DetNet flow, except for brief periods 
>>> when making up for
>>>              interfering traffic.  Any packet sent ahead of its time 
>>> potentially adds to the
>>>              number of buffers required by the next hop DetNet node 
>>> and may thus exceed the resources
>>>              allocated for a particular DetNet flow.
>>>
>>> NEW:
>>>
>>>              Ensuring adequate buffering requires, in turn, that the 
>>> source, and every DetNet
>>>              node along the path to the destination (or nearly every 
>>> node, see
>>>              ) be careful to regulate its 
>>> output to not exceed the
>>>              data rate for any DetNet flow, except for brief periods 
>>> when making up for
>>>              interfering traffic.  Any packet sent ahead of its time 
>>> potentially adds to the
>>>              number of buffers required by the next hop DetNet node 
>>> and may thus exceed the resources
>>>              allocated for a particular DetNet flow. Furthermore, 
>>> rate limiting, e.g., using traffic
>>>              policing and shaping functions, e.g., >> target="RFC2475"/>, at the ingress of the
>>>              DetNet domain must be applied. This is needed for 
>>> meeting the requirements of DetNet
>>>              flows as well as for protecting non-DetNet traffic from 
>>> potentially misbehaving DetNet
>>>              traffic sources.
>>>
>>>
>>> Furthermore, replace the two occurrences of "policing" with 
>>> "policing and shaping":
>>>
>>> OLD:
>>>     Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>     policing functions (e.g., [RFC2475]).
>>>
>>> NEW:
>>>     Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>     policing and shaping functions (e.g., [RFC2475]).
>>>
>>>
>>> OLD:
>>>     Examples of such techniques include traffic policing
>>>     functions (e.g., [RFC2475]) and separating flows into per-flow 
>>> rate-
>>>     limited queues.
>>>
>>> NEW:
>>>     Examples of such techniques include traffic policing and shaping
>>>     functions (e.g., [RFC2475]) and separating flows into per-flow 
>>> rate-
>>>     limited queues.
>>>
>>>>
>>>>>>> One related comment on this sentence in Sec 3.1:
>>>>>>>
>>>>>>> "As DetNet provides allocated resources (including provisioned 
>>>>>>> capacity)
>>>>>>>      to DetNet flows the use of transport layer congestion control
>>>>>>>      [RFC2914] by App-flows is explicitly not required."
>>>>>>>
>>>>>>> I guess congestion control should still be a requirement if the 
>>>>>>> App-flow also
>>>>>>> passes not-DetNet-aware segments of the path, e.g. maybe the 
>>>>>>> first hop.
>>>>>> This point is addressed in section 3.3.2
>>>>>>
>>>>>>     Note that the sending of App-flows that do not use transport 
>>>>>> layer
>>>>>>     congestion control per [RFC2914] into a network that is not
>>>>>>     provisioned to handle such DetNet traffic has to be treated as a
>>>>>>     fault and prevented.
>>>>>>
>>>>>>> Usually
>>>>>>> use of congestion control for application limited flows is also 
>>>>>>> not a problem
>>>>>>> if sufficient bandwidth is available. Also note that, as I 
>>>>>>> stated above, the
>>>>>>> important part for not requiring congestion control is actually 
>>>>>>> not only that
>>>>>>> resources are allocated but also that rate limiting is in place 
>>>>>>> to make sure
>>>>>>> resources usage cannot be exceeded above the reserved 
>>>>>>> allocation. Maybe this
>>>>>>> sentence could also be further clarified in the draft...?
>>>>>> Is the above sufficient?  If not, can you suggest some additional 
>>>>>> language?
>>>>> Maybe we can just extend the above statement a bit in order to be 
>>>>> crystal clear about this, e.g.:
>>>>>
>>>>> "As DetNet flow are assumed to be rate-limited and DetNet is 
>>>>> designed to provide sufficient allocated resources (including 
>>>>> provisioned capacity), the use of transport layer congestion 
>>>>> control [RFC2914] for end-to-end DetNet flows is not required, 
>>>>> however, if resources are allocated appropriately, use of 
>>>>> congestion control should not impact transmission negatively.“
>>>> Great!  (I'll leave it to the authors to do the final wording 
>>>> adaptation)
>>> "App-flow" seems to be better than "end-to-end DetNet flow". The 
>>> change with that would be:
>>>
>>> OLD:
>>>     As
>>>     DetNet provides allocated resources (including provisioned 
>>> capacity)
>>>     to DetNet flows the use of transport layer congestion control
>>>     [RFC2914] by App-flows is explicitly not required.
>>>
>>> NEW:
>>>              As
>>>              DetNet flows are assumed to be rate-limited and DetNet 
>>> is designed
>>>              to provide sufficient allocated resources (including 
>>> provisioned
>>>              capacity), the use of transport layer congestion 
>>> control [RFC2914]
>>>              for App-flows is not required; however, if resources 
>>> are allocated
>>>              appropriately, use of congestion control should not impact
>>>              transmission negatively.
>>>
>>>>>>> And then one more small comment that is also related. Sec 
>>>>>>> 3.2.2.2 says:
>>>>>>>
>>>>>>> "If packet replication and elimination is used over paths with
>>>>>>>      resource allocation (Section 3.2.1), ..."
>>>>>>>
>>>>>>> My assumption was that all DetNet traffic is send over 
>>>>>>> pre-allocated
>>>>>>> resources...? If that is not true that has implication on 
>>>>>>> congestion control
>>>>>>> and needs some additional considerations. Can you please confirm 
>>>>>>> that and maybe
>>>>>>> clarify in the draft! Thanks!
>>>>>> The intent was to cover sending over non-pre-allocated paths as a 
>>>>>> fault case, and cover it in section 3.3.2.
>>>>> If that is the case, maybe we can just removed the half-sentence I 
>>>>> cited above?
>>>> WFM!
>>> The sentence after removing the text as you suggest:
>>>
>>> OLD:
>>>     If packet replication and elimination is used over paths with
>>>     resource allocation (Section 3.2.1), and member flows that take
>>>     different-length paths through the network are combined, a merge
>>>     point may require extra buffering to equalize the delays over the
>>>     different paths.
>>>
>>> NEW:
>>>     If member flows that take different-length paths through the
>>>     network are combined, a merge point may require extra buffering
>>>     to equalize the delays over the different paths.
>>>
>>>
>>> Thank you!
>>> Janos
>>>
>>>
>>>> Thank you!
>>>>
>>>>> Thanks!
>>>>> Mirja
>>>>>
>>>>>> In addition to the previously quoted text, the section also says:
>>>>>>
>>>>>>     PRF generated DetNet member flows also need to
>>>>>>     be treated as not using transport layer congestion control 
>>>>>> even if
>>>>>>     the original App-flow supports transport layer congestion 
>>>>>> control
>>>>>>     because PREOF can remove congestion indications at the PEF and
>>>>>>     thereby hide such indications (e.g., drops, ECN markings, 
>>>>>> increased
>>>>>>     latency) from end systems.
>>>>>>
>>>>>> Does this address your concern?
>>>>>>> ---------------------------------------------------------------------- 
>>>>>>>
>>>>>>> COMMENT:
>>>>>>> ---------------------------------------------------------------------- 
>>>>>>>
>>>>>>>
>>>>>>> I agree with Alexey and Benjamin that this document should be 
>>>>>>> informational.
>>>>>>> Informational documents can also have IETF consensus, so that 
>>>>>>> cannot be the
>>>>>>> reason to go for PS. However, this document does not specify a 
>>>>>>> protocol or any
>>>>>>> requirements that are mandatory to implement for 
>>>>>>> interoperability and therefore
>>>>>>> should not be PS.
>>>>>>>
>>>>>> I defer to the IESG and AD on this...
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Lou
>>>>>>
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> detnet@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>
>


From nobody Mon Mar 25 09:20:54 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 3F18B120420 for ; Mon, 25 Mar 2019 09:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.041
X-Spam-Level: 
X-Spam-Status: No, score=-4.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtCkKRemKQRR for ; Mon, 25 Mar 2019 09:20:44 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320BC120412 for ; Mon, 25 Mar 2019 09:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553530836; x=1556122836; 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=9h3gaidmzJIjr6eZV3lZ7gl0h4xda80z5U9TWFXNIaM=; b=TBsiWxeR/huUAlEfMMuwbIUAU64wJc2j/jcHkfsU2Vf4jzGogRU876jD/IRbSb7D gDE39WlW2TnN4WCb9JhBk+MV3oHLGKrAsHap02erbEctFXEnN+XwCRRIuc/dRK80 5W8AkFHoauEvdRp+SbxbELCZVfEYpGKaPqkVKL4jXMo=;
X-AuditID: c1b4fb2d-fc7ff70000002218-4f-5c98ffd4130c
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2D.E5.08728.4DFF89C5; Mon, 25 Mar 2019 17:20:36 +0100 (CET)
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Mar 2019 17:20:36 +0100
Received: from [100.94.53.247] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.187) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 17:20:35 +0100
To: Alvaro Retana 
CC: Lou Berger , The IESG , , , 
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>   <150fb3c5-0f60-8426-0345-a17d9be984b9@ericsson.com>
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <06a42687-5942-2591-4c71-5a5ff5090474@ericsson.com>
Date: Mon, 25 Mar 2019 17:20:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <150fb3c5-0f60-8426-0345-a17d9be984b9@ericsson.com>
Content-Type: multipart/alternative; boundary="------------78FC0D36E29D42531BF03C2A"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbG9VPfK/xkxBidXq1jcOLSByeJa/w8W i9+fZrNYfPg2k8Vixp+JzBYdzW9ZHNg8ds66y+6xZMlPJo8Pm5rZApijuGxSUnMyy1KL9O0S uDLmfj/GWPBsB1PF0ZuvmRsYn9xl7GLk5JAQMJG4dv8pcxcjF4eQwBFGiSUHNrGBJIQEvjFK tO01hLCBEn/ex4HYwgIFEl+PNrCD2CICWhK3d+5kB2lmFpjOKHF+/gs2iEnLmSXO/trDBFLF JmAvcffSBmYQmxfI/np8PpDNwcEioCpx4DFYiahArMSnK4uhSgQlTs58wgJicwo4SOw+tg4s ziwQJtG7+SsLhC0ucevJfCaI49QkPr19yD6BUXAWkvZZSFpmIWmBsC0kZs4/zwhhy0s0b53N DGFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmAcHdzyW3cH4+rXjocY BTgYlXh4T3yYESPEmlhWXJl7iFGCg1lJhPeJKFCINyWxsiq1KD++qDQntfgQozQHi5I47x8h wRghgfTEktTs1NSC1CKYLBMHp1QD4/y7PIkxXTrbND/WsTOwL/vG8D9t28eN7cEs1z5XP31S u+Xji802DHsLFfTPafy7rnRignPT2uMh+6bZnvly5n/KVQke9swVa7JYlQ7NbVyg9j7RQkXs Q4jLcxmG7o/1vUl28i3qXxqks+QkgySuGVyrXZZ7sOrOD5+F91OZDid5eHxJcn+eqcRSnJFo qMVcVJwIAEksKXOfAgAA
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 16:20:49 -0000

--------------78FC0D36E29D42531BF03C2A
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alvaro,

We believe that we have addressed your comments in the most recent 
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear 
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you 
would like to discuss.

Regards,
Janos


On 3/6/2019 6:56 AM, János Farkas wrote:
> Hi Alvaro,
>
> Do the updates we are making the security section resolve your comments:
> https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
>
> The current proposed text:
>
> 5.  Security Considerations
>
>    Security considerations for DetNet are described in detail in
>    [I-D.ietf-detnet-security].  This section considers exclusively
>    security considerations which are specific to the DetNet
>    Architecture.
>
>    Security aspects which are unique to DetNet are those whose aim is to
>    provide the specific quality of service aspects of DetNet, which are
>    primarily to deliver data flows with extremely low packet loss rates
>    and bounded end-to-end delivery latency.  A DetNet may be implemented
>    using MPLS and/or IP (including both v4 and v6) technologies, and
>    thus inherits the security properties of those technologies at both
>    the control plane and the data plane.
>
>    Security considerations for DetNet are constrained (compared to, for
>    example, the open Internet) because DetNet is defined to operate only
>    within a single administrative domain (see Section 1).  The primary
>    considerations are to secure the request and control of DetNet
>    resources, maintain confidentiality of data traversing the DetNet,
>    and provide the availability of the DetNet quality of service.
>
>    To secure the request and control of DetNet resources, authentication
>    and authorization can be used for each device connected to a DetNet
>    domain, most importantly to network controller devices. Control of a
>    DetNet network may be centralized or distributed (within a single
>    administrative domain).  In the case of centralized control,
>    precedent for security considerations as defined for Abstraction and
>    Control of Traffic Engineered Networks (ACTN) can be found in
>    [RFC8453], Section 9.  In the case of a distributed control
>    protocols, DetNet security is expected to be provided by the security
>    properties of the protocols in use.  In any case, the result is that
>    manipulation of administratively configurable parameters is limited
>    to authorized entities.
>
>    To maintain confidentiality of data traversing the DetNet,
>    application flows can be protected through whatever means is provided
>    by the underlying technology.  For example, encryption may be used,
>    such as that provided by IPSec [RFC4301] for IP (Layer 3) flows and
>    by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.
>
>    DetNet flows are identified on a per-flow basis, which may provide
>    attackers with additional information about the data flows (when
>    compared to networks that do not include per-flow identification).
>    This is an inherent property of DetNet which has security
>    implications which should be considered when determining if DetNet is
>    a suitable technology for any given use case.
>
>    To provide uninterrupted availability of the DetNet quality of
>    service, provisions can be made against DOS attacks and delay
>    attacks.  To protect against DOS attacks, excess traffic due to
>    malicious or malfunctioning devices can be prevented or mitigated,
>    for example through the use of traffic admission control applied at
>    the input of a DetNet domain, as described in Section 3.2.1, and
>    through the fault mitigation methods described in Section 3.3.2.  To
>    prevent DetNet packets from being delayed by an entity external to a
>    DetNet domain, DetNet technology definition can allow for the
>    mitigation of Man-In-The-Middle attacks, for example through use of
>    authentication and authorization of devices within the DetNet domain.
>
>    Because DetNet mechanisms or applications that rely on DetNet can
>    make heavy use of methods that require precise time synchronization,
>    the accuracy, availability, and integrity of time synchronization is
>    of critical importance.  Extensive discussion of this topic can be
>    found in [RFC7384].
>
>    DetNet use cases are known to have widely divergent security
>    requirements.  The intent of this section is to provide a baseline
>    for security considerations which are common to all DetNet designs
>    and implementations, without burdening individual designs with
>    specifics of security infrastructure which may not be germane to the
>    given use case.  Designers and Implementers of DetNet systems are
>    expected to take use case specific considerations into account in
>    their DetNet designs and implementations.
>
>
> Please let us know if you have any remaining comments and what they are.
>
> Thank you!
> Janos
>
>
> On 2/23/2019 9:39 PM, Lou Berger wrote:
>>
>> Hi *Alvaro*,
>>
>> see below.
>>
>> On 2/22/2019 6:02 AM, Alvaro Retana wrote:
>>> On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net 
>>> ) wrote:
>>>
>>> Hi!
>>>
>>>> >>> ----------------------------------------------------------------------
>>>> >>> DISCUSS:
>>>> >>> 
>>>> ----------------------------------------------------------------------
>>>> >>>
>>>> >>> I support Mirja's and Alissa's DISCUSSes...and have a related 
>>>> set of concerns
>>>> >>> about the coexistence with non-DetNet traffic and privacy:
>>>> >>>
>>>> >>> §3.3.1 talks about what I think is a hard to achieve balance 
>>>> between coexisting
>>>> >>> with non-DetNet traffic and keeping that traffic from 
>>>> disrupting DetNet flows.
>>>> >>> Because of the constraints, the intent of prioritizing DetNet 
>>>> flows is clear
>>>> >>> (and that is ok), but that may result in starvation of non-DetNet
>>>> >>> traffic...even if the text does explicitly say that it "must be 
>>>> avoided".
>>>> >>>
>>>> >>> I would like to see the potential case of starving non-DetNet 
>>>> traffic called
>>>> >>> out somewhere.
>>>> >>
>>>> >> This is the objective of section 3.3.1..
>>>> >>
>>>> >>
>>>> >>> I'm looking for something similar to the first paragraph in §5,
>>>> >>> but focused on the non-DetNet traffic.
>>>> >>
>>>> >> The current text reads:
>>>> >>
>>>> >> 3.3.1. Coexistence with normal traffic
>>>> >>
>>>> >> A DetNet network supports the dedication of a high proportion of the
>>>> >> network bandwidth to DetNet flows. But, no matter how much is
>>>> >> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>>>> >> existing Class of Service schemes (e.g., DiffServ). It is also
>>>> >> important that non-DetNet traffic not disrupt the DetNet flow, of
>>>> >> course (see Section 3.3.2 and Section 5). For these reasons:
>>>> >>
>>>> >> o Bandwidth (transmission opportunities) not utilized by a DetNet
>>>> >> flow is available to non-DetNet packets (though not to other
>>>> >> DetNet flows).
>>>> >>
>>>> >> o DetNet flows can be shaped or scheduled, in order to ensure that
>>>> >> the highest-priority non-DetNet packet is also ensured a worst-
>>>> >> case latency.
>>>> >>
>>>> >> o When transmission opportunities for DetNet flows are scheduled in
>>>> >> detail, then the algorithm constructing the schedule should leave
>>>> >> sufficient opportunities for non-DetNet packets to satisfy the
>>>> >> needs of the users of the network. Detailed scheduling can also
>>>> >> permit the time-shared use of buffer resources by different DetNet
>>>> >> flows.
>>>> >>
>>>> >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>> >> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>>>> >> presence of DetNet flows in a network on the non-DetNet flows is
>>>> >> primarily a reduction in the available bandwidth.
>>>> >>
>>>> >>
>>>> >> I think we need a little bit more to understand what you'd like 
>>>> to see changed or added. Can you suggest text or what specific 
>>>> topic you'd like to see added/addressed?
>>>> >
>>>> > Yes, let me try to explain better…while comparing with the current
>>>> > text in §5, which basically says that even though the objective of
>>>> > DetNet is to provide bounded latency, a MIIM may delay the 
>>>> traffic and
>>>> > the objective may not be achieved.
>>>> >
>>>> > For non-DetNet traffic, the objective is to not starve it, while
>>>> > providing specific guarantees to the DetNet flows — said other way
>>>> > (from the Introduction): "Unused reserved resources are available to
>>>> > non-DetNet packets as long as all guarantees are fulfilled.” 
>>>>  However,
>>>> > the algorithms (maybe error, misconfiguration…or even 
>>>> maliciously) may
>>>> > end up*not* constructing the schedule to leave sufficient
>>>> > opportunities for non-DetNet packets (as suggested in the text above
>>>> > from §3.3.1).
>>>> >
>>>> > I see a parallel in how there is a risk of the intention for DetNet
>>>> > flows not being met (because of an attack) and how the intention for
>>>> > non-DetNet traffic may also not be met.
>>>> >
>>>> Okay, this sounds like basically the same point that Benjamin was
>>>> making, i.e., there must be mechanisms preventing non-detnet traffic
>>>> from impacting detnet traffic, and detnet traffic trying to use more
>>>> than its allocation and impacting non-detnet traffic. Is this 
>>>> correct or
>>>> are you asking for something different/additional?
>>>
>>> Yes.  I’m not asking so much for a mechanism, but for at least the 
>>> recognition that it is a risk.
>>>
>> Fair enough- I expect the response a response for the architecture 
>> and security draft authors to address this.  I'm sure you will 
>> confirm that it does!
>>
>>
>>>>
>>>>
>>>>
>>>> >
>>>> >>> Related to the above is the fact that the identification of 
>>>> flows could be used
>>>> >>> to specifically *not* include some of them as DetNet flows. 
>>>> This is a
>>>> >>> variation of the concern outlined in §6, but applied to 
>>>> non-DetNet flows, with
>>>> >>> the potential starvation mentioned above. Again, I would like 
>>>> to at least see
>>>> >>> some discussion of this risk.
>>>> >>
>>>> >> I don't follow - what is the risk that should be addressed?
>>>> >>
>>>> > §6 talks about potential privacy concerns due to the 
>>>> identification of
>>>> > flows.  I interpret that as potentially being able to identify the
>>>> > user (application, or both maybe).
>>>> >
>>>> Currently flow identification is based on IP headers (6 tuple) and/or
>>>> MPLS labels.  So DetNet has the same privacy concerns as standard 
>>>> IP/MPLS.
>>>>
>>>>
>>>> > As far as I understand the architecture, DetNet flows are identified
>>>> > at the edge and then assigned to specific paths.  If the
>>>> > identification of flows can be used to identify the user (for
>>>> > example), then it can be used to not only attack specific DetNet 
>>>> flow,
>>>> > but also to decide to not provide guarantees to a specific flow based
>>>> > on who the user or the application may be.
>>>> >
>>>> Given DetNet flow identification, is this any different than 
>>>> standard PBR?
>>>
>>> Right, it is not really different.  It is just not mentioned 
>>> anywhere that identification (or misidentification as it may be, 
>>> maybe maliciously) can lead to not providing guarantees, potential 
>>> starving, etc..
>>>
>> I thought the quotes capture in the various mails on the topic showed 
>> how it was -- but let's wait for the updated text and see if it 
>> sufficiently addresses your concern/point, and then go from there.
>>
>> Thanks again for the feedback.
>>
>> Lou
>>
>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet
>


--------------78FC0D36E29D42531BF03C2A
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Alvaro,

    

    We believe that we have addressed your comments in the most recent
    revision:
    https://tools.ietf.org/html/draft-ietf-detnet-architecture-12.
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

    

    Please let us know what else you would like to see done before you
    clear your DISCUSS.

    

    I/we would be happy to meet with you this week if there is anything
    you would like to discuss.

    

    Regards,

    Janos

    

    

    
On 3/6/2019 6:56 AM, János Farkas
      wrote:

    

    

      
      Hi Alvaro,

      

      Do the updates we are making the security section resolve your
      comments:

      https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o

      

      The current proposed text:

      

      5.  Security Considerations

      

         Security considerations for DetNet are described in detail in

         [I-D.ietf-detnet-security].  This section considers exclusively

         security considerations which are specific to the DetNet

         Architecture.

      

         Security aspects which are unique to DetNet are those whose aim
      is to

         provide the specific quality of service aspects of DetNet,
      which are

         primarily to deliver data flows with extremely low packet loss
      rates

         and bounded end-to-end delivery latency.  A DetNet may be
      implemented

         using MPLS and/or IP (including both v4 and v6) technologies,
      and

         thus inherits the security properties of those technologies at
      both

         the control plane and the data plane.

      

         Security considerations for DetNet are constrained (compared
      to, for

         example, the open Internet) because DetNet is defined to
      operate only

         within a single administrative domain (see Section 1).  The
      primary

         considerations are to secure the request and control of DetNet

         resources, maintain confidentiality of data traversing the
      DetNet,

         and provide the availability of the DetNet quality of service.

      

         To secure the request and control of DetNet resources,
      authentication

         and authorization can be used for each device connected to a
      DetNet

         domain, most importantly to network controller devices. 
      Control of a

         DetNet network may be centralized or distributed (within a
      single

         administrative domain).  In the case of centralized control,

         precedent for security considerations as defined for
      Abstraction and

         Control of Traffic Engineered Networks (ACTN) can be found in

         [RFC8453], Section 9.  In the case of a distributed control

         protocols, DetNet security is expected to be provided by the
      security

         properties of the protocols in use.  In any case, the result is
      that

         manipulation of administratively configurable parameters is
      limited

         to authorized entities.

      

         To maintain confidentiality of data traversing the DetNet,

         application flows can be protected through whatever means is
      provided

         by the underlying technology.  For example, encryption may be
      used,

         such as that provided by IPSec [RFC4301] for IP (Layer 3) flows
      and

         by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.

      

         DetNet flows are identified on a per-flow basis, which may
      provide

         attackers with additional information about the data flows
      (when

         compared to networks that do not include per-flow
      identification).

         This is an inherent property of DetNet which has security

         implications which should be considered when determining if
      DetNet is

         a suitable technology for any given use case.

      

         To provide uninterrupted availability of the DetNet quality of

         service, provisions can be made against DOS attacks and delay

         attacks.  To protect against DOS attacks, excess traffic due to

         malicious or malfunctioning devices can be prevented or
      mitigated,

         for example through the use of traffic admission control
      applied at

         the input of a DetNet domain, as described in Section 3.2.1,
      and

         through the fault mitigation methods described in Section
      3.3.2.  To

         prevent DetNet packets from being delayed by an entity external
      to a

         DetNet domain, DetNet technology definition can allow for the

         mitigation of Man-In-The-Middle attacks, for example through
      use of

         authentication and authorization of devices within the DetNet
      domain.

      

         Because DetNet mechanisms or applications that rely on DetNet
      can

         make heavy use of methods that require precise time
      synchronization,

         the accuracy, availability, and integrity of time
      synchronization is

         of critical importance.  Extensive discussion of this topic can
      be

         found in [RFC7384].

      

         DetNet use cases are known to have widely divergent security

         requirements.  The intent of this section is to provide a
      baseline

         for security considerations which are common to all DetNet
      designs

         and implementations, without burdening individual designs with

         specifics of security infrastructure which may not be germane
      to the

         given use case.  Designers and Implementers of DetNet systems
      are

         expected to take use case specific considerations into account
      in

         their DetNet designs and implementations.

      

      

      Please let us know if you have any remaining comments and what
      they are.

      

      Thank you!

      Janos

      

      

      
On 2/23/2019 9:39 PM, Lou Berger
        wrote:

      

      

        
Hi *Alvaro*,

        
see below.

        

        
On 2/22/2019 6:02 AM, Alvaro Retana
          wrote:

        

        

          
          
On
            February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net)
            wrote:

          


          

          
Hi!

          


          

          

            

                

                  
>>>
                    ---------------------------------------------------------------------- 

                    >>> DISCUSS: 

                    >>>
                    ---------------------------------------------------------------------- 

                    >>> 

                    >>> I support Mirja's and Alissa's
                    DISCUSSes...and have a related set of concerns 

                    >>> about the coexistence with non-DetNet
                    traffic and privacy: 

                    >>> 

                    >>> §3.3.1 talks about what I think is a
                    hard to achieve balance between coexisting 

                    >>> with non-DetNet traffic and keeping
                    that traffic from disrupting DetNet flows. 

                    >>> Because of the constraints, the intent
                    of prioritizing DetNet flows is clear 

                    >>> (and that is ok), but that may result
                    in starvation of non-DetNet 

                    >>> traffic...even if the text does
                    explicitly say that it "must be avoided". 

                    >>> 

                    >>> I would like to see the potential case
                    of starving non-DetNet traffic called 

                    >>> out somewhere. 

                    >> 

                    >> This is the objective of section 3.3.1.. 

                    >> 

                    >> 

                    >>> I'm looking for something similar to
                    the first paragraph in §5, 

                    >>> but focused on the non-DetNet traffic. 

                    >> 

                    >> The current text reads: 

                    >> 

                    >> 3.3.1. Coexistence with normal traffic 

                    >> 

                    >> A DetNet network supports the dedication of
                    a high proportion of the 

                    >> network bandwidth to DetNet flows. But, no
                    matter how much is 

                    >> dedicated for DetNet flows, it is a goal of
                    DetNet to coexist with 

                    >> existing Class of Service schemes (e.g.,
                    DiffServ). It is also 

                    >> important that non-DetNet traffic not
                    disrupt the DetNet flow, of 

                    >> course (see Section 3.3.2 and Section 5).
                    For these reasons: 

                    >> 

                    >> o Bandwidth (transmission opportunities)
                    not utilized by a DetNet 

                    >> flow is available to non-DetNet packets
                    (though not to other 

                    >> DetNet flows). 

                    >> 

                    >> o DetNet flows can be shaped or scheduled,
                    in order to ensure that 

                    >> the highest-priority non-DetNet packet is
                    also ensured a worst- 

                    >> case latency. 

                    >> 

                    >> o When transmission opportunities for
                    DetNet flows are scheduled in 

                    >> detail, then the algorithm constructing the
                    schedule should leave 

                    >> sufficient opportunities for non-DetNet
                    packets to satisfy the 

                    >> needs of the users of the network. Detailed
                    scheduling can also 

                    >> permit the time-shared use of buffer
                    resources by different DetNet 

                    >> flows. 

                    >> 

                    >> Starvation of non-DetNet traffic must be
                    avoided, e.g., by traffic 

                    >> policing functions (e.g., [RFC2475]). Thus,
                    the net effect of the 

                    >> presence of DetNet flows in a network on
                    the non-DetNet flows is 

                    >> primarily a reduction in the available
                    bandwidth. 

                    >> 

                    >> 

                    >> I think we need a little bit more to
                    understand what you'd like to see changed or added.
                    Can you suggest text or what specific topic you'd
                    like to see added/addressed? 

                    > 

                    > Yes, let me try to explain better…while
                    comparing with the current 

                    > text in §5, which basically says that even
                    though the objective of 

                    > DetNet is to provide bounded latency, a MIIM
                    may delay the traffic and 

                    > the objective may not be achieved. 

                    > 

                    > For non-DetNet traffic, the objective is to not
                    starve it, while 

                    > providing specific guarantees to the DetNet
                    flows — said other way 

                    > (from the Introduction): "Unused reserved
                    resources are available to 

                    > non-DetNet packets as long as all guarantees
                    are fulfilled.”  However, 

                    > the algorithms (maybe error,
                    misconfiguration…or even maliciously) may 

                    > end up*not* constructing the schedule to leave
                    sufficient 

                    > opportunities for non-DetNet packets (as
                    suggested in the text above 

                    > from §3.3.1). 

                    > 

                    > I see a parallel in how there is a risk of the
                    intention for DetNet 

                    > flows not being met (because of an attack) and
                    how the intention for 

                    > non-DetNet traffic may also not be met. 

                    > 

                    Okay, this sounds like basically the same point that
                    Benjamin was 

                    making, i.e., there must be mechanisms preventing
                    non-detnet traffic 

                    from impacting detnet traffic, and detnet traffic
                    trying to use more 

                    than its allocation and impacting non-detnet
                    traffic. Is this correct or 

                    are you asking for something different/additional? 

                

              

          

          
Yes.  I’m not asking so much for a mechanism, but for at
            least the recognition that it is a risk.

        

        
Fair enough- I expect the response a response for the
          architecture and security draft authors to address this.  I'm
          sure you will confirm that it does!

        


        

        

          

            

              

                  

                    


                      

                      

                      > 

                      >>> Related to the above is the fact that
                      the identification of flows could be used 

                      >>> to specifically *not* include some of
                      them as DetNet flows. This is a 

                      >>> variation of the concern outlined in
                      §6, but applied to non-DetNet flows, with 

                      >>> the potential starvation mentioned
                      above. Again, I would like to at least see 

                      >>> some discussion of this risk. 

                      >> 

                      >> I don't follow - what is the risk that
                      should be addressed? 

                      >> 

                      > §6 talks about potential privacy concerns due
                      to the identification of 

                      > flows.  I interpret that as potentially being
                      able to identify the 

                      > user (application, or both maybe). 

                      > 

                      Currently flow identification is based on IP
                      headers (6 tuple) and/or 

                      MPLS labels.  So DetNet has the same privacy
                      concerns as standard IP/MPLS. 

                      

                      

                      > As far as I understand the architecture,
                      DetNet flows are identified 

                      > at the edge and then assigned to specific
                      paths.  If the 

                      > identification of flows can be used to
                      identify the user (for 

                      > example), then it can be used to not only
                      attack specific DetNet flow, 

                      > but also to decide to not provide guarantees
                      to a specific flow based 

                      > on who the user or the application may be. 

                      > 

                      Given DetNet flow identification, is this any
                      different than standard PBR? 

                  

                

            

            
Right, it is not really different.  It is just not
              mentioned anywhere that identification (or
              misidentification as it may be, maybe maliciously) can
              lead to not providing guarantees, potential starving,
              etc..

          

        

        
I thought the quotes capture in the various mails on the
          topic showed how it was -- but let's wait for the updated text
          and see if it sufficiently addresses your concern/point, and
          then go from there.

        

        
Thanks again for the feedback.

        
Lou

        

        


        

        

          

            
Thanks!

            
Alvaro.

          

          

          

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


        

      

      

    

    

  


--------------78FC0D36E29D42531BF03C2A--


From nobody Mon Mar 25 09:46:55 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 C841A1203FF; Mon, 25 Mar 2019 09:46:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: detnet@ietf.org
Message-ID: <155353240678.28988.18080552674175846436@ietfa.amsl.com>
Date: Mon, 25 Mar 2019 09:46:46 -0700
Archived-At: 
Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 16:46:47 -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-02.txt
	Pages           : 46
	Date            : 2019-03-25

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-yang-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Mar 25 11:37: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 18EB712074B; Mon, 25 Mar 2019 11:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xGdKI78HOg20; Mon, 25 Mar 2019 11:37:03 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 7213F120700; Mon, 25 Mar 2019 11:37:03 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id 103so9008073otd.9; Mon, 25 Mar 2019 11:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=vtUZ/jFAoAYLsUr/EJqQTjeyIek9IdTvP+7qoUpDnlg=; b=lxWMcqUERYMNQbs7Snsr66HK3SCq3a41dMiHu8hwFjjz7a6R0opGyuN/wNTGvo1IhI SmW3TM85bM/yWRXTOxDdHx/org0nPmKqGrAC2cPxgumpFSSIs7WGrKa6AHp3XUXcAUpU odd5YcTIg1HuTxZ3zsUQOMCWRLmTb7+yBogZMqch6aOBb2DaySra/tZlaj4k2mDypiPN Nr3PB4bvMzGWz8iBZLgvmBTAmBJ3rS7K8hDhzfEsxv7v6A1lk2ka7+UAZjS+yrFRvP62 exAKqaxmVOEDLuZOERhGJE2SmsCodGPjZQ6q4WM3rHkiRKqUVWZuFV7zxI6J415mXaI3 +qAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=vtUZ/jFAoAYLsUr/EJqQTjeyIek9IdTvP+7qoUpDnlg=; b=eIxV5FwgqYbZ64SlphXKv563GVg18UFN6HxPv3yM0rVtNdvqkxTXVlUYOGEpSe6G/E crNbdKhav9fT8DJ2dQvvVrOY/TyJIB4sim7BiJA0KRqtFAhxZJG89SJ28n7rp22F4A/7 LbWtxgAi7tYH/UaMeY65w8gwSm4zKjCus3Z3TwKValSs7i0KE1EdMt2oKeixROzxDBNH BS+IcijNVC8fN2xhTmr6l4jBFxFfgsxrxQtthuWPdOCmyScgQVXyPBjPLWZjnJuymPUi rE/lmolXh26imZSgNBnlT8dd+fn7iSHyEPaMuoc85m6w8DrWQ4xGjP6QY7C9zZ290/da Nycg==
X-Gm-Message-State: APjAAAUANj1CKy3QjladPlGz2ilyFKiHLaJxsc5DwjdeUW1ljvxYvatr XPzVfsriSitRIEBUVFsx/fSPlTtk2SVdYvHW9hQ=
X-Google-Smtp-Source: APXvYqx0WvFifSVm6e2VWvVwRF5R5VNF+fDy43dMZpHKGnIp3X+k8EZnJ8nQfdqm3k3mrtLFs2iDqrjKavZvFYo1lKQ=
X-Received: by 2002:a9d:63d1:: with SMTP id e17mr19432886otl.239.1553539022637;  Mon, 25 Mar 2019 11:37:02 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2019 19:37:02 +0100
From: Alvaro Retana 
In-Reply-To: <06a42687-5942-2591-4c71-5a5ff5090474@ericsson.com>
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>   <150fb3c5-0f60-8426-0345-a17d9be984b9@ericsson.com> <06a42687-5942-2591-4c71-5a5ff5090474@ericsson.com>
MIME-Version: 1.0
Date: Mon, 25 Mar 2019 19:37:02 +0100
Message-ID: 
To: =?UTF-8?Q?J=C3=A1nos_Farkas?= 
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger ,  The IESG , detnet-chairs@ietf.org, detnet@ietf.org
Content-Type: multipart/alternative; boundary="00000000000096cfcb0584ef7d8f"
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 18:37:07 -0000

--00000000000096cfcb0584ef7d8f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

J=C3=A1nos:

Hi!

Yes=E2=80=A6I=E2=80=99m happy with the changes.  I=E2=80=99m clearing my DI=
SCUSS.

Thanks!

Alvaro.

On March 25, 2019 at 5:20:37 PM, J=C3=A1nos Farkas (janos.farkas@ericsson.c=
om)
wrote:

Hi Alvaro,

We believe that we have addressed your comments in the most recent
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. (
https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you
would like to discuss.

Regards,
Janos


On 3/6/2019 6:56 AM, J=C3=A1nos Farkas wrote:

Hi Alvaro,

Do the updates we are making the security section resolve your comments:
https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o

The current proposed text:

5.  Security Considerations

   Security considerations for DetNet are described in detail in
   [I-D.ietf-detnet-security].  This section considers exclusively
   security considerations which are specific to the DetNet
   Architecture.

   Security aspects which are unique to DetNet are those whose aim is to
   provide the specific quality of service aspects of DetNet, which are
   primarily to deliver data flows with extremely low packet loss rates
   and bounded end-to-end delivery latency.  A DetNet may be implemented
   using MPLS and/or IP (including both v4 and v6) technologies, and
   thus inherits the security properties of those technologies at both
   the control plane and the data plane.

   Security considerations for DetNet are constrained (compared to, for
   example, the open Internet) because DetNet is defined to operate only
   within a single administrative domain (see Section 1).  The primary
   considerations are to secure the request and control of DetNet
   resources, maintain confidentiality of data traversing the DetNet,
   and provide the availability of the DetNet quality of service.

   To secure the request and control of DetNet resources, authentication
   and authorization can be used for each device connected to a DetNet
   domain, most importantly to network controller devices.  Control of a
   DetNet network may be centralized or distributed (within a single
   administrative domain).  In the case of centralized control,
   precedent for security considerations as defined for Abstraction and
   Control of Traffic Engineered Networks (ACTN) can be found in
   [RFC8453], Section 9.  In the case of a distributed control
   protocols, DetNet security is expected to be provided by the security
   properties of the protocols in use.  In any case, the result is that
   manipulation of administratively configurable parameters is limited
   to authorized entities.

   To maintain confidentiality of data traversing the DetNet,
   application flows can be protected through whatever means is provided
   by the underlying technology.  For example, encryption may be used,
   such as that provided by IPSec [RFC4301] for IP (Layer 3) flows and
   by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.

   DetNet flows are identified on a per-flow basis, which may provide
   attackers with additional information about the data flows (when
   compared to networks that do not include per-flow identification).
   This is an inherent property of DetNet which has security
   implications which should be considered when determining if DetNet is
   a suitable technology for any given use case.

   To provide uninterrupted availability of the DetNet quality of
   service, provisions can be made against DOS attacks and delay
   attacks.  To protect against DOS attacks, excess traffic due to
   malicious or malfunctioning devices can be prevented or mitigated,
   for example through the use of traffic admission control applied at
   the input of a DetNet domain, as described in Section 3.2.1, and
   through the fault mitigation methods described in Section 3.3.2.  To
   prevent DetNet packets from being delayed by an entity external to a
   DetNet domain, DetNet technology definition can allow for the
   mitigation of Man-In-The-Middle attacks, for example through use of
   authentication and authorization of devices within the DetNet domain.

   Because DetNet mechanisms or applications that rely on DetNet can
   make heavy use of methods that require precise time synchronization,
   the accuracy, availability, and integrity of time synchronization is
   of critical importance.  Extensive discussion of this topic can be
   found in [RFC7384].

   DetNet use cases are known to have widely divergent security
   requirements.  The intent of this section is to provide a baseline
   for security considerations which are common to all DetNet designs
   and implementations, without burdening individual designs with
   specifics of security infrastructure which may not be germane to the
   given use case.  Designers and Implementers of DetNet systems are
   expected to take use case specific considerations into account in
   their DetNet designs and implementations.


Please let us know if you have any remaining comments and what they are.

Thank you!
Janos


On 2/23/2019 9:39 PM, Lou Berger wrote:

Hi *Alvaro*,

see below.
On 2/22/2019 6:02 AM, Alvaro Retana wrote:

On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net) wrote:

Hi!

>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I support Mirja's and Alissa's DISCUSSes...and have a related set of
concerns
>>> about the coexistence with non-DetNet traffic and privacy:
>>>
>>> =C2=A73.3.1 talks about what I think is a hard to achieve balance betwe=
en
coexisting
>>> with non-DetNet traffic and keeping that traffic from disrupting DetNet
flows.
>>> Because of the constraints, the intent of prioritizing DetNet flows is
clear
>>> (and that is ok), but that may result in starvation of non-DetNet
>>> traffic...even if the text does explicitly say that it "must be
avoided".
>>>
>>> I would like to see the potential case of starving non-DetNet traffic
called
>>> out somewhere.
>>
>> This is the objective of section 3.3.1..
>>
>>
>>> I'm looking for something similar to the first paragraph in =C2=A75,
>>> but focused on the non-DetNet traffic.
>>
>> The current text reads:
>>
>> 3.3.1. Coexistence with normal traffic
>>
>> A DetNet network supports the dedication of a high proportion of the
>> network bandwidth to DetNet flows. But, no matter how much is
>> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>> existing Class of Service schemes (e.g., DiffServ). It is also
>> important that non-DetNet traffic not disrupt the DetNet flow, of
>> course (see Section 3.3.2 and Section 5). For these reasons:
>>
>> o Bandwidth (transmission opportunities) not utilized by a DetNet
>> flow is available to non-DetNet packets (though not to other
>> DetNet flows).
>>
>> o DetNet flows can be shaped or scheduled, in order to ensure that
>> the highest-priority non-DetNet packet is also ensured a worst-
>> case latency.
>>
>> o When transmission opportunities for DetNet flows are scheduled in
>> detail, then the algorithm constructing the schedule should leave
>> sufficient opportunities for non-DetNet packets to satisfy the
>> needs of the users of the network. Detailed scheduling can also
>> permit the time-shared use of buffer resources by different DetNet
>> flows.
>>
>> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>> presence of DetNet flows in a network on the non-DetNet flows is
>> primarily a reduction in the available bandwidth.
>>
>>
>> I think we need a little bit more to understand what you'd like to see
changed or added. Can you suggest text or what specific topic you'd like to
see added/addressed?
>
> Yes, let me try to explain better=E2=80=A6while comparing with the curren=
t
> text in =C2=A75, which basically says that even though the objective of
> DetNet is to provide bounded latency, a MIIM may delay the traffic and
> the objective may not be achieved.
>
> For non-DetNet traffic, the objective is to not starve it, while
> providing specific guarantees to the DetNet flows =E2=80=94 said other wa=
y
> (from the Introduction): "Unused reserved resources are available to
> non-DetNet packets as long as all guarantees are fulfilled.=E2=80=9D  How=
ever,
> the algorithms (maybe error, misconfiguration=E2=80=A6or even maliciously=
) may
> end up*not* constructing the schedule to leave sufficient
> opportunities for non-DetNet packets (as suggested in the text above
> from =C2=A73.3.1).
>
> I see a parallel in how there is a risk of the intention for DetNet
> flows not being met (because of an attack) and how the intention for
> non-DetNet traffic may also not be met.
>
Okay, this sounds like basically the same point that Benjamin was
making, i.e., there must be mechanisms preventing non-detnet traffic
from impacting detnet traffic, and detnet traffic trying to use more
than its allocation and impacting non-detnet traffic. Is this correct or
are you asking for something different/additional?

Yes.  I=E2=80=99m not asking so much for a mechanism, but for at least the
recognition that it is a risk.

Fair enough- I expect the response a response for the architecture and
security draft authors to address this.  I'm sure you will confirm that it
does!





>
>>> Related to the above is the fact that the identification of flows could
be used
>>> to specifically *not* include some of them as DetNet flows. This is a
>>> variation of the concern outlined in =C2=A76, but applied to non-DetNet
flows, with
>>> the potential starvation mentioned above. Again, I would like to at
least see
>>> some discussion of this risk.
>>
>> I don't follow - what is the risk that should be addressed?
>>
> =C2=A76 talks about potential privacy concerns due to the identification =
of
> flows.  I interpret that as potentially being able to identify the
> user (application, or both maybe).
>
Currently flow identification is based on IP headers (6 tuple) and/or
MPLS labels.  So DetNet has the same privacy concerns as standard IP/MPLS.


> As far as I understand the architecture, DetNet flows are identified
> at the edge and then assigned to specific paths.  If the
> identification of flows can be used to identify the user (for
> example), then it can be used to not only attack specific DetNet flow,
> but also to decide to not provide guarantees to a specific flow based
> on who the user or the application may be.
>
Given DetNet flow identification, is this any different than standard PBR?

Right, it is not really different.  It is just not mentioned anywhere that
identification (or misidentification as it may be, maybe maliciously) can
lead to not providing guarantees, potential starving, etc..

I thought the quotes capture in the various mails on the topic showed how
it was -- but let's wait for the updated text and see if it sufficiently
addresses your concern/point, and then go from there.

Thanks again for the feedback.

Lou


Thanks!

Alvaro.

_______________________________________________
detnet mailing listdetnet@ietf.orghttps://www.ietf.org/mailman/listinfo/det=
net

--00000000000096cfcb0584ef7d8f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

J=C3=A1nos:

Hi!

Yes=E2=80=A6I=E2=80=99m happy with the changes.=C2=A0 I=E2=80=99m clea=
ring my DISCUSS.

Th=
anks!

Alvaro.
=
 
On March 25, 2019 at 5:20:37 PM, J=C3=A1nos Fa=
rkas (janos.farkas@ericsson.co=
m) wrote:
 







Hi Alvaro,



We believe that we have addressed your comments in the most recent
revision: https://tools.ietf.org/html/draft-=
ietf-detnet-architecture-12.
(https://mailarchive.ietf.org/arc=
h/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)




Please let us know what else you would like to see done before you
clear your DISCUSS.



I/we would be happy to meet with you this week if there is anything
you would like to discuss.



Regards,

Janos






On 3/6/2019 6:56 AM, J=C3=A1nos Farkas
wrote:



Hi Alvaro,



Do the updates we are making the security section resolve your
comments:

https://mailarchive.ietf.org/arch=
/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o




The current proposed text:



5.=C2=A0 Security Considerations



=C2=A0=C2=A0 Security considerations for DetNet are described in
detail in

=C2=A0=C2=A0 [I-D.ietf-detnet-security].=C2=A0 This section
considers exclusively

=C2=A0=C2=A0 security considerations which are specific to the
DetNet

=C2=A0=C2=A0 Architecture.



=C2=A0=C2=A0 Security aspects which are unique to DetNet are those
whose aim is to

=C2=A0=C2=A0 provide the specific quality of service aspects of
DetNet, which are

=C2=A0=C2=A0 primarily to deliver data flows with extremely low
packet loss rates

=C2=A0=C2=A0 and bounded end-to-end delivery latency.=C2=A0 A
DetNet may be implemented

=C2=A0=C2=A0 using MPLS and/or IP (including both v4 and v6)
technologies, and

=C2=A0=C2=A0 thus inherits the security properties of those
technologies at both

=C2=A0=C2=A0 the control plane and the data plane.



=C2=A0=C2=A0 Security considerations for DetNet are constrained
(compared to, for

=C2=A0=C2=A0 example, the open Internet) because DetNet is defined
to operate only

=C2=A0=C2=A0 within a single administrative domain (see Section
1).=C2=A0 The primary

=C2=A0=C2=A0 considerations are to secure the request and control
of DetNet

=C2=A0=C2=A0 resources, maintain confidentiality of data traversing
the DetNet,

=C2=A0=C2=A0 and provide the availability of the DetNet quality of
service.



=C2=A0=C2=A0 To secure the request and control of DetNet resources,
authentication

=C2=A0=C2=A0 and authorization can be used for each device
connected to a DetNet

=C2=A0=C2=A0 domain, most importantly to network controller
devices.=C2=A0 Control of a

=C2=A0=C2=A0 DetNet network may be centralized or distributed
(within a single

=C2=A0=C2=A0 administrative domain).=C2=A0 In the case of
centralized control,

=C2=A0=C2=A0 precedent for security considerations as defined for
Abstraction and

=C2=A0=C2=A0 Control of Traffic Engineered Networks (ACTN) can be
found in

=C2=A0=C2=A0 [RFC8453], Section 9.=C2=A0 In the case of a
distributed control

=C2=A0=C2=A0 protocols, DetNet security is expected to be provided
by the security

=C2=A0=C2=A0 properties of the protocols in use.=C2=A0 In any case,
the result is that

=C2=A0=C2=A0 manipulation of administratively configurable
parameters is limited

=C2=A0=C2=A0 to authorized entities.



=C2=A0=C2=A0 To maintain confidentiality of data traversing the
DetNet,

=C2=A0=C2=A0 application flows can be protected through whatever
means is provided

=C2=A0=C2=A0 by the underlying technology.=C2=A0 For example,
encryption may be used,

=C2=A0=C2=A0 such as that provided by IPSec [RFC4301] for IP (Layer
3) flows and

=C2=A0=C2=A0 by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2)
flows.



=C2=A0=C2=A0 DetNet flows are identified on a per-flow basis, which
may provide

=C2=A0=C2=A0 attackers with additional information about the data
flows (when

=C2=A0=C2=A0 compared to networks that do not include per-flow
identification).

=C2=A0=C2=A0 This is an inherent property of DetNet which has
security

=C2=A0=C2=A0 implications which should be considered when
determining if DetNet is

=C2=A0=C2=A0 a suitable technology for any given use case.



=C2=A0=C2=A0 To provide uninterrupted availability of the DetNet
quality of

=C2=A0=C2=A0 service, provisions can be made against DOS attacks
and delay

=C2=A0=C2=A0 attacks.=C2=A0 To protect against DOS attacks, excess
traffic due to

=C2=A0=C2=A0 malicious or malfunctioning devices can be prevented
or mitigated,

=C2=A0=C2=A0 for example through the use of traffic admission
control applied at

=C2=A0=C2=A0 the input of a DetNet domain, as described in Section
3.2.1, and

=C2=A0=C2=A0 through the fault mitigation methods described in
Section 3.3.2.=C2=A0 To

=C2=A0=C2=A0 prevent DetNet packets from being delayed by an entity
external to a

=C2=A0=C2=A0 DetNet domain, DetNet technology definition can allow
for the

=C2=A0=C2=A0 mitigation of Man-In-The-Middle attacks, for example
through use of

=C2=A0=C2=A0 authentication and authorization of devices within the
DetNet domain.



=C2=A0=C2=A0 Because DetNet mechanisms or applications that rely on
DetNet can

=C2=A0=C2=A0 make heavy use of methods that require precise time
synchronization,

=C2=A0=C2=A0 the accuracy, availability, and integrity of time
synchronization is

=C2=A0=C2=A0 of critical importance.=C2=A0 Extensive discussion of
this topic can be

=C2=A0=C2=A0 found in [RFC7384].



=C2=A0=C2=A0 DetNet use cases are known to have widely divergent
security

=C2=A0=C2=A0 requirements.=C2=A0 The intent of this section is to
provide a baseline

=C2=A0=C2=A0 for security considerations which are common to all
DetNet designs

=C2=A0=C2=A0 and implementations, without burdening individual
designs with

=C2=A0=C2=A0 specifics of security infrastructure which may not be
germane to the

=C2=A0=C2=A0 given use case.=C2=A0 Designers and Implementers of
DetNet systems are

=C2=A0=C2=A0 expected to take use case specific considerations into
account in

=C2=A0=C2=A0 their DetNet designs and implementations.





Please let us know if you have any remaining comments and what they
are.



Thank you!

Janos






On 2/23/2019 9:39 PM, Lou Berger
wrote:




Hi *Alvaro*,


see below.


On 2/22/2019 6:02 AM, Alvaro Retana
wrote:





On February
21, 2019 at 7:35:32 PM, Lou Berger (lbe=
rger@labn.net) wrote:






Hi!












>>>
----------------------------------------------------------------------=C2=A0


>>> DISCUSS:=C2=A0
>>>
----------------------------------------------------------------------=C2=A0


>>>=C2=A0

>>> I support Mirja's and Alissa's DISCUSSes...and have a
related set of concerns=C2=A0<=
br>
>>> about the coexistence with non-DetNet traffic and
privacy:=C2=A0

>>>=C2=A0

>>> =C2=A73.3.1 talks about what I think is a hard to achieve
balance between coexisting=C2=A0

>>> with non-DetNet traffic and keeping that traffic from
disrupting DetNet flows.=C2=A0=


>>> Because of the constraints, the intent of prioritizing
DetNet flows is clear=C2=A0
>>> (and that is ok), but that may result in starvation of
non-DetNet=C2=A0

>>> traffic...even if the text does explicitly say that it
"must be avoided".=C2=A0

>>>=C2=A0

>>> I would like to see the potential case of starving
non-DetNet traffic called=C2=A0

>>> out somewhere.=C2=A0

>>=C2=A0

>> This is the objective of section 3.3.1..=C2=A0

>>=C2=A0

>>=C2=A0

>>> I'm looking for something similar to the first
paragraph in =C2=A75,=C2=A0
>>> but focused on the non-DetNet traffic.=C2=A0

>>=C2=A0

>> The current text reads:=C2=
=A0

>>=C2=A0

>> 3.3.1. Coexistence with normal traffic=C2=A0

>>=C2=A0

>> A DetNet network supports the dedication of a high
proportion of the=C2=A0

>> network bandwidth to DetNet flows. But, no matter how much
is=C2=A0

>> dedicated for DetNet flows, it is a goal of DetNet to
coexist with=C2=A0

>> existing Class of Service schemes (e.g., DiffServ). It is
also=C2=A0

>> important that non-DetNet traffic not disrupt the DetNet
flow, of=C2=A0

>> course (see Section 3.3.2 and Section 5). For these
reasons:=C2=A0

>>=C2=A0

>> o Bandwidth (transmission opportunities) not utilized by a
DetNet=C2=A0

>> flow is available to non-DetNet packets (though not to
other=C2=A0

>> DetNet flows).=C2=A0<=
br>
>>=C2=A0

>> o DetNet flows can be shaped or scheduled, in order to
ensure that=C2=A0

>> the highest-priority non-DetNet packet is also ensured a
worst-=C2=A0

>> case latency.=C2=A0
>>=C2=A0

>> o When transmission opportunities for DetNet flows are
scheduled in=C2=A0

>> detail, then the algorithm constructing the schedule
should leave=C2=A0

>> sufficient opportunities for non-DetNet packets to satisfy
the=C2=A0

>> needs of the users of the network. Detailed scheduling can
also=C2=A0

>> permit the time-shared use of buffer resources by
different DetNet=C2=A0

>> flows.=C2=A0

>>=C2=A0

>> Starvation of non-DetNet traffic must be avoided, e.g., by
traffic=C2=A0

>> policing functions (e.g., [RFC2475]). Thus, the net effect
of the=C2=A0

>> presence of DetNet flows in a network on the non-DetNet
flows is=C2=A0

>> primarily a reduction in the available
bandwidth.=C2=A0

>>=C2=A0

>>=C2=A0

>> I think we need a little bit more to understand what you'd
like to see changed or added. Can you suggest text or what specific
topic you'd like to see added/addressed?=C2=A0

>=C2=A0

> Yes, let me try to explain better=E2=80=A6while comparing with the
current=C2=A0

> text in =C2=A75, which basically says that even though the
objective of=C2=A0

> DetNet is to provide bounded latency, a MIIM may delay the
traffic and=C2=A0

> the objective may not be achieved.=C2=A0

>=C2=A0

> For non-DetNet traffic, the objective is to not starve it,
while=C2=A0

> providing specific guarantees to the DetNet flows =E2=80=94 said other
way=C2=A0

> (from the Introduction): "Unused reserved resources are
available to=C2=A0

> non-DetNet packets as long as all guarantees are fulfilled.=E2=80=9D
=C2=A0However,=C2=A0

> the algorithms (maybe error, misconfiguration=E2=80=A6or even
maliciously) may=C2=A0

> end up*not* constructing the schedule to leave
sufficient=C2=A0

> opportunities for non-DetNet packets (as suggested in the text
above=C2=A0

> from =C2=A73.3.1).=C2=A0<=
br>
>=C2=A0

> I see a parallel in how there is a risk of the intention for
DetNet=C2=A0

> flows not being met (because of an attack) and how the
intention for=C2=A0

> non-DetNet traffic may also not be met.=C2=A0

>=C2=A0

Okay, this sounds like basically the same point that Benjamin
was=C2=A0

making, i.e., there must be mechanisms preventing non-detnet
traffic=C2=A0

from impacting detnet traffic, and detnet traffic trying to use
more=C2=A0

than its allocation and impacting non-detnet traffic. Is this
correct or=C2=A0

are you asking for something different/additional?=C2=A0








Yes.=C2=A0 I=E2=80=99m not asking so much for a mechanism, but for at
least the recognition that it is a risk.




Fair enough- I expect the response a response for the
architecture and security draft authors to address this.=C2=A0 I'm
sure you will confirm that it does!





















>=C2=A0

>>> Related to the above is the fact that the
identification of flows could be used=
=C2=A0

>>> to specifically *not* include some of them as DetNet
flows. This is a=C2=A0

>>> variation of the concern outlined in =C2=A76, but applied
to non-DetNet flows, with=C2=A0

>>> the potential starvation mentioned above. Again, I
would like to at least see=C2=A0

>>> some discussion of this risk.=C2=A0

>>=C2=A0

>> I don't follow - what is the risk that should be
addressed?=C2=A0

>>=C2=A0

> =C2=A76 talks about potential privacy concerns due to the
identification of=C2=A0

> flows.=C2=A0 I interpret that as potentially being able to
identify the=C2=A0

> user (application, or both maybe).=C2=A0

>=C2=A0

Currently flow identification is based on IP headers (6 tuple)
and/or=C2=A0

MPLS labels.=C2=A0 So DetNet has the same privacy concerns as
standard IP/MPLS.=C2=A0





> As far as I understand the architecture, DetNet flows are
identified=C2=A0

> at the edge and then assigned to specific paths.=C2=A0 If
the=C2=A0

> identification of flows can be used to identify the user
(for=C2=A0

> example), then it can be used to not only attack specific
DetNet flow,=C2=A0

> but also to decide to not provide guarantees to a specific
flow based=C2=A0

> on who the user or the application may be.=C2=A0

>=C2=A0

Given DetNet flow identification, is this any different than
standard PBR?=C2=A0







Right, it is not really different.=C2=A0 It is just not
mentioned anywhere that identification (or misidentification as it
may be, maybe maliciously) can lead to not providing guarantees,
potential starving, etc..






I thought the quotes capture in the various mails on the topic
showed how it was -- but let's wait for the updated text and see if
it sufficiently addresses your concern/point, and then go from
there.


Thanks again for the feedback.


Lou









Thanks!


Alvaro.








______________________________________________=
_
detnet mailing list
detne=
t@ietf.org
https://www.ietf.org/mailman/listinfo/detnet











 


--00000000000096cfcb0584ef7d8f--


From nobody Mon Mar 25 14:54: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 B3841120115 for ; Mon, 25 Mar 2019 14:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.041
X-Spam-Level: 
X-Spam-Status: No, score=-4.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc81P1ZmdaMT for ; Mon, 25 Mar 2019 14:54:34 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627B7120118 for ; Mon, 25 Mar 2019 14:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553550866; x=1556142866; 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=KIOiIzQkAfDe/kqEQI835+P8UlL0x8OqduPgj+BdJp8=; b=VmGubeRJrWoXlaPi0D7jVlyiqymSNLkThYGDFvpjCX+sS8C2PtfyF4+PIVxbtL6o XpV24Vbx1ya38SsdtFMETp0apZ48bMRGgUKI7LuvxJu4F+QzyY9w89FpUQ4EQPf2 pENuoqqmpo/T/PrXGXeoo4J6c6Pgsrw1DnKPoILSD+g=;
X-AuditID: c1b4fb30-307ff70000007fec-72-5c994e123eb4
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.4D.32748.21E499C5; Mon, 25 Mar 2019 22:54:26 +0100 (CET)
Received: from ESESSMB505.ericsson.se (153.88.183.166) 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.1713.5; Mon, 25 Mar 2019 22:54:26 +0100
Received: from [100.94.33.129] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.193) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 25 Mar 2019 22:54:25 +0100
To: Alvaro Retana 
CC: , Lou Berger ,  The IESG , , 
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>   <150fb3c5-0f60-8426-0345-a17d9be984b9@ericsson.com> <06a42687-5942-2591-4c71-5a5ff5090474@ericsson.com> 
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: 
Date: Mon, 25 Mar 2019 22:54:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DD7402E23A5BAE782928CC37"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbG9TFfIb2aMwds7whY3Dm1gsrjW/4PF 4ven2SwWH77NZLGY8Wcis0VH81sWBzaPnbPusnssWfKTyePDpma2AOYoLpuU1JzMstQifbsE roxla0+zFNztYK64vJO9gfHPW8YuRg4OCQETibv3dLoYuTiEBI4wSlw7uJgZwvnGKPHv7E9m uMymFztZuhg5OYQFCiS+Hm1gB7FFBLQkbu/cyQ5SxCwwlVFi/sfjbBAdS1gkLr9+yAxSxSZg L3H30gYwmxfIbmvezAKym0VAVeLrgxqQsKhArMSnK4uhSgQlTs58AraMUyBQ4szrb2BxZoEw icd/JrBA2OISt57MZwKxhQTUJD69fcg+gVFwFpL2WUhaZiFpgbAtJGbOP88IYctLNG+dzQxh a0i0zpnLjiy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgHB3c8ttgB+PL546HGAU4 GJV4eE1dZ8YIsSaWFVfmHmKU4GBWEuF9IjojRog3JbGyKrUoP76oNCe1+BCjNAeLkjjvHyHB GCGB9MSS1OzU1ILUIpgsEwenVAOjV6H9HKmVqVoF0Ze3/mZ4yrlUxSHX2PucU8SEV7eTFSYs rij40huy77nDrEXC7fnHP5Udr4jWFBOXXr91zdrpK76VPor+dGZisoXy55My+556ajednRdV JFRwf9GGz8usGBdH88fJ/epYxpu7Syd47flDh5Jm/q9J8uZ5+Lh20YTZuxVFEv+9UWIpzkg0 1GIuKk4EAHFIPumfAgAA
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:54:38 -0000

--------------DD7402E23A5BAE782928CC37
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Thank you Alvaro!
Janos


On 3/25/2019 7:37 PM, Alvaro Retana wrote:
> János:
>
> Hi!
>
> Yes…I’m happy with the changes.  I’m clearing my DISCUSS.
>
> Thanks!
>
> Alvaro.
>
> On March 25, 2019 at 5:20:37 PM, János Farkas 
> (janos.farkas@ericsson.com ) wrote:
>
>> Hi Alvaro,
>>
>> We believe that we have addressed your comments in the most recent 
>> revision: 
>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
>> (https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)
>>
>> Please let us know what else you would like to see done before you 
>> clear your DISCUSS.
>>
>> I/we would be happy to meet with you this week if there is anything 
>> you would like to discuss.
>>
>> Regards,
>> Janos
>>
>>
>> On 3/6/2019 6:56 AM, János Farkas wrote:
>>> Hi Alvaro,
>>>
>>> Do the updates we are making the security section resolve your comments:
>>> https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
>>>
>>> The current proposed text:
>>>
>>> 5.  Security Considerations
>>>
>>>    Security considerations for DetNet are described in detail in
>>>    [I-D.ietf-detnet-security].  This section considers exclusively
>>>    security considerations which are specific to the DetNet
>>>    Architecture.
>>>
>>>    Security aspects which are unique to DetNet are those whose aim is to
>>>    provide the specific quality of service aspects of DetNet, which are
>>>    primarily to deliver data flows with extremely low packet loss rates
>>>    and bounded end-to-end delivery latency.  A DetNet may be implemented
>>>    using MPLS and/or IP (including both v4 and v6) technologies, and
>>>    thus inherits the security properties of those technologies at both
>>>    the control plane and the data plane.
>>>
>>>    Security considerations for DetNet are constrained (compared to, for
>>>    example, the open Internet) because DetNet is defined to operate only
>>>    within a single administrative domain (see Section 1).  The primary
>>>    considerations are to secure the request and control of DetNet
>>>    resources, maintain confidentiality of data traversing the DetNet,
>>>    and provide the availability of the DetNet quality of service.
>>>
>>>    To secure the request and control of DetNet resources, authentication
>>>    and authorization can be used for each device connected to a DetNet
>>>    domain, most importantly to network controller devices.  Control of a
>>>    DetNet network may be centralized or distributed (within a single
>>>    administrative domain).  In the case of centralized control,
>>>    precedent for security considerations as defined for Abstraction and
>>>    Control of Traffic Engineered Networks (ACTN) can be found in
>>>    [RFC8453], Section 9.  In the case of a distributed control
>>>    protocols, DetNet security is expected to be provided by the security
>>>    properties of the protocols in use.  In any case, the result is that
>>>    manipulation of administratively configurable parameters is limited
>>>    to authorized entities.
>>>
>>>    To maintain confidentiality of data traversing the DetNet,
>>>    application flows can be protected through whatever means is provided
>>>    by the underlying technology.  For example, encryption may be used,
>>>    such as that provided by IPSec [RFC4301] for IP (Layer 3) flows and
>>>    by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.
>>>
>>>    DetNet flows are identified on a per-flow basis, which may provide
>>>    attackers with additional information about the data flows (when
>>>    compared to networks that do not include per-flow identification).
>>>    This is an inherent property of DetNet which has security
>>>    implications which should be considered when determining if DetNet is
>>>    a suitable technology for any given use case.
>>>
>>>    To provide uninterrupted availability of the DetNet quality of
>>>    service, provisions can be made against DOS attacks and delay
>>>    attacks.  To protect against DOS attacks, excess traffic due to
>>>    malicious or malfunctioning devices can be prevented or mitigated,
>>>    for example through the use of traffic admission control applied at
>>>    the input of a DetNet domain, as described in Section 3.2.1, and
>>>    through the fault mitigation methods described in Section 3.3.2.  To
>>>    prevent DetNet packets from being delayed by an entity external to a
>>>    DetNet domain, DetNet technology definition can allow for the
>>>    mitigation of Man-In-The-Middle attacks, for example through use of
>>>    authentication and authorization of devices within the DetNet domain.
>>>
>>>    Because DetNet mechanisms or applications that rely on DetNet can
>>>    make heavy use of methods that require precise time synchronization,
>>>    the accuracy, availability, and integrity of time synchronization is
>>>    of critical importance.  Extensive discussion of this topic can be
>>>    found in [RFC7384].
>>>
>>>    DetNet use cases are known to have widely divergent security
>>>    requirements.  The intent of this section is to provide a baseline
>>>    for security considerations which are common to all DetNet designs
>>>    and implementations, without burdening individual designs with
>>>    specifics of security infrastructure which may not be germane to the
>>>    given use case.  Designers and Implementers of DetNet systems are
>>>    expected to take use case specific considerations into account in
>>>    their DetNet designs and implementations.
>>>
>>>
>>> Please let us know if you have any remaining comments and what they are.
>>>
>>> Thank you!
>>> Janos
>>>
>>>
>>> On 2/23/2019 9:39 PM, Lou Berger wrote:
>>>>
>>>> Hi *Alvaro*,
>>>>
>>>> see below.
>>>>
>>>> On 2/22/2019 6:02 AM, Alvaro Retana wrote:
>>>>> On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net 
>>>>> ) wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>>> >>> ----------------------------------------------------------------------
>>>>>> >>> DISCUSS:
>>>>>> >>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> >>>
>>>>>> >>> I support Mirja's and Alissa's DISCUSSes...and have a related 
>>>>>> set of concerns
>>>>>> >>> about the coexistence with non-DetNet traffic and privacy:
>>>>>> >>>
>>>>>> >>> §3.3.1 talks about what I think is a hard to achieve balance 
>>>>>> between coexisting
>>>>>> >>> with non-DetNet traffic and keeping that traffic from 
>>>>>> disrupting DetNet flows.
>>>>>> >>> Because of the constraints, the intent of prioritizing DetNet 
>>>>>> flows is clear
>>>>>> >>> (and that is ok), but that may result in starvation of non-DetNet
>>>>>> >>> traffic...even if the text does explicitly say that it "must 
>>>>>> be avoided".
>>>>>> >>>
>>>>>> >>> I would like to see the potential case of starving non-DetNet 
>>>>>> traffic called
>>>>>> >>> out somewhere.
>>>>>> >>
>>>>>> >> This is the objective of section 3.3.1..
>>>>>> >>
>>>>>> >>
>>>>>> >>> I'm looking for something similar to the first paragraph in §5,
>>>>>> >>> but focused on the non-DetNet traffic.
>>>>>> >>
>>>>>> >> The current text reads:
>>>>>> >>
>>>>>> >> 3.3.1. Coexistence with normal traffic
>>>>>> >>
>>>>>> >> A DetNet network supports the dedication of a high proportion 
>>>>>> of the
>>>>>> >> network bandwidth to DetNet flows. But, no matter how much is
>>>>>> >> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>>>>>> >> existing Class of Service schemes (e.g., DiffServ). It is also
>>>>>> >> important that non-DetNet traffic not disrupt the DetNet flow, of
>>>>>> >> course (see Section 3.3.2 and Section 5). For these reasons:
>>>>>> >>
>>>>>> >> o Bandwidth (transmission opportunities) not utilized by a DetNet
>>>>>> >> flow is available to non-DetNet packets (though not to other
>>>>>> >> DetNet flows).
>>>>>> >>
>>>>>> >> o DetNet flows can be shaped or scheduled, in order to ensure that
>>>>>> >> the highest-priority non-DetNet packet is also ensured a worst-
>>>>>> >> case latency.
>>>>>> >>
>>>>>> >> o When transmission opportunities for DetNet flows are 
>>>>>> scheduled in
>>>>>> >> detail, then the algorithm constructing the schedule should leave
>>>>>> >> sufficient opportunities for non-DetNet packets to satisfy the
>>>>>> >> needs of the users of the network. Detailed scheduling can also
>>>>>> >> permit the time-shared use of buffer resources by different DetNet
>>>>>> >> flows.
>>>>>> >>
>>>>>> >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>>>> >> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>>>>>> >> presence of DetNet flows in a network on the non-DetNet flows is
>>>>>> >> primarily a reduction in the available bandwidth.
>>>>>> >>
>>>>>> >>
>>>>>> >> I think we need a little bit more to understand what you'd 
>>>>>> like to see changed or added. Can you suggest text or what 
>>>>>> specific topic you'd like to see added/addressed?
>>>>>> >
>>>>>> > Yes, let me try to explain better…while comparing with the current
>>>>>> > text in §5, which basically says that even though the objective of
>>>>>> > DetNet is to provide bounded latency, a MIIM may delay the 
>>>>>> traffic and
>>>>>> > the objective may not be achieved.
>>>>>> >
>>>>>> > For non-DetNet traffic, the objective is to not starve it, while
>>>>>> > providing specific guarantees to the DetNet flows — said other way
>>>>>> > (from the Introduction): "Unused reserved resources are 
>>>>>> available to
>>>>>> > non-DetNet packets as long as all guarantees are fulfilled.” 
>>>>>>  However,
>>>>>> > the algorithms (maybe error, misconfiguration…or even 
>>>>>> maliciously) may
>>>>>> > end up*not* constructing the schedule to leave sufficient
>>>>>> > opportunities for non-DetNet packets (as suggested in the text 
>>>>>> above
>>>>>> > from §3.3.1).
>>>>>> >
>>>>>> > I see a parallel in how there is a risk of the intention for DetNet
>>>>>> > flows not being met (because of an attack) and how the 
>>>>>> intention for
>>>>>> > non-DetNet traffic may also not be met.
>>>>>> >
>>>>>> Okay, this sounds like basically the same point that Benjamin was
>>>>>> making, i.e., there must be mechanisms preventing non-detnet traffic
>>>>>> from impacting detnet traffic, and detnet traffic trying to use more
>>>>>> than its allocation and impacting non-detnet traffic. Is this 
>>>>>> correct or
>>>>>> are you asking for something different/additional?
>>>>>
>>>>> Yes.  I’m not asking so much for a mechanism, but for at least the 
>>>>> recognition that it is a risk.
>>>>>
>>>> Fair enough- I expect the response a response for the architecture 
>>>> and security draft authors to address this.  I'm sure you will 
>>>> confirm that it does!
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> >
>>>>>> >>> Related to the above is the fact that the identification of 
>>>>>> flows could be used
>>>>>> >>> to specifically *not* include some of them as DetNet flows. 
>>>>>> This is a
>>>>>> >>> variation of the concern outlined in §6, but applied to 
>>>>>> non-DetNet flows, with
>>>>>> >>> the potential starvation mentioned above. Again, I would like 
>>>>>> to at least see
>>>>>> >>> some discussion of this risk.
>>>>>> >>
>>>>>> >> I don't follow - what is the risk that should be addressed?
>>>>>> >>
>>>>>> > §6 talks about potential privacy concerns due to the 
>>>>>> identification of
>>>>>> > flows.  I interpret that as potentially being able to identify the
>>>>>> > user (application, or both maybe).
>>>>>> >
>>>>>> Currently flow identification is based on IP headers (6 tuple) and/or
>>>>>> MPLS labels.  So DetNet has the same privacy concerns as standard 
>>>>>> IP/MPLS.
>>>>>>
>>>>>>
>>>>>> > As far as I understand the architecture, DetNet flows are 
>>>>>> identified
>>>>>> > at the edge and then assigned to specific paths.  If the
>>>>>> > identification of flows can be used to identify the user (for
>>>>>> > example), then it can be used to not only attack specific 
>>>>>> DetNet flow,
>>>>>> > but also to decide to not provide guarantees to a specific flow 
>>>>>> based
>>>>>> > on who the user or the application may be.
>>>>>> >
>>>>>> Given DetNet flow identification, is this any different than 
>>>>>> standard PBR?
>>>>>
>>>>> Right, it is not really different.  It is just not mentioned 
>>>>> anywhere that identification (or misidentification as it may be, 
>>>>> maybe maliciously) can lead to not providing guarantees, potential 
>>>>> starving, etc..
>>>>>
>>>> I thought the quotes capture in the various mails on the topic 
>>>> showed how it was -- but let's wait for the updated text and see if 
>>>> it sufficiently addresses your concern/point, and then go from there.
>>>>
>>>> Thanks again for the feedback.
>>>>
>>>> Lou
>>>>
>>>>
>>>>> Thanks!
>>>>>
>>>>> Alvaro.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> detnet mailing list
>>>>> detnet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>
>>


--------------DD7402E23A5BAE782928CC37
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Thank you Alvaro!

    Janos

    

    

    
On 3/25/2019 7:37 PM, Alvaro Retana
      wrote:

    

    

      
      
      
János:

      


      

      
Hi!

      


      

      
Yes…I’m
        happy with the changes.  I’m clearing my DISCUSS.

      


      

      
Thanks!

      


      

      
Alvaro.

      

      
On March 25, 2019 at 5:20:37 PM, János
        Farkas (janos.farkas@ericsson.com) wrote:

      

          

            

              
              Hi Alvaro,

              

              We believe that we have addressed your comments in the
              most recent
              revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12.
              (https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

              

              Please let us know what else you would like to see done
              before you
              clear your DISCUSS.

              

              I/we would be happy to meet with you this week if there is
              anything
              you would like to discuss.

              

              Regards,

              Janos

              

              

              
On 3/6/2019 6:56 AM, János
                Farkas
                wrote:

              

              

                Hi Alvaro,

                

                Do the updates we are making the security section
                resolve your
                comments:

                https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o

                

                The current proposed text:

                

                5.  Security Considerations

                

                   Security considerations for DetNet are described in
                detail in

                   [I-D.ietf-detnet-security].  This section
                considers exclusively

                   security considerations which are specific to the
                DetNet

                   Architecture.

                

                   Security aspects which are unique to DetNet are those
                whose aim is to

                   provide the specific quality of service aspects of
                DetNet, which are

                   primarily to deliver data flows with extremely low
                packet loss rates

                   and bounded end-to-end delivery latency.  A
                DetNet may be implemented

                   using MPLS and/or IP (including both v4 and v6)
                technologies, and

                   thus inherits the security properties of those
                technologies at both

                   the control plane and the data plane.

                

                   Security considerations for DetNet are constrained
                (compared to, for

                   example, the open Internet) because DetNet is defined
                to operate only

                   within a single administrative domain (see Section
                1).  The primary

                   considerations are to secure the request and control
                of DetNet

                   resources, maintain confidentiality of data
                traversing
                the DetNet,

                   and provide the availability of the DetNet quality of
                service.

                

                   To secure the request and control of DetNet
                resources,
                authentication

                   and authorization can be used for each device
                connected to a DetNet

                   domain, most importantly to network controller
                devices.  Control of a

                   DetNet network may be centralized or distributed
                (within a single

                   administrative domain).  In the case of
                centralized control,

                   precedent for security considerations as defined for
                Abstraction and

                   Control of Traffic Engineered Networks (ACTN) can be
                found in

                   [RFC8453], Section 9.  In the case of a
                distributed control

                   protocols, DetNet security is expected to be provided
                by the security

                   properties of the protocols in use.  In any case,
                the result is that

                   manipulation of administratively configurable
                parameters is limited

                   to authorized entities.

                

                   To maintain confidentiality of data traversing the
                DetNet,

                   application flows can be protected through whatever
                means is provided

                   by the underlying technology.  For example,
                encryption may be used,

                   such as that provided by IPSec [RFC4301] for IP
                (Layer
                3) flows and

                   by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2)
                flows.

                

                   DetNet flows are identified on a per-flow basis,
                which
                may provide

                   attackers with additional information about the data
                flows (when

                   compared to networks that do not include per-flow
                identification).

                   This is an inherent property of DetNet which has
                security

                   implications which should be considered when
                determining if DetNet is

                   a suitable technology for any given use case.

                

                   To provide uninterrupted availability of the DetNet
                quality of

                   service, provisions can be made against DOS attacks
                and delay

                   attacks.  To protect against DOS attacks, excess
                traffic due to

                   malicious or malfunctioning devices can be prevented
                or mitigated,

                   for example through the use of traffic admission
                control applied at

                   the input of a DetNet domain, as described in Section
                3.2.1, and

                   through the fault mitigation methods described in
                Section 3.3.2.  To

                   prevent DetNet packets from being delayed by an
                entity
                external to a

                   DetNet domain, DetNet technology definition can allow
                for the

                   mitigation of Man-In-The-Middle attacks, for example
                through use of

                   authentication and authorization of devices within
                the
                DetNet domain.

                

                   Because DetNet mechanisms or applications that rely
                on
                DetNet can

                   make heavy use of methods that require precise time
                synchronization,

                   the accuracy, availability, and integrity of time
                synchronization is

                   of critical importance.  Extensive discussion of
                this topic can be

                   found in [RFC7384].

                

                   DetNet use cases are known to have widely divergent
                security

                   requirements.  The intent of this section is to
                provide a baseline

                   for security considerations which are common to all
                DetNet designs

                   and implementations, without burdening individual
                designs with

                   specifics of security infrastructure which may not be
                germane to the

                   given use case.  Designers and Implementers of
                DetNet systems are

                   expected to take use case specific considerations
                into
                account in

                   their DetNet designs and implementations.

                

                

                Please let us know if you have any remaining comments
                and what they
                are.

                

                Thank you!

                Janos

                

                

                
On 2/23/2019 9:39 PM, Lou
                  Berger
                  wrote:

                

                

                  
Hi *Alvaro*,

                  
see below.

                  

                  
On 2/22/2019 6:02 AM,
                    Alvaro Retana
                    wrote:

                  

                  

                    
On
                      February
                      21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net)
                      wrote:

                    

                      

                    

                    
Hi!

                    

                      

                    

                    

                      

                        

                          
>>>
---------------------------------------------------------------------- 

                              >>> DISCUSS: 

                              >>>
---------------------------------------------------------------------- 

                              >>> 

                              >>> I support Mirja's and
                              Alissa's DISCUSSes...and have a
                              related set of concerns 

                              >>> about the coexistence with
                              non-DetNet traffic and
                              privacy: 

                              >>> 

                              >>> §3.3.1 talks about what I
                              think is a hard to achieve
                              balance between coexisting 

                              >>> with non-DetNet traffic and
                              keeping that traffic from
                              disrupting DetNet flows. 

                              >>> Because of the constraints,
                              the intent of prioritizing
                              DetNet flows is clear 

                              >>> (and that is ok), but that
                              may result in starvation of
                              non-DetNet 

                              >>> traffic...even if the text
                              does explicitly say that it
                              "must be avoided". 

                              >>> 

                              >>> I would like to see the
                              potential case of starving
                              non-DetNet traffic called 

                              >>> out somewhere. 

                              >> 

                              >> This is the objective of section
                              3.3.1.. 

                              >> 

                              >> 

                              >>> I'm looking for something
                              similar to the first
                              paragraph in §5, 

                              >>> but focused on the non-DetNet
                              traffic. 

                              >> 

                              >> The current text reads: 

                              >> 

                              >> 3.3.1. Coexistence with normal
                              traffic 

                              >> 

                              >> A DetNet network supports the
                              dedication of a high
                              proportion of the 

                              >> network bandwidth to DetNet
                              flows. But, no matter how much
                              is 

                              >> dedicated for DetNet flows, it is
                              a goal of DetNet to
                              coexist with 

                              >> existing Class of Service schemes
                              (e.g., DiffServ). It is
                              also 

                              >> important that non-DetNet traffic
                              not disrupt the DetNet
                              flow, of 

                              >> course (see Section 3.3.2 and
                              Section 5). For these
                              reasons: 

                              >> 

                              >> o Bandwidth (transmission
                              opportunities) not utilized by a
                              DetNet 

                              >> flow is available to non-DetNet
                              packets (though not to
                              other 

                              >> DetNet flows). 

                              >> 

                              >> o DetNet flows can be shaped or
                              scheduled, in order to
                              ensure that 

                              >> the highest-priority non-DetNet
                              packet is also ensured a
                              worst- 

                              >> case latency. 

                              >> 

                              >> o When transmission opportunities
                              for DetNet flows are
                              scheduled in 

                              >> detail, then the algorithm
                              constructing the schedule
                              should leave 

                              >> sufficient opportunities for
                              non-DetNet packets to satisfy
                              the 

                              >> needs of the users of the
                              network. Detailed scheduling can
                              also 

                              >> permit the time-shared use of
                              buffer resources by
                              different DetNet 

                              >> flows. 

                              >> 

                              >> Starvation of non-DetNet traffic
                              must be avoided, e.g., by
                              traffic 

                              >> policing functions (e.g.,
                              [RFC2475]). Thus, the net effect
                              of the 

                              >> presence of DetNet flows in a
                              network on the non-DetNet
                              flows is 

                              >> primarily a reduction in the
                              available
                              bandwidth. 

                              >> 

                              >> 

                              >> I think we need a little bit more
                              to understand what you'd
                              like to see changed or added. Can you
                              suggest text or what specific
                              topic you'd like to see added/addressed? 

                              > 

                              > Yes, let me try to explain
                              better…while comparing with the
                              current 

                              > text in §5, which basically says that
                              even though the
                              objective of 

                              > DetNet is to provide bounded latency,
                              a MIIM may delay the
                              traffic and 

                              > the objective may not be achieved. 

                              > 

                              > For non-DetNet traffic, the objective
                              is to not starve it,
                              while 

                              > providing specific guarantees to the
                              DetNet flows — said other
                              way 

                              > (from the Introduction): "Unused
                              reserved resources are
                              available to 

                              > non-DetNet packets as long as all
                              guarantees are fulfilled.”
                               However, 

                              > the algorithms (maybe error,
                              misconfiguration…or even
                              maliciously) may 

                              > end up*not* constructing the schedule
                              to leave
                              sufficient 

                              > opportunities for non-DetNet packets
                              (as suggested in the text
                              above 

                              > from §3.3.1). 

                              > 

                              > I see a parallel in how there is a
                              risk of the intention for
                              DetNet 

                              > flows not being met (because of an
                              attack) and how the
                              intention for 

                              > non-DetNet traffic may also not be
                              met. 

                              > 

                              Okay, this sounds like basically the same
                              point that Benjamin
                              was 

                              making, i.e., there must be mechanisms
                              preventing non-detnet
                              traffic 

                              from impacting detnet traffic, and detnet
                              traffic trying to use
                              more 

                              than its allocation and impacting
                              non-detnet traffic. Is this
                              correct or 

                              are you asking for something
                              different/additional? 

                        

                      

                    

                    
Yes.  I’m not asking so much for a mechanism, but
                      for at
                      least the recognition that it is a risk.

                  

                  
Fair enough- I expect the response a response for
                    the
                    architecture and security draft authors to address
                    this.  I'm
                    sure you will confirm that it does!

                  


                  

                  

                    

                      

                        

                          

                            


                                

                                

                                > 

                                >>> Related to the above is the
                                fact that the
                                identification of flows could be used 

                                >>> to specifically *not*
                                include some of them as DetNet
                                flows. This is a 

                                >>> variation of the concern
                                outlined in §6, but applied
                                to non-DetNet flows, with 

                                >>> the potential starvation
                                mentioned above. Again, I
                                would like to at least see 

                                >>> some discussion of this
                                risk. 

                                >> 

                                >> I don't follow - what is the
                                risk that should be
                                addressed? 

                                >> 

                                > §6 talks about potential privacy
                                concerns due to the
                                identification of 

                                > flows.  I interpret that as
                                potentially being able to
                                identify the 

                                > user (application, or both maybe). 

                                > 

                                Currently flow identification is based
                                on IP headers (6 tuple)
                                and/or 

                                MPLS labels.  So DetNet has the same
                                privacy concerns as
                                standard IP/MPLS. 

                                

                                

                                > As far as I understand the
                                architecture, DetNet flows are
                                identified 

                                > at the edge and then assigned to
                                specific paths.  If
                                the 

                                > identification of flows can be used
                                to identify the user
                                (for 

                                > example), then it can be used to
                                not only attack specific
                                DetNet flow, 

                                > but also to decide to not provide
                                guarantees to a specific
                                flow based 

                                > on who the user or the application
                                may be. 

                                > 

                                Given DetNet flow identification, is
                                this any different than
                                standard PBR? 

                          

                        

                      

                      
Right, it is not really different.  It is just
                        not
                        mentioned anywhere that identification (or
                        misidentification as it
                        may be, maybe maliciously) can lead to not
                        providing guarantees,
                        potential starving, etc..

                    

                  

                  
I thought the quotes capture in the various mails
                    on the topic
                    showed how it was -- but let's wait for the updated
                    text and see if
                    it sufficiently addresses your concern/point, and
                    then go from
                    there.

                  

                  
Thanks again for the feedback.

                  
Lou

                  

                  


                  

                  

                    

                      
Thanks!

                      
Alvaro.

                    

                    

                    

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


                  

                

                

              

              

            

          

        

    

    

  


--------------DD7402E23A5BAE782928CC37--


From nobody Mon Mar 25 15:05: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 97E5D120005; Mon, 25 Mar 2019 15:05:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <155355152658.24060.7298772715857679557.idtracker@ietfa.amsl.com>
Date: Mon, 25 Mar 2019 15:05:26 -0700
Archived-At: 
Subject: [Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-architecture-12: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:05:27 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-architecture-12: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss point!
The new security considerations section is well-written and quite well matched
to an architecture document.



From nobody Mon Mar 25 16:47:03 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 EE2C812017A for ; Mon, 25 Mar 2019 16:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79YKXe9kt497 for ; Mon, 25 Mar 2019 16:46:50 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAAC120186 for ; Mon, 25 Mar 2019 16:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1553557606; x=1556149606; 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=Uvcxl8EuvyouCmspt2E4NpVI+pCsc8RTe7Pfnx0MPxM=; b=HVH3a+sDodZOH09syhdmdcB8HUJ8GHD8fr+Bee4GHrIBDEeD38YBWsm0YC62FBtB Sbd2dZf8UCm1lPY7UnbluKn2iPqGhUAU75Psfx202kQt3vbEt4AIXb1g66nUmqbE RvHLxsLdCvMLdgENWIgcOxFfimsA0eigq/qchYovvdY=;
X-AuditID: c1b4fb25-259ff7000000438b-05-5c996866e732
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.1C.17291.668699C5; Tue, 26 Mar 2019 00:46:46 +0100 (CET)
Received: from ESESBMR503.ericsson.se (153.88.183.135) 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.1713.5; Tue, 26 Mar 2019 00:46:45 +0100
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 26 Mar 2019 00:46:45 +0100
Received: from [100.94.33.129] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.187) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Tue, 26 Mar 2019 00:46:44 +0100
To: Benjamin Kaduk 
CC: The IESG , , "Lou Berger" , , 
References: <155355152658.24060.7298772715857679557.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <02e2c609-9154-5a34-6e77-a15c712a031d@ericsson.com>
Date: Tue, 26 Mar 2019 00:46:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <155355152658.24060.7298772715857679557.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2J7tW5axswYg86d/BbX+n+wWPz+NJvF 4sO3mSwWM/5MZLZYvnEmk0VH81sWBzaPJUt+Mnl82NTM5tF05ihzAHMUl01Kak5mWWqRvl0C V8acdwdZC1o5Kn5M/cHUwPiIrYuRk0NCwETi/KQu5i5GLg4hgSOMEgf3r2aDcL4xShy6sIwR pArMOXtDG8IGqjrxIQTEFhZIlFj++TY7iC0ioCSx+GwLWDOzwHRGic7Ds9kgGnwl5k07BDaI TcBe4u6lDcwgNi+QvfDiLqYuRg4OFgFViU3NFiBhUYFYiU9XFkOVCEqcnPmEBcTmFPCT2PSy EyzOLGAhMXP+eUYIW15i+9s5UHFxiVtP5jNBrFWTeN9wh3ECo/AsJKNmIWmfhaR9FpL2BYws qxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECY+Xglt+qOxgvv3E8xCjAwajEwxuZODNGiDWx rLgy9xCjBAezkgjvE9EZMUK8KYmVValF+fFFpTmpxYcYpTlYlMR5/wgJxggJpCeWpGanphak FsFkmTg4pRoY7Rd2a842uVf7Qn2Xj6mFNovhPyXD3Q2LI3veLxabtVVb3fqKj+9x9i17xWWv MbTaT22o+ZTglBkiGPBNKUvSScbjWlrB4gpPjWiPvEWzjs8LP2OpZWmd4Z9evXauZv6sn9Oj it+GsqUuc1Zw5lQ0+nxJLdXnvEowV5uwb8H5ZVPWijppXVdiKc5INNRiLipOBAAGMpV/kQIA AA==
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-architecture-12: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 23:46:52 -0000

Thank you Benjamin!
Janos

On 3/25/2019 11:05 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-detnet-architecture-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for addressing my Discuss point!
> The new security considerations section is well-written and quite well matched
> to an architecture document.
>
>


From nobody Wed Mar 27 04:37:12 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 AA8941202B9 for ; Wed, 27 Mar 2019 04:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 GWMUsyr_rLtL for ; Wed, 27 Mar 2019 04:36:46 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760094.outbound.protection.outlook.com [40.107.76.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2811202CE for ; Wed, 27 Mar 2019 04:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cfznnIPFYbUBRWoi0RMBlXiG+nQNBxozk/WT1URCOIo=; b=UFd8Vgb6f7DkIAvgb5GyXgiFLq0mhV95ePJGwVKzn/j5MQF7KvIVnG31NeGdeVAcMoRaVFtxv0hv+WkSpRiztRkxRgs8yb6Ppc9U1TctbUgorOkZ6ClZ+pbPm9rYOYQt4wJwtjxu6deErKiIVCf4lUN35+6skXXtSBRJ4Ukwqtc=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB5848.namprd06.prod.outlook.com (20.179.156.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Wed, 27 Mar 2019 11:36:42 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::b89f:9d03:a203:c6a4]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::b89f:9d03:a203:c6a4%2]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 11:36:42 +0000
From: "Grossman, Ethan A." 
To: DetNet WG , "aretana.ietf@gmail.com" , "kaduk@mit.edu" 
Thread-Topic: DetNet Security Side Meeting - Today, Wednesday, 5pm, Lobby
Thread-Index: AdTkh3RrZz9poC1FTAiJl5LtkxnWMQ==
Date: Wed, 27 Mar 2019 11:36:40 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTgwNzNmOTQ2LTUwODQtMTFlOS04NDc4LWFjYmMzMjdhNTFjNlxhbWUtdGVzdFw4MDczZjk0Ny01MDg0LTExZTktODQ3OC1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIxOTc4IiB0PSIxMzE5ODE2MDE2NDI5MDAwMzYiIGg9IkRWL3BOaVlMZHlVakQvajdPb3VHaDJLZ3Ezaz0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4=
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; 
x-originating-ip: [31.133.147.206]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5e21125b-aa96-44a7-57ca-08d6b2a87bd6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB5848; 
x-ms-traffictypediagnostic: BYAPR06MB5848:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(136003)(346002)(39850400004)(189003)(199004)(55016002)(4744005)(2420400007)(53936002)(6306002)(54896002)(97736004)(106356001)(6506007)(790700001)(6436002)(3846002)(102836004)(486006)(8936002)(256004)(99286004)(2201001)(14444005)(25786009)(9686003)(6116002)(476003)(71200400001)(71190400001)(26005)(68736007)(105586002)(7696005)(8676002)(2501003)(5660300002)(2171002)(66066001)(10710500007)(316002)(15650500001)(52536014)(186003)(478600001)(14454004)(33656002)(86362001)(2906002)(7736002)(110136005)(81156014)(81166006)(74316002)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB5848; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: YdTcSBCU/zejF2rv8mkhfHL/bBm8A8leVeIJKHLWsyn3+ynfp8gpIFnFNGsLl4ZMcrf+1K74Xo34W9cK2pFXivZQrwvljVMR4ocDtr/WmahR3mID2d55OPoL6R1hCCOkGSjebo2f0R0qpIT/SvgkxSeSsBYkc3MiGisB8xatC5UhpQxD/PxO33daaATzfxDgPsW6mO/89reLL8jsbGHAb+hBM8O9Qdw20q4QLQZqioGxQ4ML2VnfdDr1bcpScCMuPXms2cUqeqActp0CJ3HpR8fPmqafRiJjHsT/ja/gmfF0JG3+2QZkiUITXAjmrK4F2SkNZRieHve618QgSjIXlqQ/peyFPrKehTcbYp9XUITd0ma3uA7/G29CifepR0qpi0mKdjKH0aCU799ciLj7PgWfnxGtkYtU9AiAD+cmHYU=
Content-Type: multipart/alternative; boundary="_000_BYAPR06MB43252FCD62812123459A03E4C4580BYAPR06MB4325namp_"
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e21125b-aa96-44a7-57ca-08d6b2a87bd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 11:36:42.0007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5848
Archived-At: 
Subject: [Detnet] DetNet Security Side Meeting - Today, Wednesday, 5pm, Lobby
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, 27 Mar 2019 11:37:09 -0000

--_000_BYAPR06MB43252FCD62812123459A03E4C4580BYAPR06MB4325namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tal and I are going to meet at 5pm today (in the hotel lobby) to discuss po=
ssible next steps for the DetNet Security draft. If anyone else is availabl=
e to join us we would appreciate your presence. We realize this is overbook=
ed with the Plenary; presumably it won't need to be a very long discussion.=
..
Ethan.

--_000_BYAPR06MB43252FCD62812123459A03E4C4580BYAPR06MB4325namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Tal and I are going to meet at 5pm today (in the hot=
el lobby) to discuss possible next steps for the DetNet Security draft. If =
anyone else is available to join us we would appreciate your presence. We r=
ealize this is overbooked with the
 Plenary; presumably it won’t need to be a very long discussion... 


Ethan.






--_000_BYAPR06MB43252FCD62812123459A03E4C4580BYAPR06MB4325namp_--