From nobody Wed Jun 2 11:50:32 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA23A16B8; Wed, 2 Jun 2021 11:50:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-6man-spring-srv6-oam@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, =?utf-8?q?Ole_Tr=C3=B8an?= , ot@cisco.com, cjbc@it.uc3m.es, int-dir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162265982179.7171.18143660610237774178@ietfa.amsl.com> Date: Wed, 02 Jun 2021 11:50:22 -0700 Archived-At: Subject: [Int-dir] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-6man-spring-srv6-oam-11=3A_=28with_COMMENT=29?= X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 18:50:23 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-6man-spring-srv6-oam-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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Top posting: thank you for the quick fix on my two DISCUSS points (I told you there were easy to fix). I also like the added text to address Martin Duke's DISCUSS point. I kept the non-blocking COMMENT points below. ---- Thank you for the work put into this document. It is comforting (even if not surprising) that the simple "good old" ping/traceroute work on a SRv6 network ;-) Thanks to Carlos Bernardos for his INT-REVIEW at https://datatracker.ietf.org/doc/review-ietf-6man-spring-srv6-oam-10-intdir-telechat-bernardos-2021-05-28/ Thanks to Ole Trøan for his shepherd document even if I regret the lack of justification for 'standards track'. Especially, because the abstract is mainly about ping/traceroute, hence should be informational but the O-flag is indeed standard track. So, all in all, this is OK. Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Is there any reason not to follow RFC 5952 about IPv6 address representation? I.e., not using uppercase ;-) (you may use uppercase for the 'variable' such as k). I understand that changing the case is a long and cumbersome endeavor... This comment is of course non-blocking. About the O-flag, as this I-D is about OAM, I would have expected that the document specifies some operational recommendations, e.g., collecting statistics about O-flag processing: packet count, requests ignored, ... -- Section 1 -- In the first sentence, is it RFC 8402 or RFC 8754 ? -- Section 1.3 -- I was about to raise a DISCUSS on this one... the abstract and introduction is about SRv6 and this section uses network programming example with END.X. Suggest to either modify abstract / introduction to mention RFC 8986 or simplify the example by not using END.X (e.g., not mentioning END.X as the plain SRH adj-sid behavior is END.X -- no need IMHO to introduce the network programming nomenclature). -- Section 2.1 -- Not important and feel free to ignore, but, while telemetry operation is important for OAM, OAM is broader than plain "telemetry data collect and export" (IMHO). I would have preferred the use of 'telemetry marking' for example. But, I guess it is too late to change the O-flag into a T-flag ;-) In "packet header", is the layer-2 header included ? IPFIX can export layer-2 information, hence my question. Perhaps better to use "IP header" here ? -- Section 2.1.1 -- I was again about the raise a DISCUSS on this point, S01.1 appears to be applicable to SRH/RFC 8754 while the text about PSP is clearly about net-pgm/RFC 8986. How can we reconciliate this ? Finally, in the case of PSP, should the normative pseudo-code be changed by introducing another 'if' in the pseudo-code ? -- Section 3.1.1 -- The figure 2 seems to have an incoherent 'screen shot' as 2001:db8:A:5:: is used as the ping target but the output of the ping displays "B5::". What did I miss ? The node N4 is assumed to "performs the standard SRH processing" but later it needs to process a "PSP SID", which is not standard SRH RFC but in the net-pgm one. -- Section 3.2.1 -- I wonder whether "These ICMPv6 responses are IP routed." is really useful here as plain IP routing will be applied (or do you mean no using SRH in the reply?). The example uses "DA" while I would expect that this would be the "SA" of the received ICMP messages. But, this is cosmetic. -- Section 3.2.2 -- What is a "classic IPv6 node" ? I guess it is a 'non SRv6-capable node' => to be added in the terminology section ? -- Section 3.3 -- "The local OAM process sends a full or partial copy" it really smells like a postcard OAM while IPFIX can be used to send aggregated data, which is also very useful. All in all, if this is a local send to another process, then worth mentioning it. == NITS == -- Section 1.3 -- As figure 1 uses a double border for SRv6-capable nodes, let's mention it in the text. From nobody Sun Jun 13 16:07:09 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A95543A13B5; Sun, 13 Jun 2021 16:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bob Hinden via Datatracker To: Cc: draft-ietf-masque-ip-proxy-reqs.all@ietf.org, masque@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162362562652.8324.1391395975676318672@ietfa.amsl.com> Reply-To: Bob Hinden Date: Sun, 13 Jun 2021 16:07:06 -0700 Archived-At: Subject: [Int-dir] Intdir early review of draft-ietf-masque-ip-proxy-reqs-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 23:07:07 -0000 Reviewer: Bob Hinden Review result: Not Ready I'm reviewing the document as part of the Internet Directorate INTDIR). Note: I have not been following MASQUE, so I may be missing some context. 1.1 Conventions Is this necessary for an Informational Document that says it isn't going to be published as an RFC? 1.2 Definitions Suggest adding here (or to the Introduction that this will work with IPv6 and IPv4. 2.1 Consumer VPN Why "consumer VPN". Sounds like all VPN to me, and you don't describe any other type of VPNs. 2.2 Point to Point Connectivity This might be clearer if it's described in terms of two end-points, instead of two IP addresses. 2.3 Point to Network Connectivity How is this different from 2.1? 2.4 Network to Network Connectivity. If it is also called "a site to site VPN", suggest just calling it that. At a higher level, isn't this all just a VPN that runs over HTTP? 3.2 Proxying of IP Packets I didn't understand the part about extensions that may modify the packets. Wouldn't the break the basic idea? 3.4 IP assignment An IP range is usually described as a Prefix/length. Why not use this terminology like that is done in the next section. I am also not sure what the difference between this section and the next one. 3.6 Identity This needs work. I think you need to describe the requirements for an identifier, not just citing examples. I also don't like using email addresses, domains, or user name. 3.7 Transport Security s/run over a protocol/run over a transport/ 3.8 Flow control I didn't understand this. 3.9 Indistinguishability Perhaps call this "Privacy". 3.12 Statefulness This section doesn't say anything. If there are requirements, say what they are. 4.2 Reliable Tranmission of IP Packets IP Packets are not reliable. You can't change that. It's the transport protocols that create session reliability. I don't understand what this section is describing. 4.3 Configuration of Congestion and Flow Control Congestion and Flow Control mechanisms are very hard, and are part of transport protocols. I don't see how what is described here could work. 4.4 Data Transport Compression Suggest using an existing IP compression technique, do not invent another one. 6. Security Considerations Surely there are Security requirements for this. They need to be described here. From nobody Fri Jun 18 00:42:48 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A75353A40BE; Fri, 18 Jun 2021 00:42:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Pascal Thubert via Datatracker To: Cc: draft-ietf-ipwave-vehicular-networking.all@ietf.org, its@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162400216663.17839.1738900015320888640@ietfa.amsl.com> Reply-To: Pascal Thubert Date: Fri, 18 Jun 2021 00:42:46 -0700 Archived-At: Subject: [Int-dir] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 07:42:47 -0000 Reviewer: Pascal Thubert Review result: Not Ready Dear authors In summary: I read a number of very good drafts collated in one, from the use cases that very complete and ready to publish, to the architecture and protocol solution in section 4 that would require more work for completeness. There are multiple instances in the use cases where protocols are listed coming out of the blue, e.g., the references to OMNI that seem artificially spread regardless of the context of the section. OMNI is used throughout, both as an open ended toolbox, and as a carpet under which all problems can be hidden. Reading this doc, OMNI shows as an interface to a software mobile router, with multiple of the device physical interfaces connected to the mobile router. This makes the stack very simple as the complexity moves to the router. But now you have to implement the router. Presented as that, the OMNI router deserves its name, it’s indeed very rich; it seems to cover all forms of MANET (many to choose from) and NEMO (and all the MIP protocol family across address families), all the possible radio interfaces on which the ND problems go away by magic, and whatever else you want to put in there. Is that the intention? Instead of referring to OMNI for virtually anything, the doc should refer to MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP), draft-nordmark-intarea-ippl for split subnets, and draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and subnet models. And then you can say that all those components can be plugged in the OMNI router, and you can discuss which MANET and which MIP you want, including using OMNI’s built in mobility. Note that my objections are not against the OMNI design, it might be the perfect thing and I am already aware of use cases that could be served by a P2MP interface like OMNI in conjunction with RFC8505 on the P2P subinterfaces (recycling the high level design we’ve been shipping for IPv4 / frame relay for the last 30 years). My objection is of the way the draft uses [OMNI] as the magic wand that solves all the problems when what you really do is throw them over the fence. I’d rather you focus on problems and use cases, for which there’s excellent text, and indicate what needs to be done without making assumption on how the needful things will be solved. In agreement with a discussion on the 6MAN list, I’d suggest to split, keep all that’s use case and problem description and ship it, remove references to protocols envisioned in the solution, and start the work on architecture of the solution and the protocol applicability statements separately. An alternate would be to centralize the discussion on protocols to annex, and explain that protocol A or B could be envisioned in solution space because to over this gap or implement that function. In any fashion, the current text is not ready for publication as applicability statement, architecture and or/solution, so the related work should be removed from the main text. But I find it mostly ready for use case and problem statement, more below. Review: Abstract This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). >>> The document goes beyond that; there was actually a thread at 6MAN where Bob Hinden said “ This document says it is a problem statement, but then becomes a solution document. Might be better to cut it down to only the problem statement part. “ >>> Would you consider doing this? If not, why? Note: you may want to respond on 6MAN as well. >>> >>>I would have thought that the traditional steps of problem statement and applicability statement of existing work could be expected from IPWAVE too. >>> Please clarify the steps that you intend to follow next with this work. 1. Introduction >>> Very readable and informative section, many thanks! Along with these WAVE standards and C-V2X standards, regardless of a wireless access technology under the IP stack of a vehicle, vehicular networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/ ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extended Route Optimization (AERO) [RFC6706BIS]). >>> NEMO (RFC 3963) is not cited. Any reason why the vehicle would not transport a network? This document describes use cases and a problem statement about IPv6-based vehicular networking for ITS, which is named IPv6 Wireless Access in Vehicular Environments (IPWAVE). First, it introduces the use cases for using V2V, V2I, and V2X networking in ITS. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy), and then enumerates requirements for the extensions of those IPv6 protocols, which are tailored to IPv6-based vehicular networking. Thus, this document is intended to motivate development of key protocols for IPWAVE. >>> 2. Terminology >>> o IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a computer situated in a vehicle (e.g., car, bicycle, autobike, motor cycle, and a similar one) and a device (e.g., smartphone and IoT device). It has at least one IP interface that runs in IEEE 802.11-OCB and has an "OBU" transceiver. Also, it may have an IP interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. See the definition of the term "OBU" in [RFC8691]. >>> Can that be a router connecting multiple computers? 3. Use Cases >>> This is another great read and an enlightening section. Maybe mention in the abstract that the doc also covers use cases? Although a Layer-2 solution can provide a support for multihop communications in vehicular networks, the scalability issue related to multihop forwarding still remains when vehicles need to disseminate or forward packets toward multihop-away destinations. In addition, the IPv6-based approach for V2V as a network layer protocol can accommodate multiple radio technologies as MAC protocols, such as 5G V2X and DSRC. Therefore, the existing IPv6 protocol can be augmented through the addition of an Overlay Multilink Network (OMNI) Interface [OMNI] and/or protocol changes in order to support both wireless single-hop/multihop V2V communications and multiple radio technologies in vehicular networks. In such a way, vehicles can communicate with each other by V2V communications to share either an emergency situation or road hazard in a highway having multiple kinds of radio technologies, such as 5G V2X and DSRC. >>> This text appears in the middle of high level use case, with a crude list of protocols; this is not a place for it >>> On a 6MAN Thread, Brian Carpenter said that the above: “ is of concern regardless of the mention of OMNI. Does it mean "can be" or "needs to be"? This paragraph seems like a very short summary of a big problem area. At the end of page 13 there is some related discussion, which mentions RPL as part of the solution (good choice, IMHO) but again seems to depend on OMNI. I don't think the fix of simply removing references to OMNI works, because it would leave a gap. In an informational document, that is not a formal problem but as far as this draft describes architecture, I don't think that big a gap is reasonable. "OMNI" is mentioned more than 20 times in the document. There are also several references to AERO, which is strongly associated with OMNI. “ >>> I agree with Brian. Here the document seems to be mixing solution with problem and putting the cart before the horse. My recommendation is to stick to what needs to be done that IPv6 does not do yet -the reqs and gaps-; but the doc should not step in the how things will be done unless the group already decided to do it. The logical next steps to a PS are an applicability statement of existing work, and if the gaps cannot be filled, there may be one or more WG chartered to fill those gaps. >>> I’d still be happy to see an annex with leads on where the solution might come from like RFC 8691 does. The existing IPv6 protocol must be augmented through the addition of an OMNI interface and/or protocol changes in order to support wireless multihop V2I communications in a highway where RSUs are sparsely deployed, so a vehicle can reach the wireless coverage of an RSU through the multihop data forwarding of intermediate vehicles. Thus, IPv6 needs to be extended for multihop V2I communications. >>> Note that I have no clue on how well OMNI applies in that space, maybe it does very well; but here it comes out of the blue with no justification. If you mention OMNI you need to detail what it is and which of the V2V problems you expect it to solve. But then, that’s beyond the scope of a PS. The existing IPv6 protocol must be augmented through the addition of an OMNI interface and/or protocol changes in order to support wireless multihop V2X (or V2I2X) communications in an urban road network where RSUs are deployed at intersections, so a vehicle (or a pedestrian's smartphone) can reach the wireless coverage of an RSU through the multihop data forwarding of intermediate vehicles (or pedestrians' smartphones). Thus, IPv6 needs to be extended for multihop V2X (or V2I2X) communications. >>> Please be more specific on what the missing functions are and whether they are missing from the stack development standpoint or if there’s work needed from the IETF. 1) If something is really missing in our specs, the text to prove from the use case above is missing 2) how OMNI serves the use case could be elaborated in an applicability statement of OMNI for V2xyz, but it is a bit blunt to present it as panacea when the problems to be solved are not listed. 3) If you look at it, OMNI seems like a software mobile router within a bump in the stack. Can that become too big? >>> my view is that the text above and the similar occasions should be replaced by something like : The existing IPv6 protocol must be augmented to provide the following functions: 1) … >>> and / or something like: In addition to the IPv6 node requirements [RFC 8504], the IPv6 protocol stack for use in a vehicle must support 1) RFC blah, 2) … To support applications of these V2X use cases, the functions of IPv6 such as VND, VMM, and VSP are prerequisites for IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a pedestrian either directly or indirectly via an IP-RSU. >>> “the functions of IPv6 such as VND, VMM, and VSP” does not parse. There’s no IPv6 reference that provides those functions. If the intention is to say that there’s stuff to add to IPv6 to support, like, say, VND, then this document fails to define how an IPv6 VND should behave, though it’s precisely what I’d expect from a problem statement. 4. Vehicular Networks >>> What is the purpose of section 4 as a whole, problem statement or applicability statement of the listed protocols? In the former case what’s the problem? In the latter case it is incomplete and needs to be exported to an applicability statement doc with all the possible technologies evaluated. This section describes an example vehicular network architecture supporting V2V, V2I, and V2X communications in vehicular networks. >>> I read this as presenting a context to explain what the problems are instead of presenting the IPVAWE “architecture”. Maybe using the term “Architecture” here is misleading and led to Bob’s comment. 4.1. Vehicular Network Architecture Figure 1 shows an example vehicular network architecture for V2I and V2V in a road network [OMNI]. a. Is using OMNI a decision that the WG made for the future work ? what does it do and what does it not do? b. Is there work left to be done? Who will do that work? Or is it the expectation that OMNI has it all defined already? An existing network architecture (e.g., an IP-based aeronautical network architecture [OMNI][UAM-ITS], a network architecture of PMIPv6 [RFC5213], and a low-power and lossy network architecture [RFC6550]) can be extended to a vehicular network architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway scenario, a vehicle may not access an RSU directly because of the distance of the DSRC coverage (up to 1 km). For example, the OMNI interface and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] can be extended to support a multihop V2I since a vehicle can take advantage of other vehicles as relay nodes to reach the RSU. Also, RPL can be extended to support both multihop V2V and V2X in the similar way. >>> all this could fit well in annex; anyway you need to explain what you expect the protocols to do and which extension is needed. In the case of RPL at least you indicate that it would do routing, but not why you cannot use it of the shelf; for OMNI, what you expect is less clear, though there’s text elsewhere about the many radio interfaces that could be used for the purpose, and the text in the UAM below that is enlightening. To support not only the mobility management of the UAM end systems, but also the multihop and multilink communications of the UAM interfaces, the UAM end systems can employ an Overlay Multilink Network (OMNI) interface [OMNI] as a virtual Non-Broadcast Multiple Access (NBMA) connection to a serving ground domain infrastructure. >>> Again, what is the expectation for OMNI? As an overlay it requires an underlay; when connecting to a MANET it needs support for that MANET. The text above seems to imply that is solves everything in V2xyz like magic; reminds me of the IPv6 multicast abstraction that was supposed to solve the broadcast problem and ended up worsening it. This infrastructure can be configured over the underlying data links. The OMNI interface and its link model provide a means of multilink, multihop and mobility coordination to the legacy IPv6 ND messaging [RFC4861] according to the NBMA principle. Thus, the OMNI link model can support efficient UAM internetworking services without additional mobility messaging, and without any modification to the IPv6 ND messaging services or link model. >>> Again, what is the expectation for OMNI? As an overlay it requires an underlay; the text above seems to imply that is solves everything in V2xyz like magic; that would be a stretch, that reminds me of IPv6 multicast that was supposed to solve the broadcast problem and ended up worsening it. Multiple vehicles under the coverage of an RSU share a prefix just as mobile nodes share a prefix of a Wi-Fi access point in a wireless LAN. This is a natural characteristic in infrastructure-based wireless networks. For example, in Figure 1, two vehicles (i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 global addresses for V2I communication. Alternatively, mobile nodes can employ an OMNI interface and use their own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless network without requiring the messaging of IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862], which uses an on-link prefix provided by the (visited) wireless LAN; this technique is known as "Bring-Your-Own- Addresses". >>> Is OMNI the only way to "Bring-Your-Own-Addresses”? Else the text could be more generic, at least use e.g., like the ref to AERO later. >>> What are the implications / limitations of doing that – like they can do line of sight V2V but not reach the internet, or the need of a local MANET / RPL that will accept to route those addresses, or the security / address ownership validation issues ? A single subnet prefix announced by an RSU can span multiple vehicles in VANET. For example, in Figure 1, for Prefix 1, three vehicles (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and Vehicle6) can construct another connected VANET, and for Prefix 3, two vehicles (i.e., Vehicle4 and Vehicle7) can construct another connected VANET. Alternatively, each vehicle could employ an OMNI interface with their own ULAs such that no topologically-oriented subnet prefixes need be announced by the RSU. >>> same as above. This seems to restate the same thing, derive an address from a topologically correct prefix or use your own with limitations to be described. For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] specifies several details, including Maximum Transmission Unit (MTU), frame format, link-local address, address mapping for unicast and multicast, stateless autoconfiguration, and subnet structure. An Ethernet Adaptation (EA) layer is in charge of transforming some parameters between the IEEE 802.11 MAC layer and the IPv6 network layer, which is located between the IEEE 802.11-OCB's logical link control layer and the IPv6 network layer. This IPv6 over 802.11-OCB can be used for both V2V and V2I in IPv6-based vehicular networks. >>> solution space. An IPv6 mobility solution is needed for the guarantee of communication continuity in vehicular networks so that a vehicle's TCP session can be continued, or UDP packets can be delivered to a vehicle as a destination without loss while it moves from an IP-RSU's wireless coverage to another IP-RSU's wireless coverage. In Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) with a corresponding node in the vehicular cloud, Vehicle2 can move from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In this case, a handover for Vehicle2 needs to be performed by either a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and AERO [RFC6706BIS]). In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a role of a home agent. On the other hand, in the network-based mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility management controller such as a Local Mobility Anchor (LMA) in PMIPv6, which also serves vehicles as a home agent, and an IP-RSU plays a role of an access router such as a Mobile Access Gateway (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs client functionality in IPv6 stack of a vehicle as a mobile node for mobility signaling message exchange between the vehicle and home agent. On the other hand, the network-based mobility scheme does not need such a client functionality for a vehicle because the network infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agent handles the mobility signaling message exchange with the home agent (e.g., LMA in PMIPv6) for the sake of the vehicle. There are a scalability issue and a route optimization issue in the network-based mobility scheme (e.g., PMIPv6) when an MA covers a large vehicular network governing many IP-RSUs. In this case, a distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the scalability issue by distributing multiple MAs in the vehicular network such that they are positioned closer to vehicles for route optimization and bottleneck mitigation in a central MA in the network-based mobility scheme. All these mobility approaches (i.e., a host-based mobility scheme, network-based mobility scheme, and distributed mobility scheme) and a hybrid approach of a combination of them need to provide an efficient mobility service to vehicles moving fast and moving along with the relatively predictable trajectories along the roadways. In vehicular networks, the control plane can be separated from the data plane for efficient mobility management and data forwarding by using the concept of Software-Defined Networking (SDN) [RFC7149][DMM-FPC]. Note that Forwarding Policy Configuration (FPC) in [DMM-FPC], which is a flexible mobility management system, can manage the separation of data-plane and control-plane in DMM. In SDN, the control plane and data plane are separated for the efficient management of forwarding elements (e.g., switches and routers) where an SDN controller configures the forwarding elements in a centralized way and they perform packet forwarding according to their forwarding tables that are configured by the SDN controller. An MA as an SDN controller needs to efficiently configure and monitor its IP-RSUs and vehicles for mobility management, location management, and security services. The mobility information of a GPS receiver mounted in its vehicle (e.g., position, speed, and direction) can be used to accommodate mobility-aware proactive handover schemes, which can perform the handover of a vehicle according to its mobility and the wireless signal strength of a vehicle and an IP-RSU in a proactive way. Vehicles can use the TCC as their Home Network having a home agent for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213], so the TCC (or an MA inside the TCC) maintains the mobility information of vehicles for location management. IP tunneling over the wireless link should be avoided for performance efficiency. Also, in vehicular networks, asymmetric links sometimes exist and must be considered for wireless communications such as V2V and V2I. >>> This is all very informative text but does not state a problem. Is there a problem is left to be solved or are we assessing the applicability of protocols? Could it for instance, forward point to issues discussed in section 5? As shown in Figure 3, as internal networks, a vehicle's moving network and an EN's fixed network are self-contained networks having multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) for the communication with another vehicle or another EN. The internetworking between two internal networks via V2I communication requires the exchange of the network parameters and the network prefixes of the internal networks. For the efficiency, the network prefixes of the internal networks (as a moving network) in a vehicle need to be delegated and configured automatically. Note that a moving network's network prefix can be called a Mobile Network Prefix (MNP) [OMNI]. >>> Then again you’re overselling OMNI. MNP is originally defined here https://datatracker.ietf.org/doc/html/rfc3963#section-2 and that’s a reference you can use normatively. As shown in Figure 3, the addresses used for IPv6 transmissions over the wireless link interfaces for IP-OBU and IP-RSU can be either global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be routed within vehicular networks [OMNI]. >>> Then again you’re overselling OMNI. There needs to be a routing protocol like a MANET that will accept to carry the MNPs, and that must be implemented by the infra and both cars. The OMNI spec is clear on that. This is why at first glance I see OMNI as a full mobile router in a bump in the stack. Now what is the problem behind this? No such protocol at IETF? Too many to choose from? No deployment? When global IPv6 addresses are used, wireless interface configuration and control overhead for Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I and V2X communications for vehicles moving fast along roadways; when ULAs and the OMNI interface are used, no DAD nor MLD messaging is needed. >>> Then again you’re overselling OMNI. Isn’t it the no dad needed a property of injecting a BYOA in the fabric for an GUA MIP Home Address which is known to be unique at home? >>> OTOH, autoconf’ing a random ULA “FD…”prefix has lesser DAD properties than autoconf’ing a random 64bit IID in a classical subnet. So who says DAD isn’t required for OMNI ULA? >>> note that IMHO DAD on wireless is a lot more harm than good, and I agree that with a good pseudo random generator the ULA has no chance to collision in the real world, as OMNI claims. It’s just that your argument here plays the other way, because there are less random bits (56) in the ULA prefix than in the IID (62), and if one starts using more prefix bits to be non-random, there will be a time when DAD on prefix is needed. Let us consider the upload/download time of a vehicle when it passes through the wireless communication coverage of an IP-RSU. For a given typical setting where 1km is the maximum DSRC communication range [DSRC] and 100km/h is the speed limit in highway, the dwelling time can be calculated to be 72 seconds by dividing the diameter of the 2km (i.e., two times of DSRC communication range where an IP-RSU is located in the center of the circle of wireless communication) by the speed limit of 100km/h (i.e., about 28m/s). For the 72 seconds, a vehicle passing through the coverage of an IP-RSU can upload and download data packets to/from the IP-RSU. 4.3. V2V-based Internetworking >>> In this section it looks like the cars are in a stable line of sight relationship. Which is probably fine for a platoon, but when you drive along with friends in different cars, you realize that the line of sight assumption does not stand over time. Soon enough, other cars meddle in, and possibly one of the cars drives faster and too far ahead so you need the infra to relay, possibly over multiple infra hops. >>> so in this section, I’d expect to see a Vehicle communicating with another one and using either line of sight or V2V relaying but also using relay via V2I (multihop I2I not just hub and spoke V2I2V ), alternatively to together for redundancy. Is that part of the problem? >>> reading deeper section 5 I found excellent text on routing via V and via I. This tells that section 4 does not play a good role at justifying section 5. Maybe keep section 4 for another doc? >>> What kind or reliability is required in a V2V use case? Do you think ND can handle it? Or MANET? What would be the assumption on L2 (roaming time, unicast vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have some L3 redundancy? 5. Problem Statement In order to specify protocols using the architecture mentioned in Section 4.1, IPv6 core protocols have to be adapted to overcome certain challenging aspects of vehicular networking. Since the vehicles are likely to be moving at great speed, protocol exchanges need to be completed in a time relatively short compared to the lifetime of a link between a vehicle and an IP-RSU, or between two vehicles. >>> Any order of magnitude? >>> Can you indicate whether this already rules out certain procedures, e.g. DAD ? The lifetime of a session varies depending on the session's type such as a web surfing, voice call over IP, and DNS query. Regardless of a session's type, to guide all the IPv6 packets to their destination host, IP mobility should be supported for the session. >>> this seems to be for unicast when you know who to talk to. Is there a need some multicast groups like anybody around interested in topic blah like I could be multicasting the speed of vehicles coming the other way that I crossed recently, for use of vehicles that I’m crossing now, so they can see a slowdown on advance Thus, the time constraint of a wireless link has a major impact on IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also vulnerable to disconnections that occur before the completion of identity verification and tunnel management. This is especially true given the unreliable nature of wireless communication. This section presents key topics such as neighbor discovery and mobility management. >>> Only ND? What about the MANET? >>> how fast should ND be to be suitable? >>> is there also a bandwidth check? You can make things much faster if you dedicate a lot of spectrum to it. But that can also be a waste. 5.1. Neighbor Discovery The requirements for IPv6 ND for vehicular networks are efficient DAD and NUD operations. >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, which is a good idea in my book? This merging and partitioning should be considered for the IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, which is a good idea in my book? Also, the partitioning of a VANET may make vehicles with the same prefix be physically unreachable. Also, SLAAC needs to prevent IPv6 address duplication due to the merging of VANETs. According to the merging and partitioning, a destination vehicle (as an IPv6 host) needs to be distinguished as either an on-link host or an off-link host even though the source vehicle uses the same prefix as the destination vehicle. >>> should reference to draft-nordmark-intarea-ippl To efficiently prevent IPv6 address duplication due to the VANET partitioning and merging from happening in vehicular networks, the vehicular networks need to support a vehicular-network-wide DAD by defining a scope that is compatible with the legacy DAD. In this case, two vehicles can communicate with each other when there exists a communication path over VANET or a combination of VANETs and IP- RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, vehicles can assure that their IPv6 addresses are unique in the vehicular network whenever they are connected to the vehicular infrastructure or become disconnected from it in the form of VANET. >>> Excellent ND time-related parameters such as router lifetime and Neighbor Advertisement (NA) interval need to be adjusted for vehicle speed and vehicle density. For example, the NA interval needs to be dynamically adjusted according to a vehicle's speed so that the vehicle can maintain its neighboring vehicles in a stable way, considering the collision probability with the NA messages sent by other vehicles. >>> Is that a problem or just an operational setting that needs to be found? >>> Do we need to reconsider the concepts of those timers? Thus, in IPv6-based vehicular networking, IPv6 ND should have minimum changes for the interoperability with the legacy IPv6 ND used in the Internet, including the DAD and NUD operations. >>> I do not find the logical link with the text before, why is this a “thus”? >>> why should the ND inside the VANET be constrained to be interoperable? This may place constraints on the solution. 5.1.1. Link Model A prefix model for a vehicular network needs to facilitate the >>> Do you mean a “subnet model” as opposed to “prefix model”. >>> it would make this piece and the next should refer to draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA, for both link and subnet issues. The general ideas are the same, but the gory details here are slightly incorrect, like this notion of prefix model than comes out of the blue. The model is really the subnet model for the subnet associated to P2MP. communication between two vehicles with the same prefix regardless of the vehicular network topology as long as there exist bidirectional E2E paths between them in the vehicular network including VANETs and IP-RSUs. This prefix model allows vehicles with the same prefix to communicate with each other via a combination of multihop V2V and multihop V2I with VANETs and IP-RSUs. Note that the OMNI interface supports an NBMA link model where multihop V2V and V2I communications use each mobile node's ULAs without need for any DAD or MLD messaging. >>> again overselling OMNI. >>> I kinda agree about the OMNI interface model, nothing against that. But you must see that there needs a lot more than what the OMNI interface to get packets across V and I hops to the destination. Like routing ala MANET, redundancy handling ala DetNet because it will be very lossy, path management ala RAW to optimize delivery vs. spectrum… And OMNI ignores ND so it does not solve the ND problems above. IPv6 protocols work under certain assumptions that do not necessarily hold for vehicular wireless access link types other than OMNI/NBMA [VIP-WAVE][RFC5889]; the rest of this section discusses implications for those link types that do not apply when the OMNI/NBMA link model >>> again overselling OMNI. >>> The keyword here is P2MP / NBMA, and OMNI is one interface that accepts that. There are others. IBM’s IPv4 over Frame relay was already P2MP / NBMA, using routing to complete the partial mesh in P2MP. The text seems to imply that OMNI is the only way to do that and that’s wrong. Also OMNI is loaded with other stuff than a plain P2MP capable interface. And ND over P2MP is not done by OMNI, OMNI only makes classical ND worse and only works in a full mesh. OTOH RFC 8505, which is designed to do ND for P2MP /NBMA would indeed work very well within an OMNI interface and solve those problems. >>> My point is that you need to tell the full story or refrain from entering solution space in this doc There is a relationship between a link and a prefix, besides the different scopes that are expected from the link-local and global types of IPv6 addresses. In an IPv6 link, it is assumed that all interfaces which are configured with the same subnet prefix and with on-link bit set can communicate with each other on an IPv6 link. >>> not assumed; that’s what the onlink but set tells. The conclusion should be that the VANET cannot set the O bit. However, the vehicular link model needs to define the relationship between a link and a prefix, considering the dynamics of wireless links and the characteristics of VANET. From the previous observation, a vehicular link model should consider the frequent partitioning and merging of VANETs due to vehicle mobility. Therefore, the vehicular link model needs to use an on- link prefix and off-link prefix according to the network topology of vehicles such as a one-hop reachable network and a multihop reachable >>> No, the once a node saw a O bit set that sticks even if it sees other advertisements of the PIO with the O bit not set. >>> This is a global and intrinsic property of the prefix (and an attack vector that could be mentioned in the sec section). >>> the VANET prefix must never come with the O bit set. network (or partitioned networks). If the vehicles with the same prefix are reachable from each other in one hop, the prefix should be on-link. >>>> No, see above; but the router may redirect though it is really risky unless this is a stable situation like a parking place. Thus, in IPv6-based vehicular networking, the vehicular link model should have minimum changes for interoperability with standard IPv6 links in an efficient fashion to support IPv6 DAD, MLD and NUD operations. When the OMNI NBMA link model is used, there are no link model changes nor DAD/MLD messaging required. >>>> again overselling OMNI. >>>> You need a good P2MP subnet model with routing support when the mesh is partial. My company alone has been shipping million of nodes that build subnets of thousands, and that was done using IETF standards. For vehicular networks with high mobility and density, the DAD needs to be performed efficiently with minimum overhead so that the vehicles can exchange a driving safety message (e.g., collision avoidance and accident notification) with each other with a short interval (e.g., 0.5 second) by a technical report from NHTSA (National Highway Traffic Safety Administration) [NHTSA-ACAS-Report]. Such a driving safety message may include a vehicle's mobility information (i.e., position, speed, direction, and acceleration/ deceleration). The exchange interval of this message is 0.5 second, which is required to allow a driver to avoid a rear-end crash from another vehicle. >>> IPv6 over broadcast MAC (used to be called internet 0, 10+ years ago) solves that MAC issue since there is no MAC. 5.1.3. Routing For multihop V2V communications in either a VANET or VANETs via IP- RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may be required to support both unicast and multicast in the links of the subnet with the same IPv6 prefix. However, it will be costly to run both vehicular ND and a vehicular ad hoc routing protocol in terms of control traffic overhead [ID-Multicast-Problems]. >>> we do that with IETF standards on battery operated devices already. Using RFC 8505 for the UNI and RPL for the NNI. It is scalable (we’ve seen 30 hops in meshes of thousands in the real world though it’s not the normal operational model, but can happen to maintain connectivity during the reboot of a root) and does not use broadcast. RPL was initially designed as a V2V2V protocol but found its market on the IoT. I’m sure the protocol would gladly come back to its roots. A routing protocol for a VANET may cause redundant wireless frames in the air to check the neighborhood of each vehicle and compute the routing information in a VANET with a dynamic network topology because the IPv6 ND is used to check the neighborhood of each vehicle. Thus, the vehicular routing needs to take advantage of the IPv6 ND to minimize its control overhead. >>> A clean description of the interaction of RPL and RFC 8505 in our IoT networks. Note that the speed of the PHY in VANET balanced the instability of the topology, and RPL still applies. Note also that RPL uses DV with a routing stretch in order to minimize the topology awareness that’s needed in each node, which results in minimal signaling. 5.2. Mobility Management For a mobility management scheme in a shared link, where the wireless subnets of multiple IP-RSUs share the same prefix, an efficient vehicular-network-wide DAD is required. If DHCPv6 is used to assign a unique IPv6 address to each vehicle in this shared link, >>> I would not use the term link, or shared. Maybe shared link -> domain? the DAD is not required. On the other hand, for a mobility management scheme with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and OMNI [OMNI]), DAD is not required because the IPv6 address of a vehicle's external wireless interface is guaranteed to be unique. >>> again overselling OMNI >>> As I said earlier, this is wring there are (64*) more chances of a collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes can collision, home addresses that are unique on a home network cannot. >>> Now if both the OMNI prefix and the IID are good randoms, then obviously, the chances of collisions round up to 0. >>> Collision is certainly not my worst fear. There is a tradeoff between the prefix usage efficiency and DAD overhead. Thus, the IPv6 address autoconfiguration for vehicular networks needs to consider this tradeoff to support efficient mobility management. >>> This is way too superficial and hides the reality of things. - Using a VANET Infra prefix allows direct routability to the internet which BYOA does not since the BYOA is not topologically correct. Yes, it costs a DAD with classic ND, but it does not with RCF8505 and the draft fails to mention that. - A BYOA needs a tunnel home, and the node needs to know who is reachable inside the VANET and what is not to decide to tunnel or not; this is a difficult problem (vs. control place overhead) that is not discussed here. For the case of a multihomed network, a vehicle can follow the first- hop router selection rule described in [RFC8028]. That is, the vehicle should select its default router for each prefix by preferring the router that advertised the prefix. >>> Still router discovery (in and out) must be very fast. Thing of the RA intervale in MIPv6. Is that sufficient? Too expensive? 6. Security Considerations >>> Any discussion on the security of classical ND and other operational issues (rfc6583) ? Security and privacy are paramount in V2I, V2V, and V2X networking. Vehicles and infrastructure must be authenticated in order to participate in vehicular networking. Also, in-vehicle devices (e.g., ECU) and a driver/passenger's mobile devices (e.g., smartphone and tablet PC) in a vehicle need to communicate with other in-vehicle devices and another driver/passenger's mobile devices in another vehicle, or other servers behind an IP-RSU in a secure way. Even though a vehicle is perfectly authenticated and legitimate, it may be hacked for running malicious applications to track and collect its and other vehicles' information. In this case, an attack mitigation process may be required to reduce the aftermath of malicious behaviors. >>> The section should mention that both with classical ND and BYOA, addresses can be impersonated, and RFC 8928 protects against that in both cases while maintaining privacy. Even though vehicles can be authenticated with valid certificates by an authentication server in the vehicular cloud, the authenticated >>> Is PKI feasible (deploying it in every car?). Is it fast enough? Is it really what IPWAVE thinks vehicle should use????? >>> e.g. why would one need to authenticate to a V2I network? >>> from the text earlier in the doc, it seemed that what you really want is access that is fast to join, capable of offering the reachability you want, anonymous, and innocuous (cars can not harm one another). vehicles may harm other vehicles, so their communication activities need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure. For the non-repudiation of the harmful activities of malicious nodes, a blockchain technology can be used [Bitcoin]. Each message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]. For a blockchain's efficient consensus in vehicular networks having fast moving vehicles, a new consensus algorithm needs to be developed or an existing consensus algorithm needs to be enhanced. >>> solution space; better express the security needs since this is a PS. To identify malicious vehicles among vehicles, an authentication method is required. >>> No. As said earlier a vehicle can be infected. You need innocuousness.which can come from things like isolation, zerotrust, and protocols that are difficult to hack around. Classical IPv6 ND is open bar. RFC 8505/8928 is protected by construction, anonymous, and fast. For the setup of a secure channel over IPsec or TLS, the multihop V2I communications over DSRC is required in a highway for the authentication by involving multiple intermediate vehicles as relay nodes toward an IP-RSU connected to an authentication server in the vehicular cloud. The V2I communications over 5G V2X (or LTE V2X) is required to allow a vehicle to communicate directly with a gNodeB (or eNodeB) connected to an authentication server in the vehicular cloud. >>> solution space. Instead, you could mention that setting up secured channels between cars that cross one another might not complete in time to establish the communication channel, and that the innocuousness must come from zerotrust in the transactions between the cars. For the IPv6 ND, the DAD is required to ensure the uniqueness of the IPv6 address of a vehicle's wireless interface. >>> for classical ND (SLAAC) that’s true. That is not with RFC 8505, since the infra maintains a table of all addresses in use in the prefix and blocks duplicates without the RFC 4862 DAD method. The stateful autoconf address grant is immediate. This DAD can be used as a flooding attack that uses the DAD-related ND packets disseminated over the VANET or vehicular networks. >>> also for DOS attacks. You can block a owner from using an address. A reference to rfc6959 is much needed here. This possibility indicates that the vehicles and IP-RSUs need to filter out suspicious ND traffic in advance. Based on the SEND [RFC3971] mechanism, the authentication for routers (i.e., IP-RSUs) can be conducted by only selecting an IP-RSU that has a certification path toward trusted parties. For authenticating other vehicles, the cryptographically generated address (CGA) can be used to verify the true owner of a received ND message, which requires to use the CGA ND option in the ND protocols. For a general protection of the ND mechanism, the RSA Signature ND option can also be used to protect the integrity of the messages by public key signatures. For a more advanced authentication mechanism, a distributed blockchain-based mechanism [Vehicular-BlockChain] can be used. >>> solution space. Again, the draft should focus on problems and needs. The problem here is that SEND is complex, and not implemented in the major stack. It relies on PKI for trusting the router. The V2I need is a zerotrust model where one V, the other local Vs, and the I, can help each other anonymously and harmlessly. 8. Informative References >>> no normative reference? >>> no normative reference? Voila! Keep safe; Pascal From nobody Fri Jun 18 14:41:45 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671113A1007; Fri, 18 Jun 2021 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gYVCbmT1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xUG9vqCz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4RuLJXIFAF5; Fri, 18 Jun 2021 14:41:34 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FA43A0FF9; Fri, 18 Jun 2021 14:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70336; q=dns/txt; s=iport; t=1624052493; x=1625262093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wa7ps/N0gPI3r8i5jf2nJ7Nx0z34qsxzN+AkFXH2gqY=; b=gYVCbmT17DQ/1BBfhMLfEmjomwOeeOTO4/jGwE4Pti7xqdGF7yB1kAgU yQnfVQK1tV7ZSkV2VGTd0vMBCq+KFEwQ9qPWCIdVfjDIiZ0q8oOy892eY JhkR9Q2UBBBWRZAFzMP5f/LEX5xsL2s6I4YBO7WcVaiwym3CnVWQOps/5 c=; X-IPAS-Result: =?us-ascii?q?A0CWAwDEEs1gl5NdJa1QAQmBCYMqIwYoflo3MYRIg0gDh?= =?us-ascii?q?TmIawOKS4UQikKBQoERA1EDCwEBAQ0BATUKAgQBAYFcgnQCF4JWAiU4EwIEA?= =?us-ascii?q?QEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFOwEBAQMBJg2GRQEBA?= =?us-ascii?q?QMBEggBCAQNDAEBIw0HAQsCAgIBBgIRAQIBAgMCJgICAh8RFAECBggCBAENB?= =?us-ascii?q?RsHgk8BglUDDiEBDop1jzQBgToCiVAaNXp/M4EBggcBAQYEBIFIQYNGDQuCM?= =?us-ascii?q?QMGBYELKoJ7hA6ENS0EgXsnHIFJRIEVJxyBYAF/PoIgQgEBAgGBGgUEDQEEC?= =?us-ascii?q?gQCBIMrNoIugi4BEAEpBBQBGAIGDwYnDg0FBgQNDhQDEQoEAgoKDAINGQYCB?= =?us-ascii?q?gEGAwoRBAYMBwEBKAIIBwECAwoZAQQBAQEBAwoMAQcBBAYFAwERGAIHCIIaj?= =?us-ascii?q?k4HDA8LCoMsiEuMK0CQbjpbCoMfihSHMIZfBIJHgxAFHQmDXosnhjGDKo0Sl?= =?us-ascii?q?ViMHoMpjHyCWwITDg0BCwSEZAICAgIEBQIOAQEGgWsigVtwFTsqAYI+UBcCD?= =?us-ascii?q?lWEU4IcO1yFUA0JgQIBAYJKhRSFSnM4AgYBCQEBAwl8hhcBJgeCGAEB?= IronPort-PHdr: A9a23:sOFXdBGXTiEOWZE3FSYxwJ1GfjwY04WdBeZdwpEmkLlJNK+k+seqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB7wLeXhaGoxG 8ERHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-HdrOrdr: A9a23:Z/Fh+KAJEEL7ooflHegGsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UkssHFJo6HmBEEZKUmstqKdkrNhQ4tKOzOW+ldATbsSrbcKpgeBJ8SQzJ8n6U 4NSdkaNDS0NykHsS+Y2nj8Lz9D+qj8zEnAv463pB0BIXAIGsNdBkVCe3um+yZNNW977O8CZe KhD7181kOdkBosH6CGL0hAe9KGi8zAlZrgbxJDLQUg8hOygTSh76O/OwSE3z8FOgk/hYsKwC zgqUjU96+ju/a0xlv3zGnI9albn9Pn159qGNGMsM4IMT/h4zzYI7iJGofy+gzdktvfsGrCo+ O8+CvI+P4DsU85S1vF+CcFHTOQjQrGpUWSlWNwykGT0PARDAhKe/apw7gpLScwLyEbzYBBOG Uh5RPGi3MfN2KzoMy2jeK4JC1Chw66p2EvnvUUiGEaWYwCaKVJpYha509NFowcdRiKp7zPPd MeQf003swmPW9yrkqp9lVH0ZipRDA+Dx2GSk8Ntoic1CVXhmlwyw8dyNYElnkN+ZohQ90cjt 60c5hAhfVLVIsbfKh9DOAOTY++DXHMWwvFNCaXLU78HK8KNnrRo9r84akz5uutZJsUpaFC1q gpkGko/1LaXnieQPFm8Kc7hSwlcV/NFggFkPsuk6SRkoeMMoYDHxfzPWwTrw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,284,1616457600"; d="scan'208";a="732210398" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2021 21:41:31 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 15ILfVno006410 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Jun 2021 21:41:31 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Fri, 18 Jun 2021 16:41:31 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 18 Jun 2021 17:41:30 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 18 Jun 2021 16:41:30 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fOcmwKrt7ZRj52rls3LigUt8aUrM8XqsIZ9gpCr+ZeazUeAvZ5Tdo+ARHhLu+pj+8xM/yA68MIVJBdun1F5m5lflYbXHQDYnfCNEvs5axlQ4uKgpJpSDoyoegGA6cjI3f2xwc+rUMKeFjAsc0ZNODDBsJ7mSAF8SNn4DlhKIPL5sc81PpHYhoB9+x68urQLImGWf8l/dz23xXllZPnmxpZGwoqum6zG5i++gfCQezmWvlwaSH4/qVQ7cAeLguO4AbNjFmIJtdoVYujzmM1sbyd917zkxsCa3xn/t0ZsXJfqokzFfXi35zqwx16kIsgKaov/6i9HSV4gJ+5Ll5ew+AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wa7ps/N0gPI3r8i5jf2nJ7Nx0z34qsxzN+AkFXH2gqY=; b=mbWrqGYKfD59Q+dUQVGdCgKBVfKQVP+m3PMAnKYWUVd70eT++x5ffqjBz+7axD3MR+24zwdG7k1v6vCHfDmdhhAc0sQ7lEZXRDHKIbII0NpPxm4pJO+zgdbbPDVdP+1PpewzENWSMSYLqRps1x908rq8lMnRj7pF3/Aeho19pI0/LSvA13YLuD9VMIXSoWN21taR17jADCu7+PDfS95V2/p1dEcrP8eDcdwn+soOAi578D/jrqiKquCpZd3J1KGdArwqSvKCtf48XCmjW15GoWjvXMhnYR4bU8KJ2yi92jHHEUuU18wcJxuKhP8HHAryBVYg3nIaFnjlYHQ2uRjRmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wa7ps/N0gPI3r8i5jf2nJ7Nx0z34qsxzN+AkFXH2gqY=; b=xUG9vqCzNmOYIh8l07XVcY1Ltnrx7cI+XeO4+pOXsWdMT0Tjc7QLri5YJvxkcD7OEUIEQLfynEYhh2fXXTOzKBzmwbqZ7RRsNIKBaBGTqPkMUfx4afRl2C473wpxbIo04eS9EAsn6cAVAB9Wi6RabCnkmCjwCC29bWES8L0s6B0= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5159.namprd11.prod.outlook.com (2603:10b6:510:3c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Fri, 18 Jun 2021 21:41:28 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64%3]) with mapi id 15.20.4242.021; Fri, 18 Jun 2021 21:41:28 +0000 From: "Eric Vyncke (evyncke)" To: "Pascal Thubert (pthubert)" , "int-dir@ietf.org" CC: "draft-ietf-ipwave-vehicular-networking.all@ietf.org" , "its@ietf.org" , "last-call@ietf.org" Thread-Topic: Intdir last call review of draft-ietf-ipwave-vehicular-networking-20 Thread-Index: AQHXZBWPNAxZ+yUsFEu0ACkdrc7rgKsabr6A Date: Fri, 18 Jun 2021 21:41:28 +0000 Message-ID: References: <162400216663.17839.1738900015320888640@ietfa.amsl.com> In-Reply-To: <162400216663.17839.1738900015320888640@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:3068:4863:7810:cab3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73ea976a-6d72-46fb-ea5b-08d932a1d482 x-ms-traffictypediagnostic: PH0PR11MB5159: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TNrB6soDeOjA1EhcF7m0fnzO4MRRexnxTvFwSWNbubhbHQE6EoAVP/41FjHkgx2vFQB2LvNRaf5prDUIOlJ3UdFCWndYPyaCA2HwTO7ksTD2Z8xmfZMeewR4u8qzLPi1+C2kTSJikVFMDaetzwy1iEdNeXD+fC0vG9LAvOJaVWF3g8qjBI8OUF6vyjz32NAef5SzzXBW1Op3lwiGIB+mTH7K4G2yDVwP8I9raYLESMAA4nzDL59ws+LpUQJj/vmKnXLK5sIoxB5QoKUK0n9OoRbFYGbqA1A4UcNTMr8rdzQ+FBlWe4zB2WwZj2Hfb9Ts9trpejRpJkV9tHWn+x0JZCjH43pRbgAyb7Vz3HKyM8ebHuu3Seb4RPD+6CRAP9X55GNYTqk7thKFUrXfN6P9J4oEd4WDGt87Vgivpiw5qx0u7f/0tqKkiSf8JS2XTFBGu25mLQuxLWM5HKoF+30rdlBtL/FJedm8R83J1N+fJiBYVL3LoNstnv8+xlDThCHk8ETnFekb0ZVh35+kYOJS8q2+LIgtojI7xbgdyKm4YvVIDC2B82lcuCxQlHRb4rEzEy12PFgphaqNz6Lm+9wMHH041M47EPv/uwE4pRIVWxKQKVT6QR/SFYHgTRsXo/OEuM6ogurOOp0obk1oSh1Zy0XKz11wFrkWYOpIYWrLqP8d2PS4ojXuNzzCcJkpzNfHEvVYz9Qr1abDsM5CYJiuJef5W9ttZ4iNShqd0NNVkSHXIRo0HMDT7fzOv/hiaqel8TsTxPc91qZzyqObM5QKBQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39850400004)(396003)(136003)(33656002)(86362001)(966005)(122000001)(8676002)(64756008)(6506007)(38100700002)(110136005)(91956017)(76116006)(36756003)(66446008)(316002)(478600001)(2616005)(66946007)(450100002)(71200400001)(66556008)(30864003)(186003)(66574015)(83380400001)(8936002)(4326008)(6486002)(54906003)(5660300002)(2906002)(53546011)(6512007)(66476007)(45980500001)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VW9wUEVQK2o1YU8vdHhNQ3F3ay9sOFhOUlJoWCtsSjZCNHk0Y1B5Q1cwc2JX?= =?utf-8?B?eW9NUldEZEIxSFI4TUJ0QUF2MlRRTU4rRkFRSjlRNnN6TkpnNUI1bEFOYUFI?= =?utf-8?B?WG1xTStpNVFUcXBlNE9xSDVEQTBxdFdrdGRWYk80SmVYVGVnL2ZXRThHeFZo?= =?utf-8?B?Y2wyUUsyQmxiQzhUQ20wK1B1ME0xRnV4TlI5OExpdXNoQS9wc3c3dnFibEtq?= =?utf-8?B?alcwZVMvZHJxNUszZkd0bnROT1BXeUYrd21qRDBxeGhtNlkreXdFbzdXc3J4?= =?utf-8?B?dmZ2ZmZwUmZYMzlKUjEzSEx5V3Z1d09sQjBQYm1KUHFzQnlJL3hwYmt2N0lq?= =?utf-8?B?K1VBRmR1U3Nid1l6K0JyNmRyRGRMRUl1M3F3TWsxODR6RTB4Mjd5bSs2NkV3?= =?utf-8?B?M0NGWXRxT0ovY1BOWExPeWRBd1poQVovd2Nybm50RmFlc25obXkyK2daS2xm?= =?utf-8?B?TnVzd1M3SWszb2JmNEdMYXNCM1R3WitvVWYxZHNSK3FXZ29sa0FpUW10K2J2?= =?utf-8?B?NU9MK1h4Mk1MeWFnb2FIT3pFNEJuV2haMy9tWnV5QThYellGNkRNcmlQL3Ns?= =?utf-8?B?STE1TEhEMUd2NkR3UVowUUhxdUFsMjg1YkdXTnQwWWc5YU12amFHSHpsejVG?= =?utf-8?B?VFpZZVplaTh4Wi9ONXpjT3JBS0cxeCtPNG5PeTlkbSs3V1kwNWkzK1JSQXhS?= =?utf-8?B?SWliUmEybTBtWXVSd1hFQ2dHR0JyL3RyZGlIYzQzcDVVbnFRdGlhYjZMalFU?= =?utf-8?B?dTBJK3J6ZnZCS3VtcjYyTUx2dHZlcFRiYitiU1ZqSlBOMFM1RHZXOTFMdmZ0?= =?utf-8?B?Wi9sK09YYVlhNG5oekgwaURuRU9mVTBsMUFuL1RvQkp5YjNCemxzSHgvV0Rl?= =?utf-8?B?bk5CdzlIU2V6OE9tMUVsait1SFhEVUlodXR2K0FiUnlOTUdzTy84bXZNMDdy?= =?utf-8?B?bTcvZk8ycVBIV2FyTnVOK1FuV29iQmJ6RWx6dFo3WEtHSGsvRGkvdkwvcjFu?= =?utf-8?B?dDZqS0ZiLzBHRHJDcDJlRmFLNVB2SytOdlhCREUzc0NqdDcvdWt6WjhLdEM4?= =?utf-8?B?QlJEMUMzYnFKWUlCR3NuUXJZTk01ZlppMURCZ294NzV6OFJrZXdYdDRQejRE?= =?utf-8?B?bTBhMktEbGZoNjB6djVuaW1jdmJOTGcrUFV5MC92ZGRlbWdUWnFzRTR6WG9s?= =?utf-8?B?VkYwcFlpYU5MTTgyRVV0KzkzMktGUlNINm9IbTEvL212U1dVYWR6S3NyZllW?= =?utf-8?B?UmxMeEg4bmFLTWpKNk1yR1B1V1NjTk1lZFptOTh1SEZsZ2hoWFlWYnZUWlhn?= =?utf-8?B?cmRaTTZJcmlWcnZ1ZVFDRC9SQzVvWFVyQUJULzQwMSszeEYxRGVZcHhkbjd5?= =?utf-8?B?Z0puTS9pUVNLR0hOZGg4akRnNVY5RWo4cEhaYTFhZ3E1NjVNS2R6dlA1RU5a?= =?utf-8?B?OHJDUURKd3Vsb2VrUGhHU0UvYm5wQ3lrOTRZa3I1QndNZ0t1RHpoZXhLTnFW?= =?utf-8?B?cWJoRUw5MHBHYUwxc2lqNW9rK043Q3laWjMwSTdZMW5mZFE1c1dFN1g2eGlm?= =?utf-8?B?Uk1OOENsdGRoZ2t1UWFMSkVtVGlmaE1ySHdNQy9xVzFWUjU3SFJpQUR5bHVX?= =?utf-8?B?RGhzQ25LL1QvKzVnZ2tReEJUWUtZMEZTWEowenpSbE8ybXIwTXdWdHpSd0RV?= =?utf-8?B?S0dxTlpuTVh6dU9aZUtJSmgvTUZ4S1BKa281aFJ5MFQzdDU2VnpKK3dyVHpF?= =?utf-8?B?WE01SFhwMFZycFlhclRWMy8wdFMrNXd4YXVXSGp3amxpSzZLOWZlbGhpMlVt?= =?utf-8?B?aVpOamprUEg1ZEdadUlwTEt0YkFrWjR3K0NqUWZCTlMzMnRSREMxRXNjM0F4?= =?utf-8?Q?K9SX4jPBy6xyc?= Content-Type: text/plain; charset="utf-8" Content-ID: <32F2EBABA2431445B35122B813404898@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73ea976a-6d72-46fb-ea5b-08d932a1d482 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2021 21:41:28.4256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uWeFS+5s3RtJtkpsFQ8vBCPQHdF1F51Bnr4FtdOYwjo8O1h324FTQOkFjvYXCTQaFgDD4WlkGwIk1SdDSqeMrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5159 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 21:41:43 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCwgUGFzY2FsDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGFzY2FsIFRodWJlcnQgdmlhIERhdGF0cmFja2VyIDxub3Jl cGx5QGlldGYub3JnPg0KUmVwbHktVG86IFBhc2NhbCBUaHViZXJ0IDxwdGh1YmVydEBjaXNjby5j b20+DQpEYXRlOiBGcmlkYXksIDE4IEp1bmUgMjAyMSBhdCAwOTo0Mg0KVG86ICJpbnQtZGlyQGll dGYub3JnIiA8aW50LWRpckBpZXRmLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1pcHdhdmUtdmVoaWN1 bGFyLW5ldHdvcmtpbmcuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1pcHdhdmUtdmVoaWN1bGFy LW5ldHdvcmtpbmcuYWxsQGlldGYub3JnPiwgIml0c0BpZXRmLm9yZyIgPGl0c0BpZXRmLm9yZz4s ICJsYXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJbnRk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwd2F2ZS12ZWhpY3VsYXItbmV0d29y a2luZy0yMA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRv OiA8aG91c2xleUB2aWdpbHNlYy5jb20+LCA8Y2piY0BpdC51YzNtLmVzPiwgPGVrLmlldGZAZ21h aWwuY29tPiwgPHBhdWxqZW9uZ0Bza2t1LmVkdT4sIEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2Nv LmNvbT4NClJlc2VudC1EYXRlOiBGcmlkYXksIDE4IEp1bmUgMjAyMSBhdCAwOTo0Mg0KDQogICAg UmV2aWV3ZXI6IFBhc2NhbCBUaHViZXJ0DQogICAgUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5DQoN CiAgICBEZWFyIGF1dGhvcnMNCg0KICAgIEluIHN1bW1hcnk6DQoNCiAgICBJIHJlYWQgYSBudW1i ZXIgb2YgdmVyeSBnb29kIGRyYWZ0cyBjb2xsYXRlZCBpbiBvbmUsIGZyb20gdGhlIHVzZSBjYXNl cyB0aGF0DQogICAgdmVyeSBjb21wbGV0ZSBhbmQgcmVhZHkgdG8gcHVibGlzaCwgdG8gdGhlIGFy Y2hpdGVjdHVyZSBhbmQgcHJvdG9jb2wgc29sdXRpb24NCiAgICBpbiBzZWN0aW9uIDQgdGhhdCB3 b3VsZCByZXF1aXJlIG1vcmUgd29yayBmb3IgY29tcGxldGVuZXNzLg0KDQogICAgVGhlcmUgYXJl IG11bHRpcGxlIGluc3RhbmNlcyBpbiB0aGUgdXNlIGNhc2VzIHdoZXJlIHByb3RvY29scyBhcmUg bGlzdGVkIGNvbWluZw0KICAgIG91dCBvZiB0aGUgYmx1ZSwgZS5nLiwgdGhlIHJlZmVyZW5jZXMg dG8gT01OSSB0aGF0IHNlZW0gYXJ0aWZpY2lhbGx5IHNwcmVhZA0KICAgIHJlZ2FyZGxlc3Mgb2Yg dGhlIGNvbnRleHQgb2YgdGhlIHNlY3Rpb24uIE9NTkkgaXMgdXNlZCB0aHJvdWdob3V0LCBib3Ro IGFzIGFuDQogICAgb3BlbiBlbmRlZCB0b29sYm94LCBhbmQgYXMgYSBjYXJwZXQgdW5kZXIgd2hp Y2ggYWxsIHByb2JsZW1zIGNhbiBiZSBoaWRkZW4uDQoNCiAgICBSZWFkaW5nIHRoaXMgZG9jLCBP TU5JIHNob3dzIGFzIGFuIGludGVyZmFjZSB0byBhIHNvZnR3YXJlIG1vYmlsZSByb3V0ZXIsIHdp dGgNCiAgICBtdWx0aXBsZSBvZiB0aGUgZGV2aWNlIHBoeXNpY2FsIGludGVyZmFjZXMgY29ubmVj dGVkIHRvIHRoZSBtb2JpbGUgcm91dGVyLiBUaGlzDQogICAgbWFrZXMgdGhlIHN0YWNrIHZlcnkg c2ltcGxlIGFzIHRoZSBjb21wbGV4aXR5IG1vdmVzIHRvIHRoZSByb3V0ZXIuIEJ1dCBub3cgeW91 DQogICAgaGF2ZSB0byBpbXBsZW1lbnQgdGhlIHJvdXRlci4gUHJlc2VudGVkIGFzIHRoYXQsIHRo ZSBPTU5JIHJvdXRlciBkZXNlcnZlcyBpdHMNCiAgICBuYW1lLCBpdOKAmXMgaW5kZWVkIHZlcnkg cmljaDsgaXQgc2VlbXMgdG8gY292ZXIgYWxsIGZvcm1zIG9mIE1BTkVUIChtYW55IHRvDQogICAg Y2hvb3NlIGZyb20pIGFuZCBORU1PIChhbmQgYWxsIHRoZSBNSVAgcHJvdG9jb2wgZmFtaWx5IGFj cm9zcyBhZGRyZXNzDQogICAgZmFtaWxpZXMpLCBhbGwgdGhlIHBvc3NpYmxlIHJhZGlvIGludGVy ZmFjZXMgb24gd2hpY2ggdGhlIE5EIHByb2JsZW1zIGdvIGF3YXkNCiAgICBieSBtYWdpYywgYW5k IHdoYXRldmVyIGVsc2UgeW91IHdhbnQgdG8gcHV0IGluIHRoZXJlLiBJcyB0aGF0IHRoZSBpbnRl bnRpb24/DQoNCiAgICBJbnN0ZWFkIG9mIHJlZmVycmluZyB0byBPTU5JIGZvciB2aXJ0dWFsbHkg YW55dGhpbmcsIHRoZSBkb2Mgc2hvdWxkIHJlZmVyIHRvDQogICAgTUFORVQgZm9yIE1BTkVUIHRo aW5ncyAobGlrZSBCWU9EKSwgTkVNTyBmb3IgTkVNTyB0aGluZ3MgKGxpa2UgTU5QKSwNCiAgICBk cmFmdC1ub3JkbWFyay1pbnRhcmVhLWlwcGwgZm9yIHNwbGl0IHN1Ym5ldHMsIGFuZA0KICAgIGRy YWZ0LXRodWJlcnQtNm1hbi1pcHY2LW92ZXItd2lyZWxlc3MgZm9yIFAyTVAvTkJNQSBsaW5rIGFu ZCBzdWJuZXQgbW9kZWxzLiBBbmQNCiAgICB0aGVuIHlvdSBjYW4gc2F5IHRoYXQgYWxsIHRob3Nl IGNvbXBvbmVudHMgY2FuIGJlIHBsdWdnZWQgaW4gdGhlIE9NTkkgcm91dGVyLA0KICAgIGFuZCB5 b3UgY2FuIGRpc2N1c3Mgd2hpY2ggTUFORVQgYW5kIHdoaWNoIE1JUCB5b3Ugd2FudCwgaW5jbHVk aW5nIHVzaW5nIE9NTknigJlzDQogICAgYnVpbHQgaW4gbW9iaWxpdHkuDQoNCiAgICBOb3RlIHRo YXQgbXkgb2JqZWN0aW9ucyBhcmUgbm90IGFnYWluc3QgdGhlIE9NTkkgZGVzaWduLCBpdCBtaWdo dCBiZSB0aGUNCiAgICBwZXJmZWN0IHRoaW5nIGFuZCBJIGFtIGFscmVhZHkgYXdhcmUgb2YgdXNl IGNhc2VzIHRoYXQgY291bGQgYmUgc2VydmVkIGJ5IGENCiAgICBQMk1QIGludGVyZmFjZSBsaWtl IE9NTkkgaW4gY29uanVuY3Rpb24gd2l0aCBSRkM4NTA1IG9uIHRoZSBQMlAgc3ViaW50ZXJmYWNl cw0KICAgIChyZWN5Y2xpbmcgdGhlIGhpZ2ggbGV2ZWwgZGVzaWduIHdl4oCZdmUgYmVlbiBzaGlw cGluZyBmb3IgSVB2NCAvIGZyYW1lIHJlbGF5IGZvcg0KICAgIHRoZSBsYXN0IDMwIHllYXJzKS4g TXkgb2JqZWN0aW9uIGlzIG9mIHRoZSB3YXkgdGhlIGRyYWZ0IHVzZXMgW09NTkldIGFzIHRoZQ0K ICAgIG1hZ2ljIHdhbmQgdGhhdCBzb2x2ZXMgYWxsIHRoZSBwcm9ibGVtcyB3aGVuIHdoYXQgeW91 IHJlYWxseSBkbyBpcyB0aHJvdyB0aGVtDQogICAgb3ZlciB0aGUgZmVuY2UuIEnigJlkIHJhdGhl ciB5b3UgZm9jdXMgb24gcHJvYmxlbXMgYW5kIHVzZSBjYXNlcywgZm9yIHdoaWNoDQogICAgdGhl cmXigJlzIGV4Y2VsbGVudCB0ZXh0LCBhbmQgaW5kaWNhdGUgd2hhdCBuZWVkcyB0byBiZSBkb25l IHdpdGhvdXQgbWFraW5nDQogICAgYXNzdW1wdGlvbiBvbiBob3cgdGhlIG5lZWRmdWwgdGhpbmdz IHdpbGwgYmUgc29sdmVkLg0KDQogICAgSW4gYWdyZWVtZW50IHdpdGggYSBkaXNjdXNzaW9uIG9u IHRoZSA2TUFOIGxpc3QsIEnigJlkIHN1Z2dlc3QgdG8gc3BsaXQsIGtlZXAgYWxsDQogICAgdGhh dOKAmXMgdXNlIGNhc2UgYW5kIHByb2JsZW0gZGVzY3JpcHRpb24gYW5kIHNoaXAgaXQsIHJlbW92 ZSByZWZlcmVuY2VzIHRvDQogICAgcHJvdG9jb2xzIGVudmlzaW9uZWQgaW4gdGhlIHNvbHV0aW9u LCBhbmQgc3RhcnQgdGhlIHdvcmsgb24gYXJjaGl0ZWN0dXJlIG9mIHRoZQ0KICAgIHNvbHV0aW9u IGFuZCB0aGUgcHJvdG9jb2wgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnRzIHNlcGFyYXRlbHkuIEFu IGFsdGVybmF0ZQ0KICAgIHdvdWxkIGJlIHRvIGNlbnRyYWxpemUgdGhlIGRpc2N1c3Npb24gb24g cHJvdG9jb2xzIHRvIGFubmV4LCBhbmQgZXhwbGFpbiB0aGF0DQogICAgcHJvdG9jb2wgQSBvciBC IGNvdWxkIGJlIGVudmlzaW9uZWQgaW4gc29sdXRpb24gc3BhY2UgYmVjYXVzZSB0byBvdmVyIHRo aXMgZ2FwDQogICAgb3IgaW1wbGVtZW50IHRoYXQgZnVuY3Rpb24uDQoNCiAgICBJbiBhbnkgZmFz aGlvbiwgdGhlIGN1cnJlbnQgdGV4dCBpcyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGFw cGxpY2FiaWxpdHkNCiAgICBzdGF0ZW1lbnQsIGFyY2hpdGVjdHVyZSBhbmQgb3Ivc29sdXRpb24s IHNvIHRoZSByZWxhdGVkIHdvcmsgc2hvdWxkIGJlIHJlbW92ZWQNCiAgICBmcm9tIHRoZSBtYWlu IHRleHQuIEJ1dCBJIGZpbmQgaXQgbW9zdGx5IHJlYWR5IGZvciB1c2UgY2FzZSBhbmQgcHJvYmxl bQ0KICAgIHN0YXRlbWVudCwgbW9yZSBiZWxvdy4NCg0KICAgIFJldmlldzoNCg0KICAgIEFic3Ry YWN0DQoNCiAgICAgICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQgYW5kIHVzZSBjYXNlcyBvZg0KICAgICAgIElQdjYtYmFzZWQgdmVoaWN1bGFyIG5ldHdvcmtp bmcgZm9yIEludGVsbGlnZW50IFRyYW5zcG9ydGF0aW9uDQogICAgICAgU3lzdGVtcyAoSVRTKS4N Cg0KICAgID4+PiBUaGUgZG9jdW1lbnQgZ29lcyBiZXlvbmQgdGhhdDsgdGhlcmUgd2FzIGFjdHVh bGx5IGEgdGhyZWFkIGF0IDZNQU4gd2hlcmUNCiAgICBCb2IgSGluZGVuIHNhaWQg4oCcIFRoaXMg ZG9jdW1lbnQgc2F5cyBpdCBpcyBhIHByb2JsZW0gc3RhdGVtZW50LCBidXQgdGhlbg0KICAgIGJl Y29tZXMgYSBzb2x1dGlvbiBkb2N1bWVudC4gICBNaWdodCBiZSBiZXR0ZXIgdG8gY3V0IGl0IGRv d24gdG8gb25seSB0aGUNCiAgICBwcm9ibGVtIHN0YXRlbWVudCBwYXJ0LiDigJwgPj4+IFdvdWxk IHlvdSBjb25zaWRlciBkb2luZyB0aGlzPyBJZiBub3QsIHdoeT8gTm90ZToNCiAgICB5b3UgbWF5 IHdhbnQgdG8gcmVzcG9uZCBvbiA2TUFOIGFzIHdlbGwuID4+PiA+Pj5JIHdvdWxkIGhhdmUgdGhv dWdodCB0aGF0IHRoZQ0KICAgIHRyYWRpdGlvbmFsIHN0ZXBzIG9mIHByb2JsZW0gc3RhdGVtZW50 IGFuZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBvZiBleGlzdGluZw0KICAgIHdvcmsgY291bGQg YmUgZXhwZWN0ZWQgZnJvbSBJUFdBVkUgdG9vLiA+Pj4gUGxlYXNlIGNsYXJpZnkgdGhlIHN0ZXBz IHRoYXQgeW91DQogICAgaW50ZW5kIHRvIGZvbGxvdyBuZXh0IHdpdGggdGhpcyB3b3JrLg0KDQog ICAgPHNuaXA+DQoNCiAgICAxLiAgSW50cm9kdWN0aW9uDQoNCiAgICA+Pj4gVmVyeSByZWFkYWJs ZSBhbmQgaW5mb3JtYXRpdmUgc2VjdGlvbiwgbWFueSB0aGFua3MhDQoNCiAgICAgICBBbG9uZyB3 aXRoIHRoZXNlIFdBVkUgc3RhbmRhcmRzIGFuZCBDLVYyWCBzdGFuZGFyZHMsIHJlZ2FyZGxlc3Mg b2YgYQ0KICAgICAgIHdpcmVsZXNzIGFjY2VzcyB0ZWNobm9sb2d5IHVuZGVyIHRoZSBJUCBzdGFj ayBvZiBhIHZlaGljbGUsIHZlaGljdWxhcg0KICAgICAgIG5ldHdvcmtzIGNhbiBvcGVyYXRlIElQ IG1vYmlsaXR5IHdpdGggSVB2NiBbUkZDODIwMF0gYW5kIE1vYmlsZSBJUHY2DQogICAgICAgcHJv dG9jb2xzIChlLmcuLCBNb2JpbGUgSVB2NiAoTUlQdjYpIFtSRkM2Mjc1XSwgUHJveHkgTUlQdjYg KFBNSVB2NikNCiAgICAgICBbUkZDNTIxM10sIERpc3RyaWJ1dGVkIE1vYmlsaXR5IE1hbmFnZW1l bnQgKERNTSkgW1JGQzczMzNdLCBMb2NhdG9yLw0KICAgICAgIElEIFNlcGFyYXRpb24gUHJvdG9j b2wgKExJU1ApIFtSRkM2ODMwQklTXSwgYW5kIEFzeW1tZXRyaWMgRXh0ZW5kZWQNCiAgICAgICBS b3V0ZSBPcHRpbWl6YXRpb24gKEFFUk8pIFtSRkM2NzA2QklTXSkuDQoNCiAgICA+Pj4gTkVNTyAo UkZDIDM5NjMpIGlzIG5vdCBjaXRlZC4gQW55IHJlYXNvbiB3aHkgdGhlIHZlaGljbGUgd291bGQg bm90DQogICAgdHJhbnNwb3J0IGEgbmV0d29yaz8NCg0KICAgIDxzbmlwPg0KDQogICAgICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdXNlIGNhc2VzIGFuZCBhIHByb2JsZW0gc3RhdGVtZW50IGFi b3V0DQogICAgICAgSVB2Ni1iYXNlZCB2ZWhpY3VsYXIgbmV0d29ya2luZyBmb3IgSVRTLCB3aGlj aCBpcyBuYW1lZCBJUHY2IFdpcmVsZXNzDQogICAgICAgQWNjZXNzIGluIFZlaGljdWxhciBFbnZp cm9ubWVudHMgKElQV0FWRSkuICBGaXJzdCwgaXQgaW50cm9kdWNlcyB0aGUNCiAgICAgICB1c2Ug Y2FzZXMgZm9yIHVzaW5nIFYyViwgVjJJLCBhbmQgVjJYIG5ldHdvcmtpbmcgaW4gSVRTLiAgTmV4 dCwgZm9yDQogICAgICAgSVB2Ni1iYXNlZCB2ZWhpY3VsYXIgbmV0d29ya3MsIGl0IG1ha2VzIGEg Z2FwIGFuYWx5c2lzIG9mIGN1cnJlbnQNCiAgICAgICBJUHY2IHByb3RvY29scyAoZS5nLiwgSVB2 NiBOZWlnaGJvciBEaXNjb3ZlcnksIE1vYmlsaXR5IE1hbmFnZW1lbnQsDQogICAgICAgYW5kIFNl Y3VyaXR5ICYgUHJpdmFjeSksIGFuZCB0aGVuIGVudW1lcmF0ZXMgcmVxdWlyZW1lbnRzIGZvciB0 aGUNCiAgICAgICBleHRlbnNpb25zIG9mIHRob3NlIElQdjYgcHJvdG9jb2xzLCB3aGljaCBhcmUg dGFpbG9yZWQgdG8gSVB2Ni1iYXNlZA0KICAgICAgIHZlaGljdWxhciBuZXR3b3JraW5nLiAgVGh1 cywgdGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBtb3RpdmF0ZQ0KICAgICAgIGRldmVsb3Bt ZW50IG9mIGtleSBwcm90b2NvbHMgZm9yIElQV0FWRS4NCg0KICAgID4+Pg0KDQogICAgPHNuaXA+ DQoNCiAgICAyLiAgVGVybWlub2xvZ3kNCg0KICAgID4+Pg0KDQogICAgPHNuaXA+DQoNCiAgICAg ICBvICBJUC1PQlU6ICJJbnRlcm5ldCBQcm90b2NvbCBPbi1Cb2FyZCBVbml0IjogQW4gSVAtT0JV IGRlbm90ZXMgYQ0KICAgICAgICAgIGNvbXB1dGVyIHNpdHVhdGVkIGluIGEgdmVoaWNsZSAoZS5n LiwgY2FyLCBiaWN5Y2xlLCBhdXRvYmlrZSwNCiAgICAgICAgICBtb3RvciBjeWNsZSwgYW5kIGEg c2ltaWxhciBvbmUpIGFuZCBhIGRldmljZSAoZS5nLiwgc21hcnRwaG9uZSBhbmQNCiAgICAgICAg ICBJb1QgZGV2aWNlKS4gIEl0IGhhcyBhdCBsZWFzdCBvbmUgSVAgaW50ZXJmYWNlIHRoYXQgcnVu cyBpbiBJRUVFDQogICAgICAgICAgODAyLjExLU9DQiBhbmQgaGFzIGFuICJPQlUiIHRyYW5zY2Vp dmVyLiAgQWxzbywgaXQgbWF5IGhhdmUgYW4gSVANCiAgICAgICAgICBpbnRlcmZhY2UgdGhhdCBy dW5zIGluIENlbGx1bGFyIFYyWCAoQy1WMlgpIFtUUy0yMy4yODUtM0dQUF0NCiAgICAgICAgICBb VFItMjIuODg2LTNHUFBdW1RTLTIzLjI4Ny0zR1BQXS4gIFNlZSB0aGUgZGVmaW5pdGlvbiBvZiB0 aGUgdGVybQ0KICAgICAgICAgICJPQlUiIGluIFtSRkM4NjkxXS4NCg0KICAgID4+PiBDYW4gdGhh dCBiZSBhIHJvdXRlciBjb25uZWN0aW5nIG11bHRpcGxlIGNvbXB1dGVycz8NCg0KICAgIDxzbmlw Pg0KDQogICAgMy4gIFVzZSBDYXNlcw0KDQogICAgPj4+IFRoaXMgaXMgYW5vdGhlciBncmVhdCBy ZWFkIGFuZCBhbiBlbmxpZ2h0ZW5pbmcgc2VjdGlvbi4gTWF5YmUgbWVudGlvbiBpbg0KICAgIHRo ZSBhYnN0cmFjdCB0aGF0IHRoZSBkb2MgYWxzbyBjb3ZlcnMgdXNlIGNhc2VzPw0KDQogICAgPHNu aXA+DQoNCiAgICAgICBBbHRob3VnaCBhIExheWVyLTIgc29sdXRpb24gY2FuIHByb3ZpZGUgYSBz dXBwb3J0IGZvciBtdWx0aWhvcA0KICAgICAgIGNvbW11bmljYXRpb25zIGluIHZlaGljdWxhciBu ZXR3b3JrcywgdGhlIHNjYWxhYmlsaXR5IGlzc3VlIHJlbGF0ZWQNCiAgICAgICB0byBtdWx0aWhv cCBmb3J3YXJkaW5nIHN0aWxsIHJlbWFpbnMgd2hlbiB2ZWhpY2xlcyBuZWVkIHRvDQogICAgICAg ZGlzc2VtaW5hdGUgb3IgZm9yd2FyZCBwYWNrZXRzIHRvd2FyZCBtdWx0aWhvcC1hd2F5IGRlc3Rp bmF0aW9ucy4gIEluDQogICAgICAgYWRkaXRpb24sIHRoZSBJUHY2LWJhc2VkIGFwcHJvYWNoIGZv ciBWMlYgYXMgYSBuZXR3b3JrIGxheWVyIHByb3RvY29sDQogICAgICAgY2FuIGFjY29tbW9kYXRl IG11bHRpcGxlIHJhZGlvIHRlY2hub2xvZ2llcyBhcyBNQUMgcHJvdG9jb2xzLCBzdWNoIGFzDQog ICAgICAgNUcgVjJYIGFuZCBEU1JDLiAgVGhlcmVmb3JlLCB0aGUgZXhpc3RpbmcgSVB2NiBwcm90 b2NvbCBjYW4gYmUNCiAgICAgICBhdWdtZW50ZWQgdGhyb3VnaCB0aGUgYWRkaXRpb24gb2YgYW4g T3ZlcmxheSBNdWx0aWxpbmsgTmV0d29yayAoT01OSSkNCiAgICAgICBJbnRlcmZhY2UgW09NTkld IGFuZC9vciBwcm90b2NvbCBjaGFuZ2VzIGluIG9yZGVyIHRvIHN1cHBvcnQgYm90aA0KICAgICAg IHdpcmVsZXNzIHNpbmdsZS1ob3AvbXVsdGlob3AgVjJWIGNvbW11bmljYXRpb25zIGFuZCBtdWx0 aXBsZSByYWRpbw0KICAgICAgIHRlY2hub2xvZ2llcyBpbiB2ZWhpY3VsYXIgbmV0d29ya3MuICBJ biBzdWNoIGEgd2F5LCB2ZWhpY2xlcyBjYW4NCiAgICAgICBjb21tdW5pY2F0ZSB3aXRoIGVhY2gg b3RoZXIgYnkgVjJWIGNvbW11bmljYXRpb25zIHRvIHNoYXJlIGVpdGhlciBhbg0KICAgICAgIGVt ZXJnZW5jeSBzaXR1YXRpb24gb3Igcm9hZCBoYXphcmQgaW4gYSBoaWdod2F5IGhhdmluZyBtdWx0 aXBsZSBraW5kcw0KICAgICAgIG9mIHJhZGlvIHRlY2hub2xvZ2llcywgc3VjaCBhcyA1RyBWMlgg YW5kIERTUkMuDQoNCiAgICA+Pj4gVGhpcyB0ZXh0IGFwcGVhcnMgaW4gdGhlIG1pZGRsZSBvZiBo aWdoIGxldmVsIHVzZSBjYXNlLCB3aXRoIGEgY3J1ZGUgbGlzdA0KICAgIG9mIHByb3RvY29sczsg dGhpcyBpcyBub3QgYSBwbGFjZSBmb3IgaXQNCg0KICAgID4+PiBPbiBhIDZNQU4gVGhyZWFkLCBC cmlhbiBDYXJwZW50ZXIgc2FpZCB0aGF0IHRoZSBhYm92ZToNCiAgICDigJwNCiAgICBpcyBvZiBj b25jZXJuIHJlZ2FyZGxlc3Mgb2YgdGhlIG1lbnRpb24gb2YgT01OSS4gRG9lcyBpdCBtZWFuICJj YW4gYmUiIG9yDQogICAgIm5lZWRzIHRvIGJlIj8gVGhpcyBwYXJhZ3JhcGggc2VlbXMgbGlrZSBh IHZlcnkgc2hvcnQgc3VtbWFyeSBvZiBhIGJpZyBwcm9ibGVtDQogICAgYXJlYS4gQXQgdGhlIGVu ZCBvZiBwYWdlIDEzIHRoZXJlIGlzIHNvbWUgcmVsYXRlZCBkaXNjdXNzaW9uLCB3aGljaCBtZW50 aW9ucw0KICAgIFJQTCBhcyBwYXJ0IG9mIHRoZSBzb2x1dGlvbiAoZ29vZCBjaG9pY2UsIElNSE8p IGJ1dCBhZ2FpbiBzZWVtcyB0byBkZXBlbmQgb24NCiAgICBPTU5JLiBJIGRvbid0IHRoaW5rIHRo ZSBmaXggb2Ygc2ltcGx5IHJlbW92aW5nIHJlZmVyZW5jZXMgdG8gT01OSSB3b3JrcywNCiAgICBi ZWNhdXNlIGl0IHdvdWxkIGxlYXZlIGEgZ2FwLiBJbiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 LCB0aGF0IGlzIG5vdCBhDQogICAgZm9ybWFsIHByb2JsZW0gYnV0IGFzIGZhciBhcyB0aGlzIGRy YWZ0IGRlc2NyaWJlcyBhcmNoaXRlY3R1cmUsIEkgZG9uJ3QgdGhpbmsNCiAgICB0aGF0IGJpZyBh IGdhcCBpcyByZWFzb25hYmxlLiAiT01OSSIgaXMgbWVudGlvbmVkIG1vcmUgdGhhbiAyMCB0aW1l cyBpbiB0aGUNCiAgICBkb2N1bWVudC4gVGhlcmUgYXJlIGFsc28gc2V2ZXJhbCByZWZlcmVuY2Vz IHRvIEFFUk8sIHdoaWNoIGlzIHN0cm9uZ2x5DQogICAgYXNzb2NpYXRlZCB3aXRoIE9NTkkuIOKA nCA+Pj4gSSBhZ3JlZSB3aXRoIEJyaWFuLiBIZXJlIHRoZSBkb2N1bWVudCBzZWVtcyB0byBiZQ0K ICAgIG1peGluZyBzb2x1dGlvbiB3aXRoIHByb2JsZW0gYW5kIHB1dHRpbmcgdGhlIGNhcnQgYmVm b3JlIHRoZSBob3JzZS4gTXkNCiAgICByZWNvbW1lbmRhdGlvbiBpcyB0byBzdGljayB0byB3aGF0 IG5lZWRzIHRvIGJlIGRvbmUgdGhhdCBJUHY2IGRvZXMgbm90IGRvIHlldA0KICAgIC10aGUgcmVx cyBhbmQgZ2Fwcy07IGJ1dCB0aGUgZG9jIHNob3VsZCBub3Qgc3RlcCBpbiB0aGUgaG93IHRoaW5n cyB3aWxsIGJlIGRvbmUNCiAgICB1bmxlc3MgdGhlIGdyb3VwIGFscmVhZHkgZGVjaWRlZCB0byBk byBpdC4gVGhlIGxvZ2ljYWwgbmV4dCBzdGVwcyB0byBhIFBTIGFyZQ0KICAgIGFuIGFwcGxpY2Fi aWxpdHkgc3RhdGVtZW50IG9mIGV4aXN0aW5nIHdvcmssIGFuZCBpZiB0aGUgZ2FwcyBjYW5ub3Qg YmUgZmlsbGVkLA0KICAgIHRoZXJlIG1heSBiZSBvbmUgb3IgbW9yZSBXRyBjaGFydGVyZWQgdG8g ZmlsbCB0aG9zZSBnYXBzLg0KDQogICAgPj4+IEnigJlkIHN0aWxsIGJlIGhhcHB5IHRvIHNlZSBh biBhbm5leCB3aXRoIGxlYWRzIG9uIHdoZXJlIHRoZSBzb2x1dGlvbiBtaWdodA0KICAgIGNvbWUg ZnJvbSBsaWtlIFJGQyA4NjkxIGRvZXMuDQoNCiAgICA8c25pcD4NCg0KICAgICAgIFRoZSBleGlz dGluZyBJUHY2IHByb3RvY29sIG11c3QgYmUgYXVnbWVudGVkIHRocm91Z2ggdGhlIGFkZGl0aW9u IG9mDQogICAgICAgYW4gT01OSSBpbnRlcmZhY2UgYW5kL29yIHByb3RvY29sIGNoYW5nZXMgaW4g b3JkZXIgdG8gc3VwcG9ydA0KICAgICAgIHdpcmVsZXNzIG11bHRpaG9wIFYySSBjb21tdW5pY2F0 aW9ucyBpbiBhIGhpZ2h3YXkgd2hlcmUgUlNVcyBhcmUNCiAgICAgICBzcGFyc2VseSBkZXBsb3ll ZCwgc28gYSB2ZWhpY2xlIGNhbiByZWFjaCB0aGUgd2lyZWxlc3MgY292ZXJhZ2Ugb2YgYW4NCiAg ICAgICBSU1UgdGhyb3VnaCB0aGUgbXVsdGlob3AgZGF0YSBmb3J3YXJkaW5nIG9mIGludGVybWVk aWF0ZSB2ZWhpY2xlcy4NCiAgICAgICBUaHVzLCBJUHY2IG5lZWRzIHRvIGJlIGV4dGVuZGVkIGZv ciBtdWx0aWhvcCBWMkkgY29tbXVuaWNhdGlvbnMuDQoNCiAgICA+Pj4gTm90ZSB0aGF0IEkgaGF2 ZSBubyBjbHVlIG9uIGhvdyB3ZWxsIE9NTkkgYXBwbGllcyBpbiB0aGF0IHNwYWNlLCBtYXliZSBp dA0KICAgIGRvZXMgdmVyeSB3ZWxsOyBidXQgaGVyZSBpdCBjb21lcyBvdXQgb2YgdGhlIGJsdWUg d2l0aCBubyBqdXN0aWZpY2F0aW9uLiBJZiB5b3UNCiAgICBtZW50aW9uIE9NTkkgeW91IG5lZWQg dG8gZGV0YWlsIHdoYXQgaXQgaXMgYW5kIHdoaWNoIG9mIHRoZSBWMlYgIHByb2JsZW1zIHlvdQ0K ICAgIGV4cGVjdCBpdCB0byBzb2x2ZS4gQnV0IHRoZW4sIHRoYXTigJlzIGJleW9uZCB0aGUgc2Nv cGUgb2YgYSBQUy4NCg0KICAgIDxzbmlwPg0KDQogICAgICAgVGhlIGV4aXN0aW5nIElQdjYgcHJv dG9jb2wgbXVzdCBiZSBhdWdtZW50ZWQgdGhyb3VnaCB0aGUgYWRkaXRpb24gb2YNCiAgICAgICBh biBPTU5JIGludGVyZmFjZSBhbmQvb3IgcHJvdG9jb2wgY2hhbmdlcyBpbiBvcmRlciB0byBzdXBw b3J0DQogICAgICAgd2lyZWxlc3MgbXVsdGlob3AgVjJYIChvciBWMkkyWCkgY29tbXVuaWNhdGlv bnMgaW4gYW4gdXJiYW4gcm9hZA0KICAgICAgIG5ldHdvcmsgd2hlcmUgUlNVcyBhcmUgZGVwbG95 ZWQgYXQgaW50ZXJzZWN0aW9ucywgc28gYSB2ZWhpY2xlIChvciBhDQogICAgICAgcGVkZXN0cmlh bidzIHNtYXJ0cGhvbmUpIGNhbiByZWFjaCB0aGUgd2lyZWxlc3MgY292ZXJhZ2Ugb2YgYW4gUlNV DQogICAgICAgdGhyb3VnaCB0aGUgbXVsdGlob3AgZGF0YSBmb3J3YXJkaW5nIG9mIGludGVybWVk aWF0ZSB2ZWhpY2xlcyAob3INCiAgICAgICBwZWRlc3RyaWFucycgc21hcnRwaG9uZXMpLiAgVGh1 cywgSVB2NiBuZWVkcyB0byBiZSBleHRlbmRlZCBmb3INCiAgICAgICBtdWx0aWhvcCBWMlggKG9y IFYySTJYKSBjb21tdW5pY2F0aW9ucy4NCg0KICAgID4+PiBQbGVhc2UgYmUgbW9yZSBzcGVjaWZp YyBvbiB3aGF0IHRoZSBtaXNzaW5nIGZ1bmN0aW9ucyBhcmUgYW5kIHdoZXRoZXIgdGhleQ0KICAg IGFyZSBtaXNzaW5nIGZyb20gdGhlIHN0YWNrIGRldmVsb3BtZW50IHN0YW5kcG9pbnQgb3IgaWYg dGhlcmXigJlzIHdvcmsgbmVlZGVkDQogICAgZnJvbSB0aGUgSUVURi4gMSkgICAgICBJZiBzb21l dGhpbmcgaXMgcmVhbGx5IG1pc3NpbmcgaW4gb3VyIHNwZWNzLCB0aGUgdGV4dCB0bw0KICAgIHBy b3ZlIGZyb20gdGhlIHVzZSBjYXNlIGFib3ZlIGlzIG1pc3NpbmcgMikgICAgICBob3cgT01OSSBz ZXJ2ZXMgdGhlIHVzZSBjYXNlDQogICAgY291bGQgYmUgZWxhYm9yYXRlZCBpbiBhbiBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBvZiBPTU5JIGZvciBWMnh5eiwgYnV0IGl0IGlzDQogICAgYSBiaXQg Ymx1bnQgdG8gcHJlc2VudCBpdCBhcyBwYW5hY2VhIHdoZW4gdGhlIHByb2JsZW1zIHRvIGJlIHNv bHZlZCBhcmUgbm90DQogICAgbGlzdGVkLiAzKSAgICAgIElmIHlvdSBsb29rIGF0IGl0LCBPTU5J IHNlZW1zIGxpa2UgYSBzb2Z0d2FyZSBtb2JpbGUgcm91dGVyDQogICAgd2l0aGluIGEgYnVtcCBp biB0aGUgc3RhY2suIENhbiB0aGF0IGJlY29tZSB0b28gYmlnPw0KDQogICAgPj4+IG15IHZpZXcg aXMgdGhhdCB0aGUgdGV4dCBhYm92ZSBhbmQgdGhlIHNpbWlsYXIgb2NjYXNpb25zIHNob3VsZCBi ZSByZXBsYWNlZA0KICAgIGJ5IHNvbWV0aGluZyBsaWtlIDoNCg0KICAgICAgIFRoZSBleGlzdGlu ZyBJUHY2IHByb3RvY29sIG11c3QgYmUgYXVnbWVudGVkIHRvIHByb3ZpZGUgdGhlIGZvbGxvd2lu Zw0KICAgICAgIGZ1bmN0aW9uczogMSkg4oCmDQoNCiAgICA+Pj4gYW5kIC8gb3Igc29tZXRoaW5n IGxpa2U6DQoNCiAgICAgICBJbiBhZGRpdGlvbiB0byB0aGUgSVB2NiBub2RlIHJlcXVpcmVtZW50 cyBbUkZDIDg1MDRdLCB0aGUgSVB2NiBwcm90b2NvbA0KICAgICAgIHN0YWNrIGZvciB1c2UgaW4g YSB2ZWhpY2xlIG11c3Qgc3VwcG9ydCAxKSBSRkMgYmxhaCwgMikg4oCmDQoNCiAgICA8c25pcD4N Cg0KICAgICAgIFRvIHN1cHBvcnQgYXBwbGljYXRpb25zIG9mIHRoZXNlIFYyWCB1c2UgY2FzZXMs IHRoZSBmdW5jdGlvbnMgb2YgSVB2Ng0KICAgICAgIHN1Y2ggYXMgVk5ELCBWTU0sIGFuZCBWU1Ag YXJlIHByZXJlcXVpc2l0ZXMgZm9yIElQdjYtYmFzZWQgcGFja2V0DQogICAgICAgZXhjaGFuZ2Us IHRyYW5zcG9ydC1sYXllciBzZXNzaW9uIGNvbnRpbnVpdHksIGFuZCBzZWN1cmUsIHNhZmUNCiAg ICAgICBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB2ZWhpY2xlIGFuZCBhIHBlZGVzdHJpYW4gZWl0 aGVyIGRpcmVjdGx5IG9yDQogICAgICAgaW5kaXJlY3RseSB2aWEgYW4gSVAtUlNVLg0KDQogICAg Pj4+IOKAnHRoZSBmdW5jdGlvbnMgb2YgSVB2NiBzdWNoIGFzIFZORCwgVk1NLCBhbmQgVlNQ4oCd IGRvZXMgbm90IHBhcnNlLiBUaGVyZeKAmXMNCiAgICBubyBJUHY2IHJlZmVyZW5jZSB0aGF0IHBy b3ZpZGVzIHRob3NlIGZ1bmN0aW9ucy4gSWYgdGhlIGludGVudGlvbiBpcyB0byBzYXkNCiAgICB0 aGF0IHRoZXJl4oCZcyBzdHVmZiB0byBhZGQgdG8gSVB2NiB0byBzdXBwb3J0LCBsaWtlLCBzYXks ICBWTkQsIHRoZW4gdGhpcw0KICAgIGRvY3VtZW50IGZhaWxzIHRvIGRlZmluZSBob3cgYW4gSVB2 NiBWTkQgc2hvdWxkIGJlaGF2ZSwgdGhvdWdoIGl04oCZcyBwcmVjaXNlbHkNCiAgICB3aGF0IEni gJlkIGV4cGVjdCBmcm9tIGEgcHJvYmxlbSBzdGF0ZW1lbnQuDQoNCiAgICA8c25pcD4NCg0KICAg IDQuICBWZWhpY3VsYXIgTmV0d29ya3MNCg0KICAgID4+PiBXaGF0IGlzIHRoZSBwdXJwb3NlIG9m IHNlY3Rpb24gNCBhcyBhIHdob2xlLCBwcm9ibGVtIHN0YXRlbWVudCBvcg0KICAgIGFwcGxpY2Fi aWxpdHkgc3RhdGVtZW50IG9mIHRoZSBsaXN0ZWQgcHJvdG9jb2xzPyBJbiB0aGUgZm9ybWVyIGNh c2Ugd2hhdOKAmXMgdGhlDQogICAgcHJvYmxlbT8gSW4gdGhlIGxhdHRlciBjYXNlIGl0IGlzIGlu Y29tcGxldGUgYW5kIG5lZWRzIHRvIGJlIGV4cG9ydGVkIHRvIGFuDQogICAgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQgZG9jIHdpdGggYWxsIHRoZSBwb3NzaWJsZSB0ZWNobm9sb2dpZXMgZXZhbHVh dGVkLg0KDQogICAgICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBhbiBleGFtcGxlIHZlaGljdWxh ciBuZXR3b3JrIGFyY2hpdGVjdHVyZQ0KICAgICAgIHN1cHBvcnRpbmcgVjJWLCBWMkksIGFuZCBW MlggY29tbXVuaWNhdGlvbnMgaW4gdmVoaWN1bGFyIG5ldHdvcmtzLg0KDQogICAgPj4+IEkgcmVh ZCB0aGlzIGFzIHByZXNlbnRpbmcgYSBjb250ZXh0IHRvIGV4cGxhaW4gd2hhdCB0aGUgcHJvYmxl bXMgYXJlDQogICAgaW5zdGVhZCBvZiBwcmVzZW50aW5nIHRoZSBJUFZBV0Ug4oCcYXJjaGl0ZWN0 dXJl4oCdLiBNYXliZSB1c2luZyB0aGUgdGVybQ0KICAgIOKAnEFyY2hpdGVjdHVyZeKAnSBoZXJl IGlzIG1pc2xlYWRpbmcgYW5kIGxlZCB0byBCb2LigJlzIGNvbW1lbnQuDQoNCiAgICA8c25pcD4N Cg0KICAgIDQuMS4gIFZlaGljdWxhciBOZXR3b3JrIEFyY2hpdGVjdHVyZQ0KDQogICAgICAgRmln dXJlIDEgc2hvd3MgYW4gZXhhbXBsZSB2ZWhpY3VsYXIgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9y IFYySSBhbmQNCiAgICAgICBWMlYgaW4gYSByb2FkIG5ldHdvcmsgW09NTkldLg0KDQogICAgYS4g ICAgICBJcyB1c2luZyBPTU5JIGEgZGVjaXNpb24gdGhhdCB0aGUgV0cgbWFkZSBmb3IgdGhlIGZ1 dHVyZSB3b3JrID8gd2hhdA0KICAgIGRvZXMgaXQgZG8gYW5kIHdoYXQgZG9lcyBpdCBub3QgZG8/ IGIuICAgICAgSXMgdGhlcmUgd29yayBsZWZ0IHRvIGJlIGRvbmU/IFdobw0KICAgIHdpbGwgZG8g dGhhdCB3b3JrPyBPciBpcyBpdCB0aGUgZXhwZWN0YXRpb24gdGhhdCBPTU5JIGhhcyBpdCBhbGwg ZGVmaW5lZA0KICAgIGFscmVhZHk/DQoNCiAgICA8c25pcD4NCg0KICAgICAgIEFuIGV4aXN0aW5n IG5ldHdvcmsgYXJjaGl0ZWN0dXJlIChlLmcuLCBhbiBJUC1iYXNlZCBhZXJvbmF1dGljYWwNCiAg ICAgICBuZXR3b3JrIGFyY2hpdGVjdHVyZSBbT01OSV1bVUFNLUlUU10sIGEgbmV0d29yayBhcmNo aXRlY3R1cmUgb2YNCiAgICAgICBQTUlQdjYgW1JGQzUyMTNdLCBhbmQgYSBsb3ctcG93ZXIgYW5k IGxvc3N5IG5ldHdvcmsgYXJjaGl0ZWN0dXJlDQogICAgICAgW1JGQzY1NTBdKSBjYW4gYmUgZXh0 ZW5kZWQgdG8gYSB2ZWhpY3VsYXIgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9yDQogICAgICAgbXVs dGlob3AgVjJWLCBWMkksIGFuZCBWMlgsIGFzIHNob3duIGluIEZpZ3VyZSAxLiAgSW4gYSBoaWdo d2F5DQogICAgICAgc2NlbmFyaW8sIGEgdmVoaWNsZSBtYXkgbm90IGFjY2VzcyBhbiBSU1UgZGly ZWN0bHkgYmVjYXVzZSBvZiB0aGUNCiAgICAgICBkaXN0YW5jZSBvZiB0aGUgRFNSQyBjb3ZlcmFn ZSAodXAgdG8gMSBrbSkuICBGb3IgZXhhbXBsZSwgdGhlIE9NTkkNCiAgICAgICBpbnRlcmZhY2Ug YW5kL29yIFJQTCAoSVB2NiBSb3V0aW5nIFByb3RvY29sIGZvciBMb3ctUG93ZXIgYW5kIExvc3N5 DQogICAgICAgTmV0d29ya3MpIFtSRkM2NTUwXSBjYW4gYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBh IG11bHRpaG9wIFYySSBzaW5jZSBhDQogICAgICAgdmVoaWNsZSBjYW4gdGFrZSBhZHZhbnRhZ2Ug b2Ygb3RoZXIgdmVoaWNsZXMgYXMgcmVsYXkgbm9kZXMgdG8gcmVhY2gNCiAgICAgICB0aGUgUlNV LiAgQWxzbywgUlBMIGNhbiBiZSBleHRlbmRlZCB0byBzdXBwb3J0IGJvdGggbXVsdGlob3AgVjJW IGFuZA0KICAgICAgIFYyWCBpbiB0aGUgc2ltaWxhciB3YXkuDQoNCiAgICA+Pj4gYWxsIHRoaXMg Y291bGQgZml0IHdlbGwgaW4gYW5uZXg7IGFueXdheSB5b3UgbmVlZCB0byBleHBsYWluIHdoYXQg eW91DQogICAgZXhwZWN0IHRoZSBwcm90b2NvbHMgdG8gZG8gYW5kIHdoaWNoIGV4dGVuc2lvbiBp cyBuZWVkZWQuIEluIHRoZSBjYXNlIG9mIFJQTCBhdA0KICAgIGxlYXN0IHlvdSBpbmRpY2F0ZSB0 aGF0IGl0IHdvdWxkIGRvIHJvdXRpbmcsIGJ1dCBub3Qgd2h5IHlvdSBjYW5ub3QgdXNlIGl0IG9m DQogICAgdGhlIHNoZWxmOyBmb3IgT01OSSwgd2hhdCB5b3UgZXhwZWN0IGlzIGxlc3MgY2xlYXIs IHRob3VnaCB0aGVyZeKAmXMgdGV4dA0KICAgIGVsc2V3aGVyZSBhYm91dCB0aGUgbWFueSByYWRp byBpbnRlcmZhY2VzIHRoYXQgY291bGQgYmUgdXNlZCBmb3IgdGhlIHB1cnBvc2UsDQogICAgYW5k IHRoZSB0ZXh0IGluIHRoZSBVQU0gYmVsb3cgdGhhdCBpcyBlbmxpZ2h0ZW5pbmcuDQoNCiAgICA8 c25pcD4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUbyBzdXBwb3J0 IG5vdCBvbmx5IHRoZSBtb2JpbGl0eQ0KICAgICAgIG1hbmFnZW1lbnQgb2YgdGhlIFVBTSBlbmQg c3lzdGVtcywgYnV0IGFsc28gdGhlIG11bHRpaG9wIGFuZA0KICAgICAgIG11bHRpbGluayBjb21t dW5pY2F0aW9ucyBvZiB0aGUgVUFNIGludGVyZmFjZXMsIHRoZSBVQU0gZW5kIHN5c3RlbXMNCiAg ICAgICBjYW4gZW1wbG95IGFuIE92ZXJsYXkgTXVsdGlsaW5rIE5ldHdvcmsgKE9NTkkpIGludGVy ZmFjZSBbT01OSV0gYXMgYQ0KICAgICAgIHZpcnR1YWwgTm9uLUJyb2FkY2FzdCBNdWx0aXBsZSBB Y2Nlc3MgKE5CTUEpIGNvbm5lY3Rpb24gdG8gYSBzZXJ2aW5nDQogICAgICAgZ3JvdW5kIGRvbWFp biBpbmZyYXN0cnVjdHVyZS4NCg0KICAgID4+PiBBZ2Fpbiwgd2hhdCBpcyB0aGUgZXhwZWN0YXRp b24gZm9yIE9NTkk/IEFzIGFuIG92ZXJsYXkgaXQgcmVxdWlyZXMgYW4NCiAgICB1bmRlcmxheTsg d2hlbiBjb25uZWN0aW5nIHRvIGEgTUFORVQgaXQgbmVlZHMgc3VwcG9ydCBmb3IgdGhhdCBNQU5F VC4gVGhlIHRleHQNCiAgICBhYm92ZSBzZWVtcyB0byBpbXBseSB0aGF0IGlzIHNvbHZlcyBldmVy eXRoaW5nIGluIFYyeHl6IGxpa2UgbWFnaWM7IHJlbWluZHMgbWUNCiAgICBvZiB0aGUgSVB2NiBt dWx0aWNhc3QgYWJzdHJhY3Rpb24gdGhhdCB3YXMgc3VwcG9zZWQgdG8gc29sdmUgdGhlIGJyb2Fk Y2FzdA0KICAgIHByb2JsZW0gYW5kIGVuZGVkIHVwIHdvcnNlbmluZyBpdC4NCg0KICAgIDxzbmlw Pg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgaW5mcmFzdHJ1Y3R1cmUg Y2FuIGJlIGNvbmZpZ3VyZWQNCiAgICAgICBvdmVyIHRoZSB1bmRlcmx5aW5nIGRhdGEgbGlua3Mu ICBUaGUgT01OSSBpbnRlcmZhY2UgYW5kIGl0cyBsaW5rDQogICAgICAgbW9kZWwgcHJvdmlkZSBh IG1lYW5zIG9mIG11bHRpbGluaywgbXVsdGlob3AgYW5kIG1vYmlsaXR5DQogICAgICAgY29vcmRp bmF0aW9uIHRvIHRoZSBsZWdhY3kgSVB2NiBORCBtZXNzYWdpbmcgW1JGQzQ4NjFdIGFjY29yZGlu ZyB0bw0KICAgICAgIHRoZSBOQk1BIHByaW5jaXBsZS4gIFRodXMsIHRoZSBPTU5JIGxpbmsgbW9k ZWwgY2FuIHN1cHBvcnQgZWZmaWNpZW50DQogICAgICAgVUFNIGludGVybmV0d29ya2luZyBzZXJ2 aWNlcyB3aXRob3V0IGFkZGl0aW9uYWwgbW9iaWxpdHkgbWVzc2FnaW5nLA0KICAgICAgIGFuZCB3 aXRob3V0IGFueSBtb2RpZmljYXRpb24gdG8gdGhlIElQdjYgTkQgbWVzc2FnaW5nIHNlcnZpY2Vz IG9yDQogICAgICAgbGluayBtb2RlbC4NCg0KICAgID4+PiBBZ2Fpbiwgd2hhdCBpcyB0aGUgZXhw ZWN0YXRpb24gZm9yIE9NTkk/IEFzIGFuIG92ZXJsYXkgaXQgcmVxdWlyZXMgYW4NCiAgICB1bmRl cmxheTsgdGhlIHRleHQgYWJvdmUgc2VlbXMgdG8gaW1wbHkgdGhhdCBpcyBzb2x2ZXMgZXZlcnl0 aGluZyBpbiBWMnh5eiBsaWtlDQogICAgbWFnaWM7IHRoYXQgd291bGQgYmUgYSBzdHJldGNoLCB0 aGF0IHJlbWluZHMgbWUgb2YgSVB2NiBtdWx0aWNhc3QgdGhhdCB3YXMNCiAgICBzdXBwb3NlZCB0 byBzb2x2ZSB0aGUgYnJvYWRjYXN0IHByb2JsZW0gYW5kIGVuZGVkIHVwIHdvcnNlbmluZyBpdC4N Cg0KICAgIDxzbmlwPg0KDQogICAgICAgTXVsdGlwbGUgdmVoaWNsZXMgdW5kZXIgdGhlIGNvdmVy YWdlIG9mIGFuIFJTVSBzaGFyZSBhIHByZWZpeCBqdXN0IGFzDQogICAgICAgbW9iaWxlIG5vZGVz IHNoYXJlIGEgcHJlZml4IG9mIGEgV2ktRmkgYWNjZXNzIHBvaW50IGluIGEgd2lyZWxlc3MNCiAg ICAgICBMQU4uICBUaGlzIGlzIGEgbmF0dXJhbCBjaGFyYWN0ZXJpc3RpYyBpbiBpbmZyYXN0cnVj dHVyZS1iYXNlZA0KICAgICAgIHdpcmVsZXNzIG5ldHdvcmtzLiAgRm9yIGV4YW1wbGUsIGluIEZp Z3VyZSAxLCB0d28gdmVoaWNsZXMgKGkuZS4sDQogICAgICAgVmVoaWNsZTIsIGFuZCBWZWhpY2xl NSkgY2FuIHVzZSBQcmVmaXggMSB0byBjb25maWd1cmUgdGhlaXIgSVB2Ng0KICAgICAgIGdsb2Jh bCBhZGRyZXNzZXMgZm9yIFYySSBjb21tdW5pY2F0aW9uLiAgQWx0ZXJuYXRpdmVseSwgbW9iaWxl IG5vZGVzDQogICAgICAgY2FuIGVtcGxveSBhbiBPTU5JIGludGVyZmFjZSBhbmQgdXNlIHRoZWly IG93biBJUHY2IFVuaXF1ZSBMb2NhbA0KICAgICAgIEFkZHJlc3NlcyAoVUxBcykgW1JGQzQxOTNd IG92ZXIgdGhlIHdpcmVsZXNzIG5ldHdvcmsgd2l0aG91dA0KICAgICAgIHJlcXVpcmluZyB0aGUg bWVzc2FnaW5nIG9mIElQdjYgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24NCiAg ICAgIChTTEFBQykgW1JGQzQ4NjJdLCB3aGljaCB1c2VzIGFuIG9uLWxpbmsgcHJlZml4IHByb3Zp ZGVkIGJ5IHRoZQ0KICAgICAgICh2aXNpdGVkKSB3aXJlbGVzcyBMQU47IHRoaXMgdGVjaG5pcXVl IGlzIGtub3duIGFzICJCcmluZy1Zb3VyLU93bi0NCiAgICAgICBBZGRyZXNzZXMiLg0KDQogICAg Pj4+ICBJcyBPTU5JIHRoZSBvbmx5IHdheSB0byAiQnJpbmctWW91ci1Pd24tQWRkcmVzc2Vz4oCd PyBFbHNlIHRoZSB0ZXh0IGNvdWxkIGJlDQogICAgbW9yZSBnZW5lcmljLCBhdCBsZWFzdCB1c2Ug ZS5nLiwgbGlrZSB0aGUgcmVmIHRvIEFFUk8gbGF0ZXIuID4+PiBXaGF0IGFyZSB0aGUNCiAgICBp bXBsaWNhdGlvbnMgLyBsaW1pdGF0aW9ucyBvZiBkb2luZyB0aGF0IOKAkyBsaWtlIHRoZXkgY2Fu IGRvIGxpbmUgb2Ygc2lnaHQgVjJWDQogICAgYnV0IG5vdCByZWFjaCB0aGUgaW50ZXJuZXQsIG9y IHRoZSBuZWVkIG9mICBhIGxvY2FsIE1BTkVUIC8gUlBMIHRoYXQgd2lsbA0KICAgIGFjY2VwdCB0 byByb3V0ZSB0aG9zZSBhZGRyZXNzZXMsIG9yIHRoZSBzZWN1cml0eSAvIGFkZHJlc3Mgb3duZXJz aGlwIHZhbGlkYXRpb24NCiAgICBpc3N1ZXMgPw0KDQogICAgPHNuaXA+DQoNCiAgICAgICBBIHNp bmdsZSBzdWJuZXQgcHJlZml4IGFubm91bmNlZCBieSBhbiBSU1UgY2FuIHNwYW4gbXVsdGlwbGUg dmVoaWNsZXMNCiAgICAgICBpbiBWQU5FVC4gIEZvciBleGFtcGxlLCBpbiBGaWd1cmUgMSwgZm9y IFByZWZpeCAxLCB0aHJlZSB2ZWhpY2xlcw0KICAgICAgIChpLmUuLCBWZWhpY2xlMSwgVmVoaWNs ZTIsIGFuZCBWZWhpY2xlNSkgY2FuIGNvbnN0cnVjdCBhIGNvbm5lY3RlZA0KICAgICAgIFZBTkVU LiAgQWxzbywgZm9yIFByZWZpeCAyLCB0d28gdmVoaWNsZXMgKGkuZS4sIFZlaGljbGUzIGFuZA0K ICAgICAgIFZlaGljbGU2KSBjYW4gY29uc3RydWN0IGFub3RoZXIgY29ubmVjdGVkIFZBTkVULCBh bmQgZm9yIFByZWZpeCAzLA0KICAgICAgIHR3byB2ZWhpY2xlcyAoaS5lLiwgVmVoaWNsZTQgYW5k IFZlaGljbGU3KSBjYW4gY29uc3RydWN0IGFub3RoZXINCiAgICAgICBjb25uZWN0ZWQgVkFORVQu ICBBbHRlcm5hdGl2ZWx5LCBlYWNoIHZlaGljbGUgY291bGQgZW1wbG95IGFuIE9NTkkNCiAgICAg ICBpbnRlcmZhY2Ugd2l0aCB0aGVpciBvd24gVUxBcyBzdWNoIHRoYXQgbm8gdG9wb2xvZ2ljYWxs eS1vcmllbnRlZA0KICAgICAgIHN1Ym5ldCBwcmVmaXhlcyBuZWVkIGJlIGFubm91bmNlZCBieSB0 aGUgUlNVLg0KDQogICAgPj4+ICBzYW1lIGFzIGFib3ZlLiBUaGlzIHNlZW1zIHRvIHJlc3RhdGUg dGhlIHNhbWUgdGhpbmcsIGRlcml2ZSBhbiBhZGRyZXNzDQogICAgZnJvbSBhIHRvcG9sb2dpY2Fs bHkgY29ycmVjdCBwcmVmaXggb3IgdXNlIHlvdXIgb3duIHdpdGggbGltaXRhdGlvbnMgdG8gYmUN CiAgICBkZXNjcmliZWQuDQoNCiAgICA8c25pcD4NCg0KICAgICAgIEZvciBJUHY2IHBhY2tldHMg dHJhbnNwb3J0ZWQgb3ZlciBJRUVFIDgwMi4xMS1PQ0IsIFtSRkM4NjkxXQ0KICAgICAgIHNwZWNp ZmllcyBzZXZlcmFsIGRldGFpbHMsIGluY2x1ZGluZyBNYXhpbXVtIFRyYW5zbWlzc2lvbiBVbml0 IChNVFUpLA0KICAgICAgIGZyYW1lIGZvcm1hdCwgbGluay1sb2NhbCBhZGRyZXNzLCBhZGRyZXNz IG1hcHBpbmcgZm9yIHVuaWNhc3QgYW5kDQogICAgICAgbXVsdGljYXN0LCBzdGF0ZWxlc3MgYXV0 b2NvbmZpZ3VyYXRpb24sIGFuZCBzdWJuZXQgc3RydWN0dXJlLiAgQW4NCiAgICAgICBFdGhlcm5l dCBBZGFwdGF0aW9uIChFQSkgbGF5ZXIgaXMgaW4gY2hhcmdlIG9mIHRyYW5zZm9ybWluZyBzb21l DQogICAgICAgcGFyYW1ldGVycyBiZXR3ZWVuIHRoZSBJRUVFIDgwMi4xMSBNQUMgbGF5ZXIgYW5k IHRoZSBJUHY2IG5ldHdvcmsNCiAgICAgICBsYXllciwgd2hpY2ggaXMgbG9jYXRlZCBiZXR3ZWVu IHRoZSBJRUVFIDgwMi4xMS1PQ0IncyBsb2dpY2FsIGxpbmsNCiAgICAgICBjb250cm9sIGxheWVy IGFuZCB0aGUgSVB2NiBuZXR3b3JrIGxheWVyLiAgVGhpcyBJUHY2IG92ZXIgODAyLjExLU9DQg0K ICAgICAgIGNhbiBiZSB1c2VkIGZvciBib3RoIFYyViBhbmQgVjJJIGluIElQdjYtYmFzZWQgdmVo aWN1bGFyIG5ldHdvcmtzLg0KDQogICAgPj4+ICBzb2x1dGlvbiBzcGFjZS4NCg0KICAgIDxzbmlw Pg0KDQogICAgICAgQW4gSVB2NiBtb2JpbGl0eSBzb2x1dGlvbiBpcyBuZWVkZWQgZm9yIHRoZSBn dWFyYW50ZWUgb2YNCiAgICAgICBjb21tdW5pY2F0aW9uIGNvbnRpbnVpdHkgaW4gdmVoaWN1bGFy IG5ldHdvcmtzIHNvIHRoYXQgYSB2ZWhpY2xlJ3MNCiAgICAgICBUQ1Agc2Vzc2lvbiBjYW4gYmUg Y29udGludWVkLCBvciBVRFAgcGFja2V0cyBjYW4gYmUgZGVsaXZlcmVkIHRvIGENCiAgICAgICB2 ZWhpY2xlIGFzIGEgZGVzdGluYXRpb24gd2l0aG91dCBsb3NzIHdoaWxlIGl0IG1vdmVzIGZyb20g YW4gSVAtUlNVJ3MNCiAgICAgICB3aXJlbGVzcyBjb3ZlcmFnZSB0byBhbm90aGVyIElQLVJTVSdz IHdpcmVsZXNzIGNvdmVyYWdlLiAgSW4NCiAgICAgICBGaWd1cmUgMSwgYXNzdW1pbmcgdGhhdCBW ZWhpY2xlMiBoYXMgYSBUQ1Agc2Vzc2lvbiAob3IgYSBVRFAgc2Vzc2lvbikNCiAgICAgICB3aXRo IGEgY29ycmVzcG9uZGluZyBub2RlIGluIHRoZSB2ZWhpY3VsYXIgY2xvdWQsIFZlaGljbGUyIGNh biBtb3ZlDQogICAgICAgZnJvbSBJUC1SU1UxJ3Mgd2lyZWxlc3MgY292ZXJhZ2UgdG8gSVAtUlNV MidzIHdpcmVsZXNzIGNvdmVyYWdlLiAgSW4NCiAgICAgICB0aGlzIGNhc2UsIGEgaGFuZG92ZXIg Zm9yIFZlaGljbGUyIG5lZWRzIHRvIGJlIHBlcmZvcm1lZCBieSBlaXRoZXIgYQ0KICAgICAgIGhv c3QtYmFzZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBzY2hlbWUgKGUuZy4sIE1JUHY2IFtSRkM2Mjc1 XSkgb3IgYQ0KICAgICAgIG5ldHdvcmstYmFzZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBzY2hlbWUg KGUuZy4sIFBNSVB2NiBbUkZDNTIxM10gYW5kDQogICAgICAgQUVSTyBbUkZDNjcwNkJJU10pLg0K DQogICAgICAgSW4gdGhlIGhvc3QtYmFzZWQgbW9iaWxpdHkgc2NoZW1lIChlLmcuLCBNSVB2Niks IGFuIElQLVJTVSBwbGF5cyBhDQogICAgICAgcm9sZSBvZiBhIGhvbWUgYWdlbnQuICBPbiB0aGUg b3RoZXIgaGFuZCwgaW4gdGhlIG5ldHdvcmstYmFzZWQNCiAgICAgICBtb2JpbGl0eSBzY2hlbWUg KGUuZy4sIFBNSVB2NiwgYW4gTUEgcGxheXMgYSByb2xlIG9mIGEgbW9iaWxpdHkNCiAgICAgICBt YW5hZ2VtZW50IGNvbnRyb2xsZXIgc3VjaCBhcyBhIExvY2FsIE1vYmlsaXR5IEFuY2hvciAoTE1B KSBpbg0KICAgICAgIFBNSVB2Niwgd2hpY2ggYWxzbyBzZXJ2ZXMgdmVoaWNsZXMgYXMgYSBob21l IGFnZW50LCBhbmQgYW4gSVAtUlNVDQogICAgICAgcGxheXMgYSByb2xlIG9mIGFuIGFjY2VzcyBy b3V0ZXIgc3VjaCBhcyBhIE1vYmlsZSBBY2Nlc3MgR2F0ZXdheQ0KICAgICAgIChNQUcpIGluIFBN SVB2NiBbUkZDNTIxM10uICBUaGUgaG9zdC1iYXNlZCBtb2JpbGl0eSBzY2hlbWUgbmVlZHMNCiAg ICAgICBjbGllbnQgZnVuY3Rpb25hbGl0eSBpbiBJUHY2IHN0YWNrIG9mIGEgdmVoaWNsZSBhcyBh IG1vYmlsZSBub2RlIGZvcg0KICAgICAgIG1vYmlsaXR5IHNpZ25hbGluZyBtZXNzYWdlIGV4Y2hh bmdlIGJldHdlZW4gdGhlIHZlaGljbGUgYW5kIGhvbWUNCiAgICAgICBhZ2VudC4gIE9uIHRoZSBv dGhlciBoYW5kLCB0aGUgbmV0d29yay1iYXNlZCBtb2JpbGl0eSBzY2hlbWUgZG9lcyBub3QNCiAg ICAgICBuZWVkIHN1Y2ggYSBjbGllbnQgZnVuY3Rpb25hbGl0eSBmb3IgYSB2ZWhpY2xlIGJlY2F1 c2UgdGhlIG5ldHdvcmsNCiAgICAgICBpbmZyYXN0cnVjdHVyZSBub2RlIChlLmcuLCBNQUcgaW4g UE1JUHY2KSBhcyBhIHByb3h5IG1vYmlsaXR5IGFnZW50DQogICAgICAgaGFuZGxlcyB0aGUgbW9i aWxpdHkgc2lnbmFsaW5nIG1lc3NhZ2UgZXhjaGFuZ2Ugd2l0aCB0aGUgaG9tZSBhZ2VudA0KICAg ICAgIChlLmcuLCBMTUEgaW4gUE1JUHY2KSBmb3IgdGhlIHNha2Ugb2YgdGhlIHZlaGljbGUuDQoN CiAgICAgICBUaGVyZSBhcmUgYSBzY2FsYWJpbGl0eSBpc3N1ZSBhbmQgYSByb3V0ZSBvcHRpbWl6 YXRpb24gaXNzdWUgaW4gdGhlDQogICAgICAgbmV0d29yay1iYXNlZCBtb2JpbGl0eSBzY2hlbWUg KGUuZy4sIFBNSVB2Nikgd2hlbiBhbiBNQSBjb3ZlcnMgYQ0KICAgICAgIGxhcmdlIHZlaGljdWxh ciBuZXR3b3JrIGdvdmVybmluZyBtYW55IElQLVJTVXMuICBJbiB0aGlzIGNhc2UsIGENCiAgICAg ICBkaXN0cmlidXRlZCBtb2JpbGl0eSBzY2hlbWUgKGUuZy4sIERNTSBbUkZDNzQyOV0pIGNhbiBt aXRpZ2F0ZSB0aGUNCiAgICAgICBzY2FsYWJpbGl0eSBpc3N1ZSBieSBkaXN0cmlidXRpbmcgbXVs dGlwbGUgTUFzIGluIHRoZSB2ZWhpY3VsYXINCiAgICAgICBuZXR3b3JrIHN1Y2ggdGhhdCB0aGV5 IGFyZSBwb3NpdGlvbmVkIGNsb3NlciB0byB2ZWhpY2xlcyBmb3Igcm91dGUNCiAgICAgICBvcHRp bWl6YXRpb24gYW5kIGJvdHRsZW5lY2sgbWl0aWdhdGlvbiBpbiBhIGNlbnRyYWwgTUEgaW4gdGhl DQogICAgICAgbmV0d29yay1iYXNlZCBtb2JpbGl0eSBzY2hlbWUuICBBbGwgdGhlc2UgbW9iaWxp dHkgYXBwcm9hY2hlcyAoaS5lLiwNCiAgICAgICBhIGhvc3QtYmFzZWQgbW9iaWxpdHkgc2NoZW1l LCBuZXR3b3JrLWJhc2VkIG1vYmlsaXR5IHNjaGVtZSwgYW5kDQogICAgICAgZGlzdHJpYnV0ZWQg bW9iaWxpdHkgc2NoZW1lKSBhbmQgYSBoeWJyaWQgYXBwcm9hY2ggb2YgYSBjb21iaW5hdGlvbg0K ICAgICAgIG9mIHRoZW0gbmVlZCB0byBwcm92aWRlIGFuIGVmZmljaWVudCBtb2JpbGl0eSBzZXJ2 aWNlIHRvIHZlaGljbGVzDQogICAgICAgbW92aW5nIGZhc3QgYW5kIG1vdmluZyBhbG9uZyB3aXRo IHRoZSByZWxhdGl2ZWx5IHByZWRpY3RhYmxlDQogICAgICAgdHJhamVjdG9yaWVzIGFsb25nIHRo ZSByb2Fkd2F5cy4NCg0KICAgICAgIEluIHZlaGljdWxhciBuZXR3b3JrcywgdGhlIGNvbnRyb2wg cGxhbmUgY2FuIGJlIHNlcGFyYXRlZCBmcm9tIHRoZQ0KICAgICAgIGRhdGEgcGxhbmUgZm9yIGVm ZmljaWVudCBtb2JpbGl0eSBtYW5hZ2VtZW50IGFuZCBkYXRhIGZvcndhcmRpbmcgYnkNCiAgICAg ICB1c2luZyB0aGUgY29uY2VwdCBvZiBTb2Z0d2FyZS1EZWZpbmVkIE5ldHdvcmtpbmcgKFNETikN CiAgICAgICBbUkZDNzE0OV1bRE1NLUZQQ10uICBOb3RlIHRoYXQgRm9yd2FyZGluZyBQb2xpY3kg Q29uZmlndXJhdGlvbiAoRlBDKQ0KICAgICAgIGluIFtETU0tRlBDXSwgd2hpY2ggaXMgYSBmbGV4 aWJsZSBtb2JpbGl0eSBtYW5hZ2VtZW50IHN5c3RlbSwgY2FuDQogICAgICAgbWFuYWdlIHRoZSBz ZXBhcmF0aW9uIG9mIGRhdGEtcGxhbmUgYW5kIGNvbnRyb2wtcGxhbmUgaW4gRE1NLiAgSW4NCiAg ICAgICBTRE4sIHRoZSBjb250cm9sIHBsYW5lIGFuZCBkYXRhIHBsYW5lIGFyZSBzZXBhcmF0ZWQg Zm9yIHRoZSBlZmZpY2llbnQNCiAgICAgICBtYW5hZ2VtZW50IG9mIGZvcndhcmRpbmcgZWxlbWVu dHMgKGUuZy4sIHN3aXRjaGVzIGFuZCByb3V0ZXJzKSB3aGVyZQ0KICAgICAgIGFuIFNETiBjb250 cm9sbGVyIGNvbmZpZ3VyZXMgdGhlIGZvcndhcmRpbmcgZWxlbWVudHMgaW4gYSBjZW50cmFsaXpl ZA0KICAgICAgIHdheSBhbmQgdGhleSBwZXJmb3JtIHBhY2tldCBmb3J3YXJkaW5nIGFjY29yZGlu ZyB0byB0aGVpciBmb3J3YXJkaW5nDQogICAgICAgdGFibGVzIHRoYXQgYXJlIGNvbmZpZ3VyZWQg YnkgdGhlIFNETiBjb250cm9sbGVyLiAgQW4gTUEgYXMgYW4gU0RODQogICAgICAgY29udHJvbGxl ciBuZWVkcyB0byBlZmZpY2llbnRseSBjb25maWd1cmUgYW5kIG1vbml0b3IgaXRzIElQLVJTVXMg YW5kDQogICAgICAgdmVoaWNsZXMgZm9yIG1vYmlsaXR5IG1hbmFnZW1lbnQsIGxvY2F0aW9uIG1h bmFnZW1lbnQsIGFuZCBzZWN1cml0eQ0KICAgICAgIHNlcnZpY2VzLg0KDQogICAgICAgVGhlIG1v YmlsaXR5IGluZm9ybWF0aW9uIG9mIGEgR1BTIHJlY2VpdmVyIG1vdW50ZWQgaW4gaXRzIHZlaGlj bGUNCiAgICAgICAoZS5nLiwgcG9zaXRpb24sIHNwZWVkLCBhbmQgZGlyZWN0aW9uKSBjYW4gYmUg dXNlZCB0byBhY2NvbW1vZGF0ZQ0KICAgICAgIG1vYmlsaXR5LWF3YXJlIHByb2FjdGl2ZSBoYW5k b3ZlciBzY2hlbWVzLCB3aGljaCBjYW4gcGVyZm9ybSB0aGUNCiAgICAgICBoYW5kb3ZlciBvZiBh IHZlaGljbGUgYWNjb3JkaW5nIHRvIGl0cyBtb2JpbGl0eSBhbmQgdGhlIHdpcmVsZXNzDQogICAg ICAgc2lnbmFsIHN0cmVuZ3RoIG9mIGEgdmVoaWNsZSBhbmQgYW4gSVAtUlNVIGluIGEgcHJvYWN0 aXZlIHdheS4NCg0KICAgICAgIFZlaGljbGVzIGNhbiB1c2UgdGhlIFRDQyBhcyB0aGVpciBIb21l IE5ldHdvcmsgaGF2aW5nIGEgaG9tZSBhZ2VudA0KICAgICAgIGZvciBtb2JpbGl0eSBtYW5hZ2Vt ZW50IGFzIGluIE1JUHY2IFtSRkM2Mjc1XSBhbmQgUE1JUHY2IFtSRkM1MjEzXSwNCiAgICAgICBz byB0aGUgVENDIChvciBhbiBNQSBpbnNpZGUgdGhlIFRDQykgbWFpbnRhaW5zIHRoZSBtb2JpbGl0 eQ0KICAgICAgIGluZm9ybWF0aW9uIG9mIHZlaGljbGVzIGZvciBsb2NhdGlvbiBtYW5hZ2VtZW50 LiAgSVAgdHVubmVsaW5nIG92ZXINCiAgICAgICB0aGUgd2lyZWxlc3MgbGluayBzaG91bGQgYmUg YXZvaWRlZCBmb3IgcGVyZm9ybWFuY2UgZWZmaWNpZW5jeS4NCiAgICAgICBBbHNvLCBpbiB2ZWhp Y3VsYXIgbmV0d29ya3MsIGFzeW1tZXRyaWMgbGlua3Mgc29tZXRpbWVzIGV4aXN0IGFuZA0KICAg ICAgIG11c3QgYmUgY29uc2lkZXJlZCBmb3Igd2lyZWxlc3MgY29tbXVuaWNhdGlvbnMgc3VjaCBh cyBWMlYgYW5kIFYySS4NCg0KICAgID4+PiAgVGhpcyBpcyBhbGwgdmVyeSBpbmZvcm1hdGl2ZSB0 ZXh0IGJ1dCBkb2VzIG5vdCBzdGF0ZSBhIHByb2JsZW0uIElzIHRoZXJlIGENCiAgICBwcm9ibGVt IGlzIGxlZnQgdG8gYmUgc29sdmVkIG9yIGFyZSB3ZSBhc3Nlc3NpbmcgdGhlIGFwcGxpY2FiaWxp dHkgb2YNCiAgICBwcm90b2NvbHM/IENvdWxkIGl0IGZvciBpbnN0YW5jZSwgZm9yd2FyZCBwb2lu dCB0byBpc3N1ZXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24NCiAgICA1Pw0KDQogICAgPHNuaXA+DQoN CiAgICAgICBBcyBzaG93biBpbiBGaWd1cmUgMywgYXMgaW50ZXJuYWwgbmV0d29ya3MsIGEgdmVo aWNsZSdzIG1vdmluZw0KICAgICAgIG5ldHdvcmsgYW5kIGFuIEVOJ3MgZml4ZWQgbmV0d29yayBh cmUgc2VsZi1jb250YWluZWQgbmV0d29ya3MgaGF2aW5nDQogICAgICAgbXVsdGlwbGUgc3VibmV0 cyBhbmQgaGF2aW5nIGFuIGVkZ2Ugcm91dGVyIChlLmcuLCBJUC1PQlUgYW5kIElQLVJTVSkNCiAg ICAgICBmb3IgdGhlIGNvbW11bmljYXRpb24gd2l0aCBhbm90aGVyIHZlaGljbGUgb3IgYW5vdGhl ciBFTi4gIFRoZQ0KICAgICAgIGludGVybmV0d29ya2luZyBiZXR3ZWVuIHR3byBpbnRlcm5hbCBu ZXR3b3JrcyB2aWEgVjJJIGNvbW11bmljYXRpb24NCiAgICAgICByZXF1aXJlcyB0aGUgZXhjaGFu Z2Ugb2YgdGhlIG5ldHdvcmsgcGFyYW1ldGVycyBhbmQgdGhlIG5ldHdvcmsNCiAgICAgICBwcmVm aXhlcyBvZiB0aGUgaW50ZXJuYWwgbmV0d29ya3MuICBGb3IgdGhlIGVmZmljaWVuY3ksIHRoZSBu ZXR3b3JrDQogICAgICAgcHJlZml4ZXMgb2YgdGhlIGludGVybmFsIG5ldHdvcmtzIChhcyBhIG1v dmluZyBuZXR3b3JrKSBpbiBhIHZlaGljbGUNCiAgICAgICBuZWVkIHRvIGJlIGRlbGVnYXRlZCBh bmQgY29uZmlndXJlZCBhdXRvbWF0aWNhbGx5LiAgTm90ZSB0aGF0IGENCiAgICAgICBtb3Zpbmcg bmV0d29yaydzIG5ldHdvcmsgcHJlZml4IGNhbiBiZSBjYWxsZWQgYSBNb2JpbGUgTmV0d29yayBQ cmVmaXgNCiAgICAgICAoTU5QKSBbT01OSV0uDQoNCiAgICA+Pj4gVGhlbiBhZ2FpbiB5b3XigJly ZSBvdmVyc2VsbGluZyBPTU5JLiBNTlAgaXMgb3JpZ2luYWxseSBkZWZpbmVkIGhlcmUNCiAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzM5NjMjc2VjdGlvbi0yIGFu ZCB0aGF04oCZcyBhIHJlZmVyZW5jZQ0KICAgIHlvdSBjYW4gdXNlIG5vcm1hdGl2ZWx5Lg0KDQog ICAgPHNuaXA+DQoNCiAgICAgICBBcyBzaG93biBpbiBGaWd1cmUgMywgdGhlIGFkZHJlc3NlcyB1 c2VkIGZvciBJUHY2IHRyYW5zbWlzc2lvbnMgb3Zlcg0KICAgICAgIHRoZSB3aXJlbGVzcyBsaW5r IGludGVyZmFjZXMgZm9yIElQLU9CVSBhbmQgSVAtUlNVIGNhbiBiZSBlaXRoZXINCiAgICAgICBn bG9iYWwgSVB2NiBhZGRyZXNzZXMsIG9yIElQdjYgVUxBcyBhcyBsb25nIGFzIElQdjYgcGFja2V0 cyBjYW4gYmUNCiAgICAgICByb3V0ZWQgd2l0aGluIHZlaGljdWxhciBuZXR3b3JrcyBbT01OSV0u DQoNCiAgICA+Pj4gVGhlbiBhZ2FpbiB5b3XigJlyZSBvdmVyc2VsbGluZyBPTU5JLiBUaGVyZSBu ZWVkcyB0byAgYmUgYSByb3V0aW5nIHByb3RvY29sDQogICAgbGlrZSBhIE1BTkVUIHRoYXQgd2ls bCBhY2NlcHQgdG8gY2FycnkgdGhlDQogICAgIE1OUHMsIGFuZCB0aGF0IG11c3QgYmUgaW1wbGVt ZW50ZWQgYnkgdGhlIGluZnJhIGFuZCBib3RoIGNhcnMuIFRoZSBPTU5JIHNwZWMNCiAgICAgaXMg Y2xlYXIgb24gdGhhdC4gVGhpcyBpcyB3aHkgYXQgZmlyc3QgZ2xhbmNlIEkgc2VlIE9NTkkgYXMg YSBmdWxsIG1vYmlsZQ0KICAgICByb3V0ZXIgaW4gYSBidW1wIGluIHRoZSBzdGFjay4gTm93IHdo YXQgaXMgdGhlIHByb2JsZW0gYmVoaW5kIHRoaXM/IE5vIHN1Y2gNCiAgICAgcHJvdG9jb2wgYXQg SUVURj8gVG9vIG1hbnkgdG8gY2hvb3NlIGZyb20/IE5vIGRlcGxveW1lbnQ/DQogICAgPHNuaXA+ DQoNCiAgICBXaGVuIGdsb2JhbCBJUHY2IGFkZHJlc3Nlcw0KICAgICAgIGFyZSB1c2VkLCB3aXJl bGVzcyBpbnRlcmZhY2UgY29uZmlndXJhdGlvbiBhbmQgY29udHJvbCBvdmVyaGVhZCBmb3INCiAg ICAgICBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gKERBRCkgW1JGQzQ4NjJdIGFuZCBNdWx0 aWNhc3QgTGlzdGVuZXINCiAgICAgICBEaXNjb3ZlcnkgKE1MRCkgW1JGQzI3MTBdW1JGQzM4MTBd IHNob3VsZCBiZSBtaW5pbWl6ZWQgdG8gc3VwcG9ydCBWMkkNCiAgICAgICBhbmQgVjJYIGNvbW11 bmljYXRpb25zIGZvciB2ZWhpY2xlcyBtb3ZpbmcgZmFzdCBhbG9uZyByb2Fkd2F5czsgd2hlbg0K ICAgICAgIFVMQXMgYW5kIHRoZSBPTU5JIGludGVyZmFjZSBhcmUgdXNlZCwgbm8gREFEIG5vciBN TEQgbWVzc2FnaW5nIGlzDQogICAgICAgbmVlZGVkLg0KDQogICAgPj4+IFRoZW4gYWdhaW4geW91 4oCZcmUgb3ZlcnNlbGxpbmcgT01OSS4gSXNu4oCZdCBpdCB0aGUgbm8gZGFkIG5lZWRlZCBhIHBy b3BlcnR5DQogICAgb2YgaW5qZWN0aW5nIGEgQllPQSBpbiB0aGUgZmFicmljIGZvciBhbiBHVUEg TUlQIEhvbWUgQWRkcmVzcyB3aGljaCBpcyBrbm93biB0bw0KICAgIGJlIHVuaXF1ZSBhdCBob21l PyA+Pj4gT1RPSCwgYXV0b2NvbmbigJlpbmcgYSByYW5kb20gVUxBIOKAnEZE4oCm4oCdcHJlZml4 IGhhcyBsZXNzZXINCiAgICBEQUQgcHJvcGVydGllcyB0aGFuIGF1dG9jb25m4oCZaW5nIGEgcmFu ZG9tIDY0Yml0IElJRCBpbiBhIGNsYXNzaWNhbCBzdWJuZXQuIFNvDQogICAgd2hvIHNheXMgREFE IGlzbuKAmXQgcmVxdWlyZWQgZm9yIE9NTkkgVUxBPyA+Pj4gbm90ZSB0aGF0IElNSE8gREFEIG9u IHdpcmVsZXNzIGlzDQogICAgYSBsb3QgbW9yZSBoYXJtIHRoYW4gZ29vZCwgYW5kIEkgYWdyZWUg dGhhdCB3aXRoIGEgZ29vZCBwc2V1ZG8gcmFuZG9tIGdlbmVyYXRvcg0KICAgIHRoZSBVTEEgaGFz IG5vIGNoYW5jZSB0byBjb2xsaXNpb24gaW4gdGhlIHJlYWwgd29ybGQsIGFzIE9NTkkgY2xhaW1z LiBJdOKAmXMganVzdA0KICAgIHRoYXQgeW91ciBhcmd1bWVudCBoZXJlIHBsYXlzIHRoZSBvdGhl ciB3YXksIGJlY2F1c2UgdGhlcmUgYXJlIGxlc3MgcmFuZG9tIGJpdHMNCiAgICAoNTYpICBpbiB0 aGUgVUxBIHByZWZpeCB0aGFuIGluIHRoZSBJSUQgKDYyKSwgYW5kIGlmIG9uZSBzdGFydHMgdXNp bmcgbW9yZQ0KICAgIHByZWZpeCBiaXRzIHRvIGJlIG5vbi1yYW5kb20sIHRoZXJlIHdpbGwgYmUg YSB0aW1lIHdoZW4gREFEIG9uIHByZWZpeCBpcyBuZWVkZWQuDQoNCiAgICA8c25pcD4NCg0KICAg ICAgIExldCB1cyBjb25zaWRlciB0aGUgdXBsb2FkL2Rvd25sb2FkIHRpbWUgb2YgYSB2ZWhpY2xl IHdoZW4gaXQgcGFzc2VzDQogICAgICAgdGhyb3VnaCB0aGUgd2lyZWxlc3MgY29tbXVuaWNhdGlv biBjb3ZlcmFnZSBvZiBhbiBJUC1SU1UuICBGb3IgYQ0KICAgICAgIGdpdmVuIHR5cGljYWwgc2V0 dGluZyB3aGVyZSAxa20gaXMgdGhlIG1heGltdW0gRFNSQyBjb21tdW5pY2F0aW9uDQogICAgICAg cmFuZ2UgW0RTUkNdIGFuZCAxMDBrbS9oIGlzIHRoZSBzcGVlZCBsaW1pdCBpbiBoaWdod2F5LCB0 aGUgZHdlbGxpbmcNCiAgICAgICB0aW1lIGNhbiBiZSBjYWxjdWxhdGVkIHRvIGJlIDcyIHNlY29u ZHMgYnkgZGl2aWRpbmcgdGhlIGRpYW1ldGVyIG9mDQogICAgICAgdGhlIDJrbSAoaS5lLiwgdHdv IHRpbWVzIG9mIERTUkMgY29tbXVuaWNhdGlvbiByYW5nZSB3aGVyZSBhbiBJUC1SU1UNCiAgICAg ICBpcyBsb2NhdGVkIGluIHRoZSBjZW50ZXIgb2YgdGhlIGNpcmNsZSBvZiB3aXJlbGVzcyBjb21t dW5pY2F0aW9uKSBieQ0KICAgICAgIHRoZSBzcGVlZCBsaW1pdCBvZiAxMDBrbS9oIChpLmUuLCBh Ym91dCAyOG0vcykuICBGb3IgdGhlIDcyIHNlY29uZHMsDQogICAgICAgYSB2ZWhpY2xlIHBhc3Np bmcgdGhyb3VnaCB0aGUgY292ZXJhZ2Ugb2YgYW4gSVAtUlNVIGNhbiB1cGxvYWQgYW5kDQogICAg ICAgZG93bmxvYWQgZGF0YSBwYWNrZXRzIHRvL2Zyb20gdGhlIElQLVJTVS4NCg0KICAgIDxzbmlw Pg0KDQogICAgNC4zLiAgVjJWLWJhc2VkIEludGVybmV0d29ya2luZw0KDQogICAgPj4+IEluIHRo aXMgc2VjdGlvbiBpdCBsb29rcyBsaWtlIHRoZSBjYXJzIGFyZSBpbiBhIHN0YWJsZSBsaW5lIG9m IHNpZ2h0DQogICAgcmVsYXRpb25zaGlwLiBXaGljaCBpcyBwcm9iYWJseSBmaW5lIGZvciBhIHBs YXRvb24sIGJ1dCB3aGVuIHlvdSBkcml2ZSBhbG9uZw0KICAgIHdpdGggZnJpZW5kcyBpbiBkaWZm ZXJlbnQgY2FycywgeW91IHJlYWxpemUgdGhhdCB0aGUgbGluZSBvZiBzaWdodCBhc3N1bXB0aW9u DQogICAgZG9lcyBub3Qgc3RhbmQgb3ZlciB0aW1lLiBTb29uIGVub3VnaCwgb3RoZXIgY2FycyBt ZWRkbGUgaW4sIGFuZCBwb3NzaWJseSBvbmUNCiAgICBvZiB0aGUgY2FycyBkcml2ZXMgZmFzdGVy IGFuZCB0b28gZmFyIGFoZWFkIHNvIHlvdSBuZWVkIHRoZSBpbmZyYSB0byByZWxheSwNCiAgICBw b3NzaWJseSBvdmVyIG11bHRpcGxlIGluZnJhIGhvcHMuDQoNCiAgICA+Pj4gc28gaW4gdGhpcyBz ZWN0aW9uLCBJ4oCZZCBleHBlY3QgdG8gc2VlIGEgVmVoaWNsZSBjb21tdW5pY2F0aW5nIHdpdGgg YW5vdGhlcg0KICAgIG9uZSBhbmQgdXNpbmcgZWl0aGVyIGxpbmUgb2Ygc2lnaHQgb3IgVjJWIHJl bGF5aW5nIGJ1dCBhbHNvIHVzaW5nIHJlbGF5IHZpYSBWMkkNCiAgICAobXVsdGlob3AgSTJJIG5v dCBqdXN0IGh1YiBhbmQgc3Bva2UgVjJJMlYgKSwgYWx0ZXJuYXRpdmVseSB0byB0b2dldGhlciBm b3INCiAgICByZWR1bmRhbmN5LiBJcyB0aGF0IHBhcnQgb2YgdGhlIHByb2JsZW0/DQoNCiAgICA+ Pj4gcmVhZGluZyBkZWVwZXIgc2VjdGlvbiA1IEkgZm91bmQgZXhjZWxsZW50IHRleHQgb24gcm91 dGluZyB2aWEgViBhbmQgdmlhIEkuDQogICAgVGhpcyB0ZWxscyB0aGF0IHNlY3Rpb24gNCBkb2Vz IG5vdCBwbGF5IGEgZ29vZCByb2xlIGF0IGp1c3RpZnlpbmcgc2VjdGlvbiA1Lg0KICAgIE1heWJl IGtlZXAgc2VjdGlvbiA0IGZvciBhbm90aGVyIGRvYz8NCg0KICAgID4+PiBXaGF0IGtpbmQgb3Ig cmVsaWFiaWxpdHkgaXMgcmVxdWlyZWQgaW4gYSBWMlYgdXNlIGNhc2U/IERvIHlvdSB0aGluayBO RCBjYW4NCiAgICBoYW5kbGUgaXQ/IE9yIE1BTkVUPyBXaGF0IHdvdWxkIGJlIHRoZSBhc3N1bXB0 aW9uIG9uIEwyIChyb2FtaW5nIHRpbWUsIHVuaWNhc3QNCiAgICB2cyBQMk1QKSBhbmQgb24gTDMg KHJlbGlhYmlsaXR5IGFsYSBEZXROZXQvUkFXKS4gU2hvdWxkIHdlIGhhdmUgc29tZSBMMyANCiAg ICByZWR1bmRhbmN5Pw0KDQogICAgPHNuaXA+DQoNCiAgICA1LiAgUHJvYmxlbSBTdGF0ZW1lbnQN Cg0KICAgIDxzbmlwPg0KDQogICAgICAgSW4gb3JkZXIgdG8gc3BlY2lmeSBwcm90b2NvbHMgdXNp bmcgdGhlIGFyY2hpdGVjdHVyZSBtZW50aW9uZWQgaW4NCiAgICAgICBTZWN0aW9uIDQuMSwgSVB2 NiBjb3JlIHByb3RvY29scyBoYXZlIHRvIGJlIGFkYXB0ZWQgdG8gb3ZlcmNvbWUNCiAgICAgICBj ZXJ0YWluIGNoYWxsZW5naW5nIGFzcGVjdHMgb2YgdmVoaWN1bGFyIG5ldHdvcmtpbmcuICBTaW5j ZSB0aGUNCiAgICAgICB2ZWhpY2xlcyBhcmUgbGlrZWx5IHRvIGJlIG1vdmluZyBhdCBncmVhdCBz cGVlZCwgcHJvdG9jb2wgZXhjaGFuZ2VzDQogICAgICAgbmVlZCB0byBiZSBjb21wbGV0ZWQgaW4g YSB0aW1lIHJlbGF0aXZlbHkgc2hvcnQgY29tcGFyZWQgdG8gdGhlDQogICAgICAgbGlmZXRpbWUg b2YgYSBsaW5rIGJldHdlZW4gYSB2ZWhpY2xlIGFuZCBhbiBJUC1SU1UsIG9yIGJldHdlZW4gdHdv DQogICAgICAgdmVoaWNsZXMuDQoNCiAgICA+Pj4gQW55IG9yZGVyIG9mIG1hZ25pdHVkZT8NCiAg ICA+Pj4gQ2FuIHlvdSBpbmRpY2F0ZSB3aGV0aGVyIHRoaXMgYWxyZWFkeSBydWxlcyBvdXQgY2Vy dGFpbiBwcm9jZWR1cmVzLCBlLmcuDQogICAgREFEID8NCg0KICAgICAgIFRoZSBsaWZldGltZSBv ZiBhIHNlc3Npb24gdmFyaWVzIGRlcGVuZGluZyBvbiB0aGUgc2Vzc2lvbidzIHR5cGUgc3VjaA0K ICAgICAgIGFzIGEgd2ViIHN1cmZpbmcsIHZvaWNlIGNhbGwgb3ZlciBJUCwgYW5kIEROUyBxdWVy eS4gIFJlZ2FyZGxlc3Mgb2YgYQ0KICAgICAgIHNlc3Npb24ncyB0eXBlLCB0byBndWlkZSBhbGwg dGhlIElQdjYgcGFja2V0cyB0byB0aGVpciBkZXN0aW5hdGlvbg0KICAgICAgIGhvc3QsIElQIG1v YmlsaXR5IHNob3VsZCBiZSBzdXBwb3J0ZWQgZm9yIHRoZSBzZXNzaW9uLg0KDQogICAgPj4+IHRo aXMgc2VlbXMgdG8gYmUgZm9yIHVuaWNhc3Qgd2hlbiB5b3Uga25vdyB3aG8gdG8gdGFsayB0by4g SXMgdGhlcmUgYSBuZWVkDQogICAgc29tZSBtdWx0aWNhc3QgZ3JvdXBzIGxpa2UgYW55Ym9keSBh cm91bmQgaW50ZXJlc3RlZCBpbiB0b3BpYyBibGFoIGxpa2UgSSBjb3VsZA0KICAgIGJlIG11bHRp Y2FzdGluZyB0aGUgc3BlZWQgb2YgdmVoaWNsZXMgY29taW5nIHRoZSBvdGhlciB3YXkgdGhhdCBJ IGNyb3NzZWQNCiAgICByZWNlbnRseSwgZm9yIHVzZSBvZiB2ZWhpY2xlcyB0aGF0IEnigJltIGNy b3NzaW5nIG5vdywgc28gdGhleSBjYW4gc2VlIGEgc2xvd2Rvd24NCiAgICBvbiBhZHZhbmNlDQoN CiAgICAgICBUaHVzLCB0aGUgdGltZSBjb25zdHJhaW50IG9mIGEgd2lyZWxlc3MgbGluayBoYXMg YSBtYWpvciBpbXBhY3Qgb24NCiAgICAgICBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSAoTkQpLiAg TW9iaWxpdHkgTWFuYWdlbWVudCAoTU0pIGlzIGFsc28NCiAgICAgICB2dWxuZXJhYmxlIHRvIGRp c2Nvbm5lY3Rpb25zIHRoYXQgb2NjdXIgYmVmb3JlIHRoZSBjb21wbGV0aW9uIG9mDQogICAgICAg aWRlbnRpdHkgdmVyaWZpY2F0aW9uIGFuZCB0dW5uZWwgbWFuYWdlbWVudC4gIFRoaXMgaXMgZXNw ZWNpYWxseSB0cnVlDQogICAgICAgZ2l2ZW4gdGhlIHVucmVsaWFibGUgbmF0dXJlIG9mIHdpcmVs ZXNzIGNvbW11bmljYXRpb24uICBUaGlzIHNlY3Rpb24NCiAgICAgICBwcmVzZW50cyBrZXkgdG9w aWNzIHN1Y2ggYXMgbmVpZ2hib3IgZGlzY292ZXJ5IGFuZCBtb2JpbGl0eQ0KICAgICAgIG1hbmFn ZW1lbnQuDQoNCiAgICA+Pj4gT25seSBORD8gV2hhdCBhYm91dCB0aGUgTUFORVQ/DQogICAgPj4+ IGhvdyBmYXN0IHNob3VsZCBORCBiZSB0byBiZSBzdWl0YWJsZT8NCiAgICA+Pj4gaXMgdGhlcmUg YWxzbyBhIGJhbmR3aWR0aCBjaGVjaz8gWW91IGNhbiBtYWtlIHRoaW5ncyBtdWNoIGZhc3RlciBp ZiB5b3UNCiAgICBkZWRpY2F0ZSBhIGxvdCBvZiBzcGVjdHJ1bSB0byBpdC4gQnV0IHRoYXQgY2Fu IGFsc28gYmUgYSB3YXN0ZS4NCg0KICAgIDUuMS4gIE5laWdoYm9yIERpc2NvdmVyeQ0KDQogICAg PHNuaXA+DQoNCiAgICAgICBUaGUgcmVxdWlyZW1lbnRzIGZvciBJUHY2IE5EIGZvciB2ZWhpY3Vs YXIgbmV0d29ya3MgYXJlIGVmZmljaWVudCBEQUQNCiAgICAgICBhbmQgTlVEIG9wZXJhdGlvbnMu DQoNCiAgICA+Pj4gTm90IGxvb2t1cD8gSXMgaXQgdGhlIGludGVudGlvbiB0byB1c2UgSVAgdW5p Y2FzdCBvdmVyIE1BQyBicm9hZGNhc3QsIHdoaWNoDQogICAgaXMgYSBnb29kIGlkZWEgaW4gbXkg Ym9vaz8NCg0KICAgICA8c25pcD4NCg0KICAgICAgICAgIFRoaXMgbWVyZ2luZyBhbmQgcGFydGl0 aW9uaW5nIHNob3VsZCBiZSBjb25zaWRlcmVkIGZvciB0aGUNCiAgICAgICBJUHY2IE5EIHN1Y2gg YXMgSVB2NiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiAoU0xBQUMpDQogICAg ICAgW1JGQzQ4NjJdLg0KDQogICAgPj4+IE5vdCBsb29rdXA/IElzIGl0IHRoZSBpbnRlbnRpb24g dG8gdXNlIElQIHVuaWNhc3Qgb3ZlciBNQUMgYnJvYWRjYXN0LCB3aGljaA0KICAgIGlzIGEgZ29v ZCBpZGVhIGluIG15IGJvb2s/DQoNCiAgICAgPHNuaXA+DQoNCiAgICAgICBBbHNvLCB0aGUgcGFy dGl0aW9uaW5nIG9mIGEgVkFORVQgbWF5IG1ha2UgdmVoaWNsZXMgd2l0aCB0aGUgc2FtZQ0KICAg ICAgIHByZWZpeCBiZSBwaHlzaWNhbGx5IHVucmVhY2hhYmxlLiAgQWxzbywgU0xBQUMgbmVlZHMg dG8gcHJldmVudCBJUHY2DQogICAgICAgYWRkcmVzcyBkdXBsaWNhdGlvbiBkdWUgdG8gdGhlIG1l cmdpbmcgb2YgVkFORVRzLiAgQWNjb3JkaW5nIHRvIHRoZQ0KICAgICAgIG1lcmdpbmcgYW5kIHBh cnRpdGlvbmluZywgYSBkZXN0aW5hdGlvbiB2ZWhpY2xlIChhcyBhbiBJUHY2IGhvc3QpDQogICAg ICAgbmVlZHMgdG8gYmUgZGlzdGluZ3Vpc2hlZCBhcyBlaXRoZXIgYW4gb24tbGluayBob3N0IG9y IGFuIG9mZi1saW5rDQogICAgICAgaG9zdCBldmVuIHRob3VnaCB0aGUgc291cmNlIHZlaGljbGUg dXNlcyB0aGUgc2FtZSBwcmVmaXggYXMgdGhlDQogICAgICAgZGVzdGluYXRpb24gdmVoaWNsZS4N Cg0KICAgID4+PiBzaG91bGQgcmVmZXJlbmNlIHRvIGRyYWZ0LW5vcmRtYXJrLWludGFyZWEtaXBw bA0KDQogICAgICAgVG8gZWZmaWNpZW50bHkgcHJldmVudCBJUHY2IGFkZHJlc3MgZHVwbGljYXRp b24gZHVlIHRvIHRoZSBWQU5FVA0KICAgICAgIHBhcnRpdGlvbmluZyBhbmQgbWVyZ2luZyBmcm9t IGhhcHBlbmluZyBpbiB2ZWhpY3VsYXIgbmV0d29ya3MsIHRoZQ0KICAgICAgIHZlaGljdWxhciBu ZXR3b3JrcyBuZWVkIHRvIHN1cHBvcnQgYSB2ZWhpY3VsYXItbmV0d29yay13aWRlIERBRCBieQ0K ICAgICAgIGRlZmluaW5nIGEgc2NvcGUgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggdGhlIGxlZ2Fj eSBEQUQuICBJbiB0aGlzDQogICAgICAgY2FzZSwgdHdvIHZlaGljbGVzIGNhbiBjb21tdW5pY2F0 ZSB3aXRoIGVhY2ggb3RoZXIgd2hlbiB0aGVyZSBleGlzdHMNCiAgICAgICBhIGNvbW11bmljYXRp b24gcGF0aCBvdmVyIFZBTkVUIG9yIGEgY29tYmluYXRpb24gb2YgVkFORVRzIGFuZCBJUC0NCiAg ICAgICBSU1VzLCBhcyBzaG93biBpbiBGaWd1cmUgMS4gIEJ5IHVzaW5nIHRoZSB2ZWhpY3VsYXIt bmV0d29yay13aWRlIERBRCwNCiAgICAgICB2ZWhpY2xlcyBjYW4gYXNzdXJlIHRoYXQgdGhlaXIg SVB2NiBhZGRyZXNzZXMgYXJlIHVuaXF1ZSBpbiB0aGUNCiAgICAgICB2ZWhpY3VsYXIgbmV0d29y ayB3aGVuZXZlciB0aGV5IGFyZSBjb25uZWN0ZWQgdG8gdGhlIHZlaGljdWxhcg0KICAgICAgIGlu ZnJhc3RydWN0dXJlIG9yIGJlY29tZSBkaXNjb25uZWN0ZWQgZnJvbSBpdCBpbiB0aGUgZm9ybSBv ZiBWQU5FVC4NCg0KICAgID4+PiBFeGNlbGxlbnQNCg0KICAgICAgIE5EIHRpbWUtcmVsYXRlZCBw YXJhbWV0ZXJzIHN1Y2ggYXMgcm91dGVyIGxpZmV0aW1lIGFuZCBOZWlnaGJvcg0KICAgICAgIEFk dmVydGlzZW1lbnQgKE5BKSBpbnRlcnZhbCBuZWVkIHRvIGJlIGFkanVzdGVkIGZvciB2ZWhpY2xl IHNwZWVkIGFuZA0KICAgICAgIHZlaGljbGUgZGVuc2l0eS4gIEZvciBleGFtcGxlLCB0aGUgTkEg aW50ZXJ2YWwgbmVlZHMgdG8gYmUNCiAgICAgICBkeW5hbWljYWxseSBhZGp1c3RlZCBhY2NvcmRp bmcgdG8gYSB2ZWhpY2xlJ3Mgc3BlZWQgc28gdGhhdCB0aGUNCiAgICAgICB2ZWhpY2xlIGNhbiBt YWludGFpbiBpdHMgbmVpZ2hib3JpbmcgdmVoaWNsZXMgaW4gYSBzdGFibGUgd2F5LA0KICAgICAg IGNvbnNpZGVyaW5nIHRoZSBjb2xsaXNpb24gcHJvYmFiaWxpdHkgd2l0aCB0aGUgTkEgbWVzc2Fn ZXMgc2VudCBieQ0KICAgICAgIG90aGVyIHZlaGljbGVzLg0KDQogICAgPj4+IElzIHRoYXQgYSBw cm9ibGVtIG9yIGp1c3QgYW4gb3BlcmF0aW9uYWwgc2V0dGluZyB0aGF0IG5lZWRzIHRvIGJlIGZv dW5kPw0KICAgID4+PiBEbyB3ZSBuZWVkIHRvIHJlY29uc2lkZXIgdGhlIGNvbmNlcHRzIG9mIHRo b3NlIHRpbWVycz8NCg0KICAgIDxzbmlwPg0KDQogICAgICAgVGh1cywgaW4gSVB2Ni1iYXNlZCB2 ZWhpY3VsYXIgbmV0d29ya2luZywgSVB2NiBORCBzaG91bGQgaGF2ZSBtaW5pbXVtDQogICAgICAg Y2hhbmdlcyBmb3IgdGhlIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGUgbGVnYWN5IElQdjYgTkQg dXNlZCBpbiB0aGUNCiAgICAgICBJbnRlcm5ldCwgaW5jbHVkaW5nIHRoZSBEQUQgYW5kIE5VRCBv cGVyYXRpb25zLg0KDQogICAgPj4+IEkgZG8gbm90IGZpbmQgdGhlIGxvZ2ljYWwgbGluayB3aXRo IHRoZSB0ZXh0IGJlZm9yZSwgd2h5IGlzIHRoaXMgYSDigJx0aHVz4oCdPw0KICAgID4+PiB3aHkg c2hvdWxkIHRoZSBORCBpbnNpZGUgdGhlIFZBTkVUIGJlIGNvbnN0cmFpbmVkIHRvIGJlIGludGVy b3BlcmFibGU/IFRoaXMNCiAgICBtYXkgcGxhY2UgY29uc3RyYWludHMgb24gdGhlIHNvbHV0aW9u Lg0KDQogICAgNS4xLjEuICBMaW5rIE1vZGVsDQoNCiAgICAgICBBIHByZWZpeCBtb2RlbCBmb3Ig YSB2ZWhpY3VsYXIgbmV0d29yayBuZWVkcyB0byBmYWNpbGl0YXRlIHRoZQ0KDQogICAgPj4+IERv IHlvdSBtZWFuIGEg4oCcc3VibmV0IG1vZGVs4oCdIGFzIG9wcG9zZWQgdG8g4oCccHJlZml4IG1v ZGVs4oCdLg0KICAgID4+PiBpdCB3b3VsZCBtYWtlIHRoaXMgcGllY2UgYW5kIHRoZSBuZXh0IHNo b3VsZCByZWZlciB0bw0KICAgIGRyYWZ0LXRodWJlcnQtNm1hbi1pcHY2LW92ZXItd2lyZWxlc3Mg Zm9yIElQdjYgb3ZlciBQMk1QIC9OQk1BLCBmb3IgYm90aCBsaW5rDQogICAgYW5kIHN1Ym5ldCBp c3N1ZXMuIFRoZSBnZW5lcmFsIGlkZWFzIGFyZSB0aGUgc2FtZSwgYnV0IHRoZSBnb3J5IGRldGFp bHMgaGVyZQ0KICAgIGFyZSBzbGlnaHRseSBpbmNvcnJlY3QsIGxpa2UgdGhpcyBub3Rpb24gb2Yg cHJlZml4IG1vZGVsIHRoYW4gY29tZXMgb3V0IG9mIHRoZQ0KICAgIGJsdWUuIFRoZSBtb2RlbCBp cyByZWFsbHkgdGhlIHN1Ym5ldCBtb2RlbCBmb3IgdGhlIHN1Ym5ldCBhc3NvY2lhdGVkIHRvIFAy TVAuDQoNCiAgICAgICBjb21tdW5pY2F0aW9uIGJldHdlZW4gdHdvIHZlaGljbGVzIHdpdGggdGhl IHNhbWUgcHJlZml4IHJlZ2FyZGxlc3Mgb2YNCiAgICAgICB0aGUgdmVoaWN1bGFyIG5ldHdvcmsg dG9wb2xvZ3kgYXMgbG9uZyBhcyB0aGVyZSBleGlzdCBiaWRpcmVjdGlvbmFsDQogICAgICAgRTJF IHBhdGhzIGJldHdlZW4gdGhlbSBpbiB0aGUgdmVoaWN1bGFyIG5ldHdvcmsgaW5jbHVkaW5nIFZB TkVUcyBhbmQNCiAgICAgICBJUC1SU1VzLiAgVGhpcyBwcmVmaXggbW9kZWwgYWxsb3dzIHZlaGlj bGVzIHdpdGggdGhlIHNhbWUgcHJlZml4IHRvDQogICAgICAgY29tbXVuaWNhdGUgd2l0aCBlYWNo IG90aGVyIHZpYSBhIGNvbWJpbmF0aW9uIG9mIG11bHRpaG9wIFYyViBhbmQNCiAgICAgICBtdWx0 aWhvcCBWMkkgd2l0aCBWQU5FVHMgYW5kIElQLVJTVXMuICBOb3RlIHRoYXQgdGhlIE9NTkkgaW50 ZXJmYWNlDQogICAgICAgc3VwcG9ydHMgYW4gTkJNQSBsaW5rIG1vZGVsIHdoZXJlIG11bHRpaG9w IFYyViBhbmQgVjJJIGNvbW11bmljYXRpb25zDQogICAgICAgdXNlIGVhY2ggbW9iaWxlIG5vZGUn cyBVTEFzIHdpdGhvdXQgbmVlZCBmb3IgYW55IERBRCBvciBNTEQNCiAgICAgICBtZXNzYWdpbmcu DQoNCiAgICA+Pj4gYWdhaW4gb3ZlcnNlbGxpbmcgT01OSS4NCiAgICA+Pj4gSSBraW5kYSBhZ3Jl ZSBhYm91dCB0aGUgT01OSSBpbnRlcmZhY2UgbW9kZWwsIG5vdGhpbmcgYWdhaW5zdCB0aGF0LiBC dXQgeW91DQogICAgbXVzdCBzZWUgdGhhdCB0aGVyZSBuZWVkcyBhIGxvdCBtb3JlIHRoYW4gd2hh dCB0aGUgT01OSSBpbnRlcmZhY2UgdG8gZ2V0DQogICAgcGFja2V0cyBhY3Jvc3MgViBhbmQgSSBo b3BzIHRvIHRoZSBkZXN0aW5hdGlvbi4gTGlrZSByb3V0aW5nIGFsYSBNQU5FVCwNCiAgICByZWR1 bmRhbmN5IGhhbmRsaW5nIGFsYSBEZXROZXQgYmVjYXVzZSBpdCB3aWxsIGJlIHZlcnkgbG9zc3ks IHBhdGggbWFuYWdlbWVudA0KICAgIGFsYSBSQVcgdG8gb3B0aW1pemUgZGVsaXZlcnkgdnMuIHNw ZWN0cnVt4oCmIEFuZCBPTU5JIGlnbm9yZXMgTkQgc28gaXQgZG9lcyBub3QNCiAgICBzb2x2ZSB0 aGUgTkQgcHJvYmxlbXMgYWJvdmUuDQoNCiAgICAgICBJUHY2IHByb3RvY29scyB3b3JrIHVuZGVy IGNlcnRhaW4gYXNzdW1wdGlvbnMgdGhhdCBkbyBub3QgbmVjZXNzYXJpbHkNCiAgICAgICBob2xk IGZvciB2ZWhpY3VsYXIgd2lyZWxlc3MgYWNjZXNzIGxpbmsgdHlwZXMgb3RoZXIgdGhhbiBPTU5J L05CTUENCiAgICAgICBbVklQLVdBVkVdW1JGQzU4ODldOyB0aGUgcmVzdCBvZiB0aGlzIHNlY3Rp b24gZGlzY3Vzc2VzIGltcGxpY2F0aW9ucw0KICAgICAgIGZvciB0aG9zZSBsaW5rIHR5cGVzIHRo YXQgZG8gbm90IGFwcGx5IHdoZW4gdGhlIE9NTkkvTkJNQSBsaW5rIG1vZGVsDQoNCiAgICA+Pj4g YWdhaW4gb3ZlcnNlbGxpbmcgT01OSS4NCiAgICA+Pj4gVGhlIGtleXdvcmQgaGVyZSBpcyBQMk1Q IC8gTkJNQSwgYW5kIE9NTkkgaXMgb25lIGludGVyZmFjZSB0aGF0IGFjY2VwdHMNCiAgICB0aGF0 LiBUaGVyZSBhcmUgb3RoZXJzLiBJQk3igJlzIElQdjQgb3ZlciBGcmFtZSByZWxheSB3YXMgYWxy ZWFkeSBQMk1QIC8gTkJNQSwNCiAgICB1c2luZyByb3V0aW5nIHRvIGNvbXBsZXRlIHRoZSBwYXJ0 aWFsIG1lc2ggaW4gUDJNUC4gVGhlIHRleHQgc2VlbXMgdG8gaW1wbHkNCiAgICB0aGF0IE9NTkkg aXMgdGhlIG9ubHkgd2F5IHRvIGRvIHRoYXQgYW5kIHRoYXTigJlzIHdyb25nLiBBbHNvIE9NTkkg aXMgbG9hZGVkIHdpdGgNCiAgICBvdGhlciBzdHVmZiB0aGFuIGEgcGxhaW4gUDJNUCBjYXBhYmxl IGludGVyZmFjZS4gQW5kIE5EIG92ZXIgUDJNUCBpcyBub3QgZG9uZQ0KICAgIGJ5IE9NTkksIE9N Tkkgb25seSBtYWtlcyBjbGFzc2ljYWwgTkQgd29yc2UgYW5kIG9ubHkgd29ya3MgaW4gYSBmdWxs IG1lc2guIE9UT0gNCiAgICBSRkMgODUwNSwgd2hpY2ggaXMgZGVzaWduZWQgdG8gZG8gTkQgZm9y IFAyTVAgL05CTUEgd291bGQgaW5kZWVkIHdvcmsgdmVyeSB3ZWxsDQogICAgd2l0aGluIGFuIE9N TkkgaW50ZXJmYWNlIGFuZCBzb2x2ZSB0aG9zZSBwcm9ibGVtcy4gPj4+IE15IHBvaW50IGlzIHRo YXQgeW91DQogICAgbmVlZCB0byB0ZWxsIHRoZSBmdWxsIHN0b3J5IG9yIHJlZnJhaW4gZnJvbSBl bnRlcmluZyBzb2x1dGlvbiBzcGFjZSBpbiB0aGlzIGRvYw0KDQogICAgPHNuaXA+DQoNCiAgICAg ICBUaGVyZSBpcyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgbGluayBhbmQgYSBwcmVmaXgsIGJl c2lkZXMgdGhlDQogICAgICAgZGlmZmVyZW50IHNjb3BlcyB0aGF0IGFyZSBleHBlY3RlZCBmcm9t IHRoZSBsaW5rLWxvY2FsIGFuZCBnbG9iYWwNCiAgICAgICB0eXBlcyBvZiBJUHY2IGFkZHJlc3Nl cy4gIEluIGFuIElQdjYgbGluaywgaXQgaXMgYXNzdW1lZCB0aGF0IGFsbA0KICAgICAgIGludGVy ZmFjZXMgd2hpY2ggYXJlIGNvbmZpZ3VyZWQgd2l0aCB0aGUgc2FtZSBzdWJuZXQgcHJlZml4IGFu ZCB3aXRoDQogICAgICAgb24tbGluayBiaXQgc2V0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIGVhY2gg b3RoZXIgb24gYW4gSVB2NiBsaW5rLg0KDQogICAgPj4+IG5vdCBhc3N1bWVkOyB0aGF04oCZcyB3 aGF0IHRoZSBvbmxpbmsgYnV0IHNldCB0ZWxscy4gVGhlIGNvbmNsdXNpb24gc2hvdWxkIGJlDQog ICAgdGhhdCB0aGUgVkFORVQgY2Fubm90IHNldCB0aGUgTyBiaXQuDQoNCiAgICAgICBIb3dldmVy LCB0aGUgdmVoaWN1bGFyIGxpbmsgbW9kZWwgbmVlZHMgdG8gZGVmaW5lIHRoZSByZWxhdGlvbnNo aXANCiAgICAgICBiZXR3ZWVuIGEgbGluayBhbmQgYSBwcmVmaXgsIGNvbnNpZGVyaW5nIHRoZSBk eW5hbWljcyBvZiB3aXJlbGVzcw0KICAgICAgIGxpbmtzIGFuZCB0aGUgY2hhcmFjdGVyaXN0aWNz IG9mIFZBTkVULg0KDQogICAgPHNuaXA+DQoNCiAgICAgICBGcm9tIHRoZSBwcmV2aW91cyBvYnNl cnZhdGlvbiwgYSB2ZWhpY3VsYXIgbGluayBtb2RlbCBzaG91bGQgY29uc2lkZXINCiAgICAgICB0 aGUgZnJlcXVlbnQgcGFydGl0aW9uaW5nIGFuZCBtZXJnaW5nIG9mIFZBTkVUcyBkdWUgdG8gdmVo aWNsZQ0KICAgICAgIG1vYmlsaXR5LiAgVGhlcmVmb3JlLCB0aGUgdmVoaWN1bGFyIGxpbmsgbW9k ZWwgbmVlZHMgdG8gdXNlIGFuIG9uLQ0KICAgICAgIGxpbmsgcHJlZml4IGFuZCBvZmYtbGluayBw cmVmaXggYWNjb3JkaW5nIHRvIHRoZSBuZXR3b3JrIHRvcG9sb2d5IG9mDQogICAgICAgdmVoaWNs ZXMgc3VjaCBhcyBhIG9uZS1ob3AgcmVhY2hhYmxlIG5ldHdvcmsgYW5kIGEgbXVsdGlob3AgcmVh Y2hhYmxlDQoNCiAgICA+Pj4gTm8sIHRoZSBvbmNlIGEgbm9kZSBzYXcgYSBPIGJpdCBzZXQgdGhh dCBzdGlja3MgZXZlbiBpZiBpdCBzZWVzIG90aGVyDQogICAgYWR2ZXJ0aXNlbWVudHMgb2YgdGhl IFBJTyB3aXRoIHRoZSBPIGJpdCBub3Qgc2V0LiA+Pj4gVGhpcyBpcyBhIGdsb2JhbCBhbmQNCiAg ICBpbnRyaW5zaWMgcHJvcGVydHkgb2YgdGhlIHByZWZpeCAoYW5kIGFuIGF0dGFjayB2ZWN0b3Ig dGhhdCBjb3VsZCBiZSBtZW50aW9uZWQNCiAgICBpbiB0aGUgc2VjIHNlY3Rpb24pLiA+Pj4gdGhl IFZBTkVUIHByZWZpeCBtdXN0IG5ldmVyIGNvbWUgd2l0aCB0aGUgTyBiaXQgc2V0Lg0KDQogICAg PHNuaXA+DQoNCiAgICAgICBuZXR3b3JrIChvciBwYXJ0aXRpb25lZCBuZXR3b3JrcykuICBJZiB0 aGUgdmVoaWNsZXMgd2l0aCB0aGUgc2FtZQ0KICAgICAgIHByZWZpeCBhcmUgcmVhY2hhYmxlIGZy b20gZWFjaCBvdGhlciBpbiBvbmUgaG9wLCB0aGUgcHJlZml4IHNob3VsZCBiZQ0KICAgICAgIG9u LWxpbmsuDQoNCiAgICA+Pj4+IE5vLCBzZWUgYWJvdmU7IGJ1dCB0aGUgcm91dGVyIG1heSByZWRp cmVjdCB0aG91Z2ggaXQgaXMgcmVhbGx5IHJpc2t5DQogICAgdW5sZXNzIHRoaXMgaXMgYSBzdGFi bGUgc2l0dWF0aW9uIGxpa2UgYSBwYXJraW5nIHBsYWNlLg0KDQogICAgICAgVGh1cywgaW4gSVB2 Ni1iYXNlZCB2ZWhpY3VsYXIgbmV0d29ya2luZywgdGhlIHZlaGljdWxhciBsaW5rIG1vZGVsDQog ICAgICAgc2hvdWxkIGhhdmUgbWluaW11bSBjaGFuZ2VzIGZvciBpbnRlcm9wZXJhYmlsaXR5IHdp dGggc3RhbmRhcmQgSVB2Ng0KICAgICAgIGxpbmtzIGluIGFuIGVmZmljaWVudCBmYXNoaW9uIHRv IHN1cHBvcnQgSVB2NiBEQUQsIE1MRCBhbmQgTlVEDQogICAgICAgb3BlcmF0aW9ucy4gIFdoZW4g dGhlIE9NTkkgTkJNQSBsaW5rIG1vZGVsIGlzIHVzZWQsIHRoZXJlIGFyZSBubyBsaW5rDQogICAg ICAgbW9kZWwgY2hhbmdlcyBub3IgREFEL01MRCBtZXNzYWdpbmcgcmVxdWlyZWQuDQoNCiAgICA+ Pj4+IGFnYWluIG92ZXJzZWxsaW5nIE9NTkkuDQogICAgPj4+PiBZb3UgbmVlZCBhIGdvb2QgUDJN UCBzdWJuZXQgbW9kZWwgd2l0aCByb3V0aW5nIHN1cHBvcnQgd2hlbiB0aGUgbWVzaCBpcw0KICAg IHBhcnRpYWwuIE15IGNvbXBhbnkgYWxvbmUgaGFzIGJlZW4gc2hpcHBpbmcgbWlsbGlvbiBvZiBu b2RlcyB0aGF0IGJ1aWxkIHN1Ym5ldHMNCiAgICBvZiB0aG91c2FuZHMsIGFuZCB0aGF0IHdhcyBk b25lIHVzaW5nIElFVEYgc3RhbmRhcmRzLg0KDQogICAgPHNuaXA+DQoNCiAgICAgICBGb3IgdmVo aWN1bGFyIG5ldHdvcmtzIHdpdGggaGlnaCBtb2JpbGl0eSBhbmQgZGVuc2l0eSwgdGhlIERBRCBu ZWVkcw0KICAgICAgIHRvIGJlIHBlcmZvcm1lZCBlZmZpY2llbnRseSB3aXRoIG1pbmltdW0gb3Zl cmhlYWQgc28gdGhhdCB0aGUNCiAgICAgICB2ZWhpY2xlcyBjYW4gZXhjaGFuZ2UgYSBkcml2aW5n IHNhZmV0eSBtZXNzYWdlIChlLmcuLCBjb2xsaXNpb24NCiAgICAgICBhdm9pZGFuY2UgYW5kIGFj Y2lkZW50IG5vdGlmaWNhdGlvbikgd2l0aCBlYWNoIG90aGVyIHdpdGggYSBzaG9ydA0KICAgICAg IGludGVydmFsIChlLmcuLCAwLjUgc2Vjb25kKSBieSBhIHRlY2huaWNhbCByZXBvcnQgZnJvbSBO SFRTQQ0KICAgICAgIChOYXRpb25hbCBIaWdod2F5IFRyYWZmaWMgU2FmZXR5IEFkbWluaXN0cmF0 aW9uKSBbTkhUU0EtQUNBUy1SZXBvcnRdLg0KICAgICAgIFN1Y2ggYSBkcml2aW5nIHNhZmV0eSBt ZXNzYWdlIG1heSBpbmNsdWRlIGEgdmVoaWNsZSdzIG1vYmlsaXR5DQogICAgICAgaW5mb3JtYXRp b24gKGkuZS4sIHBvc2l0aW9uLCBzcGVlZCwgZGlyZWN0aW9uLCBhbmQgYWNjZWxlcmF0aW9uLw0K ICAgICAgIGRlY2VsZXJhdGlvbikuICBUaGUgZXhjaGFuZ2UgaW50ZXJ2YWwgb2YgdGhpcyBtZXNz YWdlIGlzIDAuNSBzZWNvbmQsDQogICAgICAgd2hpY2ggaXMgcmVxdWlyZWQgdG8gYWxsb3cgYSBk cml2ZXIgdG8gYXZvaWQgYSByZWFyLWVuZCBjcmFzaCBmcm9tDQogICAgICAgYW5vdGhlciB2ZWhp Y2xlLg0KDQogICAgPj4+IElQdjYgb3ZlciBicm9hZGNhc3QgTUFDICh1c2VkIHRvIGJlIGNhbGxl ZCBpbnRlcm5ldCAwLCAxMCsgeWVhcnMgYWdvKQ0KICAgIHNvbHZlcyB0aGF0IE1BQyBpc3N1ZSBz aW5jZSB0aGVyZSBpcyBubyBNQUMuDQoNCiAgICA1LjEuMy4gIFJvdXRpbmcNCg0KICAgICAgIEZv ciBtdWx0aWhvcCBWMlYgY29tbXVuaWNhdGlvbnMgaW4gZWl0aGVyIGEgVkFORVQgb3IgVkFORVRz IHZpYSBJUC0NCiAgICAgICBSU1VzLCBhIHZlaGljdWxhciBNb2JpbGUgQWQgSG9jIE5ldHdvcmtz IChNQU5FVCkgcm91dGluZyBwcm90b2NvbCBtYXkNCiAgICAgICBiZSByZXF1aXJlZCB0byBzdXBw b3J0IGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0IGluIHRoZSBsaW5rcyBvZiB0aGUNCiAgICAg ICBzdWJuZXQgd2l0aCB0aGUgc2FtZSBJUHY2IHByZWZpeC4gIEhvd2V2ZXIsIGl0IHdpbGwgYmUg Y29zdGx5IHRvIHJ1bg0KICAgICAgIGJvdGggdmVoaWN1bGFyIE5EIGFuZCBhIHZlaGljdWxhciBh ZCBob2Mgcm91dGluZyBwcm90b2NvbCBpbiB0ZXJtcyBvZg0KICAgICAgIGNvbnRyb2wgdHJhZmZp YyBvdmVyaGVhZCBbSUQtTXVsdGljYXN0LVByb2JsZW1zXS4NCg0KICAgID4+PiB3ZSBkbyB0aGF0 IHdpdGggSUVURiBzdGFuZGFyZHMgb24gYmF0dGVyeSBvcGVyYXRlZCBkZXZpY2VzIGFscmVhZHku IFVzaW5nDQogICAgUkZDIDg1MDUgZm9yIHRoZSBVTkkgYW5kIFJQTCBmb3IgdGhlIE5OSS4gSXQg aXMgc2NhbGFibGUgKHdl4oCZdmUgc2VlbiAzMCBob3BzIGluDQogICAgbWVzaGVzIG9mIHRob3Vz YW5kcyBpbiB0aGUgcmVhbCB3b3JsZCB0aG91Z2ggaXTigJlzIG5vdCB0aGUgbm9ybWFsIG9wZXJh dGlvbmFsDQogICAgbW9kZWwsIGJ1dCBjYW4gaGFwcGVuIHRvIG1haW50YWluIGNvbm5lY3Rpdml0 eSBkdXJpbmcgdGhlIHJlYm9vdCBvZiBhIHJvb3QpIGFuZA0KICAgIGRvZXMgbm90IHVzZSBicm9h ZGNhc3QuIFJQTCB3YXMgaW5pdGlhbGx5IGRlc2lnbmVkIGFzIGEgVjJWMlYgcHJvdG9jb2wgYnV0 DQogICAgZm91bmQgaXRzIG1hcmtldCBvbiB0aGUgSW9ULiBJ4oCZbSBzdXJlIHRoZSBwcm90b2Nv bCB3b3VsZCBnbGFkbHkgY29tZSBiYWNrIHRvDQogICAgaXRzIHJvb3RzLg0KDQogICAgICAgQSBy b3V0aW5nIHByb3RvY29sIGZvciBhIFZBTkVUIG1heSBjYXVzZSByZWR1bmRhbnQgd2lyZWxlc3Mg ZnJhbWVzIGluDQogICAgICAgdGhlIGFpciB0byBjaGVjayB0aGUgbmVpZ2hib3Job29kIG9mIGVh Y2ggdmVoaWNsZSBhbmQgY29tcHV0ZSB0aGUNCiAgICAgICByb3V0aW5nIGluZm9ybWF0aW9uIGlu IGEgVkFORVQgd2l0aCBhIGR5bmFtaWMgbmV0d29yayB0b3BvbG9neQ0KICAgICAgIGJlY2F1c2Ug dGhlIElQdjYgTkQgaXMgdXNlZCB0byBjaGVjayB0aGUgbmVpZ2hib3Job29kIG9mIGVhY2gNCiAg ICAgICB2ZWhpY2xlLiAgVGh1cywgdGhlIHZlaGljdWxhciByb3V0aW5nIG5lZWRzIHRvIHRha2Ug YWR2YW50YWdlIG9mIHRoZQ0KICAgICAgIElQdjYgTkQgdG8gbWluaW1pemUgaXRzIGNvbnRyb2wg b3ZlcmhlYWQuDQoNCiAgICA+Pj4gQSBjbGVhbiBkZXNjcmlwdGlvbiBvZiB0aGUgaW50ZXJhY3Rp b24gb2YgUlBMIGFuZCBSRkMgODUwNSBpbiBvdXIgSW9UDQogICAgbmV0d29ya3MuIE5vdGUgdGhh dCB0aGUgc3BlZWQgb2YgdGhlIFBIWSBpbiBWQU5FVCBiYWxhbmNlZCB0aGUgaW5zdGFiaWxpdHkg b2YNCiAgICB0aGUgdG9wb2xvZ3ksIGFuZCBSUEwgc3RpbGwgYXBwbGllcy4gTm90ZSBhbHNvIHRo YXQgUlBMIHVzZXMgRFYgd2l0aCBhIHJvdXRpbmcNCiAgICBzdHJldGNoIGluIG9yZGVyIHRvIG1p bmltaXplIHRoZSB0b3BvbG9neSBhd2FyZW5lc3MgdGhhdOKAmXMgbmVlZGVkIGluIGVhY2ggbm9k ZSwNCiAgICB3aGljaCByZXN1bHRzIGluIG1pbmltYWwgc2lnbmFsaW5nLg0KDQogICAgNS4yLiAg TW9iaWxpdHkgTWFuYWdlbWVudA0KDQogICAgPHNuaXA+DQoNCiAgICAgICBGb3IgYSBtb2JpbGl0 eSBtYW5hZ2VtZW50IHNjaGVtZSBpbiBhIHNoYXJlZCBsaW5rLCB3aGVyZSB0aGUgd2lyZWxlc3MN CiAgICAgICBzdWJuZXRzIG9mIG11bHRpcGxlIElQLVJTVXMgc2hhcmUgdGhlIHNhbWUgcHJlZml4 LCBhbiBlZmZpY2llbnQNCiAgICAgICB2ZWhpY3VsYXItbmV0d29yay13aWRlIERBRCBpcyByZXF1 aXJlZC4gIElmIERIQ1B2NiBpcyB1c2VkIHRvIGFzc2lnbg0KICAgICAgIGEgdW5pcXVlIElQdjYg YWRkcmVzcyB0byBlYWNoIHZlaGljbGUgaW4gdGhpcyBzaGFyZWQgbGluaywNCg0KICAgID4+PiBJ IHdvdWxkIG5vdCB1c2UgdGhlIHRlcm0gbGluaywgb3Igc2hhcmVkLiBNYXliZSBzaGFyZWQgbGlu ayAtPiBkb21haW4/DQogICAgPHNuaXA+DQoNCiAgICB0aGUgREFEIGlzDQogICAgICAgbm90IHJl cXVpcmVkLiAgT24gdGhlIG90aGVyIGhhbmQsIGZvciBhIG1vYmlsaXR5IG1hbmFnZW1lbnQgc2No ZW1lDQogICAgICAgd2l0aCBhIHVuaXF1ZSBwcmVmaXggcGVyIG1vYmlsZSBub2RlIChlLmcuLCBQ TUlQdjYgW1JGQzUyMTNdIGFuZCBPTU5JDQogICAgICAgW09NTkldKSwgREFEIGlzIG5vdCByZXF1 aXJlZCBiZWNhdXNlIHRoZSBJUHY2IGFkZHJlc3Mgb2YgYSB2ZWhpY2xlJ3MNCiAgICAgICBleHRl cm5hbCB3aXJlbGVzcyBpbnRlcmZhY2UgaXMgZ3VhcmFudGVlZCB0byBiZSB1bmlxdWUuDQoNCiAg ICA+Pj4gYWdhaW4gb3ZlcnNlbGxpbmcgT01OSQ0KICAgID4+PiBBcyBJIHNhaWQgZWFybGllciwg dGhpcyBpcyB3cmluZyB0aGVyZSBhcmUgKDY0KikgbW9yZSBjaGFuY2VzIG9mIGENCiAgICBjb2xs aXNpb24gaW4gT01OSSBwcmVmaXhlcyB0aGFuIGluIElQdjYgSUlEcy4gPj4+IE9NTkkgcHJlZml4 ZXMgY2FuIGNvbGxpc2lvbiwNCiAgICBob21lIGFkZHJlc3NlcyB0aGF0IGFyZSB1bmlxdWUgb24g YSBob21lIG5ldHdvcmsgY2Fubm90LiA+Pj4gTm93IGlmIGJvdGggdGhlDQogICAgT01OSSBwcmVm aXggYW5kIHRoZSBJSUQgYXJlIGdvb2QgcmFuZG9tcywgdGhlbiBvYnZpb3VzbHksIHRoZSBjaGFu Y2VzIG9mDQogICAgY29sbGlzaW9ucyByb3VuZCB1cCB0byAwLiA+Pj4gQ29sbGlzaW9uIGlzIGNl cnRhaW5seSBub3QgbXkgd29yc3QgZmVhci4NCg0KICAgICAgVGhlcmUgaXMgYQ0KICAgICAgIHRy YWRlb2ZmIGJldHdlZW4gdGhlIHByZWZpeCB1c2FnZSBlZmZpY2llbmN5IGFuZCBEQUQgb3Zlcmhl YWQuICBUaHVzLA0KICAgICAgIHRoZSBJUHY2IGFkZHJlc3MgYXV0b2NvbmZpZ3VyYXRpb24gZm9y IHZlaGljdWxhciBuZXR3b3JrcyBuZWVkcyB0bw0KICAgICAgIGNvbnNpZGVyIHRoaXMgdHJhZGVv ZmYgdG8gc3VwcG9ydCBlZmZpY2llbnQgbW9iaWxpdHkgbWFuYWdlbWVudC4NCg0KICAgID4+PiBU aGlzIGlzIHdheSB0b28gc3VwZXJmaWNpYWwgYW5kIGhpZGVzIHRoZSByZWFsaXR5IG9mIHRoaW5n cy4NCiAgICAtIFVzaW5nIGEgVkFORVQgSW5mcmEgcHJlZml4IGFsbG93cyBkaXJlY3Qgcm91dGFi aWxpdHkgdG8gdGhlIGludGVybmV0IHdoaWNoDQogICAgQllPQSBkb2VzIG5vdCBzaW5jZSB0aGUg QllPQSBpcyBub3QgdG9wb2xvZ2ljYWxseSBjb3JyZWN0LiBZZXMsIGl0IGNvc3RzIGEgREFEDQog ICAgd2l0aCBjbGFzc2ljIE5ELCBidXQgaXQgZG9lcyBub3Qgd2l0aCBSQ0Y4NTA1IGFuZCB0aGUg ZHJhZnQgZmFpbHMgdG8gbWVudGlvbg0KICAgIHRoYXQuIC0gQSBCWU9BIG5lZWRzIGEgdHVubmVs IGhvbWUsIGFuZCB0aGUgbm9kZSBuZWVkcyB0byBrbm93IHdobyBpcyByZWFjaGFibGUNCiAgICBp bnNpZGUgdGhlIFZBTkVUIGFuZCB3aGF0IGlzIG5vdCB0byBkZWNpZGUgdG8gdHVubmVsIG9yIG5v dDsgdGhpcyBpcyBhDQogICAgZGlmZmljdWx0IHByb2JsZW0gKHZzLiBjb250cm9sIHBsYWNlIG92 ZXJoZWFkKSB0aGF0IGlzIG5vdCBkaXNjdXNzZWQgaGVyZS4NCg0KICAgIDxzbmlwPg0KDQogICAg ICAgRm9yIHRoZSBjYXNlIG9mIGEgbXVsdGlob21lZCBuZXR3b3JrLCBhIHZlaGljbGUgY2FuIGZv bGxvdyB0aGUgZmlyc3QtDQogICAgICAgaG9wIHJvdXRlciBzZWxlY3Rpb24gcnVsZSBkZXNjcmli ZWQgaW4gW1JGQzgwMjhdLiAgVGhhdCBpcywgdGhlDQogICAgICAgdmVoaWNsZSBzaG91bGQgc2Vs ZWN0IGl0cyBkZWZhdWx0IHJvdXRlciBmb3IgZWFjaCBwcmVmaXggYnkNCiAgICAgICBwcmVmZXJy aW5nIHRoZSByb3V0ZXIgdGhhdCBhZHZlcnRpc2VkIHRoZSBwcmVmaXguDQoNCiAgICA+Pj4gU3Rp bGwgcm91dGVyIGRpc2NvdmVyeSAoaW4gYW5kIG91dCkgbXVzdCBiZSB2ZXJ5IGZhc3QuIFRoaW5n IG9mIHRoZSBSQQ0KICAgIGludGVydmFsZSBpbiBNSVB2Ni4gSXMgdGhhdCBzdWZmaWNpZW50PyBU b28gZXhwZW5zaXZlPw0KDQogICAgPHNuaXA+DQoNCiAgICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCiAgICA+Pj4gQW55IGRpc2N1c3Npb24gb24gdGhlIHNlY3VyaXR5IG9mIGNsYXNzaWNh bCBORCBhbmQgb3RoZXIgb3BlcmF0aW9uYWwgaXNzdWVzDQogICAgKHJmYzY1ODMpID8NCg0KICAg IDxzbmlwPg0KDQogICAgICAgU2VjdXJpdHkgYW5kIHByaXZhY3kgYXJlIHBhcmFtb3VudCBpbiBW MkksIFYyViwgYW5kIFYyWCBuZXR3b3JraW5nLg0KICAgICAgIFZlaGljbGVzIGFuZCBpbmZyYXN0 cnVjdHVyZSBtdXN0IGJlIGF1dGhlbnRpY2F0ZWQgaW4gb3JkZXIgdG8NCiAgICAgICBwYXJ0aWNp cGF0ZSBpbiB2ZWhpY3VsYXIgbmV0d29ya2luZy4gIEFsc28sIGluLXZlaGljbGUgZGV2aWNlcyAo ZS5nLiwNCiAgICAgICBFQ1UpIGFuZCBhIGRyaXZlci9wYXNzZW5nZXIncyBtb2JpbGUgZGV2aWNl cyAoZS5nLiwgc21hcnRwaG9uZSBhbmQNCiAgICAgICB0YWJsZXQgUEMpIGluIGEgdmVoaWNsZSBu ZWVkIHRvIGNvbW11bmljYXRlIHdpdGggb3RoZXIgaW4tdmVoaWNsZQ0KICAgICAgIGRldmljZXMg YW5kIGFub3RoZXIgZHJpdmVyL3Bhc3NlbmdlcidzIG1vYmlsZSBkZXZpY2VzIGluIGFub3RoZXIN CiAgICAgICB2ZWhpY2xlLCBvciBvdGhlciBzZXJ2ZXJzIGJlaGluZCBhbiBJUC1SU1UgaW4gYSBz ZWN1cmUgd2F5LiAgRXZlbg0KICAgICAgIHRob3VnaCBhIHZlaGljbGUgaXMgcGVyZmVjdGx5IGF1 dGhlbnRpY2F0ZWQgYW5kIGxlZ2l0aW1hdGUsIGl0IG1heSBiZQ0KICAgICAgIGhhY2tlZCBmb3Ig cnVubmluZyBtYWxpY2lvdXMgYXBwbGljYXRpb25zIHRvIHRyYWNrIGFuZCBjb2xsZWN0IGl0cw0K ICAgICAgIGFuZCBvdGhlciB2ZWhpY2xlcycgaW5mb3JtYXRpb24uICBJbiB0aGlzIGNhc2UsIGFu IGF0dGFjayBtaXRpZ2F0aW9uDQogICAgICAgcHJvY2VzcyBtYXkgYmUgcmVxdWlyZWQgdG8gcmVk dWNlIHRoZSBhZnRlcm1hdGggb2YgbWFsaWNpb3VzDQogICAgICAgYmVoYXZpb3JzLg0KDQogICAg Pj4+IFRoZSBzZWN0aW9uIHNob3VsZCBtZW50aW9uIHRoYXQgYm90aCB3aXRoIGNsYXNzaWNhbCBO RCBhbmQgQllPQSwgYWRkcmVzc2VzDQogICAgY2FuIGJlIGltcGVyc29uYXRlZCwgYW5kIFJGQyA4 OTI4IHByb3RlY3RzIGFnYWluc3QgdGhhdCBpbiBib3RoIGNhc2VzIHdoaWxlDQogICAgbWFpbnRh aW5pbmcgcHJpdmFjeS4NCg0KICAgICAgIEV2ZW4gdGhvdWdoIHZlaGljbGVzIGNhbiBiZSBhdXRo ZW50aWNhdGVkIHdpdGggdmFsaWQgY2VydGlmaWNhdGVzIGJ5DQogICAgICAgYW4gYXV0aGVudGlj YXRpb24gc2VydmVyIGluIHRoZSB2ZWhpY3VsYXIgY2xvdWQsIHRoZSBhdXRoZW50aWNhdGVkDQoN CiAgICA+Pj4gSXMgUEtJIGZlYXNpYmxlIChkZXBsb3lpbmcgaXQgaW4gZXZlcnkgY2FyPykuIElz IGl0IGZhc3QgZW5vdWdoPyBJcyBpdA0KICAgIHJlYWxseSB3aGF0IElQV0FWRSB0aGlua3MgdmVo aWNsZSBzaG91bGQgdXNlPz8/Pz8gPj4+IGUuZy4gd2h5IHdvdWxkIG9uZSBuZWVkDQogICAgdG8g YXV0aGVudGljYXRlIHRvIGEgVjJJIG5ldHdvcms/ID4+PiBmcm9tIHRoZSB0ZXh0IGVhcmxpZXIg aW4gdGhlIGRvYywgaXQNCiAgICBzZWVtZWQgdGhhdCB3aGF0IHlvdSByZWFsbHkgd2FudCBpcyBh Y2Nlc3MgdGhhdCBpcyBmYXN0IHRvIGpvaW4sIGNhcGFibGUgb2YNCiAgICBvZmZlcmluZyB0aGUg cmVhY2hhYmlsaXR5IHlvdSB3YW50LCBhbm9ueW1vdXMsIGFuZCBpbm5vY3VvdXMgKGNhcnMgY2Fu IG5vdCBoYXJtDQogICAgb25lIGFub3RoZXIpLg0KDQogICAgICAgdmVoaWNsZXMgbWF5IGhhcm0g b3RoZXIgdmVoaWNsZXMsIHNvIHRoZWlyIGNvbW11bmljYXRpb24gYWN0aXZpdGllcw0KICAgICAg IG5lZWQgdG8gYmUgbG9nZ2VkIGluIGVpdGhlciBhIGNlbnRyYWwgd2F5IHRocm91Z2ggYSBsb2dn aW5nIHNlcnZlcg0KICAgICAgIChlLmcuLCBUQ0MpIGluIHRoZSB2ZWhpY3VsYXIgY2xvdWQgb3Ig YSBkaXN0cmlidXRlZCB3YXkgKGUuZy4sDQogICAgICAgYmxvY2tjaGFpbiBbQml0Y29pbl0pIGFs b25nIHdpdGggb3RoZXIgdmVoaWNsZXMgb3IgaW5mcmFzdHJ1Y3R1cmUuDQogICAgICAgRm9yIHRo ZSBub24tcmVwdWRpYXRpb24gb2YgdGhlIGhhcm1mdWwgYWN0aXZpdGllcyBvZiBtYWxpY2lvdXMg bm9kZXMsDQogICAgICAgYSBibG9ja2NoYWluIHRlY2hub2xvZ3kgY2FuIGJlIHVzZWQgW0JpdGNv aW5dLiAgRWFjaCBtZXNzYWdlIGZyb20gYQ0KICAgICAgIHZlaGljbGUgY2FuIGJlIHRyZWF0ZWQg YXMgYSB0cmFuc2FjdGlvbiBhbmQgdGhlIG5laWdoYm9yaW5nIHZlaGljbGVzDQogICAgICAgY2Fu IHBsYXkgdGhlIHJvbGUgb2YgcGVlcnMgaW4gYSBjb25zZW5zdXMgbWV0aG9kIG9mIGEgYmxvY2tj aGFpbg0KICAgICAgIFtCaXRjb2luXVtWZWhpY3VsYXItQmxvY2tDaGFpbl0uICBGb3IgYSBibG9j a2NoYWluJ3MgZWZmaWNpZW50DQogICAgICAgY29uc2Vuc3VzIGluIHZlaGljdWxhciBuZXR3b3Jr cyBoYXZpbmcgZmFzdCBtb3ZpbmcgdmVoaWNsZXMsIGEgbmV3DQogICAgICAgY29uc2Vuc3VzIGFs Z29yaXRobSBuZWVkcyB0byBiZSBkZXZlbG9wZWQgb3IgYW4gZXhpc3RpbmcgY29uc2Vuc3VzDQog ICAgICAgYWxnb3JpdGhtIG5lZWRzIHRvIGJlIGVuaGFuY2VkLg0KDQogICAgPj4+IHNvbHV0aW9u IHNwYWNlOyBiZXR0ZXIgZXhwcmVzcyB0aGUgIHNlY3VyaXR5IG5lZWRzIHNpbmNlIHRoaXMgaXMg YSBQUy4NCg0KICAgIDxzbmlwPg0KDQogICAgICAgVG8gaWRlbnRpZnkgbWFsaWNpb3VzIHZlaGlj bGVzIGFtb25nIHZlaGljbGVzLCBhbiBhdXRoZW50aWNhdGlvbg0KICAgICAgIG1ldGhvZCBpcyBy ZXF1aXJlZC4NCg0KICAgID4+PiBOby4gQXMgc2FpZCBlYXJsaWVyIGEgdmVoaWNsZSBjYW4gYmUg aW5mZWN0ZWQuIFlvdSBuZWVkIGlubm9jdW91c25lc3Mud2hpY2gNCiAgICBjYW4gY29tZSBmcm9t IHRoaW5ncyBsaWtlIGlzb2xhdGlvbiwgemVyb3RydXN0LCBhbmQgcHJvdG9jb2xzIHRoYXQgYXJl DQogICAgZGlmZmljdWx0IHRvIGhhY2sgYXJvdW5kLiBDbGFzc2ljYWwgSVB2NiBORCBpcyBvcGVu IGJhci4gUkZDIDg1MDUvODkyOCBpcw0KICAgIHByb3RlY3RlZCBieSBjb25zdHJ1Y3Rpb24sIGFu b255bW91cywgYW5kIGZhc3QuDQoNCiAgICA8c25pcD4NCg0KICAgICAgIEZvciB0aGUgc2V0dXAg b2YgYSBzZWN1cmUgY2hhbm5lbCBvdmVyIElQc2VjIG9yIFRMUywgdGhlIG11bHRpaG9wIFYySQ0K ICAgICAgIGNvbW11bmljYXRpb25zIG92ZXIgRFNSQyBpcyByZXF1aXJlZCBpbiBhIGhpZ2h3YXkg Zm9yIHRoZQ0KICAgICAgIGF1dGhlbnRpY2F0aW9uIGJ5IGludm9sdmluZyBtdWx0aXBsZSBpbnRl cm1lZGlhdGUgdmVoaWNsZXMgYXMgcmVsYXkNCiAgICAgICBub2RlcyB0b3dhcmQgYW4gSVAtUlNV IGNvbm5lY3RlZCB0byBhbiBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaW4gdGhlDQogICAgICAgdmVo aWN1bGFyIGNsb3VkLiAgVGhlIFYySSBjb21tdW5pY2F0aW9ucyBvdmVyIDVHIFYyWCAob3IgTFRF IFYyWCkgaXMNCiAgICAgICByZXF1aXJlZCB0byBhbGxvdyBhIHZlaGljbGUgdG8gY29tbXVuaWNh dGUgZGlyZWN0bHkgd2l0aCBhIGdOb2RlQiAob3INCiAgICAgICBlTm9kZUIpIGNvbm5lY3RlZCB0 byBhbiBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaW4gdGhlIHZlaGljdWxhciBjbG91ZC4NCg0KICAg ID4+PiBzb2x1dGlvbiBzcGFjZS4gSW5zdGVhZCwgeW91IGNvdWxkIG1lbnRpb24gdGhhdCBzZXR0 aW5nIHVwIHNlY3VyZWQgY2hhbm5lbHMNCiAgICBiZXR3ZWVuIGNhcnMgdGhhdCBjcm9zcyBvbmUg YW5vdGhlciBtaWdodCBub3QgY29tcGxldGUgaW4gdGltZSB0byBlc3RhYmxpc2ggdGhlDQogICAg Y29tbXVuaWNhdGlvbiBjaGFubmVsLCBhbmQgdGhhdCB0aGUgaW5ub2N1b3VzbmVzcyBtdXN0IGNv bWUgZnJvbSB6ZXJvdHJ1c3QgaW4NCiAgICB0aGUgdHJhbnNhY3Rpb25zIGJldHdlZW4gdGhlIGNh cnMuDQogICAgICAgRm9yIHRoZSBJUHY2IE5ELCB0aGUgREFEIGlzIHJlcXVpcmVkIHRvIGVuc3Vy ZSB0aGUgdW5pcXVlbmVzcyBvZiB0aGUNCiAgICAgICBJUHY2IGFkZHJlc3Mgb2YgYSB2ZWhpY2xl J3Mgd2lyZWxlc3MgaW50ZXJmYWNlLg0KDQogICAgPj4+IGZvciBjbGFzc2ljYWwgTkQgKFNMQUFD KSB0aGF04oCZcyB0cnVlLiBUaGF0IGlzIG5vdCB3aXRoIFJGQyA4NTA1LCBzaW5jZSB0aGUNCiAg ICBpbmZyYSBtYWludGFpbnMgYSB0YWJsZSBvZiBhbGwgYWRkcmVzc2VzIGluIHVzZSBpbiB0aGUg cHJlZml4IGFuZCBibG9ja3MNCiAgICBkdXBsaWNhdGVzIHdpdGhvdXQgdGhlIFJGQyA0ODYyIERB RCBtZXRob2QuIFRoZSBzdGF0ZWZ1bCBhdXRvY29uZiBhZGRyZXNzIGdyYW50DQogICAgaXMgaW1t ZWRpYXRlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgREFEIGNh biBiZSB1c2VkDQogICAgICAgYXMgYSBmbG9vZGluZyBhdHRhY2sgdGhhdCB1c2VzIHRoZSBEQUQt cmVsYXRlZCBORCBwYWNrZXRzDQogICAgICAgZGlzc2VtaW5hdGVkIG92ZXIgdGhlIFZBTkVUIG9y IHZlaGljdWxhciBuZXR3b3Jrcy4NCg0KICAgID4+PiBhbHNvIGZvciBET1MgYXR0YWNrcy4gWW91 IGNhbiBibG9jayBhIG93bmVyIGZyb20gdXNpbmcgYW4gYWRkcmVzcy4gQQ0KICAgIHJlZmVyZW5j ZSB0byByZmM2OTU5IGlzIG11Y2ggbmVlZGVkIGhlcmUuDQoNCiAgICA8c25pcD4NCg0KICAgICBU aGlzIHBvc3NpYmlsaXR5DQogICAgICAgaW5kaWNhdGVzIHRoYXQgdGhlIHZlaGljbGVzIGFuZCBJ UC1SU1VzIG5lZWQgdG8gZmlsdGVyIG91dCBzdXNwaWNpb3VzDQogICAgICAgTkQgdHJhZmZpYyBp biBhZHZhbmNlLiAgQmFzZWQgb24gdGhlIFNFTkQgW1JGQzM5NzFdIG1lY2hhbmlzbSwgdGhlDQog ICAgICAgYXV0aGVudGljYXRpb24gZm9yIHJvdXRlcnMgKGkuZS4sIElQLVJTVXMpIGNhbiBiZSBj b25kdWN0ZWQgYnkgb25seQ0KICAgICAgIHNlbGVjdGluZyBhbiBJUC1SU1UgdGhhdCBoYXMgYSBj ZXJ0aWZpY2F0aW9uIHBhdGggdG93YXJkIHRydXN0ZWQNCiAgICAgICBwYXJ0aWVzLiAgRm9yIGF1 dGhlbnRpY2F0aW5nIG90aGVyIHZlaGljbGVzLCB0aGUgY3J5cHRvZ3JhcGhpY2FsbHkNCiAgICAg ICBnZW5lcmF0ZWQgYWRkcmVzcyAoQ0dBKSBjYW4gYmUgdXNlZCB0byB2ZXJpZnkgdGhlIHRydWUg b3duZXIgb2YgYQ0KICAgICAgIHJlY2VpdmVkIE5EIG1lc3NhZ2UsIHdoaWNoIHJlcXVpcmVzIHRv IHVzZSB0aGUgQ0dBIE5EIG9wdGlvbiBpbiB0aGUNCiAgICAgICBORCBwcm90b2NvbHMuICBGb3Ig YSBnZW5lcmFsIHByb3RlY3Rpb24gb2YgdGhlIE5EIG1lY2hhbmlzbSwgdGhlIFJTQQ0KICAgICAg IFNpZ25hdHVyZSBORCBvcHRpb24gY2FuIGFsc28gYmUgdXNlZCB0byBwcm90ZWN0IHRoZSBpbnRl Z3JpdHkgb2YgdGhlDQogICAgICAgbWVzc2FnZXMgYnkgcHVibGljIGtleSBzaWduYXR1cmVzLiAg Rm9yIGEgbW9yZSBhZHZhbmNlZA0KICAgICAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSwgYSBk aXN0cmlidXRlZCBibG9ja2NoYWluLWJhc2VkIG1lY2hhbmlzbQ0KICAgICAgIFtWZWhpY3VsYXIt QmxvY2tDaGFpbl0gY2FuIGJlIHVzZWQuDQoNCiAgICA+Pj4gc29sdXRpb24gc3BhY2UuIEFnYWlu LCB0aGUgZHJhZnQgc2hvdWxkIGZvY3VzIG9uIHByb2JsZW1zIGFuZCBuZWVkcy4gVGhlDQogICAg cHJvYmxlbSBoZXJlIGlzIHRoYXQgU0VORCBpcyBjb21wbGV4LCBhbmQgbm90IGltcGxlbWVudGVk IGluIHRoZSBtYWpvciBzdGFjay4NCiAgICBJdCByZWxpZXMgb24gUEtJIGZvciB0cnVzdGluZyB0 aGUgcm91dGVyLiBUaGUgVjJJIG5lZWQgaXMgYSB6ZXJvdHJ1c3QgbW9kZWwNCiAgICB3aGVyZSBv bmUgViwgdGhlIG90aGVyIGxvY2FsIFZzLCBhbmQgdGhlIEksIGNhbiBoZWxwIGVhY2ggb3RoZXIg YW5vbnltb3VzbHkgYW5kDQogICAgaGFybWxlc3NseS4gPHNuaXA+DQoNCiAgICA4LiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcw0KDQogICAgPj4+IG5vIG5vcm1hdGl2ZSByZWZlcmVuY2U/DQoNCiAg ICA+Pj4gbm8gbm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KICAgIDxzbmlwPg0KDQogICAgVm9pbGEh DQoNCiAgICBLZWVwIHNhZmU7DQoNCiAgICBQYXNjYWwNCg0KDQoNCg0K From nobody Fri Jun 18 21:20:15 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B5B3A2092; Fri, 18 Jun 2021 21:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOOvx1yLlftl; Fri, 18 Jun 2021 21:20:02 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 857FD3A208F; Fri, 18 Jun 2021 21:19:58 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id w22-20020a0568304116b02904060c6415c7so11791835ott.1; Fri, 18 Jun 2021 21:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Mnu24OZKpK2F/lpZqL6j6EnKoZS+yOBKWIoQ22+/bgY=; b=QfNL2NIrVB42qC2ZRkV8+Z7IuQbHMh3SfbTrVDA0hDq4vCUUX/M1SnaiI61Zt8K7/n PsxorKalR4b/qhil5jLmc7AjfKs5ytUzxoMugx8nDh7er7RdtQkfILfI1YqfjZSg1k/3 utAde8Jo1xgA7qZEKg8zC/irSxDc3lCGxbhu+SJdQnucTDOgxEaSf4/iXXE2aN9c0k9F qz3b6MzW6Ec9E0mZG1Z7T/+hS03w1ESOtsJacEnPEnZM/Xu8BbeYKs3/RuZ5qiJg7y79 CDdZL+LPfAJVvZ+nRHFbubZ7qnXkfWfyJTm7NFZBrx6Vi4YRtYvRwSQxywuaJyyN2byC SE9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Mnu24OZKpK2F/lpZqL6j6EnKoZS+yOBKWIoQ22+/bgY=; b=mOhpd/Zx2Es5Smczh6jSs5RbsP+Jc/aDw6S7p40+snD2bmCweHIt5iiWKsQj/ARzFt Q7AIqIN8Q/kWj0v0SHZ+Eovgxi3n6c6YViIOJK3D/1fx54Y/Z3F0xqZ/orL6tqZ9lwGH erPIHlim+WCc4muoGqq3rf4Rn3N3HfsIb7YGbY1XRAC6XUelhTDq7gyNRKmcadVHGjoZ KhRMg+sr5EX5l7ZUC1bzU8vNCM/4lnC1BQ3cIg9uY6aEQ5sWg43OP3d4I0FDjIxgzERE /rCxDFbEffxySkN7KwjuitWo37fSJ5hMrWpkfQrXawX+F1JqyaghWTb/adRdld70Wuwn CSOw== X-Gm-Message-State: AOAM532zQWp520y+uq+x7zt0bWPh1Ly3jpBal8+iJq1jzcINVZ0HCppE ytmOTmUJc7doiwMYVMqHn17Wb2lfSN3EFBvlXsE= X-Google-Smtp-Source: ABdhPJw40VTxbuTG7G+wACBjhG6zMkkVUjZPebToxvAAb6p38zLT46jVgW+ZVqnvZPo0kbPVdHt4CrtswudQavCwRbE= X-Received: by 2002:a05:6830:1208:: with SMTP id r8mr12132412otp.155.1624076395868; Fri, 18 Jun 2021 21:19:55 -0700 (PDT) MIME-Version: 1.0 References: <162400216663.17839.1738900015320888640@ietfa.amsl.com> In-Reply-To: From: Erik Kline Date: Fri, 18 Jun 2021 21:19:45 -0700 Message-ID: To: "Eric Vyncke (evyncke)" Cc: "Pascal Thubert (pthubert)" , "int-dir@ietf.org" , "draft-ietf-ipwave-vehicular-networking.all@ietf.org" , "its@ietf.org" , "last-call@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2021 04:20:08 -0000 Oui! On Fri, Jun 18, 2021 at 2:41 PM Eric Vyncke (evyncke) w= rote: > > Thank you very much, Pascal > > -=C3=A9ric > > =EF=BB=BF-----Original Message----- > From: Pascal Thubert via Datatracker > Reply-To: Pascal Thubert > Date: Friday, 18 June 2021 at 09:42 > To: "int-dir@ietf.org" > Cc: "draft-ietf-ipwave-vehicular-networking.all@ietf.org" , "its@ietf.org" , "las= t-call@ietf.org" > Subject: Intdir last call review of draft-ietf-ipwave-vehicular-networkin= g-20 > Resent-From: > Resent-To: , , = , , Eric Vyncke > Resent-Date: Friday, 18 June 2021 at 09:42 > > Reviewer: Pascal Thubert > Review result: Not Ready > > Dear authors > > In summary: > > I read a number of very good drafts collated in one, from the use cas= es that > very complete and ready to publish, to the architecture and protocol = solution > in section 4 that would require more work for completeness. > > There are multiple instances in the use cases where protocols are lis= ted coming > out of the blue, e.g., the references to OMNI that seem artificially = spread > regardless of the context of the section. OMNI is used throughout, bo= th as an > open ended toolbox, and as a carpet under which all problems can be h= idden. > > Reading this doc, OMNI shows as an interface to a software mobile rou= ter, with > multiple of the device physical interfaces connected to the mobile ro= uter. This > makes the stack very simple as the complexity moves to the router. Bu= t now you > have to implement the router. Presented as that, the OMNI router dese= rves its > name, it=E2=80=99s indeed very rich; it seems to cover all forms of M= ANET (many to > choose from) and NEMO (and all the MIP protocol family across address > families), all the possible radio interfaces on which the ND problems= go away > by magic, and whatever else you want to put in there. Is that the int= ention? > > Instead of referring to OMNI for virtually anything, the doc should r= efer to > MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP), > draft-nordmark-intarea-ippl for split subnets, and > draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and subnet m= odels. And > then you can say that all those components can be plugged in the OMNI= router, > and you can discuss which MANET and which MIP you want, including usi= ng OMNI=E2=80=99s > built in mobility. > > Note that my objections are not against the OMNI design, it might be = the > perfect thing and I am already aware of use cases that could be serve= d by a > P2MP interface like OMNI in conjunction with RFC8505 on the P2P subin= terfaces > (recycling the high level design we=E2=80=99ve been shipping for IPv4= / frame relay for > the last 30 years). My objection is of the way the draft uses [OMNI] = as the > magic wand that solves all the problems when what you really do is th= row them > over the fence. I=E2=80=99d rather you focus on problems and use case= s, for which > there=E2=80=99s excellent text, and indicate what needs to be done wi= thout making > assumption on how the needful things will be solved. > > In agreement with a discussion on the 6MAN list, I=E2=80=99d suggest = to split, keep all > that=E2=80=99s use case and problem description and ship it, remove r= eferences to > protocols envisioned in the solution, and start the work on architect= ure of the > solution and the protocol applicability statements separately. An alt= ernate > would be to centralize the discussion on protocols to annex, and expl= ain that > protocol A or B could be envisioned in solution space because to over= this gap > or implement that function. > > In any fashion, the current text is not ready for publication as appl= icability > statement, architecture and or/solution, so the related work should b= e removed > from the main text. But I find it mostly ready for use case and probl= em > statement, more below. > > Review: > > Abstract > > This document discusses the problem statement and use cases of > IPv6-based vehicular networking for Intelligent Transportation > Systems (ITS). > > >>> The document goes beyond that; there was actually a thread at 6MA= N where > Bob Hinden said =E2=80=9C This document says it is a problem statemen= t, but then > becomes a solution document. Might be better to cut it down to only= the > problem statement part. =E2=80=9C >>> Would you consider doing this? = If not, why? Note: > you may want to respond on 6MAN as well. >>> >>>I would have thought = that the > traditional steps of problem statement and applicability statement of= existing > work could be expected from IPWAVE too. >>> Please clarify the steps = that you > intend to follow next with this work. > > > > 1. Introduction > > >>> Very readable and informative section, many thanks! > > Along with these WAVE standards and C-V2X standards, regardless of= a > wireless access technology under the IP stack of a vehicle, vehicu= lar > networks can operate IP mobility with IPv6 [RFC8200] and Mobile IP= v6 > protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv= 6) > [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locato= r/ > ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extende= d > Route Optimization (AERO) [RFC6706BIS]). > > >>> NEMO (RFC 3963) is not cited. Any reason why the vehicle would no= t > transport a network? > > > > This document describes use cases and a problem statement about > IPv6-based vehicular networking for ITS, which is named IPv6 Wirel= ess > Access in Vehicular Environments (IPWAVE). First, it introduces t= he > use cases for using V2V, V2I, and V2X networking in ITS. Next, fo= r > IPv6-based vehicular networks, it makes a gap analysis of current > IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management= , > and Security & Privacy), and then enumerates requirements for the > extensions of those IPv6 protocols, which are tailored to IPv6-bas= ed > vehicular networking. Thus, this document is intended to motivate > development of key protocols for IPWAVE. > > >>> > > > > 2. Terminology > > >>> > > > > o IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a > computer situated in a vehicle (e.g., car, bicycle, autobike, > motor cycle, and a similar one) and a device (e.g., smartphone = and > IoT device). It has at least one IP interface that runs in IEE= E > 802.11-OCB and has an "OBU" transceiver. Also, it may have an = IP > interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] > [TR-22.886-3GPP][TS-23.287-3GPP]. See the definition of the te= rm > "OBU" in [RFC8691]. > > >>> Can that be a router connecting multiple computers? > > > > 3. Use Cases > > >>> This is another great read and an enlightening section. Maybe men= tion in > the abstract that the doc also covers use cases? > > > > Although a Layer-2 solution can provide a support for multihop > communications in vehicular networks, the scalability issue relate= d > to multihop forwarding still remains when vehicles need to > disseminate or forward packets toward multihop-away destinations. = In > addition, the IPv6-based approach for V2V as a network layer proto= col > can accommodate multiple radio technologies as MAC protocols, such= as > 5G V2X and DSRC. Therefore, the existing IPv6 protocol can be > augmented through the addition of an Overlay Multilink Network (OM= NI) > Interface [OMNI] and/or protocol changes in order to support both > wireless single-hop/multihop V2V communications and multiple radio > technologies in vehicular networks. In such a way, vehicles can > communicate with each other by V2V communications to share either = an > emergency situation or road hazard in a highway having multiple ki= nds > of radio technologies, such as 5G V2X and DSRC. > > >>> This text appears in the middle of high level use case, with a cr= ude list > of protocols; this is not a place for it > > >>> On a 6MAN Thread, Brian Carpenter said that the above: > =E2=80=9C > is of concern regardless of the mention of OMNI. Does it mean "can be= " or > "needs to be"? This paragraph seems like a very short summary of a bi= g problem > area. At the end of page 13 there is some related discussion, which m= entions > RPL as part of the solution (good choice, IMHO) but again seems to de= pend on > OMNI. I don't think the fix of simply removing references to OMNI wor= ks, > because it would leave a gap. In an informational document, that is n= ot a > formal problem but as far as this draft describes architecture, I don= 't think > that big a gap is reasonable. "OMNI" is mentioned more than 20 times = in the > document. There are also several references to AERO, which is strongl= y > associated with OMNI. =E2=80=9C >>> I agree with Brian. Here the docu= ment seems to be > mixing solution with problem and putting the cart before the horse. M= y > recommendation is to stick to what needs to be done that IPv6 does no= t do yet > -the reqs and gaps-; but the doc should not step in the how things wi= ll be done > unless the group already decided to do it. The logical next steps to = a PS are > an applicability statement of existing work, and if the gaps cannot b= e filled, > there may be one or more WG chartered to fill those gaps. > > >>> I=E2=80=99d still be happy to see an annex with leads on where th= e solution might > come from like RFC 8691 does. > > > > The existing IPv6 protocol must be augmented through the addition = of > an OMNI interface and/or protocol changes in order to support > wireless multihop V2I communications in a highway where RSUs are > sparsely deployed, so a vehicle can reach the wireless coverage of= an > RSU through the multihop data forwarding of intermediate vehicles. > Thus, IPv6 needs to be extended for multihop V2I communications. > > >>> Note that I have no clue on how well OMNI applies in that space, = maybe it > does very well; but here it comes out of the blue with no justificati= on. If you > mention OMNI you need to detail what it is and which of the V2V prob= lems you > expect it to solve. But then, that=E2=80=99s beyond the scope of a PS= . > > > > The existing IPv6 protocol must be augmented through the addition = of > an OMNI interface and/or protocol changes in order to support > wireless multihop V2X (or V2I2X) communications in an urban road > network where RSUs are deployed at intersections, so a vehicle (or= a > pedestrian's smartphone) can reach the wireless coverage of an RSU > through the multihop data forwarding of intermediate vehicles (or > pedestrians' smartphones). Thus, IPv6 needs to be extended for > multihop V2X (or V2I2X) communications. > > >>> Please be more specific on what the missing functions are and whe= ther they > are missing from the stack development standpoint or if there=E2=80= =99s work needed > from the IETF. 1) If something is really missing in our specs, t= he text to > prove from the use case above is missing 2) how OMNI serves the = use case > could be elaborated in an applicability statement of OMNI for V2xyz, = but it is > a bit blunt to present it as panacea when the problems to be solved a= re not > listed. 3) If you look at it, OMNI seems like a software mobile = router > within a bump in the stack. Can that become too big? > > >>> my view is that the text above and the similar occasions should b= e replaced > by something like : > > The existing IPv6 protocol must be augmented to provide the follow= ing > functions: 1) =E2=80=A6 > > >>> and / or something like: > > In addition to the IPv6 node requirements [RFC 8504], the IPv6 pro= tocol > stack for use in a vehicle must support 1) RFC blah, 2) =E2=80=A6 > > > > To support applications of these V2X use cases, the functions of I= Pv6 > such as VND, VMM, and VSP are prerequisites for IPv6-based packet > exchange, transport-layer session continuity, and secure, safe > communication between a vehicle and a pedestrian either directly o= r > indirectly via an IP-RSU. > > >>> =E2=80=9Cthe functions of IPv6 such as VND, VMM, and VSP=E2=80=9D= does not parse. There=E2=80=99s > no IPv6 reference that provides those functions. If the intention is = to say > that there=E2=80=99s stuff to add to IPv6 to support, like, say, VND= , then this > document fails to define how an IPv6 VND should behave, though it=E2= =80=99s precisely > what I=E2=80=99d expect from a problem statement. > > > > 4. Vehicular Networks > > >>> What is the purpose of section 4 as a whole, problem statement or > applicability statement of the listed protocols? In the former case w= hat=E2=80=99s the > problem? In the latter case it is incomplete and needs to be exported= to an > applicability statement doc with all the possible technologies evalua= ted. > > This section describes an example vehicular network architecture > supporting V2V, V2I, and V2X communications in vehicular networks. > > >>> I read this as presenting a context to explain what the problems = are > instead of presenting the IPVAWE =E2=80=9Carchitecture=E2=80=9D. Mayb= e using the term > =E2=80=9CArchitecture=E2=80=9D here is misleading and led to Bob=E2= =80=99s comment. > > > > 4.1. Vehicular Network Architecture > > Figure 1 shows an example vehicular network architecture for V2I a= nd > V2V in a road network [OMNI]. > > a. Is using OMNI a decision that the WG made for the future work= ? what > does it do and what does it not do? b. Is there work left to be = done? Who > will do that work? Or is it the expectation that OMNI has it all defi= ned > already? > > > > An existing network architecture (e.g., an IP-based aeronautical > network architecture [OMNI][UAM-ITS], a network architecture of > PMIPv6 [RFC5213], and a low-power and lossy network architecture > [RFC6550]) can be extended to a vehicular network architecture for > multihop V2V, V2I, and V2X, as shown in Figure 1. In a highway > scenario, a vehicle may not access an RSU directly because of the > distance of the DSRC coverage (up to 1 km). For example, the OMNI > interface and/or RPL (IPv6 Routing Protocol for Low-Power and Loss= y > Networks) [RFC6550] can be extended to support a multihop V2I sinc= e a > vehicle can take advantage of other vehicles as relay nodes to rea= ch > the RSU. Also, RPL can be extended to support both multihop V2V a= nd > V2X in the similar way. > > >>> all this could fit well in annex; anyway you need to explain what= you > expect the protocols to do and which extension is needed. In the case= of RPL at > least you indicate that it would do routing, but not why you cannot u= se it of > the shelf; for OMNI, what you expect is less clear, though there=E2= =80=99s text > elsewhere about the many radio interfaces that could be used for the = purpose, > and the text in the UAM below that is enlightening. > > > > To support not only the mobility > management of the UAM end systems, but also the multihop and > multilink communications of the UAM interfaces, the UAM end system= s > can employ an Overlay Multilink Network (OMNI) interface [OMNI] as= a > virtual Non-Broadcast Multiple Access (NBMA) connection to a servi= ng > ground domain infrastructure. > > >>> Again, what is the expectation for OMNI? As an overlay it require= s an > underlay; when connecting to a MANET it needs support for that MANET.= The text > above seems to imply that is solves everything in V2xyz like magic; r= eminds me > of the IPv6 multicast abstraction that was supposed to solve the broa= dcast > problem and ended up worsening it. > > > > This infrastructure can be configured > over the underlying data links. The OMNI interface and its link > model provide a means of multilink, multihop and mobility > coordination to the legacy IPv6 ND messaging [RFC4861] according t= o > the NBMA principle. Thus, the OMNI link model can support efficie= nt > UAM internetworking services without additional mobility messaging= , > and without any modification to the IPv6 ND messaging services or > link model. > > >>> Again, what is the expectation for OMNI? As an overlay it require= s an > underlay; the text above seems to imply that is solves everything in = V2xyz like > magic; that would be a stretch, that reminds me of IPv6 multicast tha= t was > supposed to solve the broadcast problem and ended up worsening it. > > > > Multiple vehicles under the coverage of an RSU share a prefix just= as > mobile nodes share a prefix of a Wi-Fi access point in a wireless > LAN. This is a natural characteristic in infrastructure-based > wireless networks. For example, in Figure 1, two vehicles (i.e., > Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 > global addresses for V2I communication. Alternatively, mobile nod= es > can employ an OMNI interface and use their own IPv6 Unique Local > Addresses (ULAs) [RFC4193] over the wireless network without > requiring the messaging of IPv6 Stateless Address Autoconfiguratio= n > (SLAAC) [RFC4862], which uses an on-link prefix provided by the > (visited) wireless LAN; this technique is known as "Bring-Your-Own= - > Addresses". > > >>> Is OMNI the only way to "Bring-Your-Own-Addresses=E2=80=9D? Else= the text could be > more generic, at least use e.g., like the ref to AERO later. >>> What= are the > implications / limitations of doing that =E2=80=93 like they can do l= ine of sight V2V > but not reach the internet, or the need of a local MANET / RPL that = will > accept to route those addresses, or the security / address ownership = validation > issues ? > > > > A single subnet prefix announced by an RSU can span multiple vehic= les > in VANET. For example, in Figure 1, for Prefix 1, three vehicles > (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected > VANET. Also, for Prefix 2, two vehicles (i.e., Vehicle3 and > Vehicle6) can construct another connected VANET, and for Prefix 3, > two vehicles (i.e., Vehicle4 and Vehicle7) can construct another > connected VANET. Alternatively, each vehicle could employ an OMNI > interface with their own ULAs such that no topologically-oriented > subnet prefixes need be announced by the RSU. > > >>> same as above. This seems to restate the same thing, derive an a= ddress > from a topologically correct prefix or use your own with limitations = to be > described. > > > > For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] > specifies several details, including Maximum Transmission Unit (MT= U), > frame format, link-local address, address mapping for unicast and > multicast, stateless autoconfiguration, and subnet structure. An > Ethernet Adaptation (EA) layer is in charge of transforming some > parameters between the IEEE 802.11 MAC layer and the IPv6 network > layer, which is located between the IEEE 802.11-OCB's logical link > control layer and the IPv6 network layer. This IPv6 over 802.11-O= CB > can be used for both V2V and V2I in IPv6-based vehicular networks. > > >>> solution space. > > > > An IPv6 mobility solution is needed for the guarantee of > communication continuity in vehicular networks so that a vehicle's > TCP session can be continued, or UDP packets can be delivered to a > vehicle as a destination without loss while it moves from an IP-RS= U's > wireless coverage to another IP-RSU's wireless coverage. In > Figure 1, assuming that Vehicle2 has a TCP session (or a UDP sessi= on) > with a corresponding node in the vehicular cloud, Vehicle2 can mov= e > from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. = In > this case, a handover for Vehicle2 needs to be performed by either= a > host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a > network-based mobility management scheme (e.g., PMIPv6 [RFC5213] a= nd > AERO [RFC6706BIS]). > > In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a > role of a home agent. On the other hand, in the network-based > mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility > management controller such as a Local Mobility Anchor (LMA) in > PMIPv6, which also serves vehicles as a home agent, and an IP-RSU > plays a role of an access router such as a Mobile Access Gateway > (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs > client functionality in IPv6 stack of a vehicle as a mobile node f= or > mobility signaling message exchange between the vehicle and home > agent. On the other hand, the network-based mobility scheme does = not > need such a client functionality for a vehicle because the network > infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agen= t > handles the mobility signaling message exchange with the home agen= t > (e.g., LMA in PMIPv6) for the sake of the vehicle. > > There are a scalability issue and a route optimization issue in th= e > network-based mobility scheme (e.g., PMIPv6) when an MA covers a > large vehicular network governing many IP-RSUs. In this case, a > distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the > scalability issue by distributing multiple MAs in the vehicular > network such that they are positioned closer to vehicles for route > optimization and bottleneck mitigation in a central MA in the > network-based mobility scheme. All these mobility approaches (i.e= ., > a host-based mobility scheme, network-based mobility scheme, and > distributed mobility scheme) and a hybrid approach of a combinatio= n > of them need to provide an efficient mobility service to vehicles > moving fast and moving along with the relatively predictable > trajectories along the roadways. > > In vehicular networks, the control plane can be separated from the > data plane for efficient mobility management and data forwarding b= y > using the concept of Software-Defined Networking (SDN) > [RFC7149][DMM-FPC]. Note that Forwarding Policy Configuration (FP= C) > in [DMM-FPC], which is a flexible mobility management system, can > manage the separation of data-plane and control-plane in DMM. In > SDN, the control plane and data plane are separated for the effici= ent > management of forwarding elements (e.g., switches and routers) whe= re > an SDN controller configures the forwarding elements in a centrali= zed > way and they perform packet forwarding according to their forwardi= ng > tables that are configured by the SDN controller. An MA as an SDN > controller needs to efficiently configure and monitor its IP-RSUs = and > vehicles for mobility management, location management, and securit= y > services. > > The mobility information of a GPS receiver mounted in its vehicle > (e.g., position, speed, and direction) can be used to accommodate > mobility-aware proactive handover schemes, which can perform the > handover of a vehicle according to its mobility and the wireless > signal strength of a vehicle and an IP-RSU in a proactive way. > > Vehicles can use the TCC as their Home Network having a home agent > for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213]= , > so the TCC (or an MA inside the TCC) maintains the mobility > information of vehicles for location management. IP tunneling ove= r > the wireless link should be avoided for performance efficiency. > Also, in vehicular networks, asymmetric links sometimes exist and > must be considered for wireless communications such as V2V and V2I= . > > >>> This is all very informative text but does not state a problem. = Is there a > problem is left to be solved or are we assessing the applicability of > protocols? Could it for instance, forward point to issues discussed i= n section > 5? > > > > As shown in Figure 3, as internal networks, a vehicle's moving > network and an EN's fixed network are self-contained networks havi= ng > multiple subnets and having an edge router (e.g., IP-OBU and IP-RS= U) > for the communication with another vehicle or another EN. The > internetworking between two internal networks via V2I communicatio= n > requires the exchange of the network parameters and the network > prefixes of the internal networks. For the efficiency, the networ= k > prefixes of the internal networks (as a moving network) in a vehic= le > need to be delegated and configured automatically. Note that a > moving network's network prefix can be called a Mobile Network Pre= fix > (MNP) [OMNI]. > > >>> Then again you=E2=80=99re overselling OMNI. MNP is originally def= ined here > https://datatracker.ietf.org/doc/html/rfc3963#section-2 and that=E2= =80=99s a reference > you can use normatively. > > > > As shown in Figure 3, the addresses used for IPv6 transmissions ov= er > the wireless link interfaces for IP-OBU and IP-RSU can be either > global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be > routed within vehicular networks [OMNI]. > > >>> Then again you=E2=80=99re overselling OMNI. There needs to be a = routing protocol > like a MANET that will accept to carry the > MNPs, and that must be implemented by the infra and both cars. The O= MNI spec > is clear on that. This is why at first glance I see OMNI as a full m= obile > router in a bump in the stack. Now what is the problem behind this? = No such > protocol at IETF? Too many to choose from? No deployment? > > > When global IPv6 addresses > are used, wireless interface configuration and control overhead fo= r > Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener > Discovery (MLD) [RFC2710][RFC3810] should be minimized to support = V2I > and V2X communications for vehicles moving fast along roadways; wh= en > ULAs and the OMNI interface are used, no DAD nor MLD messaging is > needed. > > >>> Then again you=E2=80=99re overselling OMNI. Isn=E2=80=99t it the = no dad needed a property > of injecting a BYOA in the fabric for an GUA MIP Home Address which i= s known to > be unique at home? >>> OTOH, autoconf=E2=80=99ing a random ULA =E2=80= =9CFD=E2=80=A6=E2=80=9Dprefix has lesser > DAD properties than autoconf=E2=80=99ing a random 64bit IID in a clas= sical subnet. So > who says DAD isn=E2=80=99t required for OMNI ULA? >>> note that IMHO = DAD on wireless is > a lot more harm than good, and I agree that with a good pseudo random= generator > the ULA has no chance to collision in the real world, as OMNI claims.= It=E2=80=99s just > that your argument here plays the other way, because there are less r= andom bits > (56) in the ULA prefix than in the IID (62), and if one starts using= more > prefix bits to be non-random, there will be a time when DAD on prefix= is needed. > > > > Let us consider the upload/download time of a vehicle when it pass= es > through the wireless communication coverage of an IP-RSU. For a > given typical setting where 1km is the maximum DSRC communication > range [DSRC] and 100km/h is the speed limit in highway, the dwelli= ng > time can be calculated to be 72 seconds by dividing the diameter o= f > the 2km (i.e., two times of DSRC communication range where an IP-R= SU > is located in the center of the circle of wireless communication) = by > the speed limit of 100km/h (i.e., about 28m/s). For the 72 second= s, > a vehicle passing through the coverage of an IP-RSU can upload and > download data packets to/from the IP-RSU. > > > > 4.3. V2V-based Internetworking > > >>> In this section it looks like the cars are in a stable line of si= ght > relationship. Which is probably fine for a platoon, but when you driv= e along > with friends in different cars, you realize that the line of sight as= sumption > does not stand over time. Soon enough, other cars meddle in, and poss= ibly one > of the cars drives faster and too far ahead so you need the infra to = relay, > possibly over multiple infra hops. > > >>> so in this section, I=E2=80=99d expect to see a Vehicle communica= ting with another > one and using either line of sight or V2V relaying but also using rel= ay via V2I > (multihop I2I not just hub and spoke V2I2V ), alternatively to togeth= er for > redundancy. Is that part of the problem? > > >>> reading deeper section 5 I found excellent text on routing via V = and via I. > This tells that section 4 does not play a good role at justifying sec= tion 5. > Maybe keep section 4 for another doc? > > >>> What kind or reliability is required in a V2V use case? Do you th= ink ND can > handle it? Or MANET? What would be the assumption on L2 (roaming time= , unicast > vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have some = L3 > redundancy? > > > > 5. Problem Statement > > > > In order to specify protocols using the architecture mentioned in > Section 4.1, IPv6 core protocols have to be adapted to overcome > certain challenging aspects of vehicular networking. Since the > vehicles are likely to be moving at great speed, protocol exchange= s > need to be completed in a time relatively short compared to the > lifetime of a link between a vehicle and an IP-RSU, or between two > vehicles. > > >>> Any order of magnitude? > >>> Can you indicate whether this already rules out certain procedure= s, e.g. > DAD ? > > The lifetime of a session varies depending on the session's type s= uch > as a web surfing, voice call over IP, and DNS query. Regardless o= f a > session's type, to guide all the IPv6 packets to their destination > host, IP mobility should be supported for the session. > > >>> this seems to be for unicast when you know who to talk to. Is the= re a need > some multicast groups like anybody around interested in topic blah li= ke I could > be multicasting the speed of vehicles coming the other way that I cro= ssed > recently, for use of vehicles that I=E2=80=99m crossing now, so they = can see a slowdown > on advance > > Thus, the time constraint of a wireless link has a major impact on > IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also > vulnerable to disconnections that occur before the completion of > identity verification and tunnel management. This is especially t= rue > given the unreliable nature of wireless communication. This secti= on > presents key topics such as neighbor discovery and mobility > management. > > >>> Only ND? What about the MANET? > >>> how fast should ND be to be suitable? > >>> is there also a bandwidth check? You can make things much faster = if you > dedicate a lot of spectrum to it. But that can also be a waste. > > 5.1. Neighbor Discovery > > > > The requirements for IPv6 ND for vehicular networks are efficient = DAD > and NUD operations. > > >>> Not lookup? Is it the intention to use IP unicast over MAC broadc= ast, which > is a good idea in my book? > > > > This merging and partitioning should be considered for the > IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) > [RFC4862]. > > >>> Not lookup? Is it the intention to use IP unicast over MAC broadc= ast, which > is a good idea in my book? > > > > Also, the partitioning of a VANET may make vehicles with the same > prefix be physically unreachable. Also, SLAAC needs to prevent IP= v6 > address duplication due to the merging of VANETs. According to th= e > merging and partitioning, a destination vehicle (as an IPv6 host) > needs to be distinguished as either an on-link host or an off-link > host even though the source vehicle uses the same prefix as the > destination vehicle. > > >>> should reference to draft-nordmark-intarea-ippl > > To efficiently prevent IPv6 address duplication due to the VANET > partitioning and merging from happening in vehicular networks, the > vehicular networks need to support a vehicular-network-wide DAD by > defining a scope that is compatible with the legacy DAD. In this > case, two vehicles can communicate with each other when there exis= ts > a communication path over VANET or a combination of VANETs and IP- > RSUs, as shown in Figure 1. By using the vehicular-network-wide D= AD, > vehicles can assure that their IPv6 addresses are unique in the > vehicular network whenever they are connected to the vehicular > infrastructure or become disconnected from it in the form of VANET= . > > >>> Excellent > > ND time-related parameters such as router lifetime and Neighbor > Advertisement (NA) interval need to be adjusted for vehicle speed = and > vehicle density. For example, the NA interval needs to be > dynamically adjusted according to a vehicle's speed so that the > vehicle can maintain its neighboring vehicles in a stable way, > considering the collision probability with the NA messages sent by > other vehicles. > > >>> Is that a problem or just an operational setting that needs to be= found? > >>> Do we need to reconsider the concepts of those timers? > > > > Thus, in IPv6-based vehicular networking, IPv6 ND should have mini= mum > changes for the interoperability with the legacy IPv6 ND used in t= he > Internet, including the DAD and NUD operations. > > >>> I do not find the logical link with the text before, why is this = a =E2=80=9Cthus=E2=80=9D? > >>> why should the ND inside the VANET be constrained to be interoper= able? This > may place constraints on the solution. > > 5.1.1. Link Model > > A prefix model for a vehicular network needs to facilitate the > > >>> Do you mean a =E2=80=9Csubnet model=E2=80=9D as opposed to =E2=80= =9Cprefix model=E2=80=9D. > >>> it would make this piece and the next should refer to > draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA, for b= oth link > and subnet issues. The general ideas are the same, but the gory detai= ls here > are slightly incorrect, like this notion of prefix model than comes o= ut of the > blue. The model is really the subnet model for the subnet associated = to P2MP. > > communication between two vehicles with the same prefix regardless= of > the vehicular network topology as long as there exist bidirectiona= l > E2E paths between them in the vehicular network including VANETs a= nd > IP-RSUs. This prefix model allows vehicles with the same prefix t= o > communicate with each other via a combination of multihop V2V and > multihop V2I with VANETs and IP-RSUs. Note that the OMNI interfac= e > supports an NBMA link model where multihop V2V and V2I communicati= ons > use each mobile node's ULAs without need for any DAD or MLD > messaging. > > >>> again overselling OMNI. > >>> I kinda agree about the OMNI interface model, nothing against tha= t. But you > must see that there needs a lot more than what the OMNI interface to = get > packets across V and I hops to the destination. Like routing ala MANE= T, > redundancy handling ala DetNet because it will be very lossy, path ma= nagement > ala RAW to optimize delivery vs. spectrum=E2=80=A6 And OMNI ignores N= D so it does not > solve the ND problems above. > > IPv6 protocols work under certain assumptions that do not necessar= ily > hold for vehicular wireless access link types other than OMNI/NBMA > [VIP-WAVE][RFC5889]; the rest of this section discusses implicatio= ns > for those link types that do not apply when the OMNI/NBMA link mod= el > > >>> again overselling OMNI. > >>> The keyword here is P2MP / NBMA, and OMNI is one interface that a= ccepts > that. There are others. IBM=E2=80=99s IPv4 over Frame relay was alrea= dy P2MP / NBMA, > using routing to complete the partial mesh in P2MP. The text seems to= imply > that OMNI is the only way to do that and that=E2=80=99s wrong. Also O= MNI is loaded with > other stuff than a plain P2MP capable interface. And ND over P2MP is = not done > by OMNI, OMNI only makes classical ND worse and only works in a full = mesh. OTOH > RFC 8505, which is designed to do ND for P2MP /NBMA would indeed work= very well > within an OMNI interface and solve those problems. >>> My point is th= at you > need to tell the full story or refrain from entering solution space i= n this doc > > > > There is a relationship between a link and a prefix, besides the > different scopes that are expected from the link-local and global > types of IPv6 addresses. In an IPv6 link, it is assumed that all > interfaces which are configured with the same subnet prefix and wi= th > on-link bit set can communicate with each other on an IPv6 link. > > >>> not assumed; that=E2=80=99s what the onlink but set tells. The co= nclusion should be > that the VANET cannot set the O bit. > > However, the vehicular link model needs to define the relationship > between a link and a prefix, considering the dynamics of wireless > links and the characteristics of VANET. > > > > From the previous observation, a vehicular link model should consi= der > the frequent partitioning and merging of VANETs due to vehicle > mobility. Therefore, the vehicular link model needs to use an on- > link prefix and off-link prefix according to the network topology = of > vehicles such as a one-hop reachable network and a multihop reacha= ble > > >>> No, the once a node saw a O bit set that sticks even if it sees o= ther > advertisements of the PIO with the O bit not set. >>> This is a globa= l and > intrinsic property of the prefix (and an attack vector that could be = mentioned > in the sec section). >>> the VANET prefix must never come with the O = bit set. > > > > network (or partitioned networks). If the vehicles with the same > prefix are reachable from each other in one hop, the prefix should= be > on-link. > > >>>> No, see above; but the router may redirect though it is really r= isky > unless this is a stable situation like a parking place. > > Thus, in IPv6-based vehicular networking, the vehicular link model > should have minimum changes for interoperability with standard IPv= 6 > links in an efficient fashion to support IPv6 DAD, MLD and NUD > operations. When the OMNI NBMA link model is used, there are no l= ink > model changes nor DAD/MLD messaging required. > > >>>> again overselling OMNI. > >>>> You need a good P2MP subnet model with routing support when the = mesh is > partial. My company alone has been shipping million of nodes that bui= ld subnets > of thousands, and that was done using IETF standards. > > > > For vehicular networks with high mobility and density, the DAD nee= ds > to be performed efficiently with minimum overhead so that the > vehicles can exchange a driving safety message (e.g., collision > avoidance and accident notification) with each other with a short > interval (e.g., 0.5 second) by a technical report from NHTSA > (National Highway Traffic Safety Administration) [NHTSA-ACAS-Repor= t]. > Such a driving safety message may include a vehicle's mobility > information (i.e., position, speed, direction, and acceleration/ > deceleration). The exchange interval of this message is 0.5 secon= d, > which is required to allow a driver to avoid a rear-end crash from > another vehicle. > > >>> IPv6 over broadcast MAC (used to be called internet 0, 10+ years = ago) > solves that MAC issue since there is no MAC. > > 5.1.3. Routing > > For multihop V2V communications in either a VANET or VANETs via IP= - > RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol = may > be required to support both unicast and multicast in the links of = the > subnet with the same IPv6 prefix. However, it will be costly to r= un > both vehicular ND and a vehicular ad hoc routing protocol in terms= of > control traffic overhead [ID-Multicast-Problems]. > > >>> we do that with IETF standards on battery operated devices alread= y. Using > RFC 8505 for the UNI and RPL for the NNI. It is scalable (we=E2=80=99= ve seen 30 hops in > meshes of thousands in the real world though it=E2=80=99s not the nor= mal operational > model, but can happen to maintain connectivity during the reboot of a= root) and > does not use broadcast. RPL was initially designed as a V2V2V protoco= l but > found its market on the IoT. I=E2=80=99m sure the protocol would glad= ly come back to > its roots. > > A routing protocol for a VANET may cause redundant wireless frames= in > the air to check the neighborhood of each vehicle and compute the > routing information in a VANET with a dynamic network topology > because the IPv6 ND is used to check the neighborhood of each > vehicle. Thus, the vehicular routing needs to take advantage of t= he > IPv6 ND to minimize its control overhead. > > >>> A clean description of the interaction of RPL and RFC 8505 in our= IoT > networks. Note that the speed of the PHY in VANET balanced the instab= ility of > the topology, and RPL still applies. Note also that RPL uses DV with = a routing > stretch in order to minimize the topology awareness that=E2=80=99s ne= eded in each node, > which results in minimal signaling. > > 5.2. Mobility Management > > > > For a mobility management scheme in a shared link, where the wirel= ess > subnets of multiple IP-RSUs share the same prefix, an efficient > vehicular-network-wide DAD is required. If DHCPv6 is used to assi= gn > a unique IPv6 address to each vehicle in this shared link, > > >>> I would not use the term link, or shared. Maybe shared link -> do= main? > > > the DAD is > not required. On the other hand, for a mobility management scheme > with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and O= MNI > [OMNI]), DAD is not required because the IPv6 address of a vehicle= 's > external wireless interface is guaranteed to be unique. > > >>> again overselling OMNI > >>> As I said earlier, this is wring there are (64*) more chances of = a > collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes can c= ollision, > home addresses that are unique on a home network cannot. >>> Now if b= oth the > OMNI prefix and the IID are good randoms, then obviously, the chances= of > collisions round up to 0. >>> Collision is certainly not my worst fea= r. > > There is a > tradeoff between the prefix usage efficiency and DAD overhead. Th= us, > the IPv6 address autoconfiguration for vehicular networks needs to > consider this tradeoff to support efficient mobility management. > > >>> This is way too superficial and hides the reality of things. > - Using a VANET Infra prefix allows direct routability to the interne= t which > BYOA does not since the BYOA is not topologically correct. Yes, it co= sts a DAD > with classic ND, but it does not with RCF8505 and the draft fails to = mention > that. - A BYOA needs a tunnel home, and the node needs to know who is= reachable > inside the VANET and what is not to decide to tunnel or not; this is = a > difficult problem (vs. control place overhead) that is not discussed = here. > > > > For the case of a multihomed network, a vehicle can follow the fir= st- > hop router selection rule described in [RFC8028]. That is, the > vehicle should select its default router for each prefix by > preferring the router that advertised the prefix. > > >>> Still router discovery (in and out) must be very fast. Thing of t= he RA > intervale in MIPv6. Is that sufficient? Too expensive? > > > > 6. Security Considerations > >>> Any discussion on the security of classical ND and other operatio= nal issues > (rfc6583) ? > > > > Security and privacy are paramount in V2I, V2V, and V2X networking= . > Vehicles and infrastructure must be authenticated in order to > participate in vehicular networking. Also, in-vehicle devices (e.= g., > ECU) and a driver/passenger's mobile devices (e.g., smartphone and > tablet PC) in a vehicle need to communicate with other in-vehicle > devices and another driver/passenger's mobile devices in another > vehicle, or other servers behind an IP-RSU in a secure way. Even > though a vehicle is perfectly authenticated and legitimate, it may= be > hacked for running malicious applications to track and collect its > and other vehicles' information. In this case, an attack mitigati= on > process may be required to reduce the aftermath of malicious > behaviors. > > >>> The section should mention that both with classical ND and BYOA, = addresses > can be impersonated, and RFC 8928 protects against that in both cases= while > maintaining privacy. > > Even though vehicles can be authenticated with valid certificates = by > an authentication server in the vehicular cloud, the authenticated > > >>> Is PKI feasible (deploying it in every car?). Is it fast enough? = Is it > really what IPWAVE thinks vehicle should use????? >>> e.g. why would = one need > to authenticate to a V2I network? >>> from the text earlier in the do= c, it > seemed that what you really want is access that is fast to join, capa= ble of > offering the reachability you want, anonymous, and innocuous (cars ca= n not harm > one another). > > vehicles may harm other vehicles, so their communication activitie= s > need to be logged in either a central way through a logging server > (e.g., TCC) in the vehicular cloud or a distributed way (e.g., > blockchain [Bitcoin]) along with other vehicles or infrastructure. > For the non-repudiation of the harmful activities of malicious nod= es, > a blockchain technology can be used [Bitcoin]. Each message from = a > vehicle can be treated as a transaction and the neighboring vehicl= es > can play the role of peers in a consensus method of a blockchain > [Bitcoin][Vehicular-BlockChain]. For a blockchain's efficient > consensus in vehicular networks having fast moving vehicles, a new > consensus algorithm needs to be developed or an existing consensus > algorithm needs to be enhanced. > > >>> solution space; better express the security needs since this is = a PS. > > > > To identify malicious vehicles among vehicles, an authentication > method is required. > > >>> No. As said earlier a vehicle can be infected. You need innocuous= ness.which > can come from things like isolation, zerotrust, and protocols that ar= e > difficult to hack around. Classical IPv6 ND is open bar. RFC 8505/892= 8 is > protected by construction, anonymous, and fast. > > > > For the setup of a secure channel over IPsec or TLS, the multihop = V2I > communications over DSRC is required in a highway for the > authentication by involving multiple intermediate vehicles as rela= y > nodes toward an IP-RSU connected to an authentication server in th= e > vehicular cloud. The V2I communications over 5G V2X (or LTE V2X) = is > required to allow a vehicle to communicate directly with a gNodeB = (or > eNodeB) connected to an authentication server in the vehicular clo= ud. > > >>> solution space. Instead, you could mention that setting up secure= d channels > between cars that cross one another might not complete in time to est= ablish the > communication channel, and that the innocuousness must come from zero= trust in > the transactions between the cars. > For the IPv6 ND, the DAD is required to ensure the uniqueness of t= he > IPv6 address of a vehicle's wireless interface. > > >>> for classical ND (SLAAC) that=E2=80=99s true. That is not with RF= C 8505, since the > infra maintains a table of all addresses in use in the prefix and blo= cks > duplicates without the RFC 4862 DAD method. The stateful autoconf add= ress grant > is immediate. > > This DAD can be used > as a flooding attack that uses the DAD-related ND packets > disseminated over the VANET or vehicular networks. > > >>> also for DOS attacks. You can block a owner from using an address= . A > reference to rfc6959 is much needed here. > > > > This possibility > indicates that the vehicles and IP-RSUs need to filter out suspici= ous > ND traffic in advance. Based on the SEND [RFC3971] mechanism, the > authentication for routers (i.e., IP-RSUs) can be conducted by onl= y > selecting an IP-RSU that has a certification path toward trusted > parties. For authenticating other vehicles, the cryptographically > generated address (CGA) can be used to verify the true owner of a > received ND message, which requires to use the CGA ND option in th= e > ND protocols. For a general protection of the ND mechanism, the R= SA > Signature ND option can also be used to protect the integrity of t= he > messages by public key signatures. For a more advanced > authentication mechanism, a distributed blockchain-based mechanism > [Vehicular-BlockChain] can be used. > > >>> solution space. Again, the draft should focus on problems and nee= ds. The > problem here is that SEND is complex, and not implemented in the majo= r stack. > It relies on PKI for trusting the router. The V2I need is a zerotrust= model > where one V, the other local Vs, and the I, can help each other anony= mously and > harmlessly. > > 8. Informative References > > >>> no normative reference? > > >>> no normative reference? > > > > Voila! > > Keep safe; > > Pascal > > > >